Vuoi mantenere l’Active Directory operativa in due sedi diverse? Con un DC Windows Server 2012 R2 e un server Windows Server 2019 Essentials, la strada non è banale: Essentials non può fungere da replica accanto a un altro DC. In questa guida trovi il percorso corretto, passo‑passo, per ottenere vera ridondanza.

Scenario e obiettivo

Ambiente attuale

• Server A: Windows Server 2012 R2, già domain controller (AD DS) funzionante nel sito principale.
• Server B: Windows Server 2019 Essentials, in un secondo sito (oggi usato come laboratorio), membro della stessa rete aziendale via WAN/VPN.

Obiettivo: ottenere una seconda copia dell’Active Directory su Server B, in modo da:

• amministrare il dominio da entrambi i server;
• garantire continuità di autenticazione anche in caso di indisponibilità del sito principale o della WAN.

Prerequisito chiave: i limiti di Windows Server 2019 Essentials

L’edizione Windows Server 2019 Essentials impone restrizioni molto stringenti sul ruolo di controller di dominio: se viene promossa a DC, deve essere l’unico DC dell’intero dominio e detenere tutti i ruoli FSMO. Non è supportata la coesistenza con altri DC né l’uso in domini con trust bidirezionali.

Conseguenza pratica: non è possibile affiancare a Server A (2012 R2) un secondo DC in replica usando l’edizione Essentials. Server B può quindi:

• restare member server (gestione remota del dominio tramite RSAT/PowerShell), oppure
• essere convertito/reinstallato con Windows Server Standard o Datacenter e solo allora promosso a DC replica.

Questa condizione è il vero “blocco stradale” del progetto: per avere due DC in due sedi serve necessariamente Windows Server Standard/Datacenter sul secondo server (o una VM con tale edizione).

Percorsi di soluzione a confronto

Scenario	Passaggi principali	Note critiche
A. Aggiornare Server B a Windows Server Standard (opzione consigliata)	Procurare la licenza Standard (o predisporre una VM Standard su Server B). Installare il ruolo Active Directory Domain Services. Dal wizard scegliere Add a domain controller to an existing domain (replica). Abilitare il DNS integrato e il Global Catalog. Creare due siti AD e un site‑link adeguando intervallo/costo di replica (tipico 180 min su WAN). Stabilire una VPN/IPSec tra le sedi; aprire le porte necessarie (53/88/123/135/389/445/636/3268/3269/9389 e range RPC dinamici). Validare con repadmin, dcdiag ed Event Viewer.	Offre autenticazione locale e ridondanza completa. Richiede banda affidabile e backup regolari su entrambi i DC.
B. Tenere Essentials solo come member server	Unire Server B al dominio come member server. Installare RSAT o usare PowerShell/ADAC per gestire da remoto Server A. Potenziare il piano di backup System State di Server A e, se possibile, una replica off‑site del VHD.	Semplice ma non garantisce autenticazione locale se Server A o la WAN cadono: nessuna ridondanza reale.
C. Spostare tutto l’AD su Server B (Essentials)	Promuovere Server B a DC (Essentials). Trasferire o seize tutti i ruoli FSMO. Demotare Server A e rimuoverlo dal dominio.	Valido solo se si accetta di avere un solo DC e i limiti di Essentials (25 utenti/50 device). Non fornisce ridondanza.

Guida operativa completa per l’opzione consigliata

Di seguito i passaggi dettagliati per aggiornare Server B a Standard (o predisporre una VM Standard) e promuoverlo a domain controller replica in un secondo sito.

Checklist pre‑requisiti

• Salute dell’AD esistente su Server A:
  • dcdiag /v senza errori critici.
  • repadmin /replsummary con esiti 0 fails.
  • Nessun evento critico su Directory Service/DNS/File Replication.
• Livelli funzionali di forest e domain almeno Windows Server 2008 o superiori (tipicamente 2012 R2): i DC 2019 richiedono SYSVOL in DFSR, non FRS.
• SYSVOL in DFSR:
  • Verifica rapida: presenza del servizio NtFrs non attivo per SYSVOL e cartella C:\Windows\SYSVOL\domain sincronizzata.
  • Comando di controllo: dfsrmig /getglobalstate → atteso State 3 (Eliminated). In caso contrario, eseguire migrazione FRS→DFSR con dfsrmig /setglobalstate 1/2/3 attendendo la convergenza ad ogni step.
• Connettività affidabile tra sedi (site‑to‑site VPN/IPSec o MPLS) e DNS name resolution bidirezionale.
• Sincronizzazione oraria:
  • Il PDC Emulator del dominio deve sincronizzarsi con NTP esterno affidabile.
  • Gli altri DC si sincronizzano a cascata dalla gerarchia di dominio.
• Backup: eseguire un System State backup recente di Server A e un backup dell’intero sistema/VM.
• IP statico su Server B e routing stabile.
• Antivirus: predisporre esclusioni per cartelle e processi AD DS/DFSR/DNS (database NTDS, cartella SYSVOL, log).

Rete e firewall: porte da aprire

Per la replica AD e i servizi correlati, assicurarsi che tra i due siti siano consentite le seguenti porte (TCP/UDP):

Servizio	Porte	Note
DNS	53 TCP/UDP	Zone AD‑integrate, lookup SRV.
Kerberos	88 TCP/UDP	Autenticazione.
NTP	123 UDP	Sincronizzazione tempo.
RPC Endpoint Mapper	135 TCP	Necessario per RPC dinamico.
LDAP / LDAPS	389 TCP/UDP, 636 TCP	LDAP e LDAP su TLS.
SMB	445 TCP	SYSVOL/NETLOGON e replica DFSR.
Global Catalog	3268 TCP, 3269 TCP	Ricerca oggetti/UGM.
AD Web Services	9389 TCP	RSAT/PowerShell AD.
RPC dinamico	49152–65535 TCP/UDP	Intervallo predefinito su Windows moderni. Evitare NAT restrittivi.

Consiglio: dove possibile, permettere traffico intra‑sito DC↔DC senza ispezioni applicative; l’RPC dinamico è spesso la causa di repliche bloccate quando i firewall limitano le porte alte.

Definizione di siti e subnet in Active Directory

1. Aprire Active Directory Sites and Services.
2. Creare due siti (es. Sede-Principale e Sede-Remota) con i relativi subnet object (es. 10.10.0.0/24 e 10.20.0.0/24) assegnati ai siti.
3. Creare un site‑link dedicato (es. WAN-Link), impostando:
   • Cost maggiore rispetto ai link intra‑LAN (es. 200 o 500).
   • Intervallo di replica: tipico 180 min; ridurlo (es. 60 min) se la WAN è stabile e si desidera una convergenza più rapida.
   • Schedule: default Always; restringerlo solo se la banda è critica.

In questo modo KCC/ISTG calcolano topologia e percorsi di replica consapevoli del sito, minimizzando traffico inutile sulla WAN e garantendo che gli utenti si autentichino sul DC locale.

Installare AD DS su Server B (edizione Standard/Datacenter)

Metodo GUI (Server Manager): aggiungere ruolo Active Directory Domain Services, quindi Promote this server to a domain controller → Add a domain controller to an existing domain.

Metodo PowerShell (consigliato per ripetibilità):

# 1) Installazione del ruolo con strumenti di gestione
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools

2) Promozione a DC aggiuntivo nel dominio esistente

Install-ADDSDomainController `  -DomainName "contoso.local"`
-SiteName "Sede-Remota" `  -InstallDns`
-Credential (Get-Credential) `  -DatabasePath "C:\Windows\NTDS"`
-LogPath "C:\Windows\NTDS" `  -SysvolPath "C:\Windows\SYSVOL"`
-NoRebootOnCompletion:\$false </code></pre>

<p>Durante il wizard specificare:</p>
<ul>
  <li><strong>Domain Admin</strong> per le credenziali.</li>
  <li><strong>DSRM password</strong> sicura e archiviata.</li>
  <li><strong>Global Catalog</strong> spuntato (consigliato per ogni DC non‑RODC).</li>
  <li><strong>DNS integrato in AD</strong> (replica “tutti i DC nel dominio”).</li>
</ul>

<h3>Validare la promozione e la replica</h3>
<p>Dopo il riavvio, verificare:</p>
<ul>
  <li><strong>Annuncio come DC</strong>: condivisioni <code>SYSVOL</code> e <code>NETLOGON</code> presenti (<code>\\ServerB\SYSVOL</code>).</li>
  <li><strong>Replica</strong>:
    <pre><code>repadmin /replsummary
repadmin /showrepl
repadmin /showconn * /all /intersite
dcdiag /v

Eventi in ordine: Directory Service/DNS/DFS Replication senza errori ripetitivi.
Global Catalog attivo:

Get-ADForest | Select-Object -ExpandProperty GlobalCatalogs

DNS: progettazione e best practice

• Usare zone AD‑integrate replicando su tutti i controller di dominio nel dominio.
• Configurare i client della Sede‑Remota con DNS primario il DC locale (Server B) e secondario il DC remoto (Server A). Viceversa nella Sede‑Principale.
• Nei DC, impostare come Preferred DNS se stessi e come Alternate l’altro DC (evita dipendenze circolari di avvio).
• Mai usare DNS pubblici sulle NIC dei DC.

Distribuzione dei ruoli FSMO

È possibile lasciare tutti i ruoli su Server A, soprattutto se la Sede‑Principale rimane il centro nevralgico. In alternativa, spostare alcuni ruoli su Server B (es. Infrastructure se i RID Master e PDC Emulator restano dove la maggior parte degli oggetti nasce). Per spostare i ruoli via PowerShell:

Move-ADDirectoryServerOperationMasterRole `
  -Identity "ServerB" `
  -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster

Nota: valutare latenza WAN e resistenza ai guasti prima di distribuire i ruoli in siti diversi. Il PDC Emulator beneficia della sede con la miglior connettività/affidabilità.

Backup e recovery dei controller di dominio

• Pianificare System State backup su ogni DC (Windows Server Backup o soluzione enterprise), con conservazione off‑site.
• Testare periodicamente il ripristino non‑authoritative del database NTDS e, quando serve, le procedure di authoritative restore di OU/oggetti (o usare il Cestino AD se abilitato).
• Documentare la procedura di seize FSMO per emergenze gravi.

Hardening e igiene operativa

• Applicare le baseline di sicurezza per DC; disabilitare SMBv1; limitare l’accesso RDP; usare Windows LAPS per gli account locali.
• Firmare e crittografare LDAP (LDAPS) con certificati validi; rimuovere protocolli legacy.
• Monitorare regolarmente:
  • repadmin, dcdiag
  • Event ID tipici: 1988 (lingering objects), 2089 (tombstone lifetime), 4602 (DFSR inizializzato)

Variante: mantenere Essentials come member server

Se l’aggiornamento a Standard non è al momento possibile, mantenere Server B come member server consente comunque di gestire AD da remoto:

1. Unire Server B al dominio (System → About → Domain join).
2. Installare RSAT (gli strumenti di amministrazione remota) o utilizzare Windows Admin Center/PowerShell per amministrare Server A.
3. Concentrarsi su:
   • Backup System State frequenti di Server A (idealmente giornalieri).
   • Replica off‑site delle VM/backup del DC (cifrata) per ripartenza rapida.

Questa opzione non offre autenticazione locale alla Sede‑Remota in caso di guasti a WAN o Server A.

Variante: spostare l’unico DC su Server B con Essentials

È tecnicamente possibile promuovere Server B (Essentials) a unico DC, trasferire/seize tutti i ruoli FSMO e demotare Server A. Tuttavia si resta con un solo DC totale e le limitazioni proprie di Essentials (plateau utenti/device, assenza di trust, vincoli di ruolo). Non è ridondante: un guasto al Server B interromperebbe l’autenticazione.

Controlli post‑implementazione

• Accesso utenti: dalla Sede‑Remota, gli utenti si autenticano anche quando il link WAN è disattivato (test pilot con account di prova).
• Preferenza DC locale: verificare con echo %logonserver% (client Windows) che il logon avvenga sul DC del sito.
• Repliche: eseguire ciclicamente repadmin /replsummary e controllare l’assenza di errori.
• DNS: creare un record di prova e verificare la replicazione tra le due sedi.
• GPO: creare/modificare una GPO; verificare che SYSVOL sia aggiornato in entrambi i DC (\\ServerA\SYSVOL vs \\ServerB\SYSVOL).
• Failover: simulare indisponibilità di Server A o della WAN e assicurarsi che i servizi locali (file/print/app) restino accessibili grazie all’AD locale.

FAQ rapide

Posso “forzare” Essentials a convivere come DC replica?
No: la coesistenza con altri DC non è supportata. Il percorso corretto è usare Windows Server Standard/Datacenter per i DC.

Meglio due DC scrivibili o un RODC in sede remota?
Se la sede remota è fisicamente esposta o poco presidiata, valutare un RODC (Read‑Only DC). Offre caching delle credenziali e riduce il rischio in caso di compromissione fisica. Richiede comunque edizione Standard/Datacenter.

Serve davvero il Global Catalog su entrambi i DC?
Sì: abilitarlo su ogni DC semplifica la risoluzione dei gruppi universali e riduce la dipendenza inter‑sito nelle autenticazioni.

Qual è l’impatto su banda WAN?
La creazione del primo DC replica trasferisce il database AD e SYSVOL (diversi centinaia di MB a seconda dell’ambiente). In esercizio, il traffico è modesto e gestibile con site‑link cost/interval e con la pianificazione DFSR.

Che cosa devo fare se la promozione su 2019 fallisce per SYSVOL/FRS?
Eseguire la migrazione FRS→DFSR con dfsrmig fino a Eliminated, attendendo la convergenza (dfsrmig /getmigrationstate), poi ripetere la promozione.

Posso spostare nel tempo i ruoli FSMO verso il DC della sede remota?
Sì, ma farlo solo con repliche sane e latenza prevedibile; documentare un piano di rollback. Mantenere il PDC Emulator dove vive la maggior parte delle operazioni di scrittura e le origini del tempo.

Appendice: comandi utili

# Stato della replica e salute DC
repadmin /replsummary
repadmin /showrepl
dcdiag /v

Elenco Global Catalog

Get-ADForest | Select-Object -ExpandProperty GlobalCatalogs

Verifica site e subnet

Get-ADReplicationSite -Filter \*
Get-ADReplicationSubnet -Filter \*

Spostamento FSMO (tutti i ruoli)

Move-ADDirectoryServerOperationMasterRole -Identity "ServerB" -OperationMasterRole 0,1,2,3,4

Migrazione SYSVOL da FRS a DFSR

dfsrmig /setglobalstate 1   # Prepared
dfsrmig /getmigrationstate
dfsrmig /setglobalstate 2   # Redirected
dfsrmig /getmigrationstate
dfsrmig /setglobalstate 3   # Eliminated
dfsrmig /getmigrationstate 

Buone prassi trasversali

• Mantenere almeno due DC per dominio in siti diversi: riduce in modo drastico il rischio di perdita dell’AD.
• Creare subnet e site‑link correttamente mappati per controllare la replica su WAN e ottimizzare il logon locale.
• Usare DNS integrato in AD su entrambi i DC; i client puntano al DNS del sito locale come primario.
• Eseguire backup System State regolari su ogni DC e testare il ripristino.
• Monitorare costantemente repadmin, dcdiag e gli Event ID chiave (4602/1988/2089) per rilevare problemi prima che diventino incidenti.

Raccomandazione finale

Per ottenere davvero “due server che condividono la stessa Active Directory” su siti diversi, è indispensabile che il secondo server esegua Windows Server Standard/Datacenter. Solo così è possibile promuoverlo a DC replica e ottenere:

• autenticazione locale in ogni sito, anche con WAN fuori servizio o con il sito principale indisponibile;
• gestione AD da qualunque DC e convergenza rapida delle modifiche;
• aderenza alle buone prassi Microsoft evitando i limiti di Essentials.

Se il budget non consente subito l’upgrade, mantenere Server B come member server e rinforzare seriamente backup e piani di ripristino del DC primario, consapevoli però che così non si ottiene ridondanza dell’autenticazione.

---

Di seguito trovi una lista d’azione sintetica per l’opzione consigliata (da usare come checklist operativa):

1. Verifica salute AD su Server A (dcdiag, repadmin), backup aggiornati, SYSVOL=DFSR.
2. Prepara connettività sicura tra sedi (VPN/IPSec) e apri le porte elencate.
3. Definisci siti, subnet e site‑link (costo/interval/schedule) in Sites & Services.
4. Aggiorna Server B a Windows Server Standard/Datacenter (o crea una VM con tale edizione).
5. Installa AD DS e promuovi Server B come DC aggiuntivo con DNS e Global Catalog.
6. Valida replica e DNS; reindirizza i client del sito remoto al DNS locale come primario.
7. Valuta (non obbligatorio) la riallocazione dei ruoli FSMO.
8. Pianifica backup System State su entrambi i DC; monitora eventi e repliche.

Con questa architettura, il dominio resta disponibile anche con un sito isolato: gli utenti locali continuano a lavorare, le GPO si applicano, le applicazioni che dipendono da AD non si fermano.