ConfigMgr Chassis Type Global Condition / Requirement

wp-read-more-redirectwp-read-more-redirectNo Gravatar

Working with a customer recently we wanted to deploy a ConfigMgr Application to all all laptops in the organization without creating a new collection of just laptops.  Using the ChassisTypes  property of the Win32_SystemEnclosure  WMI namespace is a great way to do this; however, it can get a bit complicated, especially when there is non-normalized data in the inventory.  An example would be a wrongly coded ChassisType .

Additionally, if you want to target only desktops and exclude virtual computers the details can get tricky if you have a diverse environment.

continue reading on

February 16, 2018

Posted In: ConfigMgr

ConfigMgr Package/Program… will retry later

wp-read-more-redirectwp-read-more-redirectNo Gravatar

Jason Sandy’s has a great blog explaining ConfigMgr Package/Program retry behavior including the Retry return/exit/error codes and how often the retry occurs.  One bit of info missing from the blog that I couldn’t find anywhere else (documentation, forums, blogs, etc.) was how long or how many retry attempts will occur before ConfigMgr gives up.

The answer is… 1008 times!  This equates to every 10 minutes for an entire week; however, if the computer is restarted, turned off, goes to sleep, etc. the duration will be extended.

To verify this I created a Package/Program that simply exits with an error code in the FailureRetry list.  Something like


continue reading on

February 1, 2018

Posted In: ConfigMgr, ConfigMgr 2007

Tags: ,

ConfigMgr and SQL – NTFS allocation unit size

No Gravatar

It’s been many years since I read that SQL databases should use an NTFS volume formatted with at 64KB file allocation unit size (block size). So long that I didn’t remember why or if it is still considered best/good practice. It appears that it is according to Microsoft and the foremost authority on SQL with ConfigMgr.

keep reading at

December 23, 2016

Posted In: ConfigMgr, Scripting, T-SQL

ConfigMgr Content Source Path migration

No Gravatar

Several ConfigMgr scenarios require that the content Source Path be changed.  This typically includes migrating to a new ConfigMgr environment (2007 to 2012, 2012 to Current Branch, etc.), and simply moving the source content to a new location such as a DFS Share or low-speed NAS device.

Updating the Source Path can be done manually via the ConfigMgr console.  For Packages, Software Update Deployment Packages, Drivers, Driver Packages, Operating System Images, Operating System Upgrade Packages, Boot Images, and Virtual Hard Disks, just add the Pkg Source Path or Package Source Path column to the console view to review the paths, then edit the object’s Source Folder in the Data Source tab.

However, for Applications, you’ll have to step through each Deployment Type on each Application, view the properties and modify the Content Location in the Content tab.

This is all painfully slow if you have more then a handful to deal with.  So, automate it!

image image

The community has developed at least 5 solutions to this including

CoreTech and Nickalaj have the slickest solutions.  Sometimes a GUI gives the visual feedback you need to be confident in the final outcome.

158_1 image

Either of these two tools should effectively handle the changes.  As a bonus, both will actually copy the content files from the old to the new path.  Awesome!

Happy migrating!

September 28, 2016

Posted In: ConfigMgr, Scripting