-->![Microsoft System Center 2012 R2 [10-17-2013] Microsoft System Center 2012 R2 [10-17-2013]](/uploads/1/2/5/8/125845473/785462928.jpg)
System Requirements for System Center 2012 R2 Microsoft Corporation Published: July 14, 2014 Authors Anat Kerry, Bill Anderson, Bruce Hamilton, Byron Ricks, Curtis Love, John Downing, and Rayne. This is a summary article that describes the components that are updated in Update Rollup 4 for Microsoft System Center 2012 R2. Additionally, this article contains download links and links to component articles that provide more information about the issues that are resolved in this update.
Applies to: Configuration Manager (current branch)
The Configuration Manager tools include client-based and server-based tools. Use these tools to help support and troubleshoot your Configuration Manager infrastructure.
Starting in Configuration Manager version 1806, these tools are included in the
CD.LatestSMSSETUPTools
folder on the site server. No further installation is required. Use these versions of the tools with Configuration Manager version 1806 and later.All Windows operating systems listed as supported clients in Supported operating systems for clients and devices are supported for use with these tools.
Note
The System Center 2012 R2 Configuration Manager Toolkit is still available from the Microsoft Download Center. For Configuration Manager version 1806 and later, use the versions of the tools in the CD.Latest folder on the site server. Some tools were formerly in the toolkit but not included in version 1806. These legacy tools are no longer supported.
Client tools
- CMTrace: View, monitor, and analyze Configuration Manager log files
- Client Spy: Troubleshoot issues related to software distribution, inventory, and metering
- Deployment Monitoring Tool: Troubleshoot applications, updates, and baseline deployments
- Policy Spy: View policy assignments
- Power Viewer Tool: View status of power management feature
- Send Schedule Tool: Trigger schedules and evaluations of configuration baselines
Note
The ClientTools folder also includes the file Microsoft.Diagnostics.Tracing.EventSource.dll. Several client tools require this library. You can't directly use it.
Server tools
- DP Job Queue Manager: Troubleshoots content distribution jobs to distribution points
- Collection Evaluation Viewer: View collection evaluation details
- Content Library Explorer: View contents of the content library single instance store
- Content Library Transfer: Transfers content library between drives
- Content Ownership Tool: Changes ownership of orphaned packages. These packages exist in the site without an owning site server.
- Role-based Administration and Auditing Tool: Helps administrators audit roles configuration
- Run Meter Summarization Tool: Run metering summarization task and analyze metering data
Note
The ServerTools folder also includes the following files:
- AdminUI.WqlQueryEngine.dll
- Microsoft.ConfigurationManagement.ManagementProvider.dll
- Microsoft.Diagnostics.Tracing.EventSource.dll
Several server tools require these libraries. You can't directly use them.
Other tools and toolkits
- Support Center: Gather information from clients for easier analysis when troubleshooting.Starting in version 1906, OneTrace is a new log viewer with Support Center. It works similarly to CMTrace, with improvements. For more information, see Support Center OneTrace.
- Extend and migrate on-premises site to Microsoft Azure: Helps you to programmatically create Azure virtual machines (VMs) for Configuration Manager.
- Content library cleanup tool: Use ContentLibraryCleanup.exe in
CD.LatestSMSSETUPTOOLSContentLibraryCleanup
to remove orphaned content from a distribution point. - Hierarchy Maintenance Tool: Use Preinst.exe in the
<SiteServerName>SMS_<SiteCode>binX6400000409
shared folder on the site server to pass commands to the hierarchy manager component. - Update reset tool: Use CMUpdateReset.exe in
CD.LatestSMSSETUPTOOLSCMUpdateReset
to fix issues when in-console updates have problems downloading or replicating. - Service Connection Tool: Use ServiceConnectionTool.exe in
CD.LatestSMSSETUPTOOLSServiceConnectionTool
to keep your site up-to-date when your service connection point is offline. - Microsoft Deployment Toolkit (MDT): A collection of tools, processes, and guidance for automating desktop and server OS deployments.
- System Center Updates Publisher (SCUP): A stand-alone tool to manage and import custom software updates.
- Security Content Automation Protocol (SCAP) extensions: Analyze and assess your environment for compliance with NIST baselines.
- Package Conversion Manager: Convert legacy packages into applications.
With the release of System Center Service Manager (SCSM) 2012 SP1 a SCOM agent was added to the SCSM management servers. This is a very welcomed addition as many management packs do not support agentless monitoring, leaving the SCSM management servers poorly monitored.
However, there is a risk added. In the Microsoft.SystemCenter.2007 Management Pack (Friendly Name: Microsoft System Center Core Management Pack, English Display String: System Center Core Monitoring) there is a monitor that watches to see if the health service and its related processes are taking up too much memory. It has a recovery task to restart the SCOM agent if it is taking too much memory.
You will know you are encountering the issue if you see any of these events in the Operations Manager event log on your SCSM servers:
Log Name: Operations Manager
Source: Health Service Script
Date: 10/17/2013 6:48:59 PM
Event ID: 6024
Task Category: None
Level: Warning
Keywords: Classic
User: N/A
Computer: aaa.bbb.com
Description:
LaunchRestartHealthService.js : Launching Restart Health Service. Health Service exceeded ProcessHandle Count or Private Bytes threshhold.
Source: Health Service Script
Date: 10/17/2013 6:48:59 PM
Event ID: 6024
Task Category: None
Level: Warning
Keywords: Classic
User: N/A
Computer: aaa.bbb.com
Description:
LaunchRestartHealthService.js : Launching Restart Health Service. Health Service exceeded ProcessHandle Count or Private Bytes threshhold.
Log Name: Operations Manager
Source: Health Service Script
Date: 10/17/2013 6:49:59 PM
Event ID: 6060
Task Category: None
Level: Warning
Keywords: Classic
User: N/A
Computer: aaa.bbb.com
Description:
RestartHealthService.js : Restarting Health Service. Error: Failed to Terminate Health Service
Source: Health Service Script
Date: 10/17/2013 6:49:59 PM
Event ID: 6060
Task Category: None
Level: Warning
Keywords: Classic
User: N/A
Computer: aaa.bbb.com
Description:
RestartHealthService.js : Restarting Health Service. Error: Failed to Terminate Health Service
Log Name: Operations Manager
Source: Health Service Script
Date: 10/17/2013 6:23:07 PM
Event ID: 6062
Task Category: None
Level: Information
Keywords: Classic
User: N/A
Computer: aaa.bbb.com
Description:
RestartHealthService.js : Restarting Health Service. Service successfully restarted.
Source: Health Service Script
Date: 10/17/2013 6:23:07 PM
Event ID: 6062
Task Category: None
Level: Information
Keywords: Classic
User: N/A
Computer: aaa.bbb.com
Description:
RestartHealthService.js : Restarting Health Service. Service successfully restarted.
(This management pack exists in SCOM 2012, don't let the 2007 in the name fool you)
The monitor with the recovery task to restart the health service is Microsoft.SystemCenter.HealthService.ServiceStateRollup. It targets Microsoft.SystemCenter.HealthService.
It is an aggregate monitor with two unit monitors, one for the count, and one for the private bytes of HealthService.exe.
Microsoft.SystemCenter.Agent adds two additional unit monitors.
![Microsoft System Center 2012 R2 [10-17-2013] Microsoft System Center 2012 R2 [10-17-2013]](/uploads/1/2/5/8/125845473/785462928.jpg)
Since the recovery task is on the aggregate monitor, any of the child unit monitors can trigger it. In my case, it was the private bytes of Monitoring Host that was causing the recovery task to run on my SCSM servers.
The class structure for Health Service can be a little confusing.
- Microsoft.SystemCenter.HealthService
- Microsoft.SystemCenter.Agent
- Microsoft.SystemCenter.Agent.ManagementServer
- Microsoft.SystemCenter.ManagementServer
- Microsoft.SystemCenter.GatewayManagementServer
- Microsoft.SystemCenter.Agent
SCOM discovers SCSM Managemenet Servers as instances of the Microsoft.SystemCenter.Agent.ManagementServer class.
There is already an override that disables the recovery task for Microsoft.SystemCenter.ManagementServer Since Microsoft.SystemCenter.GatewayManagementServer is a child class of Microsoft.SystemCenter.ManagementServer the override applies to both of them. However Microsoft.SystemCenter.Agent.ManagementServer is not a child of management server, so the override does not apply to it. To me this is silly as I wouldn't want the recovery task restarting a health service of a management server regardless of whether or not it was in a different management group.
Our solution is actually quite simple. We just make an override that disables the recovery for that class too. Overrides do not inherit up the tree, so this will not impact Microsoft.SystemCenter.Agent.
Here is the XML of the override that I made.
<RecoveryPropertyOverride Context='SC!Microsoft.SystemCenter.Agent.ManagementServer' Enforced='true' Recovery='MSSC2007!Microsoft.SystemCenter.Agent.RestartHealthService.HealthServicePerfCounterThreshold' Property='Enabled'>
<Value>false</Value>
</RecoveryPropertyOverride>
<Value>false</Value>
</RecoveryPropertyOverride>