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

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 !

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.

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.

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.

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

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.

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

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:
Quote

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.

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

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.

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.

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

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.

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)

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

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

clicking on that will give you more details of the deployment

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,

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

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.

and Windows configures the updates…

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.

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

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

It starts the search for updates

adds some updates to the search result..

then downloads applicable updates to the cache

and then it installs the updates..

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.

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.

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 🙂

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.