My experience as a technology implementer and user: triumphs, discoveries, and expletives.


Configuration Manager Unleashed
Microsoft Most Valuable Professional
Follow Me on Twitter
web counter

Blog Roll

Persistent Posts

Presentation From Today

Here’s my presentation from today’s System Center Virtual User Group. 75%+ was actually a live demo of the new application distribution and management capabilities so these slides are just highlights and for your review – note that I ganked some content from Michael Niehaus’s presentation at Tech Australia 2011. The recording should be up tomorrow; I’ll post a link when I get it.

Another interesting presentation today was by Duane Bourgeois from Microsoft on the unified System Center 2012 installer. This has a lot of implications: both technical and logistical.


New Direction

Adaptiva HomeAfter four great years with Catapult Systems, I’ve decided to make a move away from consulting. Catapult was and is a great place to work and this move in no way reflects my displeasure with Catapult; Catapult is and will remain a top notch consulting organization ready to meet the needs of its customers. It took a special opportunity to pull me away: I was presented with an offer I could not refuse that in my opinion is in the best interests of my family and my career.

I will continue to contribute to the community, provide insight and advice, and be an all-around cheerleader for ConfigMgr; similarly this blog will continue to focus on ConfigMgr and related Microsoft technologies without being overtly “salesy” in nature – except this post of course Smile.

For those interested, my new employer is an ISV named Adaptiva that makes some awesome add-on products for ConfigMgr:

  • OneSite: Revolutionary ConfigMgr 2007 extension that enables you to manage a large distributed network as if it were a single local network. Simplify hierarchy, improve content distribution, simplify operations and save cost.
  • Client Health: Perform scheduled or instant health checks, on a PC or a collection. Maximize the success of your computer management services. Auto remediation available. Extended with custom workflows. Detailed reports and automatic health collections.
  • Green Planet: Power Management tightly integrated with ConfigMgr.

<SalesPitch>Adaptiva’s products are best of breed and blow the competition away in capabilities, features, and price. If you have or are implementing ConfigMgr or know someone who is or has, you/they should be looking at Adaptiva’s products. Please let me know if you want a demo for yourself or someone else.</SalesPitch>

Inside Central 8 - ConfigMgr has Pete on the run

Here’s a link to recent podcast I did on various topics including ConfigMgr 2012 (of course).

ConfigMgr Client Hotfix Versioning

imageTime to finally transfer my notes from two big yellow stickies to a blog post.

Basically, while trying to do a build & capture of Windows 7 SP1 recently, I was trying to apply every available (to my knowledge) client hotfix to the ConfigMgr agent. I was using Michael Murgolo’s hotfix script to automatically populate the PATCH property, but was running into all kinds of issues and so dug in to figure out what was going wrong. Note that the issues outlines below are not just present in task sequences but will also manifest if installing hotfixes in other ways also.

Problem #1

The first problem was that the script was relying on the default sort order of the Files property of the Folder object from the FileSystemObject automation object. This means that hotfixes with larger numbers but more digits would sort before hotfixes with smaller number but fewer digits because it was sorting them in normal alphabetic order instead of the desired numerical order; e.g., KB2516517 comes before KB982203 in a normal alpha sort even though 982203 is less than 251617. The presumption here is that hotfixes described in KB articles with larger numbers should always contain later code than those with smaller numbers (as we’ll see in a moment, this isn’t always true though).

To solve this issue, I modified Michael’s script to sort the KBs according to numerical order. Others have also run into this including Mattias Benninge who also modified the script and added a couple of useful features to boot; he posted his version earlier today.

Problem #2

As I stated above though, the sort order only addresses part of the problem. The other problem is the presumption I stated above which (as it turns out) does not hold true in all case because even after using my version of the script I was still getting errors.

Thus, I set forth to figure out what hotfixes install what components. The first place I started was the KB articles themselves which resulted in the following table of update files:



File Version


































Not a whole lot of help there except to confirm that some of the updates do replace the same file.

So, the next step was manually installing each hotfix with verbose logging enabled. In the verbose logs, the specific components and version numbers were listed which revealed a whole lot more as depicted in the following table:

















CCMFramework .2132




















There are so many things to draw from these two tables I’m not sure where to begin.

  1. Using the SMSClientVersion is in no way sufficient to judge whether a hotfix is installed. I know I haven’t even mentioned  this property before, but I have seen folks using this property to create queries to determine if a hotfix is installed on their clients or not. Based on the log files, SMSClientVersion is always set to the highest component version installed and thus is only indicative of a single hotfix being installed. Instead you should use the method I outlined previously with the values from the second table above. Even that method has potential problems though because of #3 below.
  2. 982203 does indeed appear to be superseded by 2516517 because they both replace the same file (lsinterface.dll) and increment the CCMFramework component version.
  3. Updating a components version number does not imply supersedance; e.g., 977176 and 2276865 both update the SMSTaskSequence component version but one updates smsswd.exe and the other updates tscore.dll. However, if you try to install 977176 after 2276865 on a client it will fail.
  4. 982203 updates CCMFramework to .2132 but 977384 updates CCMFramework to .2155 so you can’t install 982203 after 977384 however, 977384 doesn’t update lsinterface.dll so it doesn’t actually supersede 982203. (982203 is for NAP though so I don’t this is a very popular hotfix at all and there is a possible workaround to it by just unbinding IPv6 on the fix-up servers).

I’m sure there are other conclusions to draw, but those were the most obvious and relevant to me.

Another side issue I saw during my initial testing was that if I tried to install all of the hotfixes during a task sequence on a VM with 512MB (it might have even been 768, I don’t remember) of memory, the TS would die during the client installation. Once I bumped the RAM up to 1GB, everything went smoothly.


Don’t install every client hotfix just for fun.

Because the client gets reinstalled during deployment TSes anyway, the only hotfix really needed during a build and capture is 2509007 although I can see also putting 977384 in there because it is a bigger and more impactful hotfix.

Use Michael's script if you are only installing a couple of hotfixes during the TS and don’t see any conflicts based on the info above.

Use Matt’s script if you are installing more than a few hotfixes and will have a conflict (because of the sort order) based on the above info.

If you need 982203, you may have to hardcode the PATCH property to ensure the proper order or modify one of the two scripts to get the desired order. Alternatively, use 2516517 as it appears to supersede 982203.

One issue that I see with both scripts is that simply installing a hotfix on the site server, creating the hotfix package, and updating your client install package will immediately cause the hotfix to be part of any of your task sequences. This could be dangerous or bad for a variety of reasons. Be aware of this. The best work-around to this is to create a separate package that contains the hotfixes you want to deploy and the script. Both scripts look in certain sub-directories so make sure the package has the proper structure. Then, reference this package in the TS instead of the client install package.

Test, test, test.

Mobile Device Management in ConfigMgr 2012

Mobile Device Management is a very popular topic in enterprises as of late and so the question of what (exactly) ConfigMgr 2012 will be able to manage has been coming up a lot lately also.

(Note that this information is current to the best of my knowledge for beta 2 of ConfigMgr 2012 and presumably for RTM.)

Basically, there are two types of client management in ConfigMgr 2012: light and native (these aren’t official names just my characterizations).


Native client management means that a ConfigMgr agent exists for the platform and provides full and direct management of systems or devices running that platform. The supported Windows OSes are of course the best example of this type of management as are Windows Mobile 5, 6, 6.5 and a handful of other Windows CE based OSes like PocketPC 2003 (this does not include Windows Phone 7 which does not have a native client). This isn’t much different than ConfigMgr 2007. Actual management capabilities of each platform depend upon the specific platform; e.g., Widows Mobile 6.5 has a greater range of settings and tasks that can be managed than does PocketPC 2003.

It is also worth mentioning that the Mobile Device Manager product has been fully fully merged into ConfigMgr 2012 and no longer exists as a separate product.

Symbian (the now defunct Nokia mobile phone OS) is supposed to be supported as a native client. Because of the “death” of Symbian though, I have no idea if this is actually going to still be supported or not.

Finally, Unix and Linux native client support were formally announced at MMS 2011. This won’t be out of the box at RTM time (and is not in beta 2) but will be made available at a later date via a service pack or maybe R2. Not every feature will be be fully supported for these Unix and Linux clients, but the basics like inventory and software distribution will certainly be included.


This is a new type of client support for ConfigMgr 2012 and is provided using an Exchange connector. ConfigMgr directly leverages Exchange 2010’s (and Exchange 2010 only) capabilities via ActiveSync to manage any ActiveSync capable device. This means that whatever ActiveSync management capabilities that are implemented on the device are exposed to and manageable by ConfigMgr 2012. Exactly what these capabilities are is dependent on each device’s implementation of ActiveSync as the vendor of that device sees fit and is beyond the control of ConfigMgr or Microsoft. Basically, ActiveSync is a set of specifications a minimum of which must be implemented to allow the device to connect to Exchange. Not everything in the ActiveSync specification must be implemented and so not every possible management capability provided by ActiveSync is available on every phone. Thus, light client management in ConfigMgr is subject to both the capabilities (and limitations) of both the ActiveSync specification and each vendor’s implementation of ActiveSync on their device.

Currently, the following devices have ActiveSync support built into them: Windows Phone 7, Android, iOS. Microsoft does not maintain a comprehensive list of each device’s ActiveSync capabilities, but a good matrix is maintained on Wikipedia by the community: Comparison of Exchange ActiveSync Clients.


Who knows?? It’s clear that Microsoft wants to manage all enterprise worthy systems with ConfigMgr. Does this mean adding these other devices as native clients or another desktop OS? It’s all a closely guarded secret and anything I say or think on this is purely speculation.

Talk TechNet Replay

Here’s a link to the replay for my recent appearance on Talk TechNet:

We discussed a lot things including private clouds, System Center, Elmo, and of course Configuration Manager 2012.

Two OSD Application Install Issues

Here’s a quick synopsis of two issues I had at my recent customer installing some “packaged” applications during OSD.

The first was error code 0x80042000 from an InstallShield installation package. This is neither a standard Windows error code or a custom ConfigMgr error code. After some web searches, I stumbled on a blog post by fellow MVP and friend Kenny Buntinx. The symptoms lined up so we gave the solution a shot by adding the /f2 option to the command-line to create a log file. And amazingly, it worked. I have no real idea of why this works except that maybe the package fails if it can’t create the default log file which I think should be in the directory the setup.exe is run from and can’t so adding an alternate log path makes it work.

The second issue had to do with a different package for installing IBM Client Access. This was an ancient package created with an Altiris packaging tool. Unfortunately, this package checks to make sure the OS is Windows XP and only Windows XP. The customer did not know how to re-create the package so using it was the best option – minus the useless OS check of course. Based on a forum post from The App Compat Guy on how to set an exe to run in a compatibility mode without using the GUI, we created a quick script to copy the installer to C:\Windows\Temp, add a registry value as described in the forum post, and then execute the installer. The executable had to be copied to the local drive and executed from there because the application compatibility registry value required a fully qualified path and given we were running this from a DP, there was no guarantee the path was going to be the same every time. Worked like a charm.

Talk TechNet

TechNet Webcast: Talk TechNet with Keith Combs and Matt Hester - Episode 53: System Center Config Manager with Jason Sandys (Level 200)

My second appearance on Microsoft’s Talk TechNet is this Wednesday at 9AM Pacific time.

Sign up for Episode 53 and have some questions ready.

And in case Johan forgot from last time, I’m just shy of 2m tall, really about 198cm.

ConfigMgr Application Package Recipes – Adobe Reader X

So was Adobe sucking up to Apple when they decided to use the roman numeral for the version number?

Anyway, here’s another common package recipe that I see folks struggling with all the time.

<Annoyance>There is no such thing as Acrobat Reader. It has been called Adobe Reader for about 10 years now.</Annoyance>

Request Distribution Rights From Adobe

Yes, you must legally do this to distribute Adobe Reader in your enterprise/organization. It’s a simple form to fill out and you’ll get an e-mail back within a few minutes (in my experience at least) with further info:

Download the latest Adobe Reader

The best way to do this is to download this from Adobe’s FTP site: That link is to the latest US English version. Do not use the MSI that is directly downloadable: this MSI is a wrapper MSI for the actual Reader installation MSI. Download the EXE.

Note that Adobe has a well-defined version numbering scheme beyond the scope of this post that may use some confusion as to when Adobe releases different types of installers and the installers relationship to other updates; this and a lot of other good info is on Adobe’s Enterprise administration | Acrobat family of products page.

Download and install the Adobe Customization Tool

This tool lets you generate a custom transform for reader (and other Adobe products): You can install this pretty much anywhere although installing it on your site server may be frowned upon.

Extract the Reader MSI

From a command-prompt, execute the following to extract the needed files:

AdbeRdr1010_en_US.exe -nos_ne -nos_o"<DestinationPath>\<DestinationFolder>"

Adobe uses an application delivery packager from Nosso:

-nos_ne tells the package not to run the setup command; i.e., “no execute”.

-nos_o tells the package where to output the temporary files. Note that there is no space after nos_o and the path specified. Also, DestinationPath must already exist but DestinationFolder must not. It’s best to just extract it to your final location for the package source files.


Create the Transform

Do you need to create a transform? No, but it does allow you to turn off things like the first run display of the EULA and remove the shortcut from the desktop (has anyone ever launched Reader from a shortcut?).

Simply launch the customization tool open the MSI you extracted above, walk through the sections in the wizard, and save an MST in the same directory by choosing Generate Transform… under the Transform menu. Note that it does allow you to just save your changes to the original MSI, but this is very bad practice as you should never modify the vendor’s MSI. When you close the wizard, do not save your changes, they are already contained in the MST you generated.


If you are familiar with InstallShield or AdminStudio, the customization wizard will look familiar to you because the wizard is really just the transform wizard from InstallShield licensed and customized by Adobe.

Import the Package into ConfigMgr

In the ConfigMgr console, under Software Distribution –> Packages right-click and choose New –> Package From Definition.


Follow the wizard to import the MSI and have ConfigMgr create the package and programs for you:







Edit the Auto-Generated Programs to include the Transform

Simply add the following to any program command-line to use the transform:


This of course assumes that you put the MST in the same directory as the MSI and the files you extracted above. Note that relative paths are fine for MSTs and do not require full-paths. Thus, on my lab box, the full-command-line for the Per-system unattended program is

msiexec.exe /q ALLUSERS=2 /m MSINKHYV /i "AcroRead.msi" TRANSFORMS=ReaderCustom.mst

I also then use my MSICleanup script (documented in my ConfigMgr Program Scripts post) to cleanup the auto-generated programs.

Distribute and Advertise

The final steps should be pretty well-known Smile

OSD and RunOnce

I recently stumbled onto a somewhat major issue during OSD that is the result of a fundamental (bad) assumption made by many including Windows itself and Internet Explorer. That assumption is that at some point during the deployment of Windows (Windows 7 in this case), an Administrator will log on to the system. This may be during the actual deployment process or maybe right after it is done. Why is this assumption important? Because both Windows setup and Internet Explorer put items in the Windows RunOnce key (HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce) to be run the first time a user logs on. The things that Windows and IE setup put there require elevated permissions however.

Why is this assumption bad? Because the whole point of OSD in ConfigMgr is to be completely hands-off and that the first (and maybe only) user to ever log onto a system has no elevated permissions. Thus, things in RunOnce never run because task sequences in ConfigMgr run in the local SYSTEM context and never actually log into the system via the GINA.

I don’t know all the ramifications of this but it recently manifested itself at a client where we were adding IE 9 to a Windows 7 SP1 deployment. We used the IEAK to create an MSI and tested it manually with the desired results. The problem came in when we tried to add that MSI to either a Build and Capture Task Sequence or a Deployment Task Sequence. The install finished fine, but neither the Start Menu nor Taskbar icon for IE existed anymore. We could manually browse to iexplore.exe and launch it that way proving that the install was fine and of course it was listed in the Updates list under Programs and Features.

After some investigation and a TechNet forum thread pointing the way, I realized what was going on. As Michael Niehaus accurately pointed out also, this isn’t really a new issue but I’ve never seen a negative impact like this one before either. Upon examining the RunOnce key, both before and after IE 9 installation but before a reboot, I discovered no less than six other items listed that were from the base Windows 7 image we had recaptured using a Build and Capture Task Sequence. So, the conclusion is that this is not just an IE problem and it’s not just a Build and Capture issue. So even if you aren’t adding IE and even if you are using LiteTouch to create your image, it’s still possible for things to end up in the RunOnce key that never get executed.

So what’s the solution? In limited testing, the following VBScript seems to do the trick:

Const HKLM = &H80000002

Const REG_SZ = 1
Const REG_BINARY = 3
Const REG_DWORD = 4
Const REG_MULTI_SZ = 7
computer = "."

Set shell = CreateObject("WScript.Shell")
Set registry = GetObject("winmgmts:\\" & computer & "\root\default:StdRegProv")
keyPath = "SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce"
registry.EnumValues HKLM, keyPath, valueNames, valueTypes

If Not IsNull(valueNames) Then

    For i = 0 To UBound(valueNames)
        text = valueNames(i)  
        valueName = valueNames(i)
        Select Case valueTypes(i)
            Case REG_SZ
                registry.GetStringValue HKLM, keyPath, valueName, value
                WScript.Echo text & ": "  & value
                returnCode = shell.Run(value, 1, True)
                If returnCode = 0 Then
                    registry.DeleteValue HKLM, keyPath, valueName
                End If
            End Select
End If

What does it do? It simply enumerates each value under the RunOnce key, executes the command-line, and if a success code of 0 is returned from executing the command-line it deletes the value from RunOnce.

Based upon my findings, you should run this is all ConfigMgr OSD task sequences somewhere after the Setup Windows and ConfigMgr task preferably also after any included application installs and after a reboot. If there’s nothing in RunOnce, it’s a no-op.

Installing Fonts During OSD

Font_Book_IconHere’s a simple little script to install fonts during OSD. Note that this is an example of not doing any manual work during OSD: manual work is un-IT. A quick web search, using Bing of course (Hey, Scripting Guy! How Can I Install Fonts Using a Script- - Hey), and a little scripting knowledge resulted in this VBScript.

Const FONTS = &H14&

Set shell = CreateObject("Shell.Application")
Set fso = CreateObject("Scripting.FileSystemObject")
Set fontsFolder = shell.Namespace(FONTS)

scriptFullName = WScript.ScriptFullName

Set currentFolder = fso.GetFolder (fso.GetParentFolderName(scriptFullName) & "\Fonts")
For Each file In currentFolder.Files
    If fso.GetExtensionName(file.Name) = "ttf" Then
        WScript.Echo "Installing font: " & file.Path
        fontsFolder.CopyHere file.Path
    End If

Dump this is a .vbs file in a ConfigMgr package with a Fonts subfolder containing any fonts that you want to import then simply use a command-line task to call the VBScript; e.g., cscript InstallFonts.vbs.

One possible improvement for this script is to check for the existence of the Font before trying to import it because if it is already imported, a message box will be displayed with an error message which is obviously not a good thing during OSD (note that the message box is actually visible and clickable though so it’s not a show stopper).

TechEd Sessions on Channel 9

All (or at least most) of the TechEd North America 2011 sessions are online at Channel 9:

A quick filter gives you all the Identity and Management sessions:

My session is listed in there also:

Boot Image Backgrounds From TechEd

For those interested, curious, or mischievous, here are the three boot image backgrounds I used during our (Johan’s and my) pre-conference session yesterday.

What’s in a Heartbeat

Questions often come on the forums about Heartbeat Discovery including how often should they be configured to run or indirectly, what updates certain resource information in ConfigMgr like the IP Address.

The answer to the first question depends on what you are going to use the data for that is contained in a Heartbeat Discovery? But if you don’t know what’s in a Heartbeat Discovery message, it’s very difficult to answer that question. So, here’s exactly what gets included in the Data Discovery Record (DDR) generated by the client and sent to the server during a Heartbeat Discovery:

  • Is the client installed?
  • Client type (Legacy, Advanced, or Device)
  • Client version
  • NetBIOS Name
  • Character encoding used by the client
  • Default system locale identifier (typically representative of the client’s language)
  • Date and time of the DDR
  • Date and time of last DDR
  • Short name of system
  • Currently logged in (interactive) user
  • FQDN of system
  • IP Network ID
  • Platform ID (this is an encoding of the OS version)
  • AD Site Name
  • IP Address(es)
  • MAC Address(es)
  • Domain name
  • Assigned (Primary) Site
  • Hardware ID
  • Identifying number (of the computer system)
  • Product name (of the computer system)
  • UUID (of the computer system)
  • Version (of the computer system)

The above list also addresses the second question --  at least as far as Heartbeat Discovery is concerned.

So the question for how often to run the Heartbeat Discovery is really how often do you need the above information updated?

Heartbeat Discovery messages are quite small and have negligible overhead on the client. Cumulatively, a large number could impact an under-powered management point, however, so setting them too frequently is not advisable. Out of the box, the default is 7 days. I typically set this down to every 1 day and know others do it even more often. I would never recommend setting this to less than 1 or 2 hours except in very small environments – there isn’t really any value in doing so anyway as nothing in the above list normally changes that frequently.

The Heartbeat Discovery also serves as a “keep alive” or “yes I am alive” message from the client to the site server. Based on this, the Clear Install Flag and Delete Aged Discovery Data maintenance tasks perform their jobs. Note that the Delete Inactive Client Discovery Data  does not directly use the heartbeat time. Instead, Client Status Reporting (available in R2 and R3), uses the last heartbeat time along with last hardware inventory, last software inventory, and last policy polling time to determine if a client is inactive. Once a client is marked inactive by Client Status Reporting, it is then subject to the Delete Inactive Client Discovery Data task.

This “keep alive” purpose of the heartbeat discovery should also influence your choice of how often to set the interval; i.e., you shouldn’t set so infrequently that it might get accidentally marked inactive or not installed by one of the above mentioned maintenance tasks.

Note that you can manually initiate a Heartbeat Discovery anytime on a client from the Configuration Manager Control Panel applet by navigating to the actions tab, selecting Discovery Data Collection Cycle, and then pushing the Initiate Action button. Alternatively you can use Roger Zander’s Client Center, the right-click tools, or use the SDK to initiate this action remotely.

There are two additional important points to be made about Heartbeat Discovery (these are copied straight from

Heartbeat Discovery forces the rediscovery of active clients that have been deleted from the Configuration Manager database by the administrator, or by a database maintenance task.

  • If you accidentally delete a computer from the Configuration Manager console, it will automatically "come back" if it is still active on the network. You can either wait for the next Heartbeat Discovery cycle to run, or you can hurry things along by selecting the Discovery Data Collection Cycle on the client Configuration Manager Properties: Actions tab, and click OK.

Heartbeat Discovery is the discovery process that submits a client's installation status to its assigned site.

  • The client might be installed but the client state in the Configuration Manager console continues to display No for its Client state if the site hasn't received the client's discovery data record (DDR) from Heartbeat Discovery. This will be the case if the client cannot communicate with its management point.
Accessing OSD Troubleshooting Tools

imageAbout the only method for troubleshooting issues in OSD is to drop to a command-prompt (by pressing F8) and then running whatever tool you need; e.g., Trace32. The only real problem with this method is making whatever tools you need available to you. This is typically done by adding the tools directly to the boot image. MDT makes this much easier for you in the MDT Boot Image creation wizard (shown at the right) and the method outlined Michael Petersen makes this easier for standard boot images. However, once the boot image is created, there is no good way besides manually mounting the WIM and modifying it or of course recreating the boot image. Both of which, while not huge challenges or time wasters, are just annoying. Also, putting these tools in the boot image does not make them available after the Setup Windows and ConfigMgr task; i.e., when the TS is actually running in the deployed OS. And what happens if you are using boot media: then the fun really begins.

There is a simple solution to this though. Put any tools you want available in a folder accessible via a UNC and add one (or multiple) Connect to Network Folder tasks in the task sequence to connect to this UNC – the mappings do not survive a reboot so you’ll probably need at least two: one for the PE portion of the TS and one for the OS portion. Now, whenever you need the tools, simply drop to a command-prompt and change drives to whatever drive letter you chose. You can add tools on the fly and even copy log files back up to the folder if you’ve set the permissions correctly. If you don’t trust the folks troubleshooting the TS from monkeying with the tools in the first folder you can create a second folder for copying logs and a second set of Connect to Network Folder tasks to connect to the logs folder.

The Connect to Network Folder task has no impact on the running TS or the resulting OS deployment so there is no harm in adding these in. They offer a fast and flexible way to get to your troubleshooting tools without having to modify your boot images.



More Posts Next page »