Changing the Deployment Package linked to an Automatic Deployment Rule in ConfigMgr 2012

This week I want to devote a post to changing the Deployment Package, which is linked to an Automatic Deployment Rule. I came on this subject as I got and read some questions about it. Actually it was not just that, also the fact that the answer was usually, that it’s not possible, at leas not via the console. As I couldn’t imagine that it’s not possible I went on a small research to see where it’s stored and how we can change it.

XML and WMI

Let’s start with where it’s stored. In WMI it’s stored in the class SMS_AutoDeployment and then the property ContentTemplate. Here it’s stored in XML format, like this:

<?xml version="1.0" encoding="utf-16"?><ContentActionXML xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><PackageID>PTP00027</PackageID><ContentLocales><Locale>Locale:9</Locale><Locale>Locale:0</Locale></ContentLocales><ContentSources><Source Name="Internet" Order="1"/><Source Name="WSUS" Order="2"/><Source Name="UNC" Order="3" Location=""/></ContentSources></ContentActionXML>

PowerShell

Now let’s go to the cool part, how do to change the package id that’s in the ContentActionXML. Well it’s actually quite easy with common XML parsing. To get all ins-and-outs about that, read this great article on the Hey, Scripting Guy! Blog. The first I needed, was to get a direct instance of the specific Automatic Deployment Rule. For that I used the following command:

[wmi]$AutoDeployment = (Get-WmiObject -Class SMS_AutoDeployment -Namespace root/SMS/site_$($SiteCode) -ComputerName $SiteServer | Where-Object -FilterScript {$_.Name -eq $AutoDeploymentName}).__PATH

The second thing I needed to do, was to get the XML content of the ContentTemplate property. For that I used the following command:

[xml]$ContentTemplateXML = $AutoDeployment.ContentTemplate

The third thing I needed to do, was to write the new package id to the PackageId property the ContentActionXML.The nice thing here, is that the different parts of the XML content can now be accessed as properties. So I used the following command to change the package id:

$ContentTemplateXML.ContentActionXML.PackageId = $PackageId

The fourth thing I needed to do, was to write the XML content back to the ContentTemplate property. For that I used the following command:

$AutoDeployment.ContentTemplate = $ContentTemplateXML.OuterXML

The last thing was to save the changes to the Automatic Deployment Rule and for that I used the following command:

$AutoDeployment.Put()

Conclusion

It was actually quite simple to change the Deployment Package, which is linked to an Automatic Deployment Rule, even though it’s not possible via the console. To see if the changes applied, either run the Automatic Deployment Rule and check the ruleengine.log, or run the Get-CMSoftwareUpdateAutoDeploymentRule cmdlet. With the combination of ConfigMgr, WMI, XML and PowerShell, there is little that can’t be changed!

The complete code (and usage) is available via the TechNet Galleries.

13 thoughts on “Changing the Deployment Package linked to an Automatic Deployment Rule in ConfigMgr 2012”

  1. Hi Peter, I had troubles using your PS script when my ADR-name had spaces in it. f.i. “Patch Tuesday – Windows 7”. I actually had to rename the rule to Windows7, and use Windows7 as argument before it worked. Anyhow, thanks for the script. Just what I needed.

    Reply
    • Hi Martin,
      Thanks for your feedback. Glad you already resolved your own issue! I just can’t seem to be able to replicate the issue when I’m using single quotes (‘).
      Probably Also good to know, R2 makes it possible to change the package via the console!
      Peter

      Reply
  2. Nice desription, but this doesn’t work for me. Like martin I cannot select the ADR based on name, but I used the ID. But then the contenttemplate property is empty, nothing in there! 🙁

    Reply
    • That’s really weird… I just ran another test and I just reproduce the problem… I ran the command C:\Windows\SysWOW64\WindowsPowerShell\v1.0\PowerShell.exe -ExecutionPolicy ByPass .\ChangeAutoDeployment_v1_0.ps1 -SiteCode PTP -SiteServer PTSRVR02 -AutoDeploymentName ‘Windows 8’ -PackageId ‘PTP0003A’ and my new packaged was linked. Did you try going step-by-step through the script (to see where the problem starts)?

      Reply
  3. Thanks Peter, I ran the command from the site server:
    C:\Windows\SysWOW64\WindowsPowerShell\v1.0\PowerShell.exe -ExecutionPolicy ByPass .\ChangeAutoDeployment_v1_0.ps1 -SiteCode MU2 -SiteServer . -AutoDeploymentName ‘ADR: Workstation Environment – Monthly Updates – Pilot’ -PackageId MU200173

    and it worked perfectly.

    Reply
  4. Peter
    I stumbled accros this while attempting to make a more dynamic ADR. I’m trying to use the function as part of my overall script, but the XML parsing can not find the PacakgeID property. When I look at the MS_AutoDeployment class, there is no PacakgeID. Has this changed between when you origannly wrote the code and now? or am I missing something

    Reply
    • You’re correct. It seems the structure of that class (and XML) has changed. That’s also not that strange, as you can now change the package in the console, which wasn’t possible at that moment. I would advise to make the change via the console and see what happens in the SMSProv.log.

      Reply
  5. Hi Peter.

    Thanks for this post, I have used the method presented here as the inspiration to be able to add or modify a Software Update property filter based on ArticleID. This filters out an offending update that a number of our customers do not want to be re-applied by the automatic deployment rule.

    Reply

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.