This blog post is part of the Coretech Global Xmas blogging marathon – today is my turn to share something new and as a subject I have picked a feature which will be available in the upcoming new release of Configuration Manager : support for multiple deployments with a single Automatic Deployment Rule (ADR).
ADR’s are not entirely new as they already existed in Configuration Manager 2012. One of the shortcomings of ADR’s in 2012 is that they only support a single deployment. So if you have a phased deployment -for example lab, pilot and production- within your organization, you would have to create a new ADR for each phase. These ADR’s would be very much identical except for the target collection and the scheduling.
In the vNext release of Configuration Manager this is no longer an issue as a single ADR will now support multiple deployments. So following the above example we could use a single ADR for patching our lab, pilot and production machines. Time to have a closer look into how this will work.
The base ADR
Defining the rule for the machines in the first “Lab” phase is identical to what you have been doing in the past for Configuration Manager 2012. A quick walk through the steps:
After specifying a name and description for the ADR we pick the Patch Tuesday template that Microsoft has included out-of-the-box. We set the target collection to our lab workstations collection. Notice there are no options to define additional collections here. As this is the lab collection we opt to have the deployment enabled immediately.
In the deployment settings we picked the default settings.
In the Software Update settings we picked the default settings. Note that the last one day option offcourse only is valid if we let the rule run no later than one day after patch Tuesday.
We set the schedule to run every second Wednesday of the month.
For the lab phase both the available time and the installation deadline are set to as soon as possible.
Define the user experience. In our example we used the default settings.
In the next step we can specify the alert options. Also here we kept the default settings.
Also for the download settings we kept the defaults.
Specify the deployment package to store the patch binaries. In our example we used an existing package.
We will download the binaries from the internet.
In our environment only English is required.
Review the summary and click next.
At this point our our ADR has been created and we can close the wizard.
The end result is shown in the picture below. We have our ADR which currently still has a single deployment as defined in the wizard we just walked through.
Adding additional deployments
To add and additional deployment we need to select our ADR and select Add Deployment action either through the ribbon or via a right-click.
This action will kick off a slightly trimmed down wizard similar to the regular ADR one.
In step one we need to specify a target collection. We will take our second collection containing our pilot phase machines. By default the deployment would be enabled here also but as we would like some more control and make sure our lab tests were successful first, we will disable it. At a later point in time an administrator will have to enable the deployment manually.
We kept the default Deployment settings.
In our scenario we wanted one week of lab testing before deploying to the pilot collection so the schedule settings were adjusted accordingly.
We kept the default User Experience settings.
We kept the default Alerts settings.
We kept the default download settings.
Note: I noticed that these download settings do not match with the default download settings from the Create ADR wizard. Clients on a slow boundary or using fallback by default will not install the updates. Also content download to Microsoft Updates is unchecked by default in the add deployment wizard. Make sure to check the options carefully before clicking next.
Review the summary and click Next
Our additional deployment was created successfully. Click close.
As you can see our second deployment is now in place. We still have only one ADR.
To support our scenario end-to-end all we needed to do is to add a third deployment for our production environment. The end result would look like this:
So what is the end result after running the rule? This is shown in the screenshot below. There are 3 Software Update Groups, each of these groups have a single deployment as per the schedules configured in the ADR.
The names of the Update Groups get a numeric appendix based on the order and total number of deployments for the ADR.
That’s it for this feature highlight.
Enjoy the upcoming holiday period and until next time!