Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Getting Started with Microsoft System Center Operations Manager

You're reading from   Getting Started with Microsoft System Center Operations Manager Using SCOM 2016 TP 5

Arrow left icon
Product type Paperback
Published in Jun 2016
Publisher Packt
ISBN-13 9781785289743
Length 560 pages
Edition 1st Edition
Arrow right icon
Author (1):
Arrow left icon
Kevin Greene Kevin Greene
Author Profile Icon Kevin Greene
Kevin Greene
Arrow right icon
View More author details
Toc

Table of Contents (13) Chapters Close

Preface 1. Introduction to System Center Operations Manager FREE CHAPTER 2. Installing System Center Operations Manager 3. Exploring the Consoles 4. Deploying Agents 5. Working with Management Packs 6. Managing Network Devices 7. Configuring Service Models with Distributed Applications 8. Alert Tuning the Easy Way 9. Visualizing Your IT with Dashboards 10. Creating Alert Subscriptions and Reports 11. Backing Up, Maintenance and Troubleshooting Index

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

  • Monitors the health of your computers.
  • Responsible for executing modules called workflows to support different monitoring scenarios.
  • Listens on TCP port 5723.
  • Also known as the 'HealthService'.

System Center Data Access

Automatic

  • This runs on all management servers.
  • Handles communications with the OpsMgr consoles and Report servers.
  • It reads and writes data to the OpsMgr databases on behalf of workflows running on agents and gateway servers.
  • It listens on TCP port 5724.
  • It's also known as the 'SDK' service.

System Center Management Configuration

Automatic

  • This runs on all management servers.
  • It monitors configuration changes within the management group and passes any updated changes to agents.
  • It's also known as the 'Configuration' service.

Microsoft Monitoring Agent Audit Forwarding

Disabled

  • This is installed on all management servers, gateway servers and agents but disabled by default.
  • It's used with the Audit Collection Services (ACS) feature of OpsMgr.
  • It sends security event logs to an ACS collector server.

Microsoft Monitoring Agent APM

Disabled

  • This is installed on all management servers, gateway servers and agents but is disabled by default.
  • It's used with the Application Performance Monitoring (APM) feature of OpsMgr to monitor code-level health of .NET applications.

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

  • Monitors the health of your computers
  • Responsible for executing workflow modules and scripts to support different monitoring scenarios
  • Listens on TCP port 5723
  • Also known as the 'HealthService'

Microsoft Monitoring Agent Audit Forwarding

Disabled

  • Installed on all management servers, gateway servers and agents but is disabled by default
  • Used with the Audit Collection Services (ACS) feature of OpsMgr
  • Sends security event logs to an ACS collector server

Microsoft Monitoring Agent APM

Disabled

  • Installed on all management servers, gateway servers and agents but is disabled by default
  • Used with the Application Performance Monitoring (APM) feature of OpsMgr to monitor code-level health of .NET applications

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.

Consoles

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.

You have been reading a chapter from
Getting Started with Microsoft System Center Operations Manager
Published in: Jun 2016
Publisher: Packt
ISBN-13: 9781785289743
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $19.99/month. Cancel anytime
Banner background image