Today I was investigating an issue with OpsMgr Agents who where stuck in Maintenance Mode. A big help was this article from David Dixon. We managed to solve the issue but we also wanted to know what caused the issue and I investigated if the RMS HealthService was put in Maintenance Mode accidentally. By the way is not a good thing to put the RMS in Maintenance Mode! I used the next SQL query to find out if the RMS HealthService was put in Maintenance Mode: -- Find if RMS is put in MM single query-- Author: Stefan Stranger-- Date: 19-05-2010USE OperationsManagerDWSELECT     ManagedEntity.DisplayName, MaintenanceModeHistory.*FROM         ManagedEntity INNER JOIN                      MaintenanceMode ON ManagedEntity.ManagedEntityRowId = MaintenanceMode.ManagedEntityRowId INNER JOIN                      MaintenanceModeHistory ON MaintenanceMode.MaintenanceModeRowId = MaintenanceModeHistory.MaintenanceModeRowIdWHERE     (ManagedEntity.FullName = N'Microsoft.SystemCenter.HealthService:rmsservername.contoso.com') Have fun pointing your finger ;-)  

This week I’m having a MP Authoring Workshop from Brian Wren in the UK and one of the modules of this workshop is Discovery. And to my surprise Kevin Holman published a blog post on Basic troubleshooting of discovery script yesterday. It’s a good start but I’ve some more help on troubleshooting a Discovery script. Here are mine (with some help of Brian): Verify that MP has been committed on agent Check agent for eventlog errors Check management server for errors Verify that discovery is running Enable debug events in script Debug script on agent   Step 1. Verify that MP has been committed on agent. How? There are several ways. One of them is looking in the OpsMgr eventlog for EventId 1201. Step 2. Check for agent errors. How? Check for OpsMgr EventId’s like 31876 or 21405 or other Health Service Module source errors. Step 3. Check for management server errors How? Check for OpsMgr EventId’s 10801 Step 4. Verify that discovery is running How? You can look for your discovery script in the C:\Program Files\System Center Operations Manager 2007\Health Service State\ subdirectories with the next command: dir /B /S mycooldiscovery.vbs Did you found it? I hope so;-) More info here. Now you can use Process Monitor from SystInternals to monitor your cscript vb discovery script. For more info on how to use Process Monitor go to Jeevan Bish’s blog. Step 5. Enable debug events in script. How? You can add a debug function to you discovery script that writes info the eventlog using oAPI.LogScriptEvent in your discovery script. For more info on using oAPI.LogScriptEvent take a look at MSDN. Step 6. Debug script on Agent. How? See Kevin’s post on how to do this. You can alslo take a look at Brian Wren’s Demo Store App Management on OpsManJam for an LogDebugEvent Function. ' '================================================================================== ' Sub:        LogDebugEvent ' Purpose:    Logs an informational event to the Operations Manager event log '            only if Debug argument is true '================================================================================== Sub LogDebugEvent(EventNo,Message)     Message = VbCrLf & Message     If bDebug = True Then         Call oAPI.LogScriptEvent(SCRIPT_NAME,EventNo,EVENT_LEVEL_INFO,Message)     End If End Sub More blogposts on MP Authoring after this week of MP Authoring training.

I know there are already quite some other blog posts about OpsMgr Data Warehouse Grooming.  But I was helping a customer with grooming their OpsMgr Data Warehouse Database (OperationsManagerdw) and got some questions. And you may have the same questions but you are afraid to ask ;-)

How can I change the Grooming settings for the OpsMgr Data Warehouse? This cannot be done from within the OpsMgr Console. So what are the options then?

DWdatarp tool Use the Data Warehouse Data Retention Policy (dwdatarp.exe) tool from the MOM team weblog. Tip: if after running the tool you don’t see any results, you may not be dbowner on the OperationsManagerDW database.   You can save the results to a csv, but you need to do some manual stuff in Excel to have a nice formatted overview.   Read the help (dwdatarp /?) for all the options. You can also change the Grooming settings for the OpsMgr Data Warehouse with this tool.

SQL queries You have to use some SQL queries and run those on the operationsmanagerdw database in SQL Server Management Studio.   To view the Current OpsMgr Data Warehouse queries I use the next SQL queries from several sources.

--Current Grooming Settings USE OperationsManagerDW SELECT AggregationIntervalDurationMinutes, BuildAggregationStoredProcedureName, GroomStoredProcedureName, MaxDataAgeDays, GroomingIntervalMinutes, MaxRowsToGroom FROM StandardDatasetAggregation --Last Grooming Time USE OperationsManagerDW select min(datetime) as MinDate, max(datetime) as MaxDate, datediff(d,min(datetime),max(datetime)) AS NoOfDaysInDataSet from Perf.vPerfHourly --To view the number of days of total data of each type in the DW: USE OperationsManagerDW SELECT DATEDIFF(d, MIN(DWCreatedDateTime), GETDATE()) AS [Current Alert] FROM Alert.vAlert SELECT DATEDIFF(d, MIN(DateTime), GETDATE()) AS [Current Event] FROM Event.vEvent SELECT DATEDIFF(d, MIN(DateTime), GETDATE()) AS [Current Perf Raw] FROM Perf.vPerfRaw SELECT DATEDIFF(d, MIN(DateTime), GETDATE()) AS [Current Perf Hourly] FROM Perf.vPerfHourly SELECT DATEDIFF(d, MIN(DateTime), GETDATE()) AS [Current Perf Daily] FROM Perf.vPerfDaily SELECT DATEDIFF(d, MIN(DateTime), GETDATE()) AS [Current State Raw] FROM State.vStateRaw SELECT DATEDIFF(d, MIN(DateTime), GETDATE()) AS [Current State Hourly] FROM State.vStateHourly SELECT DATEDIFF(d, MIN(DateTime), GETDATE()) AS [Current State Daily] FROM State.vStateDaily --To view the oldest and newest recorded timestamps of each data type in the DW: USE OperationsManagerDW select min(DateTime) AS [Oldest Event Date] from Event.vEvent select max(DateTime) AS [Newest Event Date] from Event.vEvent select min(DateTime) AS [Oldest Perf Date]from Perf.vPerfRaw select max(DateTime) AS [Newest Perf Date]from Perf.vPerfRaw select min(DWCreatedDateTime) AS [Oldest Alert Date] from Alert.vAlert select max(DWCreatedDateTime) AS [Newest Alert Date] from Alert.vAlert --Which Tables used the most space USE OperationsManagerDW SELECT so.name, 8 * Sum(CASE WHEN si.indid IN (0, 1) THEN si.reserved END) AS data_kb, Coalesce(8 * Sum(CASE WHEN si.indid NOT IN (0, 1, 255) THEN si.reserved END), 0) AS index_kb, Coalesce(8 * Sum(CASE WHEN si.indid IN (255) THEN si.reserved END), 0) AS blob_kb FROM dbo.sysobjects AS so JOIN dbo.sysindexes AS si ON (si.id = so.id) WHERE 'U' = so.type GROUP BY so.name  ORDER BY data_kb DESCIf you look at results of the first two queries (current grooming settings and last grooming time)   Another interesting query is the “Which Tables used the most space” query. You can run this query before and after changing the grooming settings to see if the grooming had any effect. If you want to change the Grooming settings you can use the next queries. N.B. Change to the values you want to have your Grooming settings configured!!

-- From http://ops-mgr.spaces.live.com/blog/cns!3D3B8489FCAA9B51!176.entry -- Alert Data: USE OperationsManagerDW UPDATE StandardDatasetAggregation SET MaxDataAgeDays = 100 WHERE GroomStoredProcedureName = 'AlertGroom' --Event Data: USE OperationsManagerDW UPDATE StandardDatasetAggregation SET MaxDataAgeDays = 40 WHERE GroomStoredProcedureName = 'EventGroom' --Performance Data: USE OperationsManagerDW UPDATE StandardDatasetAggregation SET MaxDataAgeDays = 100 WHERE GroomStoredProcedureName = 'PerformanceGroom' AND AggregationIntervalDurationMinutes = '60' USE OperationsManagerDW UPDATE StandardDatasetAggregation SET MaxDataAgeDays = 200 WHERE GroomStoredProcedureName = 'PerformanceGroom' AND AggregationIntervalDurationMinutes = '1440' --State Data: USE OperationsManagerDW UPDATE StandardDatasetAggregation SET MaxDataAgeDays = 40 WHERE GroomStoredProcedureName = 'StateGroom' AND MaxDataAgeDays = 180 USE OperationsManagerDW UPDATE StandardDatasetAggregation SET MaxDataAgeDays = 100 WHERE GroomStoredProcedureName = 'StateGroom' AND AggregationIntervalDurationMinutes = '60' USE OperationsManagerDW UPDATE StandardDatasetAggregation SET MaxDataAgeDays = 200 WHERE GroomStoredProcedureName = 'StateGroom' AND AggregationIntervalDurationMinutes = '1440' How can I see if Grooming has worked? You can check if Grooming has worked after changing the Grooming settings by looking at the dwdatarp tool results or by running some SQL queries. Tip: save the results from the dwdatarp tool or SQL queries before and after changing the grooming settings to compare them. If you have used the dwdatarp tool for saving the before and after grooming results you can have a look at the columns Current Size and Current Row Count if they changed after changing the grooming settings.      If you like to use SQL you can run the “Which Tables used the most space” sql query to look if those have changed after changing the grooming settings. It’s also important to look at the current size and free space of the operationsmanagerdw before starting to groom.
Why don’t my database files shrink after grooming? That’s another question people often ask, and that is because the SQL DB files are static – they are manually sized. You can check your autogrow settings for the OperationsManagerDW with the Microsoft SQL Server Management Studio. For the OperationsManager Database Autogrow is default disabled and for the OperationsManagerDW the default setting for Autogrow is enabled. If you look at the Autoshrink setting for the OperationsManagerDW you can see it’s disabled. That’s why the database files won’t shrink after grooming has taken place. Please keep in mind that we don’t support/recommend EVER shrinking a DB file for OpsMgr. It causes fragmentation issues. The only thing that will change (shrink) after grooming is the used space in the database. You can check the used space for a database with the Disk Usage Report in Microsoft SQL Server Management Studio. But, sometimes shrinking the database is the only option left if you don’t have any space left… Disclaimer Please be very careful when changing your grooming settings, you can loose data ;-) Posts in this blog are provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified in the Terms of Use Links to other blog posts about Grooming:

Modifying grooming settings for the OpsMgr databases Data Warehouse Data Retention Policy (dwdatarp.exe) Changing the data retention in the OpsMgr datawarehouse

I know there are already quite some other blog posts about OpsMgr Data Warehouse Grooming.  But I was helping a customer with grooming their OpsMgr Data Warehouse Database (OperationsManagerdw) and got some questions. And you may have the same questions but you are afraid to ask ;-)

How can I change the Grooming settings for the OpsMgr Data Warehouse? This cannot be done from within the OpsMgr Console. So what are the options then?

DWdatarp tool Use the Data Warehouse Data Retention Policy (dwdatarp.exe) tool from the MOM team weblog. Tip: if after running the tool you don’t see any results, you may not be dbowner on the OperationsManagerDW database.   You can save the results to a csv, but you need to do some manual stuff in Excel to have a nice formatted overview.   Read the help (dwdatarp /?) for all the options. You can also change the Grooming settings for the OpsMgr Data Warehouse with this tool.

SQL queries You have to use some SQL queries and run those on the operationsmanagerdw database in SQL Server Management Studio.   To view the Current OpsMgr Data Warehouse queries I use the next SQL queries from several sources.

--Current Grooming Settings USE OperationsManagerDW SELECT AggregationIntervalDurationMinutes, BuildAggregationStoredProcedureName, GroomStoredProcedureName, MaxDataAgeDays, GroomingIntervalMinutes, MaxRowsToGroom FROM StandardDatasetAggregation --Last Grooming Time USE OperationsManagerDW select min(datetime) as MinDate, max(datetime) as MaxDate, datediff(d,min(datetime),max(datetime)) AS NoOfDaysInDataSet from Perf.vPerfHourly --To view the number of days of total data of each type in the DW: USE OperationsManagerDW SELECT DATEDIFF(d, MIN(DWCreatedDateTime), GETDATE()) AS [Current Alert] FROM Alert.vAlert SELECT DATEDIFF(d, MIN(DateTime), GETDATE()) AS [Current Event] FROM Event.vEvent SELECT DATEDIFF(d, MIN(DateTime), GETDATE()) AS [Current Perf Raw] FROM Perf.vPerfRaw SELECT DATEDIFF(d, MIN(DateTime), GETDATE()) AS [Current Perf Hourly] FROM Perf.vPerfHourly SELECT DATEDIFF(d, MIN(DateTime), GETDATE()) AS [Current Perf Daily] FROM Perf.vPerfDaily SELECT DATEDIFF(d, MIN(DateTime), GETDATE()) AS [Current State Raw] FROM State.vStateRaw SELECT DATEDIFF(d, MIN(DateTime), GETDATE()) AS [Current State Hourly] FROM State.vStateHourly SELECT DATEDIFF(d, MIN(DateTime), GETDATE()) AS [Current State Daily] FROM State.vStateDaily --To view the oldest and newest recorded timestamps of each data type in the DW: USE OperationsManagerDW select min(DateTime) AS [Oldest Event Date] from Event.vEvent select max(DateTime) AS [Newest Event Date] from Event.vEvent select min(DateTime) AS [Oldest Perf Date]from Perf.vPerfRaw select max(DateTime) AS [Newest Perf Date]from Perf.vPerfRaw select min(DWCreatedDateTime) AS [Oldest Alert Date] from Alert.vAlert select max(DWCreatedDateTime) AS [Newest Alert Date] from Alert.vAlert --Which Tables used the most space USE OperationsManagerDW SELECT so.name, 8 * Sum(CASE WHEN si.indid IN (0, 1) THEN si.reserved END) AS data_kb, Coalesce(8 * Sum(CASE WHEN si.indid NOT IN (0, 1, 255) THEN si.reserved END), 0) AS index_kb, Coalesce(8 * Sum(CASE WHEN si.indid IN (255) THEN si.reserved END), 0) AS blob_kb FROM dbo.sysobjects AS so JOIN dbo.sysindexes AS si ON (si.id = so.id) WHERE 'U' = so.type GROUP BY so.name  ORDER BY data_kb DESCIf you look at results of the first two queries (current grooming settings and last grooming time)   Another interesting query is the “Which Tables used the most space” query. You can run this query before and after changing the grooming settings to see if the grooming had any effect. If you want to change the Grooming settings you can use the next queries. N.B. Change to the values you want to have your Grooming settings configured!!

-- From http://ops-mgr.spaces.live.com/blog/cns!3D3B8489FCAA9B51!176.entry -- Alert Data: USE OperationsManagerDW UPDATE StandardDatasetAggregation SET MaxDataAgeDays = 100 WHERE GroomStoredProcedureName = 'AlertGroom' --Event Data: USE OperationsManagerDW UPDATE StandardDatasetAggregation SET MaxDataAgeDays = 40 WHERE GroomStoredProcedureName = 'EventGroom' --Performance Data: USE OperationsManagerDW UPDATE StandardDatasetAggregation SET MaxDataAgeDays = 100 WHERE GroomStoredProcedureName = 'PerformanceGroom' AND AggregationIntervalDurationMinutes = '60' USE OperationsManagerDW UPDATE StandardDatasetAggregation SET MaxDataAgeDays = 200 WHERE GroomStoredProcedureName = 'PerformanceGroom' AND AggregationIntervalDurationMinutes = '1440' --State Data: USE OperationsManagerDW UPDATE StandardDatasetAggregation SET MaxDataAgeDays = 40 WHERE GroomStoredProcedureName = 'StateGroom' AND MaxDataAgeDays = 180 USE OperationsManagerDW UPDATE StandardDatasetAggregation SET MaxDataAgeDays = 100 WHERE GroomStoredProcedureName = 'StateGroom' AND AggregationIntervalDurationMinutes = '60' USE OperationsManagerDW UPDATE StandardDatasetAggregation SET MaxDataAgeDays = 200 WHERE GroomStoredProcedureName = 'StateGroom' AND AggregationIntervalDurationMinutes = '1440' How can I see if Grooming has worked? You can check if Grooming has worked after changing the Grooming settings by looking at the dwdatarp tool results or by running some SQL queries. Tip: save the results from the dwdatarp tool or SQL queries before and after changing the grooming settings to compare them. If you have used the dwdatarp tool for saving the before and after grooming results you can have a look at the columns Current Size and Current Row Count if they changed after changing the grooming settings.      If you like to use SQL you can run the “Which Tables used the most space” sql query to look if those have changed after changing the grooming settings. It’s also important to look at the current size and free space of the operationsmanagerdw before starting to groom.
Why don’t my database files shrink after grooming? That’s another question people often ask, and that is because the SQL DB files are static – they are manually sized. You can check your autogrow settings for the OperationsManagerDW with the Microsoft SQL Server Management Studio. For the OperationsManager Database Autogrow is default disabled and for the OperationsManagerDW the default setting for Autogrow is enabled. If you look at the Autoshrink setting for the OperationsManagerDW you can see it’s disabled. That’s why the database files won’t shrink after grooming has taken place. Please keep in mind that we don’t support/recommend EVER shrinking a DB file for OpsMgr. It causes fragmentation issues. The only thing that will change (shrink) after grooming is the used space in the database. You can check the used space for a database with the Disk Usage Report in Microsoft SQL Server Management Studio. But, sometimes shrinking the database is the only option left if you don’t have any space left… Disclaimer Please be very careful when changing your grooming settings, you can loose data ;-) Posts in this blog are provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified in the Terms of Use Links to other blog posts about Grooming:

Modifying grooming settings for the OpsMgr databases Data Warehouse Data Retention Policy (dwdatarp.exe) Changing the data retention in the OpsMgr datawarehouse

Source: Microsoft Technet “Memory is often the source of performance problems, and you should always rule out memory problems before examining other areas of the system. Systems use both physical and virtual memory. To rule out memory problems with a system, you should configure application performance, memory usage, and data throughput settings, and then monitor the server’s memory usage to check for problems. Application performance and memory usage settings determine how system resources are allocated. In most cases you want to give the operating system and background applications the lion’s share of resources. This is especially true for Active Directory, file, print, and network and communications servers. On the other hand, for application, database, and streaming media servers, you’ll want to give the programs the server is running the most resources. Here’s an overview of counters that you’ll want to track to uncover memory, caching, and virtual memory (paging) bottlenecks.” Read more on source.

Source: Microsoft Technet “Memory is often the source of performance problems, and you should always rule out memory problems before examining other areas of the system. Systems use both physical and virtual memory. To rule out memory problems with a system, you should configure application performance, memory usage, and data throughput settings, and then monitor the server’s memory usage to check for problems. Application performance and memory usage settings determine how system resources are allocated. In most cases you want to give the operating system and background applications the lion’s share of resources. This is especially true for Active Directory, file, print, and network and communications servers. On the other hand, for application, database, and streaming media servers, you’ll want to give the programs the server is running the most resources. Here’s an overview of counters that you’ll want to track to uncover memory, caching, and virtual memory (paging) bottlenecks.” Read more on source.

Source: System Center Forum Today I was watching the latest recording of the January 2009 SCUG Meeting and to my surprise I was seeing some info about Debugging Scripts which I blogged about some time ago.    So if you didn’t had time to join the livemeeting go download the recording. Below are the starting times in the video for each speaker so you can fast forward to whatever you like. 1:05 - Savision Live Maps v3 Demo (Dennis Rietvink) 51:46 - Custom Scripting and Script Debugging in OpsMgr 2007 (Pete Zerger) 1:19:45 - Top MS Support Issues for Operations Manager 2007 (Steve Rachui) 

SQL Nexus is a tool that helps you identify the root cause of SQL Server performance issues. It loads and analyzes performance data collected by SQLDiag and PSSDiag. It can dramatically reduce the amount of time you spend manually analyzing data. With the RML Utilities you can answer questions such as the following:

Which application, database or login is consuming the most resources, and which queries are responsible for that. Whether there were any plan changes for a batch during the time when the trace was captured and how each of those plans performed. What queries are running slower in today's data as compared to a previous set of data. If you think you have OpsMgr SQL Server performance issues maybe SQL Nexus together with SQLDiag and RML Utilities can help with performance tuning and analysis. Steps:

Download SQLNexus , RML Utilities for SQL Server, Microsoft Report Viewer 2008 Redistributable and PerfStatsScript from websites. Install Microsoft Report Viewer 2008 Redistributable
Install RML Utilities for SQL Server.
Install\Run SQLNexus by running sqlnexus.exe in folder where you extracted the zipfile. Connect to SQL server
After starting SQLNexus a new database sqlnexus is created.
Create a folder SQLDiag and Unzip SQLDiag script.zip file to folder. Open StartSQLDiagTrace.cmd and change configuration as needed.
Give SQL server service account full control on D:\SQLDIAG folder if you aren’t using the local system account. Start D:\SQLDiag\StartSQLDiagTrace.cmd. This script registers sqldiag as a service and starts the service with a template (both profiler and perfmon trace) Output is being dumped in D:\SQLDiag\SQLDiagOutput folder Remark: On a busy system quite some data can be collected!!!!. Watch your freespace carefully! Customer experience on opsmgr environment with 2500 agents 20GB of data is collected in 10 minutes. Have it running for 10 mins and then stop the SQLDiag service. Stop SQLDiag with StopSQLDiagTrace.cmd script.
Importing trace data by selecting File\Import in SQLNexus tool. Select Options and select BLG Blaster on Enabled and Drop Current DB before Importing.   Remark: If you are getting the Message PerfStatsAnalysis.sql doesn’t exist message. Just copy the PerfStatsAnalyis.sql file to the requested folder.
The Next Reports are available:

Via SQLNexus

Bottleneck Analysis Blocking and Resource Wait Statistics Performance Overview with subreports

Resource Consumption Unique Batch TopN Interesting Events

I want to thank David Scheltens for showing me how to use SQL Nexus and creating the PerfStatsScripts. References: SQLNexus http://www.codeplex.com/sqlnexus SQLDiag (installed default with SQL2005 and SQL2008) http://msdn.microsoft.com/en-us/library/ms162833(SQL.90).aspx PSSDiag (to use with SQL2000) http://msdn.microsoft.com/en-us/library/aa175399(SQL.80).aspx RML Utilities http://blogs.msdn.com/psssql/archive/2007/12/18/rml-utilities-for-microsoft-sql-server-released.aspx

One of the great advantages of OpsMgr 2007 against MOM 2005 is that you can easily test OpsMgr 2007 scripts from the command prompt. Just go to the C:\Program Files\System Center Operations Manager 2007\Health Service State and open a command prompt. Type DIR /B /B *.vbs and you find all the scripts that are used on that specific agent. And if you have found your script to debug you can easily run it with cscript and see what happens. But what if a scripts needs some parameters? Most of the time these are GUIDS and how do you find the right parameters? A colleague of mine Dirk van Coeverden found an easy way to find these parameters. Let’s Look at the Operational Database Space Free (%) Monitor. This Monitor uses a vbscript GetOpsMgrDBPercentageFreeSpace.vbs which needs two parameters to work So if we want to debug this script we need two parameters; DatabaseServerName and DatabaseName. How do we find those parameters? First we need to go to the Authoring Pane in the Opsmgr Console and find the monitor which runs this script. Then we change the default timeout of the script to something smaller then the default with an override. Say 1 second. Now we have to wait for this monitor to run again and hopefully see that the script timeouts because of the lower timeout settings. And if the script runs longer than the timeout period an event 21402 – Script ran longer than the timeout period will be created. Now you can debug the script from the commandprompt with the correct parameters. Don’t forget to remove the overrides.

I saw a question of SQLBatman about Operations Manager Authoring. Here my attempt to answer those questions. Q: Referenced MP could not be found A: Search on your (Root) Management Server for *.mp files and copy all these files to one directory, like c:\Mps.  If your Authoring Console is on another machine then your (Root) Management Server copy these files to this machine. Add this directory to the References in Options Q: Create a custom attribute to the SQL DB Engine A: I only found that there are only two WMI Providers for Microsoft SQL Server 2005: WMI Provider for Configuration Management and WMI Provider for Server Events.     Source: Microsoft Windows PowerShell and SQL Server 2005 WMI Providers – Part 1 and Microsoft Windows PowerShell and SQL Server 2005 WMI Providers - Part 2     I’ve to look for more info about this question, but I at the moment I don’t have much time. But I’ll try to look into this soon.

After trying to open Reporting from the Ops Console I got the next error:

I checked if Reporting was configured correctly with the Configure Report Server tool.

Checked if SharePoint Integration was enabled. And that wasn’t the case. Tried to open ReportServer in a Browser.

Restarted the SQL Server Reporting Services (MSSQLSERVER) service. But still no luck. Opened Configure Report Server tool again and applied the Default Settings for the Report Server Virtual Directory and Report Manager Virtual Directory.

Re-entered the correct password for the Windows Service Identity and clicked Apply.

Now the Web Service Identity failed.

Changed the Web Service Identity for the Report Server and Report Manager from the DefaultAppPool to ReportServer. After the refresh the ASP.NET Service Account changed automatically from NT Authority\NetworkService to CONTOSO\OM_DRA.

Clicked Apply and did a Refresh and that solved it.

Source: SMS&MOM J.C. Hornbeck published an article from Lenny Wile on the Health of the Root Management Server is in a Grey “Not Monitored” State a couple of days ago. And you know what? I was facing the same issue after migrating my VM’s to Hyper-V yesterday.     But I also saw the next eventlogs:     Resetted the passwords for above users and restarted the  Health Service.   And the RMS was Healthy again. Ok not completely Healthy, but not grey anymore ;-)