none
script di backup attivato da una policy: comportamento diverso se lanciato a mano RRS feed

  • Domanda

  • Gent.mi, vorrei un vostro parere su un comportamento anomalo di uno script che viene eseguito da macchine XP, alla fine della sessione di lavoro, in un dominio con 2003 server. Lo script e' inserito nelle policy normalmente. 

    Lo script esegue ntbackup. Alcuni utenti, quelli con dati superiori ai GByte, non terminano il backup. Lo stesso script se lanciato a mano non da alcun problema ed esegue tutte le operazioni previste. 

    Il messaggio di errore che posso leggere sui client è:

    Tipo evento: Errore
    Origine evento: Application Hang
    Categoria evento: (101)
    ID evento: 1002
    Applicazione in stallo ntbackup.exe, versione 5.1.2600.5512, modulo in stallo hungapp, versione 0.0.0.0, indirizzo stallo 0x00000000.

    Questo errore e' ampiamente documentato per i server 2003 e si corregge, sui server, con un hotfix.

    Ma sui cliente che si fa? 

    Perche' se lancio a mano lo script non da problemi e se lo lancia il sistema alla chiusura non va?

    Grazie per l'attenzione

    Saluti Cordiali

    Angelo Capodieci

    giovedì 27 maggio 2010 12:15

Risposte

Tutte le risposte

  • A che livello di service pack è la macchina XP ?
    -- Fabrizio Volpe MCSE (NT4) (2000) (2003) , MCSA (2003) , MCTS (SQL 2005) (Exchange 2007) (Windows 2008) Fortinet Certified Network Security Administrator (FCNSA)
    giovedì 27 maggio 2010 12:24
  • Salve, il client XP e' SP3

    Saluti

    Angelo

    giovedì 27 maggio 2010 12:29
  • Allora : il problema (almeno per 2003) era legato alla chiave "FilesNotToBackup" popolata con troppi caratteri.

    Nel lanciare questo backup, tu escludi un grosso numero di files e cartelle ?

    Parlando di Gigabytes di dati, da un client, mi viene da pensare che tu salvi Dei .pst ....


    -- Fabrizio Volpe MCSE (NT4) (2000) (2003) , MCSA (2003) , MCTS (SQL 2005) (Exchange 2007) (Windows 2008) Fortinet Certified Network Security Administrator (FCNSA)
    giovedì 27 maggio 2010 12:46
  • sei per caso in questa

    http://support.microsoft.com/kb/306110

    circostanza ?

     


    Edoardo Benussi - Microsoft® MVP
    Management Infrastructure - Systems Administration
    https://mvp.support.microsoft.com/Profile/Benussi
    Windows Server Italian Forum Moderator
    edo[at]mvps[dot]org
    giovedì 27 maggio 2010 15:29
    Moderatore
  • Salve, una parte dello script è questa:

    ntbackup.exe backup "%userprofile%" /a /d "Set creato il %date% alle %time%" /v:no /r:no /rs:no /hc:off /m incremental /j "Servizi Informatici, backup tipo incrementale" /l:s /f "\\server\backup\%username%\%nomefile%"

    La politica di backup e' normale un giorno della settimana, ed incrementale ogni giorno.

    Come potete vedere da %userprofile% copio tutto il profilo dell'utente, e a volte gli utenti hanno una quantità di dati enorme, diciamo massimo 6 GByte.

    Non ho capito il riferimento ai file .pst. Lo script funziona bene se lo faccio eseguire a mano dall'utente, non funziona correttamente se si avvia quando l'utente chiude la sessione, e quindi non credo che sia un problema di troppe esclusioni incluse in ntbackup.

     

    Grazie per la cortese attenzione

    Angelo Capodieci

     

     

     

     

     

     

    giovedì 27 maggio 2010 17:58
  • Aggiungo un particolare che mi fa pensare ad un timeout nell'esecuzione di script oggetto Criteri di gruppo, su un pc ho un evento 1217, origine winlogon, in questo pc non l'evento 1002 ma di fatto il processo si e' bloccato e il file di backup non si puo' aprire.

    Saluti

    Angelo

    giovedì 27 maggio 2010 18:43
  • Ho trovato questo:

    Maximum wait time for Group Policy scripts

    Use this option to set the script timeout interval. The default interval is 600 seconds (10 minutes), and valid intervals range from 0 to 32000 seconds.

    credo sia questa la soluzione.

    Angelo

    giovedì 27 maggio 2010 18:45
  • In effetti uno script per default va in timeout dopo 10 minuti.

    Detto questo, il tuo modo di gestire il backup dei profili utente è parecchio "inusuale".

    Se hai a disposizione dello spazio disco su un server, ti consiglierei di ridirigere i profili utente su una share e poi di fare il backup dei profili sul server piuttosto che lanciare N backup dei profili utente (che consumano risorse di rete e che, mi sembra, vanno comunque ad occupare spazio disco).

    Se hai bisogno di mantenere un "versioning" dei profili puoi utilizzare le shadow copies piuttosto che vari backup set.

    http://www.windowsnetworking.com/articles_tutorials/Profile-Folder-Redirection-Windows-Server-2003.html

    http://www.windowsnetworking.com/articles_tutorials/Windows-Server-2003-Volume-Shadow-Copy-Service.html

    P.S.

    Ho citato in precedenza i  .pst (ovvero agli archivi di posta di Outlook) perchè li vedevo come l'unico motivo "sensato" per avere user profiles da vari gigabyte.

    I documenti in genere, si gestiscono su share di rete e, a quel punto, che cosa deve mantenere nel suo profilo l'utente ?

     


    -- Fabrizio Volpe MCSE (NT4) (2000) (2003) , MCSA (2003) , MCTS (SQL 2005) (Exchange 2007) (Windows 2008) Fortinet Certified Network Security Administrator (FCNSA)
    giovedì 27 maggio 2010 21:50
  • Ciao Angelo,

    potresti fare una semplice prova su una macchina e schedulargli lo script non al logout ma, ad esempio, al login, oppure ad un determinato orario (in questo caso schedulandolo sulla macchina come operazioNE pianificata e non tramite gpo).

     


    Adriano Mariolini - MCITP Server Administrator adriano.mariolini[at]my.sysadmin[dot]it
    venerdì 28 maggio 2010 05:20
  • Gent.mo Fabrizio, grazie per le tue indicazioni.

    Colgo l'occasione della tua attenzione per parlare dei roaming profile, studiero' con attenzione gli articoli che mi hai mandato.

    Ho usato per circa 4 anni il roaming dei profili degli utenti della nostra rete con circa 180 utenti.

    In due o tre occasioni qualche utente si è lamentato di aver perso i file, ovviamente li ho ritrovati con i backup, ma la loro lamentela era vera, i file non c'erano piu' mentre le cartelle c'erano tutte, ma molte vuote.

    Ho studiato a fondo il problema e' ho capito che se per qualche ragione il processo di copia del profilo durante la chiusura della sessione viene interrotto, l'utente potrebbe non avere più i suoi file quando si riconnette nuovamente.

    Perche' succede cio'?

    Perche' il sistema crea prima tutte le cartelle e poi le riempe di file, se non fa in tempo a copiare i file, nel profilo vi saranno cartelle (vuote) piu' recenti rispetto a quelle che ha l'utente nel suo profilo locale, pertanto alla prossima connessione saranno ritenute piu' recenti quelle cartelle vuote!

    Per questa ragione mi sono temporaneamente allontanato da questo meccanismo che è eccezionale, ma finche' non trovo una soluzione a questo errore, ragionevolmente probabile, non usero' piu'.

    So che esistono diverse impostazioni che nelle GP di dominio si possono impostare in riferimento ai profili, ma nessuna mi pare che risolva questo mio dilemma.

    Mi piacerebbe essere confortato da te su questa mia conclusione, la prova che ho fatto e' facilmente ripetibile: ho resettato la macchina dopo un minuto che avevo fatto la disconnessione, il profilo era di meno di 1GByte ed era la prima volta che si creava il profilo nella share di rete.

     

    Tornando al backup la soluzione adottata e' la seguente:

    una volta a settimana forzo l'utente a fare un backup completo dei suoi dati su una cartella temporanea sul suo pc, su c:\ alla fine sessione

    1. creo una cartella temporanea in c:

    2. cambio i diritti di questa cartella in modo che sia solo lui a poterla aprire

    3. eseguo il backup

    4. calcolo l'hash in locale

    5. copio il file su una share di rete a lui dedicata

    5. ricalcolo l'hash in remoto e lo confronto

    6. cancello tutto quanto avevo creato nel pc dell'utente

     

    Gli altri giorni faccio un backup incrementale direttamente sulla share di rete.

     

    Grazie veramente per la tua attenzione

    Angelo Capodieci

     

     

    venerdì 28 maggio 2010 10:32
  • Grazie Adriano per la tua risposta, ma ho capito che vi e' una regola che si puo' impostare sul tempo di durata degli script assegnati nelle policy, gli script normalmente dopo 10 minuti vengono interrotti.

    Angelo

    venerdì 28 maggio 2010 10:37
  • Ciao.

    In effetti oltre a redirigere il profilo, devi anche redirigere le folder dell'utente (almeno quelle più grandi come dimensione per esempio la documenti).

    L'alternativa è che si svolge il processo di copia in locale dal profilo di rete (che in uno degli articoli che ti ho consigliato porta a  "obscenely long logons and log offs").

    A quel punto puoi avere i problemi da te descritti, specie con profili "panciuti" come i tuoi.

    Ti consiglio vivamente di provare profile + folders  redirection, che è una soluzione estremamente diffusa e razionale.

    Il backup dei profili, come da te impostato, mi sembra estremamente laborioso.


    -- Fabrizio Volpe MCSE (NT4) (2000) (2003) , MCSA (2003) , MCTS (SQL 2005) (Exchange 2007) (Windows 2008) Fortinet Certified Network Security Administrator (FCNSA)
    venerdì 28 maggio 2010 10:42
  • Ho trovato questo:

    Maximum wait time for Group Policy scripts

    Use this option to set the script timeout interval. The default interval is 600 seconds (10 minutes), and valid intervals range from 0 to 32000 seconds.

    credo sia questa la soluzione.

    Angelo


    non capisco però il motivo per cui, invece di ottenere una segnalazione di timeout ottieni un errore di hungapp.
    Edoardo Benussi - Microsoft® MVP
    Management Infrastructure - Systems Administration
    https://mvp.support.microsoft.com/Profile/Benussi
    Windows Server Italian Forum Moderator
    edo[at]mvps[dot]org
    venerdì 28 maggio 2010 18:12
    Moderatore
  • In attesa di un riscontro, ho modificato il tipo in discussione generale.

    Ciao.


    Anca Popa
    • Modificato Anca Popa mercoledì 2 giugno 2010 13:21 error
    mercoledì 2 giugno 2010 11:31
  • Vi ringrazio per l'attenzione, ormai e' chiaro che il problema era il timeout della policy di default, rimane un mistero perche' in alcuni casi negli eventi vi sia un errore di hungapp.

    Buon Lavoro

    Saluti Cardiali

    Angelo Capodieci

    giovedì 3 giugno 2010 07:01
  • L'alternativa all'uso di "roaming profiles" e "folders redirections" come soluzione del problema prospettato all'inizio (backup dei files/documenti utente) è l'uso di scripts che, tramite "WoL" (Wake on LAN) e "shutdown" provvedano in orari "offline" ad accendere i sistemi, copiare i files e quindi spegnerli di nuovo; il tutto senza intervento alcuno da parte dell'utente; in un tale scenario lo script dovrebbe prima di tutto usare (es.) "ping" per verificare se il sistema sia acceso o spento, nel secondo caso dovrà procedere all'invio di un pacchetto WoL attendendo quindi che il sistema completi il bootstrap, a questo punto si potrà procedere con il backup di quanto desiderato ed al termine, nel caso il sistema all'inizio fosse stato spento, allo spegnimento del sistema (che resterebbe invece acceso nel caso in cui questo fosse il suo stato iniziale)

    Ovviamente quanto sopra non è sempre applicabile e presenta comunque delle limitazioni

     

    giovedì 3 giugno 2010 08:05
  • Salve, si credo che questa possa essere una strada da sperimentare, alcuni ostacoli gia' li intravedo (la multipresa che l'utente spegne prima di andare via..). Pero' si possono mettere delle regole di comportamento.

    In riferimento alle folder redirection, credo che sia veramente uno strumento potente, ma credo anche che debba essere accoppiato con un file system distribuito con un altro server, gli utenti possono infatti essere tolleranti sul fatto che un server web sia giù per qualche minito/ora, ma è difficile che tollerino l'impossibilità di accedere ai propri file word/excel anche se per poco tempo!

    Grazie a tutti

    Angelo B. Capodieci

     

    giovedì 3 giugno 2010 08:16
  • Salve, si credo che questa possa essere una strada da sperimentare, alcuni ostacoli gia' li intravedo (la multipresa che l'utente spegne prima di andare via..). Pero' si possono mettere delle regole di comportamento.

    In riferimento alle folder redirection, credo che sia veramente uno strumento potente, ma credo anche che debba essere accoppiato con un file system distribuito con un altro server, gli utenti possono infatti essere tolleranti sul fatto che un server web sia giù per qualche minito/ora, ma è difficile che tollerino l'impossibilità di accedere ai propri file word/excel anche se per poco tempo!

    Multipresa ?!? Alla faccia delle normative sulla sicurezza :D !

    In qualsiasi caso, tieni presente che esistono anche dei s/w di backup che gestiscono direttamente il WoL e che, utilizzando degli "agent" da installare sui vari clients, permettono di centralizzare le operazioni di backup degli stessi; il mio esempio con lo "script" voleva solo essere uno spunto (funzionante) non LA soluzione "definitiva"; se comunque vuoi esplorare tale opzione, ti consiglierei di utilizzare vbscript per mettere insieme uno script di "backup" da avviare sui clients; in questo caso l'idea potrebbe essere circa la seguente

    al logon, uno script si occupa di copiare i vari "pezzi" (scripts/tools...) dello script di backup da utilizzare per la copia dei files client

    all'orario desiderato, uno script centralizzato provvederà ad inviare in sequenza pacchetti WoL ai vari clients; fatto questo, ed una volta che i sistemi siano operativi, lo script potrà quindi utilizzare "psexec " (con il parametro "-d" per avviare l'operazione in background) per lanciare lo script di backup su ciascun client; fatto ciò, lo script centralizzato terminerà

    Lo script di backup avviato sui vari clients procederà a questo punto alla copia dei files desiderati sulle opportune shares di rete ed al termine provvederà all'invio di una email nel caso in cui si siano verificati errori e comunque allo spegnimento del sistema client

    In tal modo, anche in presenza di parecchi clients, le operazioni di backup avverranno "in parallelo" senza impegnare il server centralizzato per molto tempo e permettendo il completamento delle operazioni in tempi relativamente ridotti (al prezzo di un aumento del traffico di rete dovuto al backup dei vari sistemi) e senza dover ritardare indefinitamente le operazioni di logoff/spegnimento


    giovedì 3 giugno 2010 09:35
  • Edo... mi viene il dubbio che il sistema proceda comunque con le operazioni di "shutdown" pur lasciando che lo script continui a girare, questo significa che il sistema potrebbe (ad esempio) procedere alla disconnessione delle unità di rete causando un "blocco" del backup con relativo messaggio "hungapp" - non ho verificato se l'ipotesi sia corretta (non ne ho il tempo in questo momento) per cui non prendere quanto sopra per oro colato, però il mio sospetto è che accada qualcosa del genere

     

     

    giovedì 3 giugno 2010 09:38
  • grazie per le utili alternative, tutte da approfondire.

    ciao

    Angelo

    giovedì 3 giugno 2010 21:00