Troubleshooting Client Deployment Issues – Running Ccmsetup as a Service

Troubleshooting Client Deployment Issues – Running Ccmsetup as a Service

  • Comments 5
  • Likes

[Today’s post is provided by Ben Yim]

A common client deployment issue that I’ve seen over the years involves running ccmsetup as a service.  In most cases running ccmsetup as a service should be fine.  However, there are scenarios where doing so will have some unintended consequences, which will in turn cause client deployment failures.  This post will go over some of the consequences of running ccmsetup as a service and how this can cause client deployment failures.

When ccmsetup launches, it can run under one of two modes - it can either run as a service or as a standalone executable.  In many cases, such as client push installations, ccmsetup runs as a service by default.  When ccmsetup runs as a service, installation occurs over a couple of different phases.  In the first phase, ccmsetup copies itself to %windir%\ccmsetup for 64-bit computers or %windir%\system32\ccmsetup for 32-bit computers and it registers itself as a Windows service.   It does this so that there is a built in retry mechanism during the client deployment process.  Should the client installation fail because the client computer is restarted during the deployment process, ccmsetup will retry the client installation after the reboot is completed.  In ccmsetup.log, this phase will look something like this:

==========[ ccmsetup started in process 2348 ]==========                       ccmsetup  3/4/2009 11:16:10 AM
Version: 4.0.6221.1000                 ccmsetup  3/4/2009 11:16:10 AM

Downloading c:\myinstalldir\ccmsetup.exe to C:\Windows\ccmsetup\ccmsetup.exe
File download 43% complete (262144 of 602112 bytes).            ccmsetup  3/4/2009 11:16:11 AM
File download 87% complete (524288 of 602112 bytes).            ccmsetup  3/4/2009 11:16:11 AM
File download 100% complete (602112 of 602112 bytes).         ccmsetup  3/4/2009 11:16:11 AM
Download complete.                       ccmsetup  3/4/2009 11:16:11 AM
Successfully created the ccmsetup service                      ccmsetup  3/4/2009 11:16:11 AM

 

From the log file you can see that ccmsetup copies itself to the Windows directory and creates a Windows service.  It then exits the initial ccmsetup process and relaunches as a Windows service.  You can see evidence of this because ccmsetup.log shows that the process restarted.  For example, the next line in ccmsetup.log should look something like this:

Download complete.                       ccmsetup  3/4/2009 11:16:11
Successfully created the ccmsetup service                      ccmsetup  3/4/2009 11:16:11 AM
==========[ ccmsetup started in process 2608 ]==========                       ccmsetup  3/4/2009 11:16:11 AM

Version: 4.0.6221.1000                 ccmsetup  3/4/2009 11:16:11 AM

 

The key thing during this transition is that when ccmsetup relaunches as a service, it will run under the Local System context of the client computer rather than the context that ccmsetup was originally launched under.  Again, this information can be found in ccmsetup.log and would look something like this:

Running as user "SYSTEM"             ccmsetup  3/4/2009 11:16:32 AM

 

This transition can become an issue during client deployment if the Local System account on the client computer does not have access to client installation binaries.  For example, let’s say that you run ccmsetup from a network share that contains all of the client binaries.  Your user account may have access to that network share while the Local System account of the client computer does not.  When you launch ccmsetup, phase 1 will complete and ccmsetup will be able to copy itself from the network share to the Windows directory because it will be running under your user account.  However, when ccmsetup relaunches to download other client binaries, the Local System account may not have access to that network share, preventing ccmsetup from downloading the files that it needs.  When this is an issue, you’ll typically see a message that looks something like this:

Failed to access source file (…). Waiting for retry...

 

There are several ways to work around this, but one of the simplest ways to do so would be to run ccmsetup as a standalone process rather than as a service.  When ccmsetup runs as a standalone process, the entire client deployment process runs under one account.  Thus, if your user account has access to that network share, ccmsetup will have access to that network share for the duration of the client install.

You can explicitly set how ccmsetup runs using a couple of different switches.  If you pass a /service switch to ccmsetup, ccmsetup will always run as a service.  Conversely, if you pass the /noservice switch to ccmsetup, ccmsetup will always run as a standalone process.  For those of you familiar with SMS 2003, the /noservice switch effectively does the same thing as the /useronly switch in SMS 2003.  The /useronly switch was explicitly renamed to /noservice for Configuration Manager because people kept getting the impression that /useronly meant that the client installation would happen under low rights, which was never actually the case.

--Ben Yim

This posting is provided "AS IS" with no warranties, and confers no rights.

 

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • I generally just grant 'domain computers' access to the share where client install files are shared so local system can get access.

  • In case you missed them, the following posts were published on the System Center Configuration Manager

  • 我在过去一些年中常见的一个客户端部署的问题是将 ccmsetup 程序用作一个系统服务。绝大多数情况下,我们可以将 ccmsetup 程序作为系统服务正常使用。然而,也有一些情况中这么做会带来预料不到的结果,随后导致客户端部署的失败。这篇文章介绍了一些这样做带来的后果,同时介绍了这么做如何导致了客户端部署失败。

  • This was extremely helpful and resolved my problem. Thanks!

  • It did not solve my issue.Any other suggestion.?