Category: exchange

Az eltűnt e-mail esete

2013-03-20 / / 0 Comments

Tegnapelőtt este egy weboldal nem engedett be. Megpróbáltam resetelni a jelszavam. A folyamat:

Küldenek egy e-mail-t, amiben van egy link, erre kattintva kapok egy másik levelet, benne az egyszerhasználatos jelszavammal. Szokásos eljárás.

Megjött az első levél, rákattintok a linkre, közli, hogy küldi a jelszavam.

Második e-mail sehol. Várok… várok… még mindig várok. Nem jön.

A dolog nem volt se fontos, se sürgős, így napirendre tértem a téma felett.

Másnap reggel a telefonomon nézem az adott postaládát, a levél ott van. A megfelelő időben, előző este érkezett.

Leültem az irodai gépem Outlookja elé. A levelet ott sem látom. Akkor nézzük meg OWA-ban. Bejelentkezek a saját nevemben, majd megpróbálok átlépni abba a postaládába, ahova a levél érkezett (ez nem az elsődleges fiókom, hanem a freemail fiókom “exchange-esített” változata). Nem sikerül, az OWA dob egy ronda hibát valami null property-re.

Keresgélek a neten és ezt találom:

http://support.microsoft.com/kb/2777852

Remek, ezek szerint akkor tudom megnyitni a másik mailboxom ilyen módon az OWA-ban, ha a freemail.hu-t felveszem az accepted domain listára. Ehhez valahogy nincs kedvem.

Belépek a postaládába az eredeti felhasználója nevében.

A keresett levél ott van… és … azt állítja magáról, hogy private. Ok. Ez teljesen érthető. A private jelzéssel rendelkező leveleket a Full Access joggal rendelkező másik felhasználó nem láthatja.

Ez így nekem nem jó.

Tehát a megoldás:

– csinálok egy terjesztési csoportot

– belerakom az összes érintett másodlagos postaládát

– csinálok egy Transport Rule-t amely az összes a terjesztési csoport tagjainak menő levélről leszedi a Sensitivity fejlécet, ha abban private/personal/confidental van.

Teszt kívülről. Működik.

Mint a régész

2013-03-13 / / 5 Comments

Valamiért ez a cikk a privát blogba került bele, pedig simán illik ide is, méghozzá a szívás kategóriába. Sőt, a nagyon nagy szívás kategória sem lenne túlzás.
Csak hogy összezavarjam az ellenfelet, a történet végét itt írom meg.

Miután az éles szervert többször is betérdeltettem pusztán csak azzal, hogy belenéztem néhány public folderbe, kitaláltuk, hogy bevirtualizáljuk(1) az egész cuccot, atombiztosan elszeparáljuk az éles környezettől és azt már piszkálgathatom. Hogy mennyire ment könnyen a virtualizálás? Sajnos a kolléga nem ír blogot, pedig nagyban tudná vele javítani a közhangulatot. Amekkorát szopott vele, ahhoz képest egy átlag IT jómunkásember élete hawaii pihenés.

(1) A virtualizálás rendszeresen behalt, végül disaster recovery alapon backupból állt fel a rendszer.

Oké, röpke 2-3 hét alatt elkészült a tesztrendszer, odáig, hogy már futott az Information Store szolgáltatás az Exchange szerveren. Csak hogy tisztázzuk a játékteret: Windows 2003 STD, Exchange 2003 STD, külön gépen Windows 2003 STD domain controller.
Ezt a rendszert már sokkal bátrabban tanulmányozhattam. Mit mondjak, egyik döbbenetből a másikba estem. Először találtam néhány public foldert, ahol 100000 fölött volt az elemszám. Aztán találtam egyet, ahol 200000 fölött volt. Aztán beléptem az admin nevében és a postafiókjában, az elküldött elemeknél – írdd és mondd – 2000000 fölött. Ha esetleg gondot okoznának a nullák, akkor leírom betűkkel is: kétmillió feletti elemszám. Standard 32 bites Windows szerveren, melynek nem lehet 3 GB-nél több memóriát adni.

Párbeszéd.
– Az Exchange alapvetően a memóriában dolgozik – jelentettem ki.
– Csak nem a miénk – vont vállat a helyi ember – A miénk kizárólag diszkre.

Kitérő.
Egyszer valamikor egy nagyobb cég rendszereit tekergettem, mint szerver adminisztrátor. Szintén Exchange 2003. A szerver nem muzsikált túl jól, ezért kihívtunk egy Microsoft rapid mérnököt, vizsgálja át és mondjon róla véleményt. A csajszi szó szerint ledobta a haját, amikor megtudta, hogy néhány felhasználónál vannak olyan folderek, melyekben 60000 feletti az elemszám. Erre a számra mondta azt, hogy borzalmasan sok, csoda, hogy egyáltalán működik a szerver.
Kitérő vége.

Nos, mint ahogy korábban is írtam, ez a cég az Exchange platformra tette a… a mindent. Gyakorlatilag ezen megy a teljes céges workflow. Ezt kellett feltérképeznem.

Kitérő.
Az Exchange 2000-ben jelentek meg az event sinkek. Rögtön kétfajta is lett belőlük: store sinkek és transport sinkek. Az előbbi az adatbázismotorra figyelt, az utóbbi az smtp motorra. Sinket úgy lehetett létrehozni, hogy a fejlesztőember megírta a kódot, akár vbscriptben, akár vb-ben, de úgy emlékszem, írhatta C#-ban is. Ebből aztán gyártott egy COM objektumot és beregisztrálta a Windows-ba. Nem mennék bele a részletekbe, de a kétfajta sinknek más volt a beépülési technikája. A store sinkek látszódtak a Component Services konzolban, a transzport sinkek viszont nem, ezeket csak egy spéci szkript segítségével lehetett kezelni. A sinkek úgy működtek, hogy rákapcsolódtak egy eseményfigyelőre (ezeket kezelte az Event Service) és ha az bekövetkezett, akkor elindult a hozzájuk rendelt kód. Aztán a Microsoft látta, hogy ez így nem igazán jó. 2005-ben ezt az egészet – beleértve a webstore-hoz kapcsolódó matyizást is – kitette egy külön termékbe, ez lett a Sharepoint. Az Exchange 2007-ből eltűntek a transport sinkek, helyettük bejöttek a transport agent-ek. Az Exchange 2010-ből pedig eltűntek a store sinkek is.
Kitérő vége.

Az én vizsgálódásomnak az volt a célja, hogy a workflow milyen komponenseket használ. Ha például van benne transport sink, akkor megette a fene, mert ekkor már a 2007-es Exchange-re sem tudunk áttérni. Nem kicsit nehezítette a feladatot, hogy az egész roppant bonyolult rendszerről semmilyen dokumentáció nem volt, és akik készítették, mára elérhetetlenek. A rendszer csak úgy ketyeg magában.

Az első eredmények biztatóak voltak. Az smtpreg.vbs szerint transport sink nincs. Store sinkből csak a CDO for Workflow (CDOWF) volt beregisztrálva. (Innovation never stops.) Ez gáz, mert ez a CDO a 2007-ben megszűnt, de ha nem használják, akkor simán mehetünk tovább, akár a 2010-es verzióig is. Honnan tudjuk, hogy használják-e vagy sem? Ki kell nyerni a rendszerből az összes kódot és át kell vizsgálni. Bagatell.

Hol lehet kód? Custom sink nincs, tehát egyedi COM objektum sincs. Lehetnek még speciális formok, melyek mögött ott figyelhet egy-egy szkript. Nos, ilyenből rengeteg volt. Külön nehezíti a helyzetet, hogy a custom formok is több helyen lehetnek: létezik egy központi form tároló a public folder hierarchiában, külön el lehet helyezni formokat az egyes public folderek tulajdonságai között, emellett lehetnek formok a felhasználók postafiókjaiban is. Csak hogy érezzük a nagyságrendet: a központi tárolóban volt tíz egyedi form, emellett volt több tízezer public folder, melyeket – dokumentáció híján – egyenként kellene végignézni, hogy publikáltak-e a folder adatlapjába egyedi formot, plusz ott volt valami ezer kliens, akiknek a cachelt profiljába töltődtek le különböző formok. Ja, és a céges IT folyamatok között szerepelt egy olyan lépés, hogy az Outlook 2003 telepítésekor fel kellett telepíteni egy setup.exe segítségével két darab saját fejlesztésű dll-t, melyekről persze senkinek nem volt semmilyen infója. Az egész cucc csak max. Outlook2003-mal(2) működött és max. 32 bites XP-n. (Ez persze elég rendesen bebetonozta a céget a kőkorszakba.)

(2) A szkriptekben volt egy verzióvizsgálat. A lehető legbénább módon. Azt vizsgálta, hogy a kliensoldali CDO verzió első 3 karaktere egyenlő-e(!!!) az ‘1.2’ karakterlánccal. Azaz az Outlook2003 CDO verziószáma (1.21) még átment a vizsgálaton, de az Outlook 2007 CDO verziószáma (6.5) már nem. Aztán hogy felülről kompatibilis-e az új CDO, az más kérdés.

Szóval hajrá.

Átnéztem több száz public foldert. (Nyilván egy bizonyos mélység alá már nem mentem le, meg a nevek is beszédesek voltak.) Első körben találtam 37, szkripttel is rendelkező egyedi formot, szanaszét a rendszerben. (Később kiderült, hogy ennél jóval több van, de ekkor már mindegy volt.) Ezeket átbogarásztam és örömmel tapasztaltam, hogy semmi eseményfigyelés sincs bennük, egyszerű vbscript és MAPI.

Csakhogy. Két dolog is nyugtalanított.

  • A helyi emberünk szerint, ha leáll az Event Service, akkor összedől a workflow is. Márpedig ha minden az átnézett formok alapján működik, akkor nem kellene, hogy függjön a szolgáltatástól.
  • A formok alapján rekonstruáltam a folyamatot, majd összevetettem a valós folyamatokkal, mármint azokkal, melyeket a felhasználók tapasztalnak. És volt egy lyuk. Egész egyszerűen voltak olyan lépések, melyek semmelyik formban nem szerepeltek, szabály sem volt rájuk, mégis megtörténtek. Ráadásul ennek a hiányzó folyamatdarabnak erősen eseményvezérelt szaga volt. Csak hát… nem volt custom sink.

Mese nincs, meg kell nézni megint az éles rendszert. Az egyik nap bementem az ügyfélhez, és az egyik informatikus kollégájukkal elkezdtük vizsgálgatni az éles rendszert. Naná, hogy lefagyott. (Fogalmazzunk úgy, hogy nem vagyok túl népszerű ember arrafelé.) De mielőtt kinyírtuk volna, találtam valami teljesen meglepőt. Az ő Outlookjában a Public Folderek tulajdonságlapján volt egy plusz fül, Agents néven. És amögött szkriptek voltak. Rengeteg. Mármint rengeteg foldernél egy-egy szkript.

Legalább annyira zavarban voltam, mint Pinokkió anyák napján. Mi ez???

Utánaolvastam. Aztán a fejemhez kaptam. Dinoszaurusz: event szkript.

Kitérő.
Talán az 5.0, talán az 5.5 Exchange-ben debütált, valamikor 1997-98 környékén az Event Service. (Nem biztos, hogy pontosan emlékszem, cefet régen volt.) Egyértelműen Lotus Notes behatásra: az MS is szerette volna, ha a levelek mozgására lehetne valami folyamatot építeni. A beavatkozási lehetőség szkriptek segítségével történt, ezek voltak az event szkriptek. Egyszerűen megírtuk a szkriptet – figyelve benne egy bizonyos eseményt, pl. új elem érkezését a folderbe, aztán mellétettük a hozzá kapcsolódó akciót – majd ezt a szkriptet a folder Agents fülén beadtuk. Itt még voltak olyan finomságok, hogy magát a szkript futását is lehetett állítgatni. Ez az elképzelés nem jött be, ehelyett vezették be az Exchange 2000-ben a sinkeket, de kompatibilitási okokból a szkripteket is megtartották, egészen a 2003-as verzióig.
Kitérő vége.

Azaz nekem nem 10 évvel ezelőtti technológiát kellett felderítenem, hanem 15 évvel ezelőttit. Ja, hogy a tesztrendszerben miért nem láttam ezt a fület? Mert nem mindig látszik. Csak, ha megfelelő (Atyauristens) jogosultsággal lépünk be és az Outlookban nem cachelt a profilunk.

Oké. Nézzük. Rögtön az első vizsgált szkriptben ott figyelt a Folder_OnMessageCreated() függvény, azaz a custom script megrántotta a Scripting Agent COM objektumot, mely viszont rendszeresen rángatja a CDO-t, illetve azon keresztül az Event Service-t. Melyik CDO-t? Itt már elbizonytalanodtam. Oké, az 5.5 esetében ez nem volt kérdés, akkor az 1.1-es volt. Mivel a 2003 alatt is megy, így valószínűleg elboldogul az 1.2x változattal is. Vagy ott már a CDOWF kell neki? Hiszen mi más miatt lenne az ide feltelepítve? De itt már megint zavarban vagyok, mert mintha a CDOWF-et nem lehetne direktben piszkálni, hanem a benne lévő sinket kellene hivogatni saját alkalmazásból, melynek viszont látszódnia kellene a Component Services-ben is. Talán. Másfelől, ha a sima CDO 1.2-t használja, akkor is gáz van, mert a 2007-ben már az sincs benne. Viszont állítólag fel lehet rá telepíteni. Ilyet láttam már, a T-online szakértője szenvedett véresen hetekig, mert a Onebridge nem tudott együttműködni az Exchange 2007-tel, még azután sem, miután feltettük a szerverre a Onebridge által kötelezően igényelt CDO 1.21-et. Végül a CDO1.2-nek valamilyen korábbi, azóta már nem beszerezhető változatával oldották meg, ha jól emlékszem. De legyen. És akkor mi van? Mennek-e az 1997-es event szkriptek a 2007-es Exchange-en? Amikor már az utódjának tekinthető sink technológia egyik felét is visszavonták? Amikor már a szkriptelés Powershellből megy? A neten semmit sem találtam, egy-két bizonytalan fórumbejegyzéseken kívül. Egyszerűen ez a két fogalom – event script és Exchange 2007 – nem szerepelnek egy lapon.
Szóval tipródtam egy csomót, aztán egyszer csak megtaláltam a választ:

Event service
No longer available. Retain a computer that is running Exchange 2000/2003 in the Exchange 2007 organization if you need this functionality.

Na, ezzel a megoldással csak adnánk egy pofont a szarnak. Mixelt 2003/2007 rendszer üzemeltetése önmagában is nehézkes, de egy ilyen egyedi, átláthatatlan workflow-val együtt kezelhetetlen rémálom lenne, miközben semmit sem vinne előre, mert a leginkább erőforrásigényes, leginkább sérülékeny folyamat továbbra is a meglévő, harmatgyenge 2003-as szerveren futna.
Verdikt: a szerver kurvára nem upgradelhető.

Ez már nem is történelem, hanem mitológia.

ps.
Hangulati aláfestésként egy Dilbert rajz.

Disable-ExchangeCertificate

2013-03-12 / / 0 Comments

Ne is keressük a címben szereplő EMS cmdletet. Nincs ilyen. A párja az Enable-ExchangeCertificate természetesen létezik. Van még olyan, hogy Remove-ExchangeCertificate, de az nem ugyanaz.

Miről is van szó?

Egy kissé is tapasztalt Exchange rendszergazda tudja, hogy az Enable-ExchangeCertificate parancsal lehet, a certificate store-ban tárolt tanúsítványokat az Exchange különböző szolgáltatásaihoz rendelni.

Néhány héttel ezelőtt az egyik ügyfelünknél azt a feladatot kaptam, hogy rakjam rendbe a tanúsítványokat. Ez abból állt volna, hogy a régi, már nem használt tanúsítványokat leszedjük a szolgáltatásokról, majd a tesztidőszakot követően eltávolítjuk a store-ból.

Először elkezdtem keresni, hogy milyen parancsal lehet ezt megtenni. Sokat keresgéltem, de csak azt találtam, hogy a tanúsítványt el tudom távolítani a store-ból, de a szolgáltatást nem tudom leszedni róla.

Az ügyfélnél ez egy alacsony prioritású feladat volt, így  a dolgot végül is ennyiben hagytuk.

Tegnap a nagy álljunk vissza androidra című felbuzdulásom kapcsán nekiálltam, hogy rendbetegyem a saját Exchange-emen az IMAP tanúsítványát. A problémáról itt írtam: http://it-pro-hu.blogspot.hu/2013/02/mi-bajom-az-androiddal.html A feladat a következő:

Az IMAP-nak a már jó ideje megvett, de be nem üzemelt Netlockos tanúsítványt kell használnia, az IISnek ugyanakkor a saját CA által kiállítottat mert nem akartam most szétszedni az egyész SAN-os/Autodiscover-es miskulanciát.

Megpróbáltam az IMAP-ról leszedni a régi tanúsítványt és természetesen újra a néhány héttel ezelőtti problémába futottam. Itt és most viszont nem akartam feladni. Arra gondoltam, hogy az Exchange azt az információt, hogy melyik tanúsítvány van hozzárendelve egy adott szolgáltatáshoz, biztosan tárolja valahol. Az Exchange tudtommal a különböző konfigurációs beállításokat alapvetően két helyen tárolja: az Active Directory-ban és különböző XML konfigurációs fájlokban:

– ADSIEdit -> configuration namespace -> semmi

– LDIFDE -> configuration namespace export -> az export fájlban keresgélve -> semmi

– Előkerestem az IMAP és POP3 szolgáltatás .Net Assembly-jét -> .config fájl -> semmi

– IIS Metabase -> semmi

Kezd a dolog kifogni rajtam. Felhívtam Józsit, hátha van valami ötlete. Sajnos nem volt.

Tovább keresgélve ráakadtam erre a cikkre:

http://www.msexchange.org/articles-tutorials/exchange-server-2007/management-administration/managing-exchange-certificates-part3.html

Itt ezen megakadt a szemem:

By running the cmdlet, Enable-ExchangeCertificate, you will enable a certificate for one or more services by updating the metadata stored with the certificate.

Every service has different metadata requirements, and will have different properties updated:

  • POP3-IMAP4: msExchPopImapX509CertificateName property will be updated;
  • IIS: Default Web Site will be updated;
  • SMTP: the Network Service account will be granted Read access to the appropriate private file key in the directory Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys;
  • UM: certificate property will be updated to include Unified Messaging.

Hoppá, ezek szerint nem reszelgetünk konfigurációs információkat, hanem a névegyezőségből és a tanúsítvány jogokból adódik, hogy mi látszik a Get-ExchangeCertificate parancs kimenetében.

Ellenőrzésképpen tettem is egy gyors próbát.

Az alapállapot az volt, hogy mind a saját CA-m által kiállított tanúsítvány, mind a NetLock-os hozzá volt rendelve az IMAP szolgáltatáshoz.

Az IMAP szolgáltatáson elrontottam a site nevét.

Láss csodát: Mindkét tanúsítványról eltűnt az IMAP flag. Ezek után persze kérdés, hogy a rendszer mi alapján dönt, ha több lehetséges tanúsítvány van.

A másik része a dolognak az All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys könyvtár tartalma. Itt találhatóak a Local System tanúsítványai. Sajnos a fájlnevek köszönő viszonyban sincsenek a tanúsitvány thumbprintjével, firendly nevével, vagy CN-jével, vagy akár bármi értelmezhető paraméterével. Az itt található tanúsítványok közül az használható SMTP hitelesítésre amilyikre a Network Service usernek olvasási joga van (az az érzésem, hogy ez az olvasási jog ugyanúgy szükséges a POP3-hoz és az IMAP-hoz is de ezt még nem tudtam tesztelni, ha ez igaz és szükséges a tanúsítványok szétválasztása, akkor érdemes elgondolkozni, hogy a Network Service helyett egyedi service accountokat használjuk a szolgáltatásokhoz).

Ha itt állítani akarunk valamit akkor merül fel a kérdés, hogy a fájlok közül vajon melyiket kell piszkálnunk, amikor mi csak a tanúsítvány thumbprintjét ismerjük (jó lenne ezeket a jogokat a certificate mmc-ben állítani, de ott sajnos erre nincs lehetőség).

Vajon hogyan tudjuk a thumbprintet összerendelni a fájlokkal? Újabb keresgélés a neten. A megoldás innen adódik:

http://jorgequestforknowledge.wordpress.com/2012/02/10/managing-certificates-on-a-windows-computer-with-powershell/

Az itt található scripteket kicsit átpofozva írtam egy scriptet ami a thumbprint alapján megadja a fájl nevét és a jogosultságait:

param([string]$ThumbPrint)
$Cert = dir cert:\LocalMachine\My | where {$_.ThumbPrint -eq $ThumbPrint}
$MachineKeysLocation = $env:ALLUSERSPROFILE + “\Microsoft\Crypto\RSA\MachineKeys\”
$KeyFileName = $Cert.PrivateKey.CspKeyContainerInfo.UniqueKeyContainerName
$KeyFilePath = $MachineKeysLocation + $KeyFileName
Write-Host FriendlyName: $Cert.FriendlyName
Write-Host Subject: $Cert.Subject
Get-Acl $KeyFilePath | fl

EmployeeID vagy EmployeeNumber? Szerinted mindegy?

2013-02-28 / / 0 Comments

A válasz: NEM. Ha igen lenne, talán létre se jött volna ez a cikk.

De kezdjük az elején.

Kb. másfél éve építettünk egy elég nagy rendszert (AD/Exchange). Az ügyfél azzal az igénnyel állt elő, hogy az Active Directory-ba későbbi felhasználásra kerüljön bele a HR rendszerben használt egyedi azonosító.

Körülnéztem, hogy mit lehetne erre használni, és arra jutottam, hogy van két attribútum: Az EmployeeID és az EmployeeNumber. Nagyjából pénzfeldobással az elsőre esett a választás.

Az AD feltöltése kapcsán némi PowerShell scriptel ez kitöltésre is került.

Azt nem tudom, hogy az elmúlt időben használták-e ezt valamire, de két napja előjött az igény, hogy az EmployeeID jelenjen meg az Outlookban, a címlistában (GAL/OAB).

Az ügyfél azt is kibogarászta, hogy az Exchange-ben van egy Details Template Editor, amivel a kliens oldalon pl. a GAL-ban tárolt felhasználók tulajdonságlapjának megjelenését lehet beállítani (ez számomra újdonság volt, de mindig tanul az ember). A probléma csak az, hogy itt a választható attributumok között nem találta meg az EmployeeID-t.

Keresgélve ezt találtam:

http://blogs.technet.com/b/exchange/archive/2010/03/10/3409495.aspx

Ebből az derül ki (amit alapból is sejtettem), hogy egy AD attribútum, akkor jelenhet meg a GAL-ban, ha benne van a GC-ben. Tehát fogtam magam és bekapcsoltam, hogy az EmployeeID megjelenjen a GC-ben.

Három órával később az ügyfél jelentkezett, hogy a Details Template Editorban még mindig nem látja az EmployeeID-t.

Ma reggel ránéztem, és tényleg nincs ott. Újabb google. Az eredmény:

http://exchangepedia.com/2008/06/modifying-display-templates-and-additional-attributes.html

http://mostlyexchange.blogspot.hu/2005/03/adding-attributes-to-exchange-details.html

Tehát rövden:

Csak olyan AD attribútum jelenhet meg a Details Template-ben aminek van mAPIID-ja. Az EmployeeID-nak nincs, az EmployeeNumber-nek meg van. Remek.

Két megoldás kínálkozik. Vagy átpakoljuk az összes EmployeeID-t az EmployeeNumber-be, vagy az EmployeeID-nak csinálunk mAPIID-t.

Az első egy rövid PowerShell script, a második pedig egy kőkemény hegesztés, ami ráadásul nem is támogatott…

Visszanyomás

2013-02-20 / / 5 Comments

Habár szerintem már nincs olyan Exchange-közeli ember, aki ne hallott volna az elbökött bevezetése miatt felettébb rossz hírnévre szert tett back-pressure folyamatról, de még mindig van hús a csonton, melyet le lehet rágni.

Ügyfél. Exchange 2007, délután fejreáll. Szaki elkezd nyomozni, megállapítja, hogy elfogyott a C:-n a hely (hiába, hol legyen az smtp queue), elkezdi átrakni a D:-re, de aztán gyorsan el kell mennie máshová, telefon nekem, hogy fejezzem be. Az ilyen hívásokban benne van minden, amiért öröm élni: ideges ügyfél, fejreállt levelezés és egy más ember által elkezdett, de aztán félbehagyott megoldási folyamat.
Szerencsére a probléma tényleg egyértelmű volt: világosan ott figyelt a logban, hogy a queue log-ra kalkulált hely elfogyott, azaz a pánikindikátor 97%-on állt, és ekkor az Exchange már lelövi a levelezést.

Emlékszem, anno mennyit anyáztuk ezért az Exchange fejlesztőket, pedig alapvetően igazuk van. Úgy döntöttek, hogy az adatbázisok – és a 2007-estől már a queue is adatbázis – konzisztens állapota fontosabb, mint a szolgáltatás megléte, azaz ha már borzasztóan kevés a hely, akkor elindítanak egy clean shutdown-t, még mielőtt az elfogyott hely miatt dirty shutdown következne be. Viszont az anyázás is jogos volt, ugyanis az első verzióban a kevés hely az 5GB-re volt belőve. Persze, hogy nem értette az egyszeri admin, hogy most mi a fasz baj van, amikor a 10 GB-s diszk fele még szabad? Cifrázta a helyzetet, hogy nem esett le, sőt, a tapasztalataim szerint még ma sem esett le sokaknak, hogy a queue is adatbázis, tehát bőven hagyni kell neki helyet. És legfőképpen nem a meglehetősen elhanyagolt C: partíción tárolni.

No, mindegy, a kollégától megtudtam, hogy elindított egy szkriptet, mely átmozgatja a queue-t a D: meghajtóra, a folyamat le is ment, de valami még nem kerek, mert továbbra sem indul a el Transport service. Ekkor tovább szürkült a tekintetem. Valahogy nem szeretem, ha az ilyen kényes lépéseket szkriptből futtatjuk, különösen akkor nem, ha maga a mozgatás nem bonyolult és ráadásul jól dokumentált is. Így kezdhettem azzal, hogy leellenőriztem a szkriptet.
Ránézésre minden rendben. Jogosultságok beállítva, ahogy kell, az edgetransport.exe.config fájlban is korrektek a queue bejegyzései. A Transport service pedig elindult, majd pár másodperc múlva megállt.
Hmm.
Eventlog. Azt írja, hogy valami process fogja a queue adatbázist, az Exchange nem fér hozzá.
Vírusirtó. Tuti. A rohadt anyját. Megnéztem és így legyen lottó ötösöm. Valós idejű fájlvédelem bekapcsolva, a kivételek között nem szerepelt az új queue könyvtára. Felvettem. Erre az antivírus program közölte, hogy ehhez újra kellene indítani a gépet.
Hívtam a helyi embert.
– Te, újra kellene indítani az Exchange szervert. Gondolom, nem probléma, mert úgysem megy a levelezés.
– Ööö, ez nem Exchange szerver, hanem SBS. Ezen megy a cég mindene.
– Oké, értem. Újraindítható?
– Nem igazán.
– Tőlem. De addig nem lesz levelezés.
– Khm. Megkérdezem az ügyfelet.

Hamarosan jött a telefon.
– Újraindítható. Akár többször is.

Gondolom, mindenkit hazazavartak, hogy mára vége a munkaidőnek. Szeretem az ilyen rugalmasságot.
Restart. Transport service? Megint áll. Nofene, nofene. Eventlog. Ugyanaz. Valami fogja az adatbázist.
Itt hirtelen elfogytak az ötleteim. Oké, ismerem a Process Explorert, de általában csak a legvégső esetben használom. Kell itt még lennie kézzelfogható magyarázatnak.
Böngésztem tovább az eventlogot és hoppá! Nem csak egy hibaszál van, hanem kettő. Az egyik ez a ‘valami fogja a queue-t’, de van egy másik is, mely nem a szolgáltatás indításakor keletkezik, hanem rendszeres időközönként. Hogy mit mond? Hát, ez elég fura. Az a baja, hogy nem tudja meghatározni a D: meghajtóra jellemző minimális allokációs egység értékét. (Vagy valami hasonló. Nem írtam fel, meg egyébként is, magyar nyelvű szerver.)
Még csak nem is hallottam hasonlóról, de elméletileg okozhatja ez is a bajt. Gugli. Nem mondanám, hogy túl sok találatot kaptam, de ugye az ideális keresés az, amikor csak egy találat van, de az pont az, ami kell. És volt is egy elgondolkodtató cikk: azt írta a hapi, hogy ahhoz, hogy az Exchange 2007 adatbázist tudjon üzemeltetni egy meghajtón, a Network Service számára FC jogot kell adni a gyökérkönyvtáron. Csak. Megnéztem. Nem volt. Hjaj. Megadtam.
Persze, hogy elböktem. Nem mentem be az Advanced gomb mögé, hanem csak nyomtam egy OK-t. Erre elkezdte hozzáadni a Network Service-t a D: meghajtó összes objektumához. Vártam 5 percet. Aztán kimentem konyhába, megvacsoráztam. Fél óra. Visszajöttem. Még nem fejezte be. Na, ja: SBS, azaz fájlszerver is. Aztán lelőttem: mivel ez addicionális jogadás, így nem lesz belőle senkinek sem baja, ha a fájlok felénél nem lesz benne a Network Service a listában. Különben is, ha elindul az Exchange, akkor rendezem a jogosultságokat.
A lényeg: a gyökér most már jó. Transport Service restart… aztán pár másodperc múlva megállt.
Ilyen nincs.
Aki rendszeresen hárít el incidenseket, tudja, milyen érzés ez. Amikor sokadjára állítasz fel valamilyen hipotézist – egyik zseniálisabb, mint a másik – aztán feltúrod az internetet, hogyan lehet a feltételezett akadályt eltakarítani, majd valahogy el is takarítod, aztán hátradőlsz… és nem, az incidens nem szűnik meg.
A végén tényleg használnom kell a Process Explorer-t.
Aztán eszembe jutott még valami. Az a nyűves antivírus szoftver. Nem lehet, hogy az nem engedi elérni a D: gyökeret? Most már nem finomkodtam, kikapcsoltam a realtime fájlvédelmet. Service restart… és… és még megy… még mindig megy… nocsak, még mindig… eventlog… semmi. Ez megjavult.
Hátradőlés. Huh.
Aztán a következő kérdés: hogyan tovább? Mondjam azt az ügyfélnek, hogy ne használjon fájlszintű vírusvédelmet? Egy fájlszerveren? Háát, izé. Akkor inkább próbáljuk meg a két rendszert összenutolni, hátha elketyegnek egymás mellett. Drasztikus kísérlet #1: visszaindítottam a realtime védelmet. A Transport service meg se rezdült. Jó jel. Drasztikus kisérlet #2: bekapcsolt realtime védelem mellett újraindítottam a Transport szolgáltatást. Elindult. Sőt. nem is állt le. Még jobb jel. Tehát elég volt meghatároznia azt az allokációs egységet egyszer, utána már nem piszkálja a gyökeret. Drasztikus kisérlet #3: szerver újraindít. Transport service ugyanúgy megy. Tehát a meghatározott értéket nem a memóriában tárolta, hanem ki is írta valahová.
Oké. Case solved.

Tanulság?

Van az Exchange adminok egyes számú posztulátuma:
“Mindig a víruskereső a hibás.”
Nos, ezt meg kell változtatni a következő formulára:
“Mindig a víruskereső a hibás, még akkor is, ha látszólag ártatlan.”

Exchange 2010 SP3 – Végre

2013-02-13 / / 2 Comments

Tegnapi napon megjelent az Exchange 2010 SP3. !!!VÉGRE!!!

Ez talán a leginkább várt frissítése az Exchange-nek. A legfontosabb dologok amket tartalmaz:

– Az első Exchange 2010 kiadás ami telepíthető Windows 2012-re

– A minimális SP szint az Exchnage 2013 együttéléshez (ez sajnos még nem az igazi, mert Exchange 2013 oldalon kell hozzá egy CU1 jelű frissítés ami még nincs kész)

– Internet Explorer 10 támogatás

Forrás: http://blogs.technet.com/b/exchange/archive/2013/02/12/released-exchange-server-2010-sp3.aspx

Exchange patch és egyebek

2012-12-14 / / 4 Comments

Nemrég megkérdezték tőlem, miért paráznak az Exchange adminok a hotfixek telepítésétől. Megemlítettem, hogy két olyan esetről is tudok, amikor egy-egy rollup pack hazavágta a rendszert, és a kardjukba dőlt adminokat nem igazán vigasztalta, hogy az MS később visszavonta a csomagokat.

Nos, itt egy újabb csapda. Azt írják az Exchange blogon, hogy habár a Windows Update / WSUS / SCCM mind lelkendezve ajánlja ki az opcionális frissítések között a Windows Management Framework 3.0-t – igen, benne a csábos Powershell 3.0-val – az Exchange 2007/2010-et futtató gépekre inkább ne telepítsük. Ha mégis feltennénk, számíthatunk arra, hogy a rollup packok nem települnek fel, illetve az EMS begolyózik. Szóval óvatosan.

targetAddress avagy spóroljunk a licenszeken

2012-11-30 / / 5 Comments

Most következik az az eset, amikor bebizonyítom, hogy nem értek az Exchange-hez.

Mit csinálunk olyankor, amikor van egy email címünk, amiért a saját Exchange szervezetünk a felelős, de az ide érkező leveleket tovább kell küldenünk egy külső címre, és saját rendszerünkön soha egy darab levelet sem kell tárolnunk, ami a megadott címre érkezik?

Én (és az a gyanúm, hogy ezzel nem vagyok egyedül) a következőt tettem a fenti esetben. Létrehoztam a saját címünkhöz egy postaládát, a külső címhez egy kontaktot és a postaládát ráirányítottam a kontaktra. Megbékéltem azzal, hogy ez ronda, sőt minden egyes ilyen akció visz magával egy nem is túl olcsó CAL-t.

Mostanában a több ügyfélnél az Exchange 2003 – Exchange 2010 Cross-Forest migrációval birkózom (ez egyszer még megér egy másik cikket). Ennek kapcsán meglepetten tapasztaltam, hogy a migráció végén a rendszer egy olyan Mail Enabled User-t (ez ugye Exchange szempontból egy kontakt, és mint ilyen nincs postaládája) hagy maga után. Ami viszont képes leveleket továbbítani pontosan úgy, ahogy a fenti kérdésben szerepel.

Némi nyomozás után kiderült, hogy a tettes a targetAddress nevű AD property. Tehát minden levél, ami a kontakt egyik proxyaddress-ére érkezik azt a rendszer tovább küldi a targetAddress property-ben szereplő címre. Ráadásul a rendszer azt a kedvességet is megteszi (mind Exchange 2003 mind 2010 esetén), hogy a targetAddress property-t eleve kitölti a kontakt email címére.

Ebből adódóan az eredeti kérdésre adott válasz így változik:

Felveszünk egy kontaktot a külső címmel, majd a kontakt proxyAddresses listájába felvesszük az átirányítani kívánt saját címet.

Kész vagyunk. Mínusz egy CAL.

AntiSpam Update

2012-11-29 / / 6 Comments

Van egy dolog, ami már jó ideje bosszant.

Az Exchange 2007/2010 lehetőséget biztosít arra, hogy a Hub Transport szerveren feltelepísük a Microsoft AntiSpam agent-jeit. Ezzel kapunk egy jól működő, nagy tudású spam szűrő infrastruktúrát.

Ez ugyan nem annyira hatékony, mint a ForeFront for Exchange, továbbá nincs benne vírusirtó, viszont ingyen van.

Amikor ez a lehetőség először megjelent az Exchange 2007-ben, akkor lehetőségünk volt arra, hogy a hozzá tartozó definíciós fájlokat automatikusan frissítsük (Ez a ForeFront nélkül 3 hetente történt). Ez a lehetőség egy adott ponton megszűnt. Pontosabban, ha nincs ForeFrontunk akkor az Exchange maga nem frissít, hanem ezt a Windows Update teszi meg helyette.

Ezzel viszont gond van. Én magam részéről szerveren sosem kapcsolom be a frissítések automatikus telepítését (csak az automatikus letöltést), mert a folyamatos üzem miatt az nem elfogadható, hogy a szerver újrainduljon, amikor az update-nek ehhez van kedve, ráadásul bizonyos környezetekben a biztonsági frissítések csak tesztelés után kerülhetnek az éles rendszerbe. Ebből adódóan nem csak a biztonsági frissítések, hanem az AntiSpam definició sem települ automatikusan, aminek pedig kellene.

A fenti állapotot kezelendő írtam egy kis javascriptet ami feltelepíti az AntiSpam definíciós fájlt. És csak azt. Ha ezt a kis scriptet (cscript.exe SpamUpdate.js) berakjuk a Task Scheduler-be akkor a fenti problémát megoldottuk.

A script innen tölthető le.

Vissza a múltba

2012-07-19 / / 12 Comments

Kérdés jött az ügyféltől: hát mi most mit csináljunk? A helyzet röviden: lejárt a korábbi tanúsítványuk, meg szerették volna hosszabbítani, de a szolgáltató már nem volt hajlandó olyan SAN tanúsítványt kiadni, amelyikben belső név (cegnev.local) is szerepel. Ekkor viszont összedől az Exchange publikálásuk.

Első körben az volt a reakcióm, hogy szolgáltatót gyorsan kirúgni és keresni helyette egy másikat, amelyik nem ennyire vaskalapos. De mielőtt válaszoltam volna, a biztonság kedvéért futottam egy kört a guglin, és… eltátottam a számat.

  • http://help.securepaynet.net/article/6935?ci=72665&prog_id=wittyweb&isc=ssl-01

    • Ha jól értelmezem, akkor a tanúsítványszolgáltatók összedugták a buksijukat és arra jutottak, hogy az internet biztonságosabbá tétele érdekében legkésőbb 2016 októberéig mindegyikőjük visszavonja az összes olyan, általa kiadott tanúsítványt, amelynek akár a Primary Domain, akár a Subject Alternate Name mezőjében belső név, vagy privát IP cím szerepel.
    Ezzel gyakorlatilag ki is nyírták az összes olyan Exchange publikálást, ahol a belső tartományt nem split DNS alapon hozták létre, azaz a belső tartomány neve nem egyezik meg a cég külső nevével. Azaz hiába örvendeztünk pár évvel ezelőtt, hogy vége a tengernyi szopásnak, használhatunk SAN tanúsítványt az Exchange publikálásokhoz… ennek vége. Elvették a játékunkat.

    Informatikai közhely, hogy a biztonság és a kényelem egymást kizáró fogalmak: ha szigorítom a biztonságot, csökken a kényelem. Mindenki ismeri a sztorit, hogy az egyre hosszabb, egyre bonyolultabb jelszavak elméletileg növelik a biztonságot, de csak egy ideig, mert ha a felhasználó már képtelen lesz megjegyezni, akkor leírja egy papírra és kiragasztja a monitorra. Nesze neked, biztonság.
    Úgy néz ki, most is elértünk erre a szintre. Mit fog csinálni az egyszeri rendszergazda? Az, amelyiket komoly felvilágosító munkával éppen nemrég sikerült meggyőzni, hogy felejtse el a saját tanúsítványt és használjon szolgáltató által kiadottat? Szó nélkül visszatér a saját tanúsítványra. Itt olyan SAN tanúsítványt állít ki, amilyet akar, a terjesztését meg megoldja valahogyan. Mert akkorát szigorítottak a biztonságon, melyet már nem tud lekezelni.

    Illetve… van egy másik út, a mazochizmus útja. Nem, nem arra gondolok, hogy átnevezzük a tartományainkat, vagy létrehozunk egy új Active Directoryt és átmigrálunk bele mindent. Ez már nem mazochizmus, hanem öngyilkosság. Ellenben visszautazunk a múltba. Oda, amikor az Exchange 2003 publikálásoknál még nem volt SAN tanúsítvány. Persze azóta a világ sokkal bonyolultabb lett, de az elv maradt a régi:

    Végeztünk? Hát, ha szigorúan az Exchange könyvtáraira gondolunk, akkor igen. De mi is van az Outlook Anywhere mögött? Az RPC over HTTPS, mely gyakorlatilag két könyvtár az IIS default site alatt. Igen, default. Tehát ezeket is duplázni kell az új site alá. Létezik new-rpcvirtualdirectory parancs? Nem igazán. Mi a megoldás?
    Hekk.
    Meg kell keresni a default web site alatt az ApplicationHost.config fájlt, átmásolni az új site alá, majd átmásolni az rpc, rpcwithcert virtuális könyvtárakra vonatkozó részeket, értelemszerűen módosítva a sitenév bejegyzéseket. (Részletesen itt olvasható a módszer. Senkit ne tévesszen meg, hogy ez az RD Gateway szolgáltatásra vonatkozik, a gyakorlatban ugyanazokat a virtuális könyvtárakat használja, mint az Outlook Anywhere. Egy korábbi, az RD Gateway-t is érintő írásomban az egyik módszer konkrétan úgy is kezdődik, hogy a TMG-n használjuk az Exchange varázslót a publikáló szabályhoz.)

    Haladjunk tovább:

    • Az új site-hoz kötözzük hozzá a tanúsítványszolgáltató által kiadott tanúsítványt (melyben már nincs benne a cegnev.local név).
    • A reverse proxy-n (ISA, TMG, etc) gondoskodjunk róla, hogy az új site szolgáltatásai legyenek kipublikálva. (A nevekre figyeljünk oda, amennyiben szükséges, forgassuk a könyvtárneveket is.)

    Nagyjából ennyi. Az Exchange már működik. De olyan nagyon azért ne sóhajtsunk fel:

    • Mi lesz a Sharepoint szolgáltatásokkal?
    • Mi lesz az RD Web oldalunkkal?
    • Végül mi lesz az OCS\Lync szolgáltatásokkal?

    Agyhalál. Biztonságos internet. Ja.

    A mentés ronda lelkivilága

    2012-06-05 / / 0 Comments

    Ritkán szoktam az Exchange blogról linkelni, valahogy úgy érzem, hogy aki érdeklődik a téma iránt, az úgyis rajta lóg az rss csatornájukon. Most viszont kitettek egy nagyon-nagyon-nagyon hiánypótló írást, melyet mindenkinek el kell olvasnia, azoknak is, akik csak ezt a blogot követik. (“Ha én valamit szeretek magamban, az a szerénység.”)

    Export-mailbox, szomorodj meg

    2012-05-27 / / 3 Comments

    Hajnalban megállt az export. Azt mondta, hogy

    Export-Mailbox : Error was found for XY (xy@cegnev.hu) because: Error occurred in the step: Approving object. An unknown error has occurred., error code: -2147221219 At line:1 char:2312
    + CategoryInfo: InvalidOperation: (179:Int32) [Export-Mailbox], RecipientTaskException
    + FullyQualifiedErrorId : 7D782610,Microsoft.Exchange.Management.RecipientTasks.ExportMailbox

    Próbáltam utánajárni, mi is lehet ez. Volt a neten minden, zárjam be az Outlookot (ki sem volt nyitva), állítsak be valós default gateway-t (be volt), vagy futtassak le egy fixmapi nevű programot. Pusztán kíváncsiságból ráküldtem ismét, minden módosítás nélkül ugyanazt a parancsot, amelyen elhasalt. (Természetesen az exportálandó postafiókok közül kivettem a már készeket.) Simán vette az akadályt, most is az fut.

    Megvan, mi lehetett a probléma: alvás közben nem imádkoztam elég intenzíven. Aztán eddig tartott a deikus töltet.

    Ideges? Á, egyáltalán nem vagyok az. De reggel simán bevettem a savcsökkentő (kék) gyógyszerem helyett az éjszakai (fehér) koleszterincsökkentőt.

    Halott ember visszalő

    2012-05-26 / / 2 Comments

    Ezt írtam korábban:

    Itt már lejjebb adjuk az igényeket, eszébe se jusson windowsupdate-tel foglalkozni.

    Naív dolog volt azt hinni, hogy a windowsupdate ennyiben fogja hagyni. A nagy kapkodásban a kolléga ugyanis automatikus beállításon hagyta, én meg elfelejtettem leellenőrizni – őszintén szólva, egyikünknek sem jutott eszébe, hogy egyáltalán létezik – az a dög pedig, mármint a windowsupdate, hajnalban restartolta a gépet, teljeskörűen ignorálva azt, hogy milyen fontos processz fut rajta.
    Kora reggel, még félig kinyílt szemmel néztem rá a monitorra és elhűlve láttam, hogy nem látok semmit. Megszakadt a session. Meg a jókedvem. A kiadott utasítás ugyanis úgy nézett ki, hogy a get-mailbox parancs kimenetele volt belecsövezve az export-mailbox parancsba. Csakhogy a get-mailbox a jó ég tudja, milyen alapon rendezi sorrendbe a postafiókokat, de hogy nem ABC sorrendben, az biztos. Kénytelen voltam lehúzni egy listát, kimazsolázni, hogy kinek készült már el a pst-je, a többiek nevét pedig úgy összerakni egy szövegszerkesztőben, hogy be lehessen tolni az export-mailbox parancsba. Mindezt kora reggel, még kávé előtt.
    Oké, elkészült, parancs átmásol a PSH ablakba, enter – váratlan PS hiba. Ó, hogy szomorodj meg! De most legalább már tudtam a megoldást. Szerver, kliens újraindít. (Közben gyors kávé.) Beléptem a kliensre, parancs átmásol a PSH ablakba, enter – és ismét váratlan PS hiba. De most tényleg váratlan, mert még én sem számítottam rá. Egyből le is konyult az orrom. Ez most már minőségileg más helyzet, innen hogyan tovább? Aztán eszembe jutott egy fontos momentum: újraindítás közben elfelejtettem imádkozni. Tehát újraindítottam a klienst és a szervert _még egyszer_, közben barbár imákat mormoltam és a biztonság kedvéért elővettem a legcsúnyább nézésemet is. És most már elindult a szkript. Hogy az informatika egzakt tudomány? Persze, királyfi.

    Egyébként tényleg hihetetlen ez az egész és nevezhetném groteszk balszerencse-sorozatnak is, de vegyük észre, hogy van azért mögötte nem átgondolt, kapkodós gányolás is. Ha még emlékszünk, az Exchange 2007 trágya, félkész állapotban jött ki a piacra, és a nagyon várt, de időhiány miatt kimaradt funkciókat utólag hegesztgették bele, service és rollup pack-ek segítségével. Ilyen utólag beleműtött dolog volt az export-mailbox kibővítése a pst fájlok kezelésével. Ezen különösen látszik az utólagos toldozgatás, hiszen egy alapvetően szerveroldalon optimális folyamatot raktak ki a kilens oldalra, azért, mert ott már volt pst-t kezelni tudó MAPI motor, az Outlook. Igaz, emiatt a teljes adatbázismennyiséget át kell tolni kétszer a hálózaton, a feldolgozást egy erőforrásait tekintve sokkal-sokkal gyengébb gépen kell futtatni (Exchange 2007 esetén 32 bites kliensen), és akkor még nem is beszéltünk a kliensgépek speciális nyűgeiről, mint például a tipikusan automatikusra állított windowsupdate szolgáltatás, vagy éppen a rafinált csoportházirendek.

    Na, mindegy, újabb fél nap csúszás, azaz most már egy teljes nap.

    Powerhell

    2012-05-25 / / 1 Comment

    Nevezhetjük szerencsének, de eddig még sikerült megúsznom a postafiókok nagy tömegben történő exportálását pst fájlokba. Eddig. Háát…

    A környezet ránézésre nem túl veszélyes. 230 postafiók, 160 GB adatmennyiség. A szerver jól méretezett. A kliens, amelyikről a másolást végezni kell – a lehetőségekhez képest – szintén.
    Ezen azért rugózzunk egy kicsit, mert később fontos lesz. Exchange 2007, az export-mailbox követelménye 32 bites(!) Outlook 2007, szigorúan 32 bites(!) Windows 7-en. Erre kell még egy 32 bites Exchange 2007 admin csomag.
    Még a tesztfázisban összeraktam egy virtuális kliensgépet, hogy ismerkedjek a folyamat dinamikájával. Másra nem is volt jó, mert diszk, az nem volt mögötte, de sikerült bejátszani a parancsot, eljátszottam a nyelvi beállításokkal, szóval felkészültem.
    A migrációra a helyi emberünkkel közösen összeraktunk egy kliensgépet. Az éles indulás előtt ezen is teszteltem egy kicsit, minden működött, mint egy svájci óra.
    Eldördült a startpisztoly, levélforgalom leállít, a kliensen parancs kiad, elégedetten hátradől. Kábé 10 percig. Ekkor kezdett el sikítozni a Windows, hogy eldobta az agyát. Konkrétan elfogyott a memóriája. Ezzel párhuzamosan a másolás is beállt, mint a gerely. Kilőttem a taszkot. Fejvakarás. Nem túl sokáig, mert a helyzet hamarosan világossá vált. A Windows ugye 32 bites, ebben a maximum RAM 4 GB lehet. Volt még a pagefile, a kettő együtt 10 GB. Az export-mailbox egyszerre 4 szálat indít és balszerencsémre rögtön az első csoportban benne volt a titkárság postafiókja, nem is mondom, mekkora mérettel. Lúzer hiba volt. Felnyomtam a virtuális memóriát 40 GB-re, restart, aztán elkezdtem újra.
    Nem indult el. A powershell fél perc szutykolódás után váratlan hibát dobott, a legsemmitmondóbb 1000-es hibaüzenettel. Újraindítás már volt, tehát ebben sem reménykedhettem. Mi romolhatott el? Persze, játszottam még a parancs maxthreads paraméterével, de el se jutott odáig a folyamat, a powershell sorra dobta a váratlan hibákat. Pedig addigra már megszokhatta volna.
    A leginkább logikus gondolat az volt, hogy amikor erőszakosan kilőttem a powershell processzt, akkor megsérülhetett valami alkotóeleme és azóta a PS nem tér magához. Telepítsük újra! Ahogy azt Móricka elképzeli. Mivel Windows 7 esetében már beépítve jön a PS 2.0, így nem lehet külön letölteni. Feature-ként sem lehet eltávolítani, majd visszarakni. Ekkor szóltam a kollégának, hogy B terv, kezdjen el telepíteni egy másik munkaállomást. Itt már lejjebb adjuk az igényeket, eszébe se jusson windowsupdate-tel foglalkozni. Én pedig előre menekültem. Rakjunk fel WMF3 CTP2 csomagot, abban van Powershell 3. Aztán majd meglátjuk, mit csinál. Semmit. Fel sem települt. Azt mondta, hogy neki szigorúan angol nyelv kell, ez meg nem az. De meg lehet engesztelni egy angol language pack-kel. Töltsük le! Hát, nem. Nyelvi csomag eleve a Windows Update-ről szedhető le, ultimate és enterprise Windows 7 esetén. Csakhogy mi itt professional verzióval szopunk. Elvileg leszedhető az MSDN-ről a teljes csomag, de mire a 2 GB lejön, addigra a kolléga újrahúzza a gépet. És még ekkor sem garantálja senki, hogy nyelvet tudok váltani, hiszen a professional eleve nem lehet többnyelvű.
    Csapásváltás. Menjünk vissza a legutóbbi rendszermentéshez, töltsük vissza, aztán telepítsünk mindent újra attól a ponttól. Röpke félóra alatt meg is csináltam, restart, újabb próba, újabb váratlan PS elszállás.
    Hát, ezzel nem jutottam sokat előre.
    Közben kolléga felhúzta az új gépet, gyorsan kipreparáltam, maxthreads a biztonság kedvéért kettőre állítva, aztán hajrá. Nem hiszed el: ezen is váratlan Powershell hiba történt. Meg lehetett volna mintázni rólam a bambaság szobrát.

    Vicc.

    – Doktor úr, nagy baj van!
    – Mi a panasza?
    – Ha megnyomom a lábam, fáj! Ha megnyomom a derekam, fáj! Ha megnyomom a tarkóm, fáj! Milyen betegség az ilyen?
    – Valószínűleg eltörött az ujja.

    Azaz ha több kliensen is ugyanazzal a hibával száll el egy folyamat, akkor lehet, hogy a szerver a hibás. Mágikus restart. A biztonság kedvéért a kliensen is. Másolás elindít, összes végtaggal imádkozik. És igen, ez volt a probléma, a Powershell váratlanul jól működik.

    Vegyük észre az eset szépségét. A 32 bites kliensen elindított, 32 bites Exchange modullal feljavított Powershell (aka EMS) menetközben meghívogatja a 32 bites Outlook MAPI motorját, ezen keresztül próbálja meg leszívni a szerverről a levelezési tartalmakat és kirakni pst fájlokba. Aztán elfogy a RAM, ki kell lőni a taszkot, és mi hal meg tőle? A szerver. Finom.

    Mindegy, elméletileg örülhetnénk is… csakhogy itt a háromnapos ünnepre terveztünk egy háromnapos átállást. Ebből elveszett a péntek délután, az export legjobb esetben is csak szombat délre fejeződik be és igencsak csipkedhetjük magunkat, hogy ezt a fél napot behozzuk valahogy.

    Én mindenesetre halk sóhajjal betoltam az Alvin albumot az mp3 lejátszóba.

    Ott szorít, ahol szűkebb

    2012-05-23 / / 0 Comments

    Egy nagyon jó nyomozás leírása Paul-tól. Érdemes végigolvasni, megnézni, hogyan gondolkodott, milyen eszközöket használt és hogyan göngyölítette fel az esetet. Majd hasonlítsuk össze, hogyan oldottam meg anno én egy ránézésre teljesen különböző, de valójában ugyanarra a konfigurációs hibára visszavezethető problémát, pusztán a józan eszem és a Salvador Dali-féle paranoiac-critical módszer segítségével.

    A message tracking log használata – másképpen

    2012-04-18 / / 3 Comments

    Minden Exchange admin nagy barátja a message tracking log, rendszerint ennek segítségével tudjuk átrugdosni a dögöt az utca másik oldalára, azaz így bizonyítjuk, hogy a levél rendben kiment az Exchange organizációból, a továbbiakban pedig legyenek kedvesek a fogadó oldali rendszergazdát zaklatni.

    Paul Cunningham mutatott be egy másik lehetőséget, melyhez szintén a jó öreg MTL-t használjuk: addig gyötörjük, amíg nem összesíti nekünk a napi levélforgalmainkat. Hasznos információ? Igen. Hozzá lehet férni valami egyszerű módon? Tudomásom szerint nem.
    A megoldást nem teszteltem, nem tudok beszámolni gyakorlati tapasztalatokról – de mindenképpen használható ötletnek tűnik.

    Internet Database Availability Group

    2012-04-01 / / 0 Comments

    Amikor elkezdtem olvasni Scott cikkét, egyből elcsöppent a nyálam. Épp mostanában van egy olyan munkám, hogy bár az ügyfélnek nincs túl sok pénze, de szeretne egy olyan HA megoldást két telephelyen, melyek még akkor is működnek, ha a Föld megsemmisül. Üzletpolitikailag meg nem mondhatjuk azt, hogy nem.
    Szóval olvastam, olvastam, és bár a működését elsőre még nem láttam át teljes mélységében, de nagyon tetszett a dolog. Végülis nem akárki írta a cikket, aki Scott Schnollnál többet tud az Exchange HA területről, az már festi magát. És pont most jöttek ki vele, pont amikor égető szükségünk lenne rá. Remek.

    A lelkesedésem egészen addig tartott, amíg észre nem vettem az írás végén a tag-eket.

    ps.
    Persze, folyamatosan nyüzsgött agyam hátterében a kisördög: mi is van azzal a kritikus round-trip latency-vel, az adatbázisok rpcclientaccessserver paramétereivel, na meg a CAS proxyzásokkal? De olyan jó lett volna hinni benne, hogy ezt mind-mind megoldották.