Attivazione Windows in reti con due domini: strategia ADBA, KMS e MAK per Windows Server 2022 e Windows 11

Obiettivo: attivare in modo affidabile 23 server Windows Server 2022, 8 workstation Windows 11 di dominio e 8 laptop in workgroup in un’infrastruttura con due domini, scegliendo consapevolmente fra ADBA, KMS e MAK per ridurre effort, rischi e costi operativi.

Indice

Scenario e obiettivo

L’ambiente conta due domini distinti con 31 computer uniti al dominio (23 server Windows Server 2022 e 8 client Windows 11) più 8 laptop in workgroup (non membri di dominio). L’obiettivo è progettare un modello di attivazione scalabile, sicuro e semplice da gestire, minimizzando interventi manuali e mantenendo margini per future espansioni.

Sintesi esecutiva

Server e client di dominio → ADBA (Active Directory–Based Activation): nessuna soglia minima, attivazione trasparente e automatica al contatto con AD.
Laptop in workgroup → MAK (Multiple Activation Key): ideali per endpoint isolati e senza requisiti di soglia.
KMS opzionale per i soli server: la soglia di 5 è raggiunta (23 server), ma non è necessaria se si adotta ADBA per i server. Utile se si preferisce separarli o si hanno policy che richiedono KMS.
Quando passare a KMS per i client: solo quando il totale Windows 10/11 (dominio + workgroup) sarà ≥ 25.

Confronto rapido dei metodi

Metodo	Requisiti	Copertura
ADBA	Computer membri di dominio; nessuna soglia minima. Richiede la pubblicazione dell’oggetto di attivazione in AD.	Attiva in automatico ogni volta che il dispositivo contatta Active Directory.
KMS	≥ 5 richieste da server per attivare i server; ≥ 25 richieste da client (Windows 10/11) per attivare i client. Funziona anche senza join al dominio purché raggiungano l’host KMS.	Adatto a reti con molti dispositivi e connettività verso l’host KMS (porta 1688/TCP).
MAK	Nessuna soglia; attivazione singola con Microsoft (diretta o tramite proxy con VAMT).	Perfetto per endpoint isolati, remoti o in numero ridotto.

Nota: le soglie KMS sono separate: soddisfare quella dei server non avvia l’attivazione dei client in automatico.

Analisi dell’ambiente

Domini: 31 computer (23 server + 8 client) → ADBA possibile e consigliata.
Workgroup: 8 laptop → non idonei ad ADBA. Con KMS, il totale client (8 dominio + 8 workgroup = 16) resta < 25 → nessuna attivazione client via KMS.

Perché KMS non basta per i client

Il contatore KMS per i client Windows 10/11 necessita di almeno 25 richieste univoche (CMID distinti) negli ultimi cicli di reporting per “sbloccarsi”. Con soli 16 client, l’attivazione non parte; i client restano in grace finché la soglia non viene superata. Per i server, la soglia è 5 ed è ampiamente superata (23 server).

Architettura raccomandata

ADBA per tutti i membri di dominio (server e client): installare il ruolo Volume Activation Services (VAS) in ciascun dominio e pubblicare gli Activation Objects in AD. Così ogni macchina di dominio si attiva/si rinnova automaticamente quando contatta AD.
MAK per i laptop in workgroup: attivazione puntuale e senza prerequisiti infrastrutturali. Monitorabile via VAMT per tenere traccia dei conteggi MAK.
KMS opzionale per i soli server: preferibile solo se avete processi o controlli che lo richiedono. In tal caso, evitare più host KMS per Windows nello stesso dominio per non “spezzare” la soglia tra host diversi.

Schema logico (semplificato):

[ Dominio A ]                        [ Dominio B ]
   DC-A1 (VAS/ADBA)                     DC-B1 (VAS/ADBA)
   DC-A2 (VAS/ADBA, ridondanza)         DC-B2 (VAS/ADBA, ridondanza)
   |                                     |
   |-- Server e client di dominio        |-- Server e client di dominio
       attivati via ADBA                     attivati via ADBA

[ Workgroup ]
   8 laptop → attivati via MAK (diretto o tramite VAMT)

[KMS - opzionale] 
   Se adottato solo per server: 1 host KMS centralizzato (porta 1688/TCP, SRV vlmcs.tcp)
   Attenzione a non distribuire più host KMS per la stessa famiglia di prodotti.

Prerequisiti sintetici

Licenze Volume valide e chiavi adeguate:
- CSVLK (KMS Host Key) per ADBA/KMS, da installare solo su VAS/KMS host.
- GVLK (KMS client setup key) preinstallate sui media Volume di Windows; utili se si deve riconvertire endpoint precedentemente attivati con MAK.
- MAK per i laptop in workgroup.
Active Directory: almeno un DC Windows Server 2012 o successivo in ciascun dominio in cui si intende usare ADBA (con schema adeguato). Nessun requisito di soglia.
DNS (solo KMS): record vlmcs.tcp e raggiungibilità porta 1688/TCP.
Permessi: per pubblicare l’oggetto di attivazione ADBA servono privilegi elevati (tipicamente Enterprise Admins nella foresta o equivalente a seconda della topologia).

Implementazione ADBA nei due domini

ADBA è la scelta predefinita per server e client di dominio. Automatizza attivazione e rinnovo (validità 180 giorni, con tentativi di rinnovo periodici mentre il computer è connesso al dominio).

Installazione del ruolo Volume Activation Services

Accedi a un Domain Controller del dominio.
Apri Server Manager → Add roles and features → Volume Activation Services.
Installa anche gli strumenti di gestione (Include Management Tools), che forniscono il wizard Volume Activation Tools.

In alternativa via PowerShell:

Install-WindowsFeature -Name VolumeActivation -IncludeManagementTools

Pubblicazione dell’Activation Object in AD

Dal DC con VAS, apri Volume Activation Tools.
Scegli Active Directory-Based Activation.
Quando richiesto, immetti la CSVLK appropriata (ad es. per Windows Server 2022 o Windows 10/11 Volume). Il wizard creerà l’Activation Object in AD.
Verifica la riuscita e la replica tra i DC del dominio.
Ripeti la procedura nel secondo dominio.

Riconversione dei client eventualmente MAK

Se qualche endpoint di dominio fosse stato attivato in precedenza con MAK, riconvertilo a GVLK per farlo usare ADBA/KMS:

slmgr /ipk &lt;GVLK-dell-edizione&gt;
slmgr /ato

Nota: le GVLK sono chiavi pubbliche specifiche per edizione (es. Pro, Enterprise, Server Standard, Datacenter). Usa quella corretta per l’edizione installata.

Verifica e forzatura dell’attivazione

Sui dispositivi di dominio: slmgr /ato per forzare; in alternativa, riavvio + accesso al dominio.
Controlla lo stato: slmgr /dli (sintetico) o slmgr /dlv (dettagliato).
Log eventi: Applications and Services Logs → Microsoft → Windows → Security-SPP (client) e Key Management Service (se usi un host KMS).

Gestione dei server con KMS (opzionale)

Se desideri separare i server con KMS (soglia ≥ 5 già soddisfatta), procedi così:

Designa un server come Host KMS.
Installa il ruolo VAS (come sopra) e avvia il wizard Volume Activation Tools.
Seleziona Key Management Service (KMS) e inserisci la CSVLK per l’host KMS (ad esempio per Windows Server 2022).
Completa l’attivazione dell’host verso Microsoft (slmgr /ato sull’host).
Verifica il record DNS SRV vlmcs.tcp (di norma creato automaticamente). In caso di DNS non integrato, crealo manualmente puntando all’host KMS (porta 1688).
Assicurati che i server target usino la GVLK corretta per la loro edizione; puoi forzarla con slmgr /ipk <GVLK-server> e poi slmgr /ato.

Comandi utili per test:

# Verifica DNS SRV del servizio KMS
nslookup -type=srv vlmcs.tcp

Test raggiungibilità porta 1688 sull'host KMS

Test-NetConnection -ComputerName <nome-o-ip-host-kms> -Port 1688

Impostare esplicitamente un host KMS su un server client KMS

slmgr /skms <hostkms.dominio.local:1688>
slmgr /ato

Ripristinare auto-discovery KMS (SRV) su un client

slmgr /ckms </code></pre>

<p><strong>Attenzione</strong>: evitare più host KMS simultanei per la stessa famiglia di prodotti a meno di avere una strategia chiara di bilanciamento; in ambienti piccoli si rischia di “dividere” il contatore delle richieste fra host differenti.</p>

<h2>Attivazione dei laptop in workgroup con MAK</h2>
<p>I laptop non uniti al dominio non possono usare ADBA; con un totale di client &lt; 25, KMS non si attiva. La scelta operativa più semplice è MAK.</p>
<ol>
  <li>Recupera un <strong>MAK</strong> per Windows&nbsp;11 dal portale licenze.</li>
  <li>Su ciascun laptop:
    <pre><code class="language-powershell">slmgr /ipk &lt;MAK&gt;
slmgr /ato

Opzionale: usa VAMT (Volume Activation Management Tool) per:

Inventariare i PC (via AD, IP range, file CSV).
Eseguire proxy activation (utile per macchine senza accesso Internet diretto).
Monitorare i conteggi residui del MAK e lo stato di attivazione.

Automazione e gestione centralizzata

Script di attivazione forzata per i membri di dominio

Distribuisci uno Startup Script via GPO ai computer di dominio per accelerare il primo ciclo:

# Forza discovery ADBA/KMS e attivazione
cscript //B "%windir%\system32\slmgr.vbs" /ato

Riconversione massiva MAK → GVLK

Se alcuni client di dominio sono stati attivati via MAK in passato, puoi riconvertirli in massa:

$pcList = Get-ADComputer -Filter * -SearchBase "OU=Workstations,DC=contoso,DC=local" |
           Select-Object -ExpandProperty Name
foreach ($pc in $pcList) {
  Invoke-Command -ComputerName $pc -ScriptBlock {
    cscript //B "C:\Windows\System32\slmgr.vbs" /ipk &lt;GVLK-edizione&gt;
    cscript //B "C:\Windows\System32\slmgr.vbs" /ato
  }
}

Sostituisci <GVLK-edizione> con la chiave GVLK corretta per l’edizione installata.

Monitoraggio e troubleshooting

Controlli rapidi

Stato licenza locale: slmgr /dli e slmgr /dlv.
Log: Security-SPP per client; Key Management Service per host KMS.
DNS (KMS): nslookup -type=srv vlmcs.tcp.
Rete (KMS): verifica porta 1688/TCP da subnet remote; apri firewall dove necessario.

Problemi ricorrenti e soluzioni

Problema	Possibile causa	Risoluzione
Client di dominio non si attiva	Endpoint ancora con MAK; mancata replica dell’Activation Object; clock o DNS errati	Imposta GVLK corretta; verifica replicazione AD; sincronizza NTP; `slmgr /ato`
KMS non attiva i server	Soglia non raggiunta (nuova installazione); SRV/DNS assente; porta 1688 bloccata	Attendi/aggiungi server; crea SRV _vlmcs; apri 1688/TCP; `slmgr /ato`
Client non di dominio non si attivano	Inadeguate soglie KMS; nessun MAK	Usa MAK (o VAMT come proxy) finché i client non superano 25
Host KMS “invisibile”	Più host KMS attivi; SRV puntano all’host “sbagliato”	Unifica/normalizza; imposta host esplicito con `slmgr /skms` o correggi SRV

Governance, sicurezza e ruoli

Separa le chiavi: CSVLK custodite in cassaforte segreta (segregazione dei doveri). MAK esposti solo a chi esegue l’attivazione.
Ridondanza: abilita VAS su almeno due DC per dominio. Per KMS (se usato), preferisci un solo host per famiglia di prodotti salvo reali esigenze di HA.
Firewall: limita l’accesso alla porta 1688 dell’host KMS alle subnet interne interessate.
Audit: registra l’uso delle chiavi (accessi al vault, check-out, attivazioni proxy VAMT).

Office Volume e coerenza con Windows

Se distribuisci Office in edizione Volume, puoi gestire l’attivazione con le stesse logiche:

ADBA carica anche la CSVLK di Office e pubblica l’oggetto relativo: i client di dominio si attivano in automatico.
KMS ha soglia tipica di 5 per Office: spesso sufficiente anche in ambienti medi.
MAK per eventuali endpoint fuori dominio/isolati.

FAQ operative

Quanto dura l’attivazione? 180 giorni, con rinnovi automatici periodici. I client tentano un rinnovo ogni pochi giorni; se non riescono, restano attivi finché non scade la validità, poi entrano in grace.

Serve Internet? Solo la macchina che carica la CSVLK (ADBA/KMS) deve attivare verso Microsoft. I client di dominio non contattano Internet per ADBA/KMS. Con MAK, ogni laptop contatta Microsoft (oppure VAMT funge da proxy).

Due domini in una foresta o due foreste? Se sono due foreste, pubblica l’oggetto ADBA in ciascuna foresta. Se sono due domini nella stessa foresta, l’oggetto è a livello di foresta ed è condiviso; valuta comunque VAS su più DC per resilienza e gestione locale.

Posso mischiare ADBA e KMS? Sì. Per esempio: ADBA per i client di dominio e KMS per i soli server. È una configurazione comune se hai standard che impongono KMS per i server.

Checklist di go‑live

VAS installato e Activation Object pubblicato in entrambi i domini.
Replica AD verificata; almeno due DC con VAS per dominio.
Eventuali endpoint di dominio riconvertiti a GVLK.
Script GPO per slmgr /ato distribuito e monitorato.
Laptop in workgroup attivati con MAK e censiti in VAMT (se usato).
(Opzionale) Host KMS per server attivo, SRV DNS verificato, porta 1688 aperta.
Log di successo in Security‑SPP e dashboard VAMT conformi.
Procedure di recovery documentate (backup di chiavi, contatti licenze, processi di sostituzione host).

Roadmap futura

Se superi 25 client Windows 10/11 complessivi, puoi migrare gli attuali laptop workgroup a KMS (impostando slmgr /skms o attivando l’auto‑discovery via SRV), riducendo l’uso di MAK.
Automazione: pipeline di post‑provisioning che esegue automaticamente slmgr /ato, invia stato a VAMT/CMDB e notifica eventuali errori.
Osservabilità: dashboard centralizzata con esito attivazioni, scadenze di validità e trend errori.

Esempi di comandi utili

# Stato licenza rapido
slmgr /dli

Stato licenza dettagliato

slmgr /dlv

Forzare un nuovo tentativo di attivazione

slmgr /ato

Impostare esplicitamente l'host KMS (se adottato per server)

slmgr /skms kms.miodominio.local:1688

Rimuovere impostazione host KMS e tornare all'auto-discovery (SRV DNS)

slmgr /ckms

Verifica SRV KMS nel DNS

nslookup -type=srv vlmcs.tcp

Test connettività verso host KMS (porta 1688)

Test-NetConnection -ComputerName kms.miodominio.local -Port 1688

Individuare prodotti licenziati via WMI (utile per script di audit)

Get-WmiObject -Query "SELECT * FROM SoftwareLicensingProduct WHERE PartialProductKey IS NOT NULL" |
Select-Object Name, LicenseStatus, PartialProductKey </code></pre>

<h2>Conclusioni</h2>
<p>Nel contesto dato, <strong>ADBA</strong> è la soluzione più efficiente per <strong>tutti i membri di dominio</strong> (server e client): zero soglie, zero configurazioni lato endpoint e gestione centralizzata. Gli <strong>8 laptop in workgroup</strong> vanno attivati con <strong>MAK</strong> finché il parco client non raggiunge la soglia KMS (≥ 25). Se desiderato, puoi aggiungere un <strong>KMS</strong> dedicato ai server (soglia ≥ 5 già soddisfatta), mantenendo comunque ADBA per i client di dominio. Questa architettura minimizza gli interventi manuali, è resiliente (VAS su più DC), si integra con VAMT per audit e si adatta facilmente a crescite future.</p>

<hr>

<h2>Soluzione raccomandata in tabella</h2>
<table>
  <thead>
    <tr>
      <th>Categoria di macchine</th>
      <th>Metodo consigliato</th>
      <th>Motivo</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Server di entrambi i domini</td>
      <td><strong>ADBA</strong> (oppure KMS opzionale). Installare VAS su almeno un DC per dominio; meglio su due per ridondanza.</td>
      <td>Nessuna soglia; attivazione automatica e resiliente grazie a AD; separazione opzionale con KMS se richiesto da policy.</td>
    </tr>
    <tr>
      <td>Workstation di dominio</td>
      <td><strong>ADBA</strong></td>
      <td>Membri di dominio: attivazione immediata e trasparente, niente gestione chiavi lato client.</td>
    </tr>
    <tr>
      <td>Laptop in workgroup</td>
      <td><strong>MAK</strong></td>
      <td>Non idonei ad ADBA; con &lt; 25 client totali KMS non si attiva. MAK è la via più semplice e tracciabile.</td>
    </tr>
  </tbody>
</table>

<h2>Procedure sintetiche</h2>
<h3>ADBA per server e client di dominio</h3>
<ol>
  <li>Installare VAS su almeno un DC per dominio (meglio due).</li>
  <li>Importare le CSVLK (Server, Windows 10/11 e, se necessario, Office) tramite <em>Volume Activation Tools</em>.</li>
  <li>Verificare la presenza dell’<em>Activation Object</em> in AD e la replica tra i DC.</li>
  <li>Forzare l’attivazione sui client con <code>slmgr /ato</code> o attendere il ciclo automatico.</li>
</ol>

<h3>Laptop in workgroup con MAK</h3>
<ol>
  <li>Recuperare un MAK per Windows&nbsp;11.</li>
  <li>Eseguire:
    <pre><code class="language-powershell">slmgr /ipk &lt;MAK&gt;
slmgr /ato

Opzionale: usare VAMT per gestire e monitorare le attivazioni MAK in rete o in proxy.

Best practice finali

Mantenere un set di chiavi MAK per emergenze o macchine isolate.
Documentare chiavi, processi e responsabilità (chi può accedere a CSVLK/MAK, dove sono custodite, come si approva un’attivazione).
Integrare con la CMDB: lo stato licenza come metadato obbligatorio alla messa in esercizio.
Prevedere un test di rinnovo a campione ogni trimestre: controlla che i device rinnovino l’attivazione senza warning.

In breve: usa ADBA per tutto ciò che appartiene al dominio; applica MAK ai laptop in workgroup finché il numero totale di client non raggiungerà la soglia necessaria per un’eventuale attivazione KMS. Per i server, ADBA è già sufficiente; KMS è una scelta architetturale opzionale.