The following information will help you understand the various roles found within System Center 2012 R2 Operations Manager.
While in small or test environments you may consider installing all of the roles on a single server, large or production environments will often have the various roles spread across multiple servers for both performance and availability purposes.
SCOM has various roles that need to be deployed and configured within an implementation. A breakdown of these roles is given in the following sections to help you understand roles within SCOM.
The management server is the brains of SCOM. It is a role that coordinates management pack distribution, monitoring and rule application, as well as agent communication and the interface between the system and you, the admin, via the console.
Every deployment of SCOM will contain at least one management server, but adding more management servers will allow you to start to scale out the implementation for both performance and availability.
When implementing the first management server, SCOM creates what is known as a management group. This can be seen as a control boundary allowing you to select which servers are managed by this implementation of SCOM and, if required, to implement multiple management groups, each with their own sets of management servers, for different purposes.
The operational database is the database backend used by the management servers for short-term storage of data and processing of information related to the management packs implemented within your deployment and their rules, monitors, and overrides, which is the system configuration.
Every management group requires one unique operational database.
The SCOM data warehouse consists of another SQL database but is used for long-term storage of data, the default period being 400 days. Data is written in parallel to the data warehouse while the data is simultaneously being written to the operational database, but over time the data in the data warehouse such as performance metrics is aggregated, rather than it being stored as raw data.
The data warehouse database is a required component for an SCOM management group, but it can be shared between different management groups, allowing for a centralized data warehouse to be implemented, providing you with a rolled-up and consolidated view of the health and performance of the different monitored areas of your environment.
Refer to the Sizing the Environment recipe in this chapter for further information on connected management groups.
The reporting server, while an optional extra, is highly recommended as this is the role that provides access to the reporting features of SCOM. It requires a server with a dedicated SQL Server Reporting Services (SSRS) instance to be designated as the reporting server. SCOM requires a dedicated SSRS instance as it will modify its security to match that of the role-based access model used for SCOM, potentially removing access to any reports you might have previously had on the SSRS instance. It is not recommended or supported to use this SSRS instance for any purpose other than for SCOM reporting.
A gateway server is used in two main scenarios, as a way to bridge security boundaries and to act as an agent traffic management point.
A gateway can be placed outside of the security boundary where the main management servers reside, such as within an isolated Demilitarized Zone (DMZ), workgroup, or domain environments, without trusts established.
A gateway within an Active Directory environment can communicate to agents and then act as the communication point from the untrusted environment back to the management group using certificates to secure the communication channel.
A gateway can also be used to manage non-domain joined devices and then all agents will communicate to the gateway using certificates, and the gateway in turn will communicate back to the management group via certificate-secured channels.
Agents can be set to communicate with the gateway instead of directly with the management servers. This is useful for low-bandwidth remote sites where instead of having multiple agents reporting data directly across the network link, they report their data to the gateway, which can then compress that data and send it in batches instead. The compression can be as much as 50 percent.
SCOM offers users the ability to access a web-based version of the operator console using a Silverlight-rendered console. This role can either be deployed on a separate server or on an existing management server. However, it is worth noting that if installed on a separate server, a management role cannot be deployed to that same server after installation of the web console role.
Alongside the web-based operator console, the web portals for Application Performance Monitoring (APM) are also deployed as part of the web console role. These consoles give access to the rich diagnostic and performance monitoring that is gathered for .NET and Java applications.
Audit Collection Services (ACS) allows security events generated by audit policies applied to monitored systems to be collected to a central location for review and monitoring. When enabled within your environment, a service installed as part of the SCOM agent called ACS Forwarder will send all security events to the ACS Collector.
The ACS Collector is a role that is enabled on a management server and will then filter and write to the ACS Database any security events you define as being monitored. The ACS Database is a dedicated database for security events. Each ACS Collector will require its own individual database.
System Center 2012 R2 Operations Manager uses either Agent-based or Agentless communication to collect data from servers and devices. Servers with agents will push this data to the management servers or gateways that they have been assigned to, while agentless managed servers and devices, such as network switches, will generally have their information pulled from management servers.
The flow of information and/or connection points around the infrastructure can be visually represented as follows:
SCOM uses a mechanism known as management packs to control what type of information is collected and how to react to this information. These management packs are XML formatted files that define rules, monitors, scripts, and workflows for SCOM to use and essentially tell it how an aspect of your infrastructure should be monitored.
Most of these management packs will come from the suppliers of the software and devices used within your infrastructure, but there is nothing to stop you from creating your own management packs to fill a gap in monitoring if you find one. Chapter 7, Authoring Custom Monitoring Solutions with System Center 2012 R2 Operations Manager, will detail how to approach this.
You are also able to override predefined options within management packs to better tune the monitoring for your environment. Again, this is covered in more detail in Chapter 4, Operating System Center 2012 R2 Operations Manager.
While you've just been introduced to the main roles that will be encountered within almost all deployment scenarios of System Center 2012 R2 Operations Manager, there are a couple more, well, features rather than roles worth introducing.
With the release of Service Pack 1 for System Center 2012, Microsoft introduced a new feature known as Global Services Monitoring (GSM).
GSM allows you to configure a watcher node outside of your organization utilizing Microsoft's Azure platform, which can then be used to perform availability and performance monitoring of your externally accessible web-based application.
This allows you to gain a true 360 degree perspective on your environment with both internal monitoring happening from within your data center and a customer perspective from outside your network.
This information can then be surfaced through dashboards to see a visual representation of access to your services from different locations around the world.
Another feature introduced fully with the 2012 R2 release is System Center Advisor integration. System Center Advisor is a standalone cloud-based service that helps in the proactive monitoring of the configuration of infrastructure systems and provides suggestions in line with best practices.
At the time of writing this, Microsoft had a preview of the replacement for Advisor in testing named Azure Operational Insights. This allows configuration information from SCOM to be uploaded into the cloud service and for the data to be analyzed for different purposes such as capacity planning, change tracking, and security. Chapter 9, Integrating System Center 2012 R2 with Other Components, for further information.
In versions of Operations Manager prior to 2012, there was a role known as the Root Management Server (RMS). This role was typically held by the first management server deployed into a management group and was responsible for running some distinct workflows such as AD assignment, notifications, and database maintenance.
This meant special attention was required when considering high availability with Failover Clustering and adding a layer of complexity. It also meant consideration of placement was required in relation to other components, such as the data warehouse or operator console access, owing to the SDK running on the RMS that scripts and consoles used to connect to SCOM.
The good news is this role requirement has been removed in the 2012 and later releases, but there is still a RMS Emulator (RMSE) component.
The RMSE is present to only provide backward compatibility for legacy management packs, which may still contain a workflow that specifically targets the RMS (for example, the Microsoft Exchange 2010 management pack). Most management packs, especially those from Microsoft, should now be re-released with the RMS requirement removed, but if you have any in-house management packs, it is recommended you check whether they are targeting the Root Management Server class instance (Target="SC!Microsoft.SystemCenter.RootManagementServer").
You can identify which management server in your environment is running the RMSE by using the Get-SCOMRMSEmulator PowerShell command.
Running that command will display which management server is currently responsible for hosting and running the RMSE. In the event of a failure, however, the RMSE role will not fail over to another server, mainly as it isn't considered critical and should have limited impact on the environment.
If the RMSE does require to move to another management server in the event of a failure or just for proactive maintenance reasons, you can use this PowerShell command: Set-SCOMRMSEmulator.
To move the RMSE with a single PowerShell line, you would combine the command to get the details of the target management server with the Set command as in this example where the command would move the RMSE to a server named POSNCOM01:
Get-SCOMManagementServer –Name "PONSCOM01" | Set-SCOMRMSEmulator
The following are useful links to information related to the System Center 2012 Operations Manager roles and features:
Microsoft TechNet—About Gateway Servers in Operations Manager: http://technet.microsoft.com/en-us/library/hh212823.aspx
System Center Advisor: https://www.systemcenteradvisor.com/
Microsoft TechNet—Global Service Monitor: http://technet.microsoft.com/en-us/library/jj860368.aspx