Category: szívás

SCCM szívás

Kb. 2009 óta foglalkozom az SCCM-mel, persze az utóbbi években egyre kevesebbszer, de azért előkerül. Ez az a termék, ami mindig lenyűgöz, hogy úgy érzem, értek már hozzá, aztán arculcsap a valóság…sokszor prózai okokból.

Ügyfélnél telepitettem SCCM-et, szépen működgetett, majd csendben lejárt a trial időszak (ritkán nyomogattam a konzolt). Sebaj, termékkulcs megad, konzol feléled, menjünk karácsonyozni.

Most újra elővettem a konzolt, szép zöld minden (system status, component status), de valahogy mégsem csinál semmit….a logokban nincs error, csupán azt tűnt fel, hogy kb az összes logfile egyszerre megállt december 15. 13:45-kor.

Benéztem a szervizek közé, de felesleges, mert fut minden…és hoppá!..az össze főbb service stopped állapotban van, Manual start opcióval.

Gyorsan visszaállitottam Automaticra őket és a service-ek elinditása után feléledt a SCCM is (a screenshot felúton készült) Hogy ezek mitől mentek manualba, tippem sincs…

Újabb lecke, hogy sosincs unásig tudott dolog, meglepi mindig érhet…

Exchange 2013 Setup + EAC

Nekiálltam az Exchange 2013-ra való átállásnak.

Miután az első 2013-as szerver nem abba a site-ba kerül ahol a schema master van, így a schema master site-jában kezdek neki, parancssorból a dolognak (PrepareSchema, PrepareAD, PrepareDomain)

2012-es member gép (ez sosem lesz Exchnange szerver):

Hisztizik, hogy RSAT AD DS kellene neki. Az nincs, ezen a gépen nem is lesz. Válasszunk mást.

2008 R2 DC, minden FSMO role tulajdonosa:

Hisztizik, hogy kéne neki egy .NET 4.0 – Ez átverés, a release notes-ból kiderül, hogy tulajdonképpen 4.5 kell neki. Nem ugrom be, felrakom a 4.5-öt

Kéne még egy Management Framework 3.0. Felrakom.

Ezek után lefutnak a szükséges dologk.

Csak azt tudnám, melyik idióta gyártott ilyen KÖTELEZŐ parancssori kapcsolót: /IAcceptExchangeServerLicenseTerms

Azt hiszem, ha az open világban valaki elkövetne egy hasonlót, keresztbe nyelné le a közösség.

Aki már egy kicsit utánanézett az Exchange 2013-nak az tudja (aki nem azt majd telepítés után fogja képen vágni), hogy az MMC alapú Exchange Management Console-nak vége, meghalt, eltemették.

Ami helyette van az a web alapú Exchange Administration Center.

Hosszas várakozás (2010 SP3, 2013 CU1) és némi küzdelem (Schema Upgrade másik site-on, millió tonna Windows Server Role, Feature, külön letöltendő telepíőkészlet, hatszáz újraindítás) árán sikerült a saját Exchange 2010-es infrastruktúrámba (homokozó) felraknom az első Exchange 2013-at.

A telepítő gyorsan meg is kérdezte, hogy akarom-e elindítani az Administrative Centert.

Akartam. Beléptem. Magyar.

Hogy az a…

Utálok magyarul szervert adminisztrálni.

Miért?

Nem, nem beszélek jobban angolul mint magyarul. Nem, nem felvágós úri hóbort. Hanem:

Ha valami bajom van, a magyar hibaüzenetekre, problémákra kb. 0 megoldást találok a neten.

Ok. Állítsuk át angolra:

Első ötlet: Átállítom az Internet Explorert angolra. Ez magyar, mert az operációs rendszer nyelve ugyan angol, viszont a területi beállítások magyarok, elsősorban a billentyűzet miatt. (Ez az átállítás sem egy matyóhímzés mióta az IE nyelvi beállításait integrálták a control panellel: Win8/IE10)

Kilépek az EAC-ból, becsukom az IE-t.

Megpróbálom elindítani az EAC-ot újra. Csempét nem gyártottak hozzá a start menűbe. Az IE history-ban sincs (vajon miért?). Google.

Kiderül, hogy a cím megyegyezik a 2010 ECP-vel. (https://server/ecp)

Bepötyögöm, belépek, kapok egy 2010-es OWA login ablakot. Mi vaaan?

Megpróbálom a gép összes lehetséges címével (loclhost, FQDN, IP). Mindre ugyanazt kapom vissza.

Google.

Kiderül, hogy abban az esetben, ha a mailbox még a 2010-es szerveren van akkor belépés után átirányít. Ez kikerülhető, ha így: https://server/ecp?ExchClientVer=15 adjuk meg a címet.

Sikerül. Belépek. Magyar.

Gondolkoz. Nézzük meg a postaláda nyelvét.

Belépek a 2010-es OWA-ba, kiderül, hogy magyar. Ok. Átállítom angolra.

IE becsuk, újra kinyit, EAC-ba belép. Magyar.

Get-MailboxRegionalSettings: látszik, hogy angol.

Vajon ez a beállítás honnan jön? AD.

Hopp. Nem azon a site-on van a 2013 mint a felhasználói postaláda 2010-e.

Get-MailboxRegionalSettings -DomainController <Exchange 2013 site DC>

Itt is angol.

Mi van, ha már lefutott a replikáció.

IE kilép, IE belép, EAC: Angol. – véééégre.

Az eltűnt e-mail esete

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

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

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?

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

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.”

Az állandóan kinyírt rekord esete

Telefon az ügyféltől: nem tudja, mi van, de hülyén viselkedik az Exchange. Például nem lehet postafiókot létrehozni, pedig tegnap még lehetett, ráadásul a hibaüzenet is zavaros.
A hibaüzenet tényleg elég zavaros volt. Megnéztem az eventlogot, tele volt szórva AD hibával. Oké, akkor nem is az Exchange hülye, hanem az AD. Vizsgáljuk meg.

Alapvetően egyszerű felállásról volt szó, két DC, az FSMO szerepkörök szépen elosztva, mindkettő GC. Ezek melllett pöfögött egy Exchange szerver. Tényleg nem bonyolult.

Nézzük az AD-t. Teljesen meggárgyult. A címtárreplikáció szétesett, a DC1 gyakorlatilag eltűnt a rendszerből. DNS. AD integrált. Az SRV rekordok rendben. Akkor miért nem látják? Azért, mert az A rekordja tűnt el. Azaz az SRV rekordok alapján az Exchange is, meg minden más gép is kereste volna (RIDm/PDC/IM/GC is a szerencsétlen), de az A rekord híján nem érték el. Oké, ez egyszerű eset. Az egyik irányban működött a replikáció, így felvettem az A rekordot az egyik gépen, meghúztam a replikációt, átkerült a másik gépre is, pár perc és teljesen helyrejött az AD.
De miért tűnhetett el az A rekord? Két lehetőség van, dinamikus rekord volt, és a scavenge kinyírta, vagy valaki direktben törölte. Megnéztem a beállításokat, de semmi. Azaz nem volt beállítva takarítás, hiába járt le egy bejegyzés, attól az még bent maradt a zónában. Akkor maradt a manuális törlés. Lesz egy kínos beszélgetés a helyi rendszergazdával.

Na, mindegy, nézzük, mit lépett a rendrakásra az Exchange? Új postafiók… és ugyanaz a hiba. Ne te, már. Hát meggyógyítottam a címtárat! Itt van, ni: nslookup dc1… nincs ilyen rekord. Mi van? Visszatekertem a DC-re, megnéztem a zónát: tényleg eltűnt a bejegyzésem. Izé… lehet, hogy mégsem a helyi rendszergazda törölget? De akkor ki? A scavenge ki van kapcsolva mind a két DC-n, meg egyébként is, statikusnak vettem fel a rekordot. Vegyük fel újra. Hátha most nem tűnik el. (Ez a legnagyobb marhaság, reménykedni abban, hogy csak elégszer kell próbálni, aztán egyszer jó lesz. De legalább megy vele az idő, lehet gondolkodni.) Kábé 10 perc után a rekord megint törlődött, méghozzá a DC1 törölte. Egy botor próbálkozás: DC1 netlogon service újraindít, de semmi.

Azt hiszem, valami érdekeset fedeztem fel: fekete lyuk az informatikában.

Gondolkodjunk.
AD integrált DNS zónában egy rekord törlése az valójában meglehetősen bonyolult folyamat. Egyrészt van magának a dinamikus DNS-nek a törlési folyamata (lejárat, érzékenység, scavenge időzítés), másfelől pedig a rekord maga is egy AD objektum, azaz elosztott, multimaster replikált adatbázisban lakozik. Sírkő. (Ha esetleg valaki nem lenne tisztában vele: elosztott, multimaster adatbázisban nem egyszerűen törlünk, mert az nehezen replikálódna át. Ilyenkor az objektum kap egy sírkövet, miszerint már valójában halott, és ez a sírkő feltét replikálódik. A sírkövön szerepel az is, hogy meddig tartózkodik még az objektum az adatbázisban. Utána eltűnik, sírkövestől együtt.)
Jelen esetben a dögeltakarítás (scavenge) nem működött, tehát csak a sírkövezésre kellett koncentrálnom. Mivel AD objektumról van szó, értelemszerűen elő kellett kapni az Adsiedit-et. (Vigyázat, a DNS zónákat nem ajánlja fel helyből, nekünk kell tudnunk, hogy milyen szintű integrációt állítottunk be és annak megfelelően beírni vagy a DomainDNSZones vagy a ForestDNSZones partíciók DN értékét.)
És igen, szépen ott is volt a kinyírt rekord, a dNSTombstoned tulajdonsága pedig True. Tehát akármi is nyírta ki, az az AD szintjén történt. Visszabillentettem az értéket False-ra, és hátradőlve vártam, hogy megjelenjen a DNS konzolban is. (A netes forrásom szerint meg kellett volna jelennie.) Hát, nem. Ez a rekord szégyenlősebb volt annál. Akkor most mi van? Rosszabb már úgysem lehet a helyzet, kitöröltem Adsiedit-ből is, aztán a konzolból újra létrehoztam. Erre visszajött a rekord, a változója üresen állt, ellenben létrejött mellette egy tipikusan sírkövezéskor előforduló, név+guid nevű objektum is. Na, ebből mi lesz? Vártam tíz percet. Az lett, hogy az eredeti rekord eltűnt, a guidnevűből eltűnt a guid, maradt egy bejegyzés, de a tombstone már be volt kattintva. Azaz eltűnt a törölt, az új vette át a helyét, de az is egyből töröltre jelölt lett. A nénikéd.

Akkor workaround. Villámkezű Joe. Felvettem újra az A rekordot, meghúztam a replikációt, AD helyreállt, gyorsan átmozgattam az FSMO-kat a DC2-re, GC a DC1-en lekapcsol, újból meghúztam a replikációt, az Exchange szerveren a DNS kliens beállítást átírtam a DC2-re, magán az Exchange-n is mindenhol beállítottam, hogy a DC2-t használja. AD Topology (és vele még 7 egyéb) service újraindít, IISreset. Gyors ellenőrzés, még megvolt a DC1 rekordja. Oké, teszt. Új postafiók. Ugyanaza a hiba.

Vicces. Mindez péntek délután.

Ekkor vettem a fáradtságot, hogy értelmezzem az Exchange egyébként borzasztóan nem odaillő hibaüzenetét. Vazzeg. Azt írja, hogy az Address List service hülyült be. Az viszont valójában a System Attendant, mely kimaradt a nagy újraindítási hullámból. Restart. Postafiókteszt. Működött. Hurrá. DC1 bejegyzés? Már eltűnt. Most ez is hurrá, mert ez azt jelenti, hogy az Exchange már megy, a DC1-től függetlenül, azaz innentől ráérek az állandóan kinyírt A rekorddal foglalkozni.

A gond csak az, hogy semmi ötletem nem volt. Áttúrtam a netet, remek írásokat találtam arról, hogyan lehet auditálni a DNS-t, ahhoz, hogy elkapjuk a rekordtörlő rendszergazdákat. De itt magát a rendszert kellett volna elkapni, arra meg nem vonatkozik az audit. Végül úgy döntöttem, hogy marad az atombomba. Életre rángatom megint az AD-t, aztán DC1 demote (és bízom benne, hogy lemegy 10 perc alatt), az immár member szervert átnevezem, aztán DC3 promote.
Előtte feltettem a teavizet. Míg a konyhában kortyolgattam a teát, eszembe jutott, hogy adjunk egy esélyt a mágikus újraindításnak. Veszíteni nem veszítek vele semmit. A tea után meg is történt a restart – és csodák csodája, egyből létrejött a DC1 A rekordja! Igaz, dinamikus bejegyzés lett belőle, ezt gyorsan átírtam statikusra… és vártam. Elég sokat. 25 perc után kezdtem csak elhinni, hogy meggyógyult az AD, hiszen továbbra is élt az A rekord. Romeltakarítás.

Case solved. (Azt most ne firtassuk, hogy hétórányi szopást tudtam volna megúszni, ha egyből a restartot választom.)

Hogy mi volt az a rejtélyes krokodil, mely tíz percenként előbújt és leharapta az AD-ból a DC1 A rekordját, azt nem tudom és valószínűleg nem is fogom megtudni. Annyit sikerült kiderítenem, hogy két héttel ezelőtt volt egy áramszünet, mely levágta a Hyper-V hostgépet és nyilván mentek vele a virtuálisak is. (Pl. a DC1.) Utána minden visszaindult és látszólag rendben is volt. Látszólag. A mai napig.

ps.
Mondjuk, nekem még igen büdös volt az el-eltűnő A rekord objektum dSCorePropagationData tulajdonságának az értéke is. A DC2 esetében a tulajdonság értéke 0x0 volt, amikor a DC1 megjavult, akkor az övé is, de amíg rossz volt, addig az aznapi dátum volt benne. Sajnos nem találtam semmi infót, hogy konkrétan ennél az AD objektumnál ez a tulajdonság mire szolgál (úgy egyébként az öröklődés szabályozásához van köze, de ennyi a konkrétum: “This attribute is for internal use only”). Ráadásul még csak nem is módosítható.

Hyper-V 2012 + Storage Sapces 2.

Elkezdtem az első 2012-es vizsgámra tanulni. Eközben bele-bele nézegetek a jelenlegi infrastruktúrám beállításaiba.

Pár napja eszrevettem, hogy a feltelepített Storage Spaces köteteimen nincs bekapcsolva a Deduplication. Akkor úgy voltam vele, hogy majd utánanézek később, mert most még nem sürgős.

Ma a nézelődés kapcsán képenvágott a szomorú valóság:

Miután a Host (ami az ingyenes Hyper-V Server 2012) elkobozta a Storage Poolt a guest-től (ami egy Windows Server 2012 Standard), nem is lesz dedupom (legalábbis nem mindenütt). Miért? Mert a Hyper-V Serverből hiányzik ez a Role Service.

Agysebészet kőbaltával

Nem, most nem Matolcsyról fogok beszélni. Bár vad dolgok ebben az írásban is lesznek.

Habár az előzményekről már esett szó a privát blogomban (itt és itt és itt) – leginkább dühöngés és káromkodás formájában – de itt, ebben az írásban valamelyest újra felelevenítem ezeket, immár higgadtabban és szakmai szemmel.

Tehát a jelenség az volt, hogy 9-én este, amikor le akartam játszani egy videót a médiailag felturbózott Windows 2008 R2 szerveren, elment a hang, illetve beszaggatott a kép, minden lejátszóprogramban. Már amelyik egyáltalán elindult. Bementem a Control Panel / Programs panelbe, kiszórtam az összes Creative programot és drivert, emellett kiszórtam mindent, amit felesleges hulladéknak, telepítési szemétnek tartottam. A videólejátszás rögtön megjavult, a hang nyilván nem, de egyfelől írtam Jánosnak – akitől a hangkártyát kaptam kipróbálásra – hogy mi is ennek a szutyoknak a pontos neve, másfelől megrendeltem egy párezer forintos USB hangkártyát, mert több helyen is írták, hogy a HP ML110 PCI csatija nem annyira szereti a hangkártyákat.
Reggel, még az ágyban, átfutottam az éjszakai leveleket, ott volt benne a hangkártya pontos neve. Gut. Úgy pizsamásan lementem, lekaptam a Creative oldaláról a Microsoft(!) által írt drivert, feltettem, kért egy újraindítást, leokéztam… aztán kék halál.

From Segédlet
From Segédlet

Oké, láttam már ilyet, hibás drivertől nem ijedünk meg. Last good configuration. Megint kék halál. Nofene. Safe mode. Ugyanaz. Ekkor felejtettem a konyhában a kávémat. A safe módban látható volt, hogy a classpnp.sys betöltésével van a baj. Jobb híján rákerestem a neten… és rámdőlt a világ. Mint földrengéskor a tízemelet. Vajákolások, kinlódások, jószándékú, de fogalmatlan topicok, hosszan elnyúlva, aztán egy-két értelmes bejegyzés, melyek azért adtak némi támpontot és ötleteket a továbbhaladáshoz. A továbbhaladást értsd úgy, hogy egyre beljebb a mocsárba. Az első nap végén eljutottam oda, hogy realizáljam, őrült nagy baj van, de még azt se tudom, hogy a Windowsban, a hardverben, vagy a Biosban. János szerint a Creative programozóinál csak az Adobe programozói idiótábbak, szóval ő a maga részéről arra tippelt, hogy a hangkártya driver vágta haza a rendszert. Nekem meg kiesett a fejemből, hogy ez MS driver volt, és hát azért az MS csak nem öli meg a saját rendszerét. Viszont a rossz driver mellett szólt, hogy a Startup Repair is azt üzente, hogy BadDriver. Attól meg végleg kikattantam, hogy egy driver hogyan tud megölni egy szerver operációs rendszert.
Az egész napot pizsamában nyomtam végig, kaja nélkül. Hajnalban hullafáradtan dőltem bele az ágyba.
Reggel folytköv. Pizsama, a dohányzóasztal, mint szék. Éjjel még támadt néhány ötletem, azokat ki akartam próbálni, illetve előkészíteni az újratelepítést. Az ötletek közül egy sem működött, a telepítéshez összeraktam mindent (ez sem volt egyszerű, de most ne részletezzük)… aztán fellázadtam. Hagytam a francba az egészet, reggeliztem, zuhanyoztam, melegítőt cseréltem, főztem egy kávét… szóval megpróbáltam kultúrembert faragni a két napja széjjelfrusztrált gnómból.

Ez a szünet mentette meg a gépemet.

Közben ugyanis a blogbejegyzésben megjelent egy komment, melyben újabb ötletek voltak, illetve nem sokkal később egy másik, amelyikben volt egy link. Egy olyan írásra mutatott, melyet olvasván tátva maradt a szám. Bakker, ez pont az én történetem! Fura volt látni, mert az a több száz bejegyzés, melyet az utóbbi másfél napban olvastam, mind úgy nézett ki, mintha az én esetem lett volna, de aztán mégsem. Ez viszont pontosan az volt.

Amikor telepítettem a segédprogramokat, valamelyik (VLC? K-Lite? DaemonTools? Egyéb?) felajánlotta, hogy felrak egy McAfee Scan nevű cuccot. Habár az MSE már fent volt, de tapasztalataim szerint az eléggé harmatos, ezt a gépet pedig négyen fogjuk gyötörni, köztük két húszéves padaván, szóval úgy gondoltam, inkább több védelem legyen, mint kevesebb. Aztán amikor 9-én este szétesett a gép, nemcsak a hangkártya drivert és segédprogramokat szedtem le, hanem sok egyéb mellett ezt a McAfee cuccot is. Ezzel helyeztem el a pokolgépet a rendszerben. Aktiválni pedig a restarttal lehetett, melyre másnap reggel, a driver telepítésekor került sor. Jó, mi? Azt hinnéd, hogy a driver ölte meg a gépet. A fene sem gondolná, hogy a McAfee Uninstall a háttérben már szétkeffentette a lemezen az oprendszert és az egész gyakorlatilag a memóriából megy.

A KB cikk a McAfee oldalára mutatott, a kettőből szépen össze lehetett rakni a történetet. Létezik egy könyvtár, a %systemroot%\system32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\, ahol úgynevezett .cat katalógusfájlokban található minden szolgáltatásról, driverről és hotfixről minden azonosító adat. (Pontosabban a katalógusfájlok az egyes csomagok fájljairól készített hash-ek gyűjteménye, természetesen szintén aláírva.) Ezekből az adatokból a rendszer kiszed bizonyos információkat és eltárolja azokat a %systemroot%\system32\CodeIntegrity könyvtárban egy bootcat.cache nevű fájlban. Ezt a fájlt próbálja felolvasni a classpnp.sys driver. Ha nem sikerül neki, akkor megpróbálja legenerálni azt a catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} könyvtár tartalmából. És itt jön a balhé: ha az innen felszedett információk nem egyeznek meg a gép konfigurációjával (értsd driver, service, hotfix szinten), akkor a classpnp.sys eldobja az agyát: kék halál.

Ezek után lássuk, mit csinált McAfee.

Amikor azt mondtam, hogy uninstall, akkor fogta és azt a bizonyos guidnevű könyvtárat átnevezte(!?) temp????.tmp névre, létrehozott helyette egy üres újat… majd a fene tudja, mit tervezett vele, mert ebben a pillanatban tökönszúrta magát és elhalálozott. A gép pedig a következő újraindításkor szembesült vele, hogy a catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} könyvtár üres. Persze, hogy a classpnp.sys eldobta az agyát. Arra kérlek, hogy ha van előtted akár egy Windows 7, vagy akár egy Windows 2008 szerver, akkor nézzél bele ebbe a könyvtárba. Több ezer .cat fájl. Na, az ott látott szolgáltatások és driverek, illetve pecselt komponensek mind kipurcantak, mert nem volt meg hozzájuk a bootoláskor szükséges információ.
Csoda-e ezek után, hogy McAfee-t le akarják lőni Belizében?
Mondjuk, az is egyfajta understatement, hogy a Windows csak annyit mondott, hogy BadDriver. Bakker, az összes driver és az összes szolgáltatás Bad lett.

A workaround nyilván az, hogy Emergency Repair módban visszamásoljuk a temp????.tmp könyvtárból a .cat fájlokat a guidnevű könyvtárba, a bootcat.cache fájlt pedig töröljük.

Csakhogy. Nálam valahogyan a McAfee Uninstall valamelyik gonoszabb változata garázdálkodott, ez nem hozott létre temp könyvtárat, viszont a guidnevű tartalmát törölte. Ott álltam egy tök pucér katalóguskönyvtárral, úgy, hogy nem volt meg az előző állapot. Nézz bele légyszíves megint abba a könyvtárba! Hogy érzékeld a helyzetet: itt mindennek pontosan klappolnia kell: a drivereknek, a szolgáltatásoknak, méghozzá verziószámra azonosan, és persze jelen kellett lennie az összes patch katalógusfájljának, amelyik a gépen volt. Az a nyomorult classpnp.sys csak akkor indult el, ha minden egyezett.
Jópofa vadászat kezdődött. Először átmásoltam a Windows RE változatból – mely gyk. a Repair Tools opcióval indul el – a .cat fájlokat. Nem indult el. Kaptam egy bootcat.cache fájlt, bemásoltam. Kiröhögött. Újabb ötlet: ott van a szerveren egy csomó virtuális 2008 R2 szerver, szedjük ki azokból a .cat fájlokat. Windows RE alól a diskpart segédprogrammal fel lehet mountolni a vhd fájlokat, kimásoltam a {F750E6C3-38EE-11D1-85E5-00C04FC295EE} könyvtár tartalmát. Nagy levegő. Megint nem indult el. Pedig úgy emlékeztem, a host és a guest gépek azonos pecseltségi szinten vannak. Újabb ötlet: a %systemroot%\servicing\packages könyvtárban ott van az összes hotfix katalógusfájlja, küldjük még rá azt is. Le van szarva, ha több lesz. És igen, ezzel nyertünk: a három helyről összemásolt katalógusfájlokban már megvolt minden, pontosan olyan verziókkal, ahogy az a fránya kényes ízlésű classpnp.sys elvárta. Habár malmozott pár percig, de aztán kék képernyő helyett a Windows logon képernyő jött be.

Ha meglett volna a forgószékem, akkor elégedetten dőltem volna hátra.

Nyilván jött még egy nagytakarítás, a lakás gyk. tele volt romokkal, aztán rendezni kellett a kártyákat, drivereket (a találgatások során szanaszét állítgattam a registry-t), de ez már egyszerű hamupipőke munka volt, szerencsére mindent logoltam egy noteszbe.

Végezetül a Köszönet rovat. Ez az írás nem jöhetett volna létre a Microsoft nélkül. Ez kivételesen nem irónia akart lenni. Onnantól kezdve, hogy délben üdén és tisztán kijöttem a fürdőszobából és megtaláltam azt a bizonyos linket, István vezette a kezemet. Tőle kaptam az ötleteket, az én dolgom csak annyi volt, hogy utánaolvassak, megértsem, mit csinálok, majd végre is hajtsam az újabb és újabb feladatokat. A magam részéről teljesen le vagyok nyűgözve, mert egyrészt ez nem volt hivatalos bejelentés, másfelől, mint kiderült, nem is az MS sara volt az oprendszer halála – mégis teljes vehemenciával dolgoztak a hiba megszüntetésén.
És köszönettel tartozom Jánosnak is, aki a hardver irányában tett kisérletezéseimben segített.
Köszönet mindkettőjüknek.

Hyper-V 2012 + Storage Sapces

Amikor megjelent a Windwos Server 2012 megtetszett a Storage Spaces nevű szerkezet. Azt gondoltam, hogy az új Hyper-V tetején kialakítok egy virtualizált háttértároló infrastruktúrát.

Építettem egy szervert. Az alaplapi 6 csatornás intel RST RAID vezérlőre felraktam 6db merevlemezt. Ebből az első kettőből RAID 1-es tömb készült, a maradék négyet pedig hagytam magában. A RAID tömbre felraktam a Hyper-V Server 2012-t, tettem rá egy virtuális gépet, ami a raiden lévő vhd-ból bootol, és odaadtam neki a maradék négy lemezt pass-through módban. A virtuális gépre felraktam egy Windows Server 2012-t. A virtuális gépen belül pedig a pass-through lemezekből összeraktam egy Storage Spaces Pool-t.

Minden szépen működött. Adat is került az újonnan kialakított virtuális “NAS”-ra.

Elkövetkezett a kies november 19.-ei hétfői nap, amikor is látom a Nagios-ban, hogy jónéhány gépet frissíteni kéne, köztük a virtuális nas alatti Hyper-V hosztot is.

Végigmentem a gépeken, utoljára maradt a Hyper-V. Felmentek a frissítések, újraindult. Elindítottam a különböző virtuális gépeket, minden elindult

kivéve…

a remek virtuális nas-om.

1. pofon:

Közölte a drága, hogy nem tudja felcsatolni a lemezeit. Remek. 🙁

Megnéztem a diskpartban, ahol a boot lemezen kívül nem láttam semmit. Itt kellene lennie négy darab offline disknek.

Az első gyanúsítottam az integrált Intel RST vezérlő meghajtója/menedzsmentje volt. Ilyen ugyanis nincs. Mind a mai napig az Intel nem adott ki hozzá 2012-n működő darabot. Azt feltételeztem, hogy a non-raid diskeket valamelyik hotfix miatt nem látja az operációs rendszer.

Körül akartam nézni a device managerben, hogy lássam mi a helyzet.

2. pofon:

A Hyper-V Szerverből adódóan ez egy core edition. Mint ilyen, nincs device manager rajta.

– Távolról még read-only módban sem lehet device managert indítani, mert ezt, a korábban meglévő lehetőséget a Microsoft eltávolította
Itt írják, hogy tegyük fel a Server-Gui-Mgmt-Infra windows feature-t, de ezt nem tudom megtenni, hiszen ez nem egy teljes Windwos core, hanem a Hyper-V szerver, amin nincs ilyen
– PowerShell alapú device management nem része az operációs rendszernek. Van hozzá letölthető, de ezt valahogy nem akartam feltenni (így utólag kár volt)

Miután nincs device manager, tehát jön a vakrepülés. Nézzük meg, hogy mi történik, ha a lemezeket áttesszük egy másik vezérlőre. Volt a fiókban egy Intel RS2BL040 RAID vezérlő. Gondoltam erre átrakom a lemezeket és meglátom mi lesz.

3. pofon:

Szétszedtem a gépet. Amikor kihúztam az alaplapról a SATA kábeleket, az egyik beakadt és az alaplapi SATA csatlakozó műanyag része jött a kábellel együtt. 🙁 Remek. Alaplapcsere.

Még a kinyírt alaplappal és a fenti vezérlővel megpróbálkoztam.

4. pofon:

A jelzett Intel vezérlő az okosabb fajta. Mint ilyen nem adja tovább az operációs rendszernek a konfigurálatlan lemezeket (JBOD mód). A butábbik testvére az RS2WC040 persze igen. Azt nem mertem megkockáztatni, hogy felkonfiguráljam őket egyesével RAID 0-ának, mert ki tudja mit ír vissza és mi lesz az adatokkal.

Szereztem olcsón (5eFt/db) HP SC40Ge vezérlőket, amik tudják a JBOD módot. Beraktam a gépbe. Semmi sem változott. a diskpart nem lát semmit.

Tegnap reggel nekiálltam, hogy megejtsem az esedékes alaplapcserét. Miután még mindig az Intel/MS hotfix volt a gyanúsított, félreraktam a rendszer eredeti boot lemezeit, és két új lemezre raktam fel a Hyper-V-t minden hotfix nélkül. És láss csodát, még mindig nem látta a hiányzó lemezeim.

Ekkor megfogalmazódott bennem a gyanú, hogy lehet, nem is ott keresgélek, ahol kellene. Mi van, ha a Storage Spaces által felkonfigurált pool-t a Hyper-V szerver maga önhatalmúlag bevételezi.

Felraktam egy teljes Window Server 2012-t, hogy lássak is valamit, vége legyen végre ennek a vakrepülésnek.

Nyertem. 🙂 A device managerben látszanak a lemezek és a Storage Spaces konfig lát egy read-only pool-t (azt amit kerestem). Ezek után találtam is erről egy thread-et a Microsoft support fórumon.

Visszaraktam az eredeti boot lemezeket, rendbeszedtem a konfigurációt. Innen kezdve a Storage Pool-t a Hyper-V szerver kezeli és a Storage Pool virtuális kötetei lettek átadva a NAS-nak pass-through lemezként.

A véleményem, hogy a tipikus “not a bug it’s a feature” esettel állunk szemben. Ezt valaki csúnyán benézte az MS-nél: Ami pass-through az pass-through, teljesen mindegy, hogy a virtuális gép mit rak rá.

Együtt működés

Ügyfél úgy érezte, itt az ideje, hogy felrobbantsa felújítsa az informatikai rendszerét. Előbb-utóbb sor került a levelezésre is. A következő peremfeltételek szorongatták a projektet:

  • A telepített rendszernek a meglévőnél robusztusabbnak kell lennie. (Ezt nem volt nehéz megígérnünk.)
  • Licenszelési szempontból támadhatatlannak kellett lennie. Ez egész konkrétan azt jelentette, hogy mivel a felhasználók számához képest egynyolcadnyi Windows és Exchange CAL állt rendelkezésünkre, a többieknek valamilyen alternatív, de valamelyest igényes levelezést kellett biztosítanunk. (A maradék 7/8 egyébként laptopos-bolyongós külsős ember.)
  • Természetesen mindenki ragaszkodott hozzá, hogy mindenhonnan elérje a levelezését, minimum webes felületen és mobiltelefonon. Nyilván az utóbbit push metódussal.
  • A cégnek egy darab publikus IP címe van. A határon egy Cisco eszköz kezeli le a forgalmat.
  • A költségkeret adott volt. Emiatt fel kellett használnunk a korábbi licenszeket, így is éppenhogy maradt csak valami zsé új hardverre és licenszekre.
  • A meglévő rendszerhez képest Augeias istállója chipgyár tisztasággal bírt. Természetesen úgy kellett elvégezni az átalakítást, hogy minél kevesebb fennakadás legyen.
  • Függetlenül attól, hogyan oldjuk meg a levelezést, az összes alkalmazottnak ugyanazt a névteret – @cegnev.hu – kellett használnia. Egymás között is.
  • A meglévő levelezés nem veszhetett el, át kellett kerülnie az új levelezőszerverekre. Szerencsére public foldert nem használtak.

Hosszas tanakodás után egy Exchange-Zimbra kooperáció mellett döntöttünk. Zimbra esetében nyilván az Open Source Edition jöhetett csak szóba. A webes elérés evidens volt, a mobilokhoz pedig jó lesz a Z-push.
A router mögé egy ISA 2006 SP1 került. Sokat nem válogathattunk, ehhez volt licensz. Első elképzeléseink szerint majd ez osztja szét jól a https forgalmat.
Ja.

A TCP/IP-ből következően egy socketre (IP:port) csak egy listenert tudunk rakni. A HTTPS működéséből következően egy website-hoz csak egy tanúsítványt tudok hozzárendelni. Eddig oké.
Csakhogy az ISA belekeverte a mókába az autentikációt is, méghozzá listener szinten. Azaz ha olyat akarsz csinálni, hogy egy IP címen fogadsz a 443-as porton különböző belső szervereknek szánt forgalmat (a tanúsítvány SAN vagy wildcard), és ezek a belső szerverek háklisan autentikálnak… akkor nagy bajban vagy. Mert a listener autentikál. Pontosabban, meg lehet neki mondani, hogy ne autentikáljon, de ekkor senkinek sem autentikál és ráadásul még ez sem igaz… de erről majd később.

Akkor nézzük, miből élünk. Egy külső IP címünk van, azaz a socketből már csak a porttal tudunk játszani. Tudnánk. Csakhogy az Android alap Activesync kliense – legalábbis a Samsung telcsiken – nem enged portszámot beírni. Mivel a külsősök között informatikus még csak elvétve sincs, szóba sem jöhet, hogy letöltetünk velük valami appot. Ha létezik egyáltalán jó ingyenes. Tehát a Z-push és az Exchange ActiveSync (EAS) https forgalomnak ugyanazon a porton kell bejönnie, azaz ugyanaz a listener kell, hogy lekezelje. Ugyanazzal az autentikációval. Fincsi. (Nagyjából igaz ez a webes elérésekre is. A felhasználó kiszalad a világból, ha ilyen címet kell megjegyeznie, hogy https://exchange.cegnev.hu:50443/owa.)

Oké, nézzük, be tudjuk-e gyötörni egy autentikáció alá ezt a négy forgalmat. Az OWA és az EAS berakható, jelenleg is így működik. A listener FBA-t használ, azaz formon keresztül bekéri a credential adatokat, valamelyik DC-ről autentikál, az autentikáció delegáció basic, azaz http/basic autentikációval dobja át a credentialt az Exchange szervernek. Mivel az egész kommunikáció HTTPS alatt megy, így a basic nem probléma. Viszont, mivel az autentikációt – beleértve az autentikáló szervert is! – a listenerben állítjuk, a Zimbra esetében gond lesz. Lehetne úgy persze, hogy a Zimbra felhasználókat felvesszük az AD-be, majd onnan autentikál a levelezőszerver – de ez már Windows CAL. Az meg nincs.

From Segédlet

Mik a szóbajöhető opciók? Domain, egyéb AD, Radius. Az első kapásból kiesik. A másodiknál fel kellene húzni egy Samba szervert a Zimbrán, a harmadiknál pedig kellene egy-egy Radius szerver mind a Windows tartományba, mind a Zimbra mellé. (Ez egy külön szépség a listener struktúrában. Egy listener csak egyféle autentikációt ismer. Habár azt meg tudom csinálni, hogy a bejelentkezéskor megadott domainnév alapján más és más Radius szerver autentikáljon, de azt nem, hogy a bejelentkezéskor megadott domainnév alapján az egyik esetben Windows LDAP tartományból, a másik esetben külső Radiusból autentikáljon.)
Na jó. Kérdés a linuxos kollégához: meg-e lehet-e oldani? E? Fejcsóválás. Ha sima postfix lenne, akkor menne, de a Zimbra ennél kompaktabb cucc. Ha a megkerülésével piszkálnak bele az alatta lévő dolgokba, azok nem maradnának ott állandóan.

Jó. Ez az irány nem működik. Az Exchange autentikációs beállításai nem jók a Zimbrának.

From Segédlet

Akkor mi a jó? Nem húzom az időt, egyfajta beállítással tudtam csak átgyömöszölni a Zimbra forgalmát: a listeneren kikapcsoltam az autentikációt, a szabályban pedig az autentikáció delegálásánál azt adtam meg, hogy a kliensek a célszerveren közvetlenül autentikálnak. Ekkor feljött a Zimbra FBA autentikációs képernyője. Ez ugyan nem öröm, hiszen általánosságban azért csak jobb az, ha már a tűzfal lerendezi az autentikációt, de ez van. Igenám, de jó lesz-e ez az Exchange-nek? Elméletileg jó lehet. A nagykönyv szerint, ahogy korábban is írtam, az a helyes beállítás, ha a listeneren form-based autentikációt állítunk be, a szabályban a delegálásnál basic autentikációt, az Exchange szerveren pedig szintén basic-et. (A tanúsítványokról most nem értekeznék külön. Az se volt egyszerű kör, de végül mind a két rendszert befaragtuk ugyanazon CA alá.) Ezt a konfigot rúgtam fel, úgy, hogy beraktam az autentikáció nélküli listenert, a szabályban átírtam a delegálást közvetlenre, az Exchange szerveren meg engedélyeztem az FBA-t. Bentről szépen működött is – kintről viszont azt kaptam vissza, hogy a szerver elzárkózott a kapcsolat elől. Jött némi vajákolás, engedélyeztem az FBA-t közvetlenül az Exchange IIS alatt is az OWA könyvtáron, de nulla eredménnyel. Megnéztem az ISA logot – és jó magasra felugrott a szemöldököm. Beérkezik kintről a https, az ISA terminálja… majd az Exchange felé már http-n megy tovább, mely próbálkozást az Exchange – jogosan – undorral dob el. De miért? A szabályban a bridging fül alatt nincs engedélyezve a http. Akkor ezt most hogyan? Ellenteszt. Visszaállítottam mindent, rögtön https-sel próbálkozott az ISA, az Exchange pedig elfogadta. Furdalt a kiváncsiság, megnéztem az itthoni tesztrendszeremben ugyanezt TMG-vel – és ugyanez lett az eredmény is. Fura. Ha azt mondom a TMG-nek, hogy ne erőlködjön az autentikációval egy linux szerver felé, akkor nem is variál… ha viszont ugyanezt mondom neki egy Exchange szerverrel kapcsolatban, akkor átvált http-re, még akkor is, ha ez nincs neki engedélyezve.

Nos, ennyi volt a történet. Szomorú sóhajjal arrébb rúgtam az ISA szervert és betettünk elé egy Apache proxyt. Ez ugyanis nem tűzfal, de nem is fenyegetés elleni gateway, azaz nem foglalkozik az autentikációval. Terminálja a HTTPS kapcsolódást, a host header alapján tudja, milyen irányba kell továbbdobnia a kérést, immár egy új HTTPS kapcsolattal. Azaz az OWA és EAS mehet az ISA egyik hálókártyájára, a klasszikus listenerrel, a Zimbra forgalma meg mehetne az ISA másik lábára a ‘ne nyúlj hozzá’ listenerrel. (Azért használtam feltételes módot, mert a linuxos vonalnak nem ez lett a vége, de így is lehetett volna.)

Megjegyzem, ha az ISA tudná az SNI-t (Server Name Indication), akkor még sokkal egyszerűbb lenne a dolog, akkor már a HTTPS terminálása előtt tudná a megcélzott host nevét, és ennek alapján ő maga tudna forgalmat szeparálni. De nem tudja. (Talán az UAG. De azt nem ismerem.)

Tulajdonképpen ezzel a webes eléréseket lerendeztük. Az SMTP, na az szintén jó móka volt, de most hagyjuk. Ugyanis hátravolt még egy publikáció: egy belső RDS szerver alkalmazásait is ki kellett publikálnunk a külsősök felé. RdWeb, RDGW. Csakhogy: 1 IP cím. Az RDGW pedig ugyanazon a 443-as porton szeretne nyomulni, amelyiken már így is nagy a zsúfoltság. Az Exchange listenerje nem volt jó neki, innentől úgy gondoltam, ugyanazzal a trükkel bánok el vele, mint a Zimbrával: az Apache átdobja egy újabb virtuális kártyára, azon pedig olyan listenert csinálok neki, amilyet szeretne.
Jó. De milyet szeretne?

  • Egyik módszer
    Ez egy tipikus MS howto a Technet Library-ből. Semmi extra, a jó öreg “pofabe” módszer: a listener nem autentikál, a delegáció pedig közvetlen.
  • Másik módszer
    Ez egy cikk az isaserver.org-ról, Marc Grote írta. Határozottan unortodox módszert követett, a listener autentikáció integrated (azaz ntlm), a delegáció kerberos constrained.
  • Harmadik módszer
    Egy másik cikk a Technet magazinból, viszont ezt két MS nagyágyú jegyzi: Shinder és Diogenes. A trükk az, hogy mivel itt ugyanazt az /RPC/* website-ot publikáljuk, mint az Outlook Anywhere esetében, hát csináljunk meg mindent az Exchange varázslóval. A listener autentikáció basic, a delegálás közvetlen.

Erre szokták azt mondani, hogy a bőség zavara. Kipróbáltam mind a hármat. Egyik sem működött.
Ahhoz már hozzászoktam, hogy nekem valahogy mindig jobban emelkedik a pálya, mint másoknak, de azért a függőleges fal még mindig meg tud lepni.
Az RDS szerver oldalán minden rendben volt, rdweb, rdgw, tanúsítványok, házirendek. (Pedig itt sem volt egyszerű a pálya, ha próbáltál már eligazodni a kilométer hosszú nevek között egy _magyar_ nyelvű szerveren, akkor tudod, miről beszélek.) Odáig mindegyik módszerrel eljutottam, hogy az rdweb oldalon megjelentek az rdp ikonok. (A harmadik módszernél pluszban felvettem az /rdweb/* útvonalat.) Utána viszont állandóan csak autentikációs ablakokat kaptam, akármit is csináltam, akármilyen credential-t adtam meg.
A megoldás természetesen pofonegyszerű, de az autentikációra utaló hiba megzavart, ezért állandóan csak azzal gyötörtem magamat. Beletelt egy napba, mire a fejemre csaptam és felhúztam a DMZ-be egy Windows7 gépet és közvetlenül arról próbálkoztam. Természetesen mind a három módszer működött, szó sem volt autentikációs hibákról.
Egész egyszerűen az Apache nem tudja proxyzni az RPC over HTTPS-t, azaz nem fog menni az RDP over HTTPS sem. Amíg csak az RDweb-ig megyek, addig oké, az tiszta HTTPS… de utána váltunk, az indián meg elhasal. Kész szerencse, hogy az Outlook Anywhere nem volt benne a projekt szkópjában, mert az sem működne.

A többi már nem túl érdekes. Az ügyfél kapott egy ultimátumot, miszerint vagy szerez egy másik IP címet, vagy kilógatjuk az RDS szervert valami lehetetlen porton, persze ebben az esetben övé a felelősség a biztonsági kockázatért. (Sőt, ha már lúd, legyen kövér, ebben az esetben kérünk még egy IP címet és kiváltjuk az Apache proxyt is. Mert mégiscsak egy spof, meg plusz kockázat.)
De ez már nem technológia probléma.

Export-mailbox, szomorodj meg

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ő

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

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

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.

IE9 + Windows Update

Telepítettem egy új Windows Server 2008 R2-t (a régi megdeglett, fátylat rá, hogy miért). Felraktam az összes szükséges update-et, de folyton közni, hogy márpedig ő IE9-et akar telepíteni (pedig már fenn van).

Elkövettem egy Windows Update reset-et (SoftwareDistribution, catroot2 mappa töröl). A Windows Update friss meleg ropogósnak tűnik. Mint amit még sosem futtattak. Lefuttatom. Még mindíg közli, hogy kéne neki egy IE9.

Gugli a mi barátunk:

http://social.technet.microsoft.com/Forums/en-US/winservergen/thread/2c252dbe-c833-424d-9b75-4948bb8fb816

Jó hosszú. Összefoglalva:

1. Szedd le az IE9-et (a Programs and Features alatt, ha megjeleníted az update-eket akkor látod és le is tudod szedni)

2. Rebbot

3. Töltsd le a standalone telepítőt innen: http://windows.microsoft.com/en-US/internet-explorer/downloads/ie-9/worldwide-languages

4. Telepítsd fel /update-no kapcsolóval

5. A Windows Update-ből rakd fel a felkínált cumulative fix-et.

Pecs kedd

Csütörtökről péntekre virradó éjjel van, én pedig a megérdemelt pihenésemet töltöm a padláson. A ‘megérdemelt’ jelen esetben nem üres szóvirág – tényleg megdolgoztam érte.

Szerdán ügyfélnél voltam. A tervezett munka aznapra két hyper-v host beüzemelése volt, négy-négy virtuális hálózattal, mindegyiken két virtuális gép, ezekből egy-egy tartományvezérlő egy új AD-ban. Semmi izgalmas, mondhatni rutinmunka.
Lett volna. Ha kedden nem küldött volna ki az MS 9-12 hotfixet. Mely hotfixek nem telepítés közben találják el a rendszeremet. De igazából még ez sem lett volna baj, windows update jelez, telepítés megtörténik, gépek újraindulnak és mindenki megy a dolgára. Csakhogy… homokszem került a fogaskerekek közé. Az egyik host gépen lement a telepítés, csak utána valahogyan elfelejtett szólni, hogy újra kellene indítani a gépet a telepítés befejezéséhez. Én meg nem vettem észre, mert menetközben – igen, a szokásos időhiány – már telepítettem a virtuális gépeket is, és a sok gép, sok windowsupdate közben nem jelzett be a vészcsengőm, miszerint elmaradt egy újraindítás. És az is hiba volt, hogy először nem faragtam be az összes virtuális hálózatot, csak azt, amelyiken keresztül a virtuális gépek elérték a belső hálózatot, meg a netet. Úgy voltam vele, hogy telepítés közben mindig van egy csomó holtidő, majd aközben jól elkonfigurálgatok.
És ekkor lépett be Alice csodaországba. A virtuális hálózatok megadásánál változatosabbnál változatosabb hibaüzeneteket kaptam. Hogy nem tudja létrehozni, mert még az előzőn dolgozik. Abszolút nem zavarta, hogy nem volt előző. De persze a hibaüzenet után mégis létrehozta. Ránézésre jól, de használni mégsem lehetett. Ráadásul volt, amelyiket létrehozta, volt, amelyiket nem. Én meg bőszen undóztam, töröltem… végül valami óriási káosz alakult ki a virtuális hálózatokkal. Már most szólok, ha azt mondja, hogy egy hálókártyára nem tud virtuális switchet rárakni, mert már van rajta, ne kezdjél káromkodni, hogy de nincs is – szinte biztos, hogy a nagy kavarásban bekattintva maradt a kártyán az MS virtuális switch szolgáltatás.
Nem akarom a végtelenségig szaporítani a szót, végül belavíroztam magam egy olyan helyzetbe, hogy a hyper-v szerint egy, azaz 1 virtuális hálózat sem volt, a network panelen belül meg látszott nyolc hálókártya: négy virtuális switch és négy virtuális kártya. Miközben a társgépen – mely az utolsó csavarig megegyezett ezzel – minden simán ment, ha nem is elsőre, de harmadikra. Fejvakargatás. Ilyenkor tiszta haszon, hogy kopaszodom, mert van hol vakarni. A nyolc kártyából egy sem hagyta magát törölni, a konzol, ahonnan törölhettem volna, meg egyiket sem látta. Jobb híján maradt a visszaút a kályhához: hyper-v eltávolítása, majd újra felrakása. Árnyalta a helyzetet a már létrehozott két virtuális gép. VHD félrementve, hyper-v le, gép újraindul – és csak itt, ekkor ugrott ki, hogy be volt ragadva 11 patch. Köztük egy csomó szutyok dotnetes.
Az újraindítás után már ment minden simán. A virtuális gépek könyvtárait inkább töröltem, aztán hyper-v vissza. Mielőtt bármit is csináltam volna, befaragtam a virtuális switcheket. Elsőre. (Ez maradt meg tanulságnak: addig nincs virtuális gép, amíg pöpecül nincs kész a virtuális hálózat.) A hálózat után jöttek a gépek, a vhd-t felismerték, evoé. Pusztán csak fél nap helyett egy egészet csesztem el a feladatra, ami nem lett volna baj, ha időmilliomos vagyok – csak most éppen nem.

Csütörtök reggel. Egy bonyolult tesztrendszert kell összehoznom, jövő hét közepén már vagy húsz demó fog futni rajta. Nyolc gép, DC-k, Exchange szerverek, internetszimuláció, mindenféle kliensek – nem egyszerű környezet. Csütörtök reggel kezdenék… és megint egyre hülyébb jelenségekbe futottam bele. Nem húzom az időt: néhány gépen elfelejtettem kikapcsolni a windows update-et, ezek magukra rántották a patch-eket. Nagyjából a tesztrendszer 70%-ánál jártam, eldönthettem, mi legyen: vagy rárakom mindegyik gépre a hotfixeket, bevállalva azt, hogy innentől a tesztrendszer nem lesz kompatibilis magával, vagy visszamegyek a legutóbbi snapshot-hoz (jó messze az időben) és újra végigcsinálom az azóta elkövetett lépéseket. A hotfixek mellett döntöttem. Nem nyert. Két gépre az istennek sem ment fel, csak jöttek azok a legendásan értelmezhetetlen windows update hibaüzenetek. Oké, hagytam a fenébe. Csak éppen eltelt a délelőtt. Ebéd után végigcsináltam az újabb feladatokat, majd visszaálltam – a patch-ek utáni snapshotra. Azaz visszaálltam volna, mert a környezet ezer darabra szakadt. A kliensek látták az Exchange szervereket, a szervereken lévő konzolok meg nem. A névfeloldás úgy ahogy volt, meghalt. Szenvedtem még vele pár órát, majd B terv – vissza ahhoz a pár nappal ezelőtti snapshothoz, amikor még minden jó volt. Itt gyorsan letiltottam minden gépen a windows update-et és eljátszottam az utóbbi napok laborgyakorlatait. Így jutottam el péntek hajnalban oda, ahol csütörtök reggel kellett volna lennem. Amivel nem lett volna semmi baj, ha nem lennék borzalmasan beszorulva a határidők közé és nem kísérte volna ezt a tevékenységemet eddig is felfoghatatlan mértékű balszerencse.

A legjobban jellemzi a helyzetet, amikor csütörtökön napközben éppen az égre néztem és arra gondoltam, vajon mi jöhet még – erre a szélvihar miatt elment az internetkapcsolatom. Elsőre meglepődtem, de aztán elismerően bólogattam: igen, ez egy pontos találat volt. Sok mindenre számítottam, ezek mind be is következtek – de a szélvihar… az igen. Abban van fantázia.

Hotfix

Néhány hete, hogy tanuljak összeraktam egy Exchange 2010 DAG-ot több telephely között kábelnet vonalakon VPN-eken keresztül. Ez ugye hálózatilag nem a stabilitás magasiskolája.

Egyszer lett egy rövid kiesésem (egy-két perc). Erre fogta magát a DAG és szétesett. Nem ált helyre magátol, gyakorlatilag a Windows Cluster eszközeivel kellett szétszednem mert semmire sem reagált. Végülis újra össszeraktam és napirendre tértem a dolog felett.

Tegnapelőtt ráakadtam erre a cikkre. Végiggondolva az előző eset kísértetiesen hasonlított a cikkben leírtakra. Nosza rajta, szerezzük be a hotfixet, elvégre a fenti teszt DAG-om még létezik (azóta szerencsére nem volt vele újabb gond) valamint vár rám vagy három újabb DAG, csak azok már élesben.

Emlékeztem, hogy a Microsoftnak van egy webes formja ahol lehet hotfixet kérni. Meg is találtam itt.

Elküldtem az igénylést, erre ez a válasz jött tegnap:

Hello,

Thank you for contacting Microsoft Customer Service.

From the information you have provided in your message, I understand that you are located in Hungary. The Customer Service team you have reached is for North America. There are significant differences between North American versions of Microsoft products and those localized for your country.

You will be best assisted by the Microsoft subsidiary that specializes in your version of Microsoft products. You can reach them at +36 1 437 2800 or by visiting: http://www.microsoft.com/worldwide/phone/contact.aspx?country=Hungary

I hope the above information is useful. In case you require further assistance with regards to this issue, please feel free to contact us.

Thank you,

John

Microsoft Customer Service Representative

Na gratulálok. Hotfix nincs, ráadásul bődületes baromság, hogy különbség lenne a verziók között, ugyanis én a US English verzióhoz kértem fixet és nem a magyarhoz.

Azt találtam ki, hogy csinálok egy új e-mailt és bejelentkezem amerikaiként a formra. Meg is tettem. Amikor újra rákerestem a form címére (tegnap nem tettem el), megakadt a szemem az egyik találaton.

Egy próbát megér alapon össze is raktam az urlt: http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=2550886&kbln=en-us

Láss csodát, kaptam egy magyar nyelvű oldalt és 5 perc múlva a kezemben volt a hotfix, ahelyett hogy egy fél napot vártam volna az elutasításra.

Pecs

Kora reggel jött egy kérdés. Valami nem működik egy Exchange 2010 szerveren. Oké, mindjárt megnézem a tesztrendszeren.
Hát, a mindjárt kicsit elhúzódott, ugyanis szégyen ide vagy oda, de marha régen jártam már erre, tizensok patch várta toporzékolva, hogy feltelepüljön. – Jól van, aranyoskáim, azonnal – nyugtattam meg a virtuális gépeket és rányomtam az install gombra.
Közben elmentem reggelizni. Visszajöttem, restart.

Nosza, nézzük azt a problémát. Elindítottam az outlook-ot a kliensen – erre közölte, hogy nincs Exchange szerver. Hoppá. Megpingettem, látta. Névre is, IP-re is. Mind a kettőt. Biztos az outlook2003 hülyéskedik – gondoltam – és beléptem egy másik tesztgépbe, ahol outlook2010 dolgozott. Ugyanaz. Ő sem látta az Exchange szervereket.
Mi a fenét csinálhattak a patch-ek?

Korán reggel volt, az agyam még nem bootolt be rendesen, pusztán ezzel tudom magyarázni, hogy már első körben ész nélkül nekiálltam guglizni. Lett is egy csomó találat, egyik vadabb dolgot mondott, mint a másik. Mindegyik szálnak utánajártam, de minden rendben volt, ezek nem okozhatták a hibát.
Kimentem a konyhába, főztem egy kávét. Innentől mondhatom azt, hogy nekiálltam módszeresen felgöngyölíteni a problémát. Exchange szerver, eventlog. Minden rendben, viszont másfél órával ezelőtt tömérdek piros felkiáltójel. Hmm, hmm. Nagyon sok. Ezt most mind olvassam át? Eh, ez másfél órával ezelőtt volt, nekem meg most van bajom. Majd visszanézek, ha nincs jobb ötletem.
Nézzük az Exchange szolgáltatásokat. Na, itt köptem vissza kis híján a kávét. Az automatikusan induló Exchange szolgáltatások durván fele csak úgy lógott a levegőben, köztük persze az Exchange RPC is. Mind a két szerveren! Ez azért már tényleg izgalmas. Indítsuk újra. Sorra végignyomkodtam a start gombot és a szervízek elindultak. Ráküldtem még vagy 5 refresh-t, de a szolgáltatások makacsul működtek. Ez egyre rejtélyesebb. Valahogy nyugodtabb lettem volna, ha a szolgáltatások egyszer csak maguktól megálltak volna.

Na, mindegy. Nézzük az outlook mit lát. Mindent. Mind a kettő. Mind a két Exchange szerveren. Fejvakarás.
Gyorsan megnéztem, amit a kora reggeli kérdéssel kapcsolatban akartam, aztán amíg válaszoltam, be is ugrott a megoldás. A kora reggel. A patch.
Idősporolás miatt egyszerre nyomtam rá mindegyik szerveren a Windows Update gombra, aztán reggeli után egyszerre a Reboot gombra. Az öt szerver (két DC, két Exchange, egy TMG) egyszerre állt le és egyszerre indult újra. Csakhogy. Amikor az Exchange szerverek szolgáltatásai keresték volna az AD-t, az még sehol sem volt. Emiatt vésték tele piros felkiáltójellel az eseménynaplót. Később persze meglett az AD, de a szolgáltatások nem indultak el maguktól.

Tanulság? A reggeli kávé előtt soha ne pecseljünk.