How to: Set Sending Priority of All ConfigMgr Driver Packages with PowerShell

Here’s a quick answer to a post yesterday on myITForum’s ConfigMgr/SMS Email list.

#replace MySiteServer with central site server name,
#and LAB with site code
get-wmiobject sms_driverpackage -namespace root\sms\site_LAB -computer MySiteServer -filter "Priority <> 3" | foreach {
    $_.Priority = 3

Use this script to set the Sending Priority to Low for all ConfigMgr driver packages. You can see in the script, we query the SMS_DriverPackage class for all Driver packages that do not have a Priority = 3, and then enumerate each one, set the Priority property to 3 (3=Low, 2=Medium, 1=High) and then used the Put() method to save the change. Here’s a brief list of the classes that you can use modify sending priority by simply replacing the class name in the script above:

SMS_PackageBaseClass – This is the base class for all package class. Use extreme care (and testing) when running scripts against SMS_BasePackagClass.
SMS_ContentPackage – new to ConfigMgr 2012, this is for Applications, no SDK Doc currently available.

You can also use the get-wmiobject –filter command to find a specific package. Just change -filter “Priority <> 3” to –Filter “PackageID=’LAB00028′”

Bonus TIP: Here’s a quick script to show the count of each Package type using the group-object cmdlet:

#replace MySiteServer with central site server name,
#and LAB with site code
get-wmiobject sms_packagebaseclass -namespace root\sms\site_LAB -computer MySiteServer | group-object __Class | select-object Name, Count

Happy Scripting,


Win32_Product Is Evil.

This is an encore presentation from my old blog.

I’m a bit of a fan of Windows Management Instrumentation (WMI), but today’s post is a bit of a ‘buyer beware’.  I’ll sum it up, and then provide some detail and give you some ideas of where this can be a very bad thing. For starters, go to a TEST system (Windows Server 2003, Windows Vista or later), launch a PowerShell command prompt (run as administrator so that you have full rights), and run the following command:

get-wmiobject win32_product

(PowerShell is used for simplicity here – this issue occurs in every way you query Win32_Product )

Win32_Product will return some great information about each windows installer-based application.  In fact, you can even view additional properties by running get-wmiobject win32_product | select * . However, even though you called a basic query of the Win32_Product class, you actually performed a consistency check of each installation. Take a look at the Application Log after running the previous command  (event viewer), and you will see something similar to this:

EventID = 1035

Source = MsiInstaller

Details = “Windows Installer reconfigured the product…. ”

Each of these entries is for a Windows Installer product, and you can see in the details that each product was ‘reconfigured’ – luckily, if you have healthy Windows Installers, everything should be happy, and the consistency check just confirms that. If however you have systems that are unhealthy, or the installation has been altered in some way, this could cause a failure during the consistency check, or a failure of the application after the reconfigure.

The bottom line is that I expect when I query a WMI namespace, that ONLY a query occurs. Unfortunately, with Win32_Product, that’s not the case.

Here’s a KB article for Vista and Server 2008 that explains a scenario with using Win32_Product as a WMI Filter in group policy – the same info applies when querying Win32_Product manually or with an enterprise systems management tool.

Event log message indicates that the Windows Installer reconfigured all installed applications

The article only applies to Vista and Server 2008, but I can confirm that the same thing happens on Server 2008 R2 and Windows 7.

Now that we’ve talked about the general issue, let’s talk about where things can go bad with using Win32_Product in ConfigMgr.

Win32_Product Use Potential Issues
System Center Update Publisher (SCUP) Using Win32_Product in an Applicability rule will cause every system in your site (regardless of collection membership) to run the query, which causes the consistency check/repair. You can’t control this on a collection level. All clients that are configured to the Software Update Point will perform the scan. This custom update automatically replicates to all children sites with Software Update Points.  Each time a scan is run, the Windows Installer consistency check/repair will run.
Desired Configuration Management Creating a Configuration item (CI) with win32_product will cause every system that is targeted with the CI to initiate the consistency check/repair each time the baseline rule is evaluated.
SMS_DEF.MOF (hardware inventory) Untested, but I believe the consistency check/repair will occur each time hardware inventory runs for all clients in the site.
ConfigMgr 2012  App-Model Deployment Types If deploying to USERS, the consistency check/repair will occur when a user attempts to install the software from the software catalog.
If deploying to DEVICES, I the consistency check/repair will occur when the client checks to verify that software is installed.

So as you can see, in the ConfigMgr world, there are many ways to use win32_product that can cause you to have a bad day. So be careful with win32_product!

The good news is that (so far) the message reported is benign, and it doesn’t seem to actually cause a repair. If you encounter a product where this does cause a repair, please send me the info asap.



Get every new post delivered to your Inbox.

Join 1,873 other followers