none
GPO e script Powershell RRS feed

  • Domanda

  • Ho due server di dominio Windows 2012 e clients Windows 7.

    E' mia intenzione far eseguire all'avvio dei clients degli script Powershell. Gli script contengono le seguenti istruzioni:

    Param(
       [string]$password
    ) 
    $user = "[nome utente con diritti amministrativi]"
    $pass = $password | convertto-securestring -asplaintext -force
    $cred = new-object -typename System.Management.Automation.PSCredential -argumentlist $user, $pass
    
    $session = new-pssession -Credential $cred
    invoke-command -Session $session -ScriptBlock {Start-Process -FilePath "msiexec.exe" -ArgumentList "/x {[guid]} /q"}

    Lo script viene richiamato da GPO, passando come parametro la password dell'utente con diritti amministrativi inserito nella variabile $user; con le sue credenziali viene eseguita la disinstallazione dell'applicazione corrispondente al guid inserito come parametro dell'istruzione msiexec. La disinstallazione viene eseguita con un utente con diritti di amministratore, perché gli utenti normalmente non hanno i permessi di installare o disinstallare softwares. Discriminante questa che al momento non importa, dato che il problema si presenta anche eseguendo l'accesso con utenti con diritto di amministratore e comunque gli script vengono richiamati all'avvio della macchina e non all'accesso dell'utente.

    Ho creato una policy collegato alla OU di computers contenente i clients interessati. La policy l'ho configurata come segue:

    Computer Configuration\Policies\Windows Settings\Scripts\Startup

    - Order: Windows PowerShell scripts will run last
     
    - Elenco scripts powershell
    - Nome: script1.ps1 Parametri: -password [password utente con diritti amministrativi]
    - Nome: script2.ps1 Parametri: -password [password utente con diritti amministrativi]

    Eseguendo gli script via console Powershell, una volta effettuato il login, la disinstallazione viene effettuata correttamente, ma via GPO all'avvio dei clients non funziona. Verificando con GPResult la policy risulta tra gli oggetti criteri di gurppo applicati. I registri di sistema non mi forniscono errori che sembrano essere riferiti a questa policy.

    Vi chiedo se qualcuno sa fornirmi qualche aiuto utile su come risolvere il problema e dove ho sbagliato o dimenticato qualcosa.


    • Modificato Ardena martedì 15 settembre 2015 11:15 Migliorato il testo descrittivo.
    martedì 15 settembre 2015 11:09

Risposte

  • Leggendo il tuo post, noto un po' di confusione e pratiche da evitare ASSOLUTAMENTE (vedi consiglio di Perelli)

    1. User e password di una utenza amministrativa inseriti in una GPO, mettono a grave rischio la tua infrasruttura. Un normale user della tua azienda che leggesse questo post, potrebbe trovare la tua utenza "segreta" in una trentina di secondi ( senza leggere il post servirebbero 2/3 minuti, non spiego come fare, ma è una assoluta banalità )
    2. Da quello che riporti, esegui lo script come "....script\STARTUP" (non come logon) di conseguenza  l'esecuzione avviene nel contesto localsystem  e non vi è alcuna necessità di creare un secondo processo con le credenziali amministrative system è già un admin (vedi consiglio di Edoardo).
    3. Trascurando le problematiche di sicurezza, usare lo script al logon con le credenziali amministrative nella GPO per riuscire a disinstallare un programma, non ha senso, ma fortunatamente avevi scelto la modalità corretta(startup).
    4. Semplifica tutto usando un semplice cmd di due righe eseguito come startup script.FINE.

    Ecco cosa potresti usare al posto dello script powershell. 

    REM batch che "logga" qualcosa ... quando eseguito
    echo Comincio %date% %time% >>"%temp%\removestart.log" msiexec /x {guid} /q /L*V "%temp%\remove.log"

    ciao

    Gas


    Gastone Canali >http://www.armadillo.it


    Se alcuni post rispondono al tuo quesito(non necessariamente i miei), ricorda di contrassegnarli come risposta e non dimenticare di contrassegnare anche i post utili. GRAZIE! Ricorda di dare un occhio ai link Click Here andHere

    martedì 15 settembre 2015 21:01
    Moderatore

Tutte le risposte

  • Hai provato a inserire il percorso completo di msiexec? (C:\Windows\System32\msiexec.exe)

    Potresti anche fare loggare msiexec in modo verboso (/lx c:\temp\logfile.txt)

    Logging Options
    	/l[i|w|e|a|r|u|c|m|o|p|v|x|+|!|*] <LogFile>
    		i - Status messages
    		w - Nonfatal warnings
    		e - All error messages
    		a - Start up of actions
    		r - Action-specific records
    		u - User requests
    		c - Initial UI parameters
    		m - Out-of-memory or fatal exit information
    		o - Out-of-disk-space messages
    		p - Terminal properties
    		v - Verbose output
    		x - Extra debugging information
    		+ - Append to existing log file
    		! - Flush each line to the log
    		* - Log all information, except for v and x options
    	/log <LogFile>
    		Equivalent of /l* <LogFile>
    Detto questo, le password non andrebbero mai inserite in batch di nessun tipo GPO incluse


    This post is provided AS IS with no warranties or guarantees, and confers no rights.
    ~~~
    Questo post non fornisce garanzie e non conferisce diritti

    martedì 15 settembre 2015 12:25
  • un'altra possibilità è quella di far eseguire lo script nel contesto di sicureza di localsystem piuttosto che in quello di un account admin visto che lo script è di startup e nella OU hai oggetti computer

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


    martedì 15 settembre 2015 14:42
    Moderatore
  • Leggendo il tuo post, noto un po' di confusione e pratiche da evitare ASSOLUTAMENTE (vedi consiglio di Perelli)

    1. User e password di una utenza amministrativa inseriti in una GPO, mettono a grave rischio la tua infrasruttura. Un normale user della tua azienda che leggesse questo post, potrebbe trovare la tua utenza "segreta" in una trentina di secondi ( senza leggere il post servirebbero 2/3 minuti, non spiego come fare, ma è una assoluta banalità )
    2. Da quello che riporti, esegui lo script come "....script\STARTUP" (non come logon) di conseguenza  l'esecuzione avviene nel contesto localsystem  e non vi è alcuna necessità di creare un secondo processo con le credenziali amministrative system è già un admin (vedi consiglio di Edoardo).
    3. Trascurando le problematiche di sicurezza, usare lo script al logon con le credenziali amministrative nella GPO per riuscire a disinstallare un programma, non ha senso, ma fortunatamente avevi scelto la modalità corretta(startup).
    4. Semplifica tutto usando un semplice cmd di due righe eseguito come startup script.FINE.

    Ecco cosa potresti usare al posto dello script powershell. 

    REM batch che "logga" qualcosa ... quando eseguito
    echo Comincio %date% %time% >>"%temp%\removestart.log" msiexec /x {guid} /q /L*V "%temp%\remove.log"

    ciao

    Gas


    Gastone Canali >http://www.armadillo.it


    Se alcuni post rispondono al tuo quesito(non necessariamente i miei), ricorda di contrassegnarli come risposta e non dimenticare di contrassegnare anche i post utili. GRAZIE! Ricorda di dare un occhio ai link Click Here andHere

    martedì 15 settembre 2015 21:01
    Moderatore
  • Ciao Ardena,

    Il tuo thread nel Forum di TechNet è ancora aperto per noi.
    Se i consigli ricevuti ti sono stati utili, ricorda di evidenziare la soluzione cliccando su "Segna come Risposta". Aggiungo che il tuo riscontro tornerà sicuramente utile per chi si dovesse trovare nella medesima situazione, così è molto gradito dai membri della community se puoi condividere una soluzione tua.

    Grazie della collaborazione.


    • Microsoft offre questo servizio gratuitamente, per aiutare gli utenti e aumentare il database dei prodotti e delle tecnologie. Il contenuto viene fornito “così come è e non comporta alcuna responsabilità da parte dell’azienda.

    venerdì 18 settembre 2015 09:35
  • Vi ringrazio per le risposte.

    Premetto che stavo facendo delle prove per trovare la soluzione da applicare; quella che ho esposto è l'ultima di una serie di modifiche che ho applicato per capire perché queste disinstallazioni non volevano funzionare, perciò vi ho riportato qualcosa che ormai si era sporcato parecchio. Per non rischiare di essere troppo prolisso, devo avervi sviato, chiedo scusa.

    Cerco di essere breve: l'obiettivo era installare e disinstallare dei programmi all'avvio dei clients. Sono partito da semplici sctripts bat, all'inserire files MSI in Computer Configuration/Policies/Software Settings/Software Installation (per le installazioni) alla creazione di scripts PowerShell per bypassare l'utente system, dato che ad un certo punto sembrava ci fossero problemi con questo utente, anche se i reports di sistema non davano un gran che di errori per capirci qualcosa (anche con gli scripts di GastoneCanali non venivano creati i file di log che doveva generare lo script stesso). E' per questo che sono giunto a questi script PowerShell che forzano l'esecuzione con permessi di un untente amministratore creato ad hoc. Come potete vedere nel mio post, la password in queste prove l'ho inserita come parametro nella policy, per non è stata inserita direttamente nello script, leggibile da tutti. Comunque ripeto, era solo una soluzione temporanea per questi test. Grazie comunque per l'avviso sulla sicurezza.

    Avete ragione, è un po' pasticciata la gestione logon e startup. L'avvio dello script con permessi amministrativi è rimasta perché ho provato ad inserire l'avvio degli script anche in una policy di logon, dato che in startup non si muoveva foglia. Non riuscivo a capire perché, indipendentemente dalla sicurezza e dalla sensatezza di questa soluzione, avviandole a mando le script funzionano, nelle policy GPO (sia startrup e sia logon) no.

    In questi giorni, dopo aver scritto il post, analizzando più nel dettaglio il gpresult (non solo analizzando le policy applicate), ho notato che Riepilogo configurazione computer\Stato componente si bloccava in Infrastruttura componenti di gruppo e non proseguiva sulle altre voci.

    Non sto a dilungarmi, ma nel file inetres.admx erano state aggiunte da un aggiornamento Windows delle policy non riconosciute dal sistema, che mandavano tutto in blocco. Ho rimosso manualmente le policy ed ha ripreso a funzionare (su Internet era consigliata questa operazione per questo problema riconosciuto).

    A questo punto sono partito con i file batch di GastoneCanali, ma mi rimuoveva solo un programma. Dopo aver inserito le istruzioni in un unico file batch, la policy ha rimosso tutti i programmi. Chiedo: ma inserendo più script nella policy, non dovrebbe eseguirle in sequenza e non in parallelo (dato che presumo che la seconda andasse in errore perché in esecuzione la disinstallazione della prima)?

    In più ho provato ad inserire un MSI di installazione sia in Computer Configuration/Policies/Software Settings/Software Installation sia avviarlo come script nel file batch in cui ho inserito le disinstallazioni. Il programma non si installa in entrambi i casi. Il file MSI funziona, perché avviandolo manualmente il programma si installa. Vi chiedo se potete gentilmente aiutarmi anche in questo punto.

    Grazie ancora.

    venerdì 18 settembre 2015 16:04
  • Ci sarebbe da parlare un giorno sugli argomenti toccati, sarò telegrafico solo su quello che probabilmente non è chiaro:

    GPO  Computer Configuration/Policies/Software Settings/Software Installation (per le installazioni)
    In realtà serve sia per le installazioni e anche per le DISINSTALLAZIONI di ciò che è stato installato con la GPO stessa.

    creazione di scripts PowerShell per bypassare l'utente system, dato che ad un certo punto sembrava ci fossero problemi con questo utente

    Dubito fortemente che l'utente system avesse dei problemi nelle installazioni locali (sarebbe il primo caso che sento da nt4 a oggi)

    Come potete vedere nel mio post, la password in queste prove l'ho inserita come parametro nella policy, per non è stata inserita direttamente nello script, leggibile da tutti.

    L'avevo capito benissimo che non era direttamente in chiaro nello script, ma ti ripeto: 30 secondi per trovare la tua password " non presente nello script " ma passata come parametro nella gui della GPO!!!

    ho provato ad inserire l'avvio degli script anche in una policy di logon, dato che in startup non si muoveva foglia.

    Se vuoi essere sicuro che che uno startup script, cominci ad essere eseguito devi fare almento due riavvii (tre se non vuoi avere dubbi), forzando le policy ogni volta es. gpupdate /force   meglio ancora, se fai un gupdate /sync fra un riavvio e l'altro
    Spesso mi viene detto che gli  startup script  "hanno dei problemi"  e "non partono", se partono ci si lamenta perchè non vengono rimossi una volta tolti da policy...ma i problemi sono altri ;)

    Chiedo: ma inserendo più script nella policy, non dovrebbe eseguirle in sequenza e non in parallelo (dato che presumo che la seconda andasse in errore perché in esecuzione la disinstallazione della prima)?

    NO.
    msiexec.exe è un programma windows asincrono come tutti (escluse le console application) e come tale se accodi  più msiexec, questi anranno in parallelo... la prima disinstallazione funzionerà, le altre falliranno miseramante!

    Soluzione: eseguire msiexec con il comando START  /WAIT  che avvierà un processo sincrono (start /? per avere l'help, ma occhio a scrivere bene il comando altrimenti non funzionerà la disinstallazione)

      In più ho provato ad inserire un MSI di installazione sia in Computer Configuration/Policies/Software Settings/Software Installation
    Ti garantisco che l'installazione degli msi da GPO funziona, ma ti garantisco che è una rogna far funzionare il tutto, mille insidie si nascondono, da dove metti il tuo msi, ad essere sicuro che tale share dove risiedono gli intallativi sia leggibile da localsystem ...etc. Non avrai alcun feedback centralizzato sui pc che hanno recepito la policy, nessuna info se l'installazione sia andata a buon fine, nessuna info se l'applicazione sia stata disinstallata da GPO...

    http://social.technet.microsoft.com/wiki/contents/articles/4715.group-policy-survival-guide.aspx

    http://deployhappiness.com/top-10-ways-to-troubleshoot-software-deployment/


    Gastone Canali >http://www.armadillo.it


    Se alcuni post rispondono al tuo quesito(non necessariamente i miei), ricorda di contrassegnarli come risposta e non dimenticare di contrassegnare anche i post utili. GRAZIE! Ricorda di dare un occhio ai link Click Here andHere



    venerdì 18 settembre 2015 23:22
    Moderatore
  • Sono d'accordo, le installazioni/disinstallazioni tramite GPO sono parecchio problematiche e spesso non vengono attivate subito al primo riavvio anche se tutto è configurato correttamente. Secondo me dovresti cambiare approccio, così hai anche meno problemi a mettere in sicurezza la password (in ogni caso deve essere un utente dedicato che ha diritto di amministratore sul computer, ma non privilegi elevati a livello di dominio). Puoi comunque creare script PowerShell che eseguono un occultamento della password o utilizzare le operazioni pianificate ma a mio parere, se ne hai la possibilità, la soluzione migliore è implementare direttamente System Center Configuration Manager. In alternativa, se è sufficiente un'installazione immediata nei computer è preferibile utilizzare direttamente delle esecuzioni remote tramite PsExec. Infatti le ultime versioni di questa utility eseguono la crittografia anche dei comandi inviati (inclusi nome utente e password):

    http://blogs.technet.com/b/sysinternals/archive/2014/03/07/updates-process-explorer-v16-02-process-monitor-v3-1-psexec-v2-1-sigcheck-v2-03.aspx

    sabato 19 settembre 2015 15:29
    Moderatore
  • Ci sarebbe da parlare un giorno sugli argomenti toccati, sarò telegrafico solo su quello che probabilmente non è chiaro:

    Ti ringrazio per il tuo aiuto e la tua pazienza.

    > GPO  Computer Configuration/Policies/Software Settings/Software Installation (per le installazioni)

    In realtà serve sia per le installazioni e anche per le DISINSTALLAZIONI di ciò che è stato installato con la GPO stessa.

    Purtroppo i programmi che devo rimuovere sono stati installati manualmente sulle macchine all'atto della loro preparazione e non via policy, pertanto purtroppo, in questo caso, non posso usare questa policy per rimuoverli. E' per questo che un questo caso la policy ho provato ad usarla solo per le installazioni.

    > creazione di scripts PowerShell per bypassare l'utente system, dato che ad un certo punto sembrava ci fossero problemi con questo utente

    Dubito fortemente che l'utente system avesse dei problemi nelle installazioni locali (sarebbe il primo caso che sento da nt4 a oggi)

    Dato che non eseguiva le policy ho cominciato a scartare un pezzo alla volta i vari elementi. Arrivato al fondo, ho raschiato anche il system (comunque non era lui :) ).

    > Come potete vedere nel mio post, la password in queste prove l'ho inserita come parametro nella policy, per non è stata inserita direttamente nello script, leggibile da tutti.

    L'avevo capito benissimo che non era direttamente in chiaro nello script, ma ti ripeto: 30 secondi per trovare la tua password " non presente nello script " ma passata come parametro nella gui della GPO!!!

    Allora ti chiedo scusa. Avevo interpretato erroneamente la tua risposta. Comunque ti voglio tranquillizzare che era solo una prova e che non è mio solito fare queste cose. :D

    >ho provato ad inserire l'avvio degli script anche in una policy di logon, dato che in startup non si muoveva foglia.

    Se vuoi essere sicuro che che uno startup script, cominci ad essere eseguito devi fare almento due riavvii (tre se non vuoi avere dubbi), forzando le policy ogni volta es. gpupdate /force   meglio ancora, se fai un gupdate /sync fra un riavvio e l'altro
    Spesso mi viene detto che gli  startup script  "hanno dei problemi"  e "non partono", se partono ci si lamenta perchè non vengono rimossi una volta tolti da policy...ma i problemi sono altri ;)

    Ah, ok, questo mi mancava. :) Quindi, per esempio, se volessi creare una policy che voglio che si applichi il giorno dopo al riavvio di tutti i computers, devo considerare il fatto che quasi certamente questo non avverrà? Curiosità tecnica: come mai capita questa cosa? Presumo, almeno basandomi sulla mia esperienza, che questo riguarda le installazioni ed interventi sui software ed esecuzione degli script; modifiche sul registro di sistema, copia files, creazione cartelle ecc. ho visto che vengono eseguiti al primo riavvio/login senza problemi.

    > Chiedo: ma inserendo più script nella policy, non dovrebbe eseguirle in sequenza e non in parallelo (dato che presumo che la seconda andasse in errore perché in esecuzione la disinstallazione della prima)?

    NO.
    msiexec.exe è un programma windows asincrono come tutti (escluse le console application) e come tale se accodi  più msiexec, questi anranno in parallelo... la prima disinstallazione funzionerà, le altre falliranno miseramante!

    Soluzione: eseguire msiexec con il comando START  /WAIT  che avvierà un processo sincrono (start /? per avere l'help, ma occhio a scrivere bene il comando altrimenti non funzionerà la disinstallazione).

    Credevo che la policy attendesse il completamento dello script precedente prima di avviare il secondo. Io avevo interpretato che il funzionamento asincrono determinasse che se lancio in sequenza diversi msiexec.com, ogni esecuzione non verifica se è già in esecuzione un altro processo msiexec.com e parte subito, invece pensavo che inserendo uno script per ogni esecuzione nella policy, la policy attendesse il termine del primo script prima di avviare il secondo (poi mi sono trovato nella situazione opposta). Probabilmente mi sfugge il meccanismo di asincronicità dell'operazione. Grazie mille delle info. Appena posso provo. ;)

     > In più ho provato ad inserire un MSI di installazione sia in Computer Configuration/Policies/Software Settings/Software Installation

    Ti garantisco che l'installazione degli msi da GPO funziona, ma ti garantisco che è una rogna far funzionare il tutto, mille insidie si nascondono, da dove metti il tuo msi, ad essere sicuro che tale share dove risiedono gli intallativi sia leggibile da localsystem ...etc. Non avrai alcun feedback centralizzato sui pc che hanno recepito la policy, nessuna info se l'installazione sia andata a buon fine, nessuna info se l'applicazione sia stata disinstallata da GPO...

    http://social.technet.microsoft.com/wiki/contents/articles/4715.group-policy-survival-guide.aspx

    http://deployhappiness.com/top-10-ways-to-troubleshoot-software-deployment/

    Molto rassicurante. :) E' comunque un'informazione utile, perché sapere che ciò che hai elencato è previsto e "normale", mi aiuta ad affrontare con più consapevolezza le problematiche che incontro. Il "normale" tra virgolette vuol dire che in una situazione ottimale questo non dovrebbe accadere, ma vista la complessità e la quantità di elementi che vengono coinvolti con queste operazioni, è normale che si incappi in situazioni spinose.

    Grazie mille per tutte le informazioni che mi hai dato. Provo quello che mi hai detto e ti faccio sapere.

    giovedì 24 settembre 2015 09:12
  • Sono d'accordo, le installazioni/disinstallazioni tramite GPO sono parecchio problematiche e spesso non vengono attivate subito al primo riavvio anche se tutto è configurato correttamente. Secondo me dovresti cambiare approccio, così hai anche meno problemi a mettere in sicurezza la password (in ogni caso deve essere un utente dedicato che ha diritto di amministratore sul computer, ma non privilegi elevati a livello di dominio). Puoi comunque creare script PowerShell che eseguono un occultamento della password o utilizzare le operazioni pianificate ma a mio parere, se ne hai la possibilità, la soluzione migliore è implementare direttamente System Center Configuration Manager. In alternativa, se è sufficiente un'installazione immediata nei computer è preferibile utilizzare direttamente delle esecuzioni remote tramite PsExec. Infatti le ultime versioni di questa utility eseguono la crittografia anche dei comandi inviati (inclusi nome utente e password):

    http://blogs.technet.com/b/sysinternals/archive/2014/03/07/updates-process-explorer-v16-02-process-monitor-v3-1-psexec-v2-1-sigcheck-v2-03.aspx


    Grazie, provo a dare un'occhiata al System Center Configuration. ;)
    giovedì 24 settembre 2015 09:18
  • Ah, ok, questo mi mancava. :) Quindi, per esempio, se volessi creare una policy che voglio che si applichi il giorno dopo al riavvio di tutti i computers, devo considerare il fatto che quasi certamente questo non avverrà?

    Parlavo di STARTUP SCRIPT e non genericamente di POLICY, perchè il concetto precedentemente espresso è valido SOLO per gli STARTUP SCRIPT!

    Se vuoi fare delle prove per testare subito uno startup script dovrai fare come ti ho spiegato in precedenza, altrimenti non verrà eseguito e tu dirai: "ho provato ad inserire l'avvio degli script anche in una policy di logon, dato che in startup non si muoveva foglia."

    Curiosità tecnica: come mai capita questa cosa? Presumo, almeno basandomi sulla mia esperienza, che questo riguarda le installazioni ed interventi sui software ed esecuzione degli script; modifiche sul registro di sistema, copia files, creazione cartelle ecc. ho visto che vengono eseguiti al primo riavvio/login senza problemi.

    Cerco con un esempio di farti capire come funziona, spero di essere chiaro:

      • E' il tardo pomeriggio, l'orario di lavoro volge al termine, decidi di applicare una policy con uno startup Script, che dovrà essere eseguita il mattino seguente.
      • alcuni dei tuoi pc sono spenti
      • altri sono accessi dalla mattina ma vengono spenti un'ora dopo l'applicazione della startup policy...
        il giorno dopo riaccendendoli scoprirai che lo  startup script per qualche oscuro motivo, non viene eseguito!

      Devi fare attenzione le "policy utente", vengono APPLICATE e contestualmente ESEGUITE al primo logon, le  computer policy vengono sicuramente APPLICATE al primo riavvio, gli startup script,  questo è il passaggio oscuro... sono APPLICATI come policy al primo riavvio, se non presenti, ed eseguiti  alla succesiva accensione. Insomma questi script di avvio vengono eseguiti solo se applicati prima del riavvio. 

      INSISTO - Il pc è spento senza la GPO incriminata, viene acceso, parte l'APPLICAZIONE della policy che dice "all'avvio esegui lo script xxx" e NON "ASESSO viene eseguito lo script xxx", solo al sucessivo avvio verrà ESEGUITO lo script xxx!


      Qui sotto trovi la spiegazione tecnica "che ti mancava":) e altro, che chiedevi

      https://technet.microsoft.com/it-it/library/Criteri di gruppo per principianti

      Group Policy refresh interval for computers
      ...
      Specifies how often Group Policy for computers is updated while the computer is in use (in the background). This policy specifies a background update rate only for Group Policies in the Computer Configuration folder.

      By default, computer Group Policy is updated in the background every 90 minutes, with a random offset of 0 to 30 minutes. In addition to background updates, Group Policy for the computer is always updated when the system starts
      ...

      • Startup scripts are run under the Local System account, and they have the full rights that are associated with being able to run under the Local System account.
      • Beginning in Windows Vista, startup scripts are run asynchronously, by default. This is a different behavior from earlier operating systems.
      • Setting startup scripts to run synchronously may caus
      • In Windows 7 and Windows Vista, startup scripts that are run asynchronously will not be visible. Enabling the Run Startup Scripts Visible policy setting will have no effect when running startup scripts asynchronously.
    • e the boot process to run slowly.


    Per  disinstallare  qualche software le tre righe di batch citate sopra possono bastare  

    Ciao Gastone




    Gastone Canali >http://www.armadillo.it


    Se alcuni post rispondono al tuo quesito(non necessariamente i miei), ricorda di contrassegnarli come risposta e non dimenticare di contrassegnare anche i post utili. GRAZIE! Ricorda di dare un occhio ai link Click Here andHere

    giovedì 24 settembre 2015 23:55
    Moderatore
  • > Ah, ok, questo mi mancava. :) Quindi, per esempio, se volessi creare una policy che voglio che si applichi il giorno dopo al riavvio di tutti i computers, devo considerare il fatto che quasi certamente questo non avverrà?

    Parlavo di STARTUP SCRIPT e non genericamente di POLICY, perchè il concetto precedentemente espresso è valido SOLO per gli STARTUP SCRIPT!

    Se vuoi fare delle prove per testare subito uno startup script dovrai fare come ti ho spiegato in precedenza, altrimenti non verrà eseguito e tu dirai: "ho provato ad inserire l'avvio degli script anche in una policy di logon, dato che in startup non si muoveva foglia."

    Sì, sì, intendevo policy con startup script, dato che stavamo parlando di quello. :) Infatti ho poi specificato "Presumo, almeno basandomi sulla mia esperienza, che questo riguarda le installazioni ed interventi sui software ed esecuzione degli script; modifiche sul registro di sistema, copia files, creazione cartelle ecc. ho visto che vengono eseguiti al primo riavvio/login senza problemi." ;)

    >Curiosità tecnica: come mai capita questa cosa? Presumo, almeno basandomi sulla mia esperienza, che questo riguarda le installazioni ed interventi sui software ed esecuzione degli script; modifiche sul registro di sistema, copia files, creazione cartelle ecc. ho visto che vengono eseguiti al primo riavvio/login senza problemi.

    Cerco con un esempio di farti capire come funziona, spero di essere chiaro:

      • E' il tardo pomeriggio, l'orario di lavoro volge al termine, decidi di applicare una policy con uno startup Script, che dovrà essere eseguita il mattino seguente.
      • alcuni dei tuoi pc sono spenti
      • altri sono accessi dalla mattina ma vengono spenti un'ora dopo l'applicazione della startup policy...
        il giorno dopo riaccendendoli scoprirai che lo  startup script per qualche oscuro motivo, non viene eseguito!

      Devi fare attenzione le "policy utente", vengono APPLICATE e contestualmente ESEGUITE al primo logon, le  computer policy vengono sicuramente APPLICATE al primo riavvio, gli startup script,  questo è il passaggio oscuro... sono APPLICATI come policy al primo riavvio, se non presenti, ed eseguiti  alla succesiva accensione. Insomma questi script di avvio vengono eseguiti solo se applicati prima del riavvio. 

      INSISTO - Il pc è spento senza la GPO incriminata, viene acceso, parte l'APPLICAZIONE della policy che dice "all'avvio esegui lo script xxx" e NON "ASESSO viene eseguito lo script xxx", solo al sucessivo avvio verrà ESEGUITO lo script xxx!


      Qui sotto trovi la spiegazione tecnica "che ti mancava":) e altro, che chiedevi

      https://technet.microsoft.com/it-it/library/Criteri di gruppo per principianti

      Group Policy refresh interval for computers
      ...
      Specifies how often Group Policy for computers is updated while the computer is in use (in the background). This policy specifies a background update rate only for Group Policies in the Computer Configuration folder.

      By default, computer Group Policy is updated in the background every 90 minutes, with a random offset of 0 to 30 minutes. In addition to background updates, Group Policy for the computer is always updated when the system starts
      ...

      • Startup scripts are run under the Local System account, and they have the full rights that are associated with being able to run under the Local System account.
      • Beginning in Windows Vista, startup scripts are run asynchronously, by default. This is a different behavior from earlier operating systems.
      • Setting startup scripts to run synchronously may caus
      • In Windows 7 and Windows Vista, startup scripts that are run asynchronously will not be visible. Enabling the Run Startup Scripts Visible policy setting will have no effect when running startup scripts asynchronously.
    • e the boot process to run slowly.


    Per  disinstallare  qualche software le tre righe di batch citate sopra possono bastare  

    Sei stato chiarissimo. Quindi per quanto riguarda le startup script, il server non impone al client di eseguire subito lo script, ma gli dice di eseguirlo al prossimo riavvio. L'inghippo sta nel quando glielo dice: se quando è ancora acceso o mentre si sta avviando. Nel momento in cui creo la policy, nel primo caso, lo script verrà eseguito al primo riavvio, nel scondo caso invece al secondo riavvio successivo.

    Ti ringrazio tanto per la tua pazienza, chiarezza e per tutte le informazioni che mi hai dato. Grazie anche per le documentazioni. Ora penso di essere uscito dal tunnel nebbioso del "perché non va?". ;)

    venerdì 25 settembre 2015 09:54
  • Ciao e alla prossima

    Gas


    Gastone Canali >http://www.armadillo.it


    Se alcuni post rispondono al tuo quesito(non necessariamente i miei), ricorda di contrassegnarli come risposta e non dimenticare di contrassegnare anche i post utili. GRAZIE! Ricorda di dare un occhio ai link Click Here andHere

    venerdì 25 settembre 2015 10:36
    Moderatore