Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials

Comparing AD Computers to WSUS

Hi, I am just getting to grips with patch manager and am struggling to find a way of reporting on Computers in Active Directory compared to computers which have checked into WSUS. We have multiple domains and WSUS servers and need to either report on the lot or per domain to find active computers which aren't in WSUS for whatever reason. Can this be done?

One post on the forum suggested creating a patch manager computer group and setting rules for WSUS and AD computers which have reported in the last 30 days. I have tried this and it does provide a list where computers in both AD and WSUS are displayed twice. Due to the amount of workstation / server objects I am looking for a more user friendly / workable way of assessing our current state.

Any help appreciated. Thanks

Find more posts tagged with

Accepted answers

All comments

LGarvin

struggling to find a way of reporting on Computers in Active Directory compared to computers which have checked into WSUS. We have multiple domains and WSUS servers and need to either report on the lot or per domain to find active computers which aren't in WSUS for whatever reason. Can this be done?

Greetings James.

This can be done, and the post on the forum is part of that effort. As you noted, it provides a list where computers that are in both AD and WSU are displayed twice. This is the good news. To get the other side of that equation we simply need to ignore those instances where a computer is listed twice. In the Patch Manager Computer Group that you created, group by the NAME column, and focus on the groups that have (1 item). There are two possibilities:

A domain-joined computer that is not present in WSUS.
A WSUS client that is not a member of the domain.

Unfortunately, while I agree this may be somewhat tedious for large numbers of clients, it is the only available way using exclusively the Patch Manager console to get this type of comparison to find domain-joined computers that are not registered with WSUS.

An additional step you can take is to export the entire Patch Manager Computer Group to an Excel workbook. Then, in the Excel workbook you can define a second column with a formula that compares the value in the NAME column with the value in the NAME column of the next row and compares the value in the NAME column with the value in the previous row. If either are equal (meaning there are at least two instances of that computer name), set the value to ''. If BOTH are NOT EQUAL, set the value to '1'. Then filter the list for the value of this column equal to '1'. These will be the computers that are not in BOTH AD and WSUS. It requires a bit of effort to define the formula in the column, but it eliminates the need to scan a long list of computers grouped looking for the "(1 item)" tag.

An entirely different methodology that can also be used is to inventory the Registry Values that indicate that a client system is communicating with WSUS. This requires some advanced inventory configuration of the Managed Computer Inventory task to define the registry values that need to be inventoried. But, if you inventory:

WUServer in HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate
LastSuccessTime in HKLM\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\Results\Detect

you can then build a report around any systems that do not have the expected data in those two values,

e.g. WUServer is not equal (or does not contain) the actual name of the WSUS server -or- LastSuccessTime is greater than 22 hours.

cookiejc

Thanks for your reply. I think ideally the registry inventory would be best but i'll need to work out how to get that working. Do you know of any documentation for doing it?

Can anyone from Solarwinds tell me if this is a reporting function that you plan to build into the product? To be honest its something I would expect from an enterprise patch managing product as standard. To be able to easily audit your environment to ensure all your systems are protected is a basic requirement. There's little point in the rest of the funcitonality if come the time of a pen test it's discovered that a number of machines arn't being managed by WSUS and therefore have missed updates.

.
Thanks again

LGarvin

I think ideally the registry inventory would be best but i'll need to work out how to get that working. Do you know of any documentation for doing it?

The Administrator's Guide briefly mentions (on p72) how to collect FileSystem and/or Registry information using the Managed Computer Inventory task. Once that data is collected via the inventory task, the Computer (Registry Information) report category defines two datasources that can be used to build the report. The Computers datasource provides all of the identification information for the system itself, and the Registry datasource provides access to the inventoried registry data.

Can anyone from Solarwinds tell me if this is a reporting function that you plan to build into the product?

Over the lifespan of my association with the product (almost five years now), I can count on one hand the number of conversations I've had about reconciling domain membership with WSUS-registered clients. I can't speak to whether there would or would not be plans to do it (you should add an item to the Feature Requests forum, though), but in my observation the demand has been minmal.

To be honest its something I would expect from an enterprise patch managing product as standard. To be able to easily audit your environment to ensure all your systems are protected is a basic requirement. There's little point in the rest of the funcitonality if come the time of a pen test it's discovered that a number of machines arn't being managed by WSUS and therefore have missed updates.

Being able to identify machines that are not registered/communicating with the patch management systems is surely a valid need from an organizational standpoint; however, there's also a matter of practicality here. You cannot report on things that aren't there. WSUS does not require domain membership; it's architected to work in workgroup environments just the same. Furthermore, in some organizations, not all domain-member systems are actually patched by WSUS, or even by the same WSUS server. Many organizations have split end-user and datacenter patch management across more than one product (e.g. WSUS and Configuration Manager, or even multiple independent instances of WSUS). Thus, it would be totally inappropriate for the product to assume that membership in a domain implied that those machines should also be registered with WSUS. At some point it becomes a necessity for the individual patch administrator to interpret what should or should not be with respect to what actually is. Patch Manager can report on what is, but cannot possibly interpret rationally what "should be".