Issues durante upgrade in-place di Domain Controller a Windows Server 2016

L’upgrade in-place, a mio avviso, è un approccio che è preferibile evitare se possibile in particolare nel caso di un Domain Controller dove la migrazione ad una versione di sistema operativo successivo si risolve semplicemente installando nuovi Domain Controller, ad esempio virtuali, e dismettendo i precedenti.

Nel caso in cui vi sia però la necessità di eseguire un upgrade in-place di un Domain Controller a Windows Server 2016 occorre tenere presente che possono verificarsi due issue.

Issue 1: Servizio Netlogon impostato per l’avvio manuale anziché automatico

Eseguendo l’upgrade in-place di Domain Controller Windows Server 2012 o Windows Server 2012 R2 a Windows Server 2016 il servizio Netlogon non viene impostato per l’avvio automatico con la conseguenza che se si riavvia il Domain Controller la mancata esecuzione del servizio Netlogon causa una serie di problematiche alle funzionalità che dipendono da tale servizio.

A riguardo si veda la KB3201247 Netlogon service doesn’t retain settings after upgrade to Windows Server 2016:

Assume that you have one or more computers that are running Windows Server 2012 or Windows Server 2012 R2 and configured as domain controllers or member servers in an Active Directory domain. You decide to upgrade the domain controllers to Windows Server 2016.
After you upgrade the domain controllers, you notice that one or more of the following symptoms occur:

1. User logon failures
2. SID to name translation fails in object picker UIs
3. RDP connection failures
4. DNS SRV resource record registration failures
5. The firewall profile on member servers and workstations fails to select the domain profiled

This issue occurs because the upgrade process doesn’t set the startup value for the Netlogon service type to Automatic on the upgraded server. When the Netlogon service is not running, a domain controller doesn’t advertise itself as a domain controller, and all the other functionality and dependencies of the Netlogon service fail. Any service that depends on Netlogon to be running also fails.

Come riportato nella KB3201247 per risolvere l’issue occorre impostare il servizio Nellogon per l’avvio Automatico e controllare che i servizi che dipendono da Netlogon siano avviati e correttamente registrati sulla rete, quindi anche se non è richiesto è consigliabile riavviare il sistema dopo la configurazione dell’avvio automatico del servizio Netlogon.

Issue 2: Mancata sincronizzazione oraria del PDC con un NTP esterno

Eseguendo l’upgrade in-place di Domain Controller Windows Server 2012 o Windows Server 2012 R2 a Windows Server 2016 se il Domain Controller che esegue il ruolo di PDC era impostato con la sincronizzazione oraria con un NTP esterno, come da best practices, la sincronizzazione non avrà più luogo.

Questo dipende dal fatto che le impostazioni del registro di sistema relative al servizio Windows Time non sono mantenute nei seguenti scenari di upgrade in-place:

• Migrazione da Windows Server 2012 o Windows Server 2012 R2 verso Windows Server 2016
• Migrazione da Windows 7, Windows 8 o Windows 8.1 verso Windows 10 versione 1607

Questo significa che non saranno solo i Domain Controller che detengono il ruolo FSMO PDC ad essere interessati da questo issue, ma anche i computer membri di dominio e i computer configurati come Authoritative Time Server.

A riguardo si veda la KB3201265 Windows Time Service settings are not preserved during an in-place upgrade to Windows Server 2016 or Windows 10 Version 1607:

This issue occurs because the registry values for the Windows Time service are not preserved during an upgrade. Therefore, all Windows Time service values are reverted to the default state of a Workgroup Member Server or a stand-alone computer.

Domain controllers
The domain controllers (DC) that hosts the PDC emulator role is the default authoritative time server for the domain. Typically, it is configured to sync with a highly accurate time source. All other DCs in the domain sync their time with the PDC.
After you do an in-place upgrade, the PDC loses its connection to the external time server that it is configured to sync with. It also no longer announces that it is a time server.
Also, all other DCs in the domain no longer announce they are time servers, and they no longer use the domain hierarchy to sync their time. Therefore, their time setting may no longer be in sync with the setting for their peers, and domain members can no longer sync their time.

Domain Members
Domain member servers and computers that are upgraded are no longer configured to use the domain hierarchy to synchronize their time. Instead, they will sync their time with the “time.windows.com” website.

Authoritative Time Server
Windows computers that are manually configured as an Authoritative Time Server lose their configuration. Therefore, devices that are configured to use these computers to synchronize their time may not sync.

Come riportato nella KB3201265 per risolvere l’issue è possibile utilizzare 3 workaround:

Metodo 1: Prima di eseguire l’upgrade in-place eseguire il backup dei valori del registro di sistema relative al servizio Windows Time memorizzate ed eseguire il restore di tali valori dopo l’upgrade in-place, per dettagli si veda la KB3201265.

Metodo 2: Eseguire il ripristino dei valori di default del servizio Windows Time in base al ruolo del computer, questo metodo può essere utile nel caso di computer membri di dominio. Per resettare ai valori il servizio Windows Time eseguire i seguenti comandi come indicato nella  KB3201265:

net stop w32time
w32tm.exe /unregister
w32tm.exe /register
net start w32time

Metodo 3: Eseguire il restore delle impostazioni del servzio Windows Time dalla directory Windows.old, per dettagli si veda la KB3201265.