IT tutorials
Applications Server

Monitoring Microsoft Lync Server 2010 : OpsMgr Architecture

5/2/2013 1:51:00 AM
- Windows 10 Product Activation Keys Free 2019 (All Versions)
- How To Bypass Torrent Connection Blocking By Your ISP
- How To Install Actual Facebook App On Kindle Fire

OpsMgr is primarily composed of five basic components: the operations database, reporting database, Root Management Server, management agents, and Operations Console. These components make up a basic deployment scenario. There are also several optional components that provide functionality for advanced deployment scenarios.

OpsMgr was specifically designed to be scalable and can subsequently be configured to meet the needs of any size company. This flexibility stems from the fact that all OpsMgr components can either reside on one server or can be distributed across multiple servers.

Each of these various components provides specific OpsMgr functionality. OpsMgr design scenarios often involve the separation of parts of these components onto multiple servers. For example, the database components can be delegated to a dedicated server, and the management server can reside on a second server.

The following list describes the different OpsMgr components:

  • Operations database— The operations database stores the monitoring rules and the active data collected from monitored systems. This database has a seven-day default retention period.

  • Reporting database— The reporting database stores archived data for reporting purposes. This database has a 400-day default retention period.

  • Root Management Server— This is the first management server in the management group. This server runs the software development kit (SDK) and Configuration service, and is responsible for handling console communication, calculating the health of the environment, and determining what rules should be applied to each agent.

  • Management Server— Optionally, an additional management server can be added for redundancy and scalability. Agents communicate with the management server to deliver operational data and pull down new monitoring rules.

  • Management agents— Agents are installed on each managed system to provide efficient monitoring of local components. Almost all communication is initiated from the agent with the exception of the actual agent installation and specific tasks that run from the Operations Console. Agentless monitoring is also available with a reduction of functionality and environmental scalability.

  • Operations Console— The Operations Console is used to monitor systems, run tasks, configure environmental settings, set author rules, subscribe to alerts, and generate and subscribe to reports.

  • Web Console— The Web Console is an optional component used to monitor systems, run tasks, and manage maintenance mode from a web browser.

  • Audit Collection Services— This is an optional component used to collect security events from managed systems; this component is composed of a forwarder on the agent that sends all security events, a collector on the management server that receives events from managed systems, and a special database used to store the collected security data for auditing, reporting, and forensic analysis.

  • Gateway Server— This optional component provides mutual authentication through certificates for nontrusted systems in remote domains or workgroups.

  • Command shell— This optional component is built on PowerShell and provides full command-line management of the OpsMgr environment.

  • Agentless Exception Monitoring— This component can be used to monitor Windows and application crash data throughout the environment and provides insight into the health of the productivity applications across workstations and servers.

  • Connector Framework— This optional component provides a bidirectional web service for communicating, extending, and integrating the environment with third-party or custom systems.

The Operations Manager 2007 architecture, with all the major components and their data paths, is shown in Figure 1.

Figure 1. Operations Manager 2007 R2 Architecture

Understanding How OpsMgr Stores Captured Data

OpsMgr uses two Microsoft SQL Server databases for all collected data. Both databases are automatically maintained through OpsMgr-specific scheduled maintenance tasks.

The operations database stores all the monitoring rules and is imported by management packs and operational data collected from each monitored system. Data in this database is retained for seven days by default. Data retention for the operations database is lower than the reporting database to improve efficiency of the environment.


The operations database must be installed as a separate component from OpsMgr. However, it can physically reside on the same server, if needed.

The reporting database stores data for long-term trend analysis and is designed to grow much larger than the operations database. Data in the reporting database is stored in three states: raw data, hourly summary, and daily summary. The raw data is stored only for 14 days, whereas both daily and hourly data are stored for 400 days. This automatic summarization of data allows for reports that span days or months to be generated quickly.

Determining the Role of Agents in System Monitoring

The agents are the monitoring components installed on each managed computer. They monitor the system based on the rules and business logic defined in each of the management packs. Management packs are dynamically applied to agents based on the different discovery rules included with each management pack.

Defining Management Groups

OpsMgr uses the concept of management groups to logically separate geographical and organizational boundaries. Management groups enable you to scale the size of OpsMgr architecture or politically organize the administration of OpsMgr.

At a minimum, each management group consists of the following components:

  • An operations database

  • An optional reporting database

  • A Root Management Server

  • Management agents

  • Management consoles

OpsMgr can be scaled to meet the needs of different-sized organizations. For small organizations, the OpsMgr components can be installed on one server with a single management group. In large organizations, on the other hand, the distribution of OpsMgr components to separate servers enables the organizations to customize and scale their OpsMgr architecture. Multiple management groups provide load balancing and fault tolerance within the OpsMgr infrastructure. Organizations can set up multiple management servers at strategic locations to distribute the workload among them.


The general rule of thumb with management groups is to start with a single management group and add more management groups only if they are absolutely necessary. Administrative overhead is reduced, and there is less need to re-create rules and perform other redundant tasks with fewer management groups.

- Microsoft Dynamics Ax 2009 : Developing Role Centers - Role Center Web Parts
- Microsoft Dynamics Ax 2009 : Role Centers - Introduction
- Microsoft Dynamics Ax 2009 : Enterprise Portal - Securing Web Elements, Developing the Navigation
- Microsoft SharePoint 2010 : WebParts and SharePoint Pages - Writing Visual WebParts
- Microsoft SharePoint 2010 : WebParts and SharePoint Pages - Using SharePoint Designer with WebParts
- BizTalk Server 2009 : Do You Really Need an Orchestration?
- BizTalk Server 2009 : What the Orchestration Engine Provides
- SharePoint 2010 : Setting up Visio Services
- SharePoint 2010 : Setting up PerformancePoint Services
- SharePoint 2010 : Setting up Excel Services
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
programming4us programming4us
Popular tags
Video Tutorail Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 Adobe Indesign Adobe Flash Professional Dreamweaver Adobe Illustrator Adobe After Effects Adobe Photoshop Adobe Fireworks Adobe Flash Catalyst Corel Painter X CorelDRAW X5 CorelDraw 10 QuarkXPress 8 windows Phone 7 windows Phone 8 BlackBerry Android Ipad Iphone iOS