Jason Sandys Archive

Content Distribution Magic

This post is inspired by a question submitted on my previous post: Content Distribution: The Myth. The question was about how ConfigMgr determines if files are different when deciding whether or not to replicate them to distribution points. Specifically, the requestor wanted to know whether a simple name change to a file would cause ConfigMgr to see the file as a new file. Read the rest of the post at http://blog.configmgrftw.com/content-distribution-magic/.

Content Distribution: The Myth

A quick post to dispel a common ConfigMgr myth about content distribution. The functionality in question is what happens when you change the source location of a package (or any content since they’re all technically packages on the back-end)? I’ve seen it stated multiple times by multiple folks that ConfigMgr will re-copy all of the files within that source location to your DP(s). This simply isn’t so (and never was even in ConfigMgr 2007). When you change the source location, ConfigMgr does indeed kick-off a DP update for that package incrementing its version in the process. But just like all

Notes on The Software Update Scan Cycle

Most of the below information is cobbled together from a couple of TechNet pages, a blog post or two, presentations I’ve seen over the years, conversations I’ve had with others, forum posts and experience — there’s just no one definitive source with a product as big as ConfigMgr that also relies on another full product in this case. And of course, there are always gaps (and sometimes errors) in the actual public documentation. Read the rest of the post at http://blog.configmgrftw.com/notes-software-update-scan-cycle/.

WMI Manipulations and Manifestations

As a follow-on to my System Center Universe 2014 session, I thought I’d put together the various ways to create WMI “objects” so that ConfigMgr can later pick them up using Hardware Inventory. The below examples do not include any error checking and simply contain the core code snippets needed to perform the actions; variations are also possible, these are simply one way to do get the job done. The following example snippets are provided: Read the rest of the post at http://blog.configmgrftw.com/?p=747.

Endpoint Protection Policy Naming Bug

A quick one from the forums: basically, don’t use special characters in your Endpoint Protection policy names. There is (apparently) a confirmed bug when doing so. I’d say this is generally a good practice for the naming of any and all objects in ConfigMgr (and other products) – stick to the normal alphabet  (although using a dash or underscore is useful and should typically be alright) – as I heavily doubt test cases explicitly ever account for anything other than the normal alpha characters. For reference: Failed to trigger EP Installer to install.- R2 client.

ConfigMgr OS Upgrades

Up until now, upgrading the operating system (in-place) of a Configuration Manager site server or site system was strictly unsupported – that doesn’t of course mean it didn’t work, just that Microsoft never planned or designed for it and ultimately never tested it so all results and consequences of doing so were yours (and yours alone) to own and fix. Well, thanks to someone in the product group, this has changed. The documentation team recently published an update (not sure when – could have actually been there a while and I just didn’t know about it) that Nicolai Henriksen and

The WUA Dilemma in ConfigMgr

I’ve blogged about the *unfun* of the Windows Update Agent (WUA) before, answered many forums posts on the subject, and presented information on it at multiple venues including MMS and IT/Dev Connections. Until recently, I didn’t have a good solution though. The simple diagram in this post sums up the dilemma. Basically, the WUA is meant to be an autonomous component that does things like install Windows updates, detect pending reboots, and nag the end-user about the first two things. None of these are these are desirable in an enterprise environment though where ConfigMgr exists and should instead be controlling


There’s always a lot of confusion on exactly how to use CCMSETUP and the various switches and properties for it even though it’s fully documented on TechNet. The first thing to note about CCMSETUP is that it is used for all client agent installation activity (except client agent installation from WSUS). Yes, even client push uses CCMSETUP. Basically, client push simply delivers CCMSETUP to target systems and starts it. What that ultimately means is that no matter how you install the client, it’s always the same process so there is no technical difference between any of the methods (except using