none
Notebook: forzare esecuzione GPO al ripristino dopo sospensione. RRS feed

  • Discussione generale

  • Per ogni SITE aziendale ho una GPO che mappa due dischi di rete ed una serie di stampanti specifiche della LAN dalla quale l'utente si autentica.

    E' però sorto un problema legato agli utenti "migranti" dotati di notebook, i quali non lo spengono praticamente mai per mesi e passano da una sede aziendale all'altra con il PC in stand-by e lo riattivano una volta giunti in sede: il problema è legato al fatto che all'atto della riattivazione il notebook continua a presentare le mappature dei dischi di rete e la stampanti che erano stati mappati al momento della "sospensione" del notebook presso un'altra sede.

    Ho notato che, almeno per quanto riguarda le stampanti, dopo qualche secondo via via iniziano a comparire anche quelle della LAN di connessione (però si sommano a quelle già presenti), mentre per quanto riguarda le mappature dei dischi di rete non vengono proprio eseguite.

    La mappatura dei dischi di rete avviente tramite la GPO: User Configuration -> Preferences -> Drive Maps -> (Action: Replace).

    Il problema naturalmente non si presenta se l'utente arriva col notebook spento e lo accende al momento: in quel caso le GPO vengono eseguite normalmente e tutte le mappature vengono applicate, anche se ci si connette solo con l'interfaccia wireless.

    ALex.



    • Modificato Alex_B_ giovedì 7 agosto 2014 09:56
    • Tipo modificato Anca Popa giovedì 14 agosto 2014 07:24 in attesa di ulteriori feedback
    giovedì 7 agosto 2014 09:48

Tutte le risposte

  • la via più rapida è quella di impedire lo sleep/hibernate sui notebook mediante group policy costringendo gli utenti allo shutdown.

    ciao.


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    martedì 12 agosto 2014 13:15
    Moderatore
  • la via più rapida è quella di impedire lo sleep/hibernate sui notebook mediante group policy costringendo gli utenti allo shutdown.

    ciao.


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    Ti ringrazio Edoardo, ma mi sembra una soluzione un tantino forzosa.

    Quella di mettere in sospensione il notebook è purtroppo una funzionalità utile in molti frangenti e sinceramente non me la sento tanto di tagliarla via agli utenti tout court ...

    :-)

    ALex.



    • Modificato Alex_B_ martedì 12 agosto 2014 13:32
    martedì 12 agosto 2014 13:26
  • ok, in tal caso leggi qui

    Network Location Awareness

    Network Location Awareness (NLA) is a service built in to Windows that is used to determine when the computer has connectivity to the Active Directory infrastructure. The Group Policy infrastructure utilizes NLA to determine whether to attempt to download and apply GPOs. This Group Policy function is called slow link detection.

    In previous versions, Group Policy processing used slow link detection to determine if the network was reliable enough to process and apply policies. Slow link detection relied on the Internet Control Message Protocol (ICMP) or Ping to test for network connectivity and was not very reliable. Due to this specification, Group Policy processing on mobile and remote client workstations was very unreliable. When a mobile client workstation connected to the corporate network through a VPN connection or after waking from hibernation or sleep mode, the change in network connectivity usually passed by unnoticed and GPOs were not applied or refreshed. In these cases, the only way to get these clients to apply their GPOs was to have them manually run a Group Policy update from the command line or have these machines reboot while connected to the corporate network via wired Ethernet connections.

    Group Policy processing on Windows Vista, Windows 7, Windows Server 2008, and Windows Server 2008 R2 now utilize the rebuilt Network Location Awareness (NLA) service to detect network changes. The new NLA service is much better at detecting changes to network connections, and when a connection is established, NLA checks for domain controller connectivity. If a domain controller can be contacted, the NLA service notifies the computer Group Policy service, which, in turn, triggers Group Policy processing for both computer- and user-based Group Policy settings. The NLA service is not dependent on ICMP or Ping, which on its own makes it more reliable. The NLA service should run on most networks without any special configuration on the network devices or network firewalls, even if ICMP communication is disabled or blocked by the firewall.


    Read more at http://tutorial.programming4.us/windows_server/Windows-Server-2008-R2---Group-Policy-Processing%E2%80%94How-Does-It-Work.aspx#kLoz4aK4ooPlTmyg.99

    ref: http://tutorial.programming4.us/windows_server/Windows-Server-2008-R2---Group-Policy-Processing%E2%80%94How-Does-It-Work.aspx


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    martedì 12 agosto 2014 13:38
    Moderatore
  • Ciao,

    Ho guardato la NLA, ma confesso di averci capito poco.

    Dopo aver verificato che l'unica possibilità di trappiare l'evento di "ripristino da sospensione" è quella di creare una specifica Pianificazione Evento su ogni macchina, ho risolto come di seguito (tratto dalla documentazione ICT aziendale che ho prodotto).

    Problema metodologico: gli utenti dotati di notebook possono mettere in sospensione un PC presso una sede e riaccenderlo presso un'altra sede: questo non permette la rimappatura dei dischi di rete e l'utente si potrebbe ritrovare sul desktop i dischi ancora mappati sulla rete dell'altra sede genereando confusione e possibilità di disservizio in rete.
     
    Soluzione implementata: creare e mantenere sempre aggiornato sull'HD del PC un file con il Site di accesso della macchina ed implementare una utility che, ad ogni ripristino del PC da uno stato di ibernazione, verifichi che il Site di accesso non sia variato. Nel caso in cui il Site sia cambiato si provvede ad eliminare la mappatura ai dischi di rete e ad avvisare l'utente della necessità di eseguire un nuovo login.
     

    -= Memorizzazione del Site di connessione al momento del login =-
    Per memorizzare il Site di connessione è stata creata una GPO denominata "Site Check PC Logon" e linkata ad ognuno dei sites aziendali, che provvede a lanciare uno script denominato SITELOG.VBS al momento del login utente (il file è contenuto all'interno della cartella privata del Group Policy Object stesso).

    Lo script genera i seguenti due files: 

    a) %temp%\SITELOG.TXT contenente il nome del Site al momento del logon
    b) %temp%\SITELOG.LOG contenente i LOG dell'attività.
     
    -= Verifica del Site di connessione al momento del ripristino da una sospensione =-
    L'evento di ripristino dallo statio di sospensione, anche se in effetti prevede una ri-autenticazione, non viene tracciato dal sistema di rete come autenticazione quindi non è direttamente trappabile tramite GPO.
    L'unico metodo per intercettare un evento di ripristino da uno stato di sospensione è quello di creare una Pianificazione Evento su ogni PC che intercetti l'evento "Sblocco della Workstation" e come conseguenza lanci uno script che provveda alla verifica del Site di nuova connessione.
     
    Per la gestione dell'evento è stata creata una GPO denominata "Site Check PC Resume" (User Configuration -> Preferences -> Control Panel Settings -> Scheduled Task) che al recupero da sospensione lancia lo script denominato SITECHK.VBS (\\<network share>\SITECHK.VBS) che provvede alla verifica del Site attuale con quello memorizzato in %temp%\SITELOG.TXT e, nel caso venga rilevato un cambiamento, provvede alla eliminazione delle mappature di rete e all'avviso dell'utente della necessità di una nuova autenticazione di rete.
     

    Tutta la procedura sopradescritta funziona solo su PC dotati di sistema operativo da Vista in su (non funziona con Windows XP in quanto il vecchio SO non traccia l'evento "Sblocco della workstation").

    Riporto di seguito i VBS utilizzati:

    ---- SITELOG.VBS ----

    ' *** SITELOG.VBS
    ' *** Autore: ALex
    ' *** Ultima modifica: 18/08/2014
    ' *** Scopo: genera il file di LOG della connessione ad AD e salva nel file %temp%SITELOG.TXT l'ultimo AD Site di connessione del PC
    ' ------------------------------------------------' 

    ' Crea l'oggetto Shell
    Set oShell = CreateObject( "WScript.Shell" )

    ' Memorizza l'AD Site
    Set objADSysInfo = CreateObject("ADSystemInfo")
    site=objADSysInfo.SiteName

    ' Memorizza le variabili di ambiente
    user=oShell.ExpandEnvironmentStrings("%UserName%")
    computer=oShell.ExpandEnvironmentStrings("%ComputerName%")
    tempdir=oShell.ExpandEnvironmentStrings("%Temp%")

    ' Memorizza data e ora
    datetime=Now

    ' Monta la riga da scriver nel file di LOG (linelog)
    linelog=datetime & ", " & user & ", " & computer & ", " & tempdir & ", " & objADSysInfo.SiteName

    ' Monta il nome del file di Log
    logname="SITELOG.LOG"
    logdir=tempdir
    strFile = (logdir & "\" & logname)

    ' Scrive il file SITELOG.LOG
    Const ForAppending = 8
    set objFSO = CreateObject("Scripting.FileSystemObject")
    set objFile = objFSO.OpenTextFile(strFile, ForAppending, True)
    objFile.WriteLine(linelog)
    objFile.Close

    ' Monta il nome del file di Site 
    sitename="SITELOG.TXT"
    logdir=tempdir
    strFile = (logdir & "\" & sitename)
    ' WScript.Echo strFile

    ' Scrive il file SITELOG.TXT
    Const ForWriting = 2
    set objFSO = CreateObject("Scripting.FileSystemObject")
    set objFile = objFSO.OpenTextFile(strFile, ForWriting, True)
    objFile.WriteLine(site)
    objFile.Close

    ------------------------------

    ---- SITECHK.VBS ----

    ' *** SITECHK.VBS
    ' *** Autore: ALex
    ' *** Ultima modifica: 19/08/2014
    ' *** Scopo: confronta l'attuale AD Site connesso con quello contenuto nel file %temp%SITELOG.TXT e nel caso rilevi una differenza di site
    ' *** avvisa l'utente e provvede ad eseguire una eliminazione delle mappature dei dischi di rete.
    ' ------------------------------------------------' 

    ' Crea l'oggetto Shell
    Set oShell = CreateObject( "WScript.Shell" )

    ' Memorizza l'AD Site attuale
    Set objADSysInfo = CreateObject("ADSystemInfo")
    sitenow=objADSysInfo.SiteName

    ' Memorizza la variabile di ambiente %TEMP%
    tempdir=oShell.ExpandEnvironmentStrings("%Temp%")

    ' Monta il nome del file di Site 
    sitename = "SITELOG.TXT"
    logdir = tempdir
    strFile = (logdir & "\" & sitename)
    filename = strFile

    ' Verifica l'esistenza del file SITELOG.TXT, in caso affermativo procede con la verifica di cambio Site ...
    Set objFSO = CreateObject("Scripting.FileSystemObject")

    If objFSO.FileExists(filename) Then
       Set f = objFSO.OpenTextFile(filename)

       siteold = f.ReadLine

       f.Close

       if sitenow <> siteold then

    ' Esegue l'eliminazione delle mappature di rete
          On Error Resume Next

          Set objNetwork = CreateObject("Wscript.Network")
          Set colDrives = objNetwork.EnumNetworkDrives

          For i = 0 to colDrives.Count-1 Step 2
              objNetwork.RemoveNetworkDrive colDrives.Item(i), True, True
          Next

          x=MsgBox("E' stato rilevato l'accesso ad una diversa sede aziendale. E' necessario disconnettersi ed autenticarsi nuovamente per poter utilizzare le risorse di rete.", 48, "Avviso di Rete")
       Else
         Wscript.Echo "Accesso alla rete aziendale eseguito regolarmente."
       End if
    End If

    -------------------------------

    Testato ed attualmente funzionante in produzione da qualche giorno.

    ALex.
    • Modificato Alex_B_ venerdì 22 agosto 2014 09:56
    venerdì 22 agosto 2014 09:53