Windows, DFS, Event Log

Erről rég akaram már írni egy pár szóban. Elég régen használok DFS-t és azt tapasztaltam, hogy a replikáció hajlamos szétesni.
Miért? Mert leáll a replikáció. Valaki kitalálta, hogy egy adatbázis sérülés adatvesztést okozhat, ezért az adatbázis helyreállítás nem automatikus. A tapasztalat azt mutatja, hogy még egy tiszta leállás is könnyedén okoz ilyen állapotot. Hogy miért az jó kérdés.
Ilyenkor a DFS Event Logba kerül egy 2213-as figyelmeztető üzenet (Warning).
Magánvéleményem szerint ez egy igen rossz besorolás. A fenti jelzés besorolása nálam leginkább:

Critical

(Az egyetlen pozitívum, amit itt fel tudok hozni, hogy ellentétben a Microsoftos semmitmondó hibaüzenetek gyakorlatával, itt az event leírásában értelmes információ van. Ha végrehajtjuk a megoldás részben lévő két pontot az megoldja a problémát és még guglizni se kell hozzá.)

Hogy miért?
Mert:

1. Megáll a DFS replika, további figyelmeztetés nincs róla. Amíg a felhasználó észre nem veszi, hogy a fájljai nincsenek rendben az IT nem tud róla. A warning fölött meg könnyű átsiklani egy olyan logban ami könnyedén tele lehet a megszakadó kommunikáció miatt amúgyis warning-okkal.
2. Megáll a SYSVOL replika. Ez egy laza mozdulattal vágja nyakon az AD Group Policy struktúráját. Jujj.
3. Ha nem vesszük észre időben akkor jön a következő hiba:

Olvassuk el az aláhúzott részt!
Mit is jelent ez egy Domain Controllernél?
Elárulom. dcpromo-t. A SYSVOL replikát ugyanis nem lehet kezelni a DFS management alól.
Szerencsére a megoldás nem ez, hanem ez:

wmic.exe /namespace:\\root\microsoftdfs path DfsrMachineConfig set MaxOfflineTimeInDays=120

Majd újra az eredeti wmic parancs:

wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig where volumeGuid="XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" call ResumeReplication

Idiócia Windows 7/2008R2 - Jelszóváltoztatás

Kezdem a kályhától.
Elég sok különböző ügyféllel vagyok kapcsolatban. Ezek össze-vissza mindenféle VPN megoldást használnak. Elég jellemző, hogy ha bemegyek egy ügyfél VPN-jére akkor megszűnik a gépemen a net, az ügyfél gépén, meg sok esetben nem is volt (tipikusan szerver, tisztességgel lekorlátozva).
Ezek miatt kialakítottam egy virtuális gépet a saját Hyper-V infrastruktúrámon, amin fenn van az összes szükséges VPN kliens valamint a Microsoft Remote Desktop Connection Manager-ben összefogva az összes RDP kapcsolat (biztos van ennél jobb, de nem volt kedvem/időm keresni ilyet).
A fenti virtuális gépre szoktam bemenni RDP-vel és onnan managelni az ügyfelek dolgait. Így a saját gépemen megmarad a net, így tudok keresgélni, letölteni.
Az egyik ügyfélnél egy különösen idióta biztonságos konstrukcióba futottam. A VPN felépítésekor még a lokális hálózatot is kinyírta. Tehát amikor felépítettem a VPN kapcsolatot a virtuális gép felé meglévő
RDP-met is lebontotta. Innen az lett a gyakorlat, hogy a Hyper-V managerből a konzolra kapcsolódva intéztem az ügyeket (ezt legalább nem tudja kinyírni a VPN kliens).
Pár napja elkezdtem az ügyféltől kapni a figyelmeztetést, hogy lejár a jelszavam. Húztam-halasztottam, de ma már kénytelen voltam cserélni.
Bejelentkeztem (Hyper-V konzol + RDP kliens) és megpróbáltam megnyomni a Ctrl-Alt-Del-t.
Kaptam a sajtát Windows 8-amhoz ide vonatkozó ablakot. Ctrl-Alt-End: vonatkozó ablak a virtuális Windows 7-en. Millióféle kombináció full screen itt, full screen ott, Ctrl-Alt-Del, Ctrl-Alt-End, sehogy sem kapom meg a megfelelő ablakot az ügyfél Windows Server-én. RDP Manager menük végignézve A-tól Z-ig, nyoma sincs, hogy át tudnám küldeni a megfelelő billentyűzet kombinációt.
Google:
Két módszert találok:
net user parancssorból. Access Denied, mert vagyok Exchange, SPS, SCCM admin, de domain admin nem.
run32dll-es bohóckodás. Windows 7-en és ebből adódóan Windows Server 2008R2-n sem működik.
Dead End. Ez egy agyrém. Nem igaz, hogy a felhasználó számára a Ctrl-Alt-Del nyomkodásán kívül nincs más módszer a jelszóváltoztatásra!!! Örjöngök.
Gondolkoz-Gondolkoz:
OWA beficcen. Jelszó megváltoztat. Huhh.

Exchange 2013 - setup 1.

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

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