ccmsetup.exe: Trailing slash in “Source” parameter

Hello everyone!

Tonight, while I’m traveling in Houston, Texas, I wrestled with ccmsetup.exe for a little while. I was working on getting a ConfigMgr vNext client agent installed on a Windows 7 Ultimate virtual machine, and kept getting a message in my ccmsetup.log saying “Source <path> is inaccessible.


A little bit about %~dp0

Now, whenever I build installer packages for software, whether to run manually, or distribute through ConfigMgr, I generally wrap the commands inside a simple batch file, so I don’t have to constantly type out the entire command, or forget what a particular parameter should be set to.

Because I write lots of simple batch files, and use these packages from both UNC paths, as well as local installs, I use a nifty batch trick: %~dp0. Without going into too much detail, if you use %~dp0 in a batch file, it will reference the folder in which the batch file resides, including a trailing slash. For example, if you want to run a MSI package from a local or UNC path, you could write a dynamic batch file like so:

msiexec /i “%~dp0MyPackage.msi” /quiet

In the above command, the double quotes will take care of any spaces in the path, and the %~dp0 will reference the folder path in which the batch file itself resides. This command also assumes that a Windows Installer package called “MyPackage.msi” resides in the same folder alongside the batch file. Using %~dp0 is great, because no matter where I copy an entire package folder, I always know that I can execute a batch file, and it will use appropriate relative pathing to find the supporting files necessary to run the command.

Anyway, that’s enough history about %~dp0 and why I use it!


The Trailing Slash Issue

Installing the ConfigMgr client is generally quite simple: you can simply execute ccmsetup.exe by double-clicking it, or invoking it, with no parameters from a script. In this circumstance, however, I needed to specify the source folder for where to get the files, otherwise ccmsetup.exe was going to point to my ConfigMgr 2007 management point, rather than the ConfigMgr vNext management point that I wanted it to get the files from. Instead of using the /MP parameter, I elected to simply point ccmsetup.exe to the specific folder where the source files resided (on the ConfigMgr network share).

Naturally, since I was building my agent install batch file right inside the client folder on the site server (\vnext01sms_vnxclient), I simply used “%~dp0” to point ccmsetup.exe to its own folder (which was a UNC path). The command I placed into the batch file was the following:

“%~dp0ccmsetup.exe” /retry:1 /source:”%~dp0″ FSP=vnext01.ts.loc

Upon execution of this batch file, is when I experienced the “inaccessible source” error message in ccmsetup.log, as described in my opening paragraph. After encountering this issue, I experimented with a number of different permutations of the command line, none of which worked really. I finally realized that, as best I can tell, ccmsetup.exe appeared to be incorrectly parsing the value passed to the /source parameter. If you include a trailing slash on the <path> you pass to /source, then ccmsetup.exe will actually use the remainder of the command line as the <path>. This is very bad!

In short, if you want ccmsetup.exe to succeed at finding its source files, you must not include a trailing slash on the value you feed into the /source parameter!

The only scenario I have not yet tested, is passing a <path> to /source, that has a trailing slash, but does not have double-quotes around the path. I always recommend using double-quotes for any command-line value that may have spaces in it, so I would not really even consider this scenario, other than for the sake of testing.



Well, I hope this has given some of you some insight into a potential problem, and maybe even saves you a few gray hairs by finding this on Google, instead of stressing over what you are doing wrong. It appears to be a small software bug, and I’m somewhat surprised that no one else seems to have encountered it, but there’s a first time for everything, right?

If you have any feedback, or would like to ask a question, feel free to leave a comment on this article, or e-mail me directly at


Update: If you’d like to help out by recreating the issue, posting your comments, upvoting the bug report on Microsoft Connect, that would be fabulous! Make sure you log into Microsoft Connect, join the ConfigMgr vNext Beta Program, and then click the following link:

If you can reproduce the issue, make sure to click the “I can too” link on the above page.