MonthJuly 2009

Ki mivel szív?

Ez anno a régi Technet magazin egyik népszerű rovata volt. (Csak ott az utolsó szót egy szivecske rajz helyettesítette.)

Az egyik kedvenc rovatom volt: a mai napig úgy tartom, hogy egy hiba behatárolásából, megoldásából sokkal többet lehet tanulni, mint egy tisztán elméleti fejtegetéseket tartalmazó cikkből. (De a legtöbbet a kettő kombinációjából: az az ideális, ha a szerencsétlen rendszergazda miután leírta a megoldást, odaírja/odalinkeli mellé az elméletet is.)

Az egyik jó hír, hogy Jim Mcbee-nek eszébe jutott végre a blog jelszava(1). Egyből el is eresztett 8 új írást. A másik jó hír, hogy az egyik egy igen érdekes hibát és annak megoldását tartalmazza.

(1) Illetve beindult az RSS feed-je. Mert ahogy látom, írni írt… csak az RSS reader nem látta.

Pislant a hálókártya

Erre az esetmegoldásra nem leszek büszke, de tanulság azért akad benne.

Nagyon fontos ügyfél (habár hülyeség, mindegyik az) telefonál, hogy megállt a cégnél az internetelérés. Különböző okok miatt az ISA webproxy-ra gyanakszik. Mivel internet nélkül nincs élet, így a bejelentés magas prioritású.
A megoldást nehezíti, hogy magát a belső hálózatot nem mi üzemeltetjük, abszolút semmi hozzáférésünk sincsen. Csak az ISA-t kezeljük mi.

Megnéztem a logokat, mi is a helyzet a webforgalommal: a 80-as porton remekül hasítottak a bitek, még a vizsgálat közben is. Leellenőriztem, hogy ez valós forgalom-e. Az volt. Ment vissza a levél: Kedves Ügyfél, te valamit nagyon benéztél, az ISA-n gyönyörűen megy a http.

Amire jött az indignált válasz, hogy márpedig ez nem megy. Biztos, hogy jó forgalmat néztem?

Bakker. Nem. Hiszen a böngészők webproxy kliensek, akik a webproxy filter listening portján érik el az ISA-t. A 80-as porton csak akkor megy webes forgalom, ha nem webproxy kliens forgalmaz. A konkrét esetben a webproxy filter egy lehetetlen porton (na jó, annyira nem, de akkor sem írom le) figyelt, arra rákeresve rögtön dőltek is a denied connection üzenetek.

Hát, ez már mindjárt más. Akkor itt tényleg baj van.

Event log. Tele volt gyönyörű kövér 14118-as hibákkal. Azt mondja:

Description: The Web Proxy filter failed to bind its socket to IP address port xxxx. This may have been caused by another service that is already using the same port or by a network adapter that is not functional. To resolve this issue, restart the Microsoft Firewall service. The error code specified in the data area of the event properties indicates the cause of the failure.

A részletes hibakód: 0x80072740.

Néhány perc keresgélés után meg is lett a magyarázat. (Komolyan mondom, ma egy informatikusnál az internetes keresési képesség a második legfontosabb készség. Az első az angol nyelv ismerete.) Itt van a KB cikk.
(Ne keverjük össze ezzel a másik cikkel: habár a hibaüzenet ugyanaz, de ez az írás arra az esetre vonatkozik, amikor IIS is fut az ISA mellett.)

Akkor most mi is a hipotézisünk? A hétvégén valószínűleg volt egy rövid időszak, amikor leesett a link az ISA szerver belső lábáról. Ekkor a Windows Server 2003 le is kapcsolta a konkrét hálózati kártyát. Ezt hívják úgy, hogy Media Sense… és feature. Igenám, de amikor visszajön a link és feléled a hálózati kártya, az ISA szerver webproxy filtere nem képes rákapaszkodni a kijelölt portjára. Támadhatják őt a böngészőkből a kliensek, nincs bind. (A pikáns az, hogy a netstat szerint persze ott figyel a megadott porton.) Megoldás? Újra kell indítani a Microsoft Firewall klienst.
Majd.
Eddigre ugyanis az ügyfél morogva beröffentett egy linux proxy-t, mondván ők nem érnek rá. Annyiból igazuk is volt, hogy az ISA nem csak az internet felé forgalmaz, hanem a nagyon fontos anya- és társvállalatok felé is, azt a forgalmat meg még egy percre sem lehet megszakítani szolgáltatás újraindításával.
Majd este.

Addig volt időm körbenézni – és sikerült be is igazolnom a hipotézist: abban a 10 percben, amikor az ISA log szerint megállt a webproxy filter, ott figyelt két bejegyzés a system event logban is:
Warning Event 4: Adapter xxxxxxx Adapter Link Down.
Majd pár perccel később:
Information: Adapter xxxxxxx Adapter Link Up.

A többi már annyira nem érdekes, késő este újra lett indítva a szervíz, minden a helyére került.

Ja, a tanulság: ISA szerveren lehet, hogy nem hülyeség letiltani a Media Sense opciót.
(Windows Server 2008-ban alaphelyzetben le is van.)

Bitvadász vagy-e?

Haladva a korral – ugye tudjuk, előbb-utóbb a Microsoft is nyílt forráskódú lesz (Open Specific Documentation) – egy újabb adag technikai dokumentum került ki az internetre. Hogy egész pontos legyek, az Exchange 2010 működéséhez szükséges MS protokollok teljes és részletes leírása.

A doksik nyitólapja: Microsoft Exchange Server 2010 Beta Protocol Documentation.
De ha nem akarjuk egyenként letöltögetni a pdf fájlokat, akkor az utolsó linkről egy nagy tömörített fájlban is lekaphatóak.

Használati utasítás:

  1. Először nyissuk meg az MS-OXPROTO fájlt, az egy jó nagy nyitódokumentáció.
  2. Keressük meg benne a minket érdeklő protokollt.
  3. Majd nyissuk meg a megadott fájlt.

Én kiváncsiságból az Autodiscovery működését néztem át – MS-OXDISCO – és meg vagyok vele elégedve: tisztességesen részletes.

Sorvezető

Ha ISA 2006 szerveren keresztül szeretnénk Exchange 2007 webszolgáltatásokat kipublikálni, ahhoz ma már nem kell remegő kézzel nekifogni. Az internet tele van cikkekkel, írásokkal, tényleg minden információ begyűjthető. Konkrétan itt van egy MS cikk, ez alapján nem lehet semmi gond.

Vagy mégis?

Nos, amennyiben az Exchange szervered alatt Windows Server 2008 fut, akkor azért fognak érni meglepetések.

Nem akarom végig leírni a folyamatot, az említett cikk tényleg nagyon jó. Itt inkább csak a buktatókat gyűjteném össze.

Először is, a Windows 2003-as CA szerver nem fog tudni neked SAN tanúsítványt gyártani. A következő paranccsal lehet erre rábeszélni:
certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
Majd újra kell indítani a Certification szolgáltatást.

Oké. Fogod, elindítod a böngészőt az Exchange szerveren, rácsatlakozol a http://ca-server.cegnev.hu/certsrv/ weblapra – és már nem emlékszem pontosan, mit kapsz válaszul, de nem a megszokott nyitólapot. Valami olyasmit mond, hogy ez a tartalom a számodra nem érhető el.
Kedves.
A magyarázat itt található: http://support.microsoft.com/kb/922706.
A Windows Server 2003 alatti tanúsítványosztogató weblap olyan activex kontrollt használ, melyet a Windows Server 2008 / Vista undorral lök el magától. A megoldás: fel kell telepíteni egy patch-et a CA szerverre, hogy úgy is tudjon tanúsítványt osztogatni, ahogy az újabb fiúk kérik.

Akkor most már mehetünk is vissza a weblapra. De mégsem. Azt mondja, immár a helyi böngésző, hogy a CA weblapjának https-en keresztül kellene jönnie. Addig ő nem fogja megmutatni a tartalmat.

Kitérő: Szeneslapáttal igazítanám meg a frizuráját annak, aki ezt az egész nevetségesen idióta ‘Enhanced Security’ módú Internet Explorert kitalálta. Tipikusan az, amikor átesünk a ló túloldalára: használhatatlanná tesszük a terméket és a végtelenségig elbonyolítjuk az egyébként is meglehetősen érthetetlen konfigurálást. Ráadásul úgy tudom, W2k8 szerver alatt kikapcsolhatatlan – miközben ott már épp elég védelmet jelentene az UAC is. Amióta ez van, azóta az az első, hogy telepítem a Firefox-ot a szerverekre is. Szerveren úgyse nézeget az ember pornó oldalakat.

Fogcsikorgatás. Nyilván valahol át kell kattintani valamit, melynek a neve még csak nem is utal arra, hogy mit befolyásol. Szerencsére itt van a net, ahol egy sorstárs már megtalálta rá a workaround-ot.
Hurrá. Elérhető lett a CA weblapja.

Lehetne igényelni az Exchange tanúsítványát… de ez mégsem ennyire egyszerű. Amennyiben az Exchange szerverünk Windows Server 2003 alatt fut, akkor – ahogy a cikk is írja – powershell-ből tudunk tanúsítványt generálni. Csakhogy jelen esetben már W2k8 az alap, ezen már van grafikus felület is. Összedobunk egy custom MMC konzolt, felvesszük bele a Certificates (local machine) snapin-t. A Personal folderen jobbkattintunk, majd a lenti képen elmegyünk a ‘Create Custom Request’ menüponthoz.

Nagyítás

Tulajdonképpen mehetnénk a ‘Request New Certificate’ menüpontba is, hiszen itt van, LAN-on belül a CA szerver, mindenki domaintag, ne kelljen már bináris fájl tartalmát kopipasztázgatni. Mehetnénk… de nem működik. A varázsló második ablakán minden szürke – és közli, hogy nekem bizony nincs lehetőségem webserver tanúsítványt igényelnem. Márpedig hidd el nekem, hogy ha nekem nincs meg ez a jogom, akkor senki másnak sem.
Marad a custom request.

Maga az igény összerakása nem túl bonyolult, egy kicsit szokni kell az újfajta grafikus elemeket, de nem vész. Rá kell kattintani minden izére, meg bigyóra, megnézni, mi is van mögöttük. (Shinder bácsi írása elég jól képbe rakhat bárkit.)
Az alábbi ábrán azt a részt emelném ki, amitől SAN lesz a tanúsítvány.

Nagyítás

Igen, az alternatív nevek. Ahogy az előző linken is van – meg máshol is – beírtam a Subject mezőbe CN-ként a külső nevet, az Alternative Name alá meg az összes szóbajöhető lehetőséget, beleértve azt is, hogy bentről esetleg rövid névvel nyomul valaki. Amit a Subject mezőbe írtam, azt nyilván már nem írtam be az Alternative Name alá is. Aztán végigmentem a láncon, igényeltem, kiadtam, importáltam, majd exportáltam végül megint importáltam… szóval ahogy az első linken szépen le van írva – végül jött kintről az OWA teszt.

Nem sikerült. Azt írta ki, hogy a tanúsítvány nem erre a weblapra szól. A Firefox ennél imformatívabb volt, kiírta azt is, hogy mely weblapokra lenne jó ez a tanúsítvány: csak azokra, amelyek az Alternative Name mezőben szerepeltek. A Subject, az nem jött szóba.

Hozzáteszem, nem vagyok tanúsítvány guru. Fogalmam sincs, mennyire kötelező a Subject alatt CN tipusúnak megadni a nevet, nem tudom, lehet-e ott is DNS formátumot használni. Mindenesetre az egyszerűbb utat választottam, az Alternative Name alá is bedobtam a külső nevet – ahogy az ábrán is láthatod. Működött.

Odahaza ne próbáljátok ki

Kollégám futott bele az esetbe. Látszólag ez is X aktaként indult.

Nagy cég, kétszintű domainszerkezet. A felhasználók is és az Exchange 2003 szerverek is a child domainban vannak. Alapvetően minden szépen működik.

A feladat: az Exchange 2007 óvatos beterelgetése.

A címtár preparálása rendben megtörtént, legalábbis a cég alkalmazottja szerint. (A francokat.) Kolléga kiment, szétnézett, látszólag tényleg rendben volt minden.: a csoportok létrejöttek, a séma módosult, az ég kék volt és a madarak csicseregtek.

CAS szerver, HTS szerver rendben be is épült. Jött volna a Mailbox szerver, de a telepítő feldobott egy figyelmeztetést:

Nem tűnik annyira veszélyesnek, nem villog, nem piros… de akkor is, mi lehet ez? Azt mondja, a forest root tartományban nincsen RUS. De hiszen van! Konzolból látszik, adsiedit-ből látszik, a tartományi replikáció nem jelez hibát. Akkor ott RUS-nak kell lennie.

Agyalás. Internet. Kérdések az üzemeltetőkhöz: a setup /preparelegacyexchangepermissions lement minden tartományban?
Persze, hiszen ha paraméter nélkül adják ki, akkor az mindenhol megtörténik.
A setup /preparedomain is lement mindenhol?
Igen.

Ötlet semmi.

Egyáltalán, fontos-e ez egyáltalán? Fórumon valaki felvetette ugyanezt, egy MVP kolléga leoltotta, hogy szarni bele, nem fontos.
Annyiból igaza van, hogy ha a forest root tartományban nincs felhasználó, nincs Exchange szerver, az Exchange 2007 meg úgyis feleslegessé teszi a RUS-t, akkor ki a fenét érdekel, hogy most létezik-e belőle példány a forest root-ban vagy sem?
Annyiból viszont nincs igaza, hogy az AD egy bonyolult, nehezen átlátható rendszer. Ezt tovább bonyolítani csak úgy lehet, ha az adott szinten biztosak vagyunk benne, hogy minden jól működik. Ha nem teljesen százas az AD és ráteszek egy Exchange 2007 szervert, ki garantálja, hogy nem buknak ki váratlan és rejtélyes hibák?

Aludtunk rá egyet.

Másnap leültünk beszélgetni, hátha a közös gondolkodás előrébb visz. És tényleg.

Kitaláltunk egy hipotézist. Mi van, ha – még évekkel ezelőtt – nem történt meg az Exchange 2003 szintű domainprep a forest root tartományban? Most meg a fiúk rányomtak egy setup /preparelegacyexchangepermissions-t, mely kiírta, hogy nincs RUS – aztán ettől megijedve csináltak egyet? Ekkor egy látszólag jó rendszert kapunk – de a domainprep elmaradása miatt az Exchange 2007 nem érzékeli a forest root RUS-t.

Kolléga nekiugrott, tesztrendszeren lemodellezte. Bingo. 2003-as domainprep nélkül pont ehhez a szituációhoz jutottunk. Tulajdonképpen meg is kaptuk a választ: tudjuk, mi okozta a jelenséget, tudjuk, hogy nem fogja zavarni a 2007-es Exchange-t – mi kell még?

Például az, hogy lehet-e javítani? Hiszen van tesztrendszerünk, miért ne néznénk meg?

Kolléga ráküldte – a már 2007-esre preparált tartományra – a 2003-as domainprep-et. Na, ott volt ám csikorgás, meg füstölés. Fogaskerekek sikítottak, recsegett a fém. Végül lement a domainprep – de egy bizarr rendszert kaptunk. Az adminisztrátorok például kapásból le lettek tiltva (deny) egy csomó Exchange objektumról. Ijesztő volt.
Ekkor jött a kisérlet második fele. Kolléga megküldte a tartományra újból a 2007-es preparációkat – és gyönyörűen kiegyenesedett minden.

De az éles rendszeren valószínűleg nem próbáljuk ki.

Bizonytalan vagyok. Vagy nem?

Van egy CCR rendszerem, rengeteg adatbázissal. A hiba: az egyik adatbázis nem mountolható. A copy status: initalizing.
Vizuális vizsgálat: az adatbázis is, a logfájlok is szépen a helyükön vannak. Átnéztem a passzív node-ra… ott is.

Oké, mountoljuk fel. Nem megy, kiírja, hogy hiányzik neki egy logfájl. Nem mondom, hogy a popsimat vertem földhöz örömömben, de éreztem egy kis kellemes bizsergést. Itt van, végre élesben is ki lehet próbálni, mit ér a CCR. Az update-storagegroupcopy parancsot használtam már annyit a passzív node-on, hogy unom – ezzel szemben most van lehetőségem először alkalmazni a restore-storagegroupcopy parancsot az aktív node-on.

Azt írta ki, hogy ‘database was already marked as available for a mount, no action was taken‘. Azaz szerinte minden frankó, ez egy mountolható adatbázis.
Még egyszer megnéztem a passzív node-ot, megvolt az adatbázisról és a logfájlokról a replika. Oké. Fogtam, kitöröltem az aktív node-on az adatbázist.
Na, erre legyen bőr a képeden azt mondani, hogy mountolható!

Azt mondta.

Letöröltem az összes logfájlt is. Újabb restore. Megint azt mondta, hogy minden rendben, ez egy mountolható adatbázis. Miközben se adatbázis nem volt a partíción, se egy nyomoronc logfájl.
Irígyeltem az optimizmusát.

Futottam még egy bátortalan kört, hogyan lehetne _mindenképpen_ ráfuttatni a restore parancsot… de nem lehet. A -force kapcsoló sajnos nem ezt jelenti.
Törődjünk bele, ha az Exchange úgy gondolja, hogy minden rendben, akkor nincs visszaállítási lehetőséged. Még akkor sem, ha tokkal-vonóval hiányzik az egész adatbázis.

Nyilván a körbedolgozás működött. Elindítottam egy failovert, a korábbi passzív node-on ezután már felállt a problémás adatbázis, fel is lehetett mountolni. Ekkor a korábbi aktív node-on, mely most ugye már passzív lett, ki lehetett adni az update-storagegroupcopy parancsot, melynek van egy bűvös -deletexistingfiles kapcsolója. Na, ez képes gyökeresen elrendezni a terepet, csak a sávszélesség bírja.
Aztán jöhetett egy failback, és újra minden rendben.