A "nagysikerű" Trend Micro-s sorozat után (az összes résznek talán volt annyi hozzászólója mint valamelyik gyengébb Apple vs. Samsung topiknak ) elindítok egy AD sorozatot is többféle céllal.
Elsősorban itt szeretném összegyűjteni azokat az infókat amiket a migrációk, cross-forest Exchange munkák meg egyéb projectek során összegyűlt, és nem szeretném ha a feledés homályába veszne.

Valamint magyar nyelven elég szegényes ebben a témában az anyag, hátha valakinek jól jön majd.

Tehát röviden a mostani project:
Két-három állami cég összeolvad, (összesen 1500-2000 user) közös tető alá kell hozni a tíz éve épített AD és Exchange rendszereket, úgy hogy ne legyen sok sírás, valamint a végén csak egyetlenegy erdő létezzen. (Ja, aki nincs tisztában az AD alapfogalmakkal, azoknak majd valószínűleg csinálok egy pár alapozó részt is ha lesz időm). Jelenleg minkettő működik, egy kétirányú trust van közöttük, az egyikhez van valamilyen hozzáférésem.
El lehet képzelni, hogy 10 év alatt mindkét rendszerben milyen mennyiségű konfiguráció, módosítás meg mindenféle egyéb cucc gyűlt össze, szerdán kell ebből workshopot tartani azoknak akik már évek óta heggesztik a rendszereket, hogy miképp is csinálnám meg a migrációt.

Természetesen minden itt leírt, képernyőmentett cucc a képzelet szüleménye, és csak laborban történt

Tehát a sztori, pénteken sikerült az egyik jóképességű helpdesk-esnek beállítania a hozzáférésem, csinált egy tartományi felhasználót nekem amivel be tudtam lépni a terminal szerverre, majd onnan az exchange szerverekre készített ügyesen egy-egy helyi felhasználót nekem amivel be tudok lépni rájuk RDP-vel.
Mivel eléggé szenzitív rendszer, első körben csak olvasási jogot szabad csak kapnom.
A terminal szerveren nincs semmiféle management eszköz telepítve, a tartományvezérlőre nem tudok belépni, az Exchange szerverre belépve, miután elindítom az ADUC-ot a következő aranyos kép fogad:

Hmm.. ez nem túl bíztató.. az OK lenyomása után se történik semmi amivel előrébb jutnék a rendszer megismerésében:

Ha helyi felhasználóként belépve próbálom az AD konzolt a runas paranccsal futtatni, az is kövér hibára fut.

Az Exchange konzol se sokkal bíztatóbb:

Amit a helpdeskes legénynek csinálni kellett volna: A helyi felhasználókkal történő matyizás helyett, csak felveszi az egyik Exchange szerveren a Remote Desktop Users közé a tartományi felhasználom, meg a read-only exchange adminok közé, ezzel el is van intézve.

Hogy fogok én így bámi infót kinyerni szerdára?

Itt jön elő a régi barátunk, az ADSI editor (a mazochisták majdnem minden AD és Exchange adminisztrációt megcsinálhatnak ebben a progiban )
Alapból nem sok minden látszódik benne, de mindjárt eláraszt minket infóval:

Jobb klikk az ADSI edit ikonra a bal oldalt, majd connect:

Kiválasztjuk, hogy melyik kontextushoz akarunk csatlakozni (DN, Schema, Configuration, stb) majd az advanced gomb lenyomása után megadhatjuk a tartományi felhasználónevet, és meg is nyílik szépen.

A DN és Configuration context megnyitása után:

A DN-ben ugyanaz látható mint az ADUC-ben a haladó beállítások engedélyezése után, a Configuration-ban pedig az Exchange és egyéb dolgok beállításai található. Sajnos mivel még nem vagyok tagja semmilyen Exchange csoportnak, így a configuration, services, Microsoft Exchange konténert üresnek látom
Ugyanígy hozzácsatlakozhatunk a másik erdőhöz, ha a trust be van rendesen állítva, és a DNS is működik.

De ADSI editből milyen információt is tudunk kinyerni ami most épp lényeges a számunkra a tervezéshez:

1, A tartományvezérlők száma, és operációs rendszere:
A DN-ben megnyitva a domain-t, és a domain controllers OU-t, látható, hogy hány db tartományvezérlő van, (itt épp 10db) valamint az első tulajdonságait megnyitva a következők derülnek ki:

Ez a gép Hyper-V-n fut, Windows Server 2003 R2 oprendszer, SP2 telepítve, kicsit lejjeb görgetve pedig látható, hogy mikor telepítették.
Ugyanitt, a printQueue osztályban láthatóak a telepített nyomtatók:

2, Domain és forest functional level:
Domain esetén:

A DN-ben a domain tulajdonságait megnyitni, majd az msDS-Behavior-Version attribútumot sasolni ezerrel.
0 és nTMixedDomain = 1 esetén a domain Windows 2000 mixed módban fut
0 és nTMixedDomain = 0 esetén a domain Windows 2000 natív módban fut
2 értéknél a domain Windows 2003 módban fut
3-nál Windows 2008 módban
4-nél Windows 2008 R2 módban
5-nél Windows 2012 módban

Forest estén:
Configuration, partition, majd a forest nevére jobb klikk, tulajdonságok, és szintén az msDS-Behavior-Version adja meg a választ:

0 = Windows 2000
1 = Windows 2003 interim
2 = Windows 2003
3 = Windows 2008
4 = Windows 2008 R2
5 = Windows 2012

3, DHCP, Cisco ACS
Ha létezik a Configuration / Services / Cisco ACS konténer, akkor valahol van Cisco ACS a hálón.
A Configuration / Services / NetServices-ben található a hitelesített DHCP szerverek listája

4, Tanusítványszolgáltatások, OCS/Lync, AD RMS
A PKI infrastruktúra beállításait a Configuration / Services / Public Key Services-ben
OCS / Lync valószínűleg telepítve van ha a sémában megtaláljuk az ms-RTC kiterjesztéseket
Az RMS beállítások pedig a Configuration / Services / RightsManagementServices-ben vannak.

5, Séma verzió, schema master server
A séma verziójából kiderül, hogy melyik telepítővel csinálták meg az adprep /forestprep parancsot, és ha frissíteni kell akkor ezt is be kell tervezni
Ezek az adatok a séma objektum tulajdonságainál lehet megnézni:

fSMORoleOwner: a schema master szerver neve
objectVersion: a séma verziószáma

Win2000: 13
Win2003: 30
Win2003 R2: 31
Win2008: 44
Win2008 R2: 47
Win2012: 57

Még ezeken kívül sok-sok infót ki lehet nyerni az ADSI editből, de első résznek elég lesz ennyi.