Monthly Archives: October 2015

The Evolution of a Script or why I am constantly refactoring my code.

I have a confession to make, I hate reinventing the wheel when it comes to scripting. Most of the time, there are functioning examples of what I need to do readily available. All I need to do is just ask Bing or Google. Sometimes I piece together functionality from numerous scripts to make a new script that fills the need for the task at hand. This is the story of one such script.

Below you will find the gist of the Check-TSDependencies script in all its ugly glory.  As you can plainly see no though of reusability. Definitely not a tool script. If you stretch your imagination perhaps it could be called a controller script. But to be this was a get the job done; save MrBoDean some time; throw away script.

Well as I mentioned in a previous post  I have been working on improving the processes we use at work to manage SCCM and this ugly little script ended up filling a real need. SCCM has great reporting in the console, if you want to see the status of all distribution points for a single package or the status of all packages on a single distribution point. But trying to determine the status of 30-40 packages quickly does not happen very quickly.  That is until I started running this script.

Then the need for improvements came a long. “This is great for one distribution point but I keep needing to 2 or 3 or 10 …”; “This is great for troubleshooting after we have a issue, how can it be used proactively?”; “Displaying the status on the screen is ok but can you send a email of the status? Oh and I only want the email if there are failures.” and so on …

It quickly became apparent that this needed to evolve. No problem this script is so useful all it needs is parameters for prompts and hard coded packages and SCCM config. Maybe pretty it up and have it use some best practices. But when I take some time and really analyze the code that would not be very effective. The core functionality of the script is the wmi query and translating the results into easy to understand messages. The interactive prompts for the distribution point and the task sequence name are defiantly candidates for parameters. But the interactive portion would have to go or be placed in a controller script. But a little work with the SCCM comandlets and the PowerShell pipeline and the controller may not be needed.

The end result

Also available and


Lazy is as Lazy does

I was happily working away on a couple of scripts for Configuration Manager today, when a case of the monday’s hit. We are prepping to change a little over a 1000 distribution points rate limits. In testing the scripts to set the rate limit, a wmi query that returned some useful info so I tucked it away to come back and take a look at later. After getting the functional work done, I started working on documenting the state before and after the changes. That useful info earlier was the array that stores the rate limit. But in testing the documentation script, the value was null. So after comparing the console to the wmi results and a bit of head scratching, I broke down and started reading the documentation. Turns out that SCCM has lazy properties.

Some Configuration Manager object properties are relatively inefficient to retrieve. If these properties were retrieved for many instances in a class (as might be done in a query), the response would be considerably delayed. Such properties are considered lazy properties and are not usually retrieved during query operations. However, if these properties are retrieved during a query, they have null or zero values, which might not be the actual value of the property for every instance. Therefore, if you want to get the correct value for lazy properties, you must get each instance individually.

So powershell to the rescue. Run the Query for the bulk info

Then a foreach to drill in

Once we get to what we want a Get call will populate the Lazy Properties

see the script at

Get the source location for all packages in a SCCM Task Sequence

The past year or so I have been working on improving the processes we use at work to manage SCCM. One of the painful task we have is verifying that all of the package content used in a task sequence is being pulled from a source control deployment location. We average about 30 packages per OSD task sequences and after clicking on the properties of about the third package in the console, I had find a better way.

Now any time I have to do the validation
Get-TSPkgSource -PackageId "DEV005A4" -SiteCode "DEV" | out-gridview
Powershell does the heavy lifting and I can grab some coffee.