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
Additionally, if you want to target only desktops and exclude virtual computers the details can get tricky if you have a diverse environment.
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
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.
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!
The community has developed at least 5 solutions to this including