Exchange mentések vs Hyper-V

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

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

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

Tanúsítványok és Windows Phone / Mobile

Egy jó ideje velünk van az IKEv2 típusú VPN, amit úgy szoktunk „reklámozni”, hogy a mobilokra lett kifejlesztve, s csak „másodlagosan” számítógépre. Nos, ezzel kapcsolatban osztanék meg két apróságot, amire érdemes figyelni:

– a Windows Phone (7 – 8.1) / Mobile (10) telefonokon nem lehet törölni a tanúsítványt (létezik egy Certificates app, de az csak megtekintésre jó)

– egyes helyeken olvasható az, hogy a VPN kiszolgálón a root tanúsítványok között csak a miénk legyen, ellenkező esetben minden mást is elfogad. Nos, ez nem állja meg a helyét, hiszen nem véletlenül kell a tanúsítvány tartalmazza a „Server Authentication” és „IP Security IKE intermediate” felhasználási módokat (EKU/AppPolicies*).

* Windows 2000-ig EKU, 2003-tól Application Policies néven található meg az utód, ami viszont MS-specifikus, s bár legtöbbször használatuk megegyezik, nem ugyanaz az EKU-val.

A lefoglalt vhd esete

Egyik cégnél a kollégák már a hajukat tépték, amikor egy aznap délelőtt leállított virtuális gépet akartak ismét elindítani, s folyamatosan hibára futott. Az eseménynaplóban egy olyan hibaüzenetet találtunk csak:

VM-Név

Virtuális-gép-ID

VHD-útvonal.vhd

%%2147942432

0x80070020

The locale specific resource for the desired message is not present

Próbáltunk ennek alapján elindulni. A hibakód azt jelenti, hogy

2147942432: The process cannot access the file because it is being used by another process. (0x80070020).

Tehát próbáltuk kideríteni, hogy ki/mi használhatja ezt az állományt. Mivel a gép leállítása azért történt, mert egy újabb oprendszerű, de azonos nevű VM vette át a feladatát, első sorban erre gyanakodtunk – de a vhd nem volt hozzá csatolva.

Kiderült, hogy egy másik kolléga nem ezt a módszert választotta pár adat kinyeréséhez, hanem a gazdagépre csatolta fel közvetlenül a vhd állományt. Onnan leválasztva, máris elindult a virtuális gép…

Windows 10 Start menü

Egyik kolléga jelezte, hogy váltott Windows 7-ről, s kissé más a Start menü kezelése az állomány-struktúrában. Ahhoz, hogy megértsük a működését, tudnunk kell, hogy rengeteget változott: csak a parancsikonokat (.lnk) és hardlink-eket (utóbbiról itt írtam) látjuk, ráadásul csak az első szintű mappában felsorolva (a további mappa-struktúrát elrejti, azaz úgy mutatja, mintha minden közvetlenül a „Programs” alatt található mappában lenne). Természetesen itt is két helyről szedi össze a parancsikonokat, a közös és a felhasználói profilban található adatokból.

Úgy kell felfognunk, hogy a Start menü „felépítése” nem csak idézőjelekben értendő, ez valóban egy „építkezés” eredménye: egy kereséssel teszi össze a linkekből álló listát. Ha ez megvan, akkor tegyük hozzá Cortana-t – s kiderül, hogy ez ugyanaz a kereső, mint a Keresés (SearchBar).

Ahhoz, hogy tudjuk, hova nyúljunk, nézzük meg a lehetőségeket. Egyrészt van a saját felhasználói fióknak egy Start menüje, másrészt pedig a közös Start menü. Ez utóbbi helyét keresve megnézhetjük a „régi” helyén, a C:\Users mappában, de egy jó ideje már nem itt van tárolva: egy dir /a segítségével láthatjuk, hogy a szokásos „All Users” mappa egy szimbólikus link a C:\ProgramData-ra, míg a „Default User” egy Junction az ugyanitt található Default mappára.

Tehát mindenki Start menüjének a helye: C:\ProgramData\Microsoft\Windows\Start Menu\Programs.

A saját Start menünk helye természetesen a profilunkban van, a C:\Users\[profilnév]\Start Menu, pontosabban ez is Junction, célja C:\Users\[profilnév]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs, mint ahogy a C:\Users\[profilnév]\Application Data is junction a felhasználó AppData\Roaming könyvtárára.

Most, hogy megvannak a tárolási útvonalak, még bonyolítsunk egyet rajta. Ha létrehozunk egy könyvtárat a fenti útvonalak bármelyikén, a benne található .lnk állományok csak akkor jelennek meg, ha azok nem találhatóak meg másik könyvtárban.

Zárszóként még egy útvonalat jegyezzünk meg, a felhasználó által a tálcára kitűzött alkalmazások parancsikonjának helyét: C:\Users\[profilnév]\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar.

Engedélyhez kötött tanúsítványok

Ha bármely tanúsítványsablonon bekapcsoljuk, hogy valakinek kell engedélyeznie a tanúsítvány-kiállítást, akkor pár dologra érdemes figyelnünk az igénylés során. A legegyszerűbb, ha ilyenkor webes felületet használunk a kérelem benyújtásához, ugyanis elbírálás után ugyanezen a felületen tudjuk lekérni a kapott tanúsítványt.

Amennyiben mégis mmc-t (vagy bármilyen más módszert) használunk, akkor a kliens-gépen ott lesz a Request, de az engedélyezés után kapott tanúsítvány kézhezvételéhez a leggyakrabban használt módszerek:

1. exportáljuk a CA-n,
2. kliensen kérjük le a tanúsítványt, a certreq segítségével (Figyelem: bármelyik tanúsítványt le tudjuk kérni a CA-tól, ha tudjuk a CA-ban található RequestID azonosítóját, így mindenképp jegyezzük meg, hogy melyiket akarjuk letölteni)

• interaktív módon:

          certreq -retrieve RequestID

ezután kiválasztjuk a CA-t, illetve, hogy milyen néven/hova kerüljön mentésre a tanúsítvány, alapértelmezetten .cer lesz

• automata üzemmódban:

          certreq.exe -retrieve -config <CAConfig> <RequestID> <OutPutCertFile.cer>

ekkor fontos, hogy a paraméterek ilyen sorrendben legyenek (az ID-t ne tegyük a -config elé, ne tegyük paraméter-megnevezési sorrendbe), a CAConfig pedig lehet pl. Server_Neve\CA_Neve (de certreq -retrieve /? természetesen mindig súg😉 )

Amennyiben sikerült megkapnunk a tanúsítványt, az igénylő gépen importáljuk (akár grafikus felületen, dupla klikkel, akár certreq -accept <OutPutCertFile.cer> paranccsal), itt összerendelődik a privát kulccsal, így „teljessé” válik a tanúsítvány.

Bár néhány internetes fórumon szoktak rájuk hivatkozni, de a tanúsítvány-áttöltéshez se a „certutil -pulse” nem járható út, se a házirendben engedélyezett Auto-enrollment (User Configuration / Windows Settings / Security Settings / Public Key Policies / Certificate Services Client – Auto-Enrollment – erről majd egy következő cikkben még ejtek szót) nem hatásos, mint a hivatalos cikk is jelzi.

WSUS gondok

Az utóbbi időben elég sok 2012/2012 R2 oprendszeren futó WSUS-t kezelő rendszergazdának volt fejfájása. Az ok az, hogy kijött a KB3148812 frissítés, majd nem sok időre rá kijött a javítása, a KB3159706, s mindkét folt telepítése után a konzol használhatatlan lett; így első reakcióként (kerülőmegoldásként) a folt eltávolítása jött szóba. Az, hogy a folt telepítése után fellépő hibák kiküszöbölése érdekében mit kell még tenni, szokatlan módon csak a megjelenés után pár nappal jelent meg.

Nem teljesen szokványos, hogy egy frissítés telepítése után még további reszelést kelljen végrehajtani (bár nem mondhatni azt sem, hogy újdonság, pl. egyes Sharepoint termékek esetén már hagyomány). Ugyanakkor legtöbben azért használunk WSUS-t, hogy részben automatizáljuk a foltok kiszórását, most viszont pont a WSUS működésében lépett fel zavar.

Az elhárításhoz legalább két dolog szükséges:

– megtalálni, hogy mi okozta a hibát (ez nem egyszerű, ugyanis a konzolon a hibaüzenet sem segít, eseménynapló pedig teljesen már irányba visz el minket)

– ha kiderült, hogy a KB3159706, akkor azt elolvasva végrehajtani az ott leírt lépéseket.

S hogy miről is szól ez a folt, miért nem kihagyható? Nos, a Wsus-ban „Upgrades” kategóriába sorolt Windows 10 fejlesztések a Windows Update kiszolgálókon találhatóak titkosított formában már napokkal az élesítés előtt (annak biztosítása érdekében, hogy mindenhol egyszerre tudják kiengedni őket). A Windows 10 oprendszer fel tudja oldani a titkosítást (RTM óta), de a Wsus nem, ezért eddig a Wsus-ra való kiengedés előtt ezeket manuálisan kellett kikódolni, ami időigényes (és lehetséges hibaforrás) volt. A folt felvértezi a 2012/R2-t a kódolás feloldására (2016 már natívan támogatja), ami alapkövetelménye a Windows 10 Anniversary Update (és az őt követő) frissítések kiszórására.

Split-DNS vs .local

Az utóbbi időben két olyan rendezvényen is részt vettem, ahol felmerült a belső tartományi név TLD-kérdésköre: local vs. publikus (split DNS-el). Egyik helyen elfogadták JoeP-el közösen kinyilvánított álláspontunkat, másik helyen kevésbé. Nos, a tanfolyamokon el szoktam mondani ezzel kapcsolatosan a véleményem, a tapasztalataimra alapozva – de ez mindenképp mérlegelés kérdése. Pontosabban csak akkor, ha nem kis cégről beszélünk; ugyanis ahol SBS-t telepítenek, ott „gyárilag” eldöntik helyettünk (ez most az utolsó verziókra vonatkozik, régebben ott is megvolt a döntési szabadságunk).

A válasz ugyanis nagyon nem egyértelmű, ki-ki maga kell eldöntse, hogy mit választ, de ne én mondjam meg a tutit, itt van egy összefoglaló egy MVP-től (maga a cikk régi, de időnként frissítve van új információkkal, s itt felhívnám a figyelmet a legutolsó, 2014-es bejegyzésre, így talán egyértelműbb a kategóriába való besorolás oka is):

http://blogs.msmvps.com/acefekay/2009/09/07/what-s-in-an-active-directory-dns-name-choosing-a-domain-name/