I run across a lot of questions in the forums and from customers about why their batch files are failing when run using a ConfigMgr program. There is an easy answer to this (usually): the command shell, which executes batch files, cannot change its current directory to a UNC path. Although that’s a straight forward statement, I thought I’d create some demo programs to show the ramifications of this in action and to compare against an executable and a VBScript.

For each type, there are two possibilities, running from the DP – which is when a UNC is used – or running from the cache which is typically referred to as a download and execute. The choice between these two possibilities is set on the advertisement and not the program.

exe

For the exe, I wrote a small application that called the Win32 APIs GetCurrentUser and GetCurrentDirectory.

Run from DP

Run from Cache

VBScript

For the VBScript, I used the UserName and UserDomain of the WScript.Network object and the CurrentDirectory property of the WScript.Shell object.

Set WshNetwork = WScript.CreateObject("WScript.Network")
Set WshShell = WScript.CreateObject("WScript.Shell")

info = WshNetwork.UserDomain & "\" & WshNetwork.UserName & vbCrLf & WshShell.CurrentDirectory

WScript.Echo info

Run from DP

Run from Cache

batch

For the batch file, I output to a local file the USERNAME and USERDOMAIN environment variables as well as the “cd” command which if used by itself echoes the current directory.

echo %USERDOMAIN% > "c:\context.txt"
echo %USERNAME% >> "c:\context.txt"
cd >> "c:\context.txt"

As you can see below, the current directory for the batch file when run from the DP is C:\Windows. Thus, if your batch file tries to call anything from the package using a relative path, it will fail.

Note that is XP/2003, the USERNAME and USERDOMAIN environment variables are blank for the SYSTEM account, thus the first two lines of the just say “ECHO is on.”

Run from DP

Run from Cache

batch2

This batch file calls the exe using the %~dp0 batch parameter: http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/percent.mspx?mfr=true. This parameter returns the directory that the batch file was run from (including a trailing backslash).

%~dp0context.exe

The use of this parameter is pretty well documented within SMS\ConfigMgr circles – although it is not specific to SMS/ConfigMgr in any way – it is one possible solution to the batch file problem. Another is to set the program to use a drive letter instead of a UNC in the ConfigMgr program properties. This works; however, if you try to use a download and execute advertisement for the program, you will get an error because these two settings – run with drive letter and download and execute – are not compatible. %~dp0 works either way though, so is usually the best solution.

Another thing to point out is that the child process inherits the current directory from the parent process, in this case, the child is the exe and the parent is the command shell. This isn’t a big deal in the run from cache scenario, but note the current directory in the run from DP scenario for the exe.

Also notice the warning at the top of the command prompt in the Run from DP scenario. It more or less sums up what I said in the opening paragraph of this post.

Run from DP

Run from Cache

The main thing to keep in mind when using ConfigMgr programs, is that ConfigMgr is not doing anything “magic”. It is simply running the command-line you tell it to run. Things don’t work the way you think they should sometimes because you’ve made some false assumptions, not because ConfigMgr is broken.

My inaugural blogcast on Operating System Deployment (OSD) in Configuration Manager (ConfigMgr) is now available: http://myitforum.com/cs2/blogs/jsandys/pages/osd-blogcast-series.aspx. More to follow soon.

I visit a lot of clients and work work with a lot of different admins and one the recurring themes for many of these admins is having multiple – three plus usually – RDP sessions open at one time. There’s nothing wrong with this in and of itself, the problem comes when trying to find the correct window on the task bar. I often sit back patiently waiting for the person to click through all of their open sessions until they find the right one – OK, I’m not always that patient :-) More time usually gets wasted cycling through all of the open sessions than actually working in them.

Another issue that working with multiple RDP sessions brings up is screen real-estate. If you maximize the RDP session to get the biggest session to work on, you lose access to the start menu and task bar. Now if you need to switch to Outlook or IE or launch another app then you have to resize the full-screen RDP session. Also, it’s easy to forget that you’re in an RDP session and accidentally shutdown or restart the production server that you’re working on – admit it, we’ve all done it at least once.

The answer to the above is to get a second monitor (which doesn’t address the first problem above) or to not maximize your RDP sessions. The problem with not maximizing your RDP sessions is that the special key combos – like Windows+E – which I use constantly, are not passed on to the remote system.

There are other issues too, but I’ll cut the discussion short on those because you should be on board with me by now :-)

Enter a handful of multi-session RDP clients. Microsoft included an MMC based one in Windows 2000, but it was less than elegant and really didn’t improve on much. The third-party batch include an open-source one, Terminals, which works pretty well. It has it’s annoyances but does address all of the above problems (and more). It is tabbed based, stores credentials securely, organizes and tags connection settings, and is free.

My current choice however is VisionApp Remote Desktop 2009 or vRD for short. vRD is a commercial app but a free version is available – the only significant limitation is the ability to only open three remote sessions at a time. vRD does everything Terminals does but is cleaner and just seems to work better. It has a few “upscale” features also like storing credentials (securely of course) separate from the connections so that they can be shared and the navigation pane collapses when you start a new session among other things. A new version is on the horizon also.

There are at least one or two others is the game also, although the ones that I know are not free in any way – one used to be but has been converted to a shareware package.

As an enabler for any admin, using either Terminals or (stepping up to) vRD is a great move that I encourage everyone to take advantage of.

What’s the difference? Why two types? When should I use each?

These are frequent queries I get from customers and are also often echoed in the forums.

OS Install Packages are packages built using the actual source files from the OS media. For Windows XP/2003, this includes all of the individual files (in a compressed form) installed to a system during setup and the actual setup program. For Vista/7/2008, this includes an install.wim file that contains a generic “image” of the OS and the setup files used to deploy and configure this “image”. Note that WIM files are essentially just compressed archive files using the Microsoft CAB format; they contain the files that make up the OS and thus the Vista/7/2008 setup mainly just un-compresses the WIM onto the destination hard drive.

OS Images are WIM files without any other associated setup files. These are captured from a reference system that has been generalized using sysprep. The reference system is one where the OS has already been installed and possibly configured with software, updates, tweaks, and other configurations. This is all captured into the WIM file which can then be deployed to other systems making the two systems identical (minus any hardware difference of course).

Both of the above are stored in ConfigMgr packages. Package is a very ambiguous term though. For ConfigMgr, a package is a collection of source files contained in a specified folder and its subfolders; a package has no inherent functionality. Thus an “OS Install Package” has lots of files and an “OS Image” package has just one, a WIM.

OS Install Packages are used to deploy an OS from scratch using the OS setup program. In XP/2003 this means going through the “Blue Screen” setup. In Vista/7/2008 it means going through the PE based install.

OS Images are used to deploy a pre-configured OS built on a reference system (including any updates, software, tweaks, etc.). The advantage of using an OS Image is speed and the fact that it ensures that each system deployed is identical in configuration. Installing the OS and updates takes a long time typically as do some software packages. Capturing these in a single compressed file, like a WIM, eliminates the need to actually install any of these. An old Unix saying is that everything is a file. For Windows, not everything is represented as a file (as in Unix), but Windows is merely a collection of files – even the registry is just a set of files. Thus, deploying an OS contained in a WIM simply means extracting all of the files that the WIM contains onto the target system: full setup not needed.

OS Install Packages are directly used by Build & Capture Task Sequences to automatically create an image of a reference system captured in a WIM file. It is possible to use an OS Install Package to deploy systems; however, this is not commonly done -- the trade-off is time as discussed above.

OS Images are used by Deployment Task Sequences to deploy an OS to target systems.

A common follow-on question is why not use the install.wim from the Vista/7/2008 media directly without creating a reference image first? The answer is because its not recommended: the install.wim for these OSes was built using the D drive as the OS root drive. The setup program goes through great pains to fix this after the install.wim is deployed. If you simply import the install.wim and use it in a deployment task sequence, you will have undefined results.

Thus, you should always build a WIM from reference system no matter what OS you are deploying. The preferred method is to use a build and capture task sequence, but manually building and capturing a reference system is “acceptable” although highly discouraged in my opinion.

A practice previously used by many when updating their images is to deploy an existing image, make changes, and then recapture the image. This is generally considered bad form for many reasons, but was technically acceptable. This is no longer the case in Vista/7/2008. A single installation of Windows is only allowed to be syspreped three times with these newer versions of Windows because of activation: http://support.microsoft.com/kb/929828. The best practice is always to create your images from a cleanly installed reference system; this is exactly what a Build & Capture Task Sequence does for you.

I often make use of what I call “Roll-up Collections” in ConfigMgr. These are parent collections that contain sub-collections that specialize the intended membership of the parent collection. An example parent collection might be Texas with sub-collections for San Antonio, Austin, Dallas, Houston, Corpus Christi, etc. The parent collection’s membership, Texas in this case, is determined by the membership of the sub-collections; i.e., everything in the sub-collections should also be in the parent collection.

This is different than a trickle down collection where each sub-collection is limited to the membership of its parent collection and uses a query to “filter” the membership of that parent collection. The end result is similar however.

So when would you use a roll-up collection: typically if you populate the sub-collections using direct membership rules or there are more than a few sub-collections where combining the rules for use in the parent collection is non-trivial.

The following query, when added as a Query Rule to the parent collection, will accomplish the feat of a roll-up collection (where XYZ00123 is the Collection ID of the parent collection):

I was at a customer this week doing a one-day, whirlwind tour of Operating System Deployment (OSD) in ConfigMgr. They were specifically interested in server deployment so we set up a build and capture task sequence for Server 2003 SP2. Everything went well until the Prepare OS task which runs sysprep. It just wouldn’t finish; the scrollbars moved forward, then back, then forward, etc. I left at the end of the day and it was still running after 90 minutes. I couldn’t find any references on the web for a sysprep hang though.

It turns out that when I created the sysprep package, I removed the documentation files (The two chms, one doc, and readme.txt) – at least thats what I though I did. Repopulating the sysprep files with the entire contents of the deploy.cab file and re-running the B&C TS worked like a charm. Really weird.

Incidentally, did you know that each version and service pack level of Windows has its own specific version of sysprep? Vista/7 and 2008/R2 make this easier because they include sysprep as part of their base install; however, slipstreaming a service pack into either XP or Server 2003 does not update the deploy.cab and thus sysprep does not get updated.

You can download the deploy.cab for each version and service pack level from Microsoft by using your favorite decision engine and searching for “Windows XP SPx Deployment Tools” or “Windows Server 2003 SPx Deployment Tools”. An odd thing about the Server 2003 SP2 deployment tools download is that it is distributed as a patch and not a self-extracting executable. The easy way to get to the deploy.cab is to run the patch with the /extract switch which will prompt you for a location where it will dump the files from which you can pluck the deploy.cab file.

Hmmm. I received the following feedback anonymously about OSDAppChooser:

I just wanted to drop in a few suggestions for future enhancements to the OSD AppChooser in case you ever get the chance to tweak it. It'd be nice if there was some way to adjust the size of the application window. Also, it'd be nice if the line of text that reads "Please Choose an Application Set" could contain a lot more characters. And maybe if you could make the Help icon live and we could have a separate file that we could customize for support issues (for the not-so-bright techs). And lastly, is there any way to have it display for X minutes, and if there is no interaction, to close and continue on? For those times when techs start an install and then walk off, forgetting to wait around to select the desired applications. Just some suggestions!

First, I’d like to say I welcome feedback and am happy to add features to OSDAppChooser. I just wish this person would have given me a way to respond to directly to them so that I can either point out things they may not know or figure out exactly what they want.

Anyway, if that anonymous person is out there and reading this, here’s my response, please follow up with me so I can modify OSDAppChooser appropriately.

Feedback: It'd be nice if there was some way to adjust the size of the application window.

Response: The window is fully resizable; just grab a corner and drag.

Feedback: Also, it'd be nice if the line of text that reads "Please Choose an Application Set" could contain a lot more characters.

Response: Valid, but there’s only so much real estate to work with. Would a tool tip work better?

Feedback: And maybe if you could make the Help icon live and we could have a separate file that we could customize for support issues

Response: Would a tooltip here also help? Maybe combine the last two items into a single tooltip?

Feedback: is there any way to have it display for X minutes

Response: I initially planned for this (and actually included it in version 1 which was based on AutoIT), but determined it was redundant because if you are using a run command line task in a task sequence, it already has the ability to set a time limit.

I have a couple of other small ideas for improving OSDAppChooser and will hopefully release a new rev soon. If anyone has anything else they’d like to see, please let me know.