Aggiornamenti dei componenti di Servizi directory
Si applica a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
Autore: Justin Turner, Senior Support Escalation Engineer del gruppo Windows
Nota
Questo contenuto è stato redatto da un ingegnere del Supporto tecnico Microsoft ed è destinato ad amministratori esperti e architetti di sistemi che desiderano una spiegazione tecnica delle funzionalità e delle soluzioni relative a Windows Server 2012 R2 più approfondita rispetto agli argomenti solitamente disponibili su TechNet. Non è stato tuttavia sottoposto agli stessi passaggi redazionali e, di conseguenza, per alcune lingue potrebbe essere meno accurato della documentazione che si trova in genere su TechNet.
Questa lezione illustra gli aggiornamenti del componente Servizi directory in Windows Server 2012 R2.
Contenuto dell'esercitazione
Spiegare i nuovi aggiornamenti del componente Servizi directory riportati di seguito:
Spiegare i nuovi aggiornamenti del componente Servizi directory riportati di seguito:
Livelli di funzionalità di domini e foreste
Panoramica
La sezione fornisce una breve introduzione alle modifiche del livello funzionale del dominio e della foresta.
Nuova DFL e FFL
Con la versione rilasciata vengono resi disponibili nuovi livelli di funzionalità di dominio e foresta:
Livello funzionalità foresta: Windows Server 2012 R2
Livello funzionalità dominio: Windows Server 2012 R2
Il livello di funzionalità dominio di Windows Server 2012 R2 consente di supportare le seguenti funzioni:
Protezioni sul lato controller di dominio per utenti protetti
Gli utenti protetti che eseguono l'autenticazione a un dominio di Windows Server 2012 R2 non possono più:
Usare l'autenticazione NTLM
Usare suite di crittografia DES o RC4 nella preautenticazione Kerberos
Usare la delega vincolata o non vincolata
Rinnovare i ticket utente (TGT) oltre la durata iniziale di 4 ore.
Authentication Policies
Nuovi criteri di Active Directory basati su foresta che possono essere applicati agli account dei domini di Windows Server 2012 R2 per controllare quali host possono accedere da un account e applicare le condizioni di controllo di accesso per l'autenticazione ai servizi in esecuzione come account
Authentication Policy Silos
Nuovo oggetto di Active Directory basato su foresta, che può creare una relazione tra utente, servizio gestito e account computer da usare per classificare gli account per i criteri di autenticazione o per l'isolamento dell'autenticazione.
Vedere Come configurare gli account protetti per ulteriori informazioni.
Oltre alle funzionalità precedenti, il livello di funzionalità dominio di Windows Server 2012 R2 garantisce che qualsiasi controller di dominio nel dominio esegua Windows Server 2012 R2. Il livello di funzionalità foresta di Windows Server 2012 R2 non fornisce tutte le nuove funzionalità, ma garantisce che ogni nuovo dominio creato nella foresta venga automaticamente utilizzato a livello funzionale di dominio di Windows Server 2012 R2.
DFL minimo applicato alla creazione di un nuovo dominio
Windows Server 2008 DFL è il livello funzionale minimo supportato per la creazione di un nuovo dominio.
Nota
La deprecazione di FRS viene eseguita rimuovendo la possibilità di installare un nuovo dominio con un livello funzionale di dominio inferiore a Windows Server 2008 con Server Manager o tramite Windows PowerShell.
Riduzione dei livelli di funzionalità foresta e dominio
Quando si creano nuove foreste e nuovi domini, i livelli di funzionalità foresta e dominio sono settati su Windows Server 2012 R2 per impostazione predefinita, ma tali criteri possono essere regolati verso il basso utilizzando Windows PowerShell.
Per aumentare o abbassare il livello di funzionalità foresta tramite Windows PowerShell, usare il cmdlet Set-ADForestMode.
Per impostare la FFL contoso.com su modalità Windows Server 2008:
Set-ADForestMode -ForestMode Windows2008Forest -Identity contoso.com
Per aumentare o abbassare il livello di funzionalità dominio tramite Windows PowerShell, usare il cmdlet Set-ADDomainMode.
Per impostare la DFL contoso.com su modalità Windows Server 2008:
Set-ADDomainMode -DomainMode Windows2008Domain -Identity contoso.com
Promozione di un controller di dominio (DC) che esegue Windows Server 2012 R2 come replica aggiuntiva in un dominio esistente che esegue le attività 2003 DFL.
Creazione di un nuovo dominio in una foresta esistente
ADPREP
In questa versione non sono presenti nuove operazioni foresta o dominio.
Questi file con estensione .ldf contengono modifiche dello schema per il Servizio registrazione dispositivi.
Sch59
Sch61
Sch62
Sch63
Sch64
Sch65
Sch67
Cartelle di lavoro:
- Sch66
MSODS:
- Sch60
Criteri di autenticazione e silo
Sch68
Sch69
Elementi deprecati di NTFRS
Panoramica
Funzionalità rimosse (FRS) è stato deprecato in Windows Server 2012 R2. La deprecazione di FRS viene eseguita applicando un livello di funzionalità di dominio minimo (DFL) di Windows Server 2008. Tale imposizione è presente solo se il nuovo dominio viene creato tramite Server Manager o Windows PowerShell.
Usare il parametro -DomainMode con i cmdlet Install-ADDSForest o Install-ADDSDomain per specificare il livello di funzionalità del dominio. I valori supportati per questo parametro possono essere un numero intero valido o un valore stringa enumerato corrispondente. Ad esempio, per impostare il livello della modalità di dominio su Windows Server 2008 R2, è possibile specificare il valore 4 oppure "Win2008R2". Quando si eseguono questi cmdlet da Server 2012 R2, i valori validi comprendono quelli per Windows Server 2008 (3, Win2008) Windows Server 2008 R2 (4, Win2008R2) Windows Server 2012 (5, Win2012) e Windows Server 2012 R2 (6, Win2012R2). Il livello di funzionalità del dominio non può essere inferiore al livello di funzionalità della foresta, ma può essere superiore. Stante la deprecazione di FRS in questa versione, Windows Server 2003 (2, Win2003) non è un parametro riconosciuto con questi cmdlet nel momento in cui vengono eseguiti da Windows Server 2012 R2.
Modifiche a Query Optimizer LDAP
Panoramica
L'algoritmo di Query Optimizer LDAP è stato rivalutato e ottimizzato ulteriormente. Ciò ha prodotto miglioramenti delle prestazioni nell'efficienza della ricerca LDAP e nei tempi di ricerca LDAP delle query complesse.
Nota
Dal Developer:miglioramenti delle prestazioni delle ricerche tramite i perfezionamenti apportati al mapping dalla query LDAP alla query ESE. I filtri LDAP oltre un determinato livello di complessità impediscono la selezione ottimizzata degli indici, con conseguente riduzione drastica delle prestazioni (1000x o più). Questa modifica cambia il modo in cui si selezionano gli indici per le query LDAP al fine di evitare il problema.
Nota
Revisione completa dell'algoritmo di Query Optimizer LDAP, il che ha portato a:
- Tempi di ricerca più veloci
- DC più produttivi a seguito dei miglioramenti in termini di efficienza
- Meno chiamate di supporto legate a problemi prestazionali di Active Directory
- Adattamento a Windows Server 2008 R2 (KB 2862304)
Background
La possibilità di eseguire ricerche in Active Directory è un servizio di base fornito dai controller di dominio. Altri servizi e applicazioni line-of-business si basano sulle ricerche di Active Directory. Le operazioni aziendali possono interrompersi se questa funzionalità non è disponibile. Essendo un servizio di base molto usato, è fondamentale che i controller di dominio gestiscano il traffico di ricerca LDAP in modo efficiente. L'algoritmo di Query Optimizer LDAP tenta di rendere le ricerche LDAP più efficienti possibile eseguendo il mapping dei filtri di ricerca LDAP per un set di risultati che può essere soddisfatto tramite record già indicizzati nel database. Questo algoritmo è stato rivalutato e ottimizzato ulteriormente. Ciò ha prodotto miglioramenti delle prestazioni nell'efficienza della ricerca LDAP e nei tempi di ricerca LDAP delle query complesse.
Dettagli della modifica
Una ricerca LDAP contiene:
Posizione (head NC, OU, Oggetto) all'interno della gerarchia per iniziare la ricerca
Un filtro di ricerca
Un elenco degli attributi da restituire
Il processo di ricerca può essere così riassunto:
Se possibile, semplificare il filtro di ricerca.
Selezionare un set di chiavi di indice che restituirà il set interessato più piccolo.
Eseguire una o più intersezioni di chiavi di indice per ridurre il set interessato.
Per ogni record nel set interessato, valutare espressione del filtro e sicurezza. Se il filtro restituisce TRUE e viene concesso l'accesso, restituire il record al client.
Il lavoro di ottimizzazione query LDAP modifica i passaggi 2 e 3 per ridurre le dimensioni del set interessato. In particolare, l'implementazione corrente seleziona chiavi di indice duplicate ed esegue intersezioni ridondanti.
Confronto tra l’algoritmo precedente e quello nuovo
La destinazione della ricerca LDAP inefficiente riportata in questo esempio è un controller di dominio di Windows Server 2012. La ricerca viene completata in circa 44 secondi in seguito alla mancata individuazione di un indice più efficiente.
adfind -b dc=blue,dc=contoso,dc=com -f "(| (& (|(cn=justintu) (postalcode=80304) (userprincipalname=justintu@blue.contoso.com)) (|(objectclass=person) (cn=justintu)) ) (&(cn=justintu)(objectclass=person)))" -stats >>adfind.txt
Using server: WINSRV-DC1.blue.contoso.com:389
<removed search results>
Statistics
=====
Elapsed Time: 44640 (ms)
Returned 324 entries of 553896 visited - (0.06%)
Used Filter:
( | ( & ( | (cn=justintu) (postalCode=80304) (userPrincipalName=justintu@blue.contoso.com) ) ( | (objectClass=person) (cn=justintu) ) ) ( & (cn=justintu) (objectClass=person) ) )
Used Indices:
DNT_index:516615:N
Pages Referenced : 4619650
Pages Read From Disk : 973
Pages Pre-read From Disk : 180898
Pages Dirtied : 0
Pages Re-Dirtied : 0
Log Records Generated : 0
Log Record Bytes Generated: 0
Risultati di esempio che utilizzano il nuovo algoritmo
In questo esempio viene ripetuta la stessa ricerca precedente, ma la stessa è destinata a un controller di dominio Windows Server 2012 R2. La stessa ricerca viene completata in meno di un secondo a seguito dei miglioramenti apportati all'algoritmo di Query Optimizer LDAP.
adfind -b dc=blue,dc=contoso,dc=com -f "(| (& (|(cn=justintu) (postalcode=80304) (userprincipalname=dhunt@blue.contoso.com)) (|(objectclass=person) (cn=justintu)) ) (&(cn=justintu)(objectclass=person)))" -stats >>adfindBLUE.txt
Using server: winblueDC1.blue.contoso.com:389
.<removed search results>
Statistics
=====
Elapsed Time: 672 (ms)
Returned 324 entries of 648 visited - (50.00%)
Used Filter:
( | ( & ( | (cn=justintu) (postalCode=80304) (userPrincipalName=justintu@blue.contoso.com) ) ( | (objectClass=person) (cn=justintu) ) ) ( & (cn=justintu) (objectClass=person) ) )
Used Indices:
idx_userPrincipalName:648:N
idx_postalCode:323:N
idx_cn:1:N
Pages Referenced : 15350
Pages Read From Disk : 176
Pages Pre-read From Disk : 2
Pages Dirtied : 0
Pages Re-Dirtied : 0
Log Records Generated : 0
Log Record Bytes Generated: 0
Se non è possibile ottimizzare l'albero:
Ad esempio: un'espressione nell'albero si trova su una colonna non indicizzata
Registrare un elenco di indici che impediscono l'ottimizzazione
Esposto tramite traccia ETW e ID evento 1644
Per abilitare il controllo Stats in LDP
Aprire LDP.exe e connettersi e associare a un controller di dominio.
Scegliere Controlli dal menu Opzioni.
Nella finestra di dialogo Controlli espandere il menu a discesa Carica predefinito, selezionare Statistiche di ricerca, quindi fare clic suOK.
Nel menu Sfoglia, selezionare Cerca
Nella finestra di dialogo Cerca, selezionare il pulsante Opzioni.
Verificare che la casella di controllo Estesa sia selezionata nella finestra di dialogo Opzioni di ricerca e selezionare OK.
Provare a usare LDP per restituire le statistiche delle query
Eseguire le operazioni seguenti in un controller di dominio o da un client o un server aggiunto a un dominio in cui sono installati gli strumenti di Active Directory Domain Services. Ripetere quanto segue, inserendo come destinazione il controller di dominio Windows Server 2012 e il controller di dominio Windows Server 2012 R2.
Vedere l'articolo "Creating More Efficient Microsoft AD Enabled Applications" (Creazione di applicazioni abilitate per Microsoft AD più efficienti) e farvi riferimento a esso in base alle esigenze.
Usando LDP, abilitare le statistiche di ricerca (vedere Per abilitare il controllo Statistiche in LDP)
Eseguire diverse ricerche LDAP e osservare le informazioni statistiche nella parte superiore dei risultati. Ripetere la stessa ricerca in altre attività in modo da documentarle in un file di testo del Blocco note.
Eseguire una ricerca LDAP che Query Optimizer deve essere in grado di ottimizzare per via di indici di attributi
Tentare di costruire una ricerca che richieda molto tempo per essere completata (è consigliabile aumentare l'opzione Limite di tempo in modo che la ricerca non vada in timeout).
Risorse aggiuntive
Che cosa sono le ricerche di Active Directory?
Funzionamento delle ricerche di Active Directory
Creazione di applicazioni abilitate per Microsoft Active Directory più efficienti
951581 Le query LDAP vengono eseguite più lentamente del previsto nel servizio directory AD o LDS/ADAM ed è possibile registrare l'ID evento 1644
Miglioramenti dell'evento 1644
Panoramica
Questo aggiornamento aggiunge altre statistiche dei risultati della ricerca LDAP all'ID evento 1644 per facilitare la risoluzione dei problemi. Inoltre, è disponibile un nuovo valore del Registro di sistema che può essere utilizzato per abilitare la registrazione di una soglia basata sul tempo. Questi miglioramenti sono stati resi disponibili in Windows Server 2012 e Windows Server 2008 R2 SP1 tramite KB 2800945 e saranno resi disponibili per Windows Server 2008 SP2.
Nota
- Altre statistiche di ricerca LDAP vengono aggiunte all'ID evento 1644 per facilitare la risoluzione dei problemi di ricerche LDAP inefficienti o costose
- È ora possibile specificare una soglia di tempo di ricerca, ad esempio Registrare l'evento 1644 per le ricerche che richiedono più di 100 ms, anziché specificare i valori soglia dei risultati di ricerca costosi e inefficienti
Background
Durante la risoluzione dei problemi di prestazioni di Active Directory, è evidente che l'attività di ricerca LDAP potrebbe contribuire al problema. Si decide di abilitare la registrazione in modo da visualizzare query LDAP costose o inefficienti elaborate dal controller di dominio. Per abilitare la registrazione, è necessario impostare il valore di diagnostica Field Engineering e, facoltativamente, specificare i valori di soglia dei risultati della ricerca costosi/inefficienti. Quando si abilita il livello di registrazione Field Engineering su un valore pari a 5, qualsiasi ricerca che soddisfi talii criteri viene registrata nel registro eventi di Servizi directory con un ID evento 1644.
L'evento contiene:
IP client e porta
Nodo iniziale
Filtro
Ambito di ricerca
Selezione attributi
Controlli server
Voci visitate
Voci restituite
Tuttavia, i dati chiave non sono presenti nell'evento, come la quantità di tempo impiegato per l'operazione di ricerca e quale indice (se presente) è stato usato.
Altre statistiche di ricerca aggiunte all'evento 1644
Indici usati
Pagine a cui si fa riferimento
Pagine lette dal disco
Pagine prelette dal disco
Pagine pulite modificate
Pagine dirty modificate
Tempo di ricerca
Attributi che impediscono l'ottimizzazione
Nuovo valore soglia del Registro di sistema basato sul tempo per la registrazione dell'evento 1644
Anziché specificare i valori soglia dei risultati di ricerca costosi e inefficienti, è possibile specificare la soglia del tempo di ricerca. Se si desidera registrare tutti i risultati della ricerca che hanno richiesto 50 ms o un tempo superiore, è necessario specificare 50 decimale / 32 esadecimale (oltre a impostare il valore di Field Engineering).
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
"Search Time Threshold (msecs)"=dword:00000032
Confronto tra l'ID evento 1644 precedente e quello nuovo
OLD
Nuovo…
Provare a usare il registro eventi per restituire le statistiche della query
Ripetere quanto segue, inserendo come destinazione il controller di dominio Windows Server 2012 e il controller di dominio Windows Server 2012 R2. Osservare l'ID evento 1644 in entrambi i controller di dominio dopo ogni ricerca.
Usando regedit, abilitare la registrazione dell'ID evento 1644 usando una soglia basata sul tempo nel controller di dominio Windows Server 2012 R2 e il metodo precedente nel controller di dominio di Windows Server 2012.
Eseguire diverse ricerche LDAP che superano la soglia e osservare le informazioni statistiche nella parte superiore dei risultati. Usare le query LDAP documentate in precedenza e ripetere le stesse ricerche.
Eseguire una ricerca LDAP che Query Optimizer non è in grado di ottimizzare perché uno o più attributi non sono indicizzati.
Miglioramento della velocità effettiva della Replica di Active Directory
Panoramica
La replica di Active Directory usa Replica di Active Directory (RPC) per il trasporto di replica. Per impostazione predefinita, RPC usa un buffer di trasmissione 8K e una dimensione di pacchetto 5K. Questo ha l'effetto netto laddove l'istanza di invio trasmette tre pacchetti (circa 15.000K di dati) e quindi deve attendere un round trip di rete prima di inviarne altri. Supponendo un tempo di round trip di 3 ms, la velocità effettiva più elevata sarebbe di circa 40 Mbps, anche su reti da 1 Gbps o da 10 Gbps.
Nota
Ciò regola la velocità effettiva massima della replica AD facendola passare da 40 Mbps a circa 600 Mbps.
- Aumenta la dimensione del buffer di invio RPC, riducendo il numero di round trip di rete
L'effetto sarà più evidente su una rete ad alta velocità e latenza.
Questo aggiornamento aumenta la velocità effettiva massima a circa 600 Mbps, modificando le dimensioni del buffer di trasmissione RPC da 8K a 256 kB. Tale modifica consente di aumentare le dimensioni della finestra TCP oltre 8K, riducendo il numero di round trip di rete.
Nota
Non sono presenti impostazioni configurabili per la modifica di questo comportamento.