Operations Manager core features
In this section, we will cover some of the most common features used in OpsMgr. It's important that you have a high-level understanding of these features before installing OpsMgr. This will assist you during the planning and design phase of your deployment.
Management group
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.
Operational database
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.
Data Warehouse database
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.
RMS Emulator
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.
Tip
Using the Operations Manager Shell (which is the PowerShell module that gets deployed during the installation of OpsMgr), you can easily move the RMS Emulator role between management servers using the following line of code:
Get-SCOMManagementServer -Name "opsmgr1.yourdomain.com" | Set-SCOMRMSEmulator
Management Server
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:
|
Service name |
Startup type |
Description |
|---|---|---|
|
Microsoft Monitoring Agent |
Automatic |
|
|
System Center Data Access |
Automatic |
|
|
System Center Management Configuration |
Automatic |
|
|
Microsoft Monitoring Agent Audit Forwarding |
Disabled |
|
|
Microsoft Monitoring Agent APM |
Disabled |
|
Reporting Server
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.
Gateway Server
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.
Agents
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:
|
Service Name |
Startup Type |
Description |
|---|---|---|
|
Microsoft Monitoring Agent |
Automatic |
|
|
Microsoft Monitoring Agent Audit Forwarding |
Disabled |
|
|
Microsoft Monitoring Agent APM |
Disabled |
|
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.
Consoles
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.
Tip
The maximum recommended number of concurrent Operational Console connections per management server is limited to 50. If you go over this number, then you will encounter performance issues. The Web Console however, has no limit to the number of concurrent connections you can make.
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.
Management packs
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:
- Class definitions
- Discoveries
- Monitors
- Rules
- Views
- Knowledge
- Reports
- Templates
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.
Application Performance Monitoring
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.
Network device monitoring
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
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
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.
