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 /vsenza errori critici.repadmin /replsummarycon 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
NtFrsnon attivo per SYSVOL e cartellaC:\Windows\SYSVOL\domainsincronizzata. - Comando di controllo:
dfsrmig /getglobalstate→ atteso State 3 (Eliminated). In caso contrario, eseguire migrazione FRS→DFSR condfsrmig /setglobalstate 1/2/3attendendo la convergenza ad ogni step.
- Verifica rapida: presenza del servizio
- 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
- Aprire Active Directory Sites and Services.
- Creare due siti (es.
Sede-PrincipaleeSede-Remota) con i relativi subnet object (es.10.10.0.0/24e10.20.0.0/24) assegnati ai siti. - 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 GlobalCatalogsDNS: 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:
- Unire Server B al dominio (System → About → Domain join).
- Installare RSAT (gli strumenti di amministrazione remota) o utilizzare Windows Admin Center/PowerShell per amministrare Server A.
- 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 /replsummarye 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
SYSVOLsia aggiornato in entrambi i DC (\\ServerA\SYSVOLvs\\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,dcdiage 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):
- Verifica salute AD su Server A (
dcdiag,repadmin), backup aggiornati, SYSVOL=DFSR. - Prepara connettività sicura tra sedi (VPN/IPSec) e apri le porte elencate.
- Definisci siti, subnet e site‑link (costo/interval/schedule) in Sites & Services.
- Aggiorna Server B a Windows Server Standard/Datacenter (o crea una VM con tale edizione).
- Installa AD DS e promuovi Server B come DC aggiuntivo con DNS e Global Catalog.
- Valida replica e DNS; reindirizza i client del sito remoto al DNS locale come primario.
- Valuta (non obbligatorio) la riallocazione dei ruoli FSMO.
- 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.