System Center Operations Manager on Microsoft Azure and reporting
Hello Experts,
How are you doing?
Well, we have a SCOM environment on Azure Platform. The infrastructure is comprised of 2 management servers, and about 34 gateway servers (all of the gateway servers are outside the Azure platform, and across multiple domains).
My question can be divided in two scopes:
1- Today the management servers, and the database servers on Azure are shutdown everyday at 6PM, and started at 7AM.
Is there a known problem with daily downtime on SCOM management Servers?
2 - We have a problem with Reports that are not providing correct data, where the Data Warehouse aggregation doesnt seem to be running. Is this related to the fact that the costumer shut's down his environment every day at 6PM and starts at 7AM?
Thank you in advance,
How are you doing?
Well, we have a SCOM environment on Azure Platform. The infrastructure is comprised of 2 management servers, and about 34 gateway servers (all of the gateway servers are outside the Azure platform, and across multiple domains).
My question can be divided in two scopes:
1- Today the management servers, and the database servers on Azure are shutdown everyday at 6PM, and started at 7AM.
Is there a known problem with daily downtime on SCOM management Servers?
2 - We have a problem with Reports that are not providing correct data, where the Data Warehouse aggregation doesnt seem to be running. Is this related to the fact that the costumer shut's down his environment every day at 6PM and starts at 7AM?
Thank you in advance,
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
the intent of the SCOM server is actually kinda os your ops manager looking after the other servers system operations and it goes off only intended maintenance, so leaving it shutoff during that period (and is pretty long) will be missing out any event generated by the herd of systems e.g. like unintended reboots, outages etc.
One common example of behaviour of monitored systems like "dirty" reboots (note Event Collection Rules do not create alerts, so no notifications are send out). http://thoughtsonopsmgr.blogspot.sg/2015/03/dirty-server-shutdown-eventid-41-system.html
But if that is alright and accepted workflow, then the shutdown may be a SOP per se accepted at the ops end. Also during the wee hours is also when the ops team is not really on guards hence system monitoring online to capture any anomalies will help trigger them "awake" if necessary...
As of the reports, it may be attributed if there is any error event recorded under the OpsMgr event log. Like in this case where it has show many times EventID 31552 ("Failed to store data in the Data Warehouse"). This is more of Exchange (http://thoughtsonopsmgr.blogspot.sg/2011/04/eventid-31552-in-opsmgr-event-log-of.html) but the long short is when OPsmgr is down or shutoff you may not even have such errors so it is pretty hard to confirm if such practice ascertain to the false reporting - maybe good to have it not shutdown and assess if the reporting is accurate ... regardless, any tasks involving Datawarehousing can make reporting inaccurate...e.g.
One common example of behaviour of monitored systems like "dirty" reboots (note Event Collection Rules do not create alerts, so no notifications are send out). http://thoughtsonopsmgr.blogspot.sg/2015/03/dirty-server-shutdown-eventid-41-system.html
But if that is alright and accepted workflow, then the shutdown may be a SOP per se accepted at the ops end. Also during the wee hours is also when the ops team is not really on guards hence system monitoring online to capture any anomalies will help trigger them "awake" if necessary...
As of the reports, it may be attributed if there is any error event recorded under the OpsMgr event log. Like in this case where it has show many times EventID 31552 ("Failed to store data in the Data Warehouse"). This is more of Exchange (http://thoughtsonopsmgr.blogspot.sg/2011/04/eventid-31552-in-opsmgr-event-log-of.html) but the long short is when OPsmgr is down or shutoff you may not even have such errors so it is pretty hard to confirm if such practice ascertain to the false reporting - maybe good to have it not shutdown and assess if the reporting is accurate ... regardless, any tasks involving Datawarehousing can make reporting inaccurate...e.g.
This is ‘normal’ behavior because when data is inserted into the Data Warehouse it goes through processes like these:http://thoughtsonopsmgr.blogspot.sg/2011/03/eventid-31552-failed-to-store-data-in.html
The data is written to the staging tables;
The data is processed;
The data is inserted into raw tables;
The data is moved to aggregated tables.
Basically, when the Perfmon Reports are not showing all data, most of the time the data is present in the Data Warehouse, but is not processed completely. Somewhere it is stuck. By removing the cause of it, the Reports will functioning again. Of course, it takes some time for the data being processed (depending on the total amount of data in the DW), but finally, the Reports end up just fine again.
Premium Content
You need an Expert Office subscription to comment.Start Free Trial