First published on CLOUDBLOGS on Mar 13, 2009
[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%system32ccmsetup 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:myinstalldirccmsetup.exe to C:Windowsccmsetupccmsetup.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.
