none
GPO login script using powershell without network access?

    Question

  • In our domain we do not wait for the network to allow users to login, as we have had situations where users were waiting for 3-5 minutes for DirectAccess to get a connection before they could login to their PCs when off premises. We also find that our computers have not established network connectivity yet when logins occur - that may come 30-90 seconds later.  I have a powershell script for creating a signature file for Outlook that we want to run as a login script linked via GPO.  The script, at the moment anyway, is located in the \\domain\netlogon\logon_scripts\ directory so we can run the script unsigned. However, since the machines often have not completed network connections when the logon occurs, powershell logon scripts frequently fail to execute.

    I need a method to run a centrally-managed script, preferably written in powershell (though I will consider other options), at login without requiring that the script be signed and that will adjust if network connectivity is not yet in place.  The ideal solution would run a powershell script to detect if there is network connectivity, and if not it would go to sleep for a couple of minutes and then check again.

    I've found discussions of some of the issues with this in my searching, but no actual solutions.  Anybody have any ideas?

    Thanks in advance for your help!

    • Moved by Bill_Stewart Monday, May 4, 2015 9:01 PM Move to more appropriate forum
    Monday, May 4, 2015 8:36 PM

Answers

All replies

  • > I need a method to run a centrally-managed script, preferably written in
    > powershell (though I will consider other options), at login without
    > requiring that the script be signed and that will adjust if network
    > connectivity is not yet in place.
     
    Copy all scripts to a local folder (%ProgramData%\xyz) and execute from
    there.
     
    The copy can be done via a scheduled task or a shutdown script or
    whatever :)
     

    Greetings/Grüße, Martin

    Mal ein gutes Buch über GPOs lesen?
    Good or bad GPOs? - my blog…
    And if IT bothers me - coke bottle design refreshment (-:
    Tuesday, May 5, 2015 7:55 AM
  • Create a "Script distribution policy" that uses GPO preferences section to copy/update logon script from your central location to a folder locally on client. then change your client GPO to refer to this local script.

    Gleb.

    Tuesday, May 5, 2015 9:33 AM
  • Thank you for the suggestions.  The limitation with these suggestions is that powershell won't run locally unless it is signed, which we want to avoid.  There is an exception to this when the script is being run from \\domain\netlogon, as being part of the domain grants it trust, but that leads back to the requirement for network access when the script runs.  Is there a way to effectively run a local, non-signed powershell scripts without changing the overall execution policy (we are not allowed to reduce the default execution policy)?
    Tuesday, May 5, 2015 12:24 PM
  •  
    >   The limitation with these suggestions is that powershell won't run
    > locally unless it is signed,
     
    Do you have AllSigned set as execution policy?
     
    BTW: There is no execution policy that will allow scripts from UNC paths
    but block local scripts...
     
     

    Greetings/Grüße, Martin

    Mal ein gutes Buch über GPOs lesen?
    Good or bad GPOs? - my blog…
    And if IT bothers me - coke bottle design refreshment (-:
    Wednesday, May 6, 2015 10:51 AM
  • We have RemoteSigned as the execution policy.  But scripts run from \\domain\netlogon don't seem to by subject to the same restrictions, or maybe there's something else involved that I don't realize.

    Wednesday, May 6, 2015 8:51 PM
  • maybe your scheduled task, can invoke:

    powershell.exe -executionpolicy bypass doStuff.ps1

    https://technet.microsoft.com/en-gb/library/hh847736.aspx


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Wednesday, May 6, 2015 9:28 PM