Purging non-reporting servers (Configuration Assessment Legacy screens)
I use to find it annoying that, after I removed a server from "Advisor Managed" in SCOM, I then had to go to Advisor and delete it there too. It seems that one of the recent updates changed how that all works, but not necessarily for the better. Some Advisor Managed server were deleted from SCOM without any effort to proactively remove them from Advisor. I just received a "Microsoft System Center Advisor: Summary Update" email identifying them as non-reporting servers. Unfortunately, I don't see a way in the current iteration of Advisor to remove them from Advisor's configuration/inventory. Am I missing something or is this a new bug?
Seth Wanlass
shared this idea
We went one step further and removed the legacy Configuration Assessment solution and the associated screens.
4 comments
-
Lars Villaume Jørgensen
commented
I have a workspace where I get the OMS summary update email with a list of non-reporting servers. Those servers have not been reporting data for 555 days. There are from a connected scom MG that have not been running for eaually long, so my question is why to I see those servers in the summary report?
btw - doing an asteris search in the Work Space returs zero data. I have customers that are a bit annoyed about seeing those servers which they have removed from SCOM. -
You can disable the Weekly Emails too http://blogs.technet.com/b/momteam/archive/2014/07/15/disableweeklyadvisoremails.aspx
See some further conversation around this topic on the MSDN forum https://social.msdn.microsoft.com/Forums/azure/en-US/c8ed680f-9389-48d8-9f92-1fa17bcdd2db/transitioned-to-azure-opinsights-can-we-edit-email-notifications?forum=opinsights
-
For this option with regards to the NEW scenarios, in a sense of de-authorizing direct agents, follow this other idea http://feedback.azure.com/forums/267889-azure-operational-insights/suggestions/6949226-implemented-feature-to-remove-managed-management
-
Hi Seth, we found it annoying too - you shouldn't have to spend a lot of time managing the management system. The group in SCOM is enough, you shouldn't manage this in two places.
The underlying issue is that the old configuration assessment scenario (and the old Advisor service) was built on top of relational databases, and there is a strong presence of 'state' and 'objects' in that system. This means the number of machines was a fixed list which needed to be managed. Annoying, as you say.
But long are gone the days when lifetime of servers was slow - these days, machines come and go, cloud services scale out, agents appear and disappear.... and it's normal.
In this modern hybrid cloud world, you'll see we have based all the new scenarios on the search feature. The presence of a machine (or its absence) should be just inferred from its data being present or not.So, yes, we got rid of the servers page (announced here http://blogs.technet.com/b/momteam/archive/2014/07/25/system-center-advisor-limited-preview-saved-searches-cloud-attach-status-and-usage-and-more.aspx ) and we did it *exactly* to help ease the pain in the direction you are saying. Moreover, the old page was ONLY focused on the old 'configuration assessment' scenario and channel, and had no information about data being sent for the new scenarios.
So we 'steered' that in what we see as the new direction, and now just look at data from a search angle (the daily data usage and all the new intelligence pack's pages use search queries behind the scenes).
Unfortunately, in the relational backend that still powers some of the Configuration Assessment engine and Silverlight screens (and, as you just reported - the alert summary weekly email) still rely on that static list.
As we determine how to evolve this scenario, we'll investigate how to address this.
But in general, we don’t list actual agents anymore. This is intentional: in modern datacenters and clouds, we see machines come and go all the times, and we will tell from data indexed in search if they are reporting or not. We also want to get away from having to manage the list of ‘servers’ in two places: today you already manage the list of servers in Operations Manager Console, and that place is enough. We don’t want to put burden on you with un-necessary housekeeping tasks.
At the end of the day, either Advisor gets the data from those machines, and you see that data, or it doesn’t. But when a machine goes away for good because you de-commission it, you don’t have to go up to the servers page and clean it up in two places, you just remove it from SCOM – its data from the past will still be there, but new data will simply stop flowing, as it is natural.The old Silverlight screens don't think in terms of 'data flow' so you will still see the machines in those for the time being.
In search, given a name of a specific machine you are looking for, this is how you get its most recent time stamp
Computer:"NEB-OM-644561.smx.net" | Sort TimeGenerated desc | Select TimeGenerated | Top 1
or by type
Type:PerfHourly | Measure Max(TimeGenerated) by Computer
Type:Event| Measure Max(TimeGenerated) by Computer
Type:ConfigurationObject | Measure Max(TimeGenerated) by Computeror with an extra 'where' command, would give you ONLY the computers that have reported in the past but whose last data point is older than 24hours
* | Measure Max(TimeGenerated) as LastData by Computer | Where LastData<NOW-24HOURS
Type:Event | Measure Max(TimeGenerated) as LastData by Computer | Where LastData<NOW-24HOURS
and so forth...
Once this idea also gets implemented http://feedback.azure.com/forums/267889-azure-operations-insights/suggestions/6519205-allow-to-create-my-own-tile-bound-to-a-saved-searc it would essentially allow to publish this type of view in your own customized dashboard, if this information is relevant to you and that's what you would like to see for regular triage.