Attraverso le Group Policy (che indicherò da ora semplicemente con la sigla GP) è possibile configurare ogni aspetto del funzionamento dei computer connessi alla nostra rete aziendale.
La loro estrema potenza può in alcuni casi, se usate con scarsa attenzione/progettazione e senza seguire delle “buone pratiche”, generare problemi agli utenti finali nell’accesso alle risorse locali o remote, nell’usabilità del sistema o nell’accesso ai dati.
Risalire alla GP che causa di questi problemi può non essere un’operazione ******.
In questo breve articolo cercherò di mostrare alcune tecniche e strumenti disponibili per fare l’****** dei problemi legati alle GP.
Link correlati
• Implementing Common Desktop Management Scenarios with the Group Policy Management Console (in inglese)
• Group Policy Infrastructure White Paper (in inglese)
• Deployment considerations for Group Policy
• Introduction to Group Policy in Windows Server 2003
• http://www.gpoguy.com
In questa pagina
Come funzionano le GPO?
Ricerca dei problemi
Alcuni esempi di problemi e possibili soluzioni
Conclusioni
Come funzionano le GPO?
Il primo vero strumento per la ricerca e la comprensione dell’origine dei problemi è la conoscenza delle tecnologie e degli strumenti utilizzati; penso sia quindi importante, prima d’ogni altra cosa, fare un riassunto del funzionamento delle GP, senza per altro la pretesa di essere esaustivo.
Cosa sono le GP e dove sono conservate
Ogni singola GP è un insieme di impostazioni che può essere applicato per configurare un ambiente di lavoro, in base all’utente e/o in base alla macchina.
Le impostazioni presenti in una GP sono divise in due sezioni separate (Figura1):
• Computer Configuration: applicata al computer qualsiasi sia l’utente che esegue il logon
• User Configuration: applicata all’utente indifferentemente dal computer su cui esegue il logon
In ogni GP entrambe le sezioni possono essere utilizzate, e contenere delle impostazioni abilitate, o in alternativa si può usare una sola delle due sezioni disabilitando l’altra; in questo caso avremo delle GP “dedicate” agli utenti (nel caso si disabiliti la parte Computer Configuration) e delle GP “dedicate” ai computer (nel caso si disabiliti la parte User Configuration) e una più rapida applicazione e ****** delle singole GP.
Le GP sono conservate, in un dominio Active Directory, come oggetti (Group Policy Object o GPO).
Ogni GPO è costituito da due elementi distinti:
• Group Policy Container:
• è mantenuto in Active Directory nel container cn=Policy, cn=System, dc=Domain, dc=domain (Figura 2)
• contiene informazioni generali relative alla GP (es. “friendly name”, percorso al GPT, configurazione Wireless,...) (Figura 3)
• è referenziato da un GUID che individua univocamente la GP a livello di foresta
• Group Policy Template:
• è rappresentato da una struttura di directory e file su disco deputata a mantenere le diverse impostazioni indicate nella GP
• tutti i GPT sono conservati sotto lo share di rete SYSVOL replicato su tutti i Domain Controller
• ogni GPT inizia con un subfolder di SYSVOL\<nome del dominio AD>\Policies con nome corrispondente al GUID della GP collegata
• all’interno del folder con nome uguale al GUID della GP, troviamo normalmente la struttura presentata in Figura 4.
• La cartella ADM contiene il file ADM usati per costruire la parte Administrative Templates della policy
• La cartella Machine contiene le impostazioni relative alla parte Computer Configuration della GP
• La cartella User contiene le impostazioni relative alla parte User Configuration della GP
• Il file GPT.INI contiene informazioni relative alla versione e al display name della GP
Figura 1: Struttura di una GP Ingrandisci immagine
Figura 2: Group Policy Container Ingrandisci immagine
Figura 3: Group Policy Template Ingrandisci immagine
In funzione del tipo di dato da salvare, alcune parti delle GP sono salvate sia nel GPT sia nel GPC, altre solo nel GPC, altre ancora (es. le policy di IPSec) in nessuno dei due.
Area della Policy Posizione dello Storage
Wireless In GPC sotto
cn=wireless,cn=Windows, cn=Microsoft,cn=Machine, cn=<GUID della GP>,cn=System, dc=<Dominio>
in un oggetto di classe msieee80211-Policy
(Solo Windows Server 2003)
Folder Redirection In GPT, in un file chiamato fdeploy.ini, nel folder ...\user\Documents and Settings
Administrative Template In GPT, in un file chiamato registry.pol in entrambi i folder
..\user e ...\machine
Disk Quota In GPT, sempre in registry.pol, ma solo sotto il folder ...\machine
Scripts In GPT; gli script di Startup e Shutdown sono conservati nei seguenti folder:
...\machine\scripts\startup
...\machine\scripts\shutdown
Gli script di Logon e Logoff sono salvati nei folder:
...\user\scripts\logon
...\user\scripts\logoff
Internet Explorer In GPT, nel folder
…\user\Microsoft\IEAK
Security In GPT, dentro un file chiamato gptTmpl.inf nel folder
...\machine\Microsoft\Windows NT\SecEdit
Software Installation Sia in GPT sia in GPC;
In GPT sotto i folder
...\user\Applications
...\machine\Applications
In GPC nel container
cn=Packages,cn=Class Store,cn=Machine (o cn=User), cn=<GUID della Policy>, cn=System, dc=<Dominio> come oggetto packageRegistration
Software Restriction Policy In GPT, dentro il file registry.pol
IP Security Ne in GPC ne in GPT; Salvate in AD nel container cn=IP Security, cn=System, dc=<Dominio>
Figura 4: Struttura di un GPT Ingrandisci immagine
La gestione della versione delle GPT
Ad ogni GP è associato un numero di versione che viene utilizzato principalmente nella fase di replica dei dati tra Domain Controller.
Il numero di versione di una GP è mantenuto in due diversi posti:
• nell’attributo versionNumber dell’oggetto GPC in Active Directory
• nel file GPT.INI nel folder radice della GP sotto SYSVOL
In Windows 2000, i numeri di versione contenuti nel GPT e nel GPC devono coincidere perché le policy possano essere processate ed applicate. Problemi legati alla replica di Active Directory o alla replica del folder SYSVOL possono rendere i due numeri di versione diversi su un dato Domain Controller.
Windows Server 2003 e Windows XP non presentano più questo problema e le policy vengono processate anche se i numeri di versione in GPT e GPC non corrispondono.
Il numero di versione di una GP viene incrementato secondo la formula:
Versione = 65536 * (Numero di modifiche alla parte User Configuration) + Numero di modifiche alla parte Computer Configuration
Come vengono applicate le GPO
Il primo concetto fondamentale da capire riguardo all’applicazione delle GP è che questo è un processo eseguito strettamente lato client. I Domain Controller fungono solo da storage delle configurazioni e dei permessi.
Il processo di applicazione avviene in due fasi:
• GP core: è la fase in cui il sistema operativo client determina quali GP devono essere applicate alla macchina/utente e chi le deve applicare.Le GP possono essere collegate a diversi container di Active Directory e delle Local Policy possono essere definite sulla macchina locale. Ad ogni oggetto di Active Directory (user o computer) possono, quindi, essere applicate più di una GP. In questi casi esiste una gerarchia di applicazione che è determinata durante la fase GP core.Facendo riferimento alla Figura 5 l’ordine di applicazione delle GP per una macchina/utente che risiede nella Organizational Unit OU2a è il seguente:
• Local Policy definita sulla singola macchina (LP-1)
• Policy di Sito (GP-1)
• Policy di Dominio (GP-3 e poi GP-2)
• Policy connesse ai diversi livelli di Organizational Unit (GP-6, GP-5 e per ultima GP-4)
È evidente, da quanto descritto, che se, ad un qualsiasi livello, sono collegate più policy queste vengono applicate leggendo dal basso verso l’alto la lista mostrata nell’interfaccia di gestione delle GP. Nel caso in cui policy diverse configurino in modo dissimile lo stesso parametro, la policy applicata per ultima ha il sopravvento.Queste regole di applicazione possono essere sovvertite dai meccanismi di “Non-Sovrascrittura” e di “Blocco dell’ereditarietà” per i la descrizione dei quali si rimanda ai documenti riportati nel paragrafo Risorse.
• CSE (Client Site Extensions): è la fase in cui le diverse GP sono realmente applicate richiamando le opportune DLL (le CSE)
Le CSE vengono fornite con Windows e sono registrate sotto la chiave di registry
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions
È possibile sviluppare proprie CSE che eseguano l’applicazione di GP personalizzate. Nel caso si decida di scrivere proprie CSE, deve essere posta molta attenzione nello sviluppo del codice in quanto le extension sono eseguite nel contesto di Winlogon e quindi eventuali bug possono creare seri problemi all’intero sistema.
Figura 5: Gerarchia di applicazione delle GP Ingrandisci immagine
Policy Client Side Extensions
Wireless Gptext.dll
Folder redirection Fdeploy.dll
Microsoft disk quota Dskquota.dll
QoS packet scheduler Gptext.dll
Scripts Gptext.dll
Internet Explorer zone mapping Iedkcs32.dll
Security Scecli.dll
Internet Explorer branding Iedkcs32.dll
EFS recovery Scecli.dll
Microsoft offline files Cscui.dll
Software installation Appmgmts.dll
IP Security Gptext.dll
Vediamo ora, passo passo, come avviene il processo di applicazione delle GP:
• I client eseguono una richiesta DNS alla ricerca del record SRV che indica un server LDAP (un DC) nel proprio sito
• Il client si connette al DC usando un normale processo di DC Locator
• Il client esegue una verifica della velocità della connessione verso il DC usando ICMP
• Il client usa LDAP per costruire le liste di GPO per la OU, il dominio e il sito di appartenenza e determina se ha il permesso di processare le diverse GPO (permessi necessari Read e Apply per l’utente/macchina a cui si applica la policy)
• Il client usa LDAP per ricavare dai GPC il percorso dove trovare i relativi GPT, il numero di versione e le CSE implementate
• Il client usa SMB per interrogare il GPT, avere il percorso di gpt.ini e determinare il numero di versione
• Ogni CSE è eseguita nell’ordine in cui sono registrate e processano le GPO se e solo se queste sono cambiate rispetto all’ultimo ciclo di applicazione (determinato dalla fase di Core processing
• Se le GPO risultano modificate, le CSE processano le nuove impostazioni e quindi si passa alla successiva CSE fino al completamente
• Ogni CSE passa a Windows Management Instrumentation (WMI) i dati necessari ad eseguire le operazioni di Resultant Set of Policy (RSoP)
Il processo descritto può avvenire in due diverse modalità:
• Foreground: è eseguito durante l’avvio del computer o il logon dell’utente e può essere asincrono o sincrono:
• Win 2000 ha come default il processamento sincrono
• Win XP/2003 ha come default il processamento asincrono
Background: è eseguito periodicamente in base al ruolo del computer (ogni 5 minuti per i DC, ogni 90 minuti più o meno un valore random di minuti compreso tra 0 e 30 per gli altri membri del dominio). L’applicazione delle GP in background è asincrono per definizione.
Inizio pagina
Ricerca dei problemi
Dalla descrizione del processo di applicazione delle GP, è evidente che ci possono essere diverse fonti di problemi che possono impedirne il corretto funzionamento.
Alcune situazione apparentemente erronee sono in realtà comportamenti corretti:
• Alcune CSE non applicano le GP in presenza di link lenti verso il DC (es. Installazione di SW, redirezione dei folder). Questo comportamento è configurabile via GP
• Alcune GP sono processate in modo asincrono, ma non fanno nulla fino al successivo evento sincrono (es. scripts)
• Nessuna CSE processerà le proprie policy se non ci sono state modifiche dall’ultimo ciclo di applicazione. Questo è determinato confrontando il numero di versione delle GP con un numero di versione mantenuto nel registry del client
In altri casi il problema potrebbe non essere direttamente legato alle GP.
Problemi non legati alle GP
Ci sono diversi problemi legati all’infrastruttura e alla configurazione del client che possono avere un impatto sulla possibilità di applicazione delle GP.
Problemi di raggiungibilità dei DNS server
La prima cosa da verificare è la possibilità per il client di raggiungere il server DNS.Durante la fase di applicazione delle GP il cliente deve fare ripetuti accessi al DNS alla ricerca di diversi record SRV relativi a LDAP.
Per verificare la disponibilità del DNS server e la corretta configurazione del client basta lanciare nslookup da una shell; ci si deve aspettare una risposta come quella riportata in Figura 6.
Figura 6: Verifica funzionamento DNS Ingrandisci immagine
Problemi di raggiungibilità dei Domain Controller
La possibilità di contattare i DC è fondamentale per la corretta applicazione delle GP.
La prima cosa da verificare è la possibilità di contattare un Domain Controller.
Il semplice logon dell’utente alla macchina non fornisce indicazioni definitive (potrebbe aver fatto logon con credenziali in cache) e si deve quindi verificare la possibilità di eseguire un ping verso il DC o di accedervi in altro modo.
Una volta stabilito che il client e il DC possono dialogare correttamente si deve verificare che nel DNS il DC sia correttamente registrato.
In fase di applicazione delle GP il client eseguirà una query DNS alla ricerca del record SRV che specifica un LDAP server nel sito di appartenenza:
_ldap._tcp.<SITO_DI_APPARTENENZA>._sites.dc._msdcs.<NOME_DEL_DOMINIO>
Se questo record non viene correttamente trovato e risolto, l’applicazione delle GP non può essere eseguita.
Per verificare la corretta risoluzione del record indicato è necessario eseguire una query DNS usando nslookup come riportato in Figura 7.
Figura 7: Verifica della raggiungibilità dei Domain Controller Ingrandisci immagine
Problemi di replica del folder SYSVOL
La cartella SYSVOL contiene i subfolder relativi ai GPT delle diverse GP.
Questo folder deve essere mantenuto allineato tra tutti i Domain Controller per non avere problemi nell’applicazione delle policy (es. problemi di versione delle policy con Windows 2000).
Un tool utile per l’****** dei problemi di FRS è Ultrasound scaricabile al link:
http://www.microsoft.com/downloads/deta ... layLang=en
L’****** dei problemi di funzionamento esula dagli scopi di questo articolo, ma alcune delle operazioni che possono essere compiute sono:
• Assicurarsi che i DC abbiano il servizio File Replication Service attivo
• Assicurarsi che SYSVOL sia condiviso (fare riferimento agli articoli KB 257338 e 315457 per la risoluzione dei problemi legati a SYSVOL)
• Usare GPOTool (presente nel Resource Kit) per confrontare il numero di versione dei GPT sui DC: gptool /verbose
• In caso di urgenza si possono copiare I file a mano tra i diversi DC
Problemi con ICMP
Come detto in precedenza alcune CSE non applicano le GP in presenza di un link lento. Per default il discrimine tra link lento e veloce è posto a 500Kbps. La determinazione della velocità è fatta eseguendo dei ping verso il Domain Controller da cui verranno scaricate le GP.
Se il protocollo ICMP è disabilitato lato client o lato server l’applicazione delle GP viene interrotta.
La prima soluzione possibile è ovviamente riabilitare il protocollo ICMP tra client e DC. Se questo non è possibile si deve intervenire disabilitando la verifica della velocità del link.
Questa ultima operazione può essere fatta impostando a 0 le due policy:
• Computer Configuration\Administrative Templates\System\Group Policy\Group Policy Slow Link Detection
• User Configuration\Administrative Templates\System\Group Policy\Group Policy Slow LinkDetection
Se l’applicazione delle policy non funziona in toto questo metodo ovviamente non risolverà il nostro problema e dovremo intervenire impostando a 0, direttamente sul client, le voci di registry:
• GroupPolicyMinTransferRate in HKLM\Software\Policies\Microsoft\Windows\System\
• GroupPolicyMinTransferRate in HKCU\Software\Policies\Microsoft\Windows\System\
Un altro problema con il protocollo ICMP può presentarsi nel caso dei router o dei firewall posti tra il DC e il client limitino la dimensione dei pacchetti ICMP consentiti. Il problema è descritto nel documento http://support.microsoft.com/default.as ... -us;816045
Problemi legati alle GP
Dopo aver verificato che i problemi di applicazione delle GP non sono legati all’infrastruttura, si deve procedere all’****** del processo di applicazione delle GP per risalire alla causa.
In questa ****** ci sono di aiuto alcuni tool disponibili con il sistema operativo, il Resource Kit o liberamente scaricabili da internet.
Il miglior strumento disponibile per l’****** dei problemi legati all’applicazione delle GP è il log degli eventi.
Esistono sostanzialmente due tipi di log legati all’applicazione delle GP:
• Application Event Log su ogni client
• Log specifico per ogni CSE
Uso dell’Application Log sui client
Gli Application Event legati alle GP sono generati dalle seguenti sorgenti:
• Userenv: genera la maggior parte degli eventi legati alla fase GP core
• Scecli: Eventi legati alle CSE per la sicurezza
• Appmgmt o Application Manager: Eventi legati all’installazione di software via GP
• UserInit: Eventi legati agli script
• Folder Redirection: Folder Redirection event
È possibile utilizzare la Group Policy Management Console per ****** gli eventi relativi all’applicazione delle policy su qualsiasi macchina in rete: gli eventi mostrati saranno solo quelli relativi all’applicazione delle policy (Figura
.Per aumentare la quantità di informazioni riportate nel log Application è possibile impostare ad uno (1) la seguente voce di registry:
• RunDiagnosticLoggingGroupPolicy (DWORD) in
HKLM\Software\Microsoft\Windows NT\Diagnostics\
L’abilitazione della modalità diagnostica può causare problemi di performance e quindi deve essere abilitata solo in caso di reale necessità.
In alcuni casi, malgrado l’abilitazione della modalità diagnostica, le informazioni riportate nel log Application non sono sufficienti per determinare con esattezza dove risieda il problema.
In questi casi è necessario abilitare il log esteso degli eventi per le singole CSE.
Figura 8: Uso di GPMC per l'****** di errori di applicazione delle GP Ingrandisci immagine
Uso dei log estesi
L’abilitazione dei log estesi richiede la modifica delle voci di registry riportate nei seguenti articoli:
• Abilitazione di userenv.log
http://support.microsoft.com/default.as ... -us;221833
• Abilitazione dei log per Scecli
http://support.microsoft.com/default.as ... -us;245422
• Abilitazione dei log per la redirezione dei folder
http://support.microsoft.com/default.as ... -us;246509
In realtà, è disponibile un metodo più semplice per l’abilitazione del log Application esteso e dei log per le singole CSE. Questo funziona solo se le policy funzionano almeno parzialmente.
Al link http://www.gpoguy.com/tools.htm è disponibile il file gpolog.adm che consente l’abilitazione di tutti i log estesi per le GP.
Per utilizzare questo file:
• Scaricarlo dal sito indicato
• Creare una nuova policy e collegarla alla OU entro cui si trovano le macchine/utenti per i quali si vuole abilitare il log esteso.
• Espandere il ramo Computer configuration
• Fare click con il tasto destro del mouse su Administrative Template e, dal menù contestuale, scegliere l’opzione Add/Remove Templates
• Nella finestra di dialog Add/Remove Templates cliccare il bottone Add e navigare nel file system fino a trovare il file gpolog.adm
• Selezionare il file e premere OK
• In Group Policy Object Editor espandere il menù View e selezionare Filtering
• Nella finestra di dialogo Filtering deselezionare l’opzione Only show policy settings that can be fully managed (Figura 9)
• A questo punto sono disponibili, sotto Computer Configuration\Administrative Templates\System\Group Policy\Logging, una serie di policy per l’abilitazione dei log estesi delle CSE (Figura 10).
Attenzione
Le policy di attivazione dei log estesi delle CSE sono di tipo non gestito e quindi devono essere esplicitamente disabilitate prima di eliminare la policy che le ha attivate. In caso contrario si ottiene l’effetto “tatuaggio” e le policy resteranno in essere a meno che si intervenga manualmente sulle voci di registry relative.
Figura 9: Abilitazione dei log per le CSE – 1 Ingrandisci immagine
Figura 10: Opzioni di abilitazione dei log CSE fornite da gpolog.adm Ingrandisci immagine
Il log di Userenv.log è il più prolisso ma anche il più utile per l’****** dei problemi e viene salvato (come gli altri) in %windir%\debug\usermode\.
All’interno possiamo trovare il log dell'applicazione delle GP e dello user profile; può essere un po’ criptico da comprendere, ma dettaglia ogni passaggio del processo di applicazione delle GP.
In fase di ****** del problema, dopo aver attivato le I log estesi delle CSE, rinominate il file userenv.log e quindi forzate la riapplicazione delle policy per avere un nuovo log (usare gpupdate /force su WinXP e Win2003; secedit su Win2000).
Figura 11: userenv.log Ingrandisci immagine
Altri tool di ****** dei problemi
Ci sono altri tool che possono essere di grande aiuto nell’****** dei problemi legati alle GP:
• Gptool.exe: questo tool, parte del Resource Kit di Windows Server 2003, può essere utilizzato, anche da remoto, per ****** le policy realmente applicare ad un computer e/o un utente. Se usato con lo swich /verbose una parte delle informazioni restituite dalla GPMC e tra le altre il numero di versione delle singole policy così come registrato dal GPT e dal GPC (Figura 12).
• Replmon.exe: questo tool, parte dei Support Tool presenti sul CD di installazione di Windows Server 2003, consente di verificare il buon funzionamento delle repliche tra i diversi Domain Controller ed è quindi utile in tutte quelle situazioni in cui sono presenti informazioni diverse sui diversi DC.
• Snap-in Resultant Set of Policy: questo snap-in (parte integrante di Windows Server 2003) consente di fare l’****** delle policy effettivamente applicate. È possibile in questo modo tracciare problemi legati all’uso del flag Enforced sulla policy o del flag Block Inheritance sul link. Informazioni simili, ma più estese, possono essere ottenute usando il tool a linea di comando gpresult (parte del sistema operativo) o la Group Policy Management Console (GPMC) scaricabile al link:
http://www.microsoft.com/downloads/deta ... layLang=en
• ADDiag.exe: questo tool, installabile con i Support Tools presenti sul CD di Windows Server 2003, fornisce informazioni sullo stato del software installato, o disponibile per installazione, su un computer gestito con la tecnologia Intellimirror Software Installation and Maintenance. Le informazioni fornite sono le seguenti:
• Utente (credenziali di logon e SID) e piattaforma (processore e località) che possono influenzare l’installazione del software
• La presenza o meno di Terminal Server in esecuzione sul computer
• Informazioni sull’installazione o la disponibilità di software, dedotte da voci di registry
• La presenza di software disponibile per l’installazione via Active Directory
• Informazioni relative a Windows Installer
Figura 12: Numero di versione delle GP restituito da gpotool Ingrandisci immagine
Inizio pagina
Alcuni esempi di problemi e possibili soluzioni
Errata assegnazione dei permessi
Perché le GP siano applicate, i computer/utenti a cui devono essere applicate devono avere i diritti di Read e Apply sul policy link
La funzione Resultant Set of Policy della GPMC, e del tool a line di comando gpresult, consente di verificare facilmente se sono state assegnate correttamente le policy per un dato utente.
Un altro problema che può sorgere è legato all’errata assegnazione di permessi sullo share SYSVOL, da cui vengono letti i file che contengono le impostazioni delle policy. In questo caso all’utente può comparire un messaggio di accesso negato. Per verificare la corretta impostazione dei diritti di accesso è di grande utilità gpotool /checkacl /verbose. Fare riferimento agli articoli KB 257338 e 315457 per la risoluzione dei problemi legati a SYSVOL.
Servizio TCP/IP Netbios Helper disattivato
Quando il servizio TCP/IP Netbios Helper è disattivato nessuna GP è processata e nei log sono presenti errori relativa alla lettura di gpt.ini o altri file del GPT.
Per risolvere il problema si deve verificare che il computer client abbia il servizio TCP/IP Netbios Helper attivo che è necessario per risolvere il percorso UNC al GPT
Problema nella redirezione dei folder
Il problema si manifesta con l’impossibilità da parte dell’utente di applicare la policy di redirezione dei folder.
Nella maggior parte dei casi il problema si presenta quando la policy è impostata per creare un folder per ogni utente (uso della macro %username% nella definizione del folder di redirezione) e l’utente non ha tale diritto nel folder parent.
Ci si deve assicurare che l’utente abbia il diritto di creazione di folder nello share di appoggio. Consultare l’articolo KB 274443 per verificare i permessi necessari
Problemi di installazione del software via GP
Il problema si manifesta con l’impossibilità di installare correttamente le applicazioni usando le policy di Software Installation oppure con la necessità di eseguire diversi riavvii/logon utente perché si applichino.
In questo caso si devono verificare diverse cose
• di aver inserito, durante la creazione della policy, un UNC come percorso di distribuzione del pacchetto e non una directory locale al server
• che non si sia in presenza di un link lento (o visto come tale)
Se sono necessari più logon o riavvii per vedere applicata la distribuzione del software via policy, provare a disabilitare la Fast Logon Optimization (solo XP) abilitando la seguente policy:
Computer Configuration\Administrative Templates\System\Logon\Always wait for the network at computer startup and logon
