This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Custom Patch Manager Group membership report

I have been DB diving and I've yet to come up with how membership is denoted in the DB. I've found the table with the group names so you'd think they'd be linked somehow via the group name. Anyone make something like this or have an idea where I can look?

  • The Patch Manager Group definitions are not stored in the database.

    They're defined as an XML file in %ProgramFiles%\SolarWinds\Patch Manager\Server\templates\computergroups

  • Thank you. That is unfortunate as we'd like to create a report that would tell us the update status for a Patch Manager group rather than having to select certain machines out of many WSUS groups. Though I believe it can be done this way it'd be a lot easier to target the PM group for this. I've had a feature request opened and will be putting it on the forums as soon as I can.

  • Even if the PM groups were defined in the database, there's no provision for specifying a PM group as an attribute of a computer, or for reporting against PM groups in general. In fact, the only grouping mechanism that does exist for update status reports would be the WSUS Target Group memberships. One way you can approach this, however, is to use a WSUS Target Group to 'clone' the Patch Manager Computer Group, and then run the reports against the WSUS Target Group, because a WSUS client can be long to multiple groups. While WSUS groups are generally used for approval purposes, they also can be used to define reporting groups.

  • I find this the central problem in an otherwise excellent product: the poor integration between the WSUS backend and Patch Manager backend. While I'm sure attempting to crossreference the WSUS database with the PM database would be complicated (though a SQL JOIN comes immediately to mind), this is the kind of integration that I think many sysadmins are looking for in an enterprise patch management application.

    #justsaying

  • I'm somewhat confused by your remark concerning the "poor integration" between WSUS and Patch Manager.

    First, the conversation about reporting by Patch Manager Computer Group has nothing at all to do with WSUS. Reporting in Patch Manager is based upon inventory data collected from two sources: The WSUS database, and the individual clients via WMI. WSUS knows nothing about Patch Manager Computer Groups (it also knows nothing about Active Directory objects, such as OrgUnits) and there is no schema by which to associate a Patch Manager Computer Group member with the data in the WSUS database -- they are completely different data schemas with completely different keys. The only value even common to the two datasets is computer name, but computer name is not a unique field in either dataset.

    Patch Manager Computer Groups were primarily designed as a task management feature, not a reporting attribute, and reporting by PM group is not something we've heard a lot of. And, as noted, it's fairly trivial to create a WSUS Target Group and define those clients in an additional WSUS Target Group, just as you are doing with a Patch Management Computer Group -- in addition, whatever task management purposes that you are using the Patch Manager Computer Group for, can also be targeted to the WSUS Target Group instead. More significantly, the WSUS Target Group is dynamically enumerated at runtime, so as computers are added/removed to that WSUS Target Group, the task handles that seamlessly. If you're using a static list of computers in a Patch Manager Computer Group, you'll need to rebuild that task everytime the list of computers is changed.