Operations Manager 2007 Operations Guide
Microsoft Corporation
Published: February 2009
Author
Chris Fox, John Downing, Anat Kerry, Liza Poggemeyer, Scott Butler
Primary Reviewers
Dhananjay Mahajan; Joseph Chan
Feedback
Send suggestions and comments about this document to momdocs@microsoft.com. Please include the operations guide name and published date with your feedback.
Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted in examples herein are fictitious. No association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
© 2008 Microsoft Corporation. All rights reserved.
Microsoft, MS-DOS, Windows, Windows Server, Windows Vista, and Active Directory are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
All other trademarks are property of their respective owners.
Revision History
|
Release Date
|
Changes
|
|
July 13, 2007
|
- Original release of this guide
|
|
February 22, 2008
|
- Added “Maintenance and Best Practices for Operations Manager” section, which contains multiple new topics.
- Added the “Updates to the Operations Manager Deployment” section, which contains multiple new topics.
- Major updates to the Backup and Restore section, including updates to the Root Management Server and Reporting server recovery.
|
|
March 15, 2008
|
- Updated the ‘How to Promote a Management Server role to a Root Management Server Role in Operations Manager 2007’ topic in the ‘Updates to the Operations Manager 2007 Deployment’ section.
- Updated the ‘How to Promote a Management Server to a Root Management Server Role in Operations Manager 2007’ topic in the ‘Updates to the Operations Manager 2007 Deployment’ section.
- Changed formatting in the ‘How to Move the OperationsManager Database in Operations Manager 2007’ topic.
|
|
April 11, 2008
|
- Updated the ‘Configure Notifications’ section to address customer issues, as well as provide the procedure for an operator or advanced operator to create their own notification recipient and subscription.
|
|
September, 2008
|
- Expanded the management pack content to include lifecycle administration, best practices, and procedures
- Added section on Managing Audit Collection Services
- Updated the Operations Console topic to provide additional information, including information on searching the views.
- Updated the Deploy Management Agents in Operations Manager 2007 to provide more detailed, linear deployment steps, as well as additional agent administration information
|
|
February 2009
|
- Improved navigation in the table of contents.
|
Roadmap for the Operations Manager 2007 Guides
If you are new to Operations Manager 2007, you can use the following diagram to see the order in which you should read the Operations Manager 2007 Guides. This diagram will be updated as new guides become available.
Introduction to the Operations Manager Operations Guide
The Operations Manager 2007 Operations Guide is a comprehensive resource that can be used to understand and use your Operations Manager 2007 implementation to your best advantage. It follows the Operations Manager 2007 Deployment Guide in order of usage during an Operations Manager implementation project. It teaches the Operations Manager administrator what to do after successfully deploying a management group for the first time.
What Is in This Guide
You can use this guide in one of two ways:
- If you are coming to this guide having just deployed a management group for the first time, then you should start at the beginning and read through the guide sequentially.
- If you are already familiar with administering an Operations Manager 2007 management group, then just go ahead to the section that you need.
The first section, Operations Manager 2007 Default Settings, provides a tour of the the components that are present prior to any management packs being imported or agents being deployed. It explains the default behavior of Operations Manager 2007 and the objects that are present by default.
The second section, Configuring Operations Manager 2007 for Use, provides a tour of the Operations console and guides you through the administrative tasks that prepare your Operations Manager 2007 implementation for use by people that will be in the Operators role. For example adding users to Operations Manager 2007 roles, configuring recipients, and using notification channels and subscriptions.
The third section, Start Monitoring, tells you how to start monitoring your environment. These sections provide information about deploying agents, managing agents and working with alerts. With these tasks completed, your Operations Manager 2007 implementation will be monitoring your applications and computers and providing you with actionable alerts, performance data and other information from your environment.
The final section, Maintenance and Best Practices for Operations Manager remaining sections describe ongoing tasks. These sections can be used as a reference by all Operations Manager administrators for understanding general management group administration scenarios and includes the procedures needed to support those scenarios. These sections include content on administering management servers, administering Management Groups, and performing basic backup and restore procedures and administering Gateway servers.
Operations Manager 2007 Default Settings
Operations Manager 2007 has numerous settings that are configured and enabled during an Operations Manager 2007 installation. Many of these settings are contained in a series of management packs that are imported during an Operations Manager 2007 installation. These management packs are designed to provide a foundation of object types and settings upon with other management packs depend.
Before you begin importing additional management packs or deploying agents into your environment, you should first become familiar with these initial settings. This section discusses how to view, assess the impact of, and, if desired, customize these initial settings.
Review automatically imported management packs
During an Operations Manager 2007 installation, 40 management packs are imported by default. Of the 40 management packs that are imported during installation, most are libraries. Libraries are a special type of management pack that are designed to provide a foundation of object types and settings upon with other management packs depend. The management packs that you want to import to monitor applications, services, and devices in your environment will have dependencies on one more of these libraries.
You can view the list of automatically imported management packs in the Administration pane of the Operations console immediately after installation of Operations Manager 2007 is complete.
To view a list of all the imported management packs, click Management Packs in the Administration pane of the Operations console. The list of imported management packs displays in the Details pane.
The following is a list of automatically imported management packs for Operations Manager 2007:
- Application Log Library
- Baselining Tasks Library
- Client Monitoring Internal Library
- Client Monitoring Library
- Client Monitoring Views Library
- Data Warehouse Internal Library
- Data Warehouse Library
- Default management pack
- Distributed Application Designer Library
- Health Internal Library
- Health Library
- Image Library (System Center)
- Image Library (System)
- Image Library (Windows)
- Instance Group Library
- Microsoft Generic Report Library
- Microsoft ODR Report Library
- MOM 2005 Backward Compatibility
- Network Device Library
- Notifications Internal Library
- Notifications Library
- Operations Manager 2007
- Operations Manager Agent Management Library
- Operations Manager Internal Library
- Performance Library
- SNMP Library
- Synthetic Transactions Library
- System Center Core Library
- System Center Core Monitoring
- System Center Internal Library
- System Center Rule Templates
- System Center Task Templates
- System Center UI Executed Tasks
- System Hardware Library
- System Library
- Web Application Monitoring Library
- Windows Client Operating Systems Library
- Windows Cluster Library
- Windows Core Library
- Windows Service Library
Assess initial settings
Like all management packs, the enabled settings contained in the automatically imported management packs begin monitoring immediately after it is deployed to an agent. You can use the Authoring and Monitoring panes in the Operations console to display and assess the initial settings of Operations Manager 2007.
Authoring Pane
You can use the Authoring pane in the Operations console to view monitoring settings from currently imported management packs. To switch to the Authoring pane, click the Authoring button. You can then click any node under the Management Pack Objects node to view the monitoring settings that apply to the corresponding node. For example, if you click Rules, the Details pane displays a list of all the rules that are from currently imported management packs.
Rules, like all other management pack objects, are listed by the type of object to which the rule applies. Each object type is listed in ascending alphabetical order. Each monitoring object in the Details pane includes information, such as the management pack, that contains the setting and if it is currently enabled or disabled. Most settings included in the automatically imported management packs are enabled, by default.
Note
- When you first select a node under Management Pack Objects, by default, every object type, that has a monitoring setting associated with it, is displayed in the Details pane. You can limit which object types display in the Details pane by using the Scope feature. This feature is explained in Operations Manager 2007 Help in the topic How to Manage Monitoring Data using Scope, Search, and Find.
- The Operations Manager 2007 authoring console is a standalone application that provides richer management pack authoring functionality than what is provided by the authoring pane. Using the authoring console, you can create new management packs, view and modify existing management packs, verify the integrity of management packs, and import and export management packs to and from management groups. The Operations Manager 2007 authoring console can be downloaded here:
Monitoring Pane
The Monitoring pane displays the results of monitoring. It contains only folders and views. The folder structure of the Monitoring pane is defined by individual management packs that are currently imported.
Many of the libraries that are automatically imported define a folder structure and views that. For example, the Windows Client Operating Systems Library imports automatically during Operations Manager 2007 installation. This library creates a Microsoft Windows Client folder in the Monitoring pane that contains views and other subfolders. These views are designed to display information that is gathered by the client operating system management packs such as the Windows XP management pack or the Windows Vista management pack and the Information Worker management pack. If you do not import a client operating system management pack or the Information Worker management packs, these views have no data to display.
Management Pack Removal
You can delete a management pack in the Administration pane from the Details pane when the Management Packs node is selected. For the deletion to be successful, no other imported management pack can depend on the management pack you want to delete. Several of the automatically imported libraries have dependencies on other libraries. If the management pack you want to delete has any dependent management packs, Operations Manager displays a list of the dependent management packs and does not allow you to continue with the deletion.
Change initial management pack settings
You can use overrides to change the behavior that is set by automatically imported management packs. All monitoring settings, including overrides must be saved to a management pack. Before you customize any settings of a management pack, you should first plan how and to which management pack you will save these customizations.
Management Pack Formats
Management pack files in Operations Manager 2007 have two formats that are accepted as valid. These formats are sealed and unsealed. A sealed management pack is a binary file whose settings cannot be changed. An unsealed management pack is an XML file that can be edited. Of the 38 management packs that are imported as part of an Operations Manager 2007 installation only one is unsealed. The unsealed management pack is the Default management pack.
After a management pack is imported, you can use overrides to supersede a sealed management pack’s default settings. An override, like all monitoring settings, must be saved to a management pack, but because you cannot change the settings of a sealed management pack file, overrides and other customizations must be saved to a different and unsealed management pack.
The Default Management Pack
The Default management pack is provided as a repository for customizations that effect sealed management packs. It is the only unsealed management pack imported as part of the Operations Manager 2007 installation. By default, when you create an override, or any other monitoring setting, it is saved to the Default management pack. You can choose to save the override to another unsealed management pack when you create the override. You can use an existing management pack or create a new one from the Override Properties page.
Management Packs for Customizations
If you plan to use overrides to tune many of your management packs, instead of saving all of the customizations to the Default management pack you can create a set of management packs whose purpose is to store customizations.
When you create these management packs you can devise a naming convention that is the same as the management pack that holds the original settings. For example, if you want to customize settings defined in the Windows Core Library, you can create a management pack in the Operations console and name it Windows Core Customizations. This unsealed management pack can then be used to save overrides and other customizations, such as additional monitors, that supersede the default settings of the Windows Core Library.
Configure Operations Manager
Operations Manager begins gathering monitoring data immediately after it is deployed. Before Operations Manager users, such as operators and authors, can act on this data the Operations Manager administrator needs to complete some configuration tasks. The tasks include implementing user roles, which determine what actions your Operations Manager users can perform and on which objects, as well as determining your users console needs and configuring notifications.
Understanding the Operations console
The Operations console is the primary tool used for managing your Operations Manager 2007 deployment. In the Operations console, you view and interact with alerts and monitoring data, manage and edit unsealed management packs, generate and view reports, administer management group settings, and build a workspace that is customized to your needs.
The Operations console is made up of the following parts:
Toolbar
|
Provides access to the menus, search, find, and scope features, and actions. Note that the tools you see might differ depending on the level of access you have.
|
Navigation pane
|
Displays the aspects of your Operations Manager implementation, including all currently discovered objects. You can use the navigation tree to drill into your environment. When you select an item in the tree, details of that item are displayed in the Results pane.
|
Navigation buttons
Enable you to move through the monitoring and administration views in the Operations console. The buttons that you have access to depends on the security role you are signed in as. A member of the Administrator group can access all the buttons; an Operator can access all the buttons except Administration.
There are five areas:
- Monitoring
- Authoring
- Reporting
- Administration
- My Workspace
|
Actions pane
|
Displays links to any actions you can take on a selected object (such as viewing the properties of the object), additional resources you can use to get more information (links to online information), and links to the product help. The links displayed in the Actions pane are context-specific and reflect your current scope, view, and selected object.
|
Results pane
|
Displays the results from navigation using the navigation tree or from a search or find action. The Results pane also shows any textual feedback from actions.
|
Details pane
|
Displays more detailed information about the selected item in the Results pane.
|
Navigate the Operations console
To view the portion of the navigation tree that you want, select the appropriate navigation button, such as Administration or Monitoring. Which navigation buttons are available to you depends on which Operations Manager 2007 components have been installed (such as Reporting) and the role for which you are logged in (Administrators see all navigation buttons; operators see only Monitoring). Each navigation button opens a different view. The navigation tree in the Operations console is context-sensitive based on the view that you are using. For example, when you are working in the Administration view, the navigation tree shows different functions for administration (such as configuring user security), while when in the Monitoring view, the navigation tree displays monitoring functions (such as viewing alerts).
The following sections provide details about each of the views and what you can do in those views.
Monitoring view
In the Monitoring view, you can quickly find the monitoring data you need, such as alerts, performance data, and diagram views. The view displays different aspects of the monitoring data that is collected by Operations Manager 2007. Each item in the Monitoring navigation tree is either a view type or a folder that contains more views.
The views listed under the Monitoring view display aspects of your entire environment, such as current active alerts. The folders listed in the navigation tree are either features of Operations Manager, such as Agentless Exception Monitoring and synthetic transactions, or containers for views defined within a management pack. The feature folders are created when Operations Manager is installed. The folders are named after imported management packs and contain views from those management packs.
You cannot delete the folders or views that are created when Operations Manager is installed or when Management Packs are imported. However, you can personalize the display of these views by using the Personalize View option in the Monitoring pane. Also, you can hide any of the folders by clicking Show or hide views, located just above the navigation buttons, and making your selections by clearing the appropriate check boxes in the Show or hide views window.
The Find, Search, and Scope buttons on the Operations console can make it easier to access the monitoring data within the Monitoring view. For information about using Find, Search, and Scope, see View data in the Operations console.
Authoring view
In the Authoring view, you can display monitoring settings from currently imported management packs. You can click any node under the Management Pack Objects node to view the monitoring settings that apply to the corresponding node. For example, if you click Rules, the Details pane displays a list of all the rules that are from currently imported management packs. Rules, like all other management pack objects, are listed by the type of object to which the rule applies. Each object type is listed in ascending alphabetical order. Each monitoring object in the Details pane includes information, such as the management pack that contains the setting and if it is currently enabled or disabled. Most settings included in the automatically imported management packs are enabled, by default.
You can also use the Authoring view to create and configure additional monitors, distributed applications, and groups.
See the Management Pack Authoring Guide for detailed information about how to create a management pack for a product (which can be an application, a service, or a device).
Reporting view
In the Reporting view, you access the Reporting function in Operations Manager. You can use the Reporting function to create reports based on the data collected by Operations Manager. Reports present data that has been aggregated, is from specific time intervals and from specific sources, and can provide a longitudinal view of information from your monitoring environment. For example, you can create a report that shows the amount of time it takes between an alert being raised to its being written in the Operations Manager database. This report can help you identify any network delays and isolate trouble spots. Based on the data in this report, you can then take corrective action.
The Reporting view is only available if you have installed the Reporting components and have been granted access to them. For information about installing and deploying the Reporting feature, see the Operations Manager Deployment Guide. You can also find additional information about using the Reporting interface in the Report Authoring Guide and the Operations Manager Help.
Administration view
In the Administration view, you can deploy and configure all aspects of the monitoring environment. For example, if you want to set up notifications (messages that are sent when alerts occur), you do that through the Administration view. You also perform most administration aspects of Operations Manager through this view: You can configure and manage management groups and users, set up user security through user roles, and manage connectors (non-Microsoft devices that provide monitoring data to Operations Manager 2007).
My Workspace view
Use the My Workspace view to create and save custom workspaces and searches. This enables you to customize your working environment so that it shows only those items that you are interested in.
View data in the Operations console
Operations Manager 2007, with the appropriate management packs imported, will provide you with a comprehensive view of what is going on with your monitored applications, hardware, and processes. This can result in a very large volume of data being displayed in the Operations console. Learning how to quickly locate the data you need is essential to efficient interaction with the console. You can use the Scope, Find, and Search buttons on the Operations console toolbar to filter your view of monitoring data so that you can find the exact monitoring object or group of objects that you need. You can also filter your data based on the number of hours or days you would like to show.
The Scope, Search, Find, and Time tools apply a temporary filter to the data you are viewing in the console. While you can locate a specific object using Search or Find, you can also use Scope or Time to display a set of objects that meet a set of criteria. The following table shows the differences between the different filtering options:
|
Filter
|
When to use
|
|
Scope
|
Use to limit the data in a view to only those objects that meet your criteria. This scope remains in place until you clear it.
|
|
Search
|
Use to display a list of objects that meet your criteria. You can then act on those objects; however, when you navigate away from this list, the filter is removed, and any view will show all objects (not just those from your search criteria).
|
|
Find
|
Use to display a known single object.
|
|
Time
|
Use to limit the data displayed to only that data (such as alerts) that has been generated within a defined time frame.
|
If you need to view the same set of monitoring data, you can personalize a view so that the same filters are always applied to the data when you open that view in the console. You can also save a search for later use.
Changing the scope
Changing the scope of the monitoring view enables you to view only those objects that meet a certain criteria, such as management servers. For example, if you want to view only those computers in your environment that are running Windows XP, you can apply a scope that uses “Windows XP” as the criteria; no other computers are displayed.
Note that the scope used within the Operations console is different from that used for security roles. In a security sense, the term “scope” applies to the realm of responsibility (such as being responsible for all computers in the Northwest running Microsoft Exchange). A security role is made up of the scope plus a profile.
To change the scope
|
1. In the Operations console, click the Monitoring button to display the objects in your monitoring environment.
2. Click the Scope button on the Operations Manager toolbar. If this button is not available, check to make sure that you have an object, not a folder, selected in the Monitoring pane.
3. The Change View Scope dialog box displays a list of existing groups and distributed applications. If the list is too long, you can find a specific group or distributed application by entering a word or phrase in the Look for box. Once you make a selection, click OK.
Now only the objects that meet the scope criteria are shown in the Results pane.
|
Using Find and Search
Use the Find button when the list of objects in the Results pane is too long to quickly pick out a particular object. Use the Search button if you want to find all objects that meet a certain criteria.
To use the Find button to locate an object within a list
|
1. In the Operations console, click the Monitoring button.
2. Click to select a view that is available in the Monitoring pane. This displays a list of objects.
3. Check to see if a Look for box is at the top of the Results pane. If there is no Look for box, click the Find button on the Operations Manager toolbar. In Look for, type a word, such as the name of an object, that you want to find in the list, and then click Find.
The object that you are looking for is displayed.
4. Click Clear to go back to the original list of objects.
|
To use the Search feature to create a list of objects
|
1. In the Operations console, click the Monitoring button.
2. Click the Search button in the Operations Manager toolbar.
3. In the Search window, type the word or phrase that describes the set of objects you want to find. A list of objects that meet your criteria displays. The list is sorted by object type.
|
Changing the time criteria
Changing the time criteria of the monitoring view enables you to view only those objects that meet a certain criteria, such as “Last 12 hours.” When you change the time criteria, you limit what is displayed to only what has happened in that time period. For example, if you want to view the last week of data, you can change the time criteria to Last 1 week.
To change the time criteria
|
1. In the Operations console, click the Monitoring button to display the objects in your monitoring environment.
2. Click the Calendar button on the Operations Manager toolbar. If this button is not available, check to make sure that you have an object, not a folder, selected in the Monitoring pane.
3. Select the proper time criteria you are interested in.
|
Now only the objects that meet the time criteria are shown in the Results pane.
Implementing User Roles
In Operations Manager 2007 user roles assign the rights needed to access monitoring data and perform actions. User roles are designed to apply to groups of users that need access to and perform actions on the same group of monitored objects. By default, only the Operations Manager Administrator account has the right to view and act on monitoring data. All other users must have a user role assigned in order to view or act on monitoring data.
User Roles are created using the Create User Role Wizard. In this wizard you configure which Active Directory security groups are assigned this user role, which Operations Manager group or groups of monitored objects this user can access, and which tasks and views this user role can access.
Choose a Profile
Before you can start the Create User Role Wizard you must select one profile that applies to the user role you are creating. A profile determines the actions that an Operations Manager user can perform. Profiles have a defined set of rights and you cannot add or remove any of these assigned rights. For a complete list of profiles and the rights assigned to each see About User Roles in the Operations Manager 2007 Online Help. When creating user roles for operators and other Operations Manager users, select the profile that most closely matches the responsibilities of the group of users in your Operations Manager 2007 deployment
Define a scope using Operations Manager groups
Scope determines which objects you can view and perform actions on in Operations Manager 2007. A scope is comprised of one or more Operations Manager groups and is defined when creating a user role as part of the Create User Role Wizard. The Group Scope page of the Create User Role Wizard provides a list of all existing Operations Manager groups. You can choose all or just some of these groups as the scope of the user role you are creating.
Groups, like other Operations Manager objects, are defined in management packs. In Operations Manager 2007, groups are logical collections of objects, such as Windows-based computers, hard disks, or instances of Microsoft SQL Server. Several groups are created by the management packs that are imported automatically during an Operations Manager installation. If these groups do not contain the monitored objects you need for a scope, you can create a group that does. To do this you must exit the Create User Role Wizard, switch to the Monitoring pane and use the Create Group Wizard to create a group that better suits your needs.
Assign tasks and views
The Create User Role Wizard contains a page that defines the tasks that the user role you are creating can perform and a page that specifies the views that the user role you are creating can open and use. The default setting is that all users assigned that user role can run all tasks and open all views as long as their profile and scope allows it. The alternative in these wizard pages is to list the specific tasks or views that the user role you are creating can access.
Determining Console Needs
Operations Manager users need a console to access monitored objects through a graphical interface. The consoles available to your users are the Operations console and the Web console. The Operations console allows Operations Manager users to perform all actions that their user role allows while the Web console displays only Monitoring and My Workspace panes.
If you create a user role based on the Author or Advanced Operator profile those users must have the Operations console to perform all of the tasks that these profiles allow.
As the administrator you must deploy the Operations console to each user’s computer using the System Center Operations Manager 2007 Setup wizard. The Operations console can run on one of two client operating systems: Windows XP and Windows Vista. Some of the requirements include a minimum of 1 gigabytes (GB) of RAM and a 1 gigahertz (GHz) processor. For a full list of hardware and software components for installing the Operations console see Operations Manager 2007 Supported Configurations.
The Web console is designed for users that have a user role that is based on the Operator or Read-Only Operator profiles. Only the Monitoring and the My Workspace panes are available in the Web console. It is designed for operators to view monitoring data, run tasks, and resolve alerts. However, from the web console you cannot use the Run As feature. All tasks are run on the agent using the agent action account credentials.
No special hardware or operating system is required for the Web console. Users access your Web console server via Internet Explorer 6.0 or later. If you have users whose job it is to create monitoring settings or override default settings that user must have an Operations console.
Configuring Notification
Notifications generate messages or run commands automatically when an alert is raised on a monitored system. By default, notifications for alerts are not configured. If you want your Operations Manager users to be notified immediately when an alert is generated you need to configure notifications and let the users know the steps they need to take to receive them.
To configure notifications, an Operations Manager administrator must perform the following steps:
- Enable Notification Channels
- Create and Configure a Notification Action Account
Once the above steps are complete, an administrator, operator, or advanced operator can do the following:
- Create Notification Recipients
- Create Notification Subscriptions
To receive notifications, an Operations Manager user must subscribe to a notification subscription. An Operations Manager user must have the rights assigned to the Operator user role to subscribe to a notification.
Notification Message Content
Operations Manager administrators can configure message content for a notification. Operations Manager has two default message formats: short and verbose. The default short format has only a subject and is designed for small bandwidth channels and devices, such as instant messages and pagers. The default verbose format has a subject and a message body and is designed for notification channels that have more bandwidth available, such as e-mail. An administrator can accept the defaults for the short and verbose messages or edit the subject and content of a notification message.
Operations Manager uses Alert parameter variables to define the subject and body content of a notification message. Variables in Operations Manager 2007 are enclosed in dollar signs ($). An example of a variable is $Data/Context/DataItem/AlertName$. In this example the variable text is replaced with the name of the alert that triggered the notification. The Data variable reads data from a source that is external to Operations Manager.
Enable Notification Channels
To send notifications, Operations Manager 2007 can use a variety of mechanisms, such as e-mail, instant message, short message service, and pager. Choosing the delivery mechanism for the notification is called enabling a notification channel. The length and format of the message varies based on the media that receives the notification. The available notifications channels are e-mail, instant message, Short Message Service, and command. A command channel can run a script or executable file.
Operations Manager can accommodate different notification channels and endpoints with a variety of delivery protocols and formats. For example, some operators prefer to receive notifications on a pager, while others might prefer to receive notifications by e-mail. Operations Manager supports Session Initiation Protocol (SIP), which supports the transmission of messages through instant messages, and short message service (SMS), which supports the transmission of short text messages to and from mobile phones and other devices. In addition, you can configure a notification to run a command instead of or in addition to sending a notification message. A command can specify a path to an application or script that can perform basic functions. You can also use a command to integrate a custom delivery channel that is not supported by Operations Manager out of the box, such as a pager.
Create and Configure a Notification Action Account
The credentials of the Notification action account are used to create and send notifications. Ensure that the credentials for this account have sufficient rights to the servers that send notifications such as the SMTP server used for e-mail notifications or the instant messaging server.
Procedures
To create and configure the Notification action account
1. Log on to the computer with an account that is a member of the Operations Manager Administrators role for the Operations Manager 2007 management group.
Note
When you run the Operations console on a computer that is not a management server, the Connect To Server dialog box displays. In the Server name text box, type the name of the Operations Manager 2007 management server that you want the Operations console to connect to.
2. In the Operations console, click the Administration button.
3. In the Administration pane, right-click Security, and then click Create Run As Account. Use the Create Run As Account Wizard to create an account to use as the Notification action account, which is used to send the notifications.
- On the General page, click to select Windows from the Run As Account type drop-down list, and then in Display name, type Notification action account.
- On the Account page, type in the information for the User name password and domain of the user account that you are creating.
Note
For more information about the Create Run As Account Wizard, see How to Create a Run As Account in Operations Manager 2007 at http://go.microsoft.com/fwlink/?LinkId=95283.
4. In the Administration pane, click Run As Profiles.
5. In the details pane, right-click Notification Account, and then click Properties.
6. In Run As Profile Properties, click the Run As Accounts tab.
7. Click New, expand the Run As Account list, and then click Notification Action Account.
8. In the Matching Computers list, double-click the Root Management Server (RMS). Repeat this step for any other secondary management server that you want to use as secondary notification servers. If the RMS fails, the secondary server will send notifications. After all notification servers are on the list, click OK twice.
|
Enable an E-mail Notification Channel
Operations Manager 2007 notifications support sending e-mail through Simple Mail Transfer Protocol (SMTP).
Before you begin, gather the following information:
- SMTP Server information (from your SMTP administrator)
- Fully qualified domain name of the STMP server
- Port number for the STMP server
- Authentication method. You have two choices: Anonymous or Windows Integrated
- Return e-mail address. This address is used in all e-mail notifications and will receive any replies to notifications.
- E-mail subject text and body text. These are variables used to populate the subject and body of the e-mail with information unique to the alert.
Procedures
How to enable an e-mail notification channel
|
1. Log on to the computer with a user account that is a member of the Operations Manager Administrator role for the Operations Manager 2007 management group.
Note
When you run the Operations console on a computer that is not a management server, the Connect To Server dialog box displays. In the Server name text box, type the name of the Operations Manager 2007 management server that you want the Operations console to connect to.
2. In the Operations console, click the Administration button.
3. In the Administration pane, click Settings. In the Settings pane, right-click Notification, and then click Properties.
4. Click the E-mail tab, and then select the Enable e-mail notification check box.
Note
You can choose to enable a different type of notification channel, such as instant messaging, Short Messaging Service, or command by clicking on the tab by that name in the Notification properties dialog box.
5. In the SMTP servers area, click Add to display the Add SMTP server dialog box.
6. Type the fully qualified domain name (FQDN) of a Simple Mail Transfer Protocol (SMTP) server, type the port number, select the authentication method used by the SMTP server, and then click OK.
Note
You can add one or more additional servers to act as backup servers. If the primary SMTP server is unavailable, notifications are sent through the secondary server.
7. Type the Return Address that should appear on e-mail notifications, and then in the Retry primary after list, select the number of minutes to wait before trying to resend a notification to the primary SMTP server.
8. In the Default e-mail notification format area, specify the E-mail subject and E-mail message with wildcard parameters such as $Alert Source$ and $Alert Description$, and then specify the encoding type. You can click Placeholder for a full list of available variables.
If you receive notifications with missing or garbled text in the subject lines, select Generate subject line with no encoding (use if notification e-mails contain malformed subject lines. This option tells Operations Manager to send no encoding in the subject line; instead, the encoding from the SMTP server is used.
9. Click OK to return to the Operations console.
|
Enable an instant message notification channel
When you enable an instant message channel you can also specify the text of the message you want to send. A default message is already created for you. The default message includes both text and data variables. All lines of text that are contained within a set of dollar signs ($) are alert parameters and are replaced with the actual data from the alert that generated the notification. All text not contained within a set of dollar signs displays as is.
The following is the default instant message sent for alerts:
Alert: $Data/Context/DataItem/AlertName$
Priority: $Data/Context/DataItem/Priority$
Severity: $Data/Context/DataItem/Severity$
Path: $Data/Context/DataItem/ManagedEntityPath$
Resolution state: $Data/Context/DataItem/ResolutionStateName$
Last modified by: $Data/Context/DataItem/LastModifiedBy$
Before you begin, gather the following information from your instant message server (Live Communications Server):
- Fully qualified domain name
- Protocol used to send messages. You have two choices: TCP or Transport Layer Security (TLS)
- Port used for instant messages. The default is 5060.
- Encoding used by the instant message server and notification subscribers. The default is UTF-8.
- Return address to be used for the instant messages
Procedures
How to enable an instant message notification channel
|
1. Log on to the computer with a user account that is a member of the Operations Manager Administrator role for the Operations Manager 2007 management group.
Note
When you run the Operations console on a computer that is not a management server, the Connect To Server dialog box displays. In the Server name text box, type the name of an Operations Manager 2007 management server.
2. In the Operations console, click the Administration button.
3. In the Administration pane, click Settings. In the Settings pane, right-click Notification, and then click Properties.
4. Click the Instant Messaging tab, and then select the Enable instant messaging notifications check box.
5. In the IM server box, type the fully qualified domain name (FQDN) of an instant messaging server.
6. Type the Return Address that should appear on instant message notifications. Preface the address with sip:. In the Protocol option list, select either TCP or TLS (Transport Layer Security) as the protocol used to send the instant messages. In the Authentication method list, select either NTLM or Kerberos as the authentication method for users. In the IM port box, the default instant messaging port of 5060 is entered. Type the port number used to send instant messages.
Note
The return address should be a dedicated address used only for Systems Center Operations Manager notifications.
7. In the Default instant messaging notification format area, in the IM message box specify the text that is sent to notification subscribers. The IM message box contains a default message that includes text and variables. You can edit the default message or delete it and replace it with another message.
Note
The right arrow next to the IM message box displays a list of variables that you can add to the message. If you select a variable it is appended to the end of your current IM message with no spaces or explanatory text.
8. .In the Encoding box, select the text format that your IM server and notification subscribers use for transmission. By default, Unicode (UTF-8) is used. Click the arrow to view the entire list of available formatting.
9. Click OK to return to the Operations console.
|
Enable an SMS notification channel
When you enable an SMS channel you can also specify the text of the message you want to send. A default message is already created for you. The default message includes both text and data variables. All lines of text that are contained within a set of dollar signs ($) are alert parameters and are replaced with the actual data from the alert that generated the notification. All text not contained within a set of dollar signs displays as is.
Note
The modem used for SMS must support PDU mode. See Operations Manager 2007 Supported Configurations for information regarding supported hardware.
The following is the default Short Message Service (SMS) sent for alerts:
Alert: $Data/Context/DataItem/AlertName$
Priority: $Data/Context/DataItem/Priority$
Severity: $Data/Context/DataItem/Severity$
Path: $Data/Context/DataItem/ManagedEntityPath$
Resolution state: $Data/Context/DataItem/ResolutionStateName$
Last modified by: $Data/Context/DataItem/LastModifiedBy$
Procedures
To enable an SMS notification channel
|
1. Log on to the computer with a user account that is a member of the Operations Manager Administrator role for the Operations Manager 2007 management group.
Note
When you run the Operations console on a computer that is not a management server, the Connect To Server dialog box displays. In the Server name text box, type the name of an Operations Manager 2007 management server.
2. In the Operations console, click the Administration button.
3. In the Administration pane, click Settings. In the Settings pane, right-click Notification, and then click Properties.
4. Click the Short Message Service tab, and then select the Enable short message service notifications check box.
5. In the SMS message box, specify the text that is sent to SMS notification subscribers. The SMS message box contains a default message that includes text and variables. You can edit the default message or delete it and replace it with another message.
Note
The right arrow next to the SMS message box displays a list of variables that you can add to the message. If you select a variable it is appended to the end of your current IM message with no spaces or explanatory text.
6. In the Encoding box, select the text format for the SMS messages.
7. Click OK to return to the Operations console.
|
Enable a command notification channel
Command notifications differ from the other available notification channels. A command notification allows you to run an executable program automatically in response to an alert. Because you can run multiple commands in response to an alert you must assign a unique name to each command notification that you create.
Procedures
To enable a command notification
|
1. Log on to the computer with a user account that is a member of the Operations Manager Administrator role for the Operations Manager 2007 management group.
Note
When you run the Operations console on a computer that is not a management server, the Connect To Server dialog box displays. In the Server name text box, type the name of an Operations Manager 2007 management server.
2. In the Operations console, click the Administration button.
3. In the Administration pane, click Settings. In the Settings pane, right-click Notification, and then click Properties.
4. Click the Command tab, and then click Add. The Notification Command Channel dialog box displays.
5. Type a unique name for this command channel in the Notification command channel name box and a brief description in the Description box.
6. In the Notification command configuration area, type the path to the executable file that you want to run in the Full path to file box. For example, “%systemroot%\cmd.exe” or “c:\winnt\system32\cscript.exe”. Type any parameters that you want to run with this command in the Command line parameters box. Type the path of the directory used for any output of this command in the Initial directory box.
7. Click OK and then OK again to return to the Operations console.
|
Create Notification Recipients
A recipient is the user that receives the notification message. In Operations Manager 2007, there are three ways to define recipients: by list, membership, or subscription.
Compiling a list manually is the most straightforward way to define notification recipients. Use this approach if the list of recipients does not change. A less labor-intensive method to use is group membership. You can use group membership to determine who receives notification messages. Additionally, Active Directory accounts can store all contact information, including e-mail addresses, telephone numbers, and pager information. With Active Directory integration, Operations Manager 2007 is automatically informed of any change to the contact information of an account.
This procedure demonstrates how administrators configure recipients for e-mail notifications. A notification recipient defines when and from what devices notifications can be sent. You must first enable a notification channel before performing this procedure. After this procedure is complete you must create a notification subscription that defines the format of the notification message and any filters such as age or severity of the alert.
Procedures
To create a notification recipient (as an administrator)
|
1. Log on to the computer with an account that is a member of the Operations Manager Administrators role for the Operations Manager 2007 management group.
Note
When you run the Operations console on a computer that is not a management server, the Connect To Server dialog box displays. In the Server name text box, type the name of the Operations Manager 2007 management server that you want the Operations console to connect to.
2. In the Operations console, click the Administration button.
3. In the Administration pane, expand Notifications, right-click Recipients, and then click New Notification Recipient.
4. On the General tab, type a display name for this recipient. If you want to schedule when notifications should be sent, click Only send notifications during specified times and create a date range.
5. Click the Notification Devices tab.
6. Start the Create Notification Device Wizard by clicking the Add button.
7. Expand the Notification channel drop-down list, and then click E-mail.
8. In the Your address for the selected channel box type an e-mail address. For example, type e-m...@contoso.com. This is the e-mail address that is listed in the From box of each e-mail message that is sent to notification recipients.
9. On the Schedule page, you can leave the default schedule or you set a schedule that applies only to this notification, and then click Next.
10. On the General page, type a name for this notification device, and then click Finish.
11. Click Add to define another notification device. Otherwise click OK.
12. The new recipient displays in the Recipients pane.
|
To create a notification recipient (as a non-administrator)
|
1. Log on to the computer with an account that is a member of the Operators or Advanced Operators role for the Operations Manager 2007 management group.
Note
When you run the Operations console on a computer that is not a management server, the Connect to Server dialog box displays. In the Server Name text box, type the name of the Operations Manager 2007 management server that you want the Operations console to connect to.
2. In the Operations console, click Tools in the top menu bar, and then click My recipient information.
3. On the General tab, your current log in name is displayed. If you want to schedule when notifications should be sent, click Only send notifications during specified times and create a date range.
4. Click the Notification Devices tab.
5. Start the Create Notification Device Wizard by clicking the Add button.
6. Expand the Notification channel drop-down list, and then click E-mail.
7. In the Your address for the selected channel box type an e-mail address. For example, type e-m...@contoso.com. This is the e-mail address that is listed in the From box of each e-mail message that is sent to notification recipients.
8. On the Schedule page, you can leave the default schedule or you set a schedule that applies only to this notification, and then click Next.
9. On the General page, type a name for this notification device, and then click Finish.
10. Click OK.
|
Create Notification Subscriptions
Subscriptions are designed to decrease the overhead of configuring and maintaining a notification. An Operations Manager 2007 administrator or user first creates a subscription for a notification. In the subscription, the administrator or user specifies all the formats and devices that send the notifications. Users can then subscribe to this notification. While subscribing to a subscription, operators can specify how they prefer to receive the notification from the available notification channels, such as by e-mail or instant message, and whether they would like a long or short message.
The following procedures detail the steps needed to configure a subscription so that users assigned the Operator role can subscribe to specified alerts. A recipient can be an individual user account or a distribution list. Before beginning this procedure you must enable a notification channel and then create a notification recipient. There are two procedures – one performed by an administrator and one by a non-administrator.
Procedures
To create a notification subscription (as an administrator)
|
1. Log on to the computer with an account that is a member of the Operations Manager Administrators role for the Operations Manager 2007 management group.
Note
When you run the Operations console on a computer that is not a management server, the Connect To Server dialog box displays. In the Server name text box, type the name of the Operations Manager 2007 management server that you want the Operations console to connect to.
2. In the Operations console, click the Administration button.
3. In the Administration pane, expand Notifications, right-click Subscriptions, and then click New Notification Subscription. The Create Notification Subscription Wizard starts.
4. On the Introduction page, click Next.
5. On the General page, in Subscription name, type a descriptive name for the subscription, type a short description, and then click Add.
6. The Add Notification Recipients dialog box displays all notification recipients were previously created. Click each recipient that you want to include in this subscription, click OK, and then click Next.
7. On the User Role Filter page, if you want to limit the users that can subscribe to this notification subscription select Available groups and classes filtered by role, select a user role, and then click Next.
8. On the Groups page, by default, all groups are selected to receive notifications. If you want to limit the groups that receive notifications, click to deselect the top-level group, and then click to select the groups. Otherwise, click Next.
9. If you want to filter notifications so that only notifications of selected object types are sent click Only classes explicitly added to the Approved classes grid are approved, and then click Add to create a list of object types. Click Next.
10. On the Alert Criteria page, verify that the desired severity, priority, and resolution states are selected for notification. Verify that the desired category is selected, and then click Next.
11. On the Alert Aging page, click Use alert aging as a notification criteria if you want to use alert aging, otherwise click Next.
12. On the Formats page, if you want to customize the format of the e-mail sent for notification click Use this custom e-mail format, and then define the custom e-mail format. Otherwise, click Finish.
|
To create a notification subscription (as a non-administrator)
|
1. Log on to the computer with an account that is a member of the Operations Manager Operator or Advanced Operator role for the Operations Manager 2007 management group.
2. In the Operations console, click Tools, and then click My Notifications.
3. On the Introduction page, click Next.
4. On the Groups page, if you want to limit the groups that receive notifications, click to select the groups. Otherwise, click Next.
5. If you want to filter notifications so that only notifications of selected object types are sent click Only classes explicitly added to the Approved classes grid are approved, and then click Add to create a list of object types. Click Next.
6. On the Alert Criteria page, verify that the desired severity, priority, and resolution states are selected for notification. Verify that the desired category is selected, and then click Next.
7. On the Alert Aging page, click Use alert aging as a notification criteria if you want to use alert aging, otherwise click Next.
8. On the Formats page, if you want to customize the format of the e-mail sent for notification click Use this custom e-mail format, and then define the custom e-mail format. Otherwise, click Finish.
|
Start Monitoring
This section steps you through the process for deploying agents, working with management packs, and working with alerts. After these tasks are complete, your management group will automatically deploy the correct management packs to the correct computers and monitoring will begin.
Also, this section describes the configuration of the Customer Experience Improvement Program (CEIP), client monitoring options, and error reporting.
Deploying Agents in Operations Manager 2007
To begin monitoring your environment, you need to decide what applications and devices you want to monitor. Then you can identify the computers that support those applications. Operations Manager 2007 provides two methods for monitoring Windows-based computers: agent-managed or agentless managaged.
- Agent-Managed
Agent-managed computers have an Operations Manager service installed. This service, which appears as HealthService in the Services list in Computer Management is the Operations Manager agent. Monitoring computers via agents allows access to all Operations Manager options and functionality, and therefore the vast majority of monitoring is performed this way. Agents are also a key component of agentless management.
- Agentless Managed
Monitoring without an agent is an option for Windows-based computers where an agent cannot be installed. Agents can agentlessly manage a computer by proxying communications between a management group and the computer that is being managed in an agentless fashion.
- Managing Network Devices
Network devices and systems not running Windows can be supported without agents.
The first step in monitoring your environment is to deploy agents. Your network architecture will greatly influence which monitoring options to use and in planning how to deploy your agents. Be aware whether you are managing systems on the other side of a firewall or if you managing systems on an untrusted network.
Note
If you add or delete a new virtual server on a cluster after an Operations Manager 2007 agent is installed, the agent does not recognize the changes and new virtual servers are not reported. Restart the OpsMgr Health Service on the node where the virtual server is active.
After agents have been installed on managed computers and Operations Manager is configured to manage them, Operations Manager will start monitoring them as soon as the relevant management packs have been imported. We recommend a phased deployment of agents so that management packs can be customized to your needs. The alternative – deploying agents widely before customizing management packs – could create a large number of useless alerts, called noise alerts, during your rollout.
Using the Discovery Wizard for Deploying Agents
Operations Manager 2007 includes a tool for deploying agents called the Discovery Wizard. The Discovery Wizard is the easiest way to find systems to be managed and to install agents.
The Discover Wizard does not show systems that the management group is already monitoring. If you are doing a phased rollout of your management group, you can run the wizard to add new systems to the group. Also, after your initial deployment, you can use the Discovery Wizard to add newly installed computers to be managed.
When agents are pushed out to computers, Operations Manager 2007 sends the local administrator credentials required to install the agent. This could raise security concerns. Consult the Operations Manager 2007 Security Guide for security issues before you use the Discovery Wizard.
If the Discovery Wizard is not right for your needs, you have the option of manually installing agents on systems to be managed. Agents can also be embedded in the host image of the monitored computer.
Using the Discovery Wizard to Deploy Agentless Management
Windows-based systems where an agent cannot be installed can be managed without an agent. This is called agentless management.
Note
Not all management packs support agentless management, so make sure it will serve your needs before using agentless management. In particular, the Active Directory management pack and the Exchange Server 2003 management pack do not support agentless management.
Agentless management of computers is different from Agentless Exception Monitoring. Though similar in name, Agentless Exception Monitoring is used to aggregate, view, and report on error reports sent by the Windows Error Reporting service.
The Discovery Wizard can find and set up systems for agentless management. The process is almost the same as for deploying. You do, however, have to select a proxy for each agentless managed system.
A proxy is a system with an agent used to monitor an agentless system. A management group can serve as a proxy, but this takes up system resources. We recommend using an agent managed system as a proxy. This system must be set up for management before running the Discovery Wizard to establish agentless management.
Note
If a proxy is removed from management, its agentless systems are no longer managed.
Note
When monitoring virtual servers on a cluster, you must deploy agents to the cluster nodes, configure them to manage as a proxy and then monitor the virtual servers in agent less fashion.
Both the agentless managed system and its proxy need to have access to the managing server through any firewalls. For more information about interacting with firewalls, see the Operations Manager 2007 Security Guide and the Operations Manager 2007 Help.
Using the Discovery Wizard for Network Devices
The Discovery Wizard can find network devices for management.
Network devices and systems not running Windows require a proxy, just like agentless managed computers. A management group can act as a proxy, but that configuration requires more system resources. We recommend using a system with an agent as a proxy.
Both the network device and the proxy need to have access to the management group through any firewalls. For more information about interacting with firewalls, see the Operations Manager 2007 Security Guide and the Operations Manager 2007 Help.
Deploy Agents
The first step in monitoring your environment is to deploy agents. Your network architecture will greatly influence which monitoring options you use and how you plan the deployment your agents. Be aware of whether you are managing systems on the other side of a firewall from your management group or managing systems that don’t participate in a Kerberos trust with the management group.
Note
If you add or delete a new virtual server on a cluster after an Operations Manager 2007 agent is installed, the agent does not recognize the changes and new virtual servers are not reported. Restart the OpsMgr Health Service on the node where the virtual server is active.
You can use any of the following methods to deploy agents:
- The Discovery Wizard (through the Operations console)
- The Agent Setup Wizard
- The MOMAgent.msi program from the command line
- Active Directory to assign agents to a management group
The following sections provide detailed steps for each of these methods.
Using the Discovery Wizard to Deploy Agents
You can use the Operations console to search your environment for manageable objects and then deploy an agent to any object that you want to monitor. The process of searching your environment is called “discovery.” One of the advantages of using discovery is that it lists all manageable objects, including any that you might not be aware of.
The Discovery Wizard does not show systems that the management group is already monitoring. If you are doing a phased rollout of your management group, you can run the wizard to add new systems to the group. Also, after your initial deployment, you can use the Discovery Wizard to add newly installed computers to be managed.
When agents are pushed out to computers, Operations Manager 2007 sends credentials that have local administrator rights for that computer; this is required to install the agent. Sending credentials could raise security concerns. Consult the Operations Manager 2007 Security Guide for information to help you address any security issues before you use the Discovery Wizard.
If the Discovery Wizard is not right for your needs (for example, if you have a set list of computers to which you want to deploy agents), you have the option of manually installing agents on systems to be managed. Agents can also be embedded in the host image of the monitored computer.
Use the following procedure to discover Windows-based computers and to deploy the Operations Manager 2007 agent to them from the Operations console.
Procedures
To deploy the Operations Manager 2007 agent to Windows-based computers from the Operations console
1. Log into the Operations console with an account that is a member of the Operations Manager Administrators role for the Operations Manager 2007 management group.
2. Click the Administration button.
3. At the bottom of the navigation pane, click Discovery Wizard.
4. On the Introduction page, click Next. The Introduction page does not appear if the Computer and Device Management Wizard has been run before and Do not show this page again was selected.
5. On the Auto or Advanced? page, do the following:
a. Select either Automatic computer discovery or Advanced discovery. If you select Automatic computer discovery, click Next, and then go to step 7. If you select Advanced discovery, continue with the following steps.
Note
Automatic computer discovery scans for Windows-based computers in the domain that the root management server is in. Advanced discovery allows you to specify criteria for the computers that the wizard will return, such as computer names starting with NY.
b. In the Computer & Device Types list, select Servers & Clients, Server Only, or Clients Only.
c. In the Management Server list, click the management server or gateway server to discover the computers. When multiple management servers are in a management group, the agents are automatically configured to use secondary management servers if their root management server is unavailable.
d. If you selected Servers & Clients, you can select the Verify discovered computers can be contacted check box. This is likely to increase the success rate of agent deployment, but discovery can take longer.
Note
If the Active Directory catalog does not contain the NetBIOS names for computers in a domain, select Verify discovered computers can be contacted. Otherwise, the Browse, or Type In option will fail to find computers. This affects computers in the same domain as the root management server, in another domain with a full trust relationship, and in untrusted domains using a gateway server.
e. Click Next.
Note
The wizard can return approximately 4000 computers if Verify discovered computers can be contacted is selected, and can return 10,000 computers if it is not selected. Automatic computer discovery verifies that discovered computers can be contacted. A computer that is already managed by the management group is not returned.
6. On the Discovery Method page, you can locate the computers that you want to manage by either scanning or browsing Active Directory Domain Services or typing the computer names.
If you want to scan, do the following:
a. If it is not already selected, select Scan Active Directory and then click Configure.
b. In the Find Computers dialog box, type the criteria that you want to use for discovering computers and then click OK.
c. In the Domain list, click the domain of the computers that you want to discover.
If you want to browse Active Directory or type the computer names, do the following:
- Select Browse for, or type-in computer names, click Browse, specify the names of the computers that you want to manage, and then click OK.
- In the Browse for, or type-in computer names box, type the computer names, separated by semi-colon, comma, or a new line [ENTER]. You can use NetBIOS computer names or fully qualified domain names (FQDN).
7. Click Next, and on the Administrator Account page, do one of the following:
- Select Use selected Management Server Action Account if it is not already selected.
- Select Other user account, type the User name and Password, and then select the Domain from the list. If the User name is not a domain account, select This is a local computer account, not a domain account.
Important
The account must have administrative privileges on the targeted computers. If This is a local computer account, not a domain account is selected, the Management Server Action Account will be used to perform discovery. For more information about Operations Manager 2007 accounts, see the Operations Manager 2007 Security Guide.
8. Click Discover to display the Discovery Progress page. The time it takes discovery to finish depends on many factors, such as the criteria specified and the configuration of the IT environment.
Note
Computers that are already managed by the management group will not be returned by the wizard.
9. On the Select Objects to Manage page, do the following:
a. Select the computers that you want to be agent-managed computers.
b. In the Management Mode list, click Agent and then click Next.
Note
Computer Discovery shows virtual nodes of clusters. Do not select any virtual nodes to be managed.
10. On the Summary page, do the following:
a. Leave the Agent installation directory set to the default of %ProgramFiles%\System Center Operations Manager 2007 or type an installation path.
Important
If a different Agent installation directory is specified, the root of the path must exist on the targeted computer or the agent installation fails. Subdirectories, such as OM2007\Agent, are created if they do not exist.
b. Leave Agent Action Account set to the default, Local System, or select Other and type the User name, Password, and Domain. The Agent Action Account is the default account that the agent will use to perform actions. For more information about Operations Manager 2007 accounts, see the Operations Manager 2007 Security Guide.
c. Click Finish.
11. In the Agent Management Task Status dialog box, the Status for each selected computer changes from Queued to Success; the computers are ready to be managed.
Note
If the task fails for a computer, click the targeted computer. The reason for the failure is displayed in the Task Output text box.
12. Click Close.
|
Use the Agent Setup Wizard
Use the following procedure to deploy the Operations Manager 2007 agent with the MOMAgent.msi setup wizard.
Before you use the setup wizard, ensure the following:
- Each agent that is installed with the wizard must be approved by a management group. For more information, see Process Manual Agent Installations in Operations Manager 2007.
- If an agent is manually deployed to a domain controller, and an Active Directory management pack is later deployed, errors might occur during deployment of the management pack. To prevent errors from occurring before deploying the Active Directory management pack, or to recover from errors that might have already occurred, you will need to deploy the Active Directory management pack helper object by deploying the file Oomads.msi on the affected domain controller. The file Oomads.msi is on the computer that is hosting the agent at C:\Program Files\System Center Operations Manager 2007\HelperObjects. For more information, see the section “Agent-Managed Domain Controllers” in the topic Process Manual Agent Installations in Operations Manager 2007
Procedures
To deploy the Operations Manager 2007 agent with the Agent Setup Wizard
1. Use local administrator privileges to log on to the computer where you want to install the agent.
2. On the Operations Manager 2007 installation media, double-click the SetupOM.exe file.
3. On the Start page, select Install Operations Manager 2007 Agent.
4. On the Welcome page, click Next.
5. On the Destination Folder page, leave the installation folder set to the default, or click Change and type a path, and then click Next.
6. On the Management Group Configuration page, do one of the following:
- Leave the Specify Management Group information check box selected, and then click Next.
- Clear the Specify Management Group information check box if management group information has been published to Active Directory Domain Services, and then click Next.
Note
Step 7 is bypassed by the Agent Setup Wizard if the Specify Management Group information check box is cleared.
7. On the Management Group Configuration page, do the following:
a. Type the Management Group Name and Management Server name.
Note
To use a gateway server, enter the gateway server name in the Management Server text box. For more information about gateway servers, see the Operations Manager 2007 Security Guide.
b. Type the Management Server Port, or leave the default 5273.
c. Click Next.
8. When the Agent Action Account page appears, leave it set to the default of Local System, or select Domain or Local Computer Account, type the User Account, Password, and Domain or local computer, and then click Next.
Note
For information about Operations Manager 2007 accounts, see the Operations Manager 2007 Security Guide.
9. On the Ready to Install page, review the settings and then click Install to display the Installing Systems Center Operations Manager Agent page.
10. When the Completing the Systems Center Operations Manager Agent Setup Wizard page appears, click Finish.
|
Use the Command Line to Deploy Agents
You can use the MOMAgent.msi executable to deploy agents from the command line. Deploying agents from the command line is also referred to as a manual install.
Before you begin deployment, ensure the following:
- The account that is used to run MOMAgent.msi must have administrative privileges on the targeted computers.
- A management group (or single management server) must be configured to accept agents installed with MOMAgent.msi or they will be automatically rejected and therefore not display in the Operations console. For more information, see Process Manual Agent Installations in Operations Manager 2007. If the management group or server is configured to accept manually installed agents after the agents have been manually installed, the agents will display in the console after approximately one hour.
- If an agent is manually deployed to a domain controller, and an Active Directory management pack is later deployed, errors might occur during deployment of the management pack. To prevent errors from occurring before deploying the Active Directory management pack, or to recover from errors that might have already occurred, you will need to deploy the Active Directory management pack helper object by deploying the file Oomads.msi on the affected domain controller. The file Oomads.msi is on the computer that is hosting the agent at C:\Program Files\System Center Operations Manager 2007\HelperObjects. For more information, see the section “Agent-Managed Domain Controllers” in the topic Process Manual Agent Installations in Operations Manager 2007
- Each agent that is installed with MOMAgent.msi must be approved for a management group. For more information, see Process Manual Agent Installations in Operations Manager 2007.
MOMAgent.msi can be found in the Operations Manager 2007 installation media and the Management Server installation directory.
The command-line example uses Active Directory Domain Services to assign computers to management groups.
Procedures
To deploy the Operations Manager 2007 agent from the command line
|
1. Log onto the computer where you want to install the agent by using an account with local administrator privileges.
2. Open a command window.
3. Run the following command:
%WinDir%\System32\msiexec.exe /i \\path\Directory\MOMAgent.msi /qn USE_SETTINGS_FROM_AD=0 MANAGEMENT_GROUP=MG1 MANAGEMENT_SERVER_DNS=MS1.Domain1.net SECURE_PORT=Port Number ACTIONS_USE_COMPUTER_ACCOUNT=0 ACTIONSUSER=AgentAction ACTIONSDOMAIN=Domain1 ACTIONSPASSWORD=Password#2007
where:
|
USE_SETTINGS_FROM_AD=0
|
Indicates that management group settings properties will be set on the command line
|
|
MANAGEMENT_GROUP=MG1
|
Sets the management group the computer will be managed by to MG1.
|
|
MANAGEMENT_SERVER_DNS=MS1.Domain1.net
|
Sets the management server FQDN to MS1.Domain1.net (). To use a gateway server, enter the gateway server FQDN as MANAGEMENT_SERVER_DNS.
Important
If the computer’s DNS and Active Directory names differ, the MANAGEMENT_SERVER_AD_NAME property would also need to be set to the fully qualified Active Directory Domain Services name.
|
|
SECURE_PORT
|
Sets the health service port number.
|
|
ACTIONS_USE_COMPUTER_ACCOUNT=0
|
Sets the Agent Action account to a specified user account, instead of to Local System.
|
|
ACTIONSUSER=AgentAction
|
Sets the Agent Action account to AgentAction.
|
|
ACTIONSDOMAIN= Domain1
|
Sets the Agent Action account domain to Domain1.
|
|
ACTIONSPASSWORD= Password#2007
|
Sets the Agent Action account password to Password#2007.
|
|
Use Active Directory to Assign Computers
You can use Active Directory Domain Services to assign agent-managed computers to management groups. To assign computers to management groups by using Active Directory Domain Services:
- The functional level of Active Directory Domain Services domains must be Windows 2000 native or Windows Server 2003.
- Agent-managed computers and the root management server must be in the same or two-way trusted domains.
Note
Regardless of whether Active Directory Domain Services is used to assign computers to a management group, agent-managed computers and their root management server and secondary management server must be in the same domain or in two-way trusted domains, or a gateway server must be used. For more information about gateway servers, see the Operations Manager 2007 Security Guide.
Configuring agents to get their management group information from Active Directory Domain Services is also helpful if your organization uses images to deploy computers. For example, add the Operations Manager 2007 agent to the SQL Server 2005 image and configure the agent to get its management group information from Active Directory. When you initialize a new server running SQL Server 2005 from an image, the server is automatically configured to be managed by the appropriate Operations Manager 2007 management group and download the applicable management packs.
When Active Directory Domain Services assigns computers to Operations Manager 2007 management groups, the following phrases are used:
1. A domain administrator uses MOMADAdmin.exe to create an Active Directory Domain Services container for an Operations Manager 2007 management group in the domains of the computers it will manage. The Active Directory Domain Services security group that is specified when you are running MOMADAdmin.exe is granted read and delete child permissions to the container. By creating a container this way, Operations Manager administrators are given the necessary permission to add management servers to the container and assign computers to them, without needing to be domain administrators.
2. An Operations Manager administrator assigns computers to the root management server and secondary management server. For more information, see How to Use Active Directory to Assign Computers to Operations Manager 2007 Management Servers in the next section.
3. The Operations Manager 2007 agent is deployed to the computers that you want and configured to get its management group information from Active Directory by using MOMAgent.msi. See Use the Command Line to Deploy Agents for information.
Note
Active Directory Integration is disabled for agents that were installed from the Operations console. By default, Active Directory Integration is enabled for agents installed manually by using MOMAgent.msi. To disable Active Directory Integration for manual installations, use the command-line parameter USE_SETTINGS_FROM_AD=0 as it is explained in Use the Command Line to Deploy Agents.
How to Use Active Directory to Assign Computers to Operations Manager 2007 Management Servers
The Operations Manager 2007 Agent Assignment and Failover Wizard creates an agent assignment rule that uses Active Directory Domain Services to assign computers to a management group and assign the computers’ primary management server and secondary management servers. Use the following procedures to start and use the wizard.
Note
The Agent Assignment and Failover Wizard does not deploy the agent. You must deploy the agent to the computers by using MOMAgent.msi.
Changing the agent assignment rule can result in computers no longer being assigned to, and therefore monitored by, the management group. The state of these computers will change to critical, because the computers no longer send heartbeats to the management group. These computers can be deleted from the management group and, if the computer is not assigned to other management groups, the Operations Manager 2007 agent can be uninstalled.
To start the Operations Manager 2007 Agent Assignment and Failover Wizard
|
1. Log on to the Operations console with an account that is a member of the Operations Manager Administrators role for the Operations Manager 2007 management group.
2. Click the Administration button.
Note
When you run the Operations console on a computer that is not a management server, the ConnectToServer dialog box appears. In the Servername text box, type the name of the Operations Manager management server that you want the Operations console to connect to. In the EnterCredential dialog box, type a Username, Password, and Domain for the management group.
3. In the Administration pane, expand Administration, expand DeviceManagement, and then click ManagementServers.
4. In the Management Servers pane, right-click the management server or gateway server to be PrimaryManagementServer for the computers that are returned by the rules you will create in the following procedure, and then click Properties.
5. In the ManagementServerProperties dialog box, click the AgentManagement tab, and then click Add to start the Agent Assignment and Failover Wizard.
|
To use the Operations Manager 2007 Agent Assignment and Failover Wizard to assign computers to a management group
1. In the Agent Assignment and Failover Wizard, on the Introduction page, click Next.
Note
The Introduction page does not appear if the wizard has been run and Do not show this page again was selected.
2. On the Domain page, do the following:
Note
To assign computers from multiple domains to a management group, run the Agent Assignment and Failover Wizard for each domain.
- Select the domain of the computers from the Domain name drop-down list. The management server must be able to resolve the domain name.
Important
The management server and the computers that you want to manage must be in two-way trusted domains.
- Set Select Run As Profile to the Run As profile associated with the Run As account that was provided when MOMADAdmin.exe was run for the domain. The default account that is used to perform agent assignment is the computer account for the root management server, also referred to as the Active Directory Based Agent Assignment Account. If this was not the account that was used to run MOMADAdmin.exe, select Use a different account to perform agent assignment in the specified domain, and then select or create the account from the Select Run As Profile drop-down list.
Note
For more information about Run As Profiles and Run As Accounts, see the Operations Manager 2007 Security Guide.
3. On the Inclusion Criteria page, either type the LDAP query for assigning computers to this management server in the text box and then click Next, or click Configure. If you click Configure, do the following:
a. In the Find Computers dialog box, type the criteria that you want to use for assigning computers to this management server.
b. Click OK, and then click Next.
Note
The following LDAP query will return computers with a name starting with MsgOps, (&(sAMAccountType=805306369)(objectCategory=computer)(cn=MsgOps*)) For more information about LDAP queries, see http://go.microsoft.com/fwlink/?LinkId=73366.
4. On the Exclusion Rule page, type the FQDN of computers that you explicitly want to prevent from being managed by this management server, and then click Next.
Important
You must separate the computer FQDNs that you type with a semicolon, colon, or a new line (CTRL+ENTER).
5. On the Agent Failover page, either select Automatically manage failover and click Create or select Manually configure failover. If you select Manually configure failover, do the following:
a. Clear the check boxes of the management servers to which you do not want the agents to fail over.
b. Click Create.
Note
With the Manually configure failover option, you must run the wizard again if you subsequently add a management server to the management group and want the agents to fail over to the new management server.
6. In the Management Server Properties dialog box, click OK.
Note
It can take up to one hour for the agent assignment setting to propagate in Active Directory Domain Services.
|
Process Manual Agent Installations in Operations Manager 2007
Manual installation of an agent refers to the process of running MOMAgent.msi locally on a computer that is to host an Operations Manager 2007 agent. When it is installed, the agent will attempt to join the specified management group by contacting a specified management server. You can use security settings at both the management group and the management server level to configure how requests from manually installed agents will be processed.
The following three options are available to process manually installed agents.
|
Option
|
Action
|
|
Reject new manual agent installations
|
Designates that all requests from a manually installed agent will be denied by Operations Manager 2007. This is the most secure setting and is selected by default.
|
|
Review new manual agent installations in pending management view
|
Designates that all requests from a manually installed agent will be directed to the Pending Management node before being allowed to join the management group. An administrator must first review the request and manually approve the agents’ request.
|
|
Auto-approve new manually installed agents
|
This option is available only if Review new manual agent installations in pending management view has been selected. This setting causes Operations Manager 2007 to automatically allow any manually installed agent to join the management group. This is the least secure option.
|
Important
A management group or management server must be configured to accept agents that are installed with MOMAgent.msi or they will be automatically rejected and therefore not displayed in the Operations console. If a management group is configured to accept manually installed agents, the agents will display in the console approximately one hour after they are installed.
The following procedures show you how to configure security settings for manual agent installations.
How to configure security for manual agent installations for the management group
Use the following procedure to configure a management group to accept or deny agents that are installed manually.
To configure manual agent installations settings for a management group
1. Log on to the Operations console with an account that is a member of the Operations Manager Administrators role for the Operations Manager 2007 management group.
2. Click the Administration button.
Note
When you run the Operations console on a computer that is not a management server the Connect To Server dialog box will appear. In the Server name text box, type the name of the Operations Manager 2007 management server that you want the Operations console to connect to.
3. In the Administration pane, expand Administration, and then click Settings.
4. In the Settings pane, expand Type: Server, right-click Security, and then click Properties.
5. In the Global Management Server Settings – Security dialog box, on the General tab, do one of the following:
- To maintain a higher level of security, select Reject new manual agent installations, and then click OK.
- To configure for manual agent installation, click Review new manual agent installations in pending management view, and then click OK. For more information about manual agent installations, see the How to approve a pending agent installation section later in this topic.
- Optionally, select Auto-approve new manually installed agents.
|
How to override manual agent settings on a management server
Use the following procedure to override the management group Manual Agent Installs setting and configure the setting for a specific management server.
To override the manual agent installs setting for a management server
1. Log on to the Operations console with an account that is a member of the Operations Manager Administrators role for the Operations Manager 2007 management group.
2. Click the Administration button.
Note
When you run the Operations console on a computer that is not a management server, the Connect To Server dialog box appears. In the Server name text box, type the name of the Operations Manager 2007 management server that you want the Operations console to connect to.
3. In the Administration pane, expand Administration, expand Device Management, and then click Management Servers.
4. In the results pane, right-click the management server that you want to view the properties of, and then click Properties.
5. In the Management Server Properties dialog box, click the Security tab.
6. On the Security tab, do the following:
- To maintain a higher level of security, select Reject new manual agent installations, and then click OK.
- To configure for manual agent installation, click Review new manual agent installations in pending management view, and then click OK.
- Optionally, select Auto-approve new manually installed agents.
7. Click OK.
|
How to approve a pending agent installation
Use the following procedure to approve an Operations Manager 2007 agent installed for a management group with MOMAgent.msi. This procedure is not needed if the management group has been configured to automatically approve manually installed agents.
To approve a pending agent installation
|
1. In the Operations console, click Administration.
2. Click Administration, expand Administration, expand Device Management, and then click Pending Management.
3. In the Pending Management pane, select computers in Type: Manual Agent Install.
4. Right-click the computers, and then click Approve.
5. In the Manual Agent Install dialog box, click Approve. The computers now appear in the Agent Managed node and are ready to be managed.
Note
Rejected agents remain in Pending Management until the agent is uninstalled for the management group.
|
Work with Agents
After you have installed agents on the managed computers in your environment and configured Operations Manager to manage them, Operations Manager begins collecting monitoring data as soon as you import management packs (as discussed in How to Import a Management Pack in Operations Manager 2007 [OpsMgr07]). Aside from managing the data collected, there are a number of administrative tasks regarding agents. The following sections discuss those tasks.
Understanding Agent States
You can view the state (or health) of an agent in the Agent Health State View. The agent state is relayed by the Health Service Watcher, which monitors the status of agents. You can get more information about the state of an agent by going to the Health Service Watcher view.
An agent can have one of the following states:
|
State
|
Description
|
|
Healthy – green check
|
The agent is running normally.
|
|
Critical – red check
|
There is a problem on the agent.
|
|
Unknown – gray agent. The check mark and agent name are grayed out.
|
The health service watcher on the RMS that is watching the health service on the monitored computer is not receiving heartbeats from the agent anymore. It had been receiving them previously (and it was reported as healthy), but now it is not. This also means that the management servers are no longer receiving any information from the agent at all.
The computer running the agent might be down, or there might be connectivity issues. You can find more information on the Health Service Watcher view.
|
Heartbeat and Heartbeat Failure Settings in Operations Manager 2007
An agent sends a packet of data to its management server on a periodic basis; by default once every 60 seconds. This packet of data is called the heartbeat. By default, a management server can tolerate three missed heartbeats. If the management server registers four missed heartbeats, the management server will attempt to diagnose the problem by pinging the agent computer. If the ping is successful, an alert will be generated against the health service on the agent computer. If the ping is unsuccessful, an alert will be generated indicating that the computer is no longer available.
If the management server and the agent are separated by a slow connection, it might be normal for three minutes to pass without the management server receiving a heartbeat. To prevent unnecessary alerts, you can increase the number of missed heartbeats that a management server will tolerate.
It is also possible that you might be monitoring critical applications in your environment and service-level agreements might not allow waiting three minutes before alerts are generated. In this situation, you can decrease the heartbeat interval thus increasing how often an agent sends a heartbeat.
There are two settings you can adjust that relate to the heartbeat: heartbeat interval and number of missed heartbeats. Heartbeat interval refers to how often an agent sends a heartbeat. Number of missed heartbeats refers to how many heartbeats a management server will tolerate before running a diagnostic ping. Heartbeat interval and number of missed heartbeats can be configured at a global level affecting every agent and management server in the management group. In addition, the number of missed heartbeats can be overridden at the management server level and heartbeat interval can be overridden at the agent level.
In addition to using these options for failure settings, you also have the option of disabling heartbeat monitoring for all agents or for specified agents:
- That connect to the network intermittently.
- That connect to the network over poor connections or use dial-up connections.
- On systems that are frequently restarted.
Global Heartbeat Settings
The following heartbeat settings are set at a global level and affect all management servers and agents in the management group.
How to Globally Change the Heartbeat Interval
The following procedure shows how to change the heartbeat interval at the global level. Changes made in this procedure will affect all the agents in the management group.
To configure agent heartbeat interval settings
|
1. Log on to the computer with an account that is a member of the Operations Manager Administrators role for the Operations Manager 2007 management group.
2. In the Operations console, click the Administration button.
Note
When you run the Operations console on a computer that is not a management server, the Connect To Server dialog box appears. In the Server name text box, type the name of the Operations Manager 2007 management server that you want the Operations console to connect to.
3. In the Administration pane, expand Administration, and then click Settings.
4. In the Settings pane, expand Type: Agent, right-click Heartbeat, and then click Properties.
5. In the Global Agent Settings – Heartbeat dialog box, on the General tab, enter a value in the Heartbeat interval box to specify how often an agent generates a heartbeat, and then click OK.
Note
The maximum value is 86,400 seconds (1 day). The minimum value is 5 seconds.
|
How to Globally Change the Number of Missed Heartbeats a Management Server Will Tolerate
The following procedure shows how to change the number of missed heartbeats at the global level. Changes made in this procedure affect all the management servers in the management group.
To change the number of missed heartbeats a management server will tolerate
|
1. Log on to the Operations console with an account that is a member of the Operations Manager Administrators role for the Operations Manager 2007 management group.
2. Click the Administration button.
Note
When you run the Operations console on a computer that is not a management server the Connect To Server dialog box will appear. In the Server name text box, type the name of the Operations Manager 2007 management server that you want the Operations console to connect to.
3. In the Administration pane, expand Administration, and then click Settings.
4. In the Settings pane, expand Type: Server, right-click Heartbeat, and then click Properties.
5. In the Global Management Server Settings – Heartbeat dialog box, on the General tab, in the Number of missing heartbeats allowed, enter or select the number of missing heartbeats management server will allow before it starts to ping the agent.
Note
The maximum value allowed for the number of missing heartbeats is 100. The minimum value allowed is 1.
|
Management Server- Heartbeat Settings and Agent-Specific Heartbeat Settings
The following heartbeat settings can be configured on a per-management server basis.
How to Override the Heartbeat Interval
Use the following procedure to override the agent heartbeat interval settings for a specific agent.
To override the heartbeat interval setting
|
1. Log on to the Operations console with an account that is a member of the Operations Manager Administrators role for the Operations Manager 2007 management group.
2. Click the Administration button.
Note
When you run the Operations console on a computer that is not a management server, the Connect To Server dialog box appears. In the Server name text box, type the name of the Operations Manager 2007 management server that you want the Operations console to connect to.
3. In the Administration pane, expand Administration, expand Device Management, and then click Agent Managed.
4. In the results pane, right-click the object that you want to view the properties of, and then click Properties.
5. In the Agent Properties dialog box, select Override global server settings.
6. Change the Heartbeat interval. The maximum value allowed for the heartbeat interval is 86,400 seconds (1 day). The minimum value allowed is 5 seconds.
7. Click OK.
|
How to Override the Number of Missed Heartbeats a Management Server Will Tolerate
Use the following procedure to override the management group heartbeat failure setting and configure the number of missed heartbeats a specific management server will allow for an agent before it changes the state of the respective computer.
To override the number of missed heartbeats
|
1. Log on to the Operations console with an account that is a member of the Operations Manager Administrators role for the Operations Manager 2007 management group.
2. Click the Administration button.
Note
When you run the Operations console on a computer that is not a management server, the Connect To Server dialog box appears. In the Server name text box, type the name of the Operations Manager 2007 management server that you want the Operations console to connect to.
3. In the Administration pane, expand Administration, expand Device Management, and then click Management Servers.
4. In the Management Server Properties dialog box, click the Heartbeat tab.
5. On the Heartbeat tab, do the following:
a. Select Override global server settings.
b. Change the Number of missing heartbeats to the number that you want.
6. Click OK.
|
Disabling Heartbeat Monitoring
You can disable heartbeat monitoring for all agents or for specified agents.
To disable monitoring for all agents
|
1. Click Authoring to open the Authoring area.
2. Expand Management Pack Objects, and then click Monitors.
3. Find and right-click the Health Service Heartbeat Failure monitor for Health Service Watcher (Agent).
Note
You can also use Find Now to find the monitor.
4. On the shortcut menu, point to Overrides, point to Disable the Monitor, and then click For all objects of the type: Health Service Watcher (Agent).
5. Expand Management Pack Objects, and then click Rules.
6. Find and right-click Heartbeat Failure – Success under Health Service Watcher Group (Agent).
7. On the shortcut menu, point to Overrides, point to Disable the Rule, and then click For all objects of the type: Health Service Watcher (Agent).
8. Repeat the steps 6 through 7 to disable the rules Heartbeat Failure – Warning and Heartbeat Failure – Error.
|
To disable monitoring for a subset of managed systems, create a group by using the Create Group Wizard. For instance, to disable monitoring for the systems Server01.contoso.com, Server78.contoso.com, and Server99.contoso.com, create a group called Heartbeat Monitor Disabled Agents containing members of the type Health Service Watcher Group (Agent) and add the systems to that group.
For information about creating groups, see How to Create Groups in Operations Manager 2007.
To disable monitoring for a group of agents
|
1. Click Authoring to open the Authoring area.
2. Expand Management Pack Objects, and then click Monitors.
3. Find and right-click the Health Service Heartbeat Failure monitor for Health Service Watcher (Agent).
4. Click Authoring to open the Authoring area.
5. Expand Management Pack Objects and click Monitors.
6. Find and right-click the Health Service Heartbeat Failure monitor for Health Service Watcher (Agent).
Note
Use Find Now, if necessary, to find the monitor.
7. On the shortcut menu, point to Overrides, point to Disable the Monitor and then click For all objects of the type: Health Service Watcher (Agent).
8. In the Select Object dialog box, click the group to be used, in this example, Hearbeat Monitor Disabled Agents, and then click OK.
9. Expand Management Pack Objects, and then click Rules.
10. Find and right-click Heartbeat Failure – Success under Health Services Watcher Group (Agent).
11. Right-click, point to Overrides, point to Disable the Rule, and then click For a group.
12. In the Select Object dialog box, click the group to be used, in this example, Heartbeat Monitor Disabled Agents, and then click OK.
13. Click Yes to confirm.
14. Repeat the steps 7 through 13 to disable the rules Heartbeat Failure-Warning and Heartbeat Failure – Error.
|
Configure an Agent to Report to More Than One Management server
Use the following procedure to make an Operations Manager 2007 agent a member of multiple management groups, also referred to as multihoming. For example, an agent can be configured to report Active Directory data to the Networking management group and Exchange data to the Messaging management group. An agent can be a member of up to four management groups.
You do not need to use the same deployment method for all of the management groups.
Note
You can also use Active Directory Domain Services to assign agents to management groups. For more information, see Use Active Directory to Assign Computers.
Procedures
To make an Operations Manager 2007 agent a member of multiple management groups
- Do one of the following:
a. Run the Discovery Wizard from the Operations Manager 2007 Operations console that is connected to the new management group, select the computers that you want, and deploy the agent to them. For more information, see Using the Discovery Wizard to Deploy Agents.
b. Run MOMAgent.msi on the computers that you want, and modify the installation by adding a new management group. For more information, see Use the Agent Setup Wizard.
|
Use Agent-less Monitoring
Windows-based systems where an agent cannot be installed can be managed without an agent. This is called agentless management.
Note
Not all management packs support agentless management, so make sure it will serve your needs before using agentless management. In particular, the Active Directory management pack and the Exchange Server 2003 management pack do not support agentless management.
Agentless management of computers is different from Agentless Exception Monitoring. Though similar in name, Agentless Exception Monitoring is used to aggregate, view, and report on error reports that are sent by the Windows Error Reporting service.
The Discovery Wizard can find and set up systems for agentless management. The process is almost the same as for deploying. You do, however, have to select a proxy for each agentless-managed system. A proxy is a system with an agent that is used to monitor an agentless system. A management group can serve as a proxy, but this takes up system resources. A best practice is using an agent managed system as a proxy. This system must be set up for management before running the Discovery Wizard to establish agentless management.
Note
If a proxy is removed from management, its agentless systems are no longer managed.
Both the agentless-managed system and its proxy need to have access to the managing server through any firewalls. For more information about interacting with firewalls, see the Operations Manager 2007 Security Guide.
Note
When you are monitoring virtual servers on a cluster, you must deploy agents to the cluster nodes, configure them to be managed as a proxy and then monitor the virtual servers as you would monitor an agentless-managed computer.
Procedures
To configure an agent-managed computer as a proxy for agentless-managed computers
|
1. In the Agent Properties dialog box, click the Security tab.
2. On the Security tab, select Allow this agent to act as a proxy and discover managed objects on other computers, and then click OK.
|
To discover Windows-based computers and configure Operations Manager 2007 to manage them as agentless-managed computers
1. Log on to the Operations console with an account that is a member of the Operations Manager Administrators role for the Operations Manager 2007 management group.
Note
When you run the Operations console on a computer that is not a Management Server the Connect To Server dialog box appears. In the Server name text box, type the name of the Operations Manager 2007 Management Server that you want the Operations console to connect to.
2. Click Administration.
3. At the bottom of the navigation pane, click Discovery Wizard.
4. On the Introduction page, click Next. The Introduction page will be skipped if the Computer and Device Management Wizard has been run before and Do not show this page again was selected.
5. On the Auto or Advanced? page, do one of the following:
a. Select either Automatic computer discovery or Advanced discovery. If you select Automatic computer discovery, click Next, and then go to step 6. If you select Advanced discovery, continue with the following steps.
Note
Automatic computer discovery scans for Windows-based computers in the domain the Root Management. You can use advanced discovery to specify criteria for the computers the wizard will return, such as computer names starting with NY.
b. In the Computer & Device Types list, select Servers & Clients, Servers Only, or Clients Only.
c. In the Management Server list, click the Management Server or gateway server to discover the computers.
Note
For more information about gateway servers, see the Operations Manager 2007 Security Guide.
d. If you selected Servers & Clients, you can select the Verify discovered computers can be contacted check box. This is likely to increase the success rate of agent deployment, but discovery can take longer.
e. Click Next.
Note
The wizard can return approximately 4,000 computers if Verify discovered computers can be contacted is selected and 10,000 computers if it is not selected. Automatic computer discovery verifies that discovered computers can be contacted. A computer that is already managed by the management group is not returned.
6. On the Discovery Method page, you can locate the computers that you want to manage by either scanning or browsing Active Directory or by typing the computer names.
If you want to scan, do the following:
a. Select Scan Active Directory, if it is not already selected, and then click Configure.
b. In the Find Computers dialog box, type the criteria that you want to use for discovering computers, and then click OK.
c. In the Domain list, click the domain of the computers that you want to discover.
If you want to browse Active Directory or type the computer names, do the following:
- Select Browse for, or type-in computer names, click Browse, specify the names of the computers that you want to manage, and then click OK.
- In the Browse for, or type-in computer names box, type the computer names, separated by semi-colon, comma, or a new line [ENTER].
7. Click Next, and then on the Administrator Account page, do one of the following:
- Select Use selected Management Server Action Account, if it is not already selected, and then click Discover.
- Select Other user account, type the User name and Password, and then select the Domain from the list. If the User name is not a domain account, select This is a local computer account, not a domain account.
Important
The account must have administrative privileges on the targeted computers. If This is a local computer account, not a domain account is selected, the Management Server Action Account will be used to perform discovery. For more information about Operations Manager 2007 accounts, see the Operations Manager 2007 Security Guide.
8. Click Discover to display the Discovery Progress page. The time it takes discovery to finish depends on many factors, such as the criteria that are specified and the configuration of the IT environment.
9. On the Select Objects to Manage page, do the following:
a. Select the that computers you want to manage as agentless-managed computers.
b. In the Management Mode list, click Agentless.
c. Click Change, select the Proxy Agent that you want to use, click OK, and then click Next.
Important
An agentless-managed computer places greater resource requirements on the management server than an agent-managed computer. Therefore, an agent-managed computer that is configured as a proxy is recommended for managing agentless-managed computers.
10. On the Summary page, click Finish. The computers will appear in the Agentless Managed node of the Administration pane in the Operations console and are ready to be managed.
|
Investigating and Resolving Alerts
Operations Manager 2007 displays alerts in the Operations console and the Web console as specified by monitors and rules. Any alert is an indication of an issue that has occurred somewhere in your environment. Individual alerts can pertain to individual monitored devices, such as a malfunctioning hard drive on a computer to an issue with a distributed application, such as Exchange or Active Directory.
When you are addressing issues with alerts, you must consider:
- The severity of the alert.
- The number of times the alert has occurred.
- The importance of the application or device that the alert refers to your organization.
- Knowing this information will allow you to prioritize the order in which alerts will be investigated and the underlying issues resolved.
The following topics provide detailed information about resolving alerts:
- Investigate Alerts
- Investigate Alert Storms
- Resolve a Heartbeat Alert
Investigate Alerts
You can review and investigate alerts in the Monitoring pane of Operations console or the Web console. The Web console displays the same alert information as the Operations console, but provides fewer tools to deal with the alert, as it does not support the Tasks feature.
To view an alert
|
1. In the Operations console, click Monitoring.
2. In the Monitoring pane, expand Monitoring, and then click Active Alerts.
3. In the Active Alerts pane, click the alert to highlight it.
|
Operations Manager displays the Alert Details in the details pane at the bottom of the screen. Details include which monitor is involved and information about the alert and what can cause it.
The Actions pane on the right of the screen contains links to to tools and scripts that can be used to diagnose and resolve the alert. Click Actions on the toolbar to display the Actions pane if the pane is not visible. The Actions pane includes links to the settings of the monitor, the Health Explorer, controls for Maintenance Mode, Tasks for the monitor, and additional resources and help.
Using the Health Explorer
Use Health Explorer to find out what monitor is reacting and review knowledge about the monitor and possible causes. Click the alert to highlight it. The Health Explorer link under Alert Actions becomes active.
By default, when the Health Explorer window opens, all monitors in a failed state are expanded. If a monitor contains other monitors, as in the case of a roll-up monitor, Health Explorer shows all monitors in a hierarchical layout, displaying monitoring data for all dependent services and applications. To view more information about any dependent monitor, you can right-click that monitor, and then click Monitor Properties to open another Health Explorer window.
For more information about Health Explorer, see Operations Manager 2007 Help.
Using Tasks
In the Actions pane on the right of the screen, the Operations console provides tasks to troubleshoot individual alerts.
Note
If the Actions pane is not displayed, click Actions to display it.
Click an alert to highlight it to see tasks for that alert. Click a task to run the task.
Different alerts, which are raised by different monitors, offer different tasks for investigating and resolving the alert. For some examples of using tasks, see the Resolving a Heartbeat Alert section.
Closing Alerts
Monitors can be configured to automatically close alerts that have been resolved. You also have the option of manually closing an alert.
To view an alert
|
1. In the Operations console, click Monitoring.
2. In the Monitoring pane, expand Monitoring, and then click Active Alerts.
3. In the Active Alerts pane, right-click the alert, and then click Close Alert.
Note
Select multiple alerts by pressing and holding down the CTRL key when clicking alerts.
|
Using Monitor Properties
After you investigate the cause of an alert, you may be able to improve the process of dealing with similar alerts.
You can record knowledge about the alert in the Company Knowledge tab. You can view and edit company knowledge by highlighting an alert and then clicking View or edit the settings of the monitor and clicking the Company Knowledge tab.
You can also create tasks to diagnose and recover from alerts. Diagnostic and recovery tasks can run automatically when an alert is created. You can manage diagnostic and recovery tasks by highlighting an alert and then clicking View or edit the settings of the monitor and clicking the Diagnostic and Recovery tab.
Overriding a Monitor
You can use overrides to refine settings of a monitoring object in Operations Manager 2007. As you fine tune your monitors, many useless alerts will be avoided.
To override a monitor
|
1. In the Operations console, click the Authoring button.
Note
When you run the Operations console on a computer that is not a management server the Connect To Server dialog box will display. In the Server name text box, type the name of the Operations Manager 2007 management server that you want the Operations console to connect to.
2. In the Authoring pane, expand Management Pack Objects and then click Monitors.
3. In the details pane, expand an object type completely, and then click a monitor.
4. On the Operations Manager toolbar, click Overrides, and then point to Override the Monitor. You can choose to override this monitor for objects of a specific type or for all objects within a group. After you choose which group of object type to override, the Override Properties dialog box opens, enabling you to view the default settings contained in this monitor. You can then choose whether to override each individual setting contained in the monitor.
Note
If the Overrides button is not available, make sure you have selected a monitor and not a container object in the Monitors pane.
5. Click to place a check mark in the Override column next to each setting that you want to override. When you complete your changes, click OK.
|
Investigate Alert Storms
A large and sudden increase in the number of alerts is called an alert storm. An alert storm can be a symptom of massive changes of some kind within your management group, such as catastrophic failure of networks. An alert storm can also be a symptom of configuration issues within Operations Manager 2007.
Installing new or updated management packs can give rise to an alert storm. Monitors in a management pack begin working as soon as the management pack has been imported. Use best practices in importing management packs to minimize alert storms.
Finding Alert Storms
For general, real-time monitoring of alerts, use the Active Alerts view. Make sure Scope is not active and hiding alerts.
Check for large numbers of alerts when your network undergoes changes. Monitor closely when you install a new management pack.
Operations Manager 2007 offers reports that can be useful in identifying alert storms. From an Operations console with access to a Reporting Server, look at the Microsoft Generic Report Library. The reports Most Common Alerts and Most Common Events help identify high volume alerts.
Modifying Monitors and Rules
If you are getting a large number of alerts that do not point to issues in your managed systems, you need to modify the monitors or rules that create those alerts.
View active alert details in the Monitoring pane. Alert Details specifies the monitor or rule for an alert.
Modify the monitor using overrides. The procedure for overriding rules is the same as monitors. See how your overrides affect the amount of alerts and continue to fine-tune the monitors as necessary.
About Suppressed Alerts
Rules offer the option of suppressing duplicate alerts. A suppressed alert is not displayed in Operations console.
Operations Manager 2007 suppresses only duplicate alerts as defined by the Alert suppression criteria. Fields stated in the suppression criteria must be identical for the alert to be considered a duplicate and suppressed. An alert must be created by the same rule and be unresolved to be considered a duplicate.
Resolve a Heartbeat Alert
The Health Service sends a heartbeat to a management server to verify that the system is still responding. When a specified number of heartbeats fail to arrive, Operations Manager 2007 displays an alert.
This section shows how to investigate a Health Service Heartbeat Failure alert as an example. Different alerts have different causes and different resolutions.
If you want to walk through these procedures, you can cause this alert by disabling the OpsMgr Health Service on a test system.
To cause a Health Service Heartbeat Failure for testing
|
1. On a system with an agent installed, open Control Panel.
2. Double-click Administrative Tools.
3. Double-click Services.
4. Right-click OpsMgr Health Service, and then click Stop.
Note
Use this same procedure, selecting Start in step 4, when you are done testing.
|
How to Investigate Agent Heartbeat Issues
The Monitoring pane displays active alerts. Looking at an alert provides information and tools to investigate.
To investigate an active alert
|
1. Open Operations console by click Start, click Programs, click Systems Center Operations Manager 2007, and then click Operations Console.
2. Click Monitoring.
3. If necessary, in the Monitoring pane, click Monitoring to expand it.
4. Click Active Alerts to view the Health Service Heartbeat Alert.
Note
Depending on the heartbeat interval and the number of missing heartbeats, a few minutes may be required to see the alert.
5. Click the alert to highlight it and read the information in the Alert Details area. The Alert Details area provides information about the alert, including a description, knowledge about cause and resolution .
|
How to Troubleshoot Agent Heartbeat Issues
Use the tasks in the Action pane to diagnose the cause of the alert. Different alerts have different tasks. For a Health Service Heartbeat Failure alert, the tasks deal with pinging the system and verifying or restarting the service.
To use the Action Tasks in troubleshooting
|
1. If necessary, click Actions to make the Actions pane visible.
2. In the Actions pane, under Health Service Watcher Tasks, click Ping Computer. The task opens a dialog box to display its progress.
Note
If the ping fails, use standard networking troubleshooting to figure out the issue with connectivity. Verify that the system is turned on.
3. Click Close to close the dialog box.
4. Under Health Service Watcher Tasks, click Computer Management. A Computer Management dialog box for the target system opens.
5. Click Services and Applications to expand it.
6. Click Services to display Services.
7. Right-click the OpsMgr Health Service, and then click Start.
Note
After the connection with the agent is restored, the alert will be automatically resolved and the computer status will go back to healthy.
|
These steps will fix the test failure created in this topic, as well as addressing a number of possible causes of a Health Service Heartbeat Failure. If an actual failure is not resolved by these steps, use standard troubleshooting techniques to figure out the cause of the issue. For instance, the alert displayed in Active Alerts shows how old the alert is. Check for events that happened at this time to see what might have caused an issue.
Configuring the Customer Experience Improvment Program (CEIP) in Operations Manager 2007
The Microsoft Customer Experience Improvement Program (CEIP) collects information about how you use Microsoft programs and about some of the issues you might encounter. Microsoft uses this information to improve the products and features you use most often and to help solve issues. Participation in the program is strictly voluntary.
When you choose to participate in the CEIP, you configure clients with Group Policy to redirect CEIP reports to an Operations Manager 2007 management server, instead of reporting directly to Microsoft. The management servers are configured to forward these reports to Microsoft.
Important
The CEIP reports do not contain contact information about you or your organization, such as names or address.
The CEIP reports forwarded from your organization to Microsoft are combined with CEIP reports from other organizations and individual customers to help Microsoft solve issues and improve the Microsoft products and features customers use most often. For more information about the CEIP, see http://go.microsoft.com/fwlink/?linkid=75040.
Use the following procedure to configure CEIP settings. The management server must have access to the Internet to participate in the program.
Important
CEIP is a component of the Client Monitoring feature of Operations Manager 2007. Client Monitoring must be enabled on at least one management server and managed computers to participate in the CEIP. For information about enabling the Client Monitoring feature of Operations Manager 2007, see Configuring Client Monitoring in this guide. After a management server has been configured for client monitoring, all agents that are participating in CEIP should be configured via Group Policy to send their CEIP data to that management server.
To configure the CEIP settings for Operations Manager 2007
|
1. Log on to a management server with an account that is a member of the Operations Manager Administrators role for the Operations Manager 2007 management group.
2. In the Operations console, click the Administration button.
Note
When you run the Operations console on a computer that is not a management server the ConnectToServer dialog box will display. In the Servername text box, type the name of the Operations Manager 2007 management server you want the Operations console to connect to.
3. In the Administration pane, expand Administration, and then click Settings.
4. In the Settings pane, expand Type: General, right-click Privacy, and then click Properties.
5. In the Global Management Server Group Settings – Privacy dialog box, on the CEIP tab, click Join the Customer Experience Improvement Program to join the CEIP program or click I don’t want to join the program at this time to decline participation.
Note
You can click Tell me more about the program to view information about the CEIP program, including the privacy policy.
|
Configuring Operational Data Reports in Operations Manager 2007
The Microsoft Customer Experience Improvement Program (CEIP) collects information about how you use Microsoft programs and about some of the issues you might encounter. Microsoft uses this information to improve the products and features you use most often and to help solve issues. Participation in the program is strictly voluntary.
During setup of Operations Manager 2007 Reporting, on the Operational Data Reports page, you had the option to join CEIP. If you elected to join CEIP, Operations Manager 2007 Reporting collects a summary of how Operations Manager 2007 is being used and sends reports to Microsoft on a weekly basis. Microsoft uses these reports to improve the quality of its Management Packs and Operations Manager 2007. You can view the contents of these Operational Data Reports by creating a Microsoft ODR Report.
Note
Before configuring operational data reports, make sure that Operations Manager 2007 Reporting is installed, and that the Management Server has access to the Internet so that reports can be sent to Microsoft.
To configure the operational data reports settings
|
1. Log on to the computer with an account that is a member of the Operations Manager Administrators role for the Operations Manager 2007 Management Group.
2. In the Operations console, click the Administration button.
Note
When you run the Operations console on a computer that is not a Management Server, the Connect To Server dialog box displays. In the Server name text box, type the name of the Operations Manager 2007 Management Server that you want the Operations console to connect to.
3. In the Administration pane, expand Administration, and then click Settings.
4. In the Settings pane, expand Type: General, right-click Privacy, and then click Properties.
5. In the Global Management Server Settings – Privacy dialog box, on the Operational Data Reports tab, click Yes, send operational data reports to Microsoft (recommended) to send reports or click No, don’t send operational data reports to Microsoft to decline participation.
6. Click OK.
|
During setup of Operations Manager 2007 Reporting, on the Operational Data Reports page, you had the option to join CEIP. If you elected to join CEIP, Operations Manager 2007 Reporting collects information about your installation of Operations Manager 2007 and sends reports to Microsoft on a weekly basis. You can view the contents of these Operational Data Reports by creating a Microsoft ODR Report.
To create a Microsoft ODR Report
|
1. Log on to the computer with an account that is a member of the Operations Manager Report Operators role for the Operations Manager 2007 Management Group.
2. In the Operations console, click the Reporting button.
Note
When you run the Operations console on a computer that is not a Management Server, the Connect To Server dialog box displays. In the Servername text box, type the name of the Operations Manager 2007 Management Server that you want the Operations console to connect to.
3. In the Reporting pane, expand Reporting, and then click MicrosoftODRReport Library.
4. In the Microsoft ODR Report Library Reports pane, right-click one of the reports (for example, Management Packs), and then click Open.
5. In the Report view, in the Parameter area, click the down arrow in the From box, point to This week, and then click Sunday.
6. Click the down arrow in the To box, point to Thisweek, and then click Saturday.
7. Click Run to display the ODR Report.
8. Click Close to close the report.
|
Configure Client Monitoring in Operations Manager 2007
Use the following procedures to configure a management server for the server component of the Client Monitoring feature of Operations Manager 2007.
Important
If you plan to configure the management server to forward error reports to Microsoft and receive links to available solutions for those errors or participate in the Customer Experience Improvement Program (CEIP), you must first configure the management server’s proxy settings if it uses a proxy server to access the Internet. For more information, see the Configuring Internet Proxy Settings for a management server section.
The Operations Manager 2007 Client Monitoring Configuration Wizard is used to configure the server component of Client Monitoring on an Operations Manager 2007 management server. To configure the server component of Client Monitoring on multiple management servers, run the wizard once for each management server. An example of when you might configure multiple management servers for Client Monitoring is if the connection between specific clients and management servers is less expensive.
Important
The management server and error reporting clients must be in the same or fully trusted domains.
To open the Client Monitoring Configuration Wizard
|
1. Log on to the computer with an account that is a member of the Operations Manager Administrators role for the Operations Manager 2007 management group.
2. In the Operations console, click the Administration button.
Note
When you run the Operations console on a computer that is not a management server, the Connect To Server dialog box displays. In the Server name text box, type the name of the Operations Manager 2007 management server that you want the Operations console to connect to.
3. In the Administration pane, expand Administration, expand Device Management, and then click Management Servers.
4. In the management servers pane, right-click the management server on which you want to enable Client Monitoring, and then click Configure Client Monitoring. This will start the Client Monitoring Configuration Wizard. Use the same procedure to Disable Client Monitoring on the management server. You must also disable Client Monitoring on the clients. For more information, see Configuring Clients for Client Monitoring below.
Note
The Configure Client Monitoring option will be unavailable if the selected computer is a gateway server.
|
To configure Client Monitoring using the Client Monitoring Configuration Wizard
1. On the Introduction page of the Client Monitoring Configuration Wizard, click Next. The Introduction page will be skipped if the wizard has been run before and Do not show this page again was selected.
2. On the Customer Experience Improvement Program page, do one of the following:
- Leave the default option of No if you do not want your organization to participate in the program, and then click Next.
Or
a. Select Yes, if you want your organization to participate in the program.
b. Leave Use Secure Socket Layer (SSL) protocol selected if you have installed a certificate on your management server, leave Use Windows Authentication selected if you want the client computers to authenticate with the management server; otherwise, clear the options.
c. Type the appropriate Port, or leave the default of 51907, and then click Next.
Important
For information about installing a certificate on a management server, see the Operations Manager 2007 Security Guide at http://go.microsoft.com/fwlink/?LinkId=64017
3. On the Configure Error Collection page, do the following:
a. Type the local or attached File Share Path, such as C:\ErrorData,for the management server that will be used to collect error reports. The files share will be created at the local path on the management server and shared with the necessary permissions.
Important
The file share path must be on an NTFS partition and have at least 2 GB of free disk space. It is recommended that the path is no longer than 120 characters. The file share path can be a UNC path or mapped drive letter.
b. Select Collect application errors from Windows Vista or later computers if you will be managing Windows Vista or later operating systems with Operations Manager 2007. Type the Port number, or leave the default 51906. Leave Use Secure Socket Layer protocol selected if you have installed a certificate on your management server, leave Use Windows Authentication selected if you want the client computers to authenticate with the management server; otherwise, clear the options.
c. Type the Organization Name, using no more than 22 characters, and then click Next. The Organization Name can display on computers experiencing errors and running Windows Server 2003 and earlier operating systems.
4. On the Configure Error Forwarding page, do one of the following:
- Leave the Automatically forward all collected errors to Microsoft check box cleared, and then click Next.
Or
a. Select Automatically forward all collected errors to Microsoft if the management server is connected to the Internet and you want to forward error reports to Microsoft and receive links to available solutions for those errors.
b. Select Detailed to help ensure Microsoft can provide a solution to the issue, or leave the default setting of Basic.
c. Click Next.
5. On the Create File Share page, do one of the following:
- Select an Existing User Account from the list, and then click Next.
- Select Other user account, type the User name and Password, select the Domain from the list, and then click Next.
Important
The account must have the permissions necessary to create a file share on the path provided in step 3a.
6. On the Create file Share: Task Status page, after the file share has been successfully created, click Next.
Note
To modify the Client Monitoring settings on the management server, such as the file share, you must disable and then re-enable Client Monitoring on the management server. You must also then modify the Client Monitoring Group Policy settings on the clients.
7. On the Deploy Configuration Settings page, type or Browse to the location where you would like to save the <ServerName>.ADM file that contains the Client Monitoring Group Policy settings you have just made with the wizard, and then click Finish.
Important
You must use the <ServerName>.ADM file to configure clients to redirect their Client Monitoring data to the management server. For more information, see Configuring Clients for Client Monitoring below.
|
Configuring Internet Proxy Settings for a Management Server
Use the following procedure to configure the Internet proxy settings for an Operations Manager 2007 management server. You must configure these settings if features of Operations Manager 2007 are enabled that require the management server to communicate over the Internet. For example, you must configure these settings if the Client Monitoring feature of Operations Manager 2007 is configured to transmit or receive data from Microsoft.
To Configure the Internet Proxy Settings for an Operations Manager 2007 management server
1. Log on to the computer with an account that is a member of the Operations Manager Administrators role for the Operations Manager 2007 management group.
2. In the Operations console, click the Administration button.
Note
When you run the Operations console on a computer that is not a management server, the Connect To Server dialog box displays. In the Servername text box, type the name of the Operations Manager 2007 management server that you want the Operations console to connect to.
3. In the Administration pane, expand Administration, expand DeviceManagement, and then click the ManagementServers.
4. In the results pane, right-click the management server for which you want to view the properties of, and then click Properties.
5. In the Management Server Properties dialog box, click the ProxySettings tab.
6. On the Proxy Settings tab, select Use a proxy server for communication with Microsoft and then do the following:
- Select http:// or https:// from the drop-down list, and type the name of the internet proxy server in the Address text box.
- Type the Port number, and then click OK.
|
Configuring Clients for Client Monitoring
This topic provides the procedure to configure clients for the Client Monitoring feature of Operations Manager 2007.
Important
You must first configure a management server for the server component of Client Monitoring by running the Client Monitoring Configuration Wizard as described above.
To Configure clients for Client Monitoring
|
1. Run the Group Policy Object Editor (gpedit.msc) for the domain or local computer.
Note
For information about Group Policy, see http://go.microsoft.com/fwlink/?LinkId=70168.
2. Enable the Turn off Windows Error Reporting policy. This policy can be found in Computer Configuration/Administrative Templates/System/Internet Communication Management/Internet Communication settings.
3. Add the Agentless Exception Monitoring (AEM) Group Policy administrative template (<ServerName>.ADM) to the domain or local computer policy. The ADM file is created when the Client Monitoring Configuration Wizard is run.
4. Enable the AEM policies that reflect the configuration of Client Monitoring on the Operations Manager 2007 management server. The AEM policies can be found in Computer Configuration/Administrative Templates/Microsoft Applications/Microsoft Operations Manager.
Note
Use the same procedure to Disable the Group Policy settings, thereby disabling Client Monitoring on the clients.
|
Configuring Error Reporting in Operations Manager 2007
When error reporting is enabled for Operations Manager 2007 components, if an error occurs in an Operations Manager 2007 component, information about the error is anonymously reported to Microsoft. For more information about the Privacy Statement for the Microsoft Error Reporting Service, see http://go.microsoft.com/fwlink/?LinkId=64250. This information is used with error reports from other Microsoft customers to help identify and resolve common issues with Operations Manager 2007.
Note
This setting enables error reporting only for Operations Manager 2007 components. For information about enabling the Client Monitoring feature of Operations Manager 2007, which includes error reporting for the specified computers, see the Configuring Client Monitoring section in this guide.
To configure error reporting settings for Operations Manager 2007 components
1. Log on to the computer with an account that is a member of the Operations Manager Administrators role for the Operations Manager 2007 management group.
2. In the Operations console, click the Administration button.
Note
When you run the Operations console on a computer that is not a management server the ConnectToServer dialog box will display. In the Servername text box, type the name of the Operations Manager 2007 management server you want the Operations console to connect to.
3. In the Administration pane, expand Administration, and then click Settings.
4. In the Settings pane, expand Type: General, right-click Privacy, and then click Properties.
5. In the Global Management Server Settings – Privacy dialog box, click the Error Reporting tab, and then do one of the following:
- Select Automatically send error reports about this product to Microsoft without prompting the user.
- Select Prompt the user for approval before sending error reports to Microsoft.
Note
Click Tell me more about error reporting if you want to view the Privacy Statement for the Microsoft Error Reporting Service.
6. When you have made the selection you want, click OK.
|
Error Transmission settings allow you to specify which error reports are sent to Microsoft and the additional diagnostic data that is included with the error reports.
To find the Error Transmission tab of the Global management server Settings – Privacy dialog box
|
1. Log on to the computer with an account that is a member of the Operations Manager Administrators role for the Operations Manager 2007 management group.
2. In the Operations console, click the Administration button.
Note
When you run the Operations console on a computer that is not a management server, the Connect To Server dialog box will display. In the Server name text box, type the name of the Operations Manager 2007 management server you want the Operations console to connect to.
3. In the Administration pane, expand Administration, and then click Settings.
4. In the Settings pane, expand Type: General, right-click Privacy, and then click Properties.
5. In the Global Management Server Group Settings – Privacy dialog box, click the Error Transmission tab.
Note
Click Read the privacy statement to view the privacy statement.
|
To filter errors that are sent to Microsoft
|
1. On the Error Transmission tab of the Global Management Server Group Settings – Privacy dialog box, click Filter.
2. In the Error Forwarding Filters dialog box, select one or more of the options for sources of errors that you do not want forwarded to Microsoft, such as that come from specific computers.
3. In the Criteria description text box, click specific, and provide the values for the criteria of errors that you do not want forwarded to Microsoft, such as computer.contoso.com.
4. Click OK twice.
|
To configure diagnostic data sent to Microsoft with error reports
|
1. On the Error Transmission tab of the Global Management Server Settings – Privacy dialog box, do one or more of the following:
a. Select Upload diagnostic data collection request, select the additional diagnostic data that you want to send with error reports from computers reporting errors to the management servers, and then forward from the management server to Microsoft with the error reports.
b. Set Maximum number of CAB files to send to Microsoft per error group to help Microsoft diagnose the error. 10 is the recommended number.
c. Select Display links to solutions from Microsoft on error reporting computers. A link to available solutions will display to end users after the error is first encountered and the link to the solution is downloaded to the management server.
d. Select Display links to surveys from Microsoft on error reporting computers.
e. Specify the Default solution link when no Microsoft solution is available. This could be an internal Web page for technical support, for example.
2. Click OK.
|
Maintenance and Best Practices for Operations Manager
After you design, deploy and configure your Operations Manager environment, and as you start monitoring computers and devices in your organization, large amounts of data accumulates.
To protect your Operations Manager environment, and to limit service interruption, you must develop and implement a comprehensive and effective maintenance plan. An effective on-going maintenance of your Operations Manager environment can improve performance, and minimize the chances of failure.
Ensure that your maintenance plan includes:
- Regular monitoring of both software and hardware.
- Frequent backups of databases and other critical data so it can be later restored in case of failure.
If at any time there is an indication of a problem, it is best to respond immediately.
In This Section
Managing Gateway Servers in Operations Manager 2007
Managing Reporting in Operations Manager 2007
Managing Web Console Servers in Operations Manager 2007
Managing Connected Management Groups in Operations Manager 2007
Changing Passwords for Operations Manager Accounts
Identifying the Root Management Server in Operations Manager 2007
Scheduling Maintenance and Monitoring
Backing up and Restoring Operations Manager 2007 Components
Making Updates to a Operations Manager 2007 Deployment
Managing Gateway Servers in Operations Manager 2007
Operations Manager 2007 requires mutual authentication be performed between agents and Management Servers prior to the exchange of information between them. In order to secure the authentication process between the two, it is encrypted. When the agent and the Management Server reside in the same Active Directory domain or in Active Directory domains that have established trust relationships, they make use of Kerberos V5 authentication mechanisms provided by Active Directory. When the agents and Management Servers to not lie within the same trust boundary, other mechanisms must be used to satisfy the secure mutual authentication requirement.
In Operations Manager 2007, this is accomplished through the use of X.509 certificates issued for each computer. If there are many agent monitored computers, this results in a high administrative overhead for managing all those certificates. In addition, if there is a firewall between the agents and Management Servers as well, multiple authorized endpoints must be defined and maintained in the firewall rules to allow communication between them.
In order to reduce this administrative overhead, Operations Manager 2007 has a new server role called the Gateway Server. Gateway Servers are located within the trust boundary of the agents and can participate in the mandatory mutual authentication. Because they lie within the same trust boundary as the agents, the Kerberos V5 protocol for Active Directory is used. Each agent then communicates only with the Gateway Servers that it is aware of. The Gateway Servers communicate with the Management Servers.
In order to support the mandatory secure mutual authentication between the Gateway Servers and the Management Servers, certificates must be issued and installed, but only for the Gateway and Management Servers. This reduces the number of certificates required and in the case of an intervening firewall; it also reduces the number of authorized end points to be defined in the firewall rules.
As your IT environment or monitoring requirements change you may need to add or remove Gateway Servers from and Operations Manager 2007 Management Group and perform tasks on the Gateway Servers.
Determining the Health of Gateway Servers
To determine the health of a Gateway Server you must examine it from two perspectives. The first, most direct method, is to examine the health status in the Operations console and Health Explorer. This will tell you that status of the monitored components, whether or not there are any open alerts and performance data. The second, indirect method, is to be sure that data from the agents that are being monitored through the Gateway Server is being reported in a timely fashion.
Direct Method
Gateway Servers are a type of Management Server and therefore they are included in the Management Servers container under Device Management in the Administration view of the Operations console. In the details pane of this view, you can immediately see the Health State of any of Management Servers in the Management Group. By selecting any Gateway Server (or any server for that matter) and opening the context menu, you can view the properties of the server or any of the views that are available. Typically, you can directly access the Event View, Alert View, Performance View, Diagram View and State View for the selected object.
For a more comprehensive understanding of the health of a Gateway Server, open the Monitoring view and navigate to the Operations Manager, Management Server folder and select the Management Server State view object in the navigation pane. This displays the state of all Management Servers in the Management Group with Gateway Servers displayed next to the bottom by default. In the Gateway Management Server State pane, select the health status icon for the server you are interested in under the Gateway column to bring up the health state of the Gateway servers component monitors in the details pane. Typically, you will get details on the Health Service Availability, Audit Collection Availability, Configuration, Performance and Security.
Indirect Method
Gateway Servers relay monitoring data from agents to Collection Management Servers in the Management Group across trust boundaries. They also relay configuration information from the Collection Management Server to the agents that they serve. Therefore if agents that have a Gateway Server as their primary management server are reporting their data and are heartbeating, you can be sure that their Gateway Server is performing satisfactorily.
Viewing Agents by Gateway
How to view an Agents Primary Management Server
|
1. Open the Operations console, and then click the Administration button.
2. In the Administration pane, expand Administration, expand Device Management, and then click Agent Managed.
3. Displayed in the results pane are all the agent-managed devices grouped by their Primary Management Server.
4. Look for the Gateway Server of interest and grouped under it are all the agents that are currently using the Gateway.
|
Using Multiple Gateway Servers
Multiple Gateway Servers can be deployed across a trust boundary to provide redundant pathways for agents that lie across that trust boundary. Just as agents can failover between a primary and one or more secondary Management Servers, so too can they fail over between Gateway Servers. In addition, multiple Gateway servers can be used to distribute the workload of managing agentless-managed computers and managed network devices.
In addition to providing redundancy through Agent – Gateway failover, Gateway Servers can be configured to failover between Collection Management Servers in a Management Group if multiple Collection Management Servers are available.
Configuring Agent Failover Between Multiple Gateway Servers
If you have deployed multiple Gateway Servers into a domain that does not have a trust relationship established with the domain that the rest of the Management Group is in, you can configure agents to utilize those Gateway Servers as necessary. To do this, you must use the Operations Manager 2007 Command Shell.
Use the Set-ManagementServer -AgentManagedComputer command in Command Shell as shown in the following example to configure an agent to failover to multiple Gateway Servers. The commands can be run from any Command Shell in the Management Group.
To configure agent failover to multiple Gateway Servers
|
1. Log on to the computer with an account that is a member of the Administrators group.
2. On the Windows desktop, click Start, point to Programs, point to SystemCenterOperationsManager, and then click CommandShell.
3. In Command Shell, follow the example described in the next section.
|
Description
The following example can be used to configure agent failover to multiple Gateway Servers.
Important
When changing the Primary Management Server of an agent, allow the agent to connect to its new Primary Management Server before making changes to its failover server. Allowing the agent to get current topology information from the new Primary Management Server prevents the agent from losing communication with all Management Servers.
Code
$primaryMS = Get-ManagementServer | where {your filter here}
$failoverMS = Get-ManagementServer | where {your filter here}
$agent = Get-Agent | where {your filter here}
Set-ManagementServer -AgentManagedComputer: $agent -ManagementServer: $primaryMS
$agent = Get-Agent | where {your filter here}
Set-ManagementServer -AgentManagedComputer: $agent -ManagementServer: $primaryMS -FailoverServer: $failoverMS
Comments
In the code example, you will need to create a filter statement for the first three commands. The following is an example of a filter command written to find the computer contoso.com that will be assigned to the $failoverMS variable:
$failoverMS = Get-ManagementServer | where {$_.Name –eq ’contoso.com’ }
The use of two Set-ManagementServer commands is to allow the agent to connect to its new Primary Management Server for configuration information before changing the failover server.
For help with the Set-ManagementServer command, type the following in the Command Shell window:
Get-help Set-ManagementServer -full
Configure a Gateway Server to Failover Between Multiple Management Servers
Use the Set-ManagementServer-GatewayManagementServer command in Command Shell as shown in the following example to configure a Gateway Server to failover to multiple Management Servers. The commands can be run from any Command Shell in the Management Group.
To configure Gateway Server failover to multiple Management Servers
|
1. Log on to the Gateway Server with an account that is a member of the Administrators role for the Management Group.
2. On the Windows desktop, click Start, point to Programs, point to SystemCenterOperationsManager, and then click CommandShell.
3. In Command Shell, follow the example described in the next section.
|
Description
The following example can be used to configure Gateway Server failover to multiple Management Servers.
Code
$primaryMS = Get-ManagementServer | where {your filter here}
$failoverMS = Get-ManagementServer | where {your filter here}
$gatewayMS = Get-ManagementServer | where {your filter here}
Set-ManagementServer -GatewayManagementServer: $gatewayMS -ManagementServer: $primaryMS
$gatewayMS = Get-ManagementServer | where {your filter here}
Set-ManagementServer -GatewayManagementServer: $gatewayMS -ManagementServer: $primaryMS -FailoverServer: $failoverMS
Comments
In the code example, you will need to create a filter statement for the first three commands. The following is an example of a filter command written to find the computer contoso.com that will be assigned to the $failoverMS variable:
$failoverMS = Get-ManagementServer | where {$_.Name –eq ’contoso.com’ }
For help with the Set-ManagementServer command, type the following in the Command Shell window.
Get-help Set-ManagementServer -full
Managing Certificate Renewal for Gateway Servers and Management Servers
Eventually, the certificates that were obtained and installed on the Gateway Server and Collection Management Servers will expire and will need to be replaced with a new one. The other situation in which you will need to replace an existing certificate is if, for security reasons, the certificate has been revoked.
To do this, you will need to follow the same procedures that were used to obtain and import the certificates in the first place.See Deploying Gateway Servers in the Multiple Server, Single Management Group Scenario section of the Operations Manager 2007 Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=95133). It is not necessary to rerun the Gateway Approval Tool.
Removing a Gateway Server from a Management Group
Throughout the lifecycle of your Operations Manager 2007 implementation, you may need to reprovision server hardware or otherwise modify the structure and configuration of your deployment. In the case of Gateway Servers, these types of changes could stem from the decommissioning of an untrusted domain so that monitoring is no longer required or the old server hardware is to be replaced with new hardware. To remove a Gateway Server from service, you must complete the following steps.
Overview of decommissioning a Gateway Server
|
1. Configure all objects that are being managed by the Gateway Server to use a different Primary Management Server. For an agent-managed computer, this means either using another Gateway Server or a Management Server.
2. Uninstall the Gateway Server software from the server.
3. Delete the Gateway Server from the Management Group.
|
Configure Managed Objects to Use An Alternate Primary Management Server
Gateway Servers can manage three different types of objects, agent-managed computers, agentless-managed computers and network devices acting as a proxy agent.
Configuring agent-managed computers to use a different primary Management Server using the Operations Console
|
1. Log on to a Management Server with an account that is a member of the Operations Manager Administrators role for the Operations Manager 2007 Management Group.
2. In the Operations console, click the Administration button.
Note
When you run the Operations console on a computer that is not a Management Server, the Connect To Server dialog box will display. Type the name of the Operations Manager 2007 Management Server you want the Operations console to connect to in the Server name text box.
3. In the Administration pane, expand Administration, expand Device Management, and then click Agent Managed.
4. In the Agent Managed pane, select the computers for which you want to change the Primary Management Server, right-click them, and then select Change Primary Management Server.
Note
The Change Primary Management Server option will be unavailable if Active Directory Domain Services was used to assign any of the selected computers to the Management Group.
5. In the Change Management Server dialog box, select the desired Management Server from the list, and then click OK. The change takes effect on the agent after its next update interval.
|
Alternately, this configuration can be changed on the agent-managed computer itself using either of the following two procedures.
To change the Primary Management Server for agent-managed computers using the MOMAgent.msi setup wizard
|
1. Log on to the agent-managed computer with an account that is a member of the administrators security group for the computer.
2. In Add or Remove Programs, click Change for System Center Operations Manager 2007 Agent.
Note
The Agent Setup Wizard can also be run by double-clicking MOMAgent.msi, which is available on the Operations Manager 2007 installation media.
3. In the Agent Setup Wizard, click Next.
4. On the Program Maintenance page, select Modify, and then click Next.
5. On the Management Group Configuration page, leave Specify Management Group information selected, and then click Next.
6. In the next Management Group Configuration page, do the following:
a. Type the name of the Management Server.
b. Type the Management Server Port, or leave the default 5723.
c. Click Next.
7. On the Ready to Install page, review the settings, and then click Install to display the Installing Systems Center Operations Manager Agent page.
8. When the Completing the Systems Center Operations Manager Agent Setup Wizard page displays, click Finish.
|
To change the Primary Management Server for agent-managed computers using MOMAgent.msi from the command line
|
1. Log on to the agent-managed computer with an account that is a member of the administrators security group for the computer.
2. Open the command window.
3. At the prompt, type the following command-line example:
Important
Microsoft Windows Installer public properties must be uppercase, such as PROPERTY=value. For more information about Windows Installer, see http://go.microsoft.com/fwlink/?LinkId=70004.
%WinDir%\System32\msiexec.exe /i \\path\Directory\MOMAgent.msi /qn USE_SETTINGS_FROM_AD=0 MANAGEMENT_GROUP=MG1 MANAGEMENT_SERVER_DNS=MS2.Domain1.net
4. The preceding command-line example will reconfigure the agent to use MS2.Domain1.net as its Primary Management Server for Management Group MG1.
Important
If the Domain Name System (DNS) and Active Directory names for the Management Server differ, the MANAGEMENT_SERVER_AD_NAME property would also need to be set to the fully qualified Active Directory Domain Services name.
|
Redirecting Agentless Managed Computers and Network Devices
To change the proxy agent for agentless managed computers and network devices
|
1. Log on to a Management Server computer with an account that is a member of the Operations Manager Administrators role for the Operations Manager 2007 Management Group.
2. In the Operations console, click the Administration button.
Note
When you run the Operations console on a computer that is not a Management Server the Connect To Server dialog box displays. In the Server name text box, type the name of the Operations Manager 2007 Management Server that you want the Operations console to connect to.
3. In the Administration pane, expand Administration, expand Device Management, and then click Agentless Managed. If you are working with a network device, select Device Management and then Network Devices.
4. In the Agentless Managed pane, select the agentless managed computers for which you want to change the proxy agent, right-click them, and then select Change Proxy Agent. Or if you are working with a network device, then in the Network Devices pane, select the network devices for which you want to change the proxy agent, right-click them, and then select Change Proxy Agent.
5. In the Change Proxy Agent dialog box, select the computer you want to be the new proxy agent, and then click OK.
|
The final steps in removing a Gateway Server from a Management Group are straight forward. And consist of:
- Log on to the Gateway Server with an account that has administrative rights
- In Add or Remove Programs, select System Center Operations Manager 2007 Gateway, and then click Remove.
In the Operations Console, in the Administration view, under Device Management, Management Servers, select the Gateway Server, right-click it, and then click Delete.
Managing Reporting in Operations Manager 2007
The Reporting feature of Operations Manager 2007 has been enhanced for this release and focuses on customer scenarios, performance, and usability. As an administrator, you will be involved in customizing reports and setting up access to reports. Reporting makes use of an SQL database which needs to be maintained and backed up.
Managing Reporting
The Management Packs come with a variety of reports including information on alerts, availability, health, and performance. After you set up a Reporting Server and import Management Packs, you can browse available reports in the Reporting pane of the Operations console.
Note
It may take a few minutes for a report to show up after a Management Pack has been imported.
You can run standard reports from the console by entering a time frame and specifying what is to be included in the report.
To run a report from the Reporting pane
|
1. Log on to the computer with an account that is a member of the Operations Manager Report Operators role for the Operations Manager 2007 Management Group.
2. In the Operations console, click the Reporting button.
Note
When you run the Operations console on a computer that is not a Management Server, the Connect To Server dialog box displays. In the Servername text box, type the name of the Operations Manager 2007 Management Server that you want the Operations console to connect to.
3. In the Reporting pane, expand Reporting and then click MicrosoftGenericReports.
4. In the Microsoft Generic Report Library Reports pane, right-click one of the reports (for example, Availability) and then click Open.
5. In the Report view, in the Parameter area, click the down arrow in the From box, point to This week, and then click Sunday.
6. Click the down arrow in the To box, point to Thisweek and then click Saturday.
7. Click Use business hours.
Note
You can further specify the timeframe for the report in the additional options in the Parameter area.
8. Click Add.
9. In the AddObject dialog box, in the ObjectName text box, type the computer name for a computer that you want to report availability, and then click Search.
10. In the Availableitems list, click the computer you want to run a report for, click Add, and then click OK.
11. Click Run to display the Availability Report.
12. For a more detailed report, such as a report showing a graph for every day, click the horizontal bar graph under Availability Tracker.
13. In the toolbar, click View, point to GoTo, and then click Back to Parent Report to return to the original report.
14. Click Close to close the report.
|
You can export reports to various formats, including XML, comma separated text, TIFF, PDF, Web archive, or Excel.
To export a report
|
1. After a report has been run, in the toolbar, click the File menu, point to Export, and then click the format you want to export the file to.
2. In the SaveAs dialog box, select the folder where you want to save the report, and then click Save.
|
You can customize reports, save them, and schedule them to be run on a regular basis.
To save a report to favorite reports
|
1. Customize a report.
2. While viewing the new report, click the File menu, and then click Savetofavorites.
3. In the Save to favorites dialog box, type a name for the report, and then click OK.
4. Close the report.
|
Use this procedure to create a report schedule.
To create a report schedule
|
1. In the Operations console, click Reporting.
Note
When you run the Operations console on a computer that is not a Management Server, the ConnectToServer dialog box will display. In the Servername text box, type the name of the Operations Manager 2007 Management Server you want the Operations console to connect to.
2. In the Reporting pane, click Favorite Reports.
3. In the Favorite Reports pane, right-click a saved report, and then click Schedule.
4. In the Subscribe to a Report Wizard, on the Delivery Settings page, do the following:
a. Type a description in the Description text box.
b. Click the down arrow in the Delivery method list, and then click ReportServerFileShare.
c. Type a file name for the report in the File name text box.
d. Type a file path for the report in the Path text box.
Note
Report scheduling supports Universal Naming Convention (UNC) file names and must not end in a backslash.
e. Click the down arrow in the Render Format list, and then click the file format you want for the report.
f. Type a user name in the Username text box, and then type a password in the Password text box.
Note
The credentials entered must have Write user rights on the file share that was entered above.
g. Click the down arrow in the Writemode list, select the Write mode you want for subsequent files, and then click Next.
5. In the Subscribe to a Report Wizard, on the Subscription Schedule page, do the following:
a. Select one of the Generate the report options.
b. Type a start date and start time for the reports to be generated in TheSubscriptioniseffectivebeginning list. You can also enter the date when this subscription will end in The subscription expires on list, and then click Next.
6. In the Subscribe to a Report Wizard, on the Parameters page, specify a span of time for the report in the From and To lists.
7. Make any other changes you need for this report, and then click Finish.
|
Use this procedure to set up e-mail delivery for scheduled reports.
To configure e-mail settings in the SQL Server 2005 Report Server
1. On the Windows desktop, click Start, point to Programs, point to MicrosoftSQLServer 2005, point to ConfigurationTools, and then click ReportingServicesConfiguration.
2. In ReportingServicesConfigurationManager, in the ReportServerInstallationInstanceSelection dialog box, click Connect.
3. In the navigation pane, click E-mailSettings.
4. In the E-mail Settings pane, enter the following:
- An e-mail address for use as the sender address in the SenderAddress text box.
- The address of the SMTP server that will be used to send the e-mail messages in the SMTPServer text box.
5. Click Apply, and then click Exit.
|
Use this procedure to e-mail scheduled reports.
To e-mail scheduled reports
1. Log on to the computer with an account that is a member of the Operations Manager Report Operators role for the Operations Manager 2007 Management Group.
2. In the Operations console, click the Reporting button.
Note
When you run the Operations console on a computer that is not a Management Server, the Connect To Server dialog box will display. In the Server name text box, type the name of the Operations Manager 2007 Management Server you want the Operations console to connect to.
3. In the Reporting pane, click FavoriteReports.
4. In the Favorite Reports pane, right-click the Availability report you saved as a favorite, and then click Schedule.
5. In the Subscribe to a Report Wizard, on the DeliverySettings page, do the following:
- Type a description in the Description text box.
- Click the down arrow in the Delivery method list, and then click Report Server E-Mail.
- Type an e-mail address of the destination inbox to receive reports in the To text box. You can also type e-mail addresses in the Cc, Bcc, and the Reply To text boxes.
- Click the down arrow in the Render Format list, and then click the file format you want for the report.
- Click the down arrow in the Priority list, and then select the appropriate priority.
- Type a subject for the e-mail in the Subject text box.
- Click Next.
6. On the SubscriptionSchedule page, do the following:
- Select one of the Generate the report options.
- Type a start date and start time for the reports to be generated in TheSubscriptioniseffectivebeginning list. You can also enter the date when this subscription will end in Thesubscriptionwillend list, and then click Next.
7. On the Parameters page, specify a span of time for the report in the From and To lists, make any other changes you need for this report, and then click Finish.
|
As administrator, you will probably want to find reports that capture useful history about your systems, customize those reports to your needs, save them to Favorite Reports, and schedule them to run and be made available as needed. You can save them to a Windows® SharePoint® Services server or e-mail them to designated individuals.
Managing Access to Reports
Operations Manager 2007 uses role-based security. With regard to administering Operations Manager 2007, you will need to manage users as needed. The following roles are relevant to reporting.
- Report Operator
Includes a set of privileges designed for users who need access to Reports. Grants members the ability to view reports according to their configured scope.
Caution
Users assigned to this role have access to all report data in the Reporting Data Warehouse and are not limited by scope.
- Report Security Administrator
Enables the integration of SQL Server Reporting Services security with Operations Manager user roles. This gives Operations Manager Administrators the ability to control access to reports. This role can have only one member account and cannot be scoped.
Grooming
The Reporting Data Warehouse stores data for specified length of time, depending on the data (Alert, State, Event, Aem, Performance) and the aggregation type (raw data, hourly aggregations, daily aggregations). The database is set up to delete older data. Deleting the older data is called grooming.
The default settings for retention of different kinds of data is as follows:
|
Data Set
|
Aggregation Type
|
Days to be kept
|
|
Alert
|
Raw data
|
400
|
|
State
|
Raw data
|
180
|
|
State
|
Hourly aggregations
|
400
|
|
State
|
Daily aggregations
|
400
|
|
Event
|
Raw data
|
100
|
|
Aem
|
Raw data
|
30
|
|
Aem
|
Daily aggregations
|
400
|
|
Perf
|
Raw data
|
10
|
|
Perf
|
Hourly aggregations
|
400
|
|
Perf
|
Daily aggregations
|
400
|
Settings for grooming the Data Warehouse can be changed through SQL Server Management Studio.
To change grooming settings in the Reporting data warehouse
1. On the Windows desktop, click Start, point to Programs, point to Microsoft SQL Server 2005, and then click SQL Server Management Studio.
2. In the Connect to Server dialog box, in the ServerType list, select DatabaseEngine, in the ServerName list select the server and instance for your Reporting data warehouse (for example, computer\INSTANCE1), in Authentication list, select WindowsAuthentication, and then click Connect.
3. In the Object Explorer pane, expand Databases, expand OperationsManagerDW, and then expand Tables.
4. Right-click dbo.Dataset, and then click OpenTable.
5. Locate the dataset for which you want to change the grooming setting in the DatasetDefaultName column and make note of its GUID in the DatasetId column.
6. In the Object Explorer pane, right-click dbo.StandardDatasetAggregation and then click Open Table.
7. In the DatasetId column, locate the dataset GUID you noted in step 5. Multiple entries of the same GUID might display.
8. Locate the aggregation type from the list in the AggregationTypeId column by using the following values:
- 0 = raw, non aggregated data
- 10 = subhourly
- 20 = hourly
- 30 = daily
After you have located the dataset and its aggregation type, scroll to the MaxDataAgeDays column, and then edit the value there to set the grooming interval.
|
Managing Web Console Servers in Operations Manager 2007
The Web console server provides a browser based alternative to the Monitoring pane of the Operations Manager 2007 Operations console. The Web console server is commonly used when you want to access Operations Manager 2007 Management Group monitoring data:
- From the internet.
- Without installing the Operations console.
- From a location with low-bandwidth connectivity.
- When notifications are configured to contain hyperlinks to the relevant alerts in the Web console.
As your IT environment or monitoring requirements change you may need to add or remove Web console servers from an Operations Manager 2007 Management Group or perform tasks on a Web console server. For information about designing your Operations Manager 2007 Management Group, see http://go.microsoft.com/fwlink/?LinkId=95134.
Add a Web Console Server to a Management Group
Add a Web console server to an Operations Manager 2007 Management Group to provide Web-based access to monitoring data. For information about deploying a Web console server, see http://go.microsoft.com/fwlink/?LinkId=95135.
Configure Web Console to Fail Over
You can manually configure the Web console to fail over to another Root Management Server.
To configure Web Console to fail over
|
1. Using Notepad, open the file Web.Config. The default location for this file is C:\Program Files\System Center Operations Manager 2007\Web Console.
Note
You can use any editor that saves in plain text.
2. Change the following line to include the new Remote Management Server:
<add key=”MOMServer” value=”<provide new RMS server name>” />
3. Save your changes.
|
Change the Authentication Used by a Web Console Server
A Web console server is configured at installation to use either Windows or forms-based authentication. To change the authentication used by a Web console server, you must uninstall the Web console server and reinstall it. Use Add or Remove to modify the installation of System Center Operations Manager 2007 and remove the Web console feature. For information about designing your Operations Manager 2007 Management Group, see http://go.microsoft.com/fwlink/?LinkId=95134. For information about deploying a Web console server, see http://go.microsoft.com/fwlink/?LinkId=95135.
Enable Secure Sockets Layer on a Web Console Server
Configure a Web console server that uses forms-based authentication to use secure sockets layer (SSL), for a more secure Web console experience. For information about configuring the Web console server to use SSL, see the http://go.microsoft.com/fwlink/?LinkId=95136.
Update the Certificate on Web Console Servers
Certificates expire or there could be a security breach involving the certificate used for SSL connects to the Web console server. In both of these examples you will need to apply a new certificate to help maintain uninterrupted secure availability of the Web console server. For information about applying certificates to the Web console server, see the http://go.microsoft.com/fwlink/?LinkId=95136.
Remove a Web Console Server from a Management Group
You may want to remove a Web console server from an Operations Manager 2007 Management Group, for reasons such as hardware consolidation. Use Add or Remove to modify the installation of System Center Operations Manager 2007 and remove the Web console feature.
Managing Connected Management Groups in Operations Manager 2007
Connected Management Groups allow for the consolidation of alerts and the running of tasks from multiple Management Groups. Tasks can be initiated from a local Management Group to run on managed objects of a connected Management Group. This scenario is used to scale up the number of managed computers or objects you can monitor beyond the capabilities of a single Management Group.
The management group in which the data is consolidated is called the local management group, and those that contribute their data to the local management group are called the connected management groups. They relate to each other in a hierarchical fashion, with connected groups reporting up to local groups. The connected groups are in a peer-to-peer relationship with each other. Each connected group has no visibility or interaction with the other connected groups; the visibility is strictly from local Management Group to connected Management Group.
Communications between the connected and local Management Groups occurs between the Root Management Servers over TCP port 5724.
To Connect Operations Manager Management Groups
Use the following procedure to connect two Management Groups
To connect Operations Manager Management Groups
1. Log on to the computer with a user account that is a member of the Operations Manager Administrator role for the Operations Manager 2007 Management Group.
2. In the Operations console, click the Administration button.
Note
When you run the Operations console on a computer that is not a Management Server, the Connect To Server dialog box displays. In the Server name text box, type the name of the Operations Manager 2007 Management Server that you want the Operations console to connect to.
3. In the Administration pane, expand Administration, right-click ConnectedManagementGroups, and then click AddManagementGroup.
4. In the Add Management Group dialog box, in the Management Group name text box, type the name of connected Management Group.
5. In the Root Management Server text box, type the name of the Root Management Server in the connected Management Group.
Note
You must define the Root Management Server by its fully qualified domain name (FQDN).
6. Select one of the following radio buttons
Note
In either case, the account you use must be a member of the Operations Manager 2007 Administrators role for the connected Management Group.
- Select Use SDK service account if the SDK Service account is the same account in both Management Groups.
- Select Other user account if different credentials were used for the SDK service account in each Management group, and then enter the credentials for the SDK service account used in the connected Management Group.
7. Click Add.
|
To configure user roles for connected Management Groups
If you are attempting to view one or more connected Management Groups, the credentials you provide must be must be a member of a user role in each of the connected Management Groups. The scope defined for this user role will define the scope of alerts that can be viewed.
Note
The Show Connected Alerts button will not be displayed to a user if they are a member of user role which is scoped for All Groups.
For example, consider an environment where two Management Groups are needed to monitor a large number of SQL Servers. Both Management Groups have been connected. Tom has the responsibility of monitoring SQL Servers. The Operations Manager administrator wants Tom to be able to view alerts from both Management Groups in a single view. The Operations Manager administrators in both connected Management Groups assign Tom’s account to a SQL Server Operator user role. When Tom clicks Show Connected Alerts, only SQL Server-related alerts from both Management Groups are displayed.
On the local Management Group, Tom will need to be a member of a user role whose group scope includes the connected Management Groups. Connected Management Groups are listed as object groups in the Group Scope tab in the User Role Properties dialog box. Only connected Management Groups that are selected can be viewed. For more information about user roles, see the Operations Manager 2007 Security Guide at http://go.microsoft.com/fwlink/?LinkId=64017.
To view alerts from connected Management Groups
Every time you start the Operations console, only alerts from the local Management Group will be displayed. To view alerts from the connected Management Group, you will need to provide credentials for a user from the connected Management Group.
To view alerts from the connected Management Group
|
1. Start the Operations console, click the Monitoring button.
2. In the Monitoring pane, expand Monitoring, and then click ActiveAlerts.
3. In the Active Alerts pane, in the toolbar, click Show Connected Alerts.
4. In the Enter Credentials dialog box, type the username, password, and domain name of a user in the connected Management Group
Note
The credentials entered must be from a user in the connected Management Groups that is a member of a role in Operations Manager. The scope of alerts that can be viewed are determined by the scope of the user’s credentials.
5. Click OK.
|
Connecting Management Groups across untrusted domains
There are two topologies available for connecting Management Groups that span untrusted domains. If only one connected Management Group is going to be connected to one local Management Group, then the two Management Groups themselves can exist entirely within their respective domains as shown in the following figure.
If there are more than three Management Groups that are going to be connected, one local Management Group and two or more connected Management Groups, then both the local and connected Management Groups must span the two domains as shown in the following illustration.
In this either example, the same rules for user roles still apply as described in the To configure user roles for connected Management Groups topic in this document.
Managing Audit Collection Services in Operations Manager 2007
This topic will tell you how to configure, use, and maintain an Audit Collection Services (ACS) implementation in your environment. It does not cover ACS planning and deployment tasks. For planning and deployment guidance, see Operations Manager 2007 Deployment Guide. This topic presumes a deployed and functioning ACS infrastructure.
Configuring and using ACS consists of the following steps:
1. Planning and implementing your audit policy
2. Setting the filter on the ACS Collector
3. Configuring and using ACS reporting
4. Maintenance
Developing an Audit Plan
ACS collects and stores all the security event log entries from computers on which it is enabled. It does so with no regard as to what those events are or what they mean. It is up to you to determine what events you need captured and stored to fulfill your organization’s auditing requirements. The process of determining what those requirements are and how they translate into something that is actionable is called developing an audit plan. From the audit plan, you implement an audit policy via Group Policy objects at the domain or local level. It is the configuration of Group Policy objects that tells the security subsystem to write events to the security event log when a particular event or change occurs on a computer or in your environment. This process creates the trail of audited events that ACS collects.
Determine What Needs to be Audited
Companies are implementing ACS in response to various legal and regulatory requirements and for their own security, so you will not be able to determine by yourself what needs to be audited. You will need to involve individuals from several different areas of your company to develop an effective audit plan.
- IT Security—This team are those people who are responsible for responding to security incidents in your company and for developing the IT security policy. They should already have a good idea of the types of events and changes that need to be captured to satisfy the legal and regulatory needs of your company.
- Management and Legal—These individuals are responsible for ensuring your company is in compliance with regulatory policies. They likely have a deep understanding of those policies and can help elucidate the type of information that they need.
- Business Process Owners—The business process owners will have the best understanding of the types of activities and events that occur in the applications that they use to run their business. These events and activities are then matched to the requirements from the legal and management areas. You need to understand these events and activities and where they occur to be able to audit them.
In general, it is not effective or efficient to audit all activity and changes and to capture all events. This approach results in gathering a great deal of noise events, which can obscure the data that is really needed when reconstructing a series of events, thereby impeding the overall process.
Audit Best Practices
Each company’s business requirements and IT environment are unique. As such, each company’s audit policy is also unique. What you choose to audit is up to you. Here are some general recommendations on what to audit:
- Audit success and failure events in the system event category.
- Audit success events in the policy change event category on domain controllers.
- Audit success events in the account management category.
- Audit success events in the logon event category.
- Audit success events in the account logon event category on domain controllers.
- Be specific when setting up auditing on an object.
For additional suggestions on auditing security events, see Auditing Security Events Best practices
Implementing your Audit Policy
Audit plans are implemented in your environment through the modification and application of the Domain Controller Audit Group Policy, Domain Audit Group Policy and local Audit Group Policy as needed. If your auditing plan calls for tracking interactions with Active Directory or with objects such as files, you will also need to configure the System Access Control List (SACL) on those objects. For in-depth information about Auditing and Windows security, see Windows Server 2003 Product Help Auditing Policy and Special Coverage: Windows Server 2008: Auditing and Compliance in Windows Server 2008.
Audit policy settings are found in the Local Security Settings in the Administrative tools folder. Audit policies for domain controllers are defined once and applied to all domain controllers. This is done via the Domain Controller Security Policy tool in the Administrative Tools folder. Audit policy for the rest of the domain member computers can be defined at the domain level in the Domain Security Policy tool, which is located in the Administrative Tools folder on all domain controllers. There are nine common audit policy categories for Windows Server 2003 and Vista, as shown in the following list, and a few more for Windows Server 2008:
- Audit account logon events
- Audit account management
- Audit directory service access
- Audit logon events
- Audit object access
- Audit policy change
- Audit privilege use
- Audit process tracking
- Audit system events
On a member server, each of these audit policy categories can be set to Success, Failure, or No auditing. On a domain controller, in both the domain controller security policies and domain security policies, the options are to Define these policy settings, Success, Failure, or No auditing. In this case, the value of No auditing indicates that the Define these policy settings option has been selected, but that neither success nor failure options have been selected. Note that the Success and Failure options are not mutually exclusive, both can be selected. For the audit directory service access and audit object access audit policy categories, you must also configure the SACLs for the objects you want audited.
To access the Audit PolicyCcategories on a Standalone Server
|
1. Click Start, and select Administrative Tools, Local Security Policy.
2. Expand the Local Policies node to expose the Audit Policy node. The nine audit policy categories will be listed in the results pane.
3. Double-click the audit policy that you are interested in to open its property page. Here you can select to audit success and failure attempts at interaction, as well as get an explanation of the audit policy category on the Explain This Setting tab.
4. Click OK to save your settings.
|
To access the Domain Controller Security Policy
|
1. Log on to a domain controller with domain administrator rights.
2. Click Start, and select Administrative Tools, Domain Controller Security Policy.
3. Expand the Local Policies node to expose the Audit Policy node. The nine audit policy categories will be listed in the results pane.
4. Double-click the audit policy that you are interested in to open its property page. Here you can select to Define these policy settings and then select to audit Success and/or Failure attempts as desired.
|
Note
To access the domain security policy, follow the same procedure as accessing the domain controller security policy except select Domain Security Policy in step 2 of the “To access the Domain Controller Security Policy” procedure.
Preparing the Environment
This topic presumes that you have already successfully deployed the ACS collector server role and database in your Operations Manager 2007 environment. In addition to this, you should have already deployed Operations Manager 2007 agents to the computers that you will be collecting auditing information from. These computers should appear under the Agent Managed folder in the Operations Manager 2007 Operations console Administration view.
Security Event Log sizing
The ACS forwarder sends all security events from a monitored computer to the ACS collector server in near real time. As it does so, it updates a watermark that indicates which event was last successfully sent to the ACS collector. The ACS collector server buffers the incoming events for performance and reliability. If the ACS forwarder cannot communicate with the ACS collector, security events will not be lost to ACS as long as they can be written to the security event log. Then, when communications are restored, the ACS forwarder consults the watermark and picks up sending events where it left off. In effect, the security event log is the buffer that the ACS forwarder can use if needed.
For the security event log buffering process to work, the log must be of sufficient size to accommodate all the events that could be written to it in the case of a forwarder-to-collector communication failure. This is true no matter which security log retention method is used: Overwrite events by days, Overwrite events as needed, or Do not overwrite events (clear log manually).
The maximum size for the security event log in Windows Server 2003 (any edition) is 4 GB. This can be set locally in the properties of the log itself, or it can be set at the domain level for domain-joined computers in the Domain Security Policy and for all domain controllers in the Domain Controller Security Policy.
Enabling ACS Forwarders
Now that you have developed your audit plan and implemented it via an audit policy, you can begin collecting audited events from the security logs of the desired computers. The ACS forwarder component is embedded in the Operations Manager agent and is disabled by default. After it is enabled, the ACS forwarder will send all security event log events to the ACS collector they are configured to send to. ACS forwarders can be enabled either through the Operations console or programmatically by using the Operations Manager 2007 command shell extension to the Windows PowerShell.
To Enable the ACS Forwarder via the Operations console
|
1. Log on the Operations console with an account that is scoped to manage the agents that you want to enable ACS forwarding on. This account does not need to have local administrator rights on each agent computer that you want to enable as an ACS forwarder. You can provide these credentials when you run the Enable Audit Collection task.
2. In the Operations console, click the Monitoring button.
Note
When you run the Operations console on a computer that is not a Management Server, the Connect To Server dialog box displays. In the Server name text box, type the name of the Operations Manager 2007 Management Server that you want the Operations console to connect to.
3. In the Monitoring pane, expand Operations Manager, expand Agent, and then click Agent Health State. This view has two panes, and the actions in this procedure are performed in the right hand pane.
4. In the details pane, click all agents that you want to enable as ACS forwarders. You can make multiple selections by pressing CTRL or SHIFT.
5. In the Actions pane, under Health Service Tasks, click Enable Audit Collection. The Run Task – Enable Audit Collection dialog box displays.
6. In the Task Parameters section, click Override. The Override Task Parameters dialog box displays.
7. In the Override the task parameters with the new values section, click the CollectorServer parameter; in the New Value column, type the FQDN of the ACS collector and then click Override.
8. In the Task credentials section, click Other. In the User Name box, type the name of a user account that belongs to the local Administrators group on the agent computers. In the Password box, type the password for this user account. Click to expand the Domain drop-down list to view the available domains, and then click the domain of the user account.
9. Click Run Task. The Task Status dialog box displays, tracking the progress of the task.
10. When the task completes successfully, click Close.
|
Note
If you need to change which ACS collector that an ACS forwarder is assigned to, use this same procedure except in the Override the task parameters with the new values field, type the FQDN of the new, desired ACS collector.
On the product CD, Windows PowerShell scripts have been included for enabling and disabling the ACS forwarder. These scripts require a set of credentials that have administrator rights on every machine for which you want to enable ACS and the name of the ACS collector server. These scripts are located on the product CD under \acs\amd64 or acs\i386. They are called EnableForwarding.ps1 for enabling ACS forwarders and DisableForwarding.ps1 for disabling ACS forwarders.
To Target Enable ACS Forwarders for a Computer Group
|
1. Log on to the Operations console with an account that is in the Administrator role and navigate to the Monitoring view.
2. In the Monitoring view, select the Discovered Inventory object, and in the Actions pane select Change target type….
3. Ensure that the View all targets option is selected, and in the Target column, select Computer Group. This will list all the discovered computer groups in your management group.
4. Select the computer group that you want to enable the ACS forwarder for, and right-click to open the context menu.
5. From the context menu, select Open and Command Shell… . This sets the focus of the command shell window to the selected computer group. If you want to see specifically which computers are included in the selected group, type dir for a listing.
6. At the command shell command prompt, type the full path to the script you want to use, followed by the name of the server that the ACS collector is installed on—for example: d:\selectcdimage\acs\i386\enableforwarding.ps1 ContosoACSCollector. You will be prompted for credentials that have administrative rights on all the computers that are agent monitored in the management group in which you are working. You must provide these credentials in domain\username format.
|
Note
If you need to change which ACS collector that an ACS forwarder is assigned to, use this same procedure except type d:\selectcdimage\acs\i386\enableforwarding.ps1 <NameOfDesiredCollectorContosoACSCollector>.
Setting the Collector- Side Filter
The first step in implementing ACS was to make sure that the events you want get written to the security event logs on the desired computers. All of these events plus all the events that are written to the security event log by default are sent to the ACS collector. This can result in a very large volume of events being sent to the collector, which processes them and inserts them into the ACS database.
To reduce the volume of data being sent and to help eliminate noise events, you can configure a filter on the ACS collector. The filter is formatted as a Windows Management Instrumentation Query Language (WQL) query. The default filter is select * from AdtsEvent, which means accept all incoming events. The filter is controlled through the AdtAdmin command-line utility. The filter that can be defined is exclusive in nature only. This means you can configure the filter only to exclude events based on eventid or service name.
The AdtAdmin utility is found in the \Program Files\System Center Operations Manager 2007\acs\<platform> folder. For a full listing of ADTAdmin parameters and options, see the Operations Manager 2007 online help. AdtAdmin has 12 parameters in total. Only two of these switches are relevant to setting the collector site filter, as described in the following list. For a complete listing of the AdtAdmin switches, run the AdtAdmin command with the /? switch.
|
parameter
|
description
|
|
-getquery
|
Displays the WQL queries that are active on an ACS collector
|
|
-setquery
|
Configures the WQL query that the ACS collector uses to filter audit event data
|
To DetermineWwhat Events to Filter Out
When you developed your audit plan and implemented your audit policy, you defined the events that you needed to capture and save. All events except those are noise events and can be filtered out. Although you make the final determination about what noise events are and what valuable events are, a list of suggested noise events can be found in Appendix A of the Security Monitoring and Attack Detection Planning Guide. This list gives you a good place to start your filtering planning from, and it provides descriptions of the events. In addition to this list, you should consult the Planning_-_Event_Counts report under the Audit Reports folder in the Reporting view of the Operations console. This report groups all the audit events that have been received by event ID. It includes the number of events by ID and what percentage of the total number of events any single event type is. After you start collecting events and you know what each event type means, you can use this report to help you identify the most frequently occurring noise events.
Warning
There is some risk in excluding any information from an audit, but you must evaluate the magnitude of that risk against the cost in both performance and hardware that results from increased event collection load and agent load.
How to Set the Filter
You will use the AdtAdmin –setquery to set the query for the filter. This command has two subparameters, –collector, and –query, that must be used to specify which collector to connect to and to specify the syntax of the query, respectively.
How to Configure the ACS Collector Filter using AdtAdmin – setquery
|
1. Log on to the ACS collector server on which you want to configure the filter with an account that is a member of the Operations Manager 2007 Administrator role.
2. Open a command prompt, and navigate to the \Program Files\System Center Operations Manager 2007\acs\<platform directory.
3. Type the command following this syntax: adtadmin –setquery –collector:<collectorname> -query:<querysyntax>
|
For example, the following query filters out events generated by System, Local Service, and Network Service services, and it also filters events that have specified event ID numbers.adtadmin -setquery -collector:”Collector Name” /query:”SELECT * FROM AdtsEvent WHERE NOT ((HeaderUser=’SYSTEM’ OR HeaderUser=’LOCAL SERVICE’ OR HeaderUser=’NETWORK SERVICE’) OR (EventId=538 OR EventId=566 OR EventId=672 OR EventId=680 OR (EventId>=541 AND EventId<=547)))”
To Verify the Filter is Valid
|
1. Open the Operations console, and open the Microsoft Audit Collection Services folder in the Monitoring view.
2. Open the Collector folder, open the State View, and confirm that the collector is in a healthy state.
3. If the collector is not in a healthy state, look in the collector’s Event View for eventOpppsMgr log\ADtServer 4670 The collector was unable to start because it was unable to initialize the WMI provider.
|
For more information about the WQL query syntax, see Querying with WQL and WMI and SQL
ACS Reporting
After auditing data is received by the ACS collector and the inbound events are filtered, the events are processed to combine common fields and remove extraneous data and then inserted into the ACS database. By default, ACS data is kept in the database for 14 days, though this can be modified. Operations Manager makes this data visible and consumable through its reporting feature. There is a set of report definition files specifically for ACS data that must be installed to be able to access the ACS data. This procedure presumes that you have already installed ACS reporting. For more information about installing ACS reports, see How to Deploy Operations Manager 2007 ACS Reporting
ACS reports are accessible in the Reporting view of the Operations console. They are in the Audit Reports folder under the Reporting folder. ACS reporting installs 18 reports and two audit report templates. The audit report templates are used when you want to create an entirely new audit report in Microsoft SQL Server 2005 Report Builder. Report Builder is accessed by clicking the Design a new report link in the Actions pane.
- Access_Violation_-_Unsuccessful _Logon_Attempts
- Account_Management_-_Domain_and_Built-in_Administrators_Changes
- Account_Management_-_Passwords_Change_Attempts_by_Non-owner
- Account_Managment_-_User_Accounts_Created
- Account_Management_-_User_Accounts_Deleted
- Forensic_-_All_Events_For_Specified_Computer
- Forensic_-_All_Events_For_Specified_User
- Forensic_-_All_Events_With_Specified_Event_ID
- Planning_-_Event_Counts
- Planning_-_Event_Counts_By_Computer
- Planning_-_Hourly_Event_Distribution
- Planning_-_Logon_Counts_of_Privileged_Users
- System_Integrity_-_Audit_Failure
- System_Integrity_-_Audit_Log_Cleared
- Usage_-_Object_Access
- Usage_-_Privileged_Logon
- Usage_-_Sensitive_Security_Groups_Changes
- Usage_-_User_Logon
- Audit_Report_Template
- Audit5_Report_Template
Working with Reports
In the Reporting view, there are four folders:
- Reporting—This folder contains all reports that have been published to the SQL Server Reporting Services (SSRS) site. This includes all reports that are imported as components of management packs, reports that are designed and saved using the Report Builder tool, and any reports that you customize, save, and publish so that they are publicly available.
- Authored Reports—This folder contains reports that you have modified from the Reporting folder and published to the SSRS site. By default, these reports are not viewable to the public, only to the publisher of the report. This is true when the report is accessed via the Operations console or the SSRS Web site, where it will appear in the My Reports folder.
- Favorites—This folder is for reports that you use frequently and that you want to be available in the Operations Manager Web console. You can preset parameters for a published report, run the report, and then from the reports’ File menu, select Save to favorites…
- Scheduled Reports—This folder is for reports that you want to run on a one-time or recurring basis. Scheduling reports is useful for delivering rendered reports to a variety of locations, such as file shares, or to an e-mail address in a variety of formats, such as Microsoft Office Excel, .PDF, TIFF, CSV, and so forth.
For more information about running, publishing, and working with reports, see Managing Reporting in Operations Manager 2007 in this guide and the Operations Manager 2007 Report Authoring Guide
Tip
ACS reporting has not been fully integrated with Operations Manager Reporting yet; therefore, use of functions such as scheduling and relative dates in the generation of ACS reports might not give the desired results.
Maintenance
The day-to-day care and feeding of your ACS infrastructure is minimal. Most commonly, you might need to change the data-retention period that you configured during setup and change which collector a forwarder works with. For more information about how to change the ACS collector that an ACS forwarder is reporting to, see the Enabling ACS Forwarders section earlier in this topic.
Changing the ACS DataRretention Period
Operations Manager grooms, or removes, data from its various databases at regular configurable intervals. For the Operations database, this is done in the Operations console. For the ACS database, these settings are configured during setup with a default value of 14 days. This means that every day, all database partitions (and their data) that are older than 14 days are dropped or deleted. Because of the volume of data that ACS can accumulate, 14 days is not an unreasonable setting. However, some companies might need to retain data for longer periods and they must have already planned for that when making the sizing and performance calculations for their environment. You can change the retention period for the ACS data by following this procedure.
To Change the ACS Data- Retention Period
|
1. Log on to the computer running SQL Server that hosts the ACS database with an account that has administrative rights to the ACS database.
2. Open the SQL Server Management Studio tool, and connect to the database engine.
3. Expand the Databases folder, and select the OperationsManagerAC database.
4. Right-click to open the context menu and select New Query….
5. In the Query pane, type the following, where number of days to retain data + 1 equals the number of days you want to pass before data that has aged past that point is deleted. For example, if you want to retain data for 30 days, type 31
USE OperationsManagerAC UPDATE dtConfig SET Value = <number of days to retain data + 1> WHERE Id = 6 and then click the Execute button on the toolbar. This will run the query and then open the Messages pane, which should read (1 row(s) affected).
6. To view the new setting, delete the previous query text from the Query pane and enter SELECT * FROM dtConfig. This will open the Results pane below the Query pane.
7. Look at the value in the sixth row; it should now equal the value you entered for <number of days to retain data + 1>.
8. Restart the Operations Manager Audit Collection Service for this to take effect.
|
Using the Operations Manager Command Shell
The Operations Manager 2007 Command Shell is installed with the Operations Manager console, and provides a command-line environment and task-based scripting technology that you can use to automate most Operations Manager administrative tasks.
How the Operations Manager Command Shell Works
The Operations Manager Command shell is built on Windows PowerShell. Operations Manager Command Shell extends Windows Command shell with over 80 additional small utility programs, called cmdlets, that can either be run directly from the command shell prompt or called from within a batch file or script. Cmdlets can be used by themselves, or they can be combined with other cmdlets to perform complex administrative tasks. Unlike traditional command-line environments that work by returning text results to the end user or routing (“piping”) text to different command-line utilities, PowerShell manipulates .NET Framework objects directly. This provides a more robust and efficient mechanism for interacting with the system.
This topic serves as an overview to the Operations Manager Command Shell. To learn more about PowerShell, see thehttp://go.microsoft.com/fwlink/?LinkID=128867.
Using the Operations Manager Command Shell
In this section, we will walk through some common tasks with the Operations Manager 2007 Command Shell.
Launch the Operations Manager 2007 Command Shell and list the available commands
|
1. To launch the Operations Manager 2007 Command Shell, click Start, select Programs, and then select Command Shell from the System Center Operations Manager 2007 menu.
2. From the command shell prompt, type Get-OperationsManagerCommand to retrieve a list of all of the available Operations Manager 2007 cmdlets.
3. To see help for any specific cmdlet, type get-help followed by the name of the cmdlet. For example, type
get-help Get-State
to retrieve help information about the Get-State cmdlet.
|
Command Shell Usage Examples
This section contains a number of examples of command shell usage.
Important
The –name and –criteria parameters that are used by the command shell are case sensitive.
Export management packs
|
1. To export a management pack:
get-managementPack -name Microsoft.SQLServer.2005.Monitoring | export-managementPack -path c:\mp
2. To export all management packs in a management group:
get-managementPack | export-managementPack -path c:\mp
3. To export all management packs that contain a specified string in their name:
get-managementPack | where {$_.name –match ‘SQL’}
|
Examine management pack elements
|
1. To list all rules by management pack:
get-rule | select @{name=”MP”;expression={foreach-Object {$_.GetManagementPack().DisplayName}}},DisplayName | sort mp,displayName
2. To list all monitors in a specific management pack:
(get-managementPack -name Microsoft.SQLServer.2005.Monitoring) | get-monitor | sort displayName | ft displayName
3. To list all disabled discoveries:
get-discovery | where {$_.enabled -eq ‘false’} | ft displayName
|
View Alert Data
|
1. To view all unresolved alerts:
get-alert -criteria “ResolutionState <> 255″
2. To view all alerts grouped by severity and name:
get-alert -criteria “ResolutionState <> 255″ | sort severity,name | group severity,name
3. To resolve all alerts generated by rules:
get-alert -criteria “ResolutionState <> 255 and IsMonitorAlert = ‘False’” | resolve-Alert
|
Retrieve Performance Data
|
1. The example below extracts processor utilization data for all computers for the month of October 2008 to a comma-delimited file:
> $startTime = get-date ‘10/1/2008′
> $endTime = get-date ‘10/31/2008′
> $pc = get-performanceCounter -criteria: “ObjectName=’Processor’ and
CounterName=’% Processor Time’ and MonitoringObjectPath=’web.contoso.com’”
> get-performanceCounterValue -startTime $startTime -endTime $endTime -
performanceCounter $pc | export-csv c:\scripts\mom\perf.csv
|
Additional Resources
For more information about Windows PowerShell:
- Windows PowerShell Technology Center
- Scripting With Windows PowerShell
- Windows PowerShell Owner’s Manual
Changing Passwords for Operations Manager Accounts
After the initial configuration of Operations Manager accounts password, you might need to change those passwords under some circumstances.
You will need to change the password for Operations Manager 2007 accounts if:
- You specified a domain or local computer accounts for an Operations Manager 2007 account.
- Your organization has instituted password expiration.
For more information about changing the passwords for Operations Manager 2007 accounts see the “Account Information for Operations Manager 2007″ section of the Operations Manager 2007 Security Guide.
Identifying the Root Management Server in Operations Manager 2007
The Root Management Server (RMS) is the first Management Server for a Management Group. Features unique to the RMS include:
- The Web console connects to the RMS
- The RMS contains the Root Management Server Encryption Key which is used to read and write data to the Operations Manager database
- You enter the computer name for the RMS when installing reporting
- While the OpsMgr SDK and OpsMgr Config Service will be installed on both a an RMS and Management Server, these two services should only be running on the RMS and disabled on the Management Server
You might need to identify the Root Management Server if you want to install an SSL Certificate for the Web console, to find the computer name, or to backup the Root Management Server Encryption Key. Use the following procedure to identify the Root Management Server.
To identify the Root Management Server using the Operations Console
|
1. Log on to the computer hosting an Operations console with an account that is a member of the Operations Manager Administrators role for the Operations Manager 2007 Management Group.
2. In the Operations console, click the Administration button.
Note
When you run the Operations console on a computer that is not a Management Server the Connect To Server dialog box displays. In the Server name text box, type the name of the Operations Manager 2007 Management Server that you want the Operations console to connect to.
3. Expand Administration, expand DeviceManagement, and then click ManagementServers.
4. In the Management Servers pane, the Management Server with Root Management Server equal to Yes is the Root Management Server.
|
If the Root Management Server has failed, the Operations console will be unable to connect however the computer name that the Operations console attempted to connect to will be displayed.
If a computer with an installation of Operations console is unavailable, you can use the following procedure to examine the registry of any computer hosting a Management Server or Gateway Server.
Caution
Incorrectly editing the registry can severely damage your system. Before making changes to the registry, you should back up any valued data on your computer.
To identify the Root Management Server using the registry
|
1. Log on to the computer with an account that is a member of the Administrators group.
2. On the Windows desktop, click Start, click Run, type regedit and then click OK.
3. On the RegistryEditor page, expand HKEY_LOCAL_MACHINE, expand SOFTWARE, expand Microsoft, expand MicrosoftOperationsManager, expand 3.0, and then click MachineSettings.
4. In the results pane, examine the string DefaultSDKService. The value of this string contains the name of the computer hosting the Root Management Server.
Note
A Management Server that was recently promoted to a Root Management Server might not be immediately reflected in the registry.
|
Scheduling Maintenance and Monitoring
This topic provides general guidelines for scheduling Operations Manager maintenance tasks.
Maintenance Tasks Schedule
By default, Operations Manager 2007 performs maintenance tasks daily to maintain optimal performance of the Operations Manager database. These maintenance tasks are defined as System Rules in the Operations Manager 2007 Management Pack.
The following table displays the maintenance task and the time they are scheduled to run:
|
Task
|
Description
|
Schedule
|
|
Discovery Data Grooming
|
A rule that deletes aged discovery data from the OperationsManager database.
|
Every day at 2 A.M.
|
|
Partition and Grooming
|
A rule that runs workflow to partition and delete aged data from the OperationsManager database.
|
Every day at 12 A.M.
|
|
Detect and Fix Object Space
|
A rule that repairs data block corruption in database schema objects.
|
Every 30 minutes
|
|
Auto Resolve Alerts
|
A rule that automatically resolves active alerts after a period of time.
|
Every day at 4 A.M.
|
To check the schedules for the grooming jobs
|
1. In the Operations Manager 2007 Operations console, click Authoring.
2. Under Authoring, expand Management Pack Objects, and then click Rules.
3. In the Rules pane, change the scope of Management Pack objects by clicking Scope.
4. In the Scope Management Pack Objects by target(s) dialog box, click Clear All.
5. In Look for, type Root Management Server to locate the Root Management Server target from the System Center Core Library.
6. Select Root Management Server, and then click OK.
7. In the Rules pane, right-click the specific rule, and then click Properties.
8. In the Properties dialog box, click the Configuration tab.
9. Under Data Sources, click View to display the configured schedule for the rule.
10. Click Close twice to close the Properties dialog box.
Note
The scheduled times of the grooming jobs cannot be reconfigured by using an override. If you need to change the schedules of these maintenance tasks, you must first disable them with an override and then create new system rules that match the configuration of the original with new schedules.
|
Backing up and Restoring Operations Manager 2007 Components
Before reading this section, you should review the Operations Manager 2007 Design Guide to understand the components of Operations Manager 2007, and to learn how to prepare for failure recovery.
As part of your maintenance plan, it is important to include a backup plan. This plan should be thoroughly tested and documented in a simulated environment using production backups. Ensure that the Operations Manager backup plan integrates into any existing backup procedures in the organization.
Decide on issues such as:
- What to back up
- How often to back up
- Complete or incremental backups
- How and when to practice a restore.
After you decide what the best backup strategies for your Operations Manager environment, develop and document a backup plan which will become part of the overall disaster recovery plan.
It is strongly recommend that you test your backup and restore procedures thoroughly. Testing helps to ensure that you have the required back ups to recover from various failures and that staff can run the procedures smoothly and quickly if a failure occurs.
You can use a test environment including all the Operations Manager 2007 components to test your backup and restore processes.
Note
The overall back-up practices in your organization might include backing up the disk drives that the Operations Manager 2007 agent is installed on. When backing up those disk drive, including the Management Servers, be sure to exclude the <Installed Partition>\System Center Operations Manager 2007\Health Service State folder.
In This Section
What to Back Up in Operations Manager 2007
Complete and Incremental Backups in Operations Manager 2007
Backup File Naming Conventions in Operations Manager 2007
Recommended Backup Schedule in Operations Manager 2007
Failure and Restore in Operations Manager 2007
Complete and Incremental Backups in Operations Manager 2007
You must ensure that databases backups are as recent and complete as possible. This topic provides information to help you decide how to incorporate both complete and incremental database backups into the overall databases backup plan.
Complete Database Backups
A complete database backup captures the entire database, including all entries in the transaction log, and excluding any unallocated extents in the files. Pages are read directly from disk to increase the speed of the operation.
You can re-create a database from its backup in one step by restoring a backup of the database. The restore process overwrites the existing database or creates the database if it does not exist. The restored database will match the state of the database at the time the backup completed, minus any uncommitted transactions. Uncommitted transactions are rolled back when the database is restored.
A complete database backup uses more storage space per backup than transaction log and incremental database backups. Consequently, complete database backups take longer and therefore are typically created less frequently than incremental database or transaction log backups.
Incremental Database Backups
An incremental (differential) database backup records only the data that has changed since the last database backup. You can frequently make incremental backups of a database because incremental database backups are smaller and faster than complete database backups. Making frequent incremental backups decreases your risk of losing data.
In case of database failure, you can use incremental database backups to restore the database to the point at which the incremental database backup was completed.
Transaction Log Backups
The transaction log is a serial record of all the transactions that have been performed against the database since the transaction log was last backed up. With transaction log backups, you can restore the database to a specific point in time (for example, prior to entering unwanted data), or to the point of failure.
When restoring a transaction log backup, Microsoft SQL Server rolls forward all changes recorded in the transaction log. When SQL Server reaches the end of the transaction log, the state of the database is exactly as it was at the time the backup operation started. If the database is recovered, SQL Server then rolls back all transactions that were incomplete when the backup operation started.
Note
The OperationsManagerDW database uses a simple recovery model which truncates all transactions after completion. This means that backing up the log file is insufficient. Perform a complete database file backup.
Backup File Naming Conventions in Operations Manager 2007
Naming conventions can help you distinguish between backup files from several management groups and from different times. You should use a naming convention for the various backup files to eliminate the possibility of unintentionally restoring a backup file from one management group to another management group.
Database Files Naming Conventions
There might be multiple management groups in your Operations Manager 2007 environment, therefore, be sure to include the management group name or some distinguishing name in the database backup file names.
You can also include other information in the file name such as the database name, date, and type of backup. For example, a file name might be OpsMgrDB_DIFFERENTIAL_<management group name>_11_01_2007 or REPORTING_FULL_<management group name>_11_01_2007.
Custom Management Packs Naming Conventions
For custom management pack backup files, as with databases, there might be multiple management groups in your Operations Manager 2007 environment. The configuration for any given custom management pack might differ between these management groups.
Include the management group name or some distinguishing name in the XML file name for these backups. You can also include other information in the file name such as the date to the name. For example, a file name might be: <management group name>_<Management pack name>_<Management pack version>_11_01_2007.xml.
What to Back Up in Operations Manager 2007
To be able to preserve data in case of a failure you must have a recent back up of Operations Manager databases and other important data as listed in this topic.
Data to Back Up
To ensure your ability to properly preserve and restore your Operations Manager 2007 environment, you should backup several key items as follows:
- Operations Manager databases: OperationsManager database, OperationsManagerDW database, and the ACS Audit database.
- Root Management Server encryption key
- IIS 6.0 Metabase
- Custom management packs
- Files such as custom reports and certificates
In the event that the entire management group is lost, you must have backups of both the OperationsManager database and the Root Management Server key to ensure a successful recovery. Therefore, at the minimum, ensure that your backup plans include both the OperationsManager database and the Root Management Server encryption key.
See Also
How to Schedule Back Ups of Operations Manager Databases
How to Back Up the Root Management Server Encryption Key
How to Back Up the IIS 6.0 Metabase
How to Back Up Custom Management Packs
How to Back Up Files
How to Schedule Back Ups of Operations Manager Databases
The Operations Manager databases contain critical data that is required by Operations Manager. It is critical that you back up this data, and that a recent back up is available if there is a failure. Plan to back up all databases described in this topic.
Use the procedure below to schedule a database backup using SQL Server Management Studio. Use this procedure to back up the OperationsManager, OperationsManagerACS, and OperationsManagerDW databases.
Schedule a Database Back Up
To schedule a database backup to a file
|
1. Start SQL Server Management Studio.
2. In the Connect to Server dialog box, select the appropriate values in the Server type drop-down list, in the Server name box, and in the Authentication box.
3. Click Connect.
4. In Object Explorer, expand Databases.
5. Right-click the database that you want to back up, click Tasks, and then click Back Up.
6. In the Back Up Database dialog box, type the name of the backup set in the Name box, and then under Destination, click Add.
7. In the Select Backup Destination dialog box, type a path and a file name in the Destination on disk box, and then click OK.
Important
The destination location must have enough available free disk space to store the backup files based upon the frequency of your backup schedule.
8. In the Script list, click Script Action to Job.
9. If you want to change job parameters, in the New Job dialog box, under Select a page, click Steps, and then click Edit.
10. Under Select a page, click Schedules, and then click New.
11. In the New Job Schedule dialog box, type in the job name in the Name box, specify the job schedule, and then click OK.
Note
If you want to configure alerts or notifications, you can click Alerts or Notifications under Select a page.
12. Click OK twice.
|
OperationsManager Database
The OperationsManagerdatabase contains almost all of the Operations Manager environment configuration settings, agent information, management pack s with customizations, operations data, and other data required for Operations Manager to operate properly.
It is critical that you back up the OperationsManager database regularly to preserve the latest information about your Operations Manager environment. A database failure without a recent backup will result in the loss of almost all Operations Manager-specific data, and you will need to rebuild the entire Operations Manager environment.
Note
If your backup procedure sets the OperationsManager database to be offline during backup, then Operations Manager caches incoming data, and then, after back up is complete, Operations Manager stores that data in the database.
Reporting Databases
Operations Manager Reporting uses the following databases:
- Operations Manager 2007 data warehouse (OperationsManagerDW)
- SQL Server Reporting Services databases (ReportServer and ReportServerTempDB)
The OperationsManagerDW database contains all of the performance and other operational data from your Operations Manager environment. SQL Reporting Services then uses this data to generate reports such as trend analysis and performance tracking.
To be able to restore reporting functionality in case of failure, it is critical that you back up the OperationsManagerDW database. When determining how often and when to back up this database, you should consider the following:
- This database can grow to a very large size (more than one terabyte) over time.
- Management Servers frequently write data to this database.
- IT SLA requirements based on the need for reporting availability in the organization.
Note
The OperationsManagerDW database uses a simple recovery model, which truncates all transactions after completion. Therefore, backing up only the log file is insufficient – you must back up the entire database.
The SQL Server Reporting Services databases store report definitions, report metadata, cached reports and snapshots. In case of failure, you can recreate report definitions by re-importing the reports. However, cached reports, which are reports that have already been created, will be lost.
To be able to restore reporting functionality in case of failure, it is recommended that you back up the SQL Server Reporting Server databases.
ACS Database
The ACS database, OperationsManagerAC, is the central repository for events and security logs that are collected by ACS forwarders on monitored computers.
The OperationsManagerAC database can grow significantly depending upon how many ACS forwarders send events to the ACS database and the filters configured to control what events are written to the database.
Master Database
The master database is a system database, which records all of the system-level information for a Microsoft SQL Server system, including the location of the database files. It also records all logon accounts and system configuration settings. The proper functionality of the master database is key to the operation of all of the databases in a SQL Server instance.
MSDB Database
The MSDB database, Msdbdata, is a SQL system database, which is used by the SQL Server agent to schedule jobs and alerts and for recording operators. The proper functionality of the MSDB database is key to the operation of all the databases in a SQL Server instance.
Note
This database contains task schedules that are vital to the health of the Operations Manager 2007 database, and should be included in your backup plan. You need to back up this database only after you configure Operations Manager 2007 or if you change the scheduled agent jobs.
How to Back Up the Root Management Server Encryption Key
The Root Management Server is the central point of configuration management and overall health monitoring of the entire managed environment.
The Root Management Server encryption key holds all the Run As Account information defined in the management group. To successfully restore a failed Root Management Server, you must use that key to reattach the databases and to access the Run As Accounts that have been encrypted with this key. If you need to restore the Root Management Server without this backup, you would need to re-enter your entire Run As Accounts.
To backup or to restore the Root Management Server key, you need to use the SecureStorageBackup tool. The tool can start the Encryption Key Backup or Restore Wizard, or run as a command line tool. The availability and the behavior of the tool depends on whether the console is installed on the management server or not.
The SecureStorageBackup tool functions as follows:
- If the console and a management server are both installed, the tool is installed in the Operations Manager Installation folder.
In this case, by default, the Encryption Key Backup or Restore Wizard runs at the final stage of Setup, allowing you to back up the key. Also, if you start the tool without arguments, it starts the Encryption Key Backup or Restore Wizard and if you start the tool with arguments, it runs as a command line tool.
- If the console is not installed, then the SecureStorageBackup tool is not installed. For example, this happens if you are installing Operations Manager on a clustered RMS without installing the console on any server. In this case, to use the tool, you must first copy it from the SupportTools folder on the installation media, to the installation folder on the management server.
In this case, the tool runs as a command line tool, and you must provide proper arguments. You can run SecureStorageBackup.exe with the ‘/?’ switch to get help for the tool.
When backing up the encryption key, always ensure that you provide back up location that is easily accessible in case you later need to retrieve the key. For more information about backing up the Root Management Server encryption key, see the Operations Manager Deployment Guide.
Use the procedures below to back up the Root Management Server encryption key.
Procedures
To start the Encryption Key Backup or Restore Wizard to back up the Root Management Server encryption key
|
1. Log on to the computer hosting the Root Management Server with an account that is a member of the Administrators group.
2. On the Windows desktop, click Start, and then click Run.
3. In the Run dialog box, type cmd and then click OK.
4. At the command prompt, enter:
cd <Operations Manager Installation Folder>
5. Type SecureStorageBackup and then press ENTER.
6. In the Encryption Key Backup or Restore Wizard, on the Backup or Restore? page, select the Backup the Encryption Key option, and then complete the wizard.
|
To start the SecureStorageBackup tool in a command line mode to back up the Root Management Server encryption key
|
1. Log on to the computer hosting the Root Management Server with an account that is a member of the Administrators group.
2. On the Windows desktop, click Start, and then click Run.
3. In the Run dialog box, type cmd and then click OK.
4. At the command prompt, enter
cd\<Operations Manager Installation Folder>
SecureStorageBackup Backup <BackupFile>
5. At the Please enter the password to use for storage/retrieval prompt, type a password that is at least eight characters long, and then press ENTER.
6. At the Please re-enter your password prompt, type the same password, and then press ENTER.
|
How to Back Up the IIS 6.0 Metabase
The Internet Information Services (IIS) metabase is a hierarchical store that contains configuration information and schema used to configure IIS. For Operations Manager, IIS supports components such as the Web console Server and SQL Server Reporting Services; therefore, you must back it up.
Use the following procedure to back up the IIS 6.0 metabase. For more information about the IIS 6.0 metabase, see the IIS 6.0 Technical Reference at http://go.microsoft.com/fwlink/?LinkId=93786.
Procedures
To back up the IIS 6.0 metabase
|
1. Open Control Panel, double-click Administrative Tools, and then double-click Internet Information Services (IIS) Manager.
2. Right-click the name of your computer in IIS Manager, point to All Tasks, and then click Backup/Restore Configuration.
3. In the Configuration Backup/Restore dialog box, click Create Backup, and then type a name for this backup.
Note
If you want to create secure backup, in the Configuration Backup dialog box, select the Encrypt backup using password check box, type a password in the Password box, and then type the same password in the Confirm password box. The backup name cannot contain any symbols, just letters and numbers.
4. Click OK to back up the administrative settings in the metabase.
The backup name and its date and time are now listed under Previous backups.
5. Click Close, and then close IIS Manager.
|
How to Back Up Custom Management Packs
Management packs contain monitoring rules for applications and services. Both sealed and unsealed management pack s can be customized by superseding its default values using overrides, or by defining custom rules or monitors. Custom management pack s are unsealed and are saved to a separate .xml management pack file. By default, the file is saved to the My Default management pack folder.
You should back up custom management pack s regularly even though backing up the OperationsManager database captures management pack information. Backing up custom management packs separately allows you to re-import them separately from the database, which can be useful in cases when you must roll back the customized changes in one or more custom management packs.
Use the export feature from the Operations console to back up management packs.
Procedures
To export a management pack
|
1. Log on to a management server with an account that is a member of the Operations Manager Administrators role for the Operation Manager 2007 management group.
2. In the Operations console, click Administration.
3. In the Administration pane, click Management Packs.
4. In the management packs pane, right-click the management pack you want to export, and then click Export Management Pack.
5. In the Save As dialog box, type the path and file name for the management pack file, or click Browse to save the file to a different directory, and then click Save.
|
How to Back Up Files
You might consider backing up important and custom files used by Operations Manager such as:
- Custom reports (*.rdl) files.
- Certificates from a stand-alone certification authority (CA) installed on an agent or gateway server across a trust boundary.
Procedures
How to back up files
|
1. Identify and locate the custom files that require back up.
2. Use the appropriate method to back up each type of files.
|
Recommended Backup Schedule in Operations Manager 2007
You should determine how often and when to run back ups. In general you should perform database backups according to your company’s backup policy.
Back Up Schedule
The following table suggests a schedule for regular backups of your Operations Manager 2007 components and related items. These suggestions are specific to your Operations Manager 2007 environment and are meant to complement other regularly-scheduled backups in your environment.
You should schedule those back up jobs at a time that does not collide with the schedule of the Operations Manager grooming tasks. The Operations Manager grooming jobs run on the Operations Manager 2007 Database Server and both read from and write to the database. Backing up the database during the same time might cause failures in either the backup or the grooming job, or both.
At a minimum, an incremental backup of the OperationsManager database should be performed on a daily basis. A complete backup should be performed on the OperationsManager database weekly. The master and msdb databases should be backed up any time a change occurs that affects either database, but you should back them up at least monthly.
|
Component to Back Up
|
Full Backup
|
Incremental Backup
|
|
OperationsManager
|
Daily
|
Not applicable
|
|
OperationsManagerDW
|
Monthly
|
Weekly
|
|
ReportServer
|
On a recurring basis, with the frequency depending on how often reports change in your organization, and every time after significant changes to report definitions (additions, changes and deletions).
|
Same as full backup
|
|
OperationsManagerAC
|
Monthly
|
Weekly
|
|
Master database (Master)
|
Every time after installing and configuring the Operations Manager database components and after making significant changes to logons or other security changes.
|
Per IT policies
|
|
Msdb database (Msdbdata)
|
After the initial installation and configuration of the Operations Manager database components.
|
After changing the scheduled SQL Server Agent jobs that Operations Manager uses.
|
|
Custom Management Packs (.xml files)
|
Monthly or after making significant changes to Management Packs.
|
Not applicable
|
Failure and Restore in Operations Manager 2007
Even with the best maintenance practices, data might become corrupted, causing interruption to Operations Manager 2007 functionality and loss of data.
There are various causes for failure. Some of the most common causes can be classified as:
- Hardware failure, such as the storage system impacting data availability or integrity
- Security breach or virus infection
- Accidental deletion or corruption of Active Directory Domain Services (AD DS) security information, such as accounts or groups
- Physical disaster
This section describes various Operations Manager failure scenarios, and how to restore Operations Manager components to resume services.
In This Section
Failure Recovery Scenarios for the Root Management Server
Impact of Failure in Operations Manager 2007
Various Operations Manager servers and components can potentially fail, impacting the Operations Manager functionality.
The amount of data and functionality lost during a failure is different in each failure scenario. It depends on the role of the failing component, on the Operations Manager deployment, on the length of time it takes to restore the failing component, and on the availability of back ups.
Impact of Failure
The minimal impact of failure is experienced if the Operations Manager deployment includes fail-over servers, or clustering to support high availability. The greatest impact is experienced if none of those is implemented. Also, in general, the longer it takes to restore the failing component, the risk of losing data and the amount of data lost are increased, and the level of services provided is decreased. For more information about minimizing the impact of failure, see Reduce the Impact of Failure below.
In some failure scenarios, Operations Manager is able to continue to function properly for a short period of time without losing data, and then, after you repair the failing component, complete functionality is automatically restored without any further intervention.
The following table lists the impact of failure of various Operations Manager components. In this table, the assumption is that each server listed performs only a single role, as specified.
|
Failing Component
|
Impact – Best Case Scenario
|
Impact – Worst Case Scenario
|
|
Management Server
|
Workload on additional Management Servers in the Management Group is increased until the failing management server is restored.
|
- Data is queued on managed computers and is not processed because agents are unable to send it to the Management Server.
- Agentless computers are not managed.
- Gateway servers cannot transfer data from agents to Management Server.
|
|
Root Management Server
|
As long as at least one server in the cluster is functioning – there is no impact.
|
- Consoles are unable to connect and manage configuration of the Management Group.
- Configuration management of the Management Group is unavailable.
- Connections to other Management Groups are unavailable.
- Cannot perform any Operations Manager administrative tasks, such as viewing, editing or managing objects.
- Operator console does not function.
- Connections to third-party management products using connectors are unavailable.
|
|
Operations Manager Reporting server (OperationsManager database is intact)
|
As long as at least one server in the cluster is functioning – there is no impact.
|
- Data from managed computers is not processed, and is not stored in the database. This data might eventually be lost.
- Performance on managed computers is degraded, because of the accumulated data.
- Cannot perform any Operations Manager administrative tasks, such as viewing, editing or managing objects.
- Reports do not contain up-to-date information.
- Operator console does not function.
- Changes to the management pack are not propagated to agents.
|
|
Operational Database
|
If log-shipping is implemented, then services might be reduced until the database is rebuilt.
Otherwise, clustering does not reduce the impact of failure (see next column for impact).
|
- Data from managed computers is not processed, and is not stored in the database. This data might eventually be lost.
- Management servers start to queue data in their cache. When the cache is full, the management servers start to drop data, starting with performance data.
- Cannot perform any Operations Manager administrative tasks, such as viewing, editing or managing objects.
- Reports do not contain up-to-date information.
- Operator console does not function.
- Changes to management pack s are not propagated to agents.
|
|
Data Warehouse server (OperationsManagerDW database is intact)
|
As long as at least one server in the cluster is functioning – there is no impact.
If the OperationsManagerDW database is failing, clustering does not reduce the impact of failure (see next column for impact).
|
- Cannot view, edit or manage reports.
- Cannot view, edit, or manage ACS Reports if installed on the same SQL Server.
|
|
Gateway Server
|
Agents failover to another gateway server and communication with Management Servers is not interrupted.
|
- Up-to-date monitoring data is not available because Agents and Management Servers cannot communicate.
|
|
Audit Collection Database
|
If the Audit Collection Database is intact, then as long as at least one server in the cluster is functioning – there is no impact.
If the Audit Collection Database is failing, clustering does not reduce the impact of failure (see next column for impact).
|
- Security events are queued on managed computers and are not processed. This data might eventually be lost.
- Performance on managed computers is degraded, because of the accumulated data.
- ACS reports do not contain up-to-date information.
|
|
Computer hosting Operator console
|
Not applicable.
|
- Cannot use the console on the failing computer.
|
|
ACS Collector Server
|
Not applicable.
|
- Audit events from ACS Forwarder are not processed.
|
Reduce the Impact of Failure
The effects of some server failures can be reduced significantly by adding redundancy or implementing a failover solution, such as clustering. Also, in that case, the urgency of restoration is greatly reduced.
The following list includes configuration options that add redundancy and clustering to the Operations Manager deployment. Implementing any of those options will reduce the impact of failure, and contribute to high availability of Operations Manager in your organization:
- Add Management Servers
- Install the Root Management Server into a Cluster service failover cluster
- Store databases in a Cluster service failover cluster
- Configure gateway servers for failover
- Configure log shipping
- Configure cross Management Group failover
Each option is further described below. For further information about deployment options that help ensure high availability and help reduce the impact of failure, see the Operations Manager 2007 Deployment Guide.
Add Management Servers
Implement more than one management server in a management group. This allows agents failover if a management server is failing, and uninterrupted functionality if the Root Management Server is failing.
If one management server is failing, the agents reporting to that management server automatically start reporting to another management server in the same Management Group. After the failing management server is restored, agents can resume reporting to that server.
If the Root Management Server is failing, you can promote an existing management server to the Root Management Server role. After the Root Management Server is restored, you can demote the temporary Root Management Server, and re-promote the restored server to its original Root Management Server role.
Install the Root Management Server into a Microsoft Cluster Services failover cluster
Install the Root Management Server into a Cluster service failover cluster. If an Root Management Server server fails, the Root Management server cluster continues to provide the Root Management Server services to the management group without interruption.
After you restore the failing Root Management Server, you can add that server to the Root Management Server cluster.
Store databases in a Microsoft Clustering Services (MSCS) failover cluster
Store the OperationsManager and the OperationsManagerDW databases in a Cluster service failover cluster. If a database becomes corrupted, the database cluster ensures continued availability of the database, thus ensuring uninterrupted functionality.
After you restore the corrupted database, you can add it again to the database cluster.
Configure gateway server failover to multiple Management Servers
Deploy multiple gateway servers to allow agents to fail over between gateway servers and to distribute management workload.
Gateway servers can also be configured for failover between Collection Management Servers in a Management Group if multiple Collection Management Servers are available.
Configure log Shipping
Log shipping maintains a copy of an Operations Manager database on a separate Microsoft SQL 2005 server. Log shipping maintains the copy of the database up-to-date by sending the transaction logs from the database that is being used, to the database copy.
If a database becomes corrupted, you can configure Operations Manager to temporarily use the copy of the database. After the original database is restored, you can re-configure Operations Manager to use that database.
Failure Recovery Scenarios for the Root Management Server
This topic describes three failure recovery scenarios for Root Management Servers.
These scenarios involve promoting a management server to replace the Root Management Server. In all cases, a management server must be already installed as part of the management group in order to be promoted to Root Management Server.
Root Management Servers Recovery
In order to use any of these scenarios, you must either have a back up of the Root Management Server encryption key or the Root Management Server must be available to allow backing up of the encryption key.
Figure 1 Scenario One
- If the Root Management Server fails, promote another management server to be the Root Management Server.
Figure 2 Scenario Two
- If the Root Management Server fails, promote another management server to be the Root Management Server. After the original Root Management Server is available again, you have the option of promoting it back to being the Root Management Server.
Figure 3 Scenario Three
- If the Root Management Server fails, promote another management server to be the Root Management Server. In the future, you can set up a new management server and promote it to be the Root Management Server.
Use the How to Promote a Management Server to a Root Management Server Role in Operations Manager 2007 procedure to promote a management server to be the Root Management Server. You can apply this procedure to all three scenarios.
See Also
How to Promote a Management Server to a Root Management Server Role in Operations Manager 2007
How to Back Up the Root Management Server Encryption Key
High Level Restore Guidelines in Operations Manager 2007
Use the following table for information about possible failure scenarios, and the general steps required to restore operations and data in that scenario.
General Restore Steps
|
Failing Component
|
General Restoration Steps
|
Required Backups
|
|
Management Server
|
With additional Management Servers:
1. Repair the server.
2. Reinstall Operations Manager management server on the repaired server.
3. After the failing management server is restored, Operations Manager agents will eventually resume reporting to that Management Server.
Without additional Management Servers:
1. Configure the Root Management Server as the Primary Management Server in the management group.
2. Install a new management server in the management group. Use the SQL Server that is hosting the Operations Manager database and use the same Action Account that was previously defined.
3. Configure the newly installed management server as the Primary Management Server.
|
None
|
|
Root Management Server
|
Clustered:
- Repair the failing server, and re-connect to the cluster.
Not clustered:
1. Promote existing management server to Root Management Server.
2. Repair the failing server.
3. Reinstall Operations Manager management server on the repaired server.
4. Demote temporary Root Management Server to Management Server.
5. Promote repaired server to Root Management Server.
|
Root Management Server encryption key
|
|
Data Warehouse server/ Operations Manager Reporting server (OperationsManager database is intact)
|
Clustered:
1. Repair the failing server or reinstall SQL Server and re-connect to the cluster.
2. If needed – configure all Management Servers to point to the repaired server.
Not clustered:
1. Repair the server as needed.
2. Restore the OperationsManager database.
|
- OperationsManager database
- Root Management Server encryption key
|
|
OperationsManager database
|
1. Reinstall the Operations Manager Reporting server component, if needed.
2. Restore the OperationsManager database.
If log shipping has been implemented:
- Rebuild and restore the database.
|
- OperationalDatabase database
- Root Management Server encryption key
|
|
Operations Manager Reporting server
|
Clustered:
1. Repair the server and re-connect to the cluster.
2. Reinstall Operations Manager Reporting server, if needed.
3. Restore OperationsManagerDW database, and ReportServer and ReportServerTempDB databases if needed.
|
- OperationsManagerDW database
|
|
Gateway Server
|
1. Repair the server if needed.
2. Reinstall Operations Manager gateway server, if needed.
|
None
|
|
Computer hosting Operator console
|
1. Repair the computer.
2. Reinstall Operations Manager console.
|
None
|
|
Audit Collection Database
|
1. Repair the Operations Manager ACS database server, if needed.
2. Reinstall SQL Server, if needed.
3. Reinstall the Operations Manager ACS database component, if needed.
4. Restore the Audit Collection database.
|
Audit Collection Database
|
|
ACS Collector Server
|
Do either of the following:
1. Repair the ACS Collector server, if needed.
2. Install the ACS Collector on another management server in the management group, if needed.
3. Install another management server in the management group and install the ACS Collector, if needed.
|
None
|
How to Restore Operations Manager 2007 Databases
Use the following procedure to restore an Operations Manager 2007 database using SQL Server Management Studio in SQL Server 2005.
Procedures
To restore a database backup
|
1. Start SQL Server Management Studio.
2. In the Connect to Server dialog box, select the appropriate values in the Server type drop-down combo box, in the Server name box, and in the Authentication box.
3. Click Connect.
4. In Object Explorer, expand Databases, and then select the OperationsManager, OperationsManagerAC, or OperationsManagerDW database.
5. Right-click the database, point to Tasks, and then click Restore.
6. Click Database to open the Restore Database dialog box.
7. On the General page, the name of the restoring database appears in the To database list.
8. In the To a point in time text box, either retain the default (the most recent possible) or select a specific date and time by clicking the browse button, which opens the Point in Time Restore dialog box.
9. To specify the source and location of the backup sets to restore, click the From Device option.
10. Click Browse to open the Specify Backup dialog box.
11. In the Backup media list box, select one of the listed device types. To select one or more devices for the Backup location list box, click Add.
12. In the Select the backup sets to restore grid, select the backups to restore. This grid displays the backups available for the specified location.
13. In the Restore options panel, select the Overwrite the existing database option.
14. In the Restore the database files as options panel, verify the original database file name and path are correct.
15. For the Recovery state options, specify the state option Leave the databases ready to use by rolling back the uncommitted transactions. Additional transaction logs cannot be restored.
16. Click OK to proceed with the database restore.
|
How to Restore the IIS 6.0 Metabase Backup in Operations Manager 2007
Use the following procedure to restore an IIS 6.0 Metabase backup.
Procedures
To restore an IIS 6.0 Metabase backup
|
1. Open Control Panel, double-click Administrative Tools, and then double-click Internet Information Services (IIS) Manager.
2. Right-click the name of your computer in IIS Manager, point to All Tasks, and then click Backup/Restore Configuration.
3. Under Previous backups, select the file name that you want, and then click Restore. If prompted for a password, type the password.
|
How to Restore the Root Management Server Encryption Key in Operations Manager 2007
To restore the Root Management Server key, you need to use the SecureStorageBackup tool. The tool can start the Encryption Key Backup or Restore Wizard, or run as a command line tool. The availability and the behavior of the tool depends on whether the console is installed on the management server or not.
The SecureStorageBackup tool behaves as follows:
- If the console and a management server are both installed, then the tool is installed in the Operations Manager installation folder.
In this case, if you start the tool without arguments, it starts the Encryption Key Backup or Restore Wizard. If you start the tool with arguments, it runs as a command line tool.
- If the console is not installed, then the SecureStorageBackup tool is not installed. In this case, to use the tool, you must first copy it from the SupportTools folder on the installation media, to the installation folder on the Management Server. For example, this happens if you are installing Operations Manager on a clustered RMS without installation the console on any server.
In this case, the tool runs as a command line tool, and you must provide proper arguments. You can run SecureStorageBackup.exe with the ‘/?’ switch to get help for the tool.
Use the procedures below to restore the Root Management Server encryption key, which is on the same server when recovering the Root Management Server, or on a different server when creating a clustered Root Management Server.
Procedures
To start the Encryption Key Backup or Restore Wizard to restore the Root Management Server encryption key
|
1. Log on to the computer hosting the Root Management Server with an account that is a member of the Administrators group.
2. On the Windows desktop, click Start, and then click Run.
3. In the Run dialog box, type cmd, and then click OK.
4. At the command prompt, enter:
cd <Operations Manager Installation Folder>
SecureStorageBackup
5. In the Encryption Key Backup or Restore Wizard, on the Backup or Restore? page, select the Restore the Encryption Key option and then complete the wizard.
|
To start the SecureStorageBackup tool in a command line mode to restore the Root Management Server encryption key
|
1. In a command prompt window enter:
cd\<Operations Manager Installation Folder>
SecureStorageBackup Restore <BackupFile>
2. At the Please enter the password to use for storage/retrieval prompt, type the password, and then press ENTER.
Use the same password that was used to back up the encryption keys.
|
Making Updates to a Operations Manager 2007 Deployment
After the initial deployment of Operations Manager, you might need to make changes or upgrades to the original deployment for reasons such as:
- You need to replace hardware that is experiencing problems and that is no longer considered reliable.
- You need to dedicate additional hardware to improve scalability and performance.
- You need to move a database and log file to a different volume because of space or performance reasons.
- You need to change hardware that is leased and is due to expire soon.
- You need to change or upgrade hardware to comply with new hardware standards.
- You initially installed multiple Operations Manager components on a single server and you need to distribute some components to other servers.
- You need to restore functionality in a failure scenario.
Operations Manager supports changes to your Operations Manager deployment as listed below. Be cautious when performing these operations as they can result in data loss if not performed correctly.
In This Section
How to Move the OperationsManager Database in Operations Manager 2007
How to Move the OperationsManagerDW Database in Operations Manager 2007
How to Move the OperationsManagerAC Database in Operations Manager 2007
How to Promote a Management Server to a Root Management Server Role in Operations Manager 2007
How to Remove a Management Server From a Computer in Operations Manager 2007
How to Move the Operations Manager Reporting Server in Operations Manager 2007
How to Move the OperationsManager Database in Operations Manager 2007
After the initial deployment of Operations Manager, you might need to move the OperationsManager database from one SQL Server 2005-based computer to another.
SQL Server 2005 supports the ability to change the location of the data files and of the log files between SQL Server-based computers, between instances on the same SQL Server-based computer, and different volumes on the same SQL Server-based computer. For more information about using this function in SQL Server, see the SQL Server 2005 documentation at http://go.microsoft.com/fwlink/?LinkId=93787.
The high-level steps of moving the OperationsManager database are as follows:
1. Backup the OperationsManager database.
2. Uninstall the OperationsManager database.
3. Delete the OperationsManager database.
4. Restore the OperationsManager database.
5. Update Management Servers with the new database server name.
6. Update the OperationsManager database with the new database server name.
7. Update the OperationsManager database logins on the new database server. Ensure that for the Root Management Server, the SDK Account and the Action Account are included in the Logins and that they have appropriate permissions. If Reporting is installed, ensure that the Data Warehouse Action Account has appropriate permissions.
8. Set ENABLE_BROKER if needed.
9. Verify that the move is successful by ensuring that the console is displaying valid data.
OperationsManager Database Relocation
Use the procedure below to move the OperationsManager database to a new server.
To move the OperationsManager database
1. Install and configure a new SQL Server-based computer. Ensure that you have system administrator permissions on both the original and the new SQL Server-based computers
2. Back up the following:
- Back up all databases. On the current server that hosts the OperationsManager database, use SQL Server Management Studio to back up the OperationsManager (default name) database.
- Back up the encryption key on the Root Management Server by using the SecureStorageBackup.exe utility.
3. Stop the Operations Manager services (OpsMgr Config Service, OpsMgr SDK Service, and OpsMgr Health Service for Root Management Servers and OpsMgr Health Service for management servers) on the management servers in the management group.
In a clustered Root Management Server environment, use Cluster Administrator to configure each of the three services listed above with the Take Offline option.
4. On the current server that hosts the OperationsManager database, uninstall the database component as follows, these steps do not physically remove the OperationsManager database from SQL Server:
Note
Perform this step if the database is the only component on the server. Otherwise, you will still be able to delete the database following the next step.
a. Click Start, click Control Panel, and then click Add or Remove Programs.
b. In the Add or Remove Programs dialog box, select System Center Operations Manager 2007, and then select Remove.
c. Complete the wizard.
5. On the current server that hosts the OperationsManager database, delete the OperationsManager database as follows:
a. In Microsoft SQL Server Management Studio, navigate to Databases.
b. Right-click OperationsManager, and then click Delete.
c. In the Delete Object dialog box, ensure that the Delete backup and restore history information for databases and the Close existing connections options are both selected.
d. Click OK to complete the operation.
6. On the new server, use Microsoft SQL Server Management Studio to restore the OperationsManager database that you have previously backed up. To access the database backup file, copy the backup file to a local drive, or map a local drive to the folder that contains the backup file.
7. Update the registry on each management server in the management group to reference the new SQL Server-based computer. Complete this step also on the Root Management Server, and if the Root Management Server is clustered, then you must complete this step on all the nodes in the cluster.
Note
Before editing the Registry, follow your site’s backup policies with regard to the registry.
a. Log onto the management server with administrator permissions.
b. Click Start, select Run, type regedit in the Open box, and then click OK to start Registry Editor.
c. Under HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft Operations Manager\3.0\Setup, double-click the value DatabaseServerName, and then change the value to the hostname of the SQL Server-based computer now hosting the OperationsManager database.
d. Click OK.
e. Close the Registry Editor.
f. After you have completed this step on all management servers in the management group, restart the OpsMgr Config Service, OpsMgr SDK Service and OpsMgr Health Service on the Root Management Server, and then restart only the OpsMgr Health Service on the remaining Management Servers.
Important
Do not start the OpsMgr Config Service and OpsMgr SDK Service on the management servers, as these services should only be running on the Root Management Server.
8. Update the OperationsManager Database with the New Database Server Name, ensure that the account that you are logged on with has sufficient privileges on the SQL Server instance.
a. Open SQL Server Management Studio.
b. Expand Databases, OperationsManager and Tables.
c. Right-click dbo.MT_ManagementGroup, and then click Open Table.
d. Change the value in the SQLServerName_6B1D1BE8_EBB4_B425_08DC_2385C5930B04 column to reflect the name of the new SQL Server-based computer.
e. Save your change.
9. On the new server hosting the OperationsManager database, add the correct permission for the Login of the Root Management Server on which the SDK Account is running, as follows:
a. Open Microsoft SQL Server Management Studio, and in the Object Explorer pane, navigate to Security and then expand Logins.
b. Locate the SDK Account – add the account if it is not listed.
Note
If the SDK Account is running as LocalSystem, use the format <domain\computername$> in SQL Logins, where <computername> is the name of the Root Management Server.
c. Right-click the SDK Account, and select Properties.
d. In the Login Properties dialog box, in the Select a page pane, select User Mapping.
e. In the Users mapped to this login list, in the Map column, check the box that corresponds to OperationsManager (default name).
f. In the Database role membership for: OperationsManager list, ensure that the following items are checked: configsvc_users, db_datareader, db_datawriter, db_ddladmin, and sdk_users.
g. Click OK to save your changes and to close the Login Properties dialog box.
10. On the new server hosting the OperationsManager database, add the correct permission for the Login of the Root Management Server on which the Action Account is running, as follows:
a. Open Microsoft SQL Server Management Studio, and in the Object Explorer pane, navigate to Security and then expand Logins.
b. Locate the Action Account – add the account if it is not listed. If the Action Account is running as LocalSystem, use the format <domain\computername$> in SQL Logins, where <computername> is the name of the Root Management Server
c. Right-click the Action Account, and select Properties.
d. In the Login Properties dialog box, in the Select a page pane, select User Mapping.
e. In the Users mapped to this login list, in the Map column, check the box that corresponds to OperationsManager (default name).
f. In the Database role membership for: OperationsManager list, ensure that the following items are checked: db_datareader, db_datawriter, db_ddladmin, and dbmodule_users.
g. Click OK to save your changes and to close the Login Properties dialog box.
11. On the new server hosting the OperationsManager database, add the correct permission for the Login of the Data Warehouse Server on which the Data Warehouse Action Account is running, as follows:
a. Open Microsoft SQL Server Management Studio, and in the Object Explorer pane, navigate to Security and then expand Logins.
b. Locate the Data Warehouse Action Account – add the account if it is not listed.
c. Right-click the Data Warehouse Action Account, and select Properties.
d. In the Login Properties dialog box, in the Select a page pane, select User Mapping.
e. In the Users mapped to this login list, in the Map column, check the box that corresponds to OperationsManager (default name).
f. In the Database role membership for: OperationsManager list, ensure that the following items are checked: db_datareader and dwsynch_users.
g. Click OK to save your changes and to close the Login Properties dialog box.
|
Set ENABLE_BROKER
Before you can run tasks and use the Discovery Wizard to install agents, you need to set the ENABLE_BROKER value.
After moving the OperationsManager database, the status of the Sql Broker Availability Monitor might be set to ‘critical’ or to ‘Sql Broker is disabled’. You can check the state of the Sql Broker Availability Monitor by running the following SQL query:
SELECT is_broker_enabled FROM sys.databases WHERE name=’OperationsManager’
Where ‘OperationsManager’ is the default database name, replace this name as appropriate.
If the query result is ‘0’, then the Sql Broker is disabled and you must re-enable it using the following procedure.
To set ENABLE_BROKER
|
1. Open SQL Server Management Studio.
2. In the Connect to Server dialog box, select the appropriate values in the Server type list, in the Server name list, in the Authentication list, and then click Connect.
3. Click New Query.
4. In the query window, enter the following query:
ALTER DATABASE OperationsManager SET SINGLE_USER WITH ROLLBACK IMMEDIATE
5. Click Execute.
6. Enter the following query:
ALTER DATABASE OperationsManager SET ENABLE_BROKER
7. Click Execute.
8. Close SQL Server Management Studio.
Note
Closing SQL Server Management Studio closes the connection to the database in single user mode. Depending on your configuration, you may have to manually kill any process that is connected to the database before completing the ALTER query below.
9. Open SQL Server Management Studio.
10. In the Connect to Server dialog box, select the appropriate values in the Server type list, in the Server name list, in the Authentication list, and then click Connect.
11. Click New Query.
12. In the query window, enter the following query:
ALTER DATABASE OperationsManager SET MULTI_USER
13. Click Execute.
|
You can verify the setting for ENABLE_BROKER is set to 1 by using this SQL query: SELECT is_broker_enabled FROM sys.databases WHERE name=’OperationsManager’.
Note
Before you can use discovery, you must restart the following services: OpsMgr SDK Service, OpsMgr Config Service, and OpsMgr Health Service. You may also need to restart the following services: SQL Server and SQL Server Agent.
How to Move the OperationsManagerDW Database in Operations Manager 2007
For various reasons, it might be necessary to move the OperationsManagerDW database from its original server to another.
Caution
This procedure can result in data loss if not performed correctly and within a reasonable length of time. Ensure that you follow all steps precisely, and without unnecessary delays between the steps.
The high level steps to move the OperationsManagerDW database are as follows:
1. Stop Operations Manager services to prevent updates to the OperationsManagerDW database during the move.
2. Back up the OperationsManagerDW to preserve the data that Operations Manager has already collected from the management group.
3. Uninstall the current Data Warehouse component and delete the OperationsManagerDW database.
4. Install the Reporting Data Warehouse component on the new Data Warehouse server.
5. Restore the original OperationsManagerDW database.
6. Configure Operations Manager to use the OperationsManagerDW database on the new Data Warehouse server.
7. Restart Operations Manager services.
OperationsManagerDW Database Relocation Procedure
Use the procedure below to move the OperationsManagerDW database to a new Data Warehouse server.
To move the OperationsManagerDW database
|
1. Stop Operations Manager services as follows:
a. On the Root Management Server, stop the OpsMgr SDK Service and the OpsMgr Config Service.
b. On the Root Management Server and on all other Management Servers, stop the OpsMgr Health Service.
2. On the current Data Warehouse server, use SQL Server Management Studio to back up the OperationsManagerDW database (default name) to a shared folder on the server. It is recommended that you also back up the associated master database.
3. On the current Data Warehouse server, uninstall the Reporting Data Warehouse component as follows:
a. Click Start, click Control Panel, and then select Add or Remove Programs.
b. In the Add or Remove Programs dialog box, select System Center Operations Manager 2007Reporting Server, and then select Change.
c. In the System Center Operations Manager 2007 Reporting Setup Wizard, on the Operations Manager 2007 Maintenance page, select Modify, and then click Next.
d. On the Custom Setup page, configure the Data Warehouse component with the This component will not be available option.
e. Complete the wizard.
Note
This does not physically remove the OperationsManagerDW database from SQL Server.
4. On the current Data Warehouse server, delete the OperationsManagerDW database as follows:
a. In Microsoft SQL Server Management Studio, navigate to Databases.
b. Right-click OperationsManagerDW, and then select Delete.
c. In the Delete Object dialog box, ensure that the Delete backup and restore history information for databases and the Close existing connections options are both checked.
5. On the new Data Warehouse server, run SetupOM.exe to install the Reporting Data Warehouse component as follows:
a. On the System Center Operations Manager 2007 Setup page, select Install Operations Manager 2007 Reporting.
b. In the System Center Operations Manager 2007 Reporting Setup wizard, on the Custom Setup page, configure only the Data Warehouse component for installation.
If you are moving the OperationsManagerDW database to a server that is different than the server on which the Operations Manager Reporting component is installed, then Configure the Reporting Server component with the This component will not be available option.
6. On the new Data Warehouse server, delete the OperationsManagerDW database as follows:
a. In Microsoft SQL Server Management Studio, navigate to Databases.
b. Right-click OperationsManagerDW, and then select Delete.
c. In the Delete Object dialog, ensure that the Delete backup and restore history information for databases and the Close existing connections options are both checked.
7. On the new Data Warehouse server, use SQL Management Studio to restore the OperationsManagerDW database backup (from step 2). Access the database backup by copying the backup to a local drive, or by mapping a local drive to the folder that contains the backup.
8. On the new Data Warehouse server, use SQL Management Studio to create a login for the OpsMgr SDK Service account, the Data Warehouse Action Account, and the Data Reader Account.
Note
If localsystem was used as the OpsMgr SDK Service account, enter <domain\computername$> in SQL Logins.
9. On the new Data Warehouse server, add the correct login permission for the computer on which the SDK Service is running, as follows:
a. In Microsoft SQL Server Management Studio, in the Object Explorer pane, navigate to Security and then expand Logins.
b. Right-click the account that corresponds to the computer on which the SDK Service is running (for example, if localsystem is used, it will be <domain\computername$>). Select Properties.
c. In the Login Properties dialog box, in the Select a page pane, select User Mapping.
d. In the Users mapped to this login list, In the Map column, check the box that corresponds to the OperationsManagerDW database.
e. In the Database role membership for: OperationsManagerDW list, check OpsMgrReader and db_datareader.
f. Click OK to save your changes and to close the Login Properties dialog box.
10. On the new Data Warehouse server, add the correct login permission for the computer on which the Data Reader Account is running, as follows:
a. In Microsoft SQL Server Management Studio, in the Object Explorer pane, navigate to Security and then expand Logins.
b. Right-click the Data Reader Account and select Properties.
c. In the Login Properties dialog box, in the Select a page pane, select User Mapping.
d. In the Users mapped to this login list, In the Map column, check the box that corresponds to OperationsManagerDW.
e. In the Database role membership for: OperationsManagerDW list, check OpsMgrReader and db_datareader.
f. Click OK to save your changes and to close the Login Properties dialog box.
11. On the new Data Warehouse server, add the correct permission for the Login of the computer on which the Data Warehouse Action Account is running, as follows:
a. In Microsoft SQL Server Management Studio, in the Object Explorer pane, navigate to Security and then expand Logins.
b. Right-click the Data Warehouse Action Account, and select Properties.
c. In the Login Properties dialog box, in the Select a page pane, select User Mapping.
d. In the Users mapped to this login list, In the Map column, check the box that corresponds to OperationsManagerDW.
e. In the Database role membership for: OperationsManagerDW list, check the following items: OpsMgrWriter and db_owner.
f. Click OK to save your changes and to close the Login Properties dialog box.
12. On the Root Management Server, start the OpsMgr SDK Service.
13. On the server running SQL Server Reporting Services, modify the data source as follows:
a. In Internet Explorer, open http://localhost/reports<$instancename> (include <$instancename> only when using a named instance).
b. On the SQL Server Reporting Services Home page, ensure that you are viewing the Contents page. Select Show Details.
c. In the list that is displayed, click Data Warehouse Main.
d. In the Data Warehouse Main properties page, in the Connection string text box, change the name of the database server to the new Data Warehouse server.
e. Click Apply.
14. On the server running SQL Server Reporting Services, update the registry to point to the name of the new Data Warehouse server as follows:
a. Locate the key HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft Operations Manager\3.0\Reporting.
b. Double-click the value DWDBInstance, and then modify it to be the name of the new Data Warehouse server.
If the OperationsManagerDW database was installed on the same server as the Operations Manager Reporting Server, then this key does not exist and you need to add it (as a string value).
15. Configure the OperationsManager database with the name of the new Data Warehouse server as follows:
a. On the server that hosts the OperationsManager database, open SQL Server Management Studio and navigate to Databases, OperationsManager, and then to Tables.
b. Right-click dbo.MT_DataWarehouse, and then select Open Table.
c. Change the value in the MainDatabaseServerName_16781F33_F72D_033C_1DF4_65A2AFF32CA3 column to the name of the new Data Warehouse server.
d. Close SQL Server Management Studio to save your changes.
16. Configure the OperationsManagerDW database with the name of the new Data Warehouse server as follows:
a. On the new Data Warehouse server, open SQL Server Management Studio and navigate to Databases, OperationsManagerDW, and then to Tables.
b. Right-click dbo.MemberDatabase table and select Open Table.
c. Change the value in the ServerName column to the name of the new Data Warehouse server.
d. Close SQL Server Management Studio to save your changes.
17. Restart services as follows:
a. On the Root Management Server, restart the OpsMgr Config Service.
b. On all Management Servers, restart the OpsMgr Health Service.
18. Verify that the database move was successful as described in the following procedures.
|
To verify a successful move of the OperationsManagerDW database
|
1. Verify that you can successfully run a report from the console.
2. Ensure that the health state of all management servers in the management group are Healthy.
If the health state of any management server is Critical, open HealthExplorer, expand Availability – <server name>, and then continue to expand until you can navigate to Data Warehouse SQL RS Deployed Management Pack List Request State. Check the associated events to determine if there is an issue accessing the OperationsManagerDW database.
3. Check operating system events:
a. Open the operating system’s Event Viewer. Navigate to Event Viewer, and then to Operations Manager.
b. In the Operations Manager pane, search for events with a Source of Health Service Module and a Category of Data Warehouse.
The move was successful if event number 31570, 31558 or 31554 exists.
There is an issue accessing the OperationsManagerDW database if event number 31563, 31551, 31569, or 31552 exists.
4. Check events in Operations Manager:
a. In the Operations Manager console, select Monitoring.
b. Navigate to Monitoring, Operations Manager, Health Service Module Events, and then to Performance Data Source Module Events.
c. Search the Performance Data Source Module Events pane for events with a Date and Time that is later than the move.
There is a problem with the OperationsManagerDW database if events with a Source of Health Service Module and an Event Number of 10103.
|
How to Move the OperationsManagerAC Database in Operations Manager 2007
For various reasons it might be necessary to move the Audit Collection (OperationsManagerAC) database from its original server to another.
Caution
This procedure can result in data loss if not performed correctly and within a reasonable length of time. Ensure that you follow all steps precisely, and without unnecessary delays between steps.
The high-level steps for moving the OperationsManagerAC database are as follows:
1. Stop Operations Manager Audit Collection Service to prevent updates to the OperationsManagerAC database during the move.
2. Back up the OperationsManagerAC database.
3. Delete the OperationsManagerAC database on the original Audit Collection database server.
4. Restore the OperationsManagerAC database to the new Audit Collection database server.
5. Configure SQL Server permissions on the new Audit Collection database server.
6. Configure the Audit Collection Server to point to the new Audit Collection database server.
7. Restart Operations Manager Audit Collection Service.
OperationsManagerAC Datebase Relocation Procedure
Use the following procedure to move the OperationsManagerAC database to a new Audit Collection database server.
To move the OperationsManagerAC database
|
1. On the original Audit Collection database server, stop the Operations Manager Audit Collection Service.
2. On the original Audit Collection database server, use SQL Server Management Studio to back up the OperationsManagerAC database (default name) to a shared folder on the server. It is recommended that you also back up the associated master database.
3. On the original Audit Collection database server, delete the OperationsManagerAC database as follows:
a. In Microsoft SQL Server Management Studio, navigate to Databases.
b. Right-click OperationsManagerAC, and then select Delete.
c. In the Delete Object dialog box, ensure that the Delete backup and restore history information for databases and the Close existing connections options are both checked.
4. On the new Audit Collection database server, use SQL Management Studio to restore the OperationsManagerAC database backup. Access the database backup by copying the backup file to a local drive, or by mapping a local drive to the folder that contains the backup.
5. On the new Audit Collection database server, use SQL Management Studio to create a login for the Audit Collection Service server. Use the format <domain\computername$> in SQL Logins (where computername is the name of the Audit Collection Service server).
6. On the new Audit Collection database server, add the correct permission for the login of the computer on which the ACS Service is running, as follows:
a. In Microsoft SQL Server Management Studio, navigate to Security and then to Logins.
b. Right-click the account that corresponds to the computer on which the ACS Service is running (use the <domain\computername$> format). Select Properties, and then select User Mapping.
c. Check the box in the Map column that corresponds to the OperationsManagerAC database, and then select db_owner in the Database role membership for: OperationsManagerAC list.
d. Click OK.
7. On the computer hosting the Audit Collection Service, locate the registry key HKEY_LOCAL_MACHINE\Software\ODBC\ODBC.INI\OpsMgrAC. Double-click the value Server, and set it to the name of the new Audit Collection database server.
8. On the server on which the ACS service is running, start the Audit Collection Service.
9. Verify that the database move was successful by checking the OperationsManagerAC database for entries in the most recent dtEvent_<GUID> table that have a datetime stamp that is more recent than when the service was restarted in the previous step.
|
How to Promote a Management Server to a Root Management Server Role in Operations Manager 2007
Use the following procedures to promote a management server to a Root Management Server role, and then, if needed, to reset the value of ENABLE_BROKER in the OperationsManager database to 1.
Some of the high level guidelines for promoting management servers are:
- In a failure recovery scenario, you can change the Root Management Server by promoting another management server to the role of Root Management Server. In this scenario, the management server that you plan to promote to Root Management Server must have already been installed before the failure of the current Root Management Server occurred.
- If you promote the Root Management Server role away from a clustered Root Management Server, you must ensure that the services (OpsMgr Health Service, the OpsMgr Config Service, and the OpsMgr SDK Service) for that clustered Root Management Server are stopped. These services might be already stopped; for example, as a result of the clustered Root Management Server no longer being in operation. However, if these services are still running, you must manually stop them from within Cluster Administrator.
- After promoting the Root Management Server role away from a clustered Root Management Server, you cannot configure the individual nodes as management servers. This scenario is not supported and therefore you should not use the UpdateDemotedRMS action on these nodes.
- In Operations Manager 2007 SP1, it is possible to promote the Root Management Server back to the original clustered Root Management Server configuration. To do this, you must first ensure that the services described above are stopped, and then perform the PromoteRMS action on the active node of the cluster.
- In a scenario where a management server was promoted to Root Management Server and the original Root Management Server was not demoted at that time, (for various reasons such as connectivity issues, or hardware problems with the computer), then if at a later time, the original server recovers and you want to use it again as the Root Management Server, you must first demote it to a management server role because you have already promoted another management server to a Root Management Server role.
After you demote the original Root Management Server to a management server role by running the UpdateDemotedRMS action of the ManagementServerConfigTool locally on that original Root Management Server, you can re-promote it to the Root Management Server role.
Note
Running the PromoteRMS action, automatically demotes the previous Root Management Server to a management server role unless the original Root Management Server is not accessible or if /DemoteExistingRMS: is set to ‘True’ (which will delete, rather than demote the previous Root Management Server from the database).
The high-level steps for promoting a management server to Root Management Server are:
1. Promote a management server to a Root Management Server role.
2. Configure the reporting server with the name of the new Root Management Server.
3. Configure the Web console with the name of the new Root Management Server.
4. Set ENABLE_BROKER to 1 if needed. After you successfully complete the promotion, you might need to set the value of the SQL Broker Availability Monitor to 1. Check the state of the SQL Broker Availability Monitor by running the following SQL query:
SELECT is_broker_enabled FROM sys.databases WHERE name=’OperationsManager’
If the query result is ‘0’, then the SQL Broker is disabled, you must re-enable it by using the ‘To set ENABLE_BROKER to 1′ procedure later in this topic.
Procedures
To promote a management server to a Root Management Server role
|
1. On the management server that you want to promote, copy the SecureStorageBackup.exe and the ManagementServerConfigTool.exe tools from the SupportTools folder of the installation media to the installation folder (by default, C:\Program Files\System Center Operations Manager 2007), called installdir in this example.
2. Open a command prompt window, and then change the folder to the installdir folder.
3. Type the command:
SecureStorageBackup.exe Restore <filename>
Where filename is the Root Management Server encryption key backup file.
4. Provide password as required.
5. On the management server, open a command prompt window, and then type the command:
ManagementServerConfigTool.exe PromoteRMS
6. Demote the original Root Management Server to a management server by doing the following on the original Root Management Server:
Note
This step is required only if the original Root Management Server is to be used as a management server.
a. Type the command: ManagementServerConfigTool.exe UpdateDemotedRMS
b. Delete the existing sub-folders of the Health Service State folder in the installdir.
|
To configure the reporting server with the name of the new Root Management Server
|
1. Log on to the reporting server.
2. Navigate to the installation folder of Reporting Services, for example %ProgramFiles%\Microsoft SQL Server\MSSQL.2\Reporting Services\ReportServer.
3. Open the rsreportserver.config file in Notepad, and locate the two instances of <ServerName>ServerName</ServerName>, where ServerName is the name of the original Root Management Server. Change ServerName to be the name of the new Root Management Server.
4. Save the file, and then close Notepad.
5. Open the registry and locate the key HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft Operations Manager\3.0\Reporting.
6. Change the DefaultSDKServiceMachine value to be the name of the new Root Management Server.
|
To configure the Data Warehouse server with permissions for the new Root Management Server
|
1. On the server hosting the data warehouse, open Microsoft SQL Server Management Studio, and in the Object Explorer pane, navigate to Security and then expand Logins.
2. Locate the account that corresponds to the new Root Management Server and on which the SDK Service is running (if running under LocalSystem, the format is <domain\computername$>).
3. Right-click the account, and select Properties.
4. In the Login Properties dialog box, in the Select a page pane, and then select User Mapping.
5. In the Users mapped to this login list, in the Map column, check the box that corresponds to the OperationsManagerDW database.
6. In the Database role membership for: OperationsManagerDW list, ensure that the following items are checked: configsvc_users, db_datareader, db_datawriter, db_ddladmin, and sdk_users.
7. Click OK to save your changes and to close the Login Properties dialog box.
|
To configure the Web Console with the name of the new Root Management Server
|
1. Log onto the Web console server.
2. Navigate to the installation folder of the Web console, by default %ProgramFiles%\System Center Operations Manager 2007\Web Console.
3. Open the Web.config file in Notepad.
4. Locate the line ‘<add key=”MOMServer” value=”RootManagementServer “/>’, where RootManagementServer is the name of the original Root Management Server. Change RootManagementServer to be the name of the new Root Management Server.
5. Save your changes, and then close Notepad.
|
To set ENABLE_BROKER to 1
|
1. Open SQL Server Management Studio.
2. In the Connect to Server dialog box, select the appropriate values in the Server type list, in the Server name list, in the Authentication list, and then click Connect.
3. Click New Query.
4. In the query window, enter the following query:
ALTER DATABASE OperationsManager SET SINGLE_USER WITH ROLLBACK IMMEDIATE
5. Click Execute.
6. Enter the following query:
ALTER DATABASE OperationsManager SET ENABLE_BROKER
7. Click Execute.
8. In the Connect to Server dialog box, select the appropriate values in the Server type list, in the Server name list, in the Authentication list, and then click Connect.
9. Click New Query.
10. In the query window, enter the following query:
ALTER DATABASE OperationsManager SET MULTI_USER
11. Click Execute.
12. Verify that ENABLE_BROKER is set to 1 by using the following SQL query:
Select is_broker_enabled FROM sys.databases WHERE name=’OperationsManager’
|
How to Remove a Management Server From a Computer in Operations Manager 2007
Use the following procedure to remove the management server role from a computer. For example, you might need to do this if you need to free up a computer hosting the management server role and install a gateway server.
Before you remove the management server role from a computer, you must configure any objects that are managed by that Management Server, to be managed by a different management server as described below.
The high level steps to remove a management server role are as follows:
1. Delete the Management Server from the management group.
2. If the management server you are about to remove functions as a primary management server for an agent, then you must configure those agents to use a new primary Management Server. See Change the Primary Management Server below.
3. If the management server you are about to remove acts as a proxy agent for an agentless managed computer, you need to identify a new Management Server. See Configure an Agentless Managed Computer to Use a Different Proxy Agent below.
4. If the management server you are about to remove acts as a proxy agent for a network device, you need to identify a new Management Server. See Configure a Network Device to Use a Different Operations Manager 2007 Proxy Agent below.
5. Remove the management server role from a computer. See Remove the Management Server from a Computer below.
Procedures
To delete a management server from the management group
|
1. Log on to the computer with an account that is a member of the Operations Manager Administrators role for the Operations Manager 2007 management group.
2. In the Operations console, click the Administration button.
Note
When you run the Operations console on a computer that is not a Management Server, the Connect To Server dialog box will display. Type the name of the Operations Manager 2007 management server you want the Operations console to connect to in the Server name text box.
3. In the Administration pane, click Management Servers.
4. Right-click the desired management server and click delete.
5. In the Confirm Delete Management Server dialog, click Yes.
|
Change the Primary Management Server
Use one of the following procedures to change the Primary Management Server for agent-managed computers that are assigned to Primary and Secondary Management Servers without using Active Directory Domain Services.
To change the Primary Management Server for agent-managed computers using the Operations console
|
1. Log on to the computer with an account that is a member of the Operations Manager Administrators role for the Operations Manager 2007 management group.
2. In the Operations console, click the Administration button.
Note
When you run the Operations console on a computer that is not a management server the Connect To Server dialog box will display. In the Server name text box, type the name of the Operations Manager 2007 management server that you want the Operations console to connect to.
3. In the Administration pane, expand Administration, expand DeviceManagement, and then click AgentManaged.
4. In the Agent Managed pane, select the computers for which you want to change the Primary Management Server, right-click them, and then select ChangePrimaryManagementServer.
Note
The Change Primary Management Server option will be unavailable if Active Directory Domain Services was used to assign any of the selected computers to the management group.
5. In the Change Management Server dialog box, select the desired management server from the list, and then click OK. The change takes effect on the agent after its next update interval.
|
To change the Primary Management Server for agent-managed computers using the MOMAgent.msi setup wizard
|
1. Log on to a managed computer with an account that is a member of the administrators security group for the computer.
2. In AddorRemovePrograms, click ChangeforSystemCenterOperationsManager2007Agent.
Note
The AgentSetupWizard can also be run by double-clicking MOMAgent.msi, which is available on the Operations Manager 2007 installation media.
3. In the AgentSetupWizard, click Next.
4. On the ProgramMaintenance page, select Modify and click Next.
5. On the ManagementGroupConfiguration page, leave SpecifyManagementGroupinformation selected, and then click Next.
6. In the next ManagementGroupConfiguration page, do the following:
a. Type the name of the ManagementServer.
b. Type the ManagementServerPort, or leave the default 5723.
c. Click Next.
7. On the ReadytoInstall page, review the settings, and then click Install to display the InstallingSystemsCenterOperationsManagerAgent page.
8. When the Completing the Systems Center Operations Manager Agent Setup Wizard page displays, click Finish.
|
To change the Primary Management Server for agent-managed computers using MOMAgent.msi from the command line
|
1. Log on to the managed computer with an account that is a member of the administrators security group for the computer.
2. Open the command window.
3. At the prompt, type the following command-line example:
Important
Microsoft Windows Installer public properties must be uppercase, such as PROPERTY=value. For more information about Windows Installer, see http://go.microsoft.com/fwlink/?LinkId=70004.
%WinDir%\System32\msiexec.exe /i \\path\Directory\MOMAgent.msi /qn USE_SETTINGS_FROM_AD=0 MANAGEMENT_GROUP=MG1 MANAGEMENT_SERVER_DNS=MS2.Domain1.net
4. The preceding command-line example will reconfigure the agent to use MS2.Domain1.net as its Primary Management Server for management group MG1.
Important
If the Domain Name System (DNS) and Active Directory names for the management server differ, the MANAGEMENT_SERVER_AD_NAME property would also need to be set to the fully qualified Active Directory Domain Services name.
|
Configure an Agentless Managed Computer to Use a Different Proxy Agent
Use the following procedure to change the Operations Manager 2007 proxy agent for an agentless managed computer. The proxy agent can be any agent-managed computer in the management group configured to be a proxy.
To change the proxy agent for agentless managed computers
|
1. Log on to the computer with an account that is a member of the Operations Manager Administrators role for the Operations Manager 2007 management group.
2. In the Operations console, click the Administration button.
Note
When you run the Operations console on a computer that is not a management server the Connect To Server dialog box displays. In the Server name text box, type the name of the Operations Manager 2007 management server that you want the Operations console to connect to.
3. In the Administration pane, expand Administration, expand DeviceManagement, and then click AgentlessManaged.
4. In the Agentless Managed pane, select the agentless managed computers for which you want to change the proxy agent, right-click them, and then select ChangeProxyAgent.
5. In the ChangeProxyAgent dialog box, select the computer you want to be the new proxy agent, and then click OK.
|
Configure a Network Device to Use a Different Operations Manager 2007 Proxy Agent
Use the following procedure to change the Operations Manager 2007 proxy agent for network devices. The proxy agent can be any agent-managed computer in the management group. It must have SNMP installed, an optional Windows component, and be able to connect to the devices using SNMP.
To change the proxy agent for network devices
|
1. Log on to the computer with an account that is a member of the Operations Manager Administrators role for the Operations Manager 2007 management group.
2. In the Operations console, click the Administration button.
Note
When you run the Operations console on a computer that is not a management server the Connect To Server dialog box displays. In the Server name text box, type the name of the Operations Manager 2007 management server that you want the Operations console to connect to.
3. In the Administration pane, expand Administration, expand DeviceManagement, and then click NetworkDevices.
4. In the Network Devices pane, select the network devices for which you want to change the proxy agent, right-click them, and then select ChangeProxyAgent.
5. In the ChangeProxyAgent dialog box, select the computer you want to be the new proxy agent, and then click OK.
|
Remove the Management Server from a Computer
Use the following procedure to remove a management server role from a computer.
To remove a management server role from a computer
|
1. Run Add or Remove Programs on the computer you want to remove the management server component from.
2. Select System Center Operations Manager 2007, click Change or Remove, and then follow the instructions in the wizard.
|
How to Move the Operations Manager Reporting Server in Operations Manager 2007
You can move the Operations Manager Reporting Server component to a new server, or reinstall the component on the original server.
Important
Moving a Reporting Server is supported only on the Service Pack 1 version of System Center Operations Manager 2007.
The high-level steps of moving the Operations Manager Reporting Server are as follows:
1. Back up the OperationsManagerDW database.
2. Note the accounts that are being used for the Data Warehouse Action Account and for the Data Warehouse Report Deployment Account. You will need to use the same accounts later, when you reinstall the Operations Manager Reporting Server.
3. Uninstall the current Operations Manager Reporting Server component.
4. Restore the original OperationsManagerDW database.
5. If you are reinstalling the Operations Manager Reporting Server component on the original server, run the ResetSRS.exe tool to clean up and prepare the Reporting Server for the reinstallation.
6. Reinstall the Operations Manager Reporting Server component.
During this move, Operations Manager stops storing data in the OperationsManagerDW database until you complete the Operations Manager Reporting Server reinstall.
Use the procedures in this topic to move the Reporting Server to a new server and verify the success of the move.
Note
Ensure that you follow all steps precisely, as not doing so may result in data corruption.
Procedures
To move the Operations Manager Reporting server
|
1. On the current Data Warehouse server, use SQL Server Management Studio to back up the OperationsManagerDW database (default name).
2. On the current Operations Manager Reporting Server computer, uninstall the Operations Manager Reporting Server component as follows:
a. Click Start, click Control Panel, and then click Add or Remove Programs.
b. In the Add or Remove Programs dialog box, select System Center Operations Manager 2007 Reporting Server, and then select Change.
c. In the System Center Operations Manager 2007 Reporting Setup Wizard, on the Operations Manager 2007 Maintenance page, select Modify, and then click Next.
d. On the Custom Setup page, configure the Reporting Server component with the This component will not be available option.
e. Complete the wizard.
3. On the Data Warehouse server, use SQL Management Studio to restore the OperationsManagerDW database backup that you created in step 1.
4. If you are reinstalling the Operations Manager Reporting Server component on the original server, you must remove any data that is left from the original installation by doing the following:
a. Copy the ResetSRS.exe tool from the SupportTools folder on the product CD to a local folder.
b. Run the tool from a command prompt as follows:
ResetSRS.exe <SQL Server instance name>
Where SQL Server instance name is the SQL Server instance that SRS is installed on, such as ‘Instance1′. If SQL Server is using the default instance, enter MSSQLSERVER.
c. Open the Reporting Configuration Manager by clicking Start, pointing to Programs, pointing to Microsoft SQL Server 2005,pointing to Configuration Tools, and then clicking Reporting Services Configuration.
d. In the Configure Report Server page, check the status of the Web Service Identity item. If the status is not Configured (green), click that item, and then click Apply.
Check the status of the rest of the items on that page. Configure any items that are designated with a red ‘X’, indicating a non-healthy configuration status.
5. On the new Operations Manager Reporting Server computer, run SetupOM.exe to reinstall the Operations Manager Reporting Server component by pointing the Reporting Server to the existing OperationsManagerDW database, and using the original accounts for the Data Warehouse Action Account and the Data Warehouse Report Deployment Account, as follows:
a. On the System Center Operations Manager 2007 Setup page, select Install Operations Manager 2007 Reporting.
b. In the System Center Operations Manager 2007 Reporting Setup Wizard, on the Custom Setup page, configure only the Reporting Server component for installation. Configure the Data Warehouse component with the This component will not be available option.
6. Verify that the database move was successful as described in the next procedure.
|
To verify a successful move of the Reporting Server
|
1. Verify that you can successfully run a report from the Operations Manager Operations console.
2. Ensure that the health state of all management servers in the management group is Healthy.
If the health state of any management server is Critical, open HealthExplorer, expand Availability – <server name>, and then continue to expand until you can navigate to Data Warehouse SQL RS Deployed Management Pack List Request State. Check the associated events to determine if there is an issue accessing the OperationsManagerDW database.
|
