Published
Feb 16 2019 03:52 AM
1,582
Views
First published on TECHNET on Sep 20, 2016
Microsoft System Center Operations Manager, along with the Service Manager management packs, provides an excellent monitoring platform for Service Manager. Many important pieces that are vital to Service Manager health can be monitored, including:
…and much more. The full list of rules and monitors can be found in the Service Manager Management Pack Guide that you can download along with the Management Packs, and I would encourage you to read that guide thoroughly before deploying the Management Packs and bringing your Service Manager monitoring online.
One key note in the guide is where it says " This management pack requires agentless monitoring …" It's been a while since the guide was released, and that, along with the fact that the SP1 release for System Center 2012 introduced a Control Panel applet for the Microsoft Monitoring Agent (HealthService), has contributed to some confusion over Agent versus Agentless monitoring. This post addresses one of the possible drawbacks of using Agent-based monitoring and then receiving the following events in your Service Manager management server's Operations Manager Event log:
Event ID 6024
LaunchRestartHealthService.js : Launching Restart Health Service. Health Service exceeded Process\Handle Count or Private Bytes threshhold.
Event ID 6060
RestartHealthService.js : Restarting Health Service. Error: Failed to Terminate Health Service
Event ID 6062
RestartHealthService.js : Restarting Health Service. Service successfully restarted.
For more information on this, see https://blogs.technet.microsoft.com/omx/2013/10/17/health-service-restarts-on-service-manager-se... .
In Service Manager, the Microsoft Monitoring Agent's primary role is managing all the Service Manager workflows, including workflow subscriptions, group calculations, connectors, configuration, etc. Adding the Service Manger HealthService as an Operations Manager agent can result in a negative impact on the Service Manger workflows when the Operations Manager workflows run on their configured schedules.
So how do you find out whether you’re agent managed or not, and how do you switch?
First, check in Control Panel on your Service Manager Workflow Management server. If you have anything listed under Management Groups you're probably Agent managed:
You can also check in Operations Manager. Open the console and navigate to Administration –> Device Management –> Agent Managed and search for your Service Manager Workflow Management server. If it's in there, you're definitely Agent managed.
The good news is that it's easy to switch. First, clear everything from Control Panel on your Service Manager Workflow Management server, including the Automatically update management group assignments from AD DS check box. Next, select the Service Manager Workflow Management server from Operations Manager and click Delete from the task pane.
Give everything a few minutes to settle in, and then from Operations Manager, right-click Device Management and open the Discovery Wizard :
At this point I'm going to assume you're familiar with Operations Manager and skip to the important part; the Select Objects to Manage page. Select your Service Manager Workflow Management server from here, then at the bottom of the wizard dialog, choose Agentless from the Management Mode: dropdown list:
After you choose Agentless, you'll have the option to choose your Proxy Agent:
The proxy agent should be an Operations Manager Management Server or another computer in your environment (not one running Service Manager!) that is running the Microsoft Monitoring Agent and reports to the desired Operations Manager management group. The MP deployment guide has more details about what is required of your proxy agent.
One more thing before closing: The MP deployment guide section on the Service Manager Database Account profile in Operations Manager has an omission. One of the rules uses a function within SQL which requires Execute permissions in SQL. Instead of choosing the db_datareader role in SQL, you can choose something in SQL that includes Execute permissions, or much better, just give your data reader account permission to execute that single object in SQL.
Start with the Database User you created. Select the user and then Properties :
Select the Securables page and then click Search. You will get the dialog below. Select Specific Objects, then click OK.
From Select Objects, click Object Types, and then click OK, then select Scalar functions, and click OK.
Click, Browse and locate the dbo.fn_GetEntityChangeLogGroomingWatermark function, select it, and click OK.
Note that after you click OK, you have the option to check names. You can use this if you wish to be sure you have the correct name. When done, click OK again.
Give the user Grant -> Execute permissions on the object, then click OK and you're done.
You can confirm that you set the desired permissions by opening SQL Management Studio as the user you created for DB Reader. Expand the Functions Folder under the Database, and then expand Scalar Functions. You should only see the one for which you granted permissions. You can also test by running this query using the user account for which you granted permissions.
SELECT dbo.fn_GetEntityChangeLogGroomingWatermark() AS HighWaterMark
Now, you're agentless!
REMINDER : Be sure you go through the MP deployment guide to get the correct security configurations for all the pieces of this monitoring solution.
The good news is that there's a solution for monitoring your Service Manager environment, and you probably already have it: Microsoft System Center Operations Manager. Go forth and monitor, and go agentless, this will keep you informed of many known issues in Service Manager and help keep your HealthService healthy.
Scott Walker , Senior Support Escalation Engineer
Microsoft Enterprise Cloud Group
Microsoft System Center Operations Manager, along with the Service Manager management packs, provides an excellent monitoring platform for Service Manager. Many important pieces that are vital to Service Manager health can be monitored, including:
- Checking SQL Server to be sure the Broker Service is enabled
- Checking the Service Manager Grooming History to be sure cleanup of the CMDB is taking place
- Checking workflows for problems
- Checking MPS sync for failures
…and much more. The full list of rules and monitors can be found in the Service Manager Management Pack Guide that you can download along with the Management Packs, and I would encourage you to read that guide thoroughly before deploying the Management Packs and bringing your Service Manager monitoring online.
One key note in the guide is where it says " This management pack requires agentless monitoring …" It's been a while since the guide was released, and that, along with the fact that the SP1 release for System Center 2012 introduced a Control Panel applet for the Microsoft Monitoring Agent (HealthService), has contributed to some confusion over Agent versus Agentless monitoring. This post addresses one of the possible drawbacks of using Agent-based monitoring and then receiving the following events in your Service Manager management server's Operations Manager Event log:
Event ID 6024
LaunchRestartHealthService.js : Launching Restart Health Service. Health Service exceeded Process\Handle Count or Private Bytes threshhold.
Event ID 6060
RestartHealthService.js : Restarting Health Service. Error: Failed to Terminate Health Service
Event ID 6062
RestartHealthService.js : Restarting Health Service. Service successfully restarted.
For more information on this, see https://blogs.technet.microsoft.com/omx/2013/10/17/health-service-restarts-on-service-manager-se... .
In Service Manager, the Microsoft Monitoring Agent's primary role is managing all the Service Manager workflows, including workflow subscriptions, group calculations, connectors, configuration, etc. Adding the Service Manger HealthService as an Operations Manager agent can result in a negative impact on the Service Manger workflows when the Operations Manager workflows run on their configured schedules.
So how do you find out whether you’re agent managed or not, and how do you switch?
First, check in Control Panel on your Service Manager Workflow Management server. If you have anything listed under Management Groups you're probably Agent managed:
You can also check in Operations Manager. Open the console and navigate to Administration –> Device Management –> Agent Managed and search for your Service Manager Workflow Management server. If it's in there, you're definitely Agent managed.
The good news is that it's easy to switch. First, clear everything from Control Panel on your Service Manager Workflow Management server, including the Automatically update management group assignments from AD DS check box. Next, select the Service Manager Workflow Management server from Operations Manager and click Delete from the task pane.
Give everything a few minutes to settle in, and then from Operations Manager, right-click Device Management and open the Discovery Wizard :
At this point I'm going to assume you're familiar with Operations Manager and skip to the important part; the Select Objects to Manage page. Select your Service Manager Workflow Management server from here, then at the bottom of the wizard dialog, choose Agentless from the Management Mode: dropdown list:
After you choose Agentless, you'll have the option to choose your Proxy Agent:
The proxy agent should be an Operations Manager Management Server or another computer in your environment (not one running Service Manager!) that is running the Microsoft Monitoring Agent and reports to the desired Operations Manager management group. The MP deployment guide has more details about what is required of your proxy agent.
One more thing before closing: The MP deployment guide section on the Service Manager Database Account profile in Operations Manager has an omission. One of the rules uses a function within SQL which requires Execute permissions in SQL. Instead of choosing the db_datareader role in SQL, you can choose something in SQL that includes Execute permissions, or much better, just give your data reader account permission to execute that single object in SQL.
Start with the Database User you created. Select the user and then Properties :
Select the Securables page and then click Search. You will get the dialog below. Select Specific Objects, then click OK.
From Select Objects, click Object Types, and then click OK, then select Scalar functions, and click OK.
Click, Browse and locate the dbo.fn_GetEntityChangeLogGroomingWatermark function, select it, and click OK.
Note that after you click OK, you have the option to check names. You can use this if you wish to be sure you have the correct name. When done, click OK again.
Give the user Grant -> Execute permissions on the object, then click OK and you're done.
You can confirm that you set the desired permissions by opening SQL Management Studio as the user you created for DB Reader. Expand the Functions Folder under the Database, and then expand Scalar Functions. You should only see the one for which you granted permissions. You can also test by running this query using the user account for which you granted permissions.
SELECT dbo.fn_GetEntityChangeLogGroomingWatermark() AS HighWaterMark
Now, you're agentless!
REMINDER : Be sure you go through the MP deployment guide to get the correct security configurations for all the pieces of this monitoring solution.
The good news is that there's a solution for monitoring your Service Manager environment, and you probably already have it: Microsoft System Center Operations Manager. Go forth and monitor, and go agentless, this will keep you informed of many known issues in Service Manager and help keep your HealthService healthy.
Scott Walker , Senior Support Escalation Engineer
Microsoft Enterprise Cloud Group