Within the ConfigMgr world there has been a lot of talk around software updates lately. Especially with all of the recent changes including the change to allow a ConfigMgr client to download updates from Microsoft over the internet for free when managed by a CMG.

Before we go any further I want to put a disclaimer in, I found this completely by accident. I’ve tested this as much as I can and asked several other people to validate it re-mediates the issue for them and as far as we can tell it will fix your ADR with no negative impact. This script and the guidance in this post is provided “as is” and should be tested before attempting to use it in your environment.

With this in mind the ConfigMgr team has been adding more and more features to help with distribution of updates. In ConfigMgr a new feature was added into automatic deployment rules allowing updates to be processed into a software update group and deployed without downloading the updates. However while this is a cool new feature designed to help promote peer to peer content sharing and to help cut down on large software update packages there have been some challenges with it.

In the first iteration of the release (1806) it unfortunately caused some console performance issues. This was later partially resolved in the 1806 hotfix and fully resolved in 1810. However, in 1810 if you set an ADR to use Microsoft Updates or peers for content instead of downloading the content into the deployment package. You’ll notice that once you set this feature you can no longer change the ADR back to download a package. I’m unsure if this is a bug or if this is intended behavior based on some of the documentation more on that later on. Either way – both of the radio buttons are grayed out. So how do we manage to fix this without having to completely rebuild our ADR? Well PowerShell to the rescue.

Now a quick note before we go to far in on this according to the documentation you shouldn’t be able to update existing ADR’s to even use this setting:   – https://docs.microsoft.com/en-us/sccm/sum/deploy-use/automatically-deploy-software-updates  – while its possible that the language in the purple box seems confusing as you should ONLY be able to set this on ‘New automatic deployment rules – and warns you you CANT modify existing rules with this setting. (we’ll see about that).

A while back I wrote a script on how to change the deployment package by modifying the XML attached to the ADR to point it at a new package. Using some of the same code we can take a look at the ADR in question.

[wmi]$ADR = (Get-WmiObject -Class SMS_AutoDeployment -Namespace "root/sms/site_PR1" | Where-Object -FilterScript {$_.Name -eq "ADR - Servers"}).__Path

This will go out and get the ADR  and store it as a WMI object in the variable for WMI you’ll need to update the site_* to match your site code instead. I’ll include it as a script with variables on GitHub at the end of the blog.

Once we’ve got the automatic deployment rule we need to extract the content settings. The content settings are stored in the ContentTemplate for the WMI object we can take a look at all of the WMI object using WMI object explorer.


Note – it says ‘string’ there – we need to extract it in its XML format to ensure we add the property we need to resolve this correctly. We do this by casting the string to XML.

[XML]$ContentXML = $ADR.ContentTemplate
#Convert the content stored in the WMI object into the XML it should be treated as

Once we cast it into XML if we look at the child objects of the XML we notice that there is no PackageID attribute (not even a blank one) created for the object. Since this entry doesn’t exist this causes the other options to not be available.

We can do this by creating the PackageID element and then adding it as a child node to the ContentActionXML – this then causes the radio buttons to flip back to being available:

$PackageID = $ContentXML.CreateElement("PackageID")
#Create the missing PackageID element

The above creates a new element called packageID we then add the element to the content action XML using the appendChild command. We could at that point (if we wanted to) specify the package ID we wanted to use. If we don’t and leave the value blank it will simply leave the field blank in the ADR until we go back and set a package ID manually. See the blow code for how to set the package ID, then place the XML back into the content template and replace the WMI object.

#Add the missing PackageID element back to the content XML 
#$ContentXML.ContentActionXML.PackageID = "PR10000D"
#The above step is optional - if you don't use a package ID it will default to forcing you to simply select one of the three radio buttons.
$Adr.ContentTemplate = $ContentXML.ContentActionXML.OuterXml
#Swap the contenttemplate stored in the ADR with the XML that has been updated.


For the full code compiled together as a script


This script is for using when you have set the 'No deployment package' setting in ConfigMgr ADRS - and cannot uncheck the box in


    .\invoke-ADRDeploymentPackage.ps1 -SiteCode PR1 -ADRName "Example"  -Verbose -PackageID "PR10000D"

    FileName:    invoke-ADRDeploymentPackageFix.ps1
    Author:      Jordan Benzing
    Contact:     @JordanTheItGuy
    Created:     2019-01-18
    Updated:     2019-01-18

    Version history:
    1.0.0 - (2019-01-18) Script created
    [Parameter(Mandatory = $True,HelpMessage = "Enter the Site Code for your SCCM Server")]
    [Parameter(Mandatory = $True,HelpMessage = "Enter the name of the ADR")]
    [Parameter(Mandatory = $False,HelpMessage = "Enter the package ID you would like to set it to.")]
Begin {}
#$SiteCode = "PR1"
#$ADRName = "Example"
[wmi]$ADR = (Get-WmiObject -Class SMS_AutoDeployment -Namespace "root/sms/site_$($SiteCode)" | Where-Object -FilterScript {$_.Name -eq $ADRName}).__Path
Write-Verbose -Message "Got the ADR $($ADR.Name)"
#GEt the ADR WMIObject that represents the automatic deployment rule
[XML]$ContentXML = $ADR.ContentTemplate
Write-Verbose -Message "Converted the template to XML"
#Convert the content stored in the WMI object into the XML it should be treated as
$CreateContent = $MissingElement = $ContentXML.CreateElement("PackageID")
Write-Verbose -Message "Created the element for PackageID"
$AppendStep = $ContentXML.ContentActionXML.AppendChild($MissingElement)
Write-Verbose -Message "Appended the child"
#Add the missing PackageID element back to the content XML
#Create the missing PackageID element
$ContentXML.ContentActionXML.PackageID = $PackageID
Write-Verbose -Message "Succesfully added the packageID to the attribute"
#The above step is optional - if you don't use a package ID it will default to forcing you to simply select one of the three radio buttons.
$SwapStep = $Adr.ContentTemplate = $ContentXML.ContentActionXML.OuterXml
Write-Verbose -Message "Now adding the content XML back to the original ADR XMl"
#Swap the contenttemplate stored in the ADR with the XML that has been updated.
$ADR.Put() | Out-Null
Write-Verbose -Message "Completed putting the management object back"
#Put the WMI object you've been editing back.
    Write-Error $_.Exception.Message


and here is an example of running the script note that you’ll need to run this script from the ConfigMgr server alternatively you could add the -computername field to the WMI retrieval process:

You can download a copy of the commented code using parameters from the SCConfigMgr GitHub repository:


I hope this is helpful if you accidentally change an existing ADR to no longer download the content and realize you need to change it back.



There are no comments.

Leave a Reply

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