Script di login non eseguiti saltuariamente

A volte può accadere che al login dell’utente lo script di logon non venga eseguito, mi è capitato di vedere personalmente questo scenario oltre che di leggere esperienze in tal senso sui Forum di Sysadmin.it.

Il motivi che possono generare un tale malfunzionamento possono essere svariati ed escludendo quello più banale ovvero un errore nello script le causa più comune è quella in cui lo script non viene avviato piuttosto che un errore nell’esecuzione dello stesso.

Il mancato avvio dello script di avvio/logon è di solito legato a problematiche di rete come ad esempio:

• Rete lenta a causa di problemi su apparati, cavi o infrastruttura di rete con collegamenti che passano attraverso più apparati, tratte a diversa velocità o loop che causano l’intervento dello Spannig Tree.
• Servizi di rete sul computer avviati in ritardo rispetto alla procedura di avvio/logon che viene eseguita in background e non può quindi accedere alla share SYSVOL del domain controller per l’avvio degli script. I motivi per cui ciò può succedere sono svariati e spesso saltuari e possono essere causati da:
• Esecuzione di una procedura di inizializzazione a seguito dell’installazione di un aggiornamento di sistema tramite Windows Update o WSUS
• Una scansione all’avvio eseguita dall’antivirus che può durare più del dovuto a causa di file temporanei corposi causati dalla sessione di lavoro precedente
• Un rallentamento all’avvio dovuto ai programmi/servizi ad avvio automatico o alla frammentazione del partizione di avvio del sistema

Se la causa è la mancanza della rete nel momento in cui la procedura di avvio/logon prevede l’esecuzione dello script è possibile provare ad ovviare a tale problematica abilitando la GPO Computer Always wait for the network at computer startup and logon in Administrative Templates\System\Logon.

Tale GPO impone l’attesa della rete durante l’avvio del computer e l’accesso dell’utente infatti per default il sistema non attende l’inizializzazione completa della rete all’avvio e all’accesso utente, gli utenti esistenti si connettono utilizzano le credenziali memorizzate nella cache, con tempi di accesso più brevi e i criteri di gruppo vengono applicati in background quando la rete diventa disponibile.

Tale GPO è stata introdotta in Windows XP (nei sistemi precedenti quali Windows 2000 veniva sempre attesa la completa inizializzazione della rete prima dell’accesso) inoltre nella descrizione della GPO viene riportato quanto segue:

“A causa dell’aggiornamento in background, le estensioni quali Installazione software e Reindirizzamento cartelle richiedono due accessi per applicare le modifiche. Per operare in modo sicuro, tali estensioni richiedono che nessun utente sia connesso. Pertanto, è necessario elaborarle in primo piano prima che gli utenti utilizzino attivamente il computer. Inoltre, è possibile che il rilevamento delle modifiche apportate all’oggetto utente, ad esempio l’aggiunta del percorso di un profilo comune, di una home directory o di uno script di accesso oggetto utente, richiedano due accessi.

Se un utente con un profilo comune, una home directory o uno script di accesso oggetto utente si connette a un computer, Windows XP attende sempre l’inizializzazione della rete prima di consentire l’accesso dell’utente (*).

Se un utente si connette al computer per la prima volta, Windows XP attende sempre l’inizializzazione della rete.

Se si attiva questa impostazione, gli accessi vengono eseguiti allo stesso modo dei client Windows 2000, in quanto Windows XP attende l’inizializzazione completa della rete prima di consentire l’accesso degli utenti. I criteri di gruppo vengono applicati in primo piano, in modo sincrono.

Se si disattiva o non si configura questa impostazione, Windows non attende l’inizializzazione completa della rete e gli utenti si connettono con le credenziali memorizzate nella cache. I criteri di gruppo vengono applicati in modo asincrono in background.

Nota: se si desidera garantire che l’applicazione di Reindirizzamento cartelle, Installazione software o delle impostazioni del profilo utente comune avvenga con un solo accesso, attivare questa impostazione in modo che Windows attenda che la rete sia disponibile prima di applicare i criteri.

Nota: per i server, l’elaborazione dell’avvio e dell’accesso presuppone sempre l’attivazione dell’impostazione del criterio.

(*) Nella descrizione si parla di script di accesso oggetto utente sembrerebbero quindi esclusi gli script impostati direttamente sull’utente ed è proprio in questo scenario che mi è capitato di verificare la mancata esecuzione saltuaria degli script.

Si ricordi che impostando la policy Always wait for the network at computer startup and logon questa sarà attiva al secondo accesso infatti al primo questa verrà scaricata e applicata e al secondo il sistema attenderà quindi la disponibilità della rete prima di eseguire l’accesso.

Per ulteriori informazioni si vedano:

• Description of the Windows XP Professional Fast Logon Optimization feature
• Troubleshooting the intermittent slow logon or slow startup

Un’altra possibile causa potrebbe essere legata alle funzionalità TCP Chimney e RSS, spesso infatti i driver di rete non implementato correttamente tali nuove funzionalità di rete per risolvere il problema è possibile verificare se esistono driver aggiornati per i computer client che manifestano il problema oppure è possibile disabilitare tali funzionalità nel caso non di particolare interesse sui client interessati a riguardo si veda Error message when an application connects to SQL Server on a server that is running Windows Server 2003: “General Network error,” “Communication link failure,” or “A transport-level error”.

Inoltre va tenuto presente che alcuni servizi possono non essere compatibili con la funzionalità TCP Chimney e causare quindi malfunzionamenti, a riguardo si veda la seguente KB per Windows Server 2008 Information about the TCP Chimney Offload, Receive Side Scaling, and Network Direct Memory Access features in Windows Server 2008.

A riguardo segnalo anche una hotfix che è stata rilasciata per Windows 7 e Windows Server 2008 R2 che va a risolvere problematiche legate al TCP Chimney Offload in presenza di elevati carichi di rete che potrebbero verificarsi non tanto sul client, ma sul Domain Controller The TCP Chimney Offload feature fails on all network adapters in Windows Server 2008 R2 or in Windows 7 if you disable or change the properties of a network adapter.

Un’altra possibile causa potrebbe essere l’elevato numero di connessioni verso il Domain Controller, in questi scenari la problematica dovrebbe presentarsi più frequentemente nei giorni che seguono una pausa lavorativa degli uffici come ad esempio il Lunedì mattina. Per provare ad ovviare a questo problema è possibile aumentare il valore MaxUserPort, a rigurado si vedano:

• When you try to connect from TCP ports greater than 5000 you receive the error ‘WSAENOBUFS (10055)’
• MaxUserPort – what it is, what it does, when it’s important

Un’ulteriore causa del mancato avvio degli script di avvio/logon potrebbe essere dovuta al fatto che la connessione di rete viene rilavata come lenta.

In presenza di connessioni lente i meccanismi di avvio possono subire modifiche comportamentali per ovviare è possibile utilizzare due GPO computer.

La prima GPO computer è Group Policy slow link detection in Administrative Templates\System\Group Policy che è possibile attivare e impostare a 0 per considerare tutte le connessioni di rete come veloci. Per maggiori informazioni si veda la descrizione della GPO:

Specifica se una connessione è lenta per l’applicazione e l’aggiornamento dei Criteri di gruppo.

Se la velocità di trasferimento dati dal controller di dominio primario che fornisce l’aggiornamento di un criterio ai computer del gruppo è inferiore a quella specificata dal criterio, la connessione sarà considerata lenta.

La risposta del sistema a una connessione lenta varia a seconda dei criteri specificati. Il programma che applica il criterio determina la risposta a un collegamento lento. Inoltre il criterio che elabora i criteri della cartella consente di sostituire le risposte ai collegamenti lenti specificate dal programma.

Per utilizzare questo criterio, digitare nella casella “Velocità di connessione” un numero decimale compreso tra 0 e 4.294.967.200 (0xFFFFFFA0), che indica la velocità di trasferimento in kilobit al secondo. Le connessioni al di sotto del limite specificato verranno considerate lente. Se il valore immesso è 0, tutte le connessioni verranno considerate veloci.

Se si disattiva questo criterio o non lo si configura, verrà utilizzato il valore predefinito di 500 kilobit al secondo.

Questo criterio appare nelle cartelle Configurazione computer e Configurazione utente. Il criterio di Configurazione computer definisce i collegamenti lenti per i criteri della cartella Configurazione computer, mentre il criterio di Configurazione utente definisce i collegamenti lenti per i criteri della cartella Configurazione utente. Consultare anche il criterio “Non rilevare connessioni di rete lente” e i criteri relativi in Computer Configuration\Administrative Templates\System\User Profile. Nota: se il server dei profili ha connettività IP, sarà utilizzato il criterio velocità di connessione. Se non ha connettività IP, sarà utilizzata la temporizzazione SMB.

Al seguente Specifying Group Policy for Slow Link Detection è possibile verificare quali funzionalità per default non sono attive in presenza di connessioni lente ovvero Software Installation, Scripts e Folder Redirection. Si noti che in questo caso però si intendono gli script impostato tramite GPO e non quelli assegnati direttamente sull’utente (Default Behavior for Group Policy Extensions with Slow Link).

E possibile anche forzare l’esecuzione degli script impostati via GPO tramite la GPO Computer Scripts policy processing in Administrative Templates\System\Group Policy, attivado tale GPO sarà possibile forzare l’esecuzione delle policy di script anche in presenza di connessioni lente coem indicato nella descrizione

Determina il momento in cui i criteri che assegnano gli script condivisi vengono aggiornati.

Questa impostazione si applica a tutti i criteri che utilizzano il componente script dei Criteri di gruppo, quali ad esempio quelli in Impostazioni di Windows\Script.

Questa impostazione sostituisce le impostazioni personalizzate definite al momento dell’installazione dal programma che implementa il criterio degli script.

Se si abilita questa impostazione, sarà possibile modificare le opzioni nelle apposite caselle di controllo. Se si disabilita questa impostazione o non la si configura, essa non avrà alcun effetto sul sistema.

L’opzione “Consenti elaborazione attraverso una connessione di rete lenta” aggiorna i criteri anche quando gli aggiornamenti vengono trasmessi tramite una connessione di rete lenta, quale una linea telefonica. Il trasferimento degli aggiornamenti tramite connessioni lente può provocare ritardi notevoli.

L’opzione “Non applicare durante l’elaborazione periodica in background” impedisce l’aggiornamento di tali criteri in background mentre il computer è in uso. Gli aggiornamenti in background possono creare problemi agli utenti, causare l’interruzione o il funzionamento anomalo del programma e, in rari casi, danneggiare i dati.

L’opzione “Elabora anche se gli oggetti Criteri di gruppo non sono stati modificati” aggiorna e riapplica i criteri anche in assenza di modifiche. Molte implementazioni dei criteri specificano che gli aggiornamenti verranno effettuati solo in presenza di modifiche. È tuttavia possibile aggiornare i criteri che non hanno subito modifiche, riapplicando ad esempio una impostazione modificata da un utente.

Per ulteriori informazioni si veda anche How a slow link is detected for processing user profiles and Group Policy.

Come ultimo consiglio verificate anche la presenza di errori o avvisi nell’Event Viewer del computer client o del Domain controller per capire se è possibile ricavare più informazioni sul malfunzionamento o capire se si verifica in corrispondenza di determinate situazioni.