You are browsing the archive for Software Update Management.

Avatar of timdk

by timdk

ConfigMgr vNext Feature Highlight : Multiple Deployments for ADR’s

2:00 pm in Configuration Manager by timdk

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!


Avatar of timdk

by timdk

Week in Review – CW24

9:05 am in Configuration Manager by timdk

This week was a very busy and exciting one with the first edition of ITPROCeed taking place. All the effort put into the event by many paid off and the event was really a success – stay tuned for a short debrief somewhere next week.

In-between project work and the event preparations there were a few items that I did flag for further reading. Here they are outlined in this week’s review:

See you next week!


Avatar of timdk

by timdk

Troubleshooting – How to pinpoint a problematic software update based on UpdatesDeployment.log entries

1:59 pm in Configuration Manager by timdk

Recently a customer of mine bumped into an issue when applying software updates during a Task Sequence. The first symptom that was noticed was that the task sequence was taking forever to complete. Looking further into this it turned out the task sequence  step during which the updates were applied was running for a very long time.

Further investigation of the log files was required and an entry in the UpdatesDeployment log is pointing us into the right direction.


The status ciStateError indicates there is a problem with this specific update. Further looking up the error code 87d00669 indicates there might a problem with the content. The real challenge now is to find which update it actually is that is causing this problem. All we have on it right now is the ModelName (Site_ / SUM_) without any further information.

We figured that using the Get-CMSoftwareUpdate cmdlet would be the quickest and easiest way to gather some more information and tried the following command:


Unfortunately this is not the case. The command itself seems to take forever to run and on top of that we ended up with a warning indicating the result exceeded the maximum size. Using Set-CMQueryResultMaximum we could probably overcome this … but as we don’t have an hour or more to wait for results we need another solution.

In comes WMI. Using PowerShell to query WMI is really easy, but alternatively you could also use WBEMTest or a 3rd party utility. We’ll go for the Powershell approach and  need the following information:

  • The namespace in WMI (using site_ABC where ABC is the site code)
  • The hostname of the SMS Provider
  • The actual WMI Query

The actual command is shown in the screenshot below. The result is returned in a second and we immediately have the required information of our problematic Software Update.


Hope this saves you some troubleshooting time in the future!



Avatar of timdk

by timdk

Creating a Software Update Group based on an input file

3:29 pm in Configuration Manager by timdk

Depending on your patching process the way you structure and create Software Update Groups in Configuration Manager 2012 may vary. At quite a few customers I see a scenario where the monthly patch review board spawns a spreadsheet with the Updates to be released into the environment. Having to create a Software Update Group based on that spreadsheet manually can be a time consuming task for the Configuration Manager administrator.

With the new powershell cmdlets available in Configuration Manager 2012 Service Pack 1 I found out it was really straightforward to automate the creation of the Software Update Groups and populating them based on a csv input file. For someone like me, having very little experience with Powershell and scripting in general, it only took a few hours of playing in my lab to accomplish this. Lets have a look at the steps I’ve walked through.

Step 1 – The input file



Example of a .csv input file.

As a source for input we will use a csv file. As you will see later on, this type of file is very easy to use with powershell. If you need to start from an Excel (.xls, .xlsx) file you can easily save it in csv format.

The input file usually contains a lot of information on the updates to be deployed. The most common ones are the Article ID, Bulletin ID and the description of the update itself. I decided to use the description field as it is most likely a unique field. Fields like the Article ID and Bulletin ID can be applicable for multiple updates (eg for different updates per CPU architecture).The screenshot shows an input file from my lab.

Final part of this step is to copy the file on a dedicated folder on the site server.

Step 2 – Building the script


To automate the import we will be using 3 powershell cmdlets: Import-csv, Get-CMSoftwareUpdate and New-CMSoftwareUpdateGroup. Below is a short summary on what the cmdlets can be used for:

  • The Import-Csv cmdlet creates table-like custom objects from the items in CSV files. Each column in the CSV file becomes a property of the custom object and the items in rows become the property values. Click here for more details:
  • The Get-CMSoftwareUpdate cmdlet retrieves configuration settings for one or more software updates. More details on the cmdlet can be found here:
  • The New-CMSoftwareUpdateGroup cmdlet creates a software update group for Microsoft System Center 2012 Configuration Manager. More details can be found here:

The Import-csv cmdlet will be used to read the information from the input file. Based on the Displayname of an update we will use the Get-CMSoftwareUpdate cmdlet to determine the CI_ID that each update has in Configuration Manager. We will need the CI_ID’s as input for the New-CMSoftwareUpdateGroup cmdlet to populate the newly created Software Update Group.

There are two pieces of information we will need as input for the script: the path and name of the input file and the name of the new Software Update Group to be created. We should be able to provide these as parameters for the script and prompt for them in case the administrator forgets to specify them.

Putting all these elements together results in the script shown in the screenshot below:


The CreateCMSUG.ps1 script.

Save the script in the dedicated folder on the site server where the input file was saved previously.

Step 3 – Connecting via Powershell and running the script



Connecting to Powershell via the Console.

Connecting to the Configuration Manager site with powershell can be done via the console. Click the blue tab in the top left corner and select Connect via Windows Powershell. A new window will open and the prompt should look like PS %Sitecode%:\>

When running the script you can provide the required parameters immediately: the first one is the name and location of the input file and the second one is the name of the new Software Update Group. In case you do not provide them you are prompted.Notice that upon succesful creation of the Software Update Group the details of that SUG are shown. The LocalizedDisplayName property shows the name that was provided as input parameter for the script.

Step 4 – The result



The newly created Software Update Group

Open the Configuration Manager console and go to the Software Library workspace, then click Software Update Groups. Your newly created Software Update Group should be listed. If

it is not make sure to refresh the view. Optionally you can change the name of the Software Update Group by modifying its properties.





Current members of the Software Update Group

To check the membership you can either double-click the Software Update Group or right-click and select show members.

Conclusion: given the fact that I am not a scripting expert, there is probably much room for improvement on the script. As I am eager to learn more on Powershell with ConfigMgr I will further work on optimizing the script in the future. For now I have a quick and easy solution to create my Software Update Groups and save a lot of time.

The script can be downloaded here:CreateCMSUG Powershell script (2142)

Hope it helps!