Převod domény z Windows Server 2008 R2 na Windows Server 2012 R2

Obecný postup převodu domény

Běžná a doporučovaná metoda povýšení doménového řadiče je Side-by-side migration, která spočívá v instalaci nového serveru, z kterého vytvoříme doménový řadič, a přesuneme na něj role a funkce. Použití In-place upgrade je za určitých podmínek také možné, ale může způsobit řadu problémů.

Dokumentace

Nějaké informace z internetu, počínaje oficiálním popisem Microsoftu.

• Upgrade Domain Controllers to Windows Server 2012 R2 and Windows Server 2012
• Step-By-Step: Adding a Windows Server 2012 Domain Controller to an Existing Windows Server 2003 network
• Upgrading or Migrating Active Directory to Windows Server 2012 - Build Your Roadmap Now
• Introducing the first Windows Server 2012 Domain Controller (Part 1 of 2)
• Upgrading an Active Directory Domain from Windows Server 2008 or Windows Server 2008 R2 to Windows Server 2012 or Windows Server 2012 R2

Kroky migrace Active Directory

• připravit dokumentaci aktuálního stavu (doména, využívané služby, kdo k AD přistupuje, atd.)
• kontrola předpokladů
• otestování stavu domény a funkčnosti replikací (to bychom samozřejmě měli provádět průběžně či stále)
• příprava AD databáze (ADPREP)
• přidání nového serveru jako doménového řadiče
  • instalace (virtuálního) serveru s OS Windows Server 2012 R2, nastavení pevné IP adresy a DNS serverů, ponechání IPv6 (jeho vypínání je nedoporučeno)
  • (volitelně) zařazení do domény
  • povýšení serveru na doménový řadič
• přesuny rolí a funkcí
• odstranění starého DC
• opakování pro zbývající řadiče
• odstranění posledního původního DC
• povýšení funkčního stupně domény a lesa

Postup z pohledu jednotlivých DC

Standardně máme dva nebo více doménových řadičů. Nejprve potřebujeme mít přehled, kde se nachází jaké FSMO (Flexible Single Master Operations) role, správně se dnes používá termín Operations Master role. To je PDC Emulator, RID Master, Infrastructure Master, Schema Master a Domain Naming Master. Krátký popis je v článku Active Directory komponenty - domain, tree, forest, site.

Pokud nemáme tuto informaci v nějaké dokumentaci, či chceme ověřit reálný stav, tak můžeme využít grafické nástroje pro správu AD nebo získat jednoduchý přehled pomocí řádkových příkazů:

• dsquery server - seznam DC serverů
• netdom query fsmo - vypíše všechny role a jejich držitele
• dsquery server -hasfsmo schema - vypíše, kdo má roli Schema Master
• dsquery server -hasfsmo name - vypíše, kdo má roli Domain Naming Master
• dsquery server -hasfsmo infr - vypíše, kdo má roli Infrastructure Master
• dsquery server -hasfsmo pdc - vypíše, kdo má roli PDC Emulator
• dsquery server -hasfsmo rid - vypíše, kdo má roli RID Master
• dsquery server -isgc - vypíše DC, které mají GC

Role můžeme mít rozděleny různě, já budu pro zjednodušení brát situaci, že jsou všechny role na jednom DC a tomu budu říkat (historicky) PDC (Primary DC). Ostatní řadiče budu označovat jako BDC (Backup DC). Při migraci řadičů je nejjednodušší začít tím, který má nejméně rolí, tedy nějakým BDC.

Druhá věc jsou IP adresy doménových řadičů. Pokud budeme mít nový DC s novou IP adresou, tak patrně budeme muset změnit velké množství různých konfigurací na stanicích a serverech (minimálně třeba DNS, pokud využíváme tak RADIUS, apod.). Proto mi přijde jednoduší prohodit IP adresy, aby nový DC měl stejnou adresu jako nahrazovaný. Změna IP adresy doménového řadiče je oficiálně podporovaná. Pouze se doporučuje zkontrolovat DNS záznamy, že se správně změnily.

Pro některé situace je také otázka DNS jméno řadiče, pokud máme třeba napojené různé systémy na LDAP (a v konfiguraci používají DNS jméno) nebo nám na DC běží certifikační autorita (tuto situaci probíráme na konci článku) či print server. Pokud máme více DC, tak můžeme vždy jeden odstranit a pak teprve vytvořit nový se stejným jménem. Případně můžeme DC v nějakém kroku přejmenovat.

Takže takový obecný postup:

• nainstalujeme nový (záložní) BDC
• zprovozníme na něm všechny funkce jako na nahrazovaném DC
• změníme IP adresy
• otestujeme funkčnost a postupně odstraníme funkce na původním DC
• odstraníme původní DC a celý server

Poté budeme pokračovat s dalšími BDC, až se dostaneme k (primárnímu) PDC, který je nositelem Operations Masters rolí. Tam při odstraňování funkcí také přesuneme všechny role.

Kontrola předpokladů

Asi hlavní předpoklad, abychom do naší AD domény mohli přidat doménový řadič Windows Server 2012 R2, tak musí být funkční stupeň (Functional Level) domény minimálně Windows Server 2003. Já vycházím z toho, že máme Windows Server 2008 R2.

Také bychom na začátku měli ověřit, že nám nic jiného nebrání přidat nový doménový řadič Windows Server 2012 R2. Jde o různé aplikace, které jsou silně provázány s Active Directory. Příkladem je třeba Exchange Server 2010, který takový řadič podporuje až s nainstalovaným Update Rollup (RU) 5. Nebo SharePoint Server.

Kontrola stavu Active Directory

Kontroly AD bychom měli provádět průběžně. Důležité je ověřit, že je vše v bezchybném stavu, než začneme provádět změny na Active Directory. Stejné kontroly provedeme po přidání nového doménového řadiče, odstranění původního a na konci po povýšení funkčního stupně.

Testování Active Directory, domény, replikací

Je řada věcí a nástrojů, které můžeme pro kontrolu použít (nějaké informace popisuje třeba článek Active Directory Health Checks for Domain Controllers). Některé možnosti jsou uvedeny níže.

• Určitě bychom měli projít logy událostí (Event Viewer), že se v nich nenachází zásadní události stupně Error nebo Warning.
• Analýzu stavu doménových řadičů provede Domain Controller Diagnostics Tool, můžeme jej volat bez parametrů nebo použít přepínače a výstup uložit do souboru.
  • dcdiag
  • dcdiag /v /c /d /e /s:jmeno-DC > c:\jmeno-DC.log
• Pro kontrolu replikací můžeme využít Replication Diagnostics Tool, opět je k dispozici řada přepínačů (v posledním příkazu se zadává jméno doménového řadiče, zde je použito *dc, což zahrnuje všechna jména končící DC)
  • Repadmin /showreps
  • Repadmin /replsum /errorsonly
  • Repadmin /showrepl *dc /verbose /all /intersite > c:\repl.log
• Další (grafický) nástroj pro kontrolu replikací můžeme stáhnout z MS Active Directory Replication Status Tool
• Pro diagnostiku DNS můžeme stáhnout (starý) nástroj Description of the DNSLint utility, volá se z příkazové řádky a vytvoří soubor dnslint.htm
  • Dnslint /ad /s IP.adresa.DNS.serveru

Pro zajímavost ještě informace, jak můžeme z AD získat informaci o verzi schématu (nikoliv o funkčním stupni domény). Prvním krokem, než nainstalujeme doménový řadič nové verze, je použití ADPREP pro přípravu AD a tím se povýší schéma.

C:\>Dsquery * cn=schema,cn=configuration,dc=firma,dc=local -scope base -attr objectVersion
  objectVersion
  47

Výstupní hodnota verze znamená:

• 13 = Windows 2000 Server
• 30 = Windows Server 2003
• 31 = Windows Server 2003 R2
• 44 = Windows Server 2008
• 47 = Windows Server 2008 R2
• 56 = Windows Server 2012
• 69 = Windows Server 2012 R2

Instalace nového doménového řadiče

Nainstalujeme čistý (virtuální) server s OS Windows Server 2012 R2. Nastavíme pevnou IP adresou a DNS server. IPv6 ponecháme (jeho vypínání je nedoporučeno). Já provádím i to, že server zařadím do domény.

Příprava lesa, domény a schéma

Než přidáme do domény první DC s Windows Server 2012 R2, tak musíme připravit les (forest), doménu (domain) a schéma (schema). Můžeme k tomu použít příkaz Adprep, který se nachází na instalačním médiu Windows Server 2012 R2 ve složce Support/adprep. Nachází se zde již pouze 64 bitová verze Adprep.exe, takže ji můžeme spustit pouze na 64 bitovém OS. Dnes již není nutné jej spouštět přímo na DC držiteli Operations Masters rolí, ale funguje vzdáleně. Musíme jej spustit pod uživatelem, který je členem skupin Enterprise Admins, Schema Admins a Domain Admins. Používají se následující přepínače:

• Adprep /forestPrep - příprava lesa
• Adprep /domainPrep /gpPrep - příprava domény a zároveň Group Policy
• Adprep /rodcPrep - pokud chceme využívat DC pouze pro čtení

V současnosti již nemusíme používat Adprep ručně, přípravy AD proběhnou při instalaci prvního nového DC. To je popsáno v dalším kroku. Ale podle informací v Group Policy preparation is not performed when you automatically prepare an existing domain for Windows Server 2012 neproběhne Adprep /domainPrep /gpPrep a ten musíme spustit ručně!

Povýšení serveru na DC

Celý proces můžeme provést pomocí grafického průvodce. Jde o dvě fáze

• nejprve přidáme roli Active Directory Domain Services (můžeme rovnou přidat i další vlastnosti DNS, určité RSAT nástroje, SNMP Service, apod.) - to je spolu s obrázky popsáno v článku Windows Server 2012 Active Directory
• po instalaci AD DS role povýšíme server na DC - tomu se věnujeme níže

Po dokončení přidání role se nám v Server Manageru u vlajky zobrazí vykřičník, kliknutím na ikonu se dozvíme, že je třeba provést Post-deployment configuration - Promote this server to a domain controller.

V prvním kroku průvodce volíme, že přidáváme řadič do existující domény, také vidíme credentials přihlášeného uživatele a můžeme je pomocí Change změnit.

Provedou se určité kontroly a detekce našeho prostředí, buď se zobrazí chyba, nebo další krok. Zde určujeme vlastnosti (DNS a GC), můžeme DC vytvořit jako RODC, volíme Site a nastavujeme heslo pro Directory Services Restore Mode (DSRM).

V kroku DNS Options můžeme varování o DNS delegaci ignorovat.

Volíme, z jakého DC proběhne replikace AD, můžeme použít i soubor (Install from media - IFM)

Nabídnou se defaultní cesty k databázi, logům a SYSVOLu. Obecně se pro databáze doporučuje umísťovat DB soubory jinam než logy, ale myslím, že pro AD se často ponechává defaultní systémová složka.

Pokud nemáme připravené AD, tak další krok informuje, že dojde k přípravě lesa, domény a schématu. Pokud nejsme přihlášení účtem s dostatečnými právy, tak jsme informováni a můžeme jej změnit.

Následuje již pouze shrnutí a tlačítkem Install odstartujeme instalaci. Po kliknutí na tlačítko Close dojde k restartu serveru.

Kontroly po instalaci DC

Po té, co máme připravený nový DC, je důležité zkontrolovat, že vše probíhá v pořádku. Mimo kontrol logu událostí, replikací, apod. můžeme také využít Best Practices Analyzer (BPA) for Active Directory (ale také třeba DNS a dalších rolí). Nalezneme jej v Server Manager, kde zvolíme AD DS, a skrolujeme dolů na sekci Best Practices Analyzer.

Přesuny služeb a rolí

Následuje popis migrace běžnějších rolí, které mohou běžet na DC, na nový server.

Převod DNS serveru

Roli DNS jsme nainstalovali spolu s AD DS. Běžné zóny jsou součástí AD, takže se nám přenesou spolu s replikací AD. Také se automaticky přidá nový DNS server jako Name Server pro všechny zóny. Pouze pokud jsme použili nějaké zóny, které nejsou Active Directory-Integrated, tak je musíme řešit.

Převod NPS

Network Policy Server (NPS), který nabízí služby RADIUS (Remote Authentication Dial In User Service) serveru, můžeme převést velice jednoduše. Oficiální popis Migrate Network Policy Server to Windows Server 2012 R2.

Grafické rozhraní mmc konsole Network Policy Server je shodné ve verzi Windows Server 2008 R2 i Windows Server 2012 R2. Pokud klikneme pravým tlačítkem na NPS (local), tak je zde volba Export Configuration, která uloží celou konfiguraci (včetně shared secrets) do XML souboru. Na novém serveru pak použijeme volbu Import Configuration. Pokud to potřebujeme, tak také v kontextovém menu nalezneme volbu Register server in Active Directory.

Otázka je, že klienti se obrací na RADIUS server na určitou IP adresu. Takže buď musíme všude změnit nastavení, nebo jednodušší je, po aktivaci všech rolí, změnit IP adresu nového serveru na adresu nahrazovaného.

Převod DFS

Služba Distributed File System je součástí role File and Storage Services, takže nainstalujeme potřebné části (DFS Namespaces a DFS Replication). Potom pomocí DFS Management přidáme nový Namespace Server pro každý používaný Namespace.

Nejprve klikneme pravým tlačítkem na Namespaces a zvolíme Add Namespaces to Display. Poté klikneme pravým tlačítkem na zobrazený Namespace a zvolíme Add Namespace Server.

Převod DHCP

Oficiální popis Migrate DHCP Server to Windows Server 2012 R2 využívá Windows Server Migration Tools (Export-SmigServerSetting, Import-SmigServerSetting), jiné články jako Migrating existing DHCP Server deployment to Windows Server 2012 DHCP Failover a DHCP PowerShell Export Import cmdlets in Windows Server 2012 využívají nové cmdlety na Windows Server 2012 Export-DhcpServer a Import-DhcpServer.

Migraci DHCP serveru na nový řadič provedeme vcelku jednoduše pomocí exportu a importu nastavení (včetně zapůjčených adres). Můžeme využít řádkový příkaz netsh (ten má výhodu, že je podporován i při migraci z Windows Server 2003, což jsem popisoval ve starším článku), ale nově se doporučuje využít PowerShell.

Na cílový server nainstalujeme roli DHCP server a provedeme úvodní nastavení, což je autorizace (přidání) do AD. Spustíme PowerShell a export i import provedeme z tohoto serveru. Export DHCP nastavení ze serveru pdc.firma.local do souboru provedeme pomocí cmdletu:

Export-DhcpServer -ComputerName pdc.firma.local -Leases -File c:\dhcpexp.xml -verbose

Poté je dobré zastavit službu DHCP serveru na původním serveru. Import na nový server provedeme pomocí cmdletu:

Import-DhcpServer -ComputerName pdc-new.firma.local -Leases -File C:\dhcpexp.xml -BackupPath C:\dhcp -Verbose

Parametr BackupPath určuje složku, kam se nejprve provede záloha aktuálního nastavení serveru, než dojde k importu nových hodnot.

V našem případě máme DHCP server spolu s DNS serverem na DC, tehdy se doporučuje použít speciální účet DNSCredentials pro registraci DNS záznamů. Nastavení tohoto účtu se nepřeneslo spolu se zálohou. Nastavuje se tak, že v DHCP konzoli klikneme pravým tlačítkem na IPv4 (nebo IPv6), zvolíme Properties záložka Advanced a dole je tlačítko Credentials.

Převod Print Serveru

Oficiální popis Migrate Print and Document Services to Windows Server 2012, případně obrázkový návod Step-by-Step: Migrating Print Servers from Windows Server 2008 to Windows Server 2012.

Migrace tiskového serveru včetně ovladačů je jednoduchá záležitost.

• na novém serveru spustíme mmc konzoli Print Management
• klikneme pravým tlačítkem na kořenovou položku Print Management a zvolíme Migrate Printers
• nejprve zvolíme Export printer queues and printer drivers to a file
• v nastavení se připojíme k původnímu serveru a data uložíme do souboru
• poté spustíme znovu průvodce a zvolíme Import printer queues and printer drivers from a file
• zvolíme aktuální (nový) server a náš uložený soubor
• provedeme import a na závěr zkontrolujeme log událostí a otestujeme tiskárny

V průvodci jsme v jednom kroku volili, jestli se mají tiskárny publikovat do AD (List in the directory). Pokud je publikujeme a měli jsme je publikované i dříve, tak je nyní uvidíme dvakrát. Můžeme odstranit publikaci z původního serveru (Remove from directory).

Když jsme migrovali tiskárny ze starého tiskového serveru na nový, tak se sice přenesla celá serverová část, ale klienti mají tiskárnu nastavenu přes jméno tiskového serveru. Takže si je musí znovu přidat. Případným řešením je přejmenování nového serveru na jméno původního (v tom případě při importu neprovedeme publikaci tiskáren do AD, ale tuto operaci provedeme manuálně po přejmenování).

Převod WINS serveru

Stále jsme se nezbavili používání historických NetBIOS jmen (i když to Microsoft dlouho slibuje), takže často využíváme službu WINS. Stejně jako na Windows Server 2008, tak i na verzi 2012 jde o vlastnost (Feature) serveru, kterou musíme přidat.

Přenos dat funguje jednoduše na principu replikací. Otevřeme WINS konzoli kam si připojíme oba servery. U každého serveru rozklikneme Replication Partners, klikneme pravým tlačítkem a zvolíme New Replication Partner, kde zadáme vždy druhý WINS server. Poté zvolíme z kontextového menu Replicate Now.

Napoprvé mi replikace nefungovala, přitom se ani nelogovala žádná chyba, vše se vyřešilo restartem serveru (restart služby nepomohl).

Zabezpečení SSL/TLS

Můžeme zvýšit bezpečnost protokolů SSL/TLS nastavením povolených šifer, například pomocí aplikace IISCrypto, viz. článek Protokol SSL/TLS - vypnutí slabých šifer a zabezpečení serverů.

Monitoring

Pokud používáme nějaký dohled, syslog server, apod. tak musíme zařadit nový server do dohledu a zprovoznit SNMP a další používané nástroje.

Změna IP adresy

Původní DC nastavíme na nějakou volnou IP adresu. Novému DC nastavíme původní IP adresu a správné DNS servery (doporučuje se nastavit Preferred DNS na partnerský DNS server, Alternate DNS na voji IP adresu a přidat třetí adresu na 127.0.0.1). Poté můžeme rušit funkce na původním DC a kontrolovat funkčnost.

Po změně IP adresy můžeme na DC spustit následující příkazy (pro jistotu pro nastavení DNS záznamů), případně jej restartovat.

• ipconfig /flushdns
• ipconfig /registerdns
• dcdiag /fix

Rušení služeb na původním DC

DFS (Distributed File System)

Pomocí DFS Management otevřeme daný Namespace a přepneme se na záložku Namespace Servers, zvolíme původní server a Delete. Roli zatím nemůžeme odinstalovat, až při odstraňování AD DS.

NPS (Network Policy Server)

Odebereme roli NPS.

WINS (Windows Internet Name Service)

Oficiální popis Decommission a WINS server. Nejprve zkontrolujeme, že se nám všechna data zreplikovala. Klikneme pravým tlačítkem na Active Registrations, zvolíme Delete Owner, vybereme IP adresu odstraňovaného serveru a vybereme Replicate deletion to other WINS servers (tombstone). Vynutíme replikaci. Můžeme odebrat replikační partnery (se zrušením vazeb) a odinstalovat vlastnost WINS.

DNS (Domain Name System)

Odebereme roli DNS. Tím, že odinstalujeme roli DNS na serveru, tak se nezruší záznamy na zónách, kde byl tento server autoritativní (ve většině případů jde o ty AD-Integrated). Musíme tedy provést několik ručních zásahů. Oficiální popis Removing a DNS Server.

Na každé zóně (Forward i Reverse Lookup Zones) editujeme (pravým tlačítkem na zónu a volba Properties) záložku Name Servers a smažeme (remove) odstraňovaný server. Pokud máme zón hodně, tak můžeme zkusit nějaký skript, například How to update the list of Name Servers on a DNS Zone with a Script.

Windows Server 2012 přidal do PowerShellu možnosti správy DNS, takže si můžeme vytvořit malý skript, který odstranění provede. Níže uvedený skript je příklad a neručím za jeho chování ;-). Využijeme cmdlety Get-DnsServerZone, Get-DnsServerResourceRecord, Remove-DnsServerResourceRecord.

Nejprve pro otestování si můžeme vypsat všechny zóny a jejich name servery.

Get-DnsServerZone | Where-Object { $_.ZoneType -eq "Primary" -and $_.IsAutoCreated -eq $false } |
  ForEach-Object {
    echo $_.ZoneName
    Get-DnsServerResourceRecord $_.ZoneName -RRType NS -Node
  } 

Potom můžeme obdobným způsobem odstranit ze všech zón rušený DNS server. V příkladu je třeba změnit DNS jméno odstraňovaného serveru místo položky stary-dns.firma.local.

Get-DnsServerZone | Where-Object { $_.ZoneType -eq "Primary" -and $_.IsAutoCreated -eq $false } |
  ForEach-Object {
    Try { 
      Remove-DnsServerResourceRecord -ZoneName $_.ZoneName -RRType NS -Name "@" -RecordData " stary-dns.firma.local." -Force 
    } Catch [system.exception] {
      "Nejaka chyba pri odstranovani - patrne neexistuje zaznam nebo nemate opravneni."
    }
  } 

DHCP (Dynamic Host Configuration Protocol)

Když rušíme DHCP server, tak bychom měli odstranit jeho záznam z autorizovaných DHCP serverů v Active Directory (AD). Můžeme to provést v konzoli DHCP, ale v té chvíli musí server běžet. Klikneme pravým tlačítkem na daný server a zvolíme Unauthorize. Nebo pomocí příkazu netsh či cmdletu Remove-DhcpServerInDC, v tom případě již nemusí server vůbec existovat.

Pomocí Network Shell si nejprve vypíšeme seznam autorizovaných serverů z AD a pak můžeme starý server odstranit.

netsh dhcp show server
netsh dhcp delete server pdc.firma.local 10.0.0.10

Pozn.: Když jsme změnili IP adresu původního serveru, tak je stále registrovaná ta stará. Ale díky kombinaci jméno serveru a IP adresa odstraníme ten správný záznam.

Pomocí PowerShellu je postup shodný (musíme použít PowerShell na Windows Serveru 2012 s rolí DHCP).

Get-DhcpServerInDC
Remove-DhcpServerInDC -DnsName pdc.firma.local -IPAddress 10.0.0.10

Na závěr můžeme odebrat roli DHCP.

Změna bridgeheads serveru

V oficiální dokumentaci jsem k tomu nic nenašel, ale v praxi jsem narazil na problém, takže doporučuji tento krok provést (čekal jsem, že si tuto změnu vyřeší AD DS automaticky při odstraňování řadiče).

V případě, že máme více Site, tak před odstraněním doménových služeb zkontrolovat, že server není Preferred Bridgehead Server. A pokud je, tak toto změnit. Tyto servery si můžeme vypsat následujícím řádkovým příkazem nebo použít grafický nástroj, kterým dále provedeme změnu.

repadmin /bridgeheads

Pokud je náš odstraňovaný server Bridgehead, tak tuto vlastnost přesuneme na jiný doménový řadič. Použijeme Active Direcotry Sites and Services - Sites - naše site - Servers. V tabulce vidíme, který server je Bridgehead pro jaký transport (dnes asi pouze IP). Klikneme pravým tlačítkem na nový server a zvolíme Properties. Dole zvolíme Transport a Add. Obdobným způsobem odstraníme transport u rušeného serveru.

AD DS (Active Directory Domain Services)

Oficiální popis Removing a Domain Controller from a Domain. Odebráním doménových služeb zrušíme funkci doménového řadiče.

Nejprve spustíme dcpromo.exe a projdeme průvodce

Po dokončení se provede restart serveru. Pomocí Server Manager - Remove Roles odebereme roli Active Directory Domain Services a případně i File Services (DFS).

Problém při odstraňování AD DS

Při odstraňování doménového řadiče jsem narazil na následující chybu:

The operation failed because:
Active Directory Domain Services could not transfer the remaining data in directory partition DC=DomainDnsZones,DC=firma,
DC=local to Active Directory Domain Controller \\pdc.firma.local.
"The directory service is missing mandatory configuration information, and is unable to determine the ownership of floating
 single-master operation roles."

Problém je popsán v článku DCPROMO demotion fails if unable to contact the DNS infrastructure master. Pro ověření stavu, popsaného v chybě, si můžeme vypsat hodnoty pomocí řádkového příkazu:

dsquery * CN=Infrastructure,DC=DomainDnsZones,DC=firma,DC=local -attr fSMORoleOwner
dsquery * CN=Infrastructure,DC=ForestDnsZones,DC=firma,DC=local -attr fSMORoleOwner

V případě této chyby zde nalezneme starý doménový řadič OLD-PDC, což byl ještě Windows Sever 2003, který byl odstraněný před řadou let. Oprava se dá provést pomocí skriptu KB 949257, další info ForestDNSZones or DomainDNSZones FSMO says The role owner attribute could not be read. Ten spustíme pro obě zóny:

cscript fixfsmo.vbs DC=ForestDnsZones,DC=firma,DC=local
cscript fixfsmo.vbs DC=DomainDnsZones,DC=firma,DC=local

Nebo můžeme provést to samé ručně pomocí ADSI Edit, kdy můžeme volit, jaký DC nastavíme místo chybného. Důležité je, že se musíme připojit na držitele role, jinak při pokusu o změnu, dostaneme chybu:

Operation Failed. Error code: 0x20ae
The role owner attribute could not be read
  
000020AE: SvcErr: DSID-03152BF7, Problem 5003
(WILL_NOT_PERFORM) Data 0

Takže se v ADSI Edit připojíme na Connection Point DC=ForestDnsZones,DC=firma,DC=local a zvolíme odpovídající DC. Proklikáme se na Infrastructure a změníme atribut fsMORoleOwner na hodnotu s opraveným serverem:

CN=NTDS Settings,CN=PDC,CN=Servers,CN=Praha,CN=Sites,CN=Configuration,DC=firma,DC=local

Odstranění serveru

I když jsme ze serveru odstranili roli doménového řadiče, tak nám zůstal záznam v Site serverech, který můžeme smazat. Active Direcotry Sites and Services - Sites - naše site - Servers, klikneme pravým tlačítkem na rušený server a zvolíme Delete.

Odstraníme server z domény (Control Panel - System - Change Settings - Computer Name - Change - Member of Workgroup) a v AD smažeme jeho účet. Můžeme zkontrolovat DNS jestli někde nezůstal záznam s původním DC (hlavně doménové SRV).

Pokud máme DC v různých Site, tak při změnách potřebujeme vždy počkat, aby došlo k replikaci. Je dobré kontrolovat replikační topologii v Active Direcotry Sites and Services, jestli se při odstraňování DC nepoškodí. Nastavení Bridgehead serveru a spojení mezi DC (Connections). Pokud dojde k problému, tak můžeme ručně přenastavit. Za určitých podmínek můžeme spojení smazat a na každém DC můžeme spustit repadmin /KCC pro nové vygenerování. Knowledge Consistency Checker (KCC) se defaultně spouští každých 15 minut a generuje AD replikační topologii.

Přesun Operations Master rolí

Dříve, než z PDC, které je držitelem rolí, odstraníme doménové služby, tak musíme tyto role přesunout na jiný DC. Role Schema Master a Domain Naming Master jsou unikátní pro celý les a změnu musíme provádět pod účtem s právy Enterprise Admin. Role RID Master, PDC Emulator a Infrastructure Master jsou unikátní pro danou doménu a změnu musíme provádět minimálně pod účtem s právy Domain Admin (změna všech tří se provádí stejným nástrojem). Přesun rolí si popíšeme pomocí grafických nástrojů, ale je také možné použít příkaz ntdsutil.

Oficiální popis Transfer the Domain-Level Operations Master Roles, Transfer the Domain Naming Master, Transfer the Schema Master.

Schema Master

Pomocí Active Directory Schema, klikneme pravým tlačítkem na hlavní položku Active Directory Schema [DNS jméno připojeného DC], pomocí Change Active Directory Domain Controller se připojíme k DC, kterému chceme předat roli a pomocí Operations Master a tlačítka Change můžeme změnit držitele role.

Pozn.: Pro správu používáme nástroje z Remote Server Administration Tools (RSAT), mezi nimi je také Active Directory Schema snap-in. Na rozdíl od ostatních jej ale nejprve musíme registrovat v systému. To provedeme spuštěním regsvr32 schmmgmt.dll. Potom můžeme použít mmc konzoli a přidat Snap-in Active Directory Schema (nejlépe následně uložit).

Domain Naming Master

Pomocí Active Directory Domains and Trusts, klikneme pravým tlačítkem na Active Directory Domains and Trusts [DNS jméno připojeného DC], pomocí Change Active Directory Domain Controller se připojíme k DC, kterému chceme předat roli a pomocí Operations Master a tlačítka Change můžeme změnit držitele role.

Relative Identifier (RID) Master

Pomocí Active Directory Users and Computers, klikneme pravým tlačítkem na jméno domény, pomocí Change Domain Controller se připojíme k DC, kterému chceme předat roli a pomocí Operations Master a tlačítka Change můžeme změnit držitele role.

Pozn.: Na dalších záložkách můžeme pokračovat s dalšími rolemi.

Primary Domain Controller (PDC) Emulator

Pomocí Active Directory Users and Computers, klikneme pravým tlačítkem na jméno domény, pomocí Change Domain Controller se připojíme k DC, kterému chceme předat roli a pomocí Operations Master, přepnutí na záložku PDC a tlačítka Change můžeme změnit držitele role.

Infrastructure Master

Pomocí Active Directory Users and Computers, klikneme pravým tlačítkem na jméno domény, pomocí Change Domain Controller se připojíme k DC, kterému chceme předat roli a pomocí Operations Master, přepnutí na záložku Infrastructure a tlačítka Change můžeme změnit držitele role.

Nastavení Global Catalog (GC)

Pokud jsme při instalaci nenastavili DC jako GC, tak můžeme nastavit pomocí Active Directory Sites and Services, kde se proklikáme přes odpovídající Site na hledaný DC a pod ním klikneme pravým tlačítkem na NTDS Settings a zvolíme Properties. Na záložce General zatrhneme položku Global Catalog.

NTP (Network Time Protocol)

Když přesuneme Operations Master role, hlavně PDC Emulator, tak na tomto doménovém řadiči musíme nastavit zdroj času (nejčastěji) z internetu. Ostatní DC synchronizují čas právě s držitelem této role, klientské stanice používají svůj doménový řadič.

Na původním řadiči si můžeme vypsat nastavení pomocí:

w32tm /query /configuration

Nastavení můžeme provést (v příkladu je použit NTP server tik.cesnet.cz):

w32tm /config /manualpeerlist:tik.cesnet.cz /syncfromflags:manual /reliable:yes /update

Pokud potřebujeme otestovat NTP na nějakém serveru:

w32tm /stripchart /computer:tik.cesnet.cz

Pokud potřebujeme změnit nastavení dřívějšího PDC, tedy nastavit server, aby se synchronizoval s DC:

w32tm /config /syncfromflags:domhier /update

Povýšení funkčního stupně (Raise Functional Level)

Ve chvíli, kdy jsme migrovaly všechny doménové řadiče, se můžeme pustit do zvýšení stupně funkčnosti domény a lesa. Funkční stupeň domény a lesa nám určuje vlastnosti, které Active Directory Domain Services nabízí. Stručný výčet je v článku Understanding Active Directory Domain Services (AD DS) Functional Levels. Pokud na všech doménových řadičích v AD DS doméně běží nová verze Windows Server, můžeme povýšit úroveň funkčnosti domény na stejnou verzi jako OS. Pokud na všech doménových řadičích v AD DS lese běží nová verze Windows Server, můžeme povýšit úroveň funkčnosti lesa na stejnou verzi jako OS.

Oficiální popis ke zvýšení úrovně funkčnosti domény a lesa je v článcích Raise the Domain Functional Level a Raise the Forest Functional Level.

Povýšení domény

Musíme provádět s právy Domain Admins nebo Enterprise Admins.

• pomocí Active Directory Domains and Trust
• klikneme pravým tlačítkem na doménu
• zvolíme Raise domain functional level
• vybereme Windows Server 2012 R2 a klikneme Raise

Povýšení lesa

Musíme provádět s právy Enterprise Admins.

• pomocí Active Directory Domains and Trust
• klikneme pravým tlačítkem na Active Directory Domains and Trust
• zvolíme Raise Forest Functional Level
• vybereme Windows Server 2012 R2 a klikneme Raise

Active Directory Certificate Services (AD CS)

Trochu bokem ještě doplním určitý popis převodu certifikační autority (CA). Když jsem se snažil o migraci CA ze serveru 2003 na 2008, tak jsem neuspěl. Dnes již vím, že proto, že jsem měnil jméno serveru, a v tom případě je třeba manuálně upravit řadu konfigurací. Určitě je lepší zachovávat jméno serveru při migraci AD CS. Dnešní oficiální dokumentace je již také mnohem lepší než dříve.

Migrace certifikační autority bývá problematická, pokud se do ní chceme pustit, tak se doporučuje zachovat jméno serveru (tedy nejprve musíme odinstalovat CA, odstranit či přejmenovat server, nový server pojmenovat stejně jako původní). Rozhodl jsem se tedy, že na původním DC, kde běží CA, zachovám tuto jedinou funkci (abych nemusel provádět migraci) a vše ostatní odstraním. Ovšem při odebírání AD DS jsem narazil na problém, že není možno zrušit funkci doménového řadiče, pokud na něm běží CA. Nejprve se musí odebrat AD CS, pak můžeme odebrat AD DS.

Rozhodl jsem se tedy stále zachovat původní server a provést následující kroky (což vše proběhlo bez chyb). Provést zálohu CA, odebrání role AD CS, následně odebrání AD DS, opětovnou instalaci AD CS a obnovu zálohy. Tedy takový lehce zjednodušený proces migrace. Následující kroky popisují kompletní zálohu, včetně věci, které v tomto specifickém případě nebudeme obnovovat.

Oficiální popis je již slušně napsaný Active Directory Certificate Services Migration Guide, další informace nalezneme třeba v Disaster Recovery Procedures for Active Directory Certificate Services (ADCS) a Step-By-Step: Migrating The Active Directory Certificate Service From Windows Server 2003 to 2012 R2.

Bokem zde uvedu odkaz na článek Mirka Knotka PKI – přecházíme na SHA-2, který popisuje jednoduchou metodu, jak přepnout vydávání certifikátů z SHA1 na SHA256. Jelikož v roce 2016 budou často certifikáty s SHA1 označovány za nebezpečné a v roce 2017 úplně nepodporované, tak jde o aktuální téma.

Záloha AD CS

Kompletní záloha certifikačních služeb se skládá z řady kroků.

Backing up a CA templates list

Poznamenáme si seznam povolených certifikačních šablon (třeba print screen z konzole).

Myslím, že se také hodí poznamenat instalované vlastnosti role AD CS.

Pouze pro jistotu si také můžeme poznamenat umístění CDP a AIA, pomocí AD CS konzole otevřeme Enterprise PKI a proklikáme se na naši CA.

Recording a CA's signature algorithm and CSP

Uložíme údaje o algoritmu podpisu CA a CSP.

certutil.exe -getreg ca\csp\* > csp.txt

Backing up a CA database and private key

Provedeme zálohu CA pomocí konzole. Pravým tlačítkem klikneme na naši CA a zvolíme All Tasks - Back up CA, zadáme cestu do složky a heslo, kterým se ochrání soubor s certifikátem CA (obsahuje i privátní klíč).

Nyní bychom měli CA zastavit a odinstalovat!

Backing up CA registry settings

Pomocí regedit zazálohujeme (exportujeme) registry v následující cestě HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration.

Backing up CAPolicy.inf

Pokud používáme upravený soubor C:\Windows\CAPolicy.inf, tak jej zkopírujeme do zálohy.

Removing the CA role service from the source server

Než nainstalujeme CA na nový server (nebo v našem případě opět na tento po odinstalaci AD DS), tak musíme odebrat roli CA. Enterprise CA ukládá svoje konfigurační data do AD DS a jsou svázána s common name CA. Když odebereme CA roli ze serveru, tak se neodstraní CA databáze, privátní klíč a certifikát. V případě problémů tedy můžeme opět přidat CA roli na server a obnovit jeho činnost, což je vlastně náš případ.

Obnova AD CS

Adding the CA role service to the destination server

Přidáme novou roli Active Directory Certificate Services, typ Enterprise, v kroku Set Up Private Key zvolíme Use existing private key a Select a certificate and use its associated private key. Měl by se nám nabídnout náš certifikát (protože se při odinstalaci nesmazal). Dokončíme instalaci.

Restoring the CA database and configuration on the destination server

Provedeme obnovu CA pomocí konzole. Pravým tlačítkem klikneme na naši CA a zvolíme All Tasks - Restore CA, nejprve dojde k zastavení služeb, jako položku k obnově zatrhneme pouze Certificate database and certificate database log, zvolíme složku, kde je uložena záloha. Provedeme obnovu a nastartování služeb.

Provedeme zálohu aktuálního stavu registrů v cestě HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration. A obnovíme registry exportované na původním serveru. Restartujeme službu CA.

Můžeme ještě ověřit, že jsou v pořádku umístění CDP a AIA a korektně se načítají.

Posledním krokem obnovy je Restoring the certificate templates list, tedy povolení certifikačních šablon. Klikneme pravým tlačítkem na Certificate Templates, zvolíme New - Certificate Template to Issue a vybereme naše používané šablony.

Verifying the Migration

Můžeme manuálně vydat CDP, klikneme pravým tlačítkem na Revoked Certificates a zvolíme Publish, a zkontrolovat.

Zkusíme vystavit jeden nebo více certifikátů z našich šablon. Klasickou kontrolou je také zkontrolování událostí pomocí Event Viewer pro roli AD CS.

Některé chyby z průběhu migrace

Již od začátku, tedy kontroly domény a řadičů, jsem narazil na různé menší chyby. Pár jich zde stručně zmíním.

DCdiag a RODCprep

Při použití DCdiag se v části NCSecDesc zobrazí chyba:

Error NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS doesn't have Replicating Directory Changes In Filtered Set access rights
 for the naming context

Je to z důvodu, že nebyl proveden adprep /rodcprep. Chybu můžeme ignorovat nebo provést adprep, popis Dcdiag fails for NCSecDesc test on Windows 2008 Domain Controllers.

Certifikát ze šablony Kerberos Authentication

Na novém řadiči najdeme v logu událostí chybu Kerberos-Key-Distribution-Center, Event ID: 32:

The Key Distribution Center (KDC) uses a certificate without KDC Extended Key Usage (EKU) which can result in authentication
 failures for device certificate logon and smart card logon from non-domain-joined devices. Enrollment of a KDC certificate
 with KDC EKU (Kerberos Authentication template) is required to remove this warning.

Existuje nová šablona CA s názvem Kerberos Authentication a doporučuje se, aby DC měl vystaven certifikát z této šablony místo starší Domain Controller. Nějaké info je v článku Configure Windows Logon With An Electronic Identity Card (EID).

Autentizace pomocí NPS selhává

Autentizace WiFi klientů pomocí RADIUSu s PEAP selhává. Loguje se chyba Network Policy Server denied access to a user, která obsahuje důvod:

Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user
 account or the password was incorrect.

Uživatelské údaje jsou v pořádku, problém se našel v certifikátu na serveru. V politice NPS v Constraints - Authentication Methods je použit protokol PEAP a zde se automaticky nastavil certifikát ze šablony Kerberos Authentication místo Domain Controller. Po změně certifikátu začalo vše fungovat. Určitá zmínka je v článku Windows NAP as RADIUS in a Windows 7 Server 2012 Wireless World.

Problém s veřejnými složkami na Exchange serveru

Problém, který by asi neměl souviset se změnou doménového řadiče, ale mně se objevil právě ve chvíli přidání nového DC. Poštovní zprávy zasílané do Public Folder se nedoručí a vrací NDR (Non-Delivery Report).

#554 5.2.0 STOREDRV.Deliver.Exception:ObjectNotFoundException; Failed to process message due to a permanent exception with
 message The Active Directory user wasn't found. ObjectNotFoundException: The Active Directory user wasn't found. ##

Problém vznikl v situaci, kdy byl v prostředí Microsoft Exchange Server 2003 migrován na Microsoft Exchange Server 2007 a novější. A v konfiguraci AD pod First Administrative Group zůstal prázdný kontejner Servers. Řešením je tento kontejner smazat (pozor, celá administrativní skupiny, i když je prázdná, se smazat nesmí). Použijeme adsiedit a cestu:

Configuration Container - CN=Configuration,DC=DomainName,DC=local - CN=Services - CN=Microsoft Exchange -
 CN=OrganizationName - CN=Administrative Groups - CN=First Administrative Group - CN=Servers

Možnost smazání (z jiného důvodu) uvádí Microsoft i ve svém KB When trying to replicate the public folder content to Microsoft Exchange Server 2010 it will not replicate, další informace Public Folder Replication Fails Due To Empty Legacy Administrative Group či diskuze When sending e-mail messages to a mail-enabled public folder that have been replicated from old Exchange Server 2000/2003/2007, Exchange Server 2010 environment mails are rejected with NDR.