Archívum

Archive for the ‘Exchange’ Category

Out-of-office on Distribution Group

július 24, 2017 4 hozzászólás

Még régebben feltettek nekem egy kérdést, amit érdemesnek tartok egy eszmefuttatásra: miként lehet egy disztribúciós csoporton beállítani automatikus választ?

A kolléga eredeti ötlete az volt, hogy a levél-tippet használja fel (felhasználóknál a beállítás Fájl / Beállítások / Levelek / Email tippek szekció). Nos, az Outlook 2010-től használható email-tipp jellemzően* belső címzett esetén jelenik meg, s arra használható, hogy a feladó kiválasztása után, de még a levél elküldése előtt értesüljünk a címzett állapotáról. Pontosabban, ha az illetőnél be van kapcsolva a “Házon/magán kívül” állapot, akkor az ott megadott szöveg lesz látható még a levél elküldése előtt, illetve, ha tagja valamilyen csoportnak, akkor a csoporton beállított MailTip is látszik.

(* bizonyos, jól meghatározott esetekben külső címzett is, pl. érzékeny információ küldésekor).

Az eredeti kérdésre a választ több módon oldhatjuk meg, példaként 1-1 szerver-oldali, illetve fiók-szinten megvalósított ötletet írok, a teljesség/mélység igénye nélkül (no meg 3rd party megoldások kihagyásával).

A Transport Rule estén a szerveren hozunk létre egy szabályt, de annak formátuma (illetve az SMTP-kódja) nagyon hasonló a hibaüzenetekhez, még akkor is, ha saját hibaüzenetet teszünk be (most maradjunk az egyszerű rgazda szinten), ezért ezt – főleg kezdőknek – nem javaslom.

Fiók-oldalon sokkal elegánsabb megoldási lehetőségünk van, erre például egy dedikált fiókot hoznék létre – ő már tud OoO üzenettel válaszolni (ne feledjük, ez feladónként napi 1 üzenetet eredményez), az általa kapott leveleket pedig automatikusan továbbítani a csoportnak (akár úgy, hogy neki lokálisan is maradjon egy példány, naplózási céllal).

Sokan felkaphatják a fejüket, hogy de ők láttak az elosztási csoportokon olyan pipát, ami OoO-val kapcsolatos. Igen, a régebbi Exchange-ken az Advanced fülön grafikusan ki volt vezetve egy ilyen pipalehetőség („Send Out-of-office message to originator”), de ez csak arra való, hogy a tagok bármelyikén beállított OoO üzeneteket az eredeti feladónak küldje, ne a csoportnak szórja szét. Ha ez megfelelőnek tűnik az eredeti probléma megoldására, számítsunk rá, hogy nem biztos, hogy mindenki egységesen állítja be az ilyen üzeneteket, illetve, amennyiben a csoportból többen beállítottak maguknak saját OoO üzenetet, a feladó mindenkitől megkapja.

Az újabb Exchange-ken a grafikus kivezetés helyét a PS vette át:

Get-DistributionGroup * | Set-DistributionGroup -SendOofMessageToOriginatorEnabled:$true

Amennyiben még tovább bonyolítjuk a kérdést, s szeretnénk képet betenni: nos, ezt nem támogatja az OoO. Ha mégsem bírjuk ki, akkor Outlook segítségével létrehozunk egy szabályt, ami egy olyan sablonra mutat, amelyik megfelelően elő van készítve – de ez már tényleg túlmutat a cikk keretein 🙂

Reklámok
Kategóriák:Exchange Címke: ,

Exchange mentések vs Hyper-V

szeptember 15, 2016 Hozzászólás

Adott helyen egy VM (történetesen egy Exchange) átkerült egy 2012-es gazdagépről egy 2012 R2-t futtató gépre. A mozgatás után látszólag minden rendben működött, így a rendszergazda kollégák nem bolygatták többet.

Egy bizonyos idő eltelte után a szerver nem volt hajlandó fogadni a leveleket, a monitorozó-rendszer erőforráshiányra panaszkodott. Megnézve a paramétereket, a kollégák egyből kiszúrták, hogy itt bizony merevlemez-kapacitás hiányzik, s tudjuk, hogy az Exchange-be épített Back-pressure hatására inkább visszautasítja a levelek fogadását, mint veszélyeztesse „saját épségét”. Tüneti kezelésként gyorsan felszabadítottak némi helyet, de természetesen nem hagyták annyiban a dolgot, biztos, ami biztos alapon segítséget is kértek.

Utánajárva, hogy miért lett tele a kötet, kiderült, hogy a naplók törlése nem történt meg (ez akkor történik meg, amikor egy teljes mentés készül az Exchange-ről). Kiderült, hogy magán a levelező szerveren nem volt beállítva mentés, de a gazdagépen viszont igen, mégpedig a teljes VM mentése. Ez „triggerelni” szokta az Exchange-logok törlését is, itt viszont nem történt meg. Az okot keresve elég hamar rátaláltunk, hogy mikor volt az utolsó teljes mentés (Exchange-konzol segítségével kiolvasható), majd mivel a jelzett dátum körül történt a mozgatás, nyilvánvalóvá vált, hogy ezzel függ össze. Szerencsére a gazdagép Hyper-V konzolját megnyitva egyből látszott a probléma: az Integration Services (itt írtam róla legutóbb) nem volt naprakész. A friss, 2012 R2-s kiegészítőket telepítve, majd a VM-et újraindítva a következő mentés egyből ismét helyreállította a rendet.

Office 2016 gondolatok

november 6, 2015 6 hozzászólás

Az új Outlook 2016 sok embernek fog fejfájást okozni. Az ok egyszerű: Exchange kiszolgálóhoz csak akkor fog tudni csatlakozni, ha rendesen be van állítva az autodiscover szolgáltatás. Mielőtt ezt részleteznénk, nézzük a manuális lehetőségeket: vagy Outlook.com, illetve más Exchange ActiveSync (EAS)-kiszolgáló, vagy Pop/Imap kiszolgáló. Az EAS nem használható Exchange esetén, ugyanis az EAS-protokollt is tervezik kivezetni (miután az Outlook.com-ot átteszik Exchange-alapúra), helyette az OutlookAnywhere használata javasolt. Az idők folyamán így alakultak a lehetőségeink (teljesség igénye nélkül):

Outlook 2003: outlook2003

Outlook 2010: Outlook2010

Outlook 2013: outlook2013

Outlook 2016:outlook2016

Mivel manuális lehetőségünk nincs, nem marad más hátra, mint a levelezés automatikus beállítása. Ahhoz, hogy ez működjön, már Exchange 2007 óta velünk van az Autodiscover lehetőség – még ha eddig nem is mindenki használta.

No de miről is szól ez? Nagy vonalakban: a kliens kiküld egy igényt, mely szerint szeretne adott tartomány CAS-kiszolgálójához csatlakozni, erre kap egy választ, ami alapján „bekonfigurálja” magát (halkan megjegyzem, ez most tényleg nagyon konyha-nyelven volt elmondva). Ahhoz, hogy ez működjön, természetesen a minimum a jól beállított Exchange-kiszolgáló – s itt máris elakadtunk, hiszen az önjelölt rendszergazdák számára a levelezés beállítása kimerül a ki/bejövő forgalom megvalósításánál. Ha ezt az akadályt vettük, akkor még tanúsítvány(ok), illetve a DNS-nevek megfelelő beállítása van hátra.

Nem tartom kizártnak, hogy az új, 2016-os Office terjedése kapcsán nőni fog a „piros gombos” hívások száma, hiszen elég sok helyen a kiszolgáló alap-beállításokkal fut. S akkor még nem beszéltem arról, amiről már egyes kollégák is írtak, hogy Outlook-foltozás volt szükséges bizonyos Exchange-kiszolgálókkal való együttműködéshez.

Exchange DAG szívások

szeptember 15, 2015 Hozzászólás

Adott projekt kapcsán belefutottam egy olyan hibába, hogy az Exch DAG nem akart összejönni – az adatbázis replikációja folyamatosan hibára futott, azzal az üzenettel, hogy az elsődleges kiszolgálón hiányolt egy log-állományt (ami viszont ott volt). Sebaj, ezt a múltkor (bár nem írtam le) egy új adatbázis létrehozásával kerültük ki, amibe átmozgattuk a postafiókokat, most pedig úgy, hogy ideiglenesen áttettük körkörös logolásra, ekkor már simán létrehozta a másolatot (utána természetesen illik visszaállítani a logolást).

Következett (volna) a PF replikációja. Nos, itt látszólag minden szép és jó volt – csak épp replikáció nem történt… Tekintettel arra, hogy 2003-asról migráltak, a múltkoriak alapján manuálisan kellett létrehozni a szükséges mappákat (amennyiben nem akarunk manuálisan belenyúlni, akkor setup.com /prepareAD ismételt futtatásával is illik létrejönnie), valamint a megfelelő nyilvános mappa adatbázisokon módosítani az msExchOwningPFTree értékét, hogy a most létrehozott PF mappa DN-jére mutasson. Viszont az IS újraindítása után (mindkét szerveren) továbbra sem változott a helyzet – így ismét közösen folytattuk a nyomozást.

Egy eddig nem említett lehetőséget vetettünk be: a loggolás szintjét megemeltük (Server configuration, kiszolgálón jobb klikk, Manage Diagnostic Logging Properties) az alábbiak szerint:

  • MSExchangeIS
    • 9001 Public
      • Replication Backfill – High
      • Replication Errors – Medium
      • Replication General – High
      • Replication Incoming Messages – High
      • Replication NDRs – High
      • Replication Outgoing Messages – High

Az Application eseménynaplóban ezután a MSExchangeIS Public Store által generált alábbi bejegyzéseket kell figyeljük (teljes lista itt):

  • 3030
  • 3038
  • 3018
  • 3027

Ennek alapján tisztán látszott, hogy az eseménynaplóban szerepelt a kiküldött levél, de az is kiderült, hogy kiküldésre sem kerülnek a szinkronizációs levelek. Az ok: a kollégák a leírásból az utolsó lépést kihagyták: a Servers konténer törlését. Tartalmilag üres volt, de a konténer még létezett – ennek eltávolítása után máris helyreállt a replikáció.

Igen ám, de az előző tesztelések eredményeképpen az Exch2-n látszólag két PF lett felcsatolva. Ezt nem lehetett látni a PF-management konzolból (ott ráadásul a szerver kiválasztása ablakban hiba is fogadott), egyedül adott PF-mappa replikációjának beállításánál látszott ez a rossz állapot.

Lefuttattuk a

Get-MailboxServer | Get-PublicFolderDatabase

parancsot, ahol egy hibaüzenet segített a megoldás felé vezető úton:

WARNING: The object EXCH2-PFDB02 has been corrupted, and it’s in an inconsistent state. The following validation errors happened:

ADSI Edittel ellenőrizve/javítva a PF objektum msExchOwningPFTree tulajdonságát (ez magával vonja a visszacsatolás – BackLink – értékének módosulását is az msExchOwningPFTreeBL mezőben), majd az IS szolgáltatást újraindítva helyrebillent a lelki béke 🙂

Mielőtt még hátradőltünk volna, a végén, miután megvolt az új CAS Array is, a felhasználók panaszkodtak az ActiveSync működésképtelen voltára. Erre szerencsére „gyors” (értsd: Exchange-tempós 🙂 ) megoldást jelentett a Server config/Client Access varázslójának újrafuttatása (haladóbbak vehetik sorra az alól található fülek: OWA, ECP, stb. beállításait), hogy biztosan mindenhol jól legyen beállítva a külső csatlakozási elérhetőség (external name).

Kategóriák:Exchange Címke: , ,

Exch 2010 SP3 UR8 – nem szabad!

december 12, 2014 8 hozzászólás

Bár nem szeretném elvenni a kenyeret a különböző hírportáloktól, de néhány nap eltelte után sem láttam még azt a hírt, hogy a Microsoft ismét elbaltázott egy frissítést (részint érthető, hiszen csak az hibázik, aki dolgozik – részint viszont olyan alaphiba csúszott be, ami egy hétköznapi tesztelésen már kiderült volna).

Konkrétan nem egy akármilyen termék, a piacon csak bizonyos nyelvi verziókat érintő foltról van szó, hanem a címben említett javításról. A környezetemben a legtöbb levelezési rendszer Exch 2003/2010 alapokon nyugszik (ez nem reprezentatív felmérés 🙂 ), s ezeken elég sok felhasználó postafiókja tengődik. Nos, a rendszergazdáknak álmatlan éjszakákat okozni azzal, hogy a folt telepítése után az Outlook véletlenszerűen nem tud megnyitni elemeket (pl. levelek, mappák), nem tud státuszt váltani (pl. olvasott/olvasatlan), illetve ismételt jelszó-kérésekkel bombázza a felhasználót (közöttük lehetnek VIP-userek is) – véleményem szerint nem a legjobb Karácsony előtti elfoglaltság.

Megoldás: nem szabad feltenni. Aki már feltette, az nyugodtan távolítsa el, egy újraindítás szükséges, de a nyugalom érdekében megéri. A Microsoft már visszavonta a foltot, dolgoznak a problémán, egy újabb verziót fognak kiadni – de aki Wsus-al rendelkezik (ki az, aki nem?), ott is a “Nem engedélyezett” státuszról nyugodtan tegye “Tiltott” állapotba.

Támadás-sorozat

április 24, 2014 Hozzászólás

Egyik ügyfélnél a biztonsági naplóban elkezdtek sorozatosan megjelenni Security 529 azonosítójú hibaüzenetek:

Forrás Eseményazonosító Legutóbbi előfordulás Összes előfordulás
  Security 529 2014.04.21. 3:20 1 530 *
Bejelentkezési hiba:
  Ok: Ismeretlen felhasználó vagy rossz jelszó
  Felhasználónév: oracle
  Tartomány:  
  Bejelentkezés típusa: 3
  Bejelentkezési folyamat: Advapi
  Hitelesítési csomag: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
  Munkaállomás neve: DL380
  Hívó felhasználóneve: DL380$
  Hívó tartománya: DOMAIN
  Hívó bejelentkezési azonosítója: (0x0,0x3E7)
  Hívó folyamatazonosítója: 2052
  Átvitt szolgáltatások:
  Forrás hálózati címe:
  Forrásport:

Első körben ellenőrizték a tűzfalat, de ott nem volt sem az RDP, sem a http beengedve, de természetesen az SMTP igen. Ez a tény, valamint a folyamat azonosítójának visszafejtése (Inetinfo.exe) vezettek el oda, hogy valószínűleg STMP-támadás áldozatai lettek.

További adatok kiderítése céljából az ESM-ben megemeltük a logolást: STMP-protokoll/log engedélyezés, majd a loggolás engedélyezése mellett található tulajdonság-lapon, annak is a speciális fülén tudunk további adatokat bekapcsolni.

Ennek alapján kiderült az ip-cím, majd ezt lekövetve az is, hogy egy Shanghaj-i címről küldik a hitelesíteni próbálkozó emaileket. Ilyenkor néha segít, ha a támadó gép szolgáltatójának írott levéllel jelezzük, hogy adott kliense fertőzött – volt, hogy ilyenkor aktív kommunikáció alakult ki 🙂

 

Kategóriák:Exchange Címke: ,

Exchange 2010 SP3 UR2

augusztus 19, 2013 3 hozzászólás

A múlt héten, kedden kijött frissítések (legalábbis a címben említett folt biztosan) megmutatták, hogy miért jó megfontoltan telepíteni a javításokat. Legalábbis azon kollégák egy részénél, akik rendelkeznek a piros gombbal, páran máris jelezték segítségbeli igényüket.

A gond ugyanis az, hogy a megszokottól ellentétben az említett folt igényli az SP3 telepítőt. Ha ezt automatikusan nem találja, illetve a telepítés során nem mutatjuk meg neki (pl. automatikusan Wsus-ról próbál települni), akkor  Error 8024002D hibaüzenettel sikertelen telepítésnek lehetünk tanúi:

Exch2010SP3UR2

Nem kell megrémülni, a szokott helyről letöltve az SP3-at, kicsomagolva, majd újraindítva a telepítést sikeresek lehetünk. Sőt, ha nem akarunk azzal bajlódni, hogy megmutassuk a telepítőnek a szervízcsomag helyét, csomagoljuk ki egyből abba a könyvtárba, ahol az várja. Ennek lekérdezése az alábbi paranccsal történik:

Get-ItemProperty “HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{4934D1EA-BE46-48B1-8847-F1AF20E892C1}” | Select InstallSource

A kicsomagolás után ráengedjük a foltot, majd hátradőlhetünk…

p.s. a folt telepítése utáni újraindítást követő ellenőrzésre (mint itt írtam, nem jó a szokásos Get-ExchangeServer) használhatjuk vagy a már hivatkozott cikkbeli Névjegy-et, vagy az alábbi parancsot:

GCM exsetup |%{$_.Fileversioninfo}

Kategóriák:Exchange Címke: , ,