Jump to content


using System Center 2012 Configuration Manager - Part 10. Monitoring our Monthly Updates Automatic Deployment Rule

Recommended Posts

In Part 1 of this series we created our new LAB, we got the System Center 2012 Configuration Manager ISO and extracted it, then copied it to our Active Directory server. We then created the System Management container in AD, delegated permissions to the container, extended the Schema for Configuration Manager. We then opened TCP ports 1433 and 4022 for SQL replication between sites, installed some prerequisites like .NET Framework 4.0, added some features and then downloaded and installed SQL Server 2008 R2 SP1 CU6. We then configured SQL Server using SQL Server Management Studio for security and memory configurations prior to running the Configuration Manager 2012 setup to assess server readiness. Finally we installed a central administration site (CAS).


In Part 2 we setup our Primary server with SQL Server 2008 R2 SP1 CU6. We then installed Configuration Manager 2012 on our primary server (P01) and verified that it was replicating to our central administration site (CAS) server. Then we configured Discovery methods for our Hierarchy and then configure Boundaries and Boundary Groups. In Part 3 we configured Discovery methods and configured boundaries and created a boundary group, we then configured them for Automatic Site Assignment and Content Location.


In Part 4 we added the Application Catalog roles to our Hierarchy. We then configured Custom Client Device Settings and then deployed those settings to the All Systems collection on site P01. After that we created Custom Client User Settings and deployed them to the All Users collection in order to allow users to define their own User and Device affinity settings.


In Part 5 we installed the WSUS server role (it is required for the Software Update Point role). We then installed the Software Update Point role on our CAS and Primary servers and we configured the SUP to support ConfigMgr Client Agent deployment which is a recommended Best Practice method of deploying the Configuration Manager Client Agent. In Part 6 we prepared our server for the Endpoint Protection Point role, and installed that role before configuring custom client device settings and custom antimalware policies. We then deployed those custom client device settings and custom antimalware policies to our newly created Endpoint Protection collections.


In Part 7 we added operating system deployment ability to our hierarchy by adding Windows 7 X64. We used the Build and Capture process to capture a WIM image which we can later deploy to targeted computers using network boot (PXE). PXE boot requires specific settings on our distribution points and the boot images used to deliver the operating system WIM images were therefore also enabled for PXE support.


In Part 8 we added Applications to our Software Library and configured the requirements in the Deployment Type to add new abilities to the application delivery process. We monitored the approval process of our applications and saw how requirements can influence whether an application is installed or not and we noted the difference between deploying to Users versus Devices. Now we will take a look at how Automatic Deployment Rules can be used to automate the deployment of windows updates on Patch Tuesday using a recurring schedule to patch your infrastructure using Software Updates.


In Part 9 we created some folders and collections using a PowerShell script to make targeting of Windows Updates easier, we then performed a full synchronization of our Software Update Point before creating an Automatic Deployment Rule (ADR) for Windows 7 monthly updates for Patch Tuesday.


Now we will monitor the ADR when it runs per the schedule we defined and we will monitor the downloading and deployment of those updates both to the distribution points and finally to our Windows 7 client computers. We will review the process in fine detail in order to understand the sequence of events when an ADR is run on a schedule.


Tip: Automatic Deployment Rules can be run either automatically (using a predefined schedule such as the one we created for the Patch Tuesday ADR) or manually (by right clicking on the ADR and choosing Run Now) when you want to test them.


Note: In this post we will assume that Patch Tuesday is occuring today and we will also assume that Microsoft has released a whole bunch of Windows Updates. As today is in fact not Patch Tuesday (it's actually a Friday) I will make a small change to my ADR, this is not needed in production and i'm only doing it to get the patches that were in fact released on the last Patch Tuesday. You might be wondering why i'm doing it this way, and the answer is simple, the computers I use to create these guides are in a lab and that LAB was powered off when Patch Tuesday came and went, therefore no patches were downloaded based on the ADR's settings (of last 1 day). In order to get around this and to present you with what you would see I will modify my ADR to download patches released in the Last Month. To run our ADR as if today was Patch Tuesday I adjust two things, firstly I adjust the Software Updates Tab so that Date Released or Revised is set to Last 1 Month and then I adjust the Evaluation Schedule so that it kicks off 5 minutes from now. You do not have to do this, I'm doing this to show you what happens when the ADR actually runs on Patch Tuesday !


last one month.png


Step 1. Monitor the RuleEngine.log file to determine ADR activity

Perform the following on the CAS server as SMSadmin


To get a better understanding of what happens when our ADR runs we will monitor the log it uses for processing ADRs. On Patch Tuesday when our ADR runs it logs the fact to the RuleEngine.log file.


Tip: The RuleEngine.Log file is located in D:\Program Files\Microsoft Configuration Manager\Logs


Open this log file in CMtrace and you'll see the following when the ADR runs on a schedule. Notice that I've configured my rule to run in a few minutes from now purely for the purpose of capturing the event in the log.


next event is.png


When the actual scheduled time occurs the ADR will be triggered and you'll see lines similar to the following in the log


Note: the Updated next occurence will be one month from the date listed (and not one day as in the screenshot below), this screenshot shows one day as I adjusted it to run for this guide as described in the notes above.


rule is running on schedule.png


if you scroll further down in the log you'll see our Windows 7 Monthly Updates ADR is referenced directly and it also informs us if updates need to be downloaded into our previously created package, in this particular case 25 updates need to be downloaded into our package on the CAS server.


25 Updates need to be downloaded.png


Underneath that you'll see the ADR is attempting to download content (with content ID) and whether it was successful or not.


downloading updates.png


You can also open Windows Explorer at this point and browse to the location of your Windows 7 Updates package source location, you'll see that folder filling up with folders which in turn contain files, these are the updates being downloaded.


windows 7 updates.png


after the ADR has downloaded all the updates it'll update the Deployment Package, look for the line Updating pacakage "CAS0000C" now where "CAS0000C" is the package ID of your Windows 7 updates package


Updating package CAS0000C now.png


After that it will Enforce the Create Deployment Action (by creating a new deployment containing the updates it has just downloaded). This can be seen in the RuleEngine.log below where it says:


We need to create a new UpdateGroup/Deployment


we need to create a new updategroup deployment.png


This brand new deployment can now be found in the Monitoring Workspace by clicking on Deployments. Notice how the date and time are appended to the Deployment name, this makes running reports on that months ADR's easy. The compliance information revealed at this point is listed as Unknown (1) as my one and only Windows 7 client is powered off.


ADR software updates - monthly deployment in monitoring workspace.png


Finally after creating the new deployment the ADR creates an alert and updates the success information of the rule.


updated success information for Rule.png


Step 2. Monitor our Deployment Package getting distributed to our Distribution Points

Perform the following on the CAS server as SMSadmin


Now that the ADR has run and our Deployment Package has been updated we can check the status of the package. In the Software Library workspace, select Software Updates and expand Deployment Packages, select our Windows 7 Updates deployment Package.


distribution point status.png


Straight away you can see that the status is good as it's green (successful). However let's dig deeper and click on Content Status in the right corner, then select our package in question, Windows 7 Updates.


Once again we can see it's successful, however if you have multiple distribution points you may want to know more information. Click on View Status.


view status.png


This shows us 4 tabs where we can review the success or failure of our deployment package getting to our distribution points.


content was successfully refreshed.png


In addition to using the Configuration Manager console to get the status of our Deployment Package (which contains our windows updates), you can review the distrmgr.log file on CAS to review when the Deployment Package gets the updates added to it and then when it is distributed to the distribution point(s).


Open the distrmgr.log file and look for the line Found package properties updated information for package 'CAS0000C' which is our Deployment Package, change the Package ID to suit your own Deployment Package id.


found package properties update notification for package.png


further down the log you can see that the source for the package has changed or the package source needs to be refreshed. At this point it updates the source version (to 2) and then adds the changed content (new updates)


the source for package cas0000c has changed or the package source needs to be refreshed.png


and then it sends the package to our distribution points (P01 in our case).


sending a copy of package cas0000c to site P01.png


Step 3. Monitor the Windows update process on our clients

Perform the following on a client computer as Testuser


Logon to a Windows 7 computer as testuser.


Once the computer has received policy you'll see the following notification telling you that software changes are required


software changes are required.png


clicking on that will give you more details of the deployment


software changes must be applied to your computer after.png


If you click on View Details you'll get even more details of what this deployment actually is..


and it is of course our Windows Updates,


software center.png


click on Install all required to see what happens when the deadline is met (one week from now...)


install all required.png


the updates are downloaded and installed... if there's a restart required you'll be informed of that, you can click on restart to speed up the process.


restart required.png


and Windows configures the updates...


configuring windows 7 updates.png


If you want to see the process above via logfiles you can review the WUAhandler.log on the client to see when it scans against our SUP server to see what's available, and it can see that updates are missing.


its a wsus update source type.png


and the updates are installed, you can also see the restart information per update listed, this is the same info that was reflected in the Software Center


installation of updates completed.png


In addition to the above log you can review the windowsupdate.log in C:\Windows


It starts the search for updates


start search for updates.png


adds some updates to the search result..


add updates to search result.png


then downloads applicable updates to the cache


downloading updates to cache.png


and then it installs the updates..


installs the updates.png


before telling us that it suceeded installing those updates...




Step 4. Monitor the compliance

Perform the following on the CAS server as SMSadmin


In the Monitoring workspace, select deployments and click on Run Summarization in the Ribbon, this will run a summary of the compliance data that the server has received from the clients via state messages.


Run Summarization.png


and then select our recently created Windows 7 Updates ADR deployment, the data returned at this point may not reflect the actual compliance state or our client(s) as it can take a long time to process this data in this view. So in the screenshot below the compliance state for our Deployment is In Progress.


compliance state is in progress.png


At this point we are done, you can wait and click on refresh until it registers as compliant (trust me !) or you can run a report for compliance. We havn't configured reporting yet, that's another part of the series. If you are experiencing delays in this information then take a look at this post on technet to understand how compliance should look and how long it takes to process the information.


After some minutes processing the data it shows up as compliant ! job done :-)


compliant !.png


O.K. that's it for this post, I hope you understand how Automatic Deployment Rules work now and how the entire process flows, until next time, adios.

Share this post

Link to post
Share on other sites

Hi anyweb,


Thank you again for this documentation,


I have followed up with this and the previous Part 9. It looks good so far but I have several Updates, Updates Rollups and Critical

Updates which are not being published and I don't know why not. Have you any idea about the reasion for this behavior or what it might be?


In the screenshot you can see that these are already downloaded, but this I had to do manually as well.


Thanky you




Share this post

Link to post
Share on other sites

well all that shows me is you have an ADR setup to run every day (should be once a month for patch tuesday) for Windows 7 updates, can you please clarify the following



It looks good so far but I have several Updates, Updates Rollups and Critical

Updates which are not being published and I don't know why not.


have you verified that you've done a successful sync ?

Share this post

Link to post
Share on other sites

sorry for my delayed response.


I have entered every day, because I want to see a possible positive result next day. Before this I had the running time once a month as you explained in your descriptions.


The sync was successful and the patch downloaded completely.




Share this post

Link to post
Share on other sites

use the one from the RC version it should work fine, i will be covering deploying operating systems in Configuration Manager 2012 Service Pack 1 soon however.

Share this post

Link to post
Share on other sites

Hi Anyweb,


Great tutorial, it's been a lot of help!


I am running into a problem though that I'm hoping you can help with. I have been able to get everything working up to the client seeing that there are software changes required and the Software Center shows the updates. But I would like the updates to automatically install and I can't seem to get that to happen. As of right now the client shows "Past due - will be installed" but I'm still required to manually kick off the installation. Is there a way to force the installation as soon as the updates are available? I don't want users ignoring the message about updates and never installing any.




Share this post

Link to post
Share on other sites

Hey Anyweb...

As always great job on this post in particular. I found it to be extremely helpful in understanding the way updates are download, packaged, and deployed... and all automagically!!


Still, I've run into an error that I'm having trouble with. Everything works flawlessly until deploying to clients. Here is an example from the WUAHandler.log from a problem machine...


<![LOG[its a WSUS Update Source type ({F45E8BEE-9A7B-4C8B-A561-53D5ECFAA5DB}), adding it.]LOG]!><time="16:34:33.292+300" date="09-26-2013" component="WUAHandler" context="" type="1" thread="5388" file="sourcemanager.cpp:1232">
<![LOG[Waiting for 2 mins for Group Policy to notify of WUA policy change...]LOG]!><time="16:34:33.432+300" date="09-26-2013" component="WUAHandler" context="" type="1" thread="5388" file="sourcemanager.cpp:954">
<![LOG[Failed to Add Update Source for WUAgent of type (2) and id ({F45E8BEE-9A7B-4C8B-A561-53D5ECFAA5DB}). Error = 0x87d00692.]LOG]!><time="16:34:35.757+300" date="09-26-2013" component="WUAHandler" context="" type="3" thread="5388" file="cwuahandler.cpp:2325">
So, It's pretty obvious to me that there is a conflict where '12 is trying to point the machine to the '12 server holding the deployment and some kind of policy that is pointing to the '07 server that is still in place for machines that haven't been migrated. Unfortunately, my Network Admin and myself have not been able to isolate where it's coming from.
For some background/troubleshooting... We're obviously in the process of migrating from '07 to '12. We'd like to begin updating the '12 clients while still updating/migrating the '07 clients. The most telling troubleshooting I've found is in the registry. In the key HKLM/Software/Policies/Microsoft/Windows/WindowsUpdate there are two sub-keys called WUServer and WUStatusServer. On every client that is/was on CCM '07 those sub-keys are set to the '07 server. If I manually change them to the '12 server, they automatically revert back to the '07 server when I run the evaluation cycles on the machines from the '12 console. Just to test that, I imaged a new machine and did not let '07 install whatsoever. Rather, I installed '12 from scratch... no migration basically. Everything works like a charm on that machine. This machine's reg keys in question were already set to the '12 server.
Do you have any idea what is causing the migrated systems to revert back like that? Do the systems refresh group policy when the evaluation cycles are started?
I hope I have not inundated you with info to the point of confusion and I sincerely hope all of that make sense. As always, thanks for the assistance!
*Edit - For whatever reason, the pasted LOG is omitting a couple lines. Of course, they are the most pertinent. Because you've likely seen them before, I'll just try to describe. One is enabling the '12 server policy to use the '12 server. The other missing lines report an error enabling that policy because "group policy setting were overwritten by....."
Edited by xc3ss1v3

Share this post

Link to post
Share on other sites

First of all, this guide was just great in helping me getting to know sccm.


I have one question with regards to Windows updates. If I set up everything just like the guide (that is only include updated added in the last 1 day and run the update every 2nd Tuesday of every month), what will happen to update that were release prior of the creation of the ADR?



Share this post

Link to post
Share on other sites


what will happen to update that were release prior of the creation of the ADR?


you'll need to create separate baselines Software Update Groups for those updates and deploy them accordingly

Share this post

Link to post
Share on other sites

Quick question... This will be the 2nd month of running updates. In the RuleEngine.log I see where SCCM did go out and pursue updates as scheduled on Update Tuesday. From what I can tell, nothing was added to the deployment package because everything already existed. I know this will seem like common sense, but I just wanted to verify. Since nothing was added, it would not automatically create another deployment, correct?


And, visa versa, if something was added, then it would automatically create a new deployment? I wouldn't need to trigger it?

Share this post

Link to post
Share on other sites

These are such great posts. Long time listerner- first time caller here.


We are just now getting to the process of migrating from WSUS to SCCM for our updates. I've got all the clients setup and ADR's working etc.


The only issue I am having is with the server updates and how to set those up. I have run your script and have all the folders/collections setup. I just don't know what to do next, and how to set the maintenance windows for the collection that says Server 2008 Maintenance Window. I am assuming the "2008 Manual" is best served by just manually specifying which servers I want to do manually. In the guide it says you will cover maintenance windows, but I can't find that post, did I miss it?


Thanks so much for your help and these posts!

Share this post

Link to post
Share on other sites

This is probably a silly question, but how would I go about setting up an ADR to run on "Patch Tuesday", which in my case, I'm GMT+10 so "Patch Tuesday" is actually "Patch Wednesday" here.


Currently in our legacy SCCM 2007 environment I do this all manually on the Thursday of patch week, but was hoping to leverage ADRs in our new 2012 environment to help simplify this.


I currently have a rule to fire every second Tuesday at 11:59:59 PM but unfortunately doesn't seem to get all the updates (must be released later).


I also couldn't find any sort of method to set the Sync time to UTC (the client schedule yes, but not the actual sync schedule)



Share this post

Link to post
Share on other sites

Hi anyweb,


Doesn't work. The ADR fires at 11:59PM on the second Tuesday of every month (I'm already using the Patch Tuesday template type). The issue is, that most updates don't come into our system until 6AM the Wednesday morning. (Our update sync schedule is every two hours, so this is not the cause.)


Making the rule fire on every second Wednesday doesn't suffice either as there are months where the second Wednesday happens before the second Tuesday. Any ideas?



Share this post

Link to post
Share on other sites

hi there,


we are using the system center 2012 r2 and i have deployed all OSD task sequences and updates to unknown computers collection.


my question is: how do you deploy a new operating system incl. updates to an already known machine? (=not unknown system)


because machines with a re-setup will be member of all systems collection and you dont want to deploy OSD & updates with "required" ticked, do you?

Share this post

Link to post
Share on other sites



Firstly, great tutorials, very useful indeed.


Have a weird one that has occurred today. We have an ADR set that includes severities so that we can set a custom severity of "low" to exclude any updates that are pushed out to the clients. However, in the latest batch of updates, I had marked up IE11 as low, and for some reason I cannot fathom, it was included in the deployment and so was released out onto our clients.


Obviously, this isn't ideal, and has resulted in me running around trying to figure out why it's happened, however my co-workers and I cannot find a flaw in the logic of the rule, so I am opening up to the gestalt to see if anyone else might have some idea as the reason behind this.


Thanks in advance for any brainstorm that can be provided.


All the best,



Share this post

Link to post
Share on other sites

Hmmmm...sorry to hear that happened. It is possible that Microsoft modified the IE11 update, and that's why it got put into your deployment? For instance, usually a new IE browser is listed as "optional" in the Windows Update catalog. Eventually (many months or a year later), Microsoft decides that the new browser version is "important" or "critical."


I don't use ADRs for Windows Updates; I'm just thinking out loud here.

Share this post

Link to post
Share on other sites

Thanks for the reply.


IE11 hadn't been shown as an update since it came out, but that changed in May. We always run a month behind on updates to allow kinks to be ironed out before we apply the updates to clients. By default there is no severity classification on most of the updates, so we have a rule in the ADR that states anything but "Low" severity updates are included, and if we don't want an update to be included in the update group we put a custom severity of "Low" onto that update so it is excluded. This has worked fine in the past, and I set this severity on IE11 on Friday, however come Saturday, when the ADR ran and created the Software Update Group for May, the rule was ignored and IE11 included.


The very scenario you suggested had previously happened with IE10. Microsoft had changed the classification from a Security Update to an Update Rollup, and it slipped through that way, hence why we have been especially careful about IE11, and so the frustration over this (*use polite words....) "hiccup". ;)

Share this post

Link to post
Share on other sites

Hi anyone that can help

I'd just like to say this site is great. It's helped me a lot moving towards my goal of hopefully one day being ann SCCM specialist.

I have a question. I'm currently trying to use Automatic Deployment Rules for patch Tuesday on a lab I have setup, So I

can try and understand how it works. The ADR works to a point, gathers some software updates, 6 in total last time

around. However, when I look in the "All software updates" node I can see 108 updates listed from the last patch Tuesday

are available. Any ideas why these 108 updates are not in my ADR group? I used the following criteria in my ADR


DATE RELEASED OR REVISED: Last 1 week (7 days)

UPDATE CLASSIFICATION: Critical Updates Or Security Updates OR Update Rollups OR Updates

Any suggestions what to check out would be massively appreciated.


Share this post

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Create New...