locked
CCMSetup via startup script RRS feed

  • Question

  • I am attempting to use a startup script to use logic to determine if a SCCM Client needs to be installed on a client and then it kicks off ccmsetup with no parameters since it gets those from AD.  This script itself works great and does what I need it to do.  When we configured it as a startup script, the script runs correctly and launches ccmsetup when it is supposed to.  CCMSetup runs to completion on both Vista and Windows 7 systems.  On Windows XP systems, ccmsetup launches and gets the correct parameters from AD and goes to the correct MP, but when it begins to download client.msi, ccmsetup seems to halt and never moves any further.  The management point is ok because vista and Win7 are using the same one.  And if I run the script interactively it runs to completion.  I even run it with PSEXEC -s to test running as local system and it works fine and runs to completion.  It's only when it runs as a system startup script that ccmsetup halts.  Permissions are ok but as a quick test I opened up permissions completely but that did not help.  I can see in the ccmsetup log that it is running as system and not a user which may have insufficient rights.  The IIS logs on the server show a successful connnection with several 206 return codes wich I believe is successful partial downloads.  The temp client MSI file is present in the ccmsetup folder as a temp file with a name such as BIT1.TMP and a size of 17,429KB, the size of client.msi and it remains. The last 2 lines in the ccmsetup.log are :

    Starting BITS download for client deployment files
    Download Update: Connecting to the server.

    IIS log will show :
    W3SVC1 10.35.120.46 GET /CCM_Client/ccmsetup.cab - 5080 - 10.22.37.38 ccmsetup 200 0 0

    followed by about 14 of the same entries at the time client.msi is downloading via bits:
    W3SVC1 10.35.120.46 GET /CCM_Client/i386/client.msi - 5080 - 10.22.37.38 Microsoft+BITS/6.7 206 0 0

    Bottom line, same clients running Windows XP to same server hang in this spot every time when ccmsetup runs through startup script but those clients to same server run 100%successful every time when ccmsetup is run in any way other than through a system startup script.  They run to completion interactively, through client push, remotely using psexec, etc.  Windows Vista and Win 7 clients run to completion always, even from the startup script.  So it's only XP running ccmsetup via startup script that is the problem.  I have seen a few similar posts in another forum with no solution but there was mention of a possible timing issue when running through startup script where perhaps some services have not yet started.  Any help would be greatly appreciated.

    Wednesday, April 28, 2010 1:52 PM

Answers

  • I had what sounds like the same problem, or at least similar.  I'm still testing my solution, but it seems on some Windows XP machines CCMSETUP was being killed off during the startup process, I don't know why.  However, changing my script slightly to make it wait for CCMSETUP seems to have fixed the problem.

    See my post here for details of what I found and the way I changed my script code:

    http://social.technet.microsoft.com/Forums/en-US/configmgrsetup/thread/77d67d49-6bb3-4780-906c-5be46a107c21

    I hope this is of some help.

    • Proposed as answer by jsc.19 Thursday, April 29, 2010 9:32 PM
    • Marked as answer by Mitch Schreiber Friday, April 30, 2010 9:54 AM
    Wednesday, April 28, 2010 9:59 PM
  • To follow up on some findings after further testing, JSC.19 was correct in that when ccmsetup is running as a service, it is ok to launch it with WshShell.Run smsinstall,0,TRUE.  Return is passed from ccmsetup back to the vbscript and it exits.  When running ccmsetup with command ine parameters it runs as a service by default.  However, I am running ccmsetup with no parameters so that it retrieves the parameters from Active Directory since we have published to AD.  I have found that when running ccmsetup without parameters, it does not run as a service.  Therefore, if I use the true option of wshell.run,the script will wait until ccmsetup completes.  I tested this in a login script on test machines and it resulted in long waits during login.  If logging in while the script was running we would see the "running startup scripts" dialogue for as long as it took for ccmsetup to complete!  Not sure why CCMSETUP does not run as a service when not using command line parameters.  It gets the command line parameters from the client push settings.  Thought about specifying /service option which should be default but you cannot include ccmsetup parameters in client push settings, only client.msi parameters.  So for me the fix for now is to kick off ccmsetup by spawning a scheduled task from the startup script.  See above.
    Friday, April 30, 2010 10:10 PM

All replies

  • I had what sounds like the same problem, or at least similar.  I'm still testing my solution, but it seems on some Windows XP machines CCMSETUP was being killed off during the startup process, I don't know why.  However, changing my script slightly to make it wait for CCMSETUP seems to have fixed the problem.

    See my post here for details of what I found and the way I changed my script code:

    http://social.technet.microsoft.com/Forums/en-US/configmgrsetup/thread/77d67d49-6bb3-4780-906c-5be46a107c21

    I hope this is of some help.

    • Proposed as answer by jsc.19 Thursday, April 29, 2010 9:32 PM
    • Marked as answer by Mitch Schreiber Friday, April 30, 2010 9:54 AM
    Wednesday, April 28, 2010 9:59 PM
  • Thank you jsc.19 for a great post.  I think we are on the same page because switching the option on wshell.run for ccmsetup to true also works for me.  Not sure if it would be an issue since ccmsetup can run for a long time for some of our clients on slow networks so not sure what impact if any it would have on the bot process to have the startup script running for several minutes.  I used the false option so that the script could just kick off ccmsetup and then move on.  The AD guys liked that and may not like it if the script has to wait. I also tried setting it back to false and putting a 60 second sleep after the wshell.run command and this time client.msi did download but ccmsetup just stopped later on during the file copy.  So I was originally thinking the problem had to do with a bits download issue but I now think that was a coincidence and ccmsetup just gets killed after the vbscript exits. I read somewhere else that someone changed their script to create a scheduled task to run ccmsetup rather than call it directly from within the vbscript.  Have not tried that yet but it would be a last resort.  Thanks again and please let me know if you find anything new.  I will do the same.
    Thursday, April 29, 2010 4:50 PM
  • I'm glad I was able to help.  I wasted several full days on this only in the last week, a interesting coincidence to see your post so close to mine.  I only came back to it actually being the script after seeming to rule everything else I could think of out of the equation.  I wish I understood why on some machines CCMSETUP is killed off, I'm guessing some sort of start-up environment is set up and torn down by the OS and its not aware CCMSETUP is running, but that is a total guess.

    I had the same concern about start-up times while the script waited, but it turns out to be OK, even on slow links, because CCMSETUP installs as a service, and that is when control gets returned to the script.  This initial step by CCMSETUP is quick in my environment, obviously you'll need to test in yours.  The CCMSETUP service then does the client install, and that can take ten minutes or more at some sites in my environment, but there is no hold up to the machine or user.  I was also thinking about using the start-up script to configure a scheduled task if I found it was impacting start-up times.  Eventually I intend to move to using the Software Updates feature to push the SCCM client to machines and get away from the script, but I can't do that just yet.

    I put my production change in last night, so hopefully when I get in to work this morning I'll see my missing 15% of machines start to show up in SCCM.  Fingers crossed.

    Thursday, April 29, 2010 9:32 PM
  • That seems to be true when I run the script with the false option.  CCMSetup launches then control returns to the script and it ends and ccmsetup keeps going on its own.  When I run it manually I can see this happen.  When I use the True option and run it manually, ccmsetup is launched but control does not return to the vbscript until ccmsetup is completely done so the startup vbscript keeps running until ccmsetup is done.  I am not really sure if that is really a problem that impacts the user and startup process. It's just that anything that would need to occur in the startup process after the startup script would now be waiting until ccmsetup was complete. The other thing is I assured the AD team that this script would take a few seconds and exit and not impact bootup.  It doesn't affect login as I can login while this is running with no problem.  This would have been a bigger problem with Windows 2000.  Anyway, I also tried using the method to create a scheduled task that starts 5 minutes after the script runs and so far that seems to be working.  This is a link to the blog where I found it. (thanks to Bill P. the person that posted it)

    http://smsimpossible.blogspot.com/2008/12/client-health-check-script-take-2.html

    The key changes to the script are to define some time variables and the run the AT command to schedule ccmsetup instead of running it directly.  Just need logic in case someone keeps rebooting before ccmsetup completes because the script will keep adding new AT jobs unnecessarily .  . .

    objCurTime = Time()
    objCurHour = Hour(objCurTime)
    objCurMin = Minute(objCurTime)+5
    objInstallTime = objCurHour & ":" & objCurMin
    .
    .
    .
    .
    smsinstall = "at " & objInstallTime & " \\" & Wscript.Arguments.Named("smsserver") & "\SMSClient\ccmsetup.exe" & InstallArgs
    WshShell.Run smsinstall,0,False

    Friday, April 30, 2010 10:29 AM
  • To follow up on some findings after further testing, JSC.19 was correct in that when ccmsetup is running as a service, it is ok to launch it with WshShell.Run smsinstall,0,TRUE.  Return is passed from ccmsetup back to the vbscript and it exits.  When running ccmsetup with command ine parameters it runs as a service by default.  However, I am running ccmsetup with no parameters so that it retrieves the parameters from Active Directory since we have published to AD.  I have found that when running ccmsetup without parameters, it does not run as a service.  Therefore, if I use the true option of wshell.run,the script will wait until ccmsetup completes.  I tested this in a login script on test machines and it resulted in long waits during login.  If logging in while the script was running we would see the "running startup scripts" dialogue for as long as it took for ccmsetup to complete!  Not sure why CCMSETUP does not run as a service when not using command line parameters.  It gets the command line parameters from the client push settings.  Thought about specifying /service option which should be default but you cannot include ccmsetup parameters in client push settings, only client.msi parameters.  So for me the fix for now is to kick off ccmsetup by spawning a scheduled task from the startup script.  See above.
    Friday, April 30, 2010 10:10 PM