none
Computer GPO Startup scripts not working in Windows 10 RRS feed

  • Question

  • Hi.

    I have a specific problem. I have some scripts (VBS scripts) that rely on Administrative rights (enumerating different keys in HKLM\System part of Registry and writing/changing some values in those keys). In Windows 7 I would distribute those scripts through Computer GPO at Startup ... scripts would be run as SYSTEM and everything worked fine. Unfortunately, I noticed scripts are not doing their job when executing through GPO on Windows 10 machines. I investigated further and my conclusion so far is that this issue is related with SYSTEM no longer having Administrative rights during execution (UAC is disabled on the machine but this doesn't seem to matter). Also I noticed that if I create a scheduled task to execute the script during computer startup and configure the task to run under "SYSTEM account with Highest privileges" then everything works fine even on Windows 10 machines.

    So, my question would be, is there a way for those VBS scripts to successfully do their job on Windows 10 machines, even when we are distributing them through Computer GPO at Startup?

    Thank you very much. Your input/explanation/help is very much appreciated.


    • Edited by khrbud Saturday, March 9, 2019 8:51 AM misspeling
    Saturday, March 9, 2019 8:49 AM

Answers

  • If we modify the script and remove "On Error Resume Next" just before the values should be written to Registry, what you get is an error that states "Registry path does not exist" (which is BS).


    The WMI provider for the registry may not be accessible during startup.   Windows 10 is much different from other systems.

    Altering the firewall during startup is not allowed. This is a security constraint. You should be using Group Policy to set firewall rules. The GP can be applied because it is allowed to alter the firewall and it only runs after the startup is complete. During startup Windows 8 and later protect the firewall and other parts of the OS that need to be protected until all of the other security components are up and validated.

    You can try to alter the application of GP to only run the script at the end of startup but I don't think that will make a difference.


    \_(ツ)_/

    • Marked as answer by khrbud Saturday, March 9, 2019 5:20 PM
    Saturday, March 9, 2019 4:39 PM

All replies

  • There is no way to answer this without access to your system.  You will have to try to troubleshoot your systems and GPO.  Since the scripts run correctly under all other circumstances the scripts are not the issue and this is not a scripting issue.

    You can open an incident with MS support for help if you do not know how to troubleshoot GP issues.


    \_(ツ)_/

    • Marked as answer by khrbud Saturday, March 9, 2019 9:50 AM
    • Unmarked as answer by khrbud Saturday, March 9, 2019 5:20 PM
    Saturday, March 9, 2019 9:23 AM
  • Thank you for a quick answer. Yeahh, something strange is going on? I even managed to test one more thing. I have an in-house application that we programed that relies on Administrative rights. App needs to do it's job during (you guessed it) Computer startup. But Computer startup GPO doesn't support executing apps, only VBS or PowerShell scripts. So, I have a script that executes the app and that script is a Computer startup script. Script executes just fine on Windows 10 (I write to event log when the script is executed, and the record is there), but application doesn't (not on Windows 10 machines). And again, if I create a scheduled task to execute the application during computer startup and configure the task to run under "SYSTEM account with Highest privileges" then everything works fine. So, the problem is definitely related to the user rights (scripts and applications have to be executed as "Run as Administrator" even though they are being executed under SYSTEM account and with UAC disabled).

    I will try and post this question under Windows forum, try and see if someone has some idea why this is happening.

    Saturday, March 9, 2019 9:50 AM
  • UAC has no effect on the SYSTEM account.  UAC only applies to interactive sessions.  The issue is likely what the app is trying to do and the way the system account runs when executed during startup.  Contact the app developer for help tracking this down.  Windows 10 has more security restrictions and its startup behavior is very different from previous versions of PowerShell.

    The most common cause of the failure is an app that prompts during execution.


    \_(ツ)_/

    Saturday, March 9, 2019 9:56 AM
  • And this would be the situation when the message "please contact your Administrator" pops-up and you are the Administrator :-)) ... I'm the frickin app developer and all I get is "access denied" (yeahh, I'm app developer, DB admin, Domain admin, DHCP admin, IT security specialist, support technician, mail server admin, Web server admin, FTP server admin, VPN and RADIUS server admin, PKI server admin, IT network technician, Production network admin, ... two time youngest winner of my company's, with over 3500 employees and 7 branches all over the country, annual achievement reward ... all rolled into one and all for under 1000 euros ... I hate my life and I hate my country :-) ... I should probably move to Ireland, work as a busboy and earn more money).

    Thank you one more time.

    P.S.

    One more thing. All the things I have mentioned, all of the servers I installed ... no outside integrator's or support.


    • Edited by khrbud Saturday, March 9, 2019 10:39 AM misspling
    Saturday, March 9, 2019 10:33 AM
  • Take a break.  Get a ukulele and serenade the Irish lassies.

    Been there done that.  It is good training for something....

    Try to discover what your program is doing that would violate the startup rules.  Are you catching all exceptions?  Have you managed all error paths?

    Is the program signed???


    \_(ツ)_/

    Saturday, March 9, 2019 11:09 AM
  • The app is signed. Certificate is trusted.

    But this is not only related to my app. Lets take a look at this script:

    1. works OK as a Windows 7 startup script

    2. works OK through Windows 10 task scheduler (under SYSTEM account with the option Highest privileges enabled)

    3. doesn't work as a Windows 10 startup script

    Option Explicit
    Dim objWMIService, colItems, objItem, WSHShell, objREG
    Dim varRegKey, arrRegValueNames, arrRegValueTypes, varRegValueName, varRegValue
    
    If WScript.Arguments.Count = 0 Then WScript.Quit
    If WScript.Arguments(0) <> "/R" Then WScript.Quit
    
    varRegKey = "SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules"
    Const varHKLM = &H80000002
    
    Set objWMIService = GetObject("winmgmts:\\.\root\cimv2")
    Set colItems = objWMIService.ExecQuery("Select * From Win32_OperatingSystem")
    For Each objItem in colItems
     If InStr(objItem.Caption, "Windows XP") Then
      Set objWMIService = Nothing
      Set colItems = Nothing
      WScript.Quit
     End If
    Next
    
    Set WSHShell = CreateObject("WScript.Shell")
    Set objREG = getObject("Winmgmts:root\default:StdRegProv")
    
    If objREG.enumValues(varHKLM, varRegKey, arrRegValueNames, arrRegValueTypes) = 0 Then
     For Each varRegValueName In arrRegValueNames
      If Left(UCase(varRegValueName), 4) = "FPS-" AND InStr(UCase(varRegValueName), UCase("-In")) Then
       varRegValue = ""
       On Error Resume Next
       varRegValue = WSHShell.RegRead("HKEY_LOCAL_MACHINE\" & varRegKey & "\" & varRegValueName)
       On Error Goto 0
       If varRegValue <> "" AND InStr(varRegValue, "|Active=TRUE|") Then
        varRegValue = Replace(varRegValue, "|Active=TRUE|", "|Active=FALSE|")
        On Error Resume Next
        WSHShell.RegWrite "HKEY_LOCAL_MACHINE\" & varRegKey & "\" & varRegValueName, varRegValue, "REG_SZ"
        On Error Goto 0
       End If
      End If
     Next
    End If
    
    Set objWMIService = Nothing
    Set colItems = Nothing
    Set WSHShell = Nothing
    Set objREG = Nothing
    WScript.Quit

    If we modify the script and remove "On Error Resume Next" just before the values should be written to Registry, what you get is an error that states "Registry path does not exist" (which is BS).

    So, I tried and posted the same question in "Windows 10 Security" part of the forum but they redirected me to this question here :-) ... maybe I shouldn't have marked this question as answered. But your original answer makes sense ... this is not a script error, this is Windows behavior and how it processes startup scripts (or how I have configured something that breaks the default behavior).


    • Edited by khrbud Saturday, March 9, 2019 2:32 PM misspeling
    Saturday, March 9, 2019 2:31 PM
  • You are not managing errors.

    What app is there in that script?

    Why would you use WMI to access the registry when VBScript has a registry object?

    Why aren't you doping this with PowerShell?


    \_(ツ)_/

    Saturday, March 9, 2019 4:27 PM
  • If we modify the script and remove "On Error Resume Next" just before the values should be written to Registry, what you get is an error that states "Registry path does not exist" (which is BS).


    The WMI provider for the registry may not be accessible during startup.   Windows 10 is much different from other systems.

    Altering the firewall during startup is not allowed. This is a security constraint. You should be using Group Policy to set firewall rules. The GP can be applied because it is allowed to alter the firewall and it only runs after the startup is complete. During startup Windows 8 and later protect the firewall and other parts of the OS that need to be protected until all of the other security components are up and validated.

    You can try to alter the application of GP to only run the script at the end of startup but I don't think that will make a difference.


    \_(ツ)_/

    • Marked as answer by khrbud Saturday, March 9, 2019 5:20 PM
    Saturday, March 9, 2019 4:39 PM
  • You are not managing errors.

    When script is not important or it's not important for me to execute correctly every single time, yeahh I don't manage errors.

    What app is there in that script?

    I was talking about TWO examples. This example is script only.

    Why would you use WMI to access the registry when VBScript has a registry object?

    Now you got me. As I see it I use WMI only to test OS or did I just say a stupidest thing ever and you are thinking "what an idiot"?

    Why aren't you doping this with PowerShell?

    Because Microsoft concluded how it would be stupid idea to distribute PowerShell through MSI package (I can't deploy it through GPO "Software Installation" and I don't like using GP Preferences and TaskScheduler for this one ... lets say I'm an old fashioned guy that likes GPO's and GP Administrative Templates and I will use GP Preferences only as a last resort when nothing else works). Windows 7 comes with PowerShell v2 and Windows 10 comes with PowerShell v4 or v5 and I don't have patience to figure out which command will work where and why (when the script is not important, and this one isn't).

    I know how to code in PowerShell (at least I hope so) but when the scripts are not that important and I don't want to put that much effort, I use VBS. Not to mention that this script I have sent you is not good at all (I differentiate FPS rules based on a name of the REG value instead of using "EmbedCtxt=@FirewallAPI.dll,-28502" and "Dir=In") so please do not judge me based on the quality of this script.

    Saturday, March 9, 2019 4:59 PM
  • Altering the firewall during startup is not allowed. This is a security constraint. You should be using Group Policy to set firewall rules. The GP can be applied because it is allowed to alter the firewall and it only runs after the startup is complete. During startup Windows 8 and later protect the firewall and other parts of the OS that need to be protected until all of the other security components are up and validated.

    OK, this makes sense. But why would this work then when I use TaskScheduler to distribute the script (trigger is "At startup"). Yeahh, but this certainly makes sense.

    Saturday, March 9, 2019 5:11 PM
  • Altering the firewall during startup is not allowed. This is a security constraint. You should be using Group Policy to set firewall rules. The GP can be applied because it is allowed to alter the firewall and it only runs after the startup is complete. During startup Windows 8 and later protect the firewall and other parts of the OS that need to be protected until all of the other security components are up and validated.

    OK, this makes sense. But why would this work then when I use TaskScheduler to distribute the script (trigger is "At startup"). Yeahh, but this certainly makes sense.

    The task sched does not run until after the startup script and other things are run to completion. In fact the newer recommendation is tio use a startup task and not a startup script. Startup and Login scripts are mostly deprecated and will likely be removed at some time. You should be migrating off of those now as it can take some time to learn, build and test with the newer methods in GP and with the task scheduler.


    \_(ツ)_/

    Saturday, March 9, 2019 6:18 PM
  • Why would you use WMI to access the registry when VBScript has a registry object?

    Now you got me. As I see it I use WMI only to test OS or did I just say a stupidest thing ever and you are thinking "what an idiot"?

    Shell.RegRead/RegWrite do the same thing as WMI and use the API and not COM.

    PowerShell with the registry provider also uses that API and allows enumeration.  It is much easier to use and works in PS2 and later.


    \_(ツ)_/

    Saturday, March 9, 2019 6:21 PM
  • Why aren't you doping this with PowerShell?

    Because Microsoft concluded how it would be stupid idea to distribute PowerShell through MSI package (I can't deploy it through GPO "Software Installation" and I don't like using GP Preferences and TaskScheduler for this one ... lets say I'm an old fashioned guy that likes GPO's and GP Administrative Templates and I will use GP Preferences only as a last resort when nothing else works). Windows 7 comes with PowerShell v2 and Windows 10 comes with PowerShell v4 or v5 and I don't have patience to figure out which command will work where and why (when the script is not important, and this one isn't).

    I know how to code in PowerShell (at least I hope so) but when the scripts are not that important and I don't want to put that much effort, I use VBS. Not to mention that this script I have sent you is not good at all (I differentiate FPS rules based on a name of the REG value instead of using "EmbedCtxt=@FirewallAPI.dll,-28502" and "Dir=In") so please do not judge me based on the quality of this script.

    PowerShell scripts can be easily distributed via MSI.  I have never heard that Microsoft said that.  MSI can distribute anything including text files.

    Local startup scripts can be specified with a GPO and do not require GPP.

    Windows 7 should be upgraded to WMF 5.1 and PS2 should not be used. 
    You have until November to upgrade Windows 7 or you will no longer get updates and patches.


    \_(ツ)_/

    Saturday, March 9, 2019 6:24 PM
  • Yeahh, read that today (The Startup Script is Dead). I will begin the process of migration on monday. Thanks.
    Saturday, March 9, 2019 6:33 PM
  • Will check it out. Thanks.
    Saturday, March 9, 2019 6:34 PM
  • Yeahh, read that today (The Startup Script is Dead). I will begin the process of migration on monday. Thanks.

    Note the date.  The earliest warnings cam before W10 was released.  W10 hammered a lot of scripts.  I have not been using Logon or Startup scripts since Windows XP on WS2000 and later.  They are a hangover from NT4.  WS2003 eli innated the need for drive mapping via script with the delivery of GP and WS2008 added the rest of the GP tools needed.  MS bought a company that specialized in extending GP and used their products on WS2008.

    If you don't like GPP you can build your own ADMX templates.


    \_(ツ)_/

    Saturday, March 9, 2019 6:43 PM
  • PowerShell scripts can be easily distributed via MSI.

    WMF is a MSU package. Software distribution from GPO is MSI only. I know, I should use TS and wusa.

    You have until November to upgrade Windows 7 or you will no longer get updates and patches.

    You crack me up. Well no shit, Einstein! As of 01.01.2019. we no longer have any Windows XP in our firm (yeahhh, you heard that correctly) and only, ONLY because I was conducting a terror campaign all through the last year. As of couple of weeks ago we finally managed to turn on the SMB packet signing as mandatory and shut down the SMBv1. I'm one of Admins that implemented almost all the recommendations from the Pass-the-hash white papers 1 and 2 (including denying through GPO "Domain Admins" to logon to only selected servers, I think 5 servers and on those servers ONLY Domain Admins can logon to ... my whole frickin Domain is separated in Tier0, Tier1.A, Tier 1.B, Tier 1.C, ... and Tiers 2.A and 2.B ... and users in each tier can only logon to those tiers, no where else, and this is implemented not through recommendations but through GPO policies so no fucking around). My firm is separated in one IT network and two production networks ... I'm admin on one of the two production networks. My coworkers hate me, they think I'm paranoid bastard but when WannaCry ransomware were encrypting data on servers on our IT network and the other production network while ours stayed intact (no single one infection, including XP machines because of Software Restriction Policies that I have implemented 5 years before), no one even said thanks.

    If you will be willing to come to my firm and explain to my managers (pencil pushers whole lot of them) how we should buy Enterprise versions of Windows 10 and not OEM Pro versions, you would be more than welcome because there is nothing harder than being the prophet in your own village. If you would be willing to explain to my managers how they should invest more in new hardware, how we should start buying Server 2019 CAL licenses just to be able to use new OS, yeahhh you would be more than welcome.

    So, one very smart old Buddhist monk once told me to "Take a break. Get a ukulele and serenade the Irish lassies." and I'm going to do that right now. Thank you for all the help. It was very much appreciated.

    Saturday, March 9, 2019 7:30 PM
  • I thought you meant using MSO with scripts.  WMF 5.1 can be remotely installed but not with an MSI.  Search and you will find many ways to do it.


    \_(ツ)_/

    Saturday, March 9, 2019 7:44 PM
  • You crack me up. Well no shit, Einstein! As of 01.01.2019. we no longer have any Windows XP in our firm (yeahhh, you heard that correctly) and only, ONLY because I was conducting a terror campaign all through the last year.

    Sounds like me over 30+ years. Constantly at war with idiot managers. Keep it up. You will be appreciated.

    Good luck.


    \_(ツ)_/

    Saturday, March 9, 2019 7:46 PM
  • Couple of tips for someone migrating his Startup scripts to Task scheduler in Active Directory environment (through Group Policy Preferences).

    1. Although GPP allows you to specify really long names for the Task, don't. There is a good chance Computers will not pick up that Task. Use description instead.

    2. When specifying the user account under which task will be executed, and if that user is a "SYSTEM", in the field "From this location" (on "Select User or Group" screen) leave your Domain (do not change it to Computer) ... If you change it, and if you specify "SYSTEM" you will get "BUILTIN\SYSTEM" and there is a good chance Computers will not pick up that Task. If you don't change it, and if you specify "SYSTEM" you will get "NT AUTHORITY\SYSTEM" and everything should work.

    3. Do not check the "Hidden" checkbox because there is a good chance task will simply not execute. Why? Because of cheese, that's why.

    4. When specifying trigger, be sure to check the "Delay task for up to (random delay)" and use at least "1 minute". If you don't, there is a good chance task will run, but the script won't do what it's meant to do.

    5. If you are sure you have done everything correctly and the task simply won't execute, delete the task and recreate it with the same parameters ... there is a good chance this will help.

    Have a nice day.

    Monday, March 11, 2019 4:33 PM