BGags

...so noted! I'm high on decongestants right now. Thanks for the suggestions! What I'd really like to do is figure out the SQL such that the derived table of jobcounts handles the null possibility within the presented table.

Okay! What should I modify them to? I included those check conditions because a few systems ran into a case where the Install Patch command was succeeding (as far as Automate cared, anyway), even though the patches weren't getting installed. The "download failed, will attempt again" state occurred result would cause the monitor to trip for these systems over and over again, every five minutes, without actually accomplishing anything. I wanted to make the monitor itself as (relatively) harmless by itself as I could, so I could let admins that know SQL or admins that use this monitor to hu

Summary: I think the Automate Patch Manager's stock Daytime Patching (DTP) functions give up way too easily. So I wrote a RAWSQL monitor that you can use to drive patch delivery scripts during the day to systems missing patches. The monitor is built to use stock Patch Manager features relating to Microsoft Update Policies, so it should be pretty universal. The configured criteria as written: System is online Windows OS No servers No reboot pending Has an effective Microsoft Update Policy that has Daytime Patching enabled Has more than 0 missing updates

@NickBurnsI'm doing something a little different than that directly; I'm taking the results and creating per-computer alerts that detail the type of problem detected, then those either get auto-fix scripts thrown at them or a single ticket created per-client for manual attention.

A bunch of us have found it true that Automate's own mechanisms and reporting don't tell the true tale of everything that's going on with patching. In determining how to fix it, I've found that it's not only important to determine the true patch state of our systems, but also to figure out what Automate itself is (and isn't!) doing. To that end, all I've got so far is a query inspired by Gavsto's, with a couple extra columns including most recent patch job per system, most recent patch job with an installation attempt, most recent patching error with date of error, and (perhaps most importantl

A couple things about the health check script: 1. I am working on one meant for public consumption. The vast majority of folks who will want to use it are all on the "new" patch manager (I'm not), and so my values for searching for approved hotfixes are going to be different than others, so I'm trying to parameterize that. 2. I'm also working through something right now where I'm finding that superseded hotfixes aren't being properly removed from Automate. I've got a number of systems that report anywhere from 1 to 10 updates missing, but when those updates are attempted again, the res

What was helpful for me: I also made a dataview for the EDF. I love dataviews!

Let me get back from Automation Nation first. There's a few different scripts. I'll share the Windows Update Repair script, my WUA validator script, and probably update the original post to include the current minimum WUA version numbers that I'm using as reference.

This document is meant as a successor to and replacement for "How I got to 95% patch efficacy in Eight Easy(?) Steps", mainly because about half of it is obsolete, but also because "efficacy" wasn't used correctly in that context and I know better now. Mostly. My hope is to make this more of a living document. I'd like to update this original front post as changes to it are needed rather than force the reader to descend into seven pages of comments to find the most up-to-date solution for any given problem. DISCLAIMER: I'm still running the "Classic" Patch Manager, based on the advice

One of the problems is that IE 9 and below report as a piece of software visible in Programs and Features, but IE 10 and 11 are distributed as OS Updates. With IE, you can go with the file version of iexplore.exe, but there's also a registry key you could hunt down. For file versions in general, here's a snippet of PowerShell code that usually works: Write-Output (Get-Childitem "").VersionInfo.ProductVersion Go check out the Script Exchange section. I'm pretty sure someone there has posted an IE Version detection script that posts to an EDF. If not, I have one, and will pos

Certificate Authorities tend to accumulate a craplog of logfiles that need to be occasionally cleaned out, only to reaccumulate over time. Little-known feature is that you can put the CA into a circular logging mode where they don't accumulate anymore. All SBS servers (eww) come equipped with a running CA service. You can set a search to look for servers with a running certsvc and fire this script at it once a month. You can set a size threshold for cleanup in a Global I've set. Fire it off once a month and never worry about CA log accumulation again. Clear-AD-Cert-Logs.zip

...okay, upon further review, I apparently am behind on my own Server 2012 / R2 WUA. What the hell. See? You shouldn't listen to me.

Hey, everyone. A funny thing happened when reviewing the h_patching data for 2012 / R2 servers the other day. I noticed that the WUA version reported in my EDF did NOT match the WUA version reported by the actual Windows update command. The ProductVersion of wuaueng.dll is 7.9.9600.17489, but the reported version in the history is 7.9.9600.18235. Well, CRAP. What's perhaps more alarming is that I did a search for "determine windows update agent version powershell server 2012", and I got back an article on SpiceWorks (wait five seconds for that pop-up!) that also referenced usin

This topic has been covered at length already. Check out this thread for more information than you really ever wanted to know about the Windows Update Agent. viewtopic.php?f=7&t=2123

This is the sound of me up-voting this request.