Created during the initial installation of OpsMgr, a management group is a unique logical administrative unit that defines the security boundaries of your monitoring environment.

When choosing a management group name, you must ensure that the name is unique within your Active Directory forest and also understand that whatever name you choose, it's case sensitive. It's also recommended that you refrain from using any unsupported special characters in the name and stick with letters and numbers.

You can have multiple management groups running concurrently in the same domain without a problem (this is useful for pre-production and production environments) and all configuration changes and customizations that you make will be contained inside each unique group.

A SQL database that forms the central component of every Management Group, the Operational database installs with a default name of OperationsManager. It contains all your OpsMgr customizations along with configuration and monitoring data for all managed objects. A dedicated Operational database is required for every OpsMgr management group you deploy.

Data is retained in the Operational database by default for seven days - think of this as OpsMgr's short-term memory store. This retention period can be modified for different types of datasets by configuring database grooming within the Operations console.

The data warehouse is a SQL database that can be either dedicated or shared by an OpsMgr management group. This database has a default installation name of OperationsManagerDW.

All historical alerting and monitoring data is stored here and with retention period of up to four-hundred days, this can be considered OpsMgr's long-term memory store. Having the ability to retain data for such a long period means OpsMgr can use the data warehouse to generate rich reports that will help you to better understand the availability and performance of your IT services.

Installed by default onto the first management server that you deploy, the Root Management Server (RMS) Emulator exists to support backward compatibility with legacy OpsMgr management packs that specifically target the RMS role. If there are no legacy management packs that contain rules targeted at the RMS role, then essentially, the RMS Emulator is not required and all management servers are considered equal.

In early releases of OpsMgr, the RMS role was arguably the most important role within the management group and unless you deployed Failover Clustering across two servers, it was also a single-point of failure. Since OpsMgr 2012, the single-point of failure RMS role was removed and out-of-box high availability was made possible using a new feature called Resource Pools. These pools are a collection of management servers that distribute the workload and ensure that monitoring continues in the event of a management server failing.

Get-SCOMManagementServer -Name "opsmgr1.yourdomain.com" | Set-SCOMRMSEmulator

The Management Server role is responsible for managing and communicating with agents, maintaining management group configuration, communicating with the OpsMgr SQL databases, and facilitating console connections.

After installation of this role, you will find five new Windows services installed on your server. Out of the five services, three are configured with a service start up type of Automatic and two of them are set to Disabled.

These management server services and their startup types are detailed in the following table:

The OpsMgr Reporting Server role integrates with SQL Server Reporting Services (SSRS) and gives you the ability to generate and schedule reports from an intuitive user interface inside the Operations Console. You can choose from ready-made reports that come bundled with the various management packs you deploy or you can generate your own custom reports using some of the generic templates on offer.

Good reporting enables you to visualize the monitoring data generated from your IT infrastructure and provide exactly the kind of high-level information that senior management teams request on a regular basis. You also have the option to e-mail reports on a specific schedule or simply export them into various easy-to-read formats, such as Word, Excel, PDF, CSV, and TIFF to name a few.

The primary role of a Gateway Server is to act as a go-between for monitored agents that are located in untrusted domains and networks - DMZ's are a great example of where to use this role in your environment.

When located in an untrusted domain, a Gateway Server must use certificates to authenticate with the main OpsMgr environment. It communicates with management servers over TCP port 5723 and cannot connect directly to the OpsMgr databases.

A Gateway Server also acts as a data compressor and can be used to compress monitoring traffic from agents to the management servers by up to 50% in certain scenarios.

The OpsMgr agent is used for server and client monitoring of Windows and Unix/Linux operating systems. A push installation can be initiated from management servers and gateway servers to make the deployment nice and easy. It can also be deployed manually or added into computer images and packaged as an application for deployment with a tool such as System Center Configuration Manager.

On a Windows computer, after the agent has been installed, three new windows services are created. These new services and their startup types are detailed in the following table:

The agent's job is to communicate with management and gateway servers, discover objects, execute workflows, and run diagnostic tasks on monitored computers.

If you have deployed multiple management groups, the OpsMgr agent can perform a feature called 'multi-homing' whereby it can communicate with up to four different management groups at any given time. This feature will be discussed in more detail in Chapter 4, Deploying Agents.

There are a number of consoles that you can interact with when you are working with OpsMgr. The most common one is the Operations Console, which is essentially the main console that you will use when administering OpsMgr. In Figure 1.2, you can see the Operations Console in action monitoring some Windows computers.

Figure 1.2: The Operations Console

During installation, you can choose to deploy the Web Console, which is a lighter and scaled-down version of the Operations Console. This console will be deployed as an IIS website on whichever server you choose to run it from. Although you can't perform any administration or reporting tasks here, the Web Console is useful if you want to give your OpsMgr users read-only access to the monitored environment.

When you deploy the Web Console role with the installation wizard, you get an automatic installation of the Application Advisor and Application Diagnostics consoles - both of which are used in conjunction with the APM feature for code-level monitoring of your applications.

If you want to get any monitoring value at all from OpsMgr, then you are going to need to install some management packs. These are small files based on XML that can be imported into OpsMgr and which hold information about how to monitor a specific application or hardware product set.

Management packs can contain some or all of the following objects:

In Chapter 5, Working with Management Packs, you will learn much more about management packs and how to use them to get the most out of your OpsMgr deployment.

Another optional and very useful feature of OpsMgr is Application Performance Monitoring (APM). When configured, this gives IT Operations teams the ability to help troubleshoot problems inside applications at the code-level, similar to the world of a Developer. This synergy has become known as 'DevOps', and it's something that has gained a lot of traction in the last few years.

A real benefit of deploying APM in OpsMgr is that, not only do you get to dive deep into your .NET and Java application code; you can also see the health of the underlying infrastructure that runs those applications.

If you're going to monitor the full breadth of your IT services, then you will no doubt want to include network device monitoring in your designs. With a choice of ICMP or SNMP (v1/v2c/v3) monitoring, you can take advantage of the built-in Network Node and Vicinity dashboards to give you rich visualizations on the health of your network infrastructure. Chapter 6, Managing Network Devices, will get you up and running with this feature in no time.

Audit Collection Services (ACS) is an optional feature used to collect security event logs from monitored systems and bring them together in a central SQL database for auditing and compliance purposes. ACS uses its own SQL database (named OpsMgrAC by default), which is kept completely separate from the OperationsManager and OperationsManagerDW databases.

To enable ACS, you must deploy a management server and configure it as an ACS Collector. The ACS Collector then receives and processes the audited security event logs from targeted computers and passes that information into the OpsMgrAC database.

Specific computers running the OpsMgr agent can be targeted with ACS audit policies to enable them as an ACS Forwarder. When Windows computers are enabled as ACS Forwarders, the Microsoft Monitoring Agent Audit Forwarding service is started on those computers and configured with an 'Automatic' start up state. When this service is running, the ACS audit policies are applied and security events will be sent to the ACS Collector for auditing.

Agentless Exception Monitoring (AEM) is an optional feature that centralizes the collection of hardware, operating system, and application crash information from selected computers. If you're familiar with the old 'Dr. Watson Debugger for Windows' tool that collects data from your computer when it crashes, then AEM is a centralized version of this which feeds the crash data into OpsMgr.

The OpsMgr Sizing Helper tool is an interactive Excel document designed to assist you with planning and sizing your deployments. As shown in Figure 1.2, you can choose from a number of different configuration scenarios and all you need to have is a rough idea of what it is that you actually need to monitor.

Figure 1.3: OpsMgr Sizing Helper Tool

This should be the go-to tool that you use prior to every OpsMgr deployment that you do. Although the information it feeds back to you is to be used purely as a guide, it goes a long way to ensure that your designs are aligned as close to best-practice recommendations as possible. You can download the tool from http://tinyurl.com/opsmgrsizing.

All OpsMgr features are fully supported by Microsoft to run in a virtual environment that meets the minimum requirements outlined in the OpsMgr Sizing Helper tool. Purely for performance reasons, Microsoft recommends running the OpsMgr SQL databases on physical disks rather than on virtual disks but this is only a recommendation and there is no issue if you want to deploy the databases in a virtual environment, assuming of course, that you have configured the underlying storage where your virtual disks are located according to best practice recommendations for SQL workloads.

You also have the option of running some or your entire OpsMgr environment on Microsoft Azure for the following three recommended scenarios:

If you're running OpsMgr 2012 R2, then the following versions of SQL Server are supported to host the databases:

If you're running OpsMgr 2016, then your SQL choice is slightly more limited:

The following operating systems are supported to run OpsMgr 2012 R2:

OpsMgr 2016 can be deployed on these operating systems:

If you deploy the OpsMgr 2012 R2 Web Console role, the following Internet Explorer and Silverlight versions are supported:

The OpsMgr 2016 Web Console has the following requirements:

In the following table, we can see the TCP port numbers and outgoing directions that the various OpsMgr features require. This information can be useful when configuring communication across firewalls in your organization.

Although the majority of firewall ports required for OpsMgr are TCP-based, the following table lists the UDP port numbers and the direction they should be enabled for:

If you need to deploy an OpsMgr 2012 R2 agent to your Windows estate for monitoring, then the following is a list of supported server and client operating systems:

For OpsMgr 2016 agents, the following Windows server and client operating systems are supported:

A wide range of cross-platform operating systems are supported and the following list details the versions you can monitor with both OpsMgr 2012 R2 and OpsMgr 2016: