none
running a VBS script with parms

    Question

  • I am calling a VBS script in my GPO as shown above.   If you click BROWSE both the .vbs and .xml are there, as part of the GPO.    This is a Computer policy.  On my target machine I've rebooted many times and I've run gpresult /h.  My policy is being applied yet the .vbs never runs.   How come?

    If I run this .vbs and .xml from my test machine it works.

    c:\>ConfigMgrStartup1.vbs /config:ConfigMgrStartup.xml     that works.  how do I make it work from the GPO? 


    mqh7

    Friday, February 26, 2016 6:01 PM

Answers

  • > On a file server I created a new share.   D:\cm2012client (or
    > \\Server\d$\cm2012client <file://%5C%5CServer%5Cd$%5Ccm2012client>)
     
    So the share here is not Ccm2012client, but d$ - and by default, access
    to admin shares is restricted to administrators only. You should create
    a _real_ share for your purpose :)
     
    • Marked as answer by mqh7 Tuesday, March 01, 2016 6:14 PM
    Tuesday, March 01, 2016 4:51 PM

All replies

  • My policy is being applied yet the .vbs never runs.   How come?

    How do you know the vbs "never runs" ?

    maybe it *is* running, but is encountering a problem internally within the script?

    e.g. the startup script processor, will probably be running it like this:

    \\contoso.com\sysvol\contoso.com\policies\<GUID>\machine\scripts\scriptname.vbs /config:\\contoso.com\sysvol\contoso.com\policies\<GUID>\machine\scripts\scriptcfg.xml

    (I may have the folder structure incorrect, but you should see the idea ;)

    So, does your script, with parameters, like that, still function correctly?

    you can check the logs on the client, for the startup script events, to see if it is failing to execute the script or not.

    you could also put some logic into the script, at the start of the script, to create some temp file, and then see if that temp file is created, that the script is actually being executed at all, or not executed at all.


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Saturday, February 27, 2016 9:20 AM
  • assuming you are trying to use Jason's script, I note this from his documentation:

    http://blog.configmgrftw.com/configmgr-client-startup-script/

    The Script Log File The script automatically generates a cumulative log file of all its activity and actions named ConfigMgrStartup.vbs.log. If the system does not have a ConfigMgr client agent installed, this log file is placed in the system temp directory (usually C:\Windows\Temp). If the system does have the client agent installed, the log file will be stored in ConfigMgr client agent log directory. This log file is in a format readable by Trace32.

    So, does the logfile he mentions, exist?


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Saturday, February 27, 2016 9:25 AM
  • As mentioned by Don above, first we need to figure out whether the script is actually being executed or not.
     
    Also, if you put it into the Startup Group Policy, the script runs as the computer's SYSTEM context when it does execute. However, when you run it on your test machine manually, it runs under the user's own security context.
     
    So you need to make sure the system context has the permission to access whatever rescource the script requires.
     

    Regards,

    Ethan Hua


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com

    Monday, February 29, 2016 2:37 AM
    Moderator
  • > *c:\>*ConfigMgrStartup1.vbs /config:ConfigMgrStartup.xml     that
    > works.  how do I make it work from the GPO?
     
    Are you sure it does not run? Or does it silently fail due to not
    finding the XML file? If the latter, I'd suggest to create a wrapper
    batch file:
     
    @echo off
    cscript %~dp0ConfigMgrStartup1.vbs /config:%~dp0COnfigMgrStartup.xml
     
    Help on %~dp0 can be found in "for /?"
     
    Monday, February 29, 2016 10:03 AM
  • Yes it is running.  I even did what Martin Binder suggested, I had a .CMD file call my VBS script.    Here is my .cmd file I used to call it. 

    echo "this script ran  %time%" >> "c:\temp\echo.txt"
    cscript %~dp0ConfigMgrStartup.vbs /config:%~dp0COnfigMgrStartup.xml
    echo "this script ran TWICE %time%" >> "c:\temp\echo2.txt"

    I have my GPO run this .CMD file.   I reboot my test workstation and both .TXT files get created yet the vbs script does nothing.  So  copied the .VBS and .XML file to my test machine and ran it from a CMD window.  The cm2012 client gets installed.

    I am using my own account which is both a local and domain admin and has full rights to all required shares. 


    mqh7

    Monday, February 29, 2016 6:20 PM
  • > cscript %~dp0ConfigMgrStartup.vbs /config:%~dp0COnfigMgrStartup.xml
     
    Change this to
     
    cscript %~dp0ConfigMgrStartup.vbs /config:%~dp0COnfigMgrStartup.xml
     >%temp%\%~n0.log 2>&1
     
    Then examine the logfile (%temp%\ConfigMgrStartup.log) - maybe you are
    experiencing a VBS runtime error...
     
    Tuesday, March 01, 2016 9:56 AM
  • OK Martin, I did what you suggested and the log file says "Access is denied."   Now, this is very odd since I have done the following prior to running this GPO.

    On a file server I created a new share.   D:\cm2012client (or \\Server\d$\cm2012client

    I then granted Domain Computers READ to the share.

    I then granted Domain Computers FULL RIGHTS to the security.

    Yet it does not get access when run via GPO.  But....if I log into my test workstation and I open up a CMD window I can manually run the command it does work. 

    So how come I do have Access from the workstation running manually but I don't have Access from a running GPO?   Thank you sir.


    mqh7

    Tuesday, March 01, 2016 3:49 PM
  • > On a file server I created a new share.   D:\cm2012client (or
    > \\Server\d$\cm2012client <file://%5C%5CServer%5Cd$%5Ccm2012client>)
     
    So the share here is not Ccm2012client, but d$ - and by default, access
    to admin shares is restricted to administrators only. You should create
    a _real_ share for your purpose :)
     
    • Marked as answer by mqh7 Tuesday, March 01, 2016 6:14 PM
    Tuesday, March 01, 2016 4:51 PM
  • For anyone who finds this post, I had a similar problem in an SCCM 2012R2 lab environment I configured. By default the computer's account does not have permissions to the \\SCCMSERVER\SMS_XXX\Client folder (where XXX is your site code). To resolve this I added the "Domain Computers" security group to this folder with read only permissions and the script works - this is because a startup script runs under the computer's account, so the computer's account needs to be able to connect to the share. I am not sure if this is a security risk for production environments, but it worked for my purposes.


    • Edited by BenSBB Tuesday, May 31, 2016 4:42 PM
    Tuesday, May 31, 2016 4:41 PM