I know this can be done, I’m just not smart enough to do it. I’d like a quick and dirty analyses that give me 2 little things, the Computer Name and All Installed Patches on that machine. The KB number and the name of the patch would be super helpful, so would the date installed. This would save me hours of work every month. Oh boy, it would be so sweet if someone can help me with this. I’d be grateful for just Microsoft patches, but if I can get 3rd party patch information, that would be wonderful, but my priority for now if getting the Microsoft patch information. Help, I’m doing so much extra work and such a Analyses would save my life!
If you can give me a quick cut and paste, I’m buying lunch!
Thanks,
I’m not sure I would see much use in that. Between different OSes need different patch KB numbers, patches getting superseded and replaced so quickly…I usually base reports upon what patches are still outstanding. We can do that pretty easily in both Compliance and in Web Reports.
So what do you do in cases where a system is missing the December rollup, but has the January rollup present?
Or (in a case I looked at a few days ago) a system is missing the first January rollup, but has installed the second January rollup that superseded the first a few days after it was published?
I agree with Jason here that the effectiveness of reporting on installed Patches is questionable (vs. what patches are actually needed by a system), but have a look at the following Forum post and see if it helps:
Putting in my two cents… we’ve found servers that have failed to become relevant to new content after customers installed their own security tools that prevented the servers from receiving new information from the main BES server. The client servers were still able to telnet to the main BES server on the defined port, but were not able to receive any updates from the infrastructure. They continued to report in as if all was well. Looking at a report that shows relevant patches only will not shed light on the issue and the server goes unpatched.
Test for that by sending the endpoints a Blank Custom Action. Endpoints that do not reply with Completed are likely having issues getting new content (such as the action you just sent)
This is an interesting scenario, though I expect it to be quite rare.
As brolly33 suggests, one approach would be to send test actions. If they’re not receiving any updates, they would not run the action.
Another might be to proactively monitor the Agents and their site versions. In BES Support, there is an analysis called ‘BES Health Checks Analysis’ which contains a property called “Actionsite Version”. In the case you describe, I’d expect that the actionsite version of the endpoints in question did not match that of the rest of the environment. We could prepare a report that would be able to identify those endpoints that are still reporting in, but have an older actionsite version than expected to highlight such endpoints.
Alternatively, you could create a property that validates the site versions of the Patch (or Compliance) sites on the endpoints to ensure they’re up to date.
If a server fails to sync a specific site, yet is able to sync other sites, would it show the most up to date actionsite version? Or do I need to place watchdog properties on specific site versions, too?
Yes, you’d need to monitor the site versions for each site. I’d consider that a temporary debugging step though, the better fix is to whitelist the directories in whatever security tool you have that is blocking the gathers.
You could also set an analysis to look for the failed gathers in the client logs.