Criteri di gruppo

Ottimizzazione delle prestazioni dei Criteri di gruppo

Darren Mar-Elia

Panoramica:

• Oggetti Criteri di gruppo monolitici e funzionali
• Come elaborare le voci relative ai Criteri di gruppo
• Cosa succede quando si apportano modifiche ai Criteri di gruppo

Spesso mi viene posta la domanda: "Dal punto di vista delle prestazioni, è preferibile utilizzare pochi oggetti Criteri di gruppo più grandi o tanti più piccoli?".Questa domanda è il tema di questo articolo, insieme alle altre sul progetto e sulle prestazioni dei Criteri di gruppo.E, come avviene per la maggior parte delle domande generiche,

posso rispondere anticipatamente:"Dipende".Sebbene riconosca che questa risposta possa sembrare evasiva, il mio obiettivo è indicare i meccanismi che stanno alla base dell'elaborazione dei Criteri di gruppo, al fine di consentire agli utenti di prendere decisioni consapevoli sul progetto dei Criteri di gruppo, a prescindere se si è all'inizio o se si cerca di ottimizzare un ambiente con centinaia di oggetti Criteri di gruppo esistenti.

Oggetti Criteri di gruppo monolitici e funzionali

Partiamo, innanzitutto, dalla descrizione dei diversi metodi a disposizione per implementare gli oggetti Criteri di gruppo.I termini "monolitico" e "funzionale" fanno riferimento a come questi vengono progettati.Gli oggetti Criteri di gruppo (GPO) monolitici contengono impostazioni provenienti da molte aree differenti.Ad esempio, un GPO monolitico potrebbe contenere impostazioni provenienti dai criteri Modelli amministrativi, Manutenzione di Internet Explorer e Installazione software, in un unico oggetto Criteri di gruppo.Al contrario, i GPO funzionali eseguono una sola operazione,ad esempio, eseguono l'installazione software oppure applicano le impostazioni di protezione.Ho anche visto GPO funzionali che contengono una sola impostazione criterio.Ma probabilmente si tratta di una situazione estrema.Nella Figura 1 vengono illustrati alcuni dei vantaggi e degli svantaggi di ciascun approccio.

Figure 1 Confronto tra GPO monolitici e funzionali

Come si può vedere, non è possibile rispondere a priori su quale approccio, monolitico o funzionale, sia il più adatto per tutti i casi.È probabile che nel in un ambiente, siano necessari entrambi.Ad esempio, l'approccio funzionale potrebbe sembrare più adatto durante la creazione di criteri di protezione per l'intero dominio.Utilizzare un unico GPO che contiene solo le impostazioni di protezione rende più facile delegare il controllo di tale oggetto agli amministratori della protezione.Con lo stesso token, se l'amministrazione dei Criteri di gruppo viene delegata agli amministratori dell'unità organizzativa, stabilendo un oggetto Criteri di gruppo monolitico per ogni unità organizzativa, tali amministratori potrebbero usufruire di un'unica posizione dalla quale gestire tutte le impostazioni dei criteri.In questo modo il loro lavoro risulterebbe più semplice e sarebbe possibile ridurre il numero di GPO creati per gli utenti e i computer di una determinata unità organizzativa.

In che modo tali decisioni di alto livello possono influire sulle prestazioni dell'elaborazione dei Criteri di gruppo? Inoltre, come è possibile prendere decisioni appropriate sulla progettazione dei Criteri di gruppo in grado di ridurre l'impatto sulle prestazioni?Il primo passaggio verso l'ottimizzazione delle prestazioni dell'infrastruttura esistente dei Criteri di gruppo è scoprire come avviene l'elaborazione dei Criteri di gruppo.

Informazioni sull'elaborazione dei Criteri di gruppo

L'elaborazione dei Criteri di gruppo è un insieme complesso di interazioni che interessano molte parti dell'infrastruttura Windows® e Active Directory®.A livello superiore, l'elaborazione dei Criteri di gruppo è suddivisa in due parti.La prima viene definita elaborazione principale o dell'infrastruttura Criteri di gruppo.In questa fase, un client dei Criteri di gruppo di Windows richiede al controller di dominio più vicino di stabilire la velocità di collegamento del controller di dominio, dove si trova nella gerarchia di Active Directory (ossia, a quale sito, dominio e unità organizzativa appartiene il client) e quali GPO vengono applicati al computer o all'utente attualmente connesso.È importante notare che, in questo contesto, un client potrebbe essere un server o una workstation appartenente a un dominio di Active Directory.Dopo aver creato l'elenco di GPO, inizia la fase successiva: l'elaborazione dell'estensione lato client (CSE).Durante la fase CSE, ciascuna estensione CSE registrata elabora l'elenco di GPO che ha implementato le impostazioni nella relativa area.Ad esempio, l'estensione CSE Registro di sistema o Modello amministrativo viene eseguita sempre per prima ed elabora tutti i GPO che si applicano a un determinato computer o utente e che hanno implementato i criteri del Registro di sistema.

L'elenco riportato di seguito descrive in dettaglio i passaggi del ciclo di elaborazione dei Criteri di gruppo, comprese le interazioni di rete tra il client e il controller di dominio.È importante ricordare che i Criteri di gruppo si applicano sia ai computer che agli utenti.Pertanto, ogni volta che viene elaborato un criterio, ad esempio durante un aggiornamento in background dei Criteri di gruppo, il ciclo indicato più avanti viene ripetuto sia per il computer che per l'account utente attualmente connesso a un determinato sistema, poiché a entrambi è possibile applicare diversi gruppi di criteri.In questo caso, Windows esegue contemporaneamente il ciclo di elaborazione per il computer e per l'utente e ciascun ciclo viene eseguito su un thread differente all'interno del processo del modulo Criteri di gruppo(il processo Winlogon per Windows 2000, Windows XP e Windows Server® 2003 e il servizio client dei Criteri di gruppo in Windows Vista® e Windows Server 2008).

Elaborazione dei Criteri di gruppo in una procedura che prevede sei passaggi:

1. Il client esegue il rilevamento di un collegamento lento ICMP (Internet Control Message Protocol) in un controller di dominio del proprio sito per determinare la velocità di collegamento.In Windows Vista, l'uso di ICMP per il rilevamento di un collegamento lento viene sostituito dal servizio Riconoscimento presenza in rete (NLA).
2. Il client legge le informazioni sullo stato della CSE dal relativo Registro di sistema locale per stabilire gli ultimi GPO elaborati.
3. Il client si avvale di LDAP per cercare l'attributo gpLink di Active Directory in ciascun oggetto contenitore nella relativa posizione nella gerarchia di Active Directory: prima al livello dell'unità organizzativa (comprese tutte le unità organizzative nidificate), poi al livello del dominio e, infine, al livello del sito di Active Directory.Dai risultati di questa ricerca, crea un elenco di GPO da prendere in considerazione per l'elaborazione.
4. Ogni oggetto Criteri di gruppo viene poi cercato in Active Directory per determinare se il client (l'utente o il computer) dispone delle autorizzazioni necessarie per elaborarlo.Vengono presi in considerazione anche il numero di versione, il percorso al modello Criteri di gruppo (GPT) del GPO in SYSVOL e le CSE implementate nei GPO.
5. Il client utilizza poi il protocollo SMB (Server Message Block) per leggere il contenuto del modello Criteri di gruppo e richiamare il numero di versione del GPO dal file gpt.ini.I numeri di versione del contenitore Criteri di gruppo (GPC) e del modello Criteri di gruppo (GPT) vengono utilizzati per stabilire se un GPO è stato modificato dall'ultimo ciclo di elaborazione.
6. Ogni CSE viene eseguita nell'ordine in cui è stata registrata in HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions. Inoltre, se dopo l'ultimo ciclo di elaborazione il GPO risulta modificato, ogni CSE elabora gli oggetti Criteri di gruppo che implementano tale CSE (come stabilito durante l'elaborazione principale).Ciascuna CSE registra anche i dati del gruppo di criteri risultante (RSOP) in Windows Management Instrumentation (WMI) durante ogni aggiornamento, se disponibile.

Esaminiamo questo processo e come le prestazioni vengono influenzate.La prima cosa da tenere presente è che esiste una differenza tra l'elaborazione in background e quella in primo piano.L'elaborazione in primo piano si verifica per i computer durante il riavvio di un sistema e per gli utenti al momento dell'accesso.Per impostazione predefinita, gli aggiornamenti in background sulle workstation e sui server membri si verificano ogni 90 minuti, più altri trenta minuti in un valore generato casualmente.Sempre per impostazione predefinita, gli aggiornamenti in background nei controller di dominio avvengono ogni 5 minuti.In Windows Vista, è anche possibile che si verifichino aggiornamenti basati su NLA. Si tratta fondamentalmente di eventi di aggiornamento in background attivati da un precedente errore di elaborazione dei Criteri di gruppo causato dall'assenza di un controller di dominio (ad esempio, se durante un intervallo di background il client non è in linea).Perché è importante fare queste distinzioni?Principalmente perché alcune CSE (ad esempio, le CSE Installazione software e Reindirizzamento cartelle) non vengono eseguite durante un aggiornamento in background.Durante un aggiornamento in background anche gli script di accesso e disconnessione o di avvio e arresto non vengono eseguiti.

Allo stesso modo, nel passaggio 1 di questo processo, ho parlato di processo di rilevamento di un collegamento lento.Nei sistemi precedenti a Windows Vista, questo processo si basa sui client che utilizzano ICMP per eseguire il ping del controller di dominio al fine di stabilire la disponibilità e la velocità di collegamento.Se il valore calcolato che indica la velocità del collegamento scende al di sotto di una determinata soglia (il valore predefinito è 500 Kb/s), il collegamento è considerato lento e, pertanto, alcune CSE, come Installazione software, Reindirizzamento cartelle e Manutenzione di Internet Explorer, non vengono eseguite.Tutte queste condizioni possono influire sulle prestazioni così come sulla distribuzione prevista dei criteri.

Probabilmente, l'aspetto del ciclo di elaborazione dei criteri che influisce maggiormente sulle prestazioni è la logica secondo la quale si determina se gli oggetti Criteri di gruppo che si applicano a un computer o a un utente sono stati modificati.Il modulo Criteri di gruppo presenta un'ottimizzazione integrata che stabilisce che se dopo l'ultima elaborazione dei Criteri di gruppo non è cambiato nulla per un computer o un utente, non avviene alcuna elaborazione.Ciò potrebbe avere ovviamente un impatto negativo sul tempo impiegato dai client per elaborare i criteri, soprattutto se l'ambiente Criteri di gruppo è abbastanza statico.Esaminiamo più approfonditamente in cosa consiste una modifica.

Quando si verifica una modifica dei Criteri di gruppo

In cosa consiste una modifica in termini di elaborazione dei Criteri di gruppo?Esistono diversi fattori, ma il più ovvio è che se si apporta una modifica a un oggetto Criteri di gruppo, i client che elaborano tale oggetto rilevano la modifica e rielaborano il GPO.In che modo un client può sapere se un oggetto Criteri di gruppo è stato modificato?In base ai numeri di versione sull'oggetto Criteri di gruppo e all'interno del client.

Un GPO è composto da due parti: il contenitore Criteri di gruppo (GPC) memorizzato in Active Directory in CN=Policies, il contenitore CN=System all'interno di ciascun dominio, e il modello Criteri di gruppo (GPT) memorizzato in SYSVOL nella cartella Criteri.Ognuna delle due parti dell'oggetto Criteri di gruppo contiene un numero di versione.Per il GPC, questo numero di versione è memorizzato nell'attributo versionNumber sull'oggetto GPC.Per il GPT, tale numero è memorizzato nel file gpt.ini alla radice di un determinato GPT.Anche il client conserva un record dei numeri di versione dei GPO elaborati (sia per il computer che per l'utente) nel Registro di sistema.Queste informazioni sulla versione vengono conservate in HKLM\Software\Microsoft\Windows\Currentversion\Group Policy\History per il computer e in HKLM\Software\Microsoft\Windows\Currentversion\Group Policy\<SID of User> per l'utente su ciascun client.

Durante l'elaborazione dei Criteri di gruppo, una delle parti deve esaminare i numeri di versione di tutti gli oggetti Criteri di gruppo a cui sono soggetti il computer o l'utente e deve metterli a confronto con quanto elaborato durante l'ultimo ciclo, come rilevato nel Registro di sistema.Se uno qualsiasi dei numeri di versione degli attuali oggetti Criteri di gruppo risulta diverso (si noti che tali numeri devono solo essere differenti, ossia maggiori o minori), tali GPO vengono elaborati durante il ciclo di elaborazione in corso.In caso contrario, non vengono elaborati a meno che non venga riscontrata una delle altre condizioni di modifica.Le altre condizioni di modifica a cui ci si riferisce sono:

• Una modifica dell'elenco dei GPO applicati a un utente o a un computer (è stato aggiunto o rimosso un GPO)
• Una modifica dell'appartenenza al gruppo di protezione di un utente o un computer
• Una modifica di un filtro WMI collegato a un GPO (un filtro WMI è stato aggiunto o rimosso)

Se si riscontra una di queste modifiche delle condizioni, il client rielabora i criteri durante il ciclo.Ma questo processo presenta alcuni aspetti secondari di cui bisogna tener conto, poiché possono avere un impatto significativo sulle prestazioni.Se, per una determinata CSE, 1 GPO su 10 presenta eventuali modifiche, è necessario che vengano elaborati tutti i GPO per questa CSE.Tenere presente che tale elaborazione si verifica per ciascuna CSE.Tuttavia, le CSE devono elaborare i criteri nell'ordine di precedenza con cui vengono elaborati i controlli (prima i GPO locali, in seguito i GPO collegati al sito, i GPO collegati al dominio e infine i GPO collegati all'unità organizzativa).Tenendo presente questo requisito, supponiamo che un utente disponga di 10 GPO, ciascuno collegato a un livello differente della gerarchia di Active Directory.E supponiamo che ciascuno di tali 10 GPO implementi alcune impostazioni dei criteri dei Modelli amministrativi.A questo punto, subentra un amministratore che modifica un GPO collegato al dominio aggiungendo una nuova impostazione dei criteri dei Modelli amministrativi.Nel momento in cui il computer o l'utente inizia l'elaborazione dei criteri, nota subito che il numero di versione del GPO modificato è maggiore rispetto a quello individuato durante l'ultima elaborazione, pertanto è necessario rielaborare il GPO.Ma per rispettare l'ordine di precedenza dell'elaborazione dei Criteri di gruppo, il computer o l'utente deve elaborare tutte le impostazioni dei Modelli amministrativi che si applicano a tutti i GPO.Dunque, una semplice modifica a un GPO può avere un impatto potenzialmente importante sulle prestazioni del client.

Confronto tra le prestazioni dei GPO monolitici e funzionali

Dopo aver preso in esame il ciclo di elaborazione e la modalità con cui le modifiche all'ambiente dei Criteri di gruppo influiscono sull'elaborazione, torniamo alla ai GPO monolitici e funzionali e proviamo a capire in che modo ciascun approccio influisce sulle prestazioni.

Le prestazioni dei GPO monolitici possono essere penalizzate a causa del funzionamento del controllo delle versioni dei Criteri di gruppo.I motivi non sono del tutto ovvi, ma hanno a che vedere con l'assenza del concetto di controllo delle versioni per ciascuna CSE nell'elaborazione dei Criteri di gruppo.Supponiamo che a un utente vengano applicati tre GPO.Ogni GPO è monolitico, nel senso che implementa diverse aree di criteri.Ad esempio, supponiamo che ogni GPO implementi i criteri Modelli amministrativi, Installazione software e Reindirizzamento cartelle.Ora, supponiamo che un amministratore apporti una modifica al criterio Modelli amministrativi in uno di questi GPO.In seguito alla modifica, il numero di versione aumenta.A questo punto, subentra l'utente che elabora i Criteri di gruppo.L'estensione CSE Modelli amministrativi viene avviata e rileva che uno dei GPO è stato modificato, quindi elabora nuovamente gli altri tre.

Durante l'esecuzione delle CSE Installazione software e Reindirizzamento cartelle, vengono presi in considerazione i numeri di versione del GPO e viene subito rilevato il nuovo numero di versione in uno dei GPO.Ma, poiché tale numero di versione non indica l'area dei criteri che è stata modificata, si passa alla rielaborazione di tutti e tre i GPO.Ne risulta che, durante l'implementazione di un GPO monolitico, le modifiche a un'area dei criteri possono causare l'elaborazione in un'altra area.

In realtà, nel caso dei criteri Installazione software o Reindirizzamento cartelle, tali estensioni CSE potrebbero non eseguire effettivamente alcuna elaborazione perché, ad esempio, se un'applicazione è già stata installata non verrà installata nuovamente.Ma il punto è che questo comportamento può verificarsi con qualunque CSE e questo va tenuto in considerazione durante la progettazione dei GPO monolitici.Se nell'area dei criteri si verificano spesso delle modifiche, si potrebbe pensare all'uso di GPO che implementano tale area dei criteri separatamente dalle altre.

Dal punto di vista di un GPO funzionale, le considerazioni sulle prestazioni sono più ovvie.Se si dispone di più GPO per utente o computer (perché l'approccio funzionale interessa in genere più GPO per una determinata serie di impostazioni di criteri), significa che il modulo Criteri di gruppo deve impiegare più tempo per enumerare quei GPO durante la fase principale di elaborazione dei Criteri di gruppo.Tuttavia, come vedremo nella prossima sezione, ciò non implica necessariamente un impatto negativo sulle prestazioni.

Misurazione delle prestazioni dei Criteri di gruppo

Infine, per poter prendere la decisione giusta sulle prestazioni dell'infrastruttura Criteri di gruppo, è necessario essere in grado di misurare le prestazioni dei Criteri di gruppo nell'ambiente reale.Modellare o prevedere le prestazioni dei Criteri di gruppo è quasi impossibile, considerato l'ampio numero di fattori che possono influire su un determinato ciclo di elaborazione.Per questo motivo, la misurazione empirica rappresenta la soluzione migliore per scoprire se le prestazioni dell'elaborazione dei Criteri di gruppo rappresentano un problema.Cosa si intende per peggioramento delle prestazioni?Il peggioramento delle prestazioni si verifica quando l'elaborazione dei Criteri di gruppo influisce negativamente sull'esperienza degli utenti all'interno dei propri sistemi.Questa situazione varia a seconda dell'organizzazione, ma il punto chiave è essere a conoscenza del problema.

Quindi, come misurare la durata di un determinato ciclo di elaborazione dei Criteri di gruppo?Ancora una volta la risposta non è semplice.Se si esegue Windows Vista o Windows Server 2008, è possibile sfruttare i nuovi registri operativi del Visualizzatore eventi.Il registro operativo dei Criteri di gruppo all'interno del Visualizzatore eventi, che si trova in Registri applicazioni e servizi\Microsoft\Windows\Criteri di gruppo\Operativo, fornisce un'eccellente strumentazione di ciascun passaggio del ciclo di elaborazione dei Criteri di gruppo, compreso il tempo impiegato in ogni fase di elaborazione (vedere la Figura 2).

Figura 2** Evento del registro operativo dei Criteri di gruppo che illustra il tempo di elaborazione **(Fare clic sull'immagine per ingrandirla)

Tuttavia, se non si lavora in un ambiente Windows Vista o Windows Server 2008, i meccanismi per calcolare i tempi di elaborazione dei criteri sono meno diretti.In tal caso, è possibile attivare la registrazione dettagliata di userenv (vedere l'articolo del sito Supporto tecnico Microsoft all'indirizzo support.microsoft.com/kb/221833) e visualizzare i timestamp all'interno di questo file relativi a un determinato ciclo di elaborazione o utilizzare i valori presenti nel Registro di sistema sul client che indicano le ore di avvio e di arresto dell'elaborazione dei criteri.Per il computer tali valori sono memorizzati in:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\
Group Policy\State\Machine\Extension-List\
{00000000-0000-0000-0000-000000000000}

mentre per l'utente sono memorizzati in:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\
Group Policy\State\<SID of User>\Extension-List\
{00000000-0000-0000-0000-000000000000}

I valori vengono memorizzati in formato FILETIME e devono essere convertiti in una data e ora di formato normali.Per ottenere le stesse informazioni, è anche possibile utilizzare l'utilità gratuita GPTime.exe (disponibile all'indirizzo gpoguy.com/tools.htm#GP_Time_Utility).

Se non si dispone di un ambiente Windows Vista o Windows Server 2008, ma si ha accesso a un registro userenv, è ancora possibile ottenere informazioni importanti sul tempo impiegato da ogni ciclo di elaborazione dei criteri.Ad esempio, nella Figura 3 viene illustrato un frammento del registro userenv che illustra parte della fase principale dell'elaborazione dei Criteri di gruppo.

Figura 3** Una parte del registro userenv **(Fare clic sull'immagine per ingrandirla)

Tenere presente che ogni riga del file di registro contiene un timestamp.La parte principale del ciclo di elaborazione dei Criteri di gruppo comincia quando viene visualizzato un evento del tipo ProcessGPOs che indical'inizio dell'elaborazione (in background) dei Criteri di gruppo per un utente.La parte CSE del ciclo di elaborazione inizia quando viene visualizzata la riga ProcessGPOs che indical'elaborazione del Registro di sistema delle estensioni.È possibile utilizzare questo registro e il timestamp per determinare la durata di ciascuna parte di un ciclo di criteri.

Osservazioni generali sulle prestazioni

Se si impiega troppo tempo per esaminare i file di registro userenv, vengono visualizzati i primi modelli e sebbene non sia possibile prevedere la durata dell'elaborazione dei criteri, è possibile fare delle osservazioni di carattere generale su come viene impiegato il tempo in un determinato ciclo di elaborazione.Ad esempio, durante un evento di elaborazione dei criteri, quando vengono apportate modifiche ai criteri e, a causa di tali modifiche, le estensioni CSE devono eseguire altre operazioni, il tempo impiegato nella parte principale di elaborazione dei Criteri di gruppo è in genere molto inferiore rispetto al tempo impiegato per la parte dell'estensione CSE.

Ciò vale per quasi tutte le aree dei criteri perché la maggior parte delle estensioni CSE deve eseguire attività che richiedono più tempo rispetto all'elaborazione della parte principale, le cui attività più dispendiose risultano le query ad Active Directory e SYSVOL.Ad esempio, non c'è paragone tra il tempo impiegato per l'elaborazione principale rispetto al tempo impiegato per un'estensione CSE Installazione software che esegue un'installazione di Microsoft® Office.Tuttavia, per un aggiornamento in background dei criteri dove nulla è stato modificato dall'ultimo ciclo di elaborazione, il tempo impiegato dalla parte principale del ciclo di elaborazione è quasi lo stesso rispetto al tempo impiegato per la parte dell'estensione CSE.L'unica eccezione è rappresentata dall'elaborazione dei criteri del Registro di sistema. Tale operazione è piuttosto rapida, a meno che non siano presenti decine o centinaia di impostazioni dei criteri del Registro di sistema per un determinato utente o computer.

Inoltre, disattivando la parte del computer o dell'utente di un GPO a causa del mancato utilizzo, non vi sono effetti evidenti sulle prestazioni dell'elaborazione dei criteri.Se non si utilizza una parte del criterio, l'unico overhead è rappresentato dall'esecuzione di query in Active Directory. La stessa query deve essere eseguita per visualizzare l'opzione di disattivazione, come quella utilizzata per stabilire se sono state implementate estensioni CSE per quella parte di GPO.L'effetto della disattivazione di una parte è irrilevante.

Consigli sulla progettazione per ottimizzare le prestazioni dei Criteri di gruppo

Dopo aver preso in esame diversi aspetti delle prestazioni dell'elaborazione dei Criteri di gruppo, di seguito vengono riportati alcuni consigli per la progettazione che possono influire direttamente sulle prestazioni.Tali consigli sono raggruppati in quattro punti principali.

1. Se si apportano modifiche frequenti ai GPO, non ci si deve dimenticare degli effetti descritti in precedenza, laddove una modifica a un'estensione CSE può influire sull'elaborazione di tutte le estensioni CSE.A tal fine, se si pianificano modifiche frequenti ai criteri del Registro di sistema, ad esempio, è più opportuno inserire i criteri del Registro di sistema in GPO funzionali (GPO che eseguono solo i criteri del Registro di sistema) in quanto, nel momento in cui viene apportata una modifica, tali GPO impediscono l'elaborazione delle altre estensioni CSE.
2. Per calcolare quando il numero di GPO è da considerarsi eccessivo, tenere presente che l'elaborazione dei criteri si verifica soltanto durante le modifiche, pertanto le estensioni CSE "costose" come Installazione software e Reindirizzamento cartelle, la gestione di diversi criteri del Registro di sistema o l'impostazione delle autorizzazioni su file o Registri di sistema di grandi dimensioni impiegano gran parte del tempo.Il tempo impiegato per sottoporre a query Active Directory, in modo da ottenere l'elenco di GPO durante l'elaborazione principale, rappresenta spesso la parte minore del ciclo di elaborazione.Pertanto, il tempo per elaborare 30 GPO che si applicano a un determinato utente, ma che eseguono modifiche minime ai criteri del Registro di sistema e che non cambiano frequentemente, dovrebbe essere inferiore rispetto all'elaborazione di 5 GPO che eseguono regolarmente estensioni CSE costose, perché tali GPO cambiano frequentemente.
3. Evitare i comportamenti che causano rallentamenti ovvi nelle prestazioni dell'elaborazione dei criteri.Ad esempio, è possibile stabilire che un criterio forzi l'elaborazione delle estensioni CSE anche se non è stato modificato alcun GPO (in Configurazione computer\Modelli amministrativi\Sistema\Criteri di gruppo).Tuttavia, se si esegue questa operazione, l'elaborazione dei criteri dura più a lungo durante ogni ciclo.
4. Tenere presente le conseguenze derivanti dalla disattivazione dell'opzione di ottimizzazione rapida dell'accesso in Windows XP e Windows Vista (viene effettuata attivando i criteri in Configurazione computer\Modelli amministrativi\Sistema\Accesso\Attendi sempre disponibilità rete all'avvio e all'accesso).Una volta attivati tali criteri, l'elaborazione in primo piano da asincrona diventa sincrona.Ciò significa che i criteri del computer e dell'utente devono essere completati prima che l'utente assuma il controllo del computer e del desktop.Tuttavia, tutto ciò potrebbe risultare vantaggioso perché viene risolto il problema di eseguire due o più riavvii o accessi per i criteri Installazione software e Reindirizzamento cartelle.

Conclusioni

Nonostante le prestazioni di elaborazione dei Criteri di gruppo non rappresentino una scienza esatta, esistono alcune informazioni sul processo di progettazione che consentono di attenuare i problemi relativi alle prestazioni.

Per capire come funziona il ciclo di elaborazione e come viene impiegato il tempo la strada è lunga ed è necessario tenere traccia dei problemi relativi alle prestazioni.Utilizzare i registri operativi di Windows Vista o Windows Server 2008 (o i registri userenv delle prime versioni di Windows) per ottenere informazioni instrumentate sul ciclo di elaborazione.Non trascurare gli aspetti bizzarri dell'elaborazione dell'estensione CSE e cosa si intende per modifica dei criteri dal punto di vista delle CSE.E ricordare che, negli ambienti dinamici in cui vengono eseguite molte modifiche, i GPO funzionali potrebbero essere più adatti rispetto a quelli monolitici.In conclusione, i Criteri di gruppo rappresentano una tecnologia progettata per consentire una migliore gestione dell'ambiente Windows.È molto importante che la progettazione dei Criteri di gruppo dipenda dalle esigenze aziendali e non il contrario.Ricordarsi, inoltre, che i comportamenti delle prestazioni analizzati nel presente articolo consentono di soddisfare tale obiettivo.

Darren Mar-Eliaè un MVP per i Criteri di gruppo Microsoft, creatore del famoso sito Criteri di gruppo (www.gpoguy.com) e coautore di Microsoft Windows Group Policy Guide (Microsoft Press, 2005).È anche direttore tecnico e fondatore di SDM Software, Inc. Può essere contattato all'indirizzo Darren@gpoguy.com.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.