Exchange, Active Directory, Windows server... és ami még belefér
Az Exchange Team Blogon jártam. Megláttam a rég várva várt címet Exchange 2013 RTM CU1 … Status.
A “Status” szó így hirtelen nem tett gyanakvóvá. Pedig kellett volna.
Szóval az ígéretekkel ellentétben a fenti update nem jelenik meg az első negyedévben. Tehát még nem tudok a meglévő 2010-es infrastruktúrámba 2013-at telepíteni.
A cél azért nincs messze. Ha igaz amit ígérnek, jövő hét kedden a kezünkbe kerül az új játék. 🙂
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.
Aki szeret elmélyedni a részletekben, annak ajánlom a figyelmébe ezt a word doksit: az összes olyan sémamódosítást tartalmazza, melyeket a 2003-as verzió óta az Exchange okozott, beleértve magának az Exchange-nek a belépését is a címtárba.
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.
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.
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:
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:
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:
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
Recent Comments