Introduction:
I recently release the first version of a Software Delivery trending tool for SMP [1]. With a few weeks of operations in production it is time to share some interesting result that are showing how useful the tool can be when it comes to understand what is happening in a production environment.
In this article we'll go thru 4 anonymous samples gathered from various production environments.
Sample 1: Windows Assessment Scan
The Windows System Assessment scan used by Patch Management Solution (to report installed and applicable updates from computers with the Software Update Agent) runs quick regularly - by default every 4 hours on workstation. In this graph we do see that the tool is running very regularly with some fixed interval (so we can see how the managed computers are synchronised due to common user trends i.e. people do come in the office in the morning, turn the computer on and work until the evening ;).
However there is something else that may not be obvious, but that is quite interesting tool. Given the SWD Execution table is set to hold no more than 1 million entry you would expect to see a full graph, with no flat line anywhere. This can be explained again by human behaviour. People do go on holiday :D. And when this happens, sometimes they take their laptop home for casual usage, or sometimes they shutdown just before the Windows System Assessment Scan results are sent to the server.
So when the workstation is opened a few days or weeks later it sends the data back to the SMP. And the NSE contains the execution time, which is the field we use. So you can actually see the impact of holidays on this graph.
Sample 2: Upgrade agent asap
This is the classic (and expected) view of a run-asap deployment to computers. Many computers will get the policy really quickly and run it, forming a nice bell. There isn't much to say about this, after form the fact that I wish all my Manged Deliveries would work just the same way.
Sample 3: Software Update installation head
The software update installation head is the behaviour encountered during the first week of release an update to production. It really depends on the process you have, but above we can see what happens with a customer using Patch Automation [2] to validate and deploy updates to production within a short period of time. The validation is done on approximately 1% of the estate.
The large peaks we are seeing are the scheduled installation, whilst the short peaks are night execution widows (mainly used by servers). All is going well for this software update freshly release, however in other cases you can see more errors that prompt further monitoring (depending if the error rate is constant over time or not).
Sample 4: Software update installation tail
The Software Update Installation tail is what you see and learn from checking Software Update execution results 4 weeks in a patching campaign. On the graph above (and many other software update graph for some customer servers) you are seeing a large count of failure versus some successes.
Upon deeper inspection we found out that the execution return code for the failing installation where 1058. This code indicates that either the Widows Update Service is disabled or Windows 7 computers were not activate properly against a licensing server (so they cannot apply any software updates).
Conclusion:
The visual aspect of the Evt_AeX_SWD_Execution table allow us to peer into what policies are doing in production. It allows us to troubleshoot problem that would not necessarily be obvious, and it also helps understand how human interaction with systems can impact patch compliance (when a computer is off for a few weeks) or software problem (there are some samples I have not shared, but I have one that is all red because a Software Update is constantly failing with error 17028, indicating that the update returns as not applicable (despite the fact that it matches the pre-requisites and contains vulnerable dll's).