Risolvere i problemi relativi all'attivazione basata su Active Directory (ADBA) dei client che non attivano

Note

Questo articolo è stato originariamente pubblicato sul blog TechNet il 26 marzo 2018.

Di recente ho collaborato alla distribuzione di Windows Server 2016 nell'ambiente di un cliente. L'introduzione di questa nuova piattaforma ha offerto anche l'opportunità di eseguire la migrazione della metodologia di attivazione dall'uso di un server del Servizio di gestione delle chiavi all'attivazione basata su Active Directory.

Come procedura appropriata per apportare tutte le modifiche, è stata avviata la migrazione nell'ambiente di test del cliente. È stata avviata la distribuzione seguendo le istruzioni riportate in Attivazione basata su Active Directory e Servizio di gestione delle chiavi s. I controller di dominio nell'ambiente di test eseguono windows Server 2012 R2, quindi non è necessario preparare la foresta. Il ruolo è stato installato in un controller di dominio di Windows Server 2012 R2 e si è scelto Attivazione basata su Active Directory come metodo di attivazione dei contratti multilicenza. È stata installata la chiave del Servizio di gestione delle chiavi e è stato assegnato un nome di "ATTIVAZIONE AD KMS (** LAB)." Il post di blog è stato seguito passo dopo passo.

Abbiamo iniziato creando quattro macchine virtuali, due Windows 2016 Server Standard e due Windows 2016 Server Datacenter. A questo punto tutto era fantastico. È stato creato un server fisico che esegue Windows 2016 Server Standard e il computer è stato attivato correttamente.

A dire il vero, la parte relativa all'installazione e alla configurazione è stata molto semplice. Tuttavia, tutte le macchine virtuali che avevo costruito la settimana precedente hanno mostrato che non erano attivate. Ho controllato il computer fisico ed era tutto a posto. Ho quindi parlato con il cliente per discutere dell'accaduto. La prima domanda è stata "Cosa è cambiato nel fine settimana?" E come al solito la risposta era "niente". Questa volta, niente era stato davvero cambiato, e abbiamo dovuto capire cosa stava succedendo.

Si è recato in uno dei server di problemi, è stato aperto un prompt dei comandi ed è stato controllato l'output del slmgr /ao-list comando. L'opzione /ao-list visualizza tutti gli oggetti attivazione in Active Directory.

I risultati mostrano che sono presenti due oggetti di attivazione: uno per Windows Server 2012 R2 e l'attivazione AD del Servizio di gestione delle chiavi appena creata (** LAB) che è la licenza di Windows Server 2016. Ciò conferma che Active Directory è configurato correttamente per attivare i client del Servizio di gestione delle chiavi windows.

Sapendo che il comando è per l'attivazione slmgr delle licenze, ho continuato con diverse opzioni. Ho provato l'opzione /dlv , che visualizzerà informazioni dettagliate sulla licenza. Questo aspetto era corretto, stavo eseguendo la versione Standard di Windows Server 2016, c'è un ID attivazione, un ID di installazione, un URL di convalida, anche un codice Product Key parziale.

Qualcuno ha notato ciò che mi è sfuggito a questo punto? Si tornerà ad esso dopo gli altri passaggi per la risoluzione dei problemi, ma è sufficiente dire che la risposta è in questo screenshot.

Il mio pensiero ora è che per qualche motivo, la chiave è interrotta, quindi uso l'opzione /upk , che disinstalla la chiave corrente. Anche se questo è stato efficace per rimuovere la chiave, in genere non è il modo migliore per farlo. Il server deve essere riavviato prima di ottenere una nuova chiave che potrebbe lasciare il server in uno stato non valido? Ho scoperto che l'uso dell'opzione /ipk (che faccio più avanti nella risoluzione dei problemi) sovrascrive la chiave esistente ed è un percorso più sicuro da intraprendere.

Ho eseguito di nuovo l'opzione /dlv per visualizzare le informazioni dettagliate sulla licenza. Sfortunatamente, questo non mi ha dato informazioni utili, solo un codice Product Key non trovato errore. Perché non c'è una chiave perché l'ho appena disinstallata.

Ho pensato che fosse un colpo lungo, ma ho provato l'opzione /ato , che dovrebbe attivare Windows sui server del Servizio di gestione delle chiavi noti (o Active Directory come potrebbe essere il caso). Anche in questo caso, è stato restituito un errore di prodotto non trovato.

Il prossimo pensiero era che a volte arrestare e avviare un servizio fa il trucco, quindi ho provato a questo successivo. Dovevo arrestare e avviare il servizio SPPSvc, ovvero Microsoft Software Protection Platform Service. Da un prompt dei comandi amministrativo si usano i comandi e net start attendibilinet stop. Si noti inizialmente che il servizio non è in esecuzione, quindi penso che questo debba essere.

Tuttavia, dopo l'avvio del servizio e il tentativo di attivare nuovamente Windows, viene comunque visualizzato l'errore non trovato del prodotto.

Ho quindi esaminato il registro eventi Application in uno dei server con problemi. Ho individuato un errore relativo all'attivazione della licenza, ID evento 8198, con codice 0x8007007B.

Durante la ricerca di questo codice, è stato trovato un articolo che indica che il nome del file, il nome della directory o la sintassi dell'etichetta del volume non è corretto. Leggendo i metodi descritti nell'articolo, non sembrava che nessuno di loro si adattasse alla situazione. Quando ho eseguito il nslookup -type=all _vlmcs._tcp comando, ho trovato il server del Servizio di gestione delle chiavi esistente (ancora un sacco di computer Windows 7 e Server 2008 nell'ambiente, quindi era necessario tenerlo in giro), ma anche i cinque controller di dominio. Ciò ha indicato che non era un problema DNS e che i problemi erano altrove.

A questo punto, sapevo che il DNS funzionava correttamente. Active Directory era configurato in modo corretto come origine di attivazione del Servizio di gestione delle chiavi. Il server fisico è stato attivato correttamente. Poteva forse trattarsi di un problema specifico delle macchine virtuali? Come nota collaterale interessante, a questo punto, il cliente mi ha informato che qualcuno di un altro reparto aveva deciso di creare una decina di macchine virtuali Windows Server 2016. Quindi ora presumo di avere un'altra dozzina di server per gestire che non saranno attivati. Tuttavia, questi server sono attivati solo bene.

Beh, sono tornato al slmgr comando per capire come attivare questi mostri. Questa volta userò l'opzione /ipk , che mi permetterà di installare un codice Product Key. Sono andato in Appendice A: Chiavi di installazione client del Servizio di gestione delle chiavi per ottenere le chiavi appropriate per la versione Standard di Windows Server 2016. Alcuni server sono Datacenter, ma è prima necessario risolvere questo problema.

Ho usato l'opzione /ipk per installare un codice Product Key, scegliendo il tasto Windows Server 2016 Standard.

Da questo punto in poi, ho acquisito solo i risultati dalle mie esperienze di Datacenter, ma erano gli stessi. Ho usato il /ato commutatore per forzare l'attivazione. Riceviamo il messaggio impressionante che il prodotto è stato attivato correttamente.

Usando di nuovo l'opzione /dlv , è possibile vedere che ora è stato attivato da Active Directory.

Ma allora che cosa non aveva funzionato? Per quale motivo ho dovuto rimuovere il codice installato e aggiungere codici generici per consentire l'attivazione delle macchine virtuali? Per quale motivo le altre macchine venivano attivate senza problemi? Come ho già detto, mi era sfuggita un'informazione fondamentale nelle fasi iniziali dell'analisi del problema. Ero completamente confuso, quindi ho raggiunto il poster dal blog iniziale. Il poster ha visto subito il problema e mi ha aiutato a capire cosa mi mancava presto.

Quando ho eseguito il primo /dlv commutatore, nella descrizione era la chiave. Nella descrizione era indicato Windows® Operating System, RETAIL Channel. Avevo notato la descrizione e pensato che RETAIL Channel indicasse la presenza di un codice acquistato valido.

Quando si esamina l'output del /dlv commutatore da un server attivato correttamente, si noti che la descrizione ora indica il canale VOLUME_KMSCLIENT. Questo ci fa sapere che è effettivamente una licenza multilicenza.

Che cosa indica quindi il canale RETAIL? Questa dicitura significa che il supporto usato per installare il sistema operativo è un'immagine ISO MSDN. Ho quindi chiesto al mio cliente se per caso sulla rete fosse presente una seconda immagine ISO di Windows Server 2016. Risposta affermativa. Si dà il caso che sulla rete fosse presente un'altra immagine ISO, che era stata usata per creare l'altra decina di computer. Sono state confrontate le due immagini ISO e, chiaramente, quella che mi era stata assegnata per creare i server virtuali era in realtà un'immagine ISO MSDN. Hanno rimosso l'ISO MSDN dalla rete e ora abbiamo tutti i server esistenti attivati e non ci preoccupano più l'attivazione non riuscita nelle build future.