Exam Ref 70-246 Monitoring and Operating a Private Cloud
Chapter 2. Deploy resource monitoring
Operations Manager functions as the senses for your organization’s private cloud environment. Deploying the Operations Manager agent allows you to extract performance data and configuration information from the monitored computer, virtual machine, or device. In this chapter, you’ll learn about: deploying agents to computers, how to monitor network devices, how to leverage management packs, how to monitor a variety of different services and applications, and how to view that monitoring data through dashboards and reports.
Objectives in this chapter:
Objective 2.1: Deploy end-to-end monitoring
Objective 2.2: Configure end-to-end monitoring
Objective 2.3: Create monitoring reports and dashboards
Objective 2.1: Deploy end-to-end monitoring
End-to-end monitoring involves being able to monitor all aspects of a private cloud deployment, from the application running on a monitored server through to the functionality of network devices. To deploy end-to-end monitoring, you need to deploy the Operations Manager agent to the computers or virtual machines that you want to monitor. You can also configure Operations Manager to manage network devices. You enhance the functionality of Operations Manager by importing management packs.
This section covers the following topics:
Deploying Operations Manager agents
Discovering network devices
Monitoring network devices
Using management packs
Deploying Operations Manager agents
The Operations Manager agent is a service that you deploy to computers and devices, usually termed “managed objects.” You want to manage and monitor this service using Operations Manager. The Operations Manager agent collects information from the managed object.
The information that it collects depends on the rules and monitors that are included in the collection of management packs installed on the Operations Manager server. For example, the System Center Management Pack for SQL Server management pack will compare telemetry from the monitored instance of SQL Server against rules and thresholds defined in the management pack. In the event that one of these rules or thresholds is breached, the Operations Manager agent will transmit data to the Operations Manager management server, triggering an Operations Manager alert.
There are four general methods that you can use to deploy the Operations Manager agent to computers running Windows based operating systems:
Discovery Wizard Part of the Operations Manager console. You can use this wizard to deploy agents to computers running Windows, UNIX, or Linux operating systems as shown in Figure 2-1. You can also use it to deploy agents to supported network devices.
FIGURE 2-1 Discover Windows computers
Manual Installation While it’s certainly possible to install the Operations Manager agent by signing on to a computer and running through the installation wizard, doing this consumes substantially more time than other methods. When you are considering deploying the Operations Manager agent across hundreds, if not thousands of devices, you’ll need a method that requires less time than manual deployment.
Scripted Installation Scripting the installation of the agent is more efficient than manually installing the agent, as it doesn’t require direct administrator intervention beyond launching the script.
Inclusion in OS Deployment Image Rather than install the agent after a computer or virtual machine has been deployed, you can instead include the Operations Manager agent in the deployment image. This is especially effective in environments where computers are members of an AD DS domain and are able to query AD DS for Operations Manager settings.
Windows agent deployment using the Discovery Wizard
The Discovery Wizard is part of the Operations Manager console and allows you to deploy agents to computers or devices. If you want to deploy the Operations Manager agent using the Operations Manager console, you’ll need to use an account that is a member of the Operations Manager Administrator role.
To deploy the Operations Manager agent to Windows computers that are members of the same domain as the Operations Manager console, perform the following steps:
1. Right-click the Device Management node, located in the Administration workspace of the Operations Manager console. Then, click Discovery Wizard.
2. On the Discovery Type page of the Computer And Device Management Wizard, click Windows Computers.
More Info: Agent Deployment
You can learn more about deploying the Operations Manager agent at http://technet.microsoft.com/en-us/library/hh551142.aspx.
3. On the Auto Or Advanced page, click Automatic Computer Discovery as shown in Figure 2-2. Advanced Discovery gives you the option of specifying whether server or client operating systems will be discovered. You can also use this method to scan Active Directory for computers with particular names, owner, or with a particular description.
FIGURE 2-2 Automatic computer discovery
4. On the Administrator Account page, shown in Figure 2-3, select whether to use the Management Server Action Account, or a specific Active Directory user account that has the necessary privileges to install the agent on a managed computer. In most cases, this account will need to either be directly or indirectly a member of the local Administrators group on the target computer. When you click Discover, Operations Manager will query Active Directory for computer accounts. Depending on the number of objects within Active Directory, this might take some time.
FIGURE 2-3 Specify account credentials
5. On the Discovery Results page, shown in Figure 2-4, select all of the hosts on which you want to deploy the Operations Manager agent. You can use this dialog box to choose between Agent and Agentless management. Agentless management allows you to collect performance and availability data from a computer, but not all management packs support agentless mode.
FIGURE 2-4 Discovery results
6. On the Summary page, shown in Figure 2-5, specify the credentials that the agent should use when performing actions on the managed computer, and the folder on the target computer into which the agent should be installed. The default is to use Local System. Clicking Finish will deploy the Operations Manager agent to the selected computers.
FIGURE 2-5 Agent installation directory
7. You will be able to view the progress of the installation on the Agent Management Task Status dialog box, shown in Figure 2-6.
FIGURE 2-6 Agent task status
You can view a list of computers that have the Operations Manager agent already deployed and configured by selecting the Agent Managed node, under the Device Management node, in the Administration workspace of the Operations Manager console, as shown in Figure 2-7.
FIGURE 2-7 Agent managed computers
UNIX/Linux agent deployment using the Discovery Wizard
You can deploy the Operations Manager agent on computers running supported versions of UNIX or Linux by performing a local manual installation, or a remote installation using the Discovery Wizard. The Operations Manager agent is supported on the following versions of UNIX and Linux:
CentOS 5 and 6 (x86/x64)
Debian GNU/Linux 5,6, and 7 (x86/x64)
HP-UX 11i v2 and V3 (PA-RISC and IA64)
IBM AIX 5.3, AIX 6.1 (POWER), and AIX 7.1 (POWER)
Novell SUSE Linux Enterprise Server 9 (x86), 10 SP1 (x86/x64), and 11 (x86/x64)
Oracle Solaris 9 (SPARC), Solaris 10 (SPARC and x86), and Solaris 11 (SPARC and x86)
Oracle Linux 5 and 6 (x86/x64)
Red Hat Enterprise Linux 4, 5, and 6 (x86/x64)
Ubuntu Linux Server 10.04 and 12.04 (x86/x64)
The first method is to transfer the appropriate installation packages from the Operations Manager server to the UNIX or Linux computer, and install them using an account that has sufficient privileges on that computer.
More Info: Manual UNIX/Linux Agent Deployment
You can learn more about manually deploying the Operations Manager agent on computers running UNIX or Linux at http://technet.microsoft.com/en-us/library/hh212686.aspx.
The other option is to use the Discovery Wizard. Prior to deploying an agent to a computer running a supported version of UNIX or Linux using the Discovery Wizard, you need to configure a UNIX/Linux Action Account profile set up with a Monitoring Run As Account. To run the wizard to create this account, you’ll need to have configured the following:
Username and password for unprivileged access to the computer running UNIX or Linux. This account needs to be configured on the computer running UNIX or Linux so that it can elevate privileges using either su or sudo. If using ‘su’ to elevate privileges, you’ll need to provide the ‘su’ password. Sudo will also need to be specially configured with appropriate TTY and password settings to support the Discovery Wizard. You can configure these using the visudo command. While it is also possible to configure an account that already has privileged access and doesn’t require su or sudo to elevate privilege, this presents a security risk and should be avoided.
The computer will need to be configured so that an SSH connection can be made using this account and that appropriate ports are open on the computer’s firewall. You should verify that an SSH connection can be established from the management server to the computer running UNIX or Linux prior to attempting installation using the Discovery Wizard.
More Info: Troubleshooting UNIX/Linux Agent Deployment
You can learn more about troubleshooting the deployment of the Operations Manager agent for Linux and UNIX at http://social.technet.microsoft.com/wiki/contents/articles/4966.troubleshooting-unixlinux-agent-discovery-in-system-center-2012-operations-manager.aspx.
To create the account profile used by Operations Manager for installation of the agent on computers running UNIX or Linux, perform the following steps:
1. In the Administration workspace of the Operations Manager console, select UNIX/Linux accounts under Run As Configuration, and click Create Run As Account in the Tasks pane.
2. On the Account Type page of the Create UNIX/Linux Run As Account Wizard, click Agent Maintenance Account, as shown in Figure 2-8, and click Next. If you were creating an account to monitor a UNIX or Linux computer on which an agent was already installed, you would select the Monitoring Account option.
FIGURE 2-8 Agent maintenance account
3. On the General Properties page, provide a name and a description for the account.
4. On the Account Credentials page, shown in Figure 2-9, specify the username and password used to connect to the computer running UNIX or Linux. This connection will be made over SSH. You can choose a privileged account, which is assumed already have root privileges, or an unprivileged account. In that case su or sudo will be used to elevate privileges once a session is established.
FIGURE 2-9 Run As Account credentials
5. On the Elevation page, shown in Figure 2-10, select the method used to elevate privileges once the credentials specified in the previous step have been used to establish a connection.
FIGURE 2-10 Elevation options
6. On the Distribution Security page, select how credentials will be transmitted to managed computers, and then create the Run As Account.
Once the Run As Account is created, you’ll need to create a Run As Profile. To create a Run As Profile, perform the following steps:
1. In the Administration workspace of the Operations Manager console, select Profiles under Run As Configuration, and click Create Run As Profile in the Tasks pane.
2. On the General Properties page of the Run As Profile Wizard, provide a name for the Run As profile, and select a management pack in which to store the management pack.
3. On the Run As Accounts page, add the Run As Accounts that will be used with this profile. This will include the Agent Maintenance account described earlier and any Monitoring accounts that you have also configured to interact with computers running UNIX or Linux operating systems. This page is shown in Figure 2-11.
FIGURE 2-11 Run As Accounts
4. Complete the wizard to create the Run As Profile.
Once the Run As Profile is configured for supported Linux-based and UNIX-based computers, you’ll be able to deploy the Operations Manager agent to these computers using the Discovery Wizard by performing the following steps:
1. Right-click the Device Management node in the Administration Workspace of the Operations Manager console, and then click Discovery Wizard.
2. On the Discovery Type page of the Computer And Device Management Wizard, click UNIX/Linux computers.
3. On the Discovery Criteria page, select a target resource pool and click Add. This specifies where the monitored computers will be placed. Use the All Management Servers Resource Pool unless you have configured another option. A resource pool is a collection of Operations Manager management servers that share an Operations Manager workload.
4. On the Discovery Criteria dialog box, enter the IP address or FQDN of the computers running UNIX or Linux that you wish to deploy the agent on. Use the Set Credentials button to configure the credentials used for discovery and agent installation. This dialog box is shown in Figure 2-12. After you have configured the discovery criteria, save these criteria, and then click Discover on the Discovery Criteria page.
FIGURE 2-12 Discovery criteria
5. On the Computer Selection page, select the discovered computers that you want to manage, and click Manage. The agent will be deployed.
Manual agent installation
You’ll need to install the Operations Manager agent manually if you need to monitor computers located on a perimeter or isolated network, or if you need to monitor computers that are not members of an AD DS domain. You can perform manual installation in one of two ways:
Double-clicking the MOMAgent.msi installer and answering the questions posed in the wizard
Using the command line options to perform the installation
Using the MOMAgent.msi Setup Wizard
MOMAgent.msi comes in x64 and x86 versions. These files are located by default under the C:\Program Files\Microsoft System Center 2012 R2\Operations Manager\Server\AgentManagement folder, as shown in Figure 2-13.
FIGURE 2-13 Agent location
To install the agent manually using the wizard, perform the following steps:
1. Start the installer and accept the license terms.
2. Specify the destination folder. By default this will be C:\Program Files\Microsoft Monitoring Agent.
3. On the Agent Setup page, select whether you want Active Directory to configure the agent. This requires that you have configured a container in AD DS using MOMADAdmin.exe. You can also configure the agent to connect to Operations Manager to determine management group information.
4. On the Management Group Configuration page, specify the Management Group Name, the Management Server Name, and the Management Server Port. Figure 2-14 shows this page configured to connect to the management group named Tailspintoys on the management server Opsmgr.tailspintoys.internal.
FIGURE 2-14 Management group configuration
5. On the Agent Action Account page, choose whether actions performed by the Operations Manager agent are completed using the Local System account, a Domain account, or a Local account.
6. On the Microsoft Update page, choose whether Microsoft Update will be used to provide automatic updates.
7. Review the summary, like the one shown in Figure 2-15, and click Install to complete the agent installation.
FIGURE 2-15 Agent setup
Using the Command Line
Rather than walking through each page of the MOMAgent.msi Wizard, you can perform agent installation by running MOMAgent.msi using Msiexec.exe from the command line. Msiexe.exe allows you to run installers that use the .msi format and is located in the %WinDir%\System32 folder.
To run MOMAgent.msi from the command line, use the following format:
%WinDir%\System32\msiexec.exe /i path\Directory\MOMAgent.msi /qn USE_SETTINGS_
FROM_AD={0|1} USE_MANUALLY_SPECIFIED_SETTINGS={0|1} MANAGEMENT_GROUP=MGname
MANAGEMENT_SERVER_DNS=MSname MANAGEMENT_SERVER_AD_NAME=MSname SECURE_PORT=PortNumber
ACTIONS_USE_COMPUTER_ACCOUNT={0|1} ACTIONSUSER=UserName ACTIONSDOMAIN=DomainName
ACTIONSPASSWORD=Password AcceptEndUserLicenseAgreement=1
Where:
USE_SETTINGS_FROM_AD={0|1} Use this option to specify whether management group settings are obtained from AD DS, or from the command line. This works in conjunction with the next setting. The computer must be a member of the domain, and Active Directory must be configured if you are going to use this option.
USE_MANUALLY_SPECIFIED_SETTINGS={0|1} Use this option to specify whether management group settings are specified from the command line. This works in conjunction with the previous setting.
MANAGEMENT_GROUP=MGname Use this option to specify the Operations Manager Management Group name, when you are using the command line to specify the options.
MANAGEMENT_SERVER_DNS=MSname Use this option to specify the Operations Manager management server FQDN, when using the command line to specify the options.
MANAGEMENT_SERVER_AD_NAME =MSname Use this option to specify the Active Directory computer account name of the Operations Manager Management Server, when using the command line to specify the options.
SECURE_PORT=PortNumber Use this option to specify the health service port number. The default port number is 5723.
ACTIONS_USE_COMPUTER_ACCOUNT={0|1} Use this option to specify whether the LOCAL SYSTEM account or a specified user account, specified using the ACTIONSUSER, ACTIONSDOMAIN, and ACTIONSPASSWORD settings, is used.
ACTIONSUSER=UserName Use this option when using a custom account to specify the user name of the account.
ACTIONSDOMAIN=DomainName Use this option when using a custom account to specify the domain name used with the account.
ACTIONSPASSWORD=Password Use this option when using a custom account to specify the password associated with the account.
AcceptEndUserLicenseAgreement=1 Use this option to agree to the Microsoft Software License Terms. This option is required when installing the Operations Manager agent from the command line.
Before a manually installed agent can be used, you’ll need to authorize it from the Operations Manager console.
More Info: Manual Agent Installation
You can learn more about manual agent installation at http://technet.microsoft.com/en-us/library/hh212915.aspx.
Automatic agent assignment
You can use AD DS to assign computers with the Operations Manager agent installed to Operations Manager management groups. For example, you would do this when you have deployed the agent manually using the option to get management server and group settings from AD DS, or when you’ve deployed the Operations Manager agent as part of an operating system image.
To configure automatic agent assignment, perform the following steps:
1. Create a domain security group and add it to the Operations Manager Administrators security role. Figure 2-16 shows the TailspinMOMAdmin security group added to this security role.
FIGURE 2-16 Operations Manager Administrators
2. A member of the Domain Admins AD DS group must then run the following command MOMADADMIN.exe <ManagementGroupName> <MOMAdminSecurityGroup> <RunAsAccount> <Domain> where
<ManagementGroupName> is the name of the Operations Manager management group.
<MOMAdminSecurityGroup> is the name of the domain security group that has been added to the Operations Manager Administrators security role.
<RunAsAccount> is an account that has the permission to read and write information to the newly created container in Active Directory.
<Domain> is the domain that the container is created in.
3. Running this command also adds the <RunAsAccount> to the <MOMAdminSecurityGroup>.
More Info: Active Directory Assignment
You can learn more about Active Directory assignment at http://technet.microsoft.com/en-us/library/hh212922.aspx.
For example, to create the container for the TailspinToys management group, using the TAILSPINTOYS\TailspinMOMAdmin group as the security group, and TAILSPINTOYS\Administrator as the runas account, start the command:
MOMADAdmin.exe tailspintoys TAILSPINTOYS\TailspinMOMAdmin TAILSPINTOYS\Administrator
tailspintoys
The MOMADAdmin.exe utility is located by default in the C:\Program Files\Microsoft System Center 2012 R2\Operations Manager\Server folder. You can determine your Operations Manager management group name using the Get-SCOMManagementGroup Windows PowerShell cmdlet.
Once the container has been created, you run the Agent Assignment And Failover Wizard to assign agents to specific management servers within the management group. You can start the Agent Assignment And Failover Wizard by clicking Add on the Auto Agent Assignment tab of the Management Server Properties dialog box of the management server that you want to assign agents to, in the Administration workspace shown in Figure 2-17.
FIGURE 2-17 Auto Agent Assignment
You must run the Agent Assignment And Failover Wizard in each domain where you want to use it to perform auto assignment. To complete the wizard, perform the following steps:
1. On the Domain page, specify the domain for which you are configuring automatic agent assignment. Figure 2-18 shows the selection of the Tailspintoys.internal domain.
FIGURE 2-18 Domain selection
2. On the Inclusion Criteria page, you can create an LDAP query, or use the dialog box to configure a search based on criteria including name, description, managed by, operating system, and operating system version. Figure 2-19 shows the inclusion criteria that will include all of the computers that have names starting with the characters SYD.
FIGURE 2-19 Inclusion criteria
3. On the Exclusion Criteria page, you can enter a list of computers to be excluded from agent assignment. You should list computers using FQDNs, separating each by a semicolon, comma, or new line. Figure 2-20 shows the computer Excluded.tailspintoys.internal in the list of excluded computers.
FIGURE 2-20 Exclusion rule
4. On the Agent Failover page, you can specify whether agents will contact another management server in the same management group automatically, or manually fail over to specific management servers. Figure 2-21 shows the Agent Failover page of the Agent Assignment And Failover Wizard, with the Automatically Manage Failover option page.
FIGURE 2-21 Automatic failover management
Authorizing agents
If you are planning on installing the Operations Manager agent onto a computer manually, using the MOMAgent.msi installer, or plan to deploy the agent as part of an image, you’ll need to configure how the Operations Manager management deals with the agents once it is contacted.
You can configure one of the following options:
Reject New Manual Agent Installations When you select this option, any requests from a manually deployed agent, or agent deployed as part of an image will automatically be rejected by the Operations Manager management server.
Review New Manual Agent Installations In Pending Management View When you select this option, all requests from manually deployed agents or agents deployed as part of an image will be placed in a list, visible through the Pending Management queue. Administrators are able to use this list to perform approval.
Auto-Approve New Manually Installed Agents When you select this option (only available if the Review option is already selected) any Operations Manager agent that contacts the management server will automatically be joined to the management group.
To configure how the Operations Manager management server responds to manual agent installation, perform the following steps:
1. In the Settings node of the Administration workspace, right-click Security under Type: Server, and click Properties.
2. On the Global Management Server Settings - Security dialog box, select the option that you want to configure, as shown in Figure 2-22.
FIGURE 2-22 Global Management Server Settings
More Info: Managing Manual Agent Installation
You can learn more about managing manual agent installation at http://technet.microsoft.com/en-us/library/hh212853.aspx.
Exam Tip
You’ll need to be familiar with the different ways in which you can deploy the Operations Manager agent. You’ll also need to know in which cases you will need to authorize an agent and when you need to perform a manual installation
Discovering network devices
Operations Manager discovers network devices by running discovery rules that the Operations Manager Administrator configures. Network discovery rules include the following information:
IP address or FQDN of the devices that you want to discover.
The SNMP (Simple Network Management Protocol) version used by each device. Operations Manager supports SNMP v1, v2, and v3.
The SNMP community string of any SNMP v1 or v2 compatible devices to be discovered.
User name, context, authentication protocol, authentication key, privacy key, and privacy protocol for each SNMP v3 device.
The management server that will monitor the discovered network devices.
When performing network discovery, any firewalls between the Operations Manager management server and the network devices to be discovered must allow SNMP (UDP) and ICMP bidirectionally. SNMP usually uses 161 (UDP) and 162 (TCP/UDP). If you are going to be discovering devices that use SNMP v1 or v2, you’ll need to configure the Run As account to use for this purpose. You can do this before creating the discovery rule, or during the discovery rule creation process.
To create a network discovery rule, perform the following steps:
1. Right-click the Network Management node in the Administration workspace of the Operations Manager console, and click Discovery Wizard.
2. On the Discovery Type page of the Computer And Device Management Wizard, click Network Devices, as shown in Figure 2-23, and click Next.
FIGURE 2-23 Network devices
3. On the General Properties page, shown in Figure 2-24, provide the following information:
The name for the rule. An informative name for the Rule.
The management server from which network discovery will be performed.
The resource pool. You can create a new resource pool, or select an existing resource pool that will be responsible for monitoring discovered network devices.
FIGURE 2-24 Network Discovery rule
4. On the Discovery Methods page, shown in Figure 2-25, choose between Explicit Discovery and Recursive Discovery. You should select Explicit Discovery when you know the address of each network device that you want Operations Manager to manage. Recursive Discovery provides a more thorough discovery of network devices, but this process is likely to take longer and is likely to discover devices that you may not be interested in having Operations Manager monitor.
FIGURE 2-25 Explicit Discovery
5. If you are discovering devices that support SNMP v1 or SNMP v2, either select an existing Run As account, or create a new Run As account for this purpose. This Run As account includes the SNMP v1 or v2 community string.
Exam Tip
Remember what you need to include when configuring a Run As account for network device discovery for devices that use SNMP v1 or v2.
6. On the Devices page, shown in Figure 2-26, you can either add the devices that you want to discover manually, or import them from a text file that contains a list of IPv4 addresses.
FIGURE 2-26 Specify devices
7. When adding devices manually, provide the following information as shown in Figure 2-27:
IPv4 address or FQDN of the device.
Access mode. This can be ICMP, SNMP, or ICMP and SNMP. If you choose ICMP and SNMP, the device must be accessible using both protocols.
Port number. The default is UDP port 161, but if you are using another port for SNMP you can change this.
SNMP version. This allows you to specify whether to use SNMP v1 or v2, or SNMP v3. If using SNMP v1 or v2, specify the Run As account that contains the community string.
FIGURE 2-27 Add a device
8. If adding an SNMP v3 device, you will need to add the FQDN or IP address, as well as an SNMP v3 Run As account that includes User Name, Context, Authentication Protocol, Authentication Key, Privacy Protocol, and Privacy Key.
9. If you are creating a recursive discovery rule, you can configure filters based on IP address range. You can also configure exclusions on a per IP address basis.
10. On the Schedule Discovery page, specify how often to run the network device discovery rule. Figure 2-28 shows this page.
FIGURE 2-28 Network discovery schedule
11. On the Summary page, review the settings, and click Create.
You can confirm successful discovery of network devices by viewing the Network Devices node, under Network Management in the Administration workspace of the Operations Manager console.
More Info: Network Device Discovery
You can learn more about how Operations Manager can discover network devices at http://technet.microsoft.com/en-us/library/hh278846.aspx.
Monitoring network devices
You can use Operations Manager to monitor physical and virtual network routers and switches, including the ports on those devices, VLANs (virtual local area network) and Host Standby Router Protocol (HSRP) groups that they are members of, as well as the status of supported firewall and load balancing devices. Specifically, you can use Operations Manager to monitor the following aspects of network devices:
Connection health Monitor from the perspective of the network device and devices connected to the monitored network device.
VLAN health Allows you to view the health state of switches that participate in a specific VLAN.
HSRP group health View the health state of the devices that participate in a HSRP group.
Port/Interface Monitor the operational and administrative status of device ports and interfaces.
Processor utilization Monitor the processor utilization of supported network devices.
Memory utilization Monitor the memory utilization of supported network devices.
System Center 2012 R2 Operations Manager supports monitoring the following numbers of network devices:
2000 network devices (approximately 25,000 monitored interfaces/ports) managed by two resource pools.
1000 network devices (approximately 12,500 monitored interfaces/ports) managed by a single resource pool that consists of three or more Operations Manager management servers.
To perform network discovery and monitoring, you need to ensure that the following management packs are installed:
Microsoft.Windows.Server.NetworkDiscovery
Microsoft.Windows.Client.NetworkDiscovery
Discovered network devices are visible through the Monitoring workspace of the Operations Manager console. Under the Network Monitoring node, shown in Figure 2-29, you can view the following information:
FIGURE 2-29 Network Monitoring categories
Active Alerts
Hosts
HSRP Groups
Legacy Network Devices
Network Devices
Network Summary Dashboard
Routers
Switches
VLANS
You can also view the following device-related performance information:
Free Memory (Percent)
ICMP Ping Response Time (Milliseconds)
Interface Usage Statistics
Port Usage Statistics
Processor Utilization (Percent)
You can also use the following Operations Manager dashboard views when monitoring network devices:
Network Summary Dashboard Provides summary information, including which network devices are experiencing the highest processor utilization, or which interfaces are encountering the most errors.
Network Node Dashboard Provides information about each network device. Includes alerts generated by each device and information including processor utilization.
Network Interface Dashboard Provides information about network device interfaces/ports, including alerts generated by interfaces/ports and traffic statistics.
Network Vicinity Dashboard Provides information on the relationship between discovered network devices and computers with the Operations Manager agent installed. This is useful for determining the cause of network outages.
More Info: Network Device Monitoring
You can learn more about network device monitoring at http://technet.microsoft.com/en-us/library/hh212935.aspx.
Using management packs
An Operations Manager management pack is a collection of elements that allow you to use Operations Manager to perform tasks, gather, and display important information about computers, applications, services, and devices. Management packs are often specific to a particular product, device, application, role, or service, and contain elements that extend Operations Manager’s ability to integrate with that service. For example, the Microsoft Exchange Server 2013 management pack contains elements that allow Operations Manager to monitor important aspects of an Exchange Server 2013 deployment, just as the System Center Management Pack for SQL Server contains elements that allow Operations Manager to monitor important aspects of a SQL Server 2012 deployment. Individuals or organizations with detailed knowledge about how the managed object functions, write management packs. You can view the list of management packs imported into Operations Manager from the Management Packs node of the Administration workspace, as shown in Figure 2-30.
FIGURE 2-30 Management Packs
More Info: Management Packs
You can learn more about Operations Manager management packs at http://technet.microsoft.com/en-us/library/hh212794.aspx.
Management packs can include some or all of the following elements:
Monitors Provides information to the Operations Manager agent about which aspects of the managed object it should track. For example, which logs to monitor.
Rules Determines which performance and discovery data the agent collects. It also determines which situations trigger alerts. For example, which event in a specific log should generate an Operations Manager alert.
Tasks Allows an activity to be performed either through the agent or the Operations Manager console. For example, a task might restart a particular service. Tasks are triggered either by alerts or manually through the Operations Manager console. Tasks are performed by the Operations Manager agent or by the console (for example, when you trigger a ping task).
Views Provides a customized interface for viewing information and managing managed objects.
Reports Display insightful and meaningful data about the managed object. Customized reports come from the management pack authors to display information about the managed objects.
Object Discoveries Identify objects that Operations Manager can monitor.
Run As profiles Allows rules, tasks, monitors, and discoveries to be run using an alternate set of credentials.
Knowledge These are helpful articles that provide Operations Manager administrators with diagnostic and problem resolution advice.
Management packs come as either sealed or unsealed. A sealed management pack is read-only. Sealed management packs are digitally signed by the management pack authors and use the .mp extension. This digital signature gives you confidence that a third party hasn’t modified the contents of the management pack. You can make modifications to sealed management packs using overrides, described later in this chapter. Unsealed management packs usually use the .xml extension and can be created and modified by the Operations Manager Administrator.
Exam Tip
Remember the difference between sealed and unsealed management packs.
Some management packs are designated libraries. Library management packs provide a set of classes on which other management packs build. Dependencies exist where one management pack makes references to content in another management pack. To view a management pack’s dependencies, right-click the management pack and select the Dependencies tab, as shown in Figure 2-31. The information displayed on this tab will also provide you with a list of management packs that depend on this management pack.
FIGURE 2-31 Management pack dependencies
Importing management packs
While Operations Manager ships with a collection of management packs, to get the most out of the product, you’ll need to import management packs that are specific to the type of objects that you want to monitor. You can use several methods to obtain Operations Manager management packs.
The simplest method is to download and import management packs from the Microsoft System Center Marketplace using the Operations Manager console. Figure 2-32 shows searching for and selecting a SQL Server 2012 related management pack from the online catalog. System Center Marketplace stores a very large number of management packs and should be the first place you look when you need an Operations Manager management pack.
FIGURE 2-32 Management pack catalog
You can use the Operations Manager console to download management packs from the online catalog to import at a later point in time. Figure 2-33 shows the Operations Manager console interface for downloading management packs. This allows you to store important management packs in a separate location for easy import into other Operations Manager management groups.
FIGURE 2-33 Management pack download
If you’ve obtained the management pack files already, you can import them from local storage using the Operations Manager console. When importing sealed management packs, you must ensure that the Operations Manager server trusts the CA that issued the signing certificate used to sign the sealed management pack. If the Operations Manager server doesn’t trust the CA that issued the signing certificate that was used to sign the sealed management pack, you won’t be able to import the sealed management pack. Prior to attempting to import management packs, ensure that you’ve imported any management pack dependencies. You won’t be able to import a management pack if dependency management packs are not present on the Operations Manager server. Figure 2-34 shows importing SQL Server 2012 and Exchange Server 2013 management packs.
FIGURE 2-34 Import management pack
Important to note is that once you have imported a management pack, Operations Manager will automatically begin monitoring relevant objects based on the default management pack configurations and thresholds. This can lead to an increase in alerts, depending on the configuration of the management pack that you have imported.
More Info: Importing Management Packs
You can learn more about importing management packs at http://technet.microsoft.com/en-us/library/hh212691.aspx.
Removing management packs
Removing a management pack eliminates all of the settings and thresholds associated with the management pack. For example, if you’ve upgraded all of the SQL Server instances in your organization to SQL Server 2014, you might choose to remove management packs that were used to monitor previous versions of SQL Server.
You can only remove a management pack if any dependent management packs have also been removed. For example, Figure 2-35 shows that the SQL Server Core Library management pack is required for three other management packs. Before you are able to remove the SQL Server Core Library management pack, you’ll have to remove the three management packs that list the SQL Server Core Library management pack as a dependency. You delete a management pack by right-clicking the management pack in the Operations Manager console, and clicking Delete.
FIGURE 2-35 Management pack dependencies
More Info: Removing Management Packs
You can learn more about removing management packs at http://technet.microsoft.com/en-us/library/hh230746.aspx.
Thought experiment: Operations Manager management packs and agents at Tailspin Toys
You are responsible for managing the Operations Manager deployment at Tailspin Toys. The previous administrator imported a large number of management packs that are no longer relevant to your organization and should be removed. You also want to start using Operations Manager to monitor several network devices that support the SNMP v3 protocol. Finally, you want to configure Active Directory so that domain-joined clients automatically receive information about the Operations Manager deployment.
With this information in mind, answer the following questions:
1. What steps must you take before removing an installed management pack?
2. What must you include when configuring a Run As account for devices that will be managed through SMNP v3?
3. Which utility do you use to configure automatic agent assignment?
Objective summary
You can deploy the Operations Manager agent to computers that are members of a trusted Active Directory domain using the Discovery Wizard. You can also manually install the agent, or include it in an operating system image.
You can deploy the Operations Manager agent to supported versions of UNIX and Linux using the Discovery Wizard, or by manually installing the agent.
When manually installing the agent, or including it in an image, you’ll need to configure agent authorization.
You can use Operations Manager to manage network devices that support the SNMP v1, v2, or v3 protocols.
Management packs allow you to enhance the functionality of Operations Manager.
You can only import a management pack if the management pack dependencies are already installed.
You can only remove a management pack if no other management packs exist, that have the management pack you want to remove as a dependency.
Objective review
Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of the chapter.
1. You are creating a Run As account to be used with a network device discovery rule. All network devices in your organization support SNMP v2. Which of the following must you include when configuring the Run As account?
A. Community string.
B. Device name.
C. Device IP address.
D. Authentication key.
2. You want to ensure that all newly deployed servers in your organization have the Operations Manager agent installed and connected to the single management server. All newly deployed servers are automatically joined to an AD DS domain. Which of the following must you configure to accomplish this goal?
A. Configure Active Directory automatic agent assignment.
B. Configure the Global Management Server additional setting Automatically Approve New Manually Installed Agents.
C. Configure the Global Management Server settings to Reject New Manual Agent Installations.
D. Configure the Global Management Server settings to Review New Manual Agent Installations In Pending Management View.
3. Which of the following utilities do you use to configure Active Directory automatic agent assignment?
A. MOMADadmin.exe.
B. Cmtrace.exe.
C. MOMAgent.msi.
D. GPedit.msc.
Objective 2.2: Configure end-to-end monitoring
Once you have imported management packs, you’ll need to tune them so that they provide you with useful monitoring information. Another form of monitoring is synthetic transactions, which allow you to configure monitoring for a variety of different objects, from websites, through to UNIX processes, network ports, and Windows Services. If you want to verify the functionality of your organization’s web applications from external locations, you can configure Global Service Monitor. If you want to monitor complex multi-tier applications, you can configure a distributed application model.
This section covers the following topics:
Managing management packs
Configuring synthetic transactions
Using Global Service Monitor
Application Performance Monitoring
Creating distributed application models
Managing management packs
Subject matter experts create Operations Manager management packs so that Operations Manager will provide you with useful information about a particular application, service, role, or device. However, while the experts who created the management pack know a large amount about the subject of the management pack, they don’t know anything about your specific private cloud environment. Importing the management pack is only the first part of the management pack’s lifecycle. You also need to test, tune, and alter each management pack so that it provides you with the information that you actually need to know to perform your job.
More Info: Management Pack Lifecycle
You can learn more about the management pack lifecycle at http://technet.microsoft.com/en-us/library/hh212732.aspx.
Microsoft describes the management pack lifecycle in the following manner:
Review and evaluate in pre-production environment Before deploying a management pack into your organization’s production environment, you should evaluate the management pack in a test or development environment.
Tune the management pack settings Use overrides to tune the management pack. Save these overrides in a separate unsealed management pack.
Deploy the management packs into production environment When you do this, you’ll also import the separate, unsealed management packs that contained the overrides that you created in your test or development environment.
Maintain the management pack Once the management pack has been deployed, you may still need to perform additional tuning. The following changes in circumstances should lead you to retune the management pack:
Changing business needs Your organizational requirements might change in terms of the monitoring of the object that is the subject of the management pack. This may necessitate reevaluating how the management pack has been tuned.
The environment changes For example, there is a change in computer hardware, operating system, or virtual machine configuration that impacts the monitored object.
Additional applications You add a new application to the environment that interacts with the monitored object in a substantive way.
Application upgrade You should tune the management pack if the management pack monitors an application that you’ve upgraded, or to which you’ve applied a service pack.
Updated management pack If the vendor releases an updated version of the management pack, you may need to begin the process again. Management pack upgrades provide a great example as to why you should document the management pack tuning process. If you’ve created documentation explaining how you’ve tuned the management pack, you’ll be able to refer to it when tuning a new version of the management pack.
Overrides
When you first import a management pack, you may find that while it tells you many useful things about the product, service, device, or object that you should know, it also tells you many things about the product, service, device, or object that you aren’t interested in. Overrides allow you to alter the settings of a rule or a monitor in a sealed management pack without changing the rule or monitor itself.
To configure an override for a rule, perform the following steps:
1. In the Authoring workspace of the Operations Manager console, expand Management Pack Objects, and click the Rules node.
2. Locate the rule for which you want to create the override. Figure 2-36 shows a rule named MSSQL 2012: Logins Per Second.
FIGURE 2-36 Management pack rules
3. Right-click the rule, and click Properties. On the Overrides tab, shown in Figure 2-37, click Disable to disable the rule, or click Override to change the parameters of the rule.
FIGURE 2-37 Configure overrides
4. When you click Override, you’ll be asked to choose between all objects of the class that the override applies to, to a group, to a specific object of the class, or for all objects of another class. If you only wanted to configure the override on logins per second for one SQL Server instance, you’d choose the Specific Object Of The Class option.
5. On the Override Properties dialog box, you then select the parameter name that you want to override, provide a new override value, select the option to enforce the override, and select an unsealed management pack in which to store the override. You should create a management pack to store for overrides of a specific management pack, otherwise it will be stored in the default management pack. Figure 2-38 shows that the Frequency parameter of the MSSQL 2012: Logins Per Second rule has been altered to 500.
FIGURE 2-38 Override properties
To configure an override for a monitor, perform the following steps:
1. In the Authoring workspace of the Operations Manager console, expand Management Pack Objects, and click the Monitors node.
2. Select the monitor that you want to configure the override for. Figure 2-39 shows the Server Resources monitor in the Exchange Server Management pack.
FIGURE 2-39 Monitors
3. Right-click the monitor that you want to configure the override for, and click Properties.
4. On the Overrides tab, shown in Figure 2-40, click the Monitor that you wish to configure the override for, and click Override. Click Disable if you want to disable the monitor instead.
FIGURE 2-40 Monitor overrides
5. When you click Override, you’ll be given the option of creating an override for all objects in the class, for a group, for a specific object, or for objects in another class. If you only want to configure an override for a specific monitored object, rather than all objects the monitor is used with, select Specific Object. You can only select a specific object if Operations Manager already monitors that object.
6. On the Override Properties dialog box, select the parameter that you want to modify, set the Override value, ensure that the Enforced checkbox is selected, and choose the unsealed management pack in which to store the override. For example, in Figure 2-41, the Alert Priority is set to Medium, from Low.
FIGURE 2-41 Override options
More Info: Overrides
You can learn more about Operations Manager management pack overrides at http://technet.microsoft.com/en-us/library/hh212869.aspx.
Tuning management packs
Tuning a management pack is the process of adjusting what the management pack is telling you so it provides you with the information that you want to know, rather than the information that the management pack authors think you need to know. When tuning management packs, you should consult with the service owner, subject matter experts, and the operations team members who are responsible for monitoring and responding to alerts.
You can use the following approach when tuning management packs:
Start by tuning the highest severity alerts first, and then work through towards the lowest.
Remember that rules generate alerts that do not auto-close when the issue that caused the alert is resolved. Alerts generated by monitors close, then the issue is fixed.
Evaluate how actionable an alert is. Actionable alerts are those where you are informed what event occurred to trigger the alert, and where there are clear steps to resolve the cause of the alert. Consider disabling alerts for rules where no action is required.
Evaluate the validity of the alert. Some alerts will inform you that they were triggered by a particular event, such as a service failing. If you investigate and find that the service that supposedly triggered the alert hasn’t failed, assess whether you should disable the alert.
Evaluate whether multiple alerts are informing you about the same issue. You can suppress those alerts that are providing you with duplicate notification about the same issue.
Microsoft provides the following recommendations for management pack tuning:
Only import a single management pack at a time. This gives you a chance to concentrate on tuning one management pack. Tuning more than one management pack concurrently consumes substantially more time.
Review alerts reported for servers monitored by the newly imported management pack. Use the Alerts and Most Common Alerts reports to determine which alerts are being created the most often, and use this as a starting point for tuning.
Disable monitors or rules when you determine that you don’t need to be notified about a particular issue.
Alter the threshold of the monitor generating the alert if you want the underlying issue to be monitored, but not at the sensitivity at which the current monitor is configured.
Save overrides to an unsealed management pack that uses the name ManagementPack_Overrides. For example, call the management pack that stores the overrides for the Microsoft Exchange Server 2013 management pack, Microsoft Exchange Server 2013_Overrides. This simplifies the process of keeping track of overrides.
More Info: Management Pack Tuning
You can learn more about tuning Operations Manager management packs at http://technet.microsoft.com/en-us/library/hh230704.aspx.
Exporting management packs
Exporting a management pack allows you to create a backup of that management pack. This can be useful for management packs that store overrides and customizations as exporting that management pack allows you to save all of the overrides and customizations that you configured. This allows you to then import the custom unsealed management pack to a management server in another management group so that you can use the overrides and customizations with the sealed management pack in that management group. For example, you might spend time tuning a new sealed management pack in a development-monitoring environment before introducing it into a production-monitoring environment. Prior to importing the management pack into the production environment, you would export the customizations into a separate unsealed management pack, importing both the sealed and unsealed management pack.
If you are using the Operations Manager console, you’re only able to export unsealed management packs. If necessary, you can export a sealed management pack using the Export-SCOMManagementPack Windows PowerShell cmdlet, though it is usually simpler to reimport the sealed management pack from the location from which you originally obtained it.
More Info: Exporting Management Packs
You can learn more about exporting management packs at http://technet.microsoft.com/en-us/library/hh320149.aspx.
Configuring synthetic transactions
Synthetic transactions are a form of outside-in monitoring which do not require an agent on the monitored object. Synthetic transactions are performed by a third computer, with the Operations Manager agent installed, called a watcher node. Synthetic transactions are tests that are performed to determine the availability or performance of one of the following items:
OLD DB Data Source
Process
TCP Port
UNIX or Linux Log File
UNIX or Linux Process
Web Application Availability
Web Application Transaction
Windows Service
You can configure Operations Manager to run tests against these items by configuring one of the management pack templates, available through the Authoring workspace of the Operations Manager console, and shown in Figure 2-42. The Application Performance Monitoring template, also listed here, is covered later in the chapter.
FIGURE 2-42 Management pack templates
The tests that form the basis of synthetic transactions are initiated from a computer termed a watcher node. A watcher node can be a management server, a computer or device that hosts an Operations Manager agent. When configuring certain synthetic transactions, you specify which computers will function as watcher nodes, as shown in Figure 2-43.
FIGURE 2-43 Watcher nodes
More Info: Watcher Nodes
You can learn more about watcher nodes at http://technet.microsoft.com/en-us/library/hh457584.aspx.
OLE DB data source
You can use the OLE DB data source template to create a synthetic transaction to monitor the performance and availability of any database, not just those running Microsoft’s SQL Server, that you can establish a connection to through OLE DB. It’s possible to create this synthetic transaction even when the computer that hosts the database does not have an Operations Manager agent installed.
To create a synthetic transaction using the OLE DB Data Source Wizard, perform the following steps:
1. Under Management Pack Templates, in the Authoring workspace of the Operations Manager console, click OLE DB Data Source, and click Add Monitoring Wizard on the ribbon.
2. On the Monitoring Type page, select OLE DB Data Source, as shown in Figure 2-44, and click Next.
FIGURE 2-44 OLE DB Data Source
3. On the General Properties page, provide a name for the monitor, and select an unsealed management pack in which to store the monitor.
4. On the Connection String page, provide the connection string to the database that you will be connecting to with the monitor. Provide a query that will be used to perform the test and specify a timeout. Figure 2-45 shows a query against the Operations Manager database.
FIGURE 2-45 Connection string
5. On the Query Performance page, select the measurements that you want to monitor, the error threshold, and the warning thresholds, as shown in Figure 2-46.
FIGURE 2-46 Query performance
6. On the Watcher Nodes page, specify the computers with the Operations Manager agent installed from which the OLE DB test will be performed.
7. Complete the wizard to create the OLE DB synthetic transaction.
More Info: OLE DB Data Source
You can learn more about performing tests against OLE DB data sources at http://technet.microsoft.com/en-us/library/hh457575.aspx.
Process
A process monitoring synthetic transaction allows you to monitor whether a specific process is running on a computer. You can use a process monitoring synthetic transaction to determine the following information:
Number of processes running
Amount of time that the process has been running
Processor utilization of the process
Process memory utilization
When configuring a process monitoring synthetic transaction, you can also configure an alert to be raised if the processor or memory utilization exceeds a specific threshold, as shown in Figure 2-47.
FIGURE 2-47 Performance Data
More Info: Processes
You can learn more performing tests against processes at http://technet.microsoft.com/en-us/library/hh457551.aspx.
TCP Port
A TCP Port-based synthetic transaction allows you to perform a test to determine if a service, host, or device is contactable over the network. When creating a TCP Port-based synthetic transaction, you can determine the following:
Can the target host be contacted?
Is the connection to the target host accepted?
Has the connection to the target host timed out?
Can the FQDN of the target host be resolved?
When configuring the TCP Port-based synthetic transaction, you specify the computer name or IP address, and the port that you want the transaction to connect to. Figure 2-48 shows a synthetic transaction that will connect to host Smtp.tailspintoys.internal on port 25.
FIGURE 2-48 Target and port
More Info: TCP Ports
You can learn more about performing tests against TCP Ports at http://technet.microsoft.com/en-us/library/hh457544.aspx.
UNIX or Linux log file
The UNIX or Linux log file synthetic transaction type allows you to check whether specific text is detected in a certain log file residing on a computer running the UNIX or Linux operating systems. When configuring the synthetic transaction, you must provide the following information:
Computer Name This is the name of a computer running UNIX or Linux that has the Operations Manager agent installed and which hosts the log file that you want to monitor. As an alternative, you can specify a Computer Group, which will allow you to use the synthetic transaction to monitor multiple computers with the UNIX or Linux operating system.
Log file path The path to, and name of, the log file
Regular expression This is a regular expression to detect the text that must occur in the log file to trigger an alert. If the text is a simple string, you don’t have to use a regular expression.
More Info: UNIX or Linux Log Files
You can learn more about performing tests on UNIX or Linux log files at http://technet.microsoft.com/en-us/library/hh457589.aspx.
UNIX or Linux Process
You can use the UNIX or Linux Process synthetic transaction type to determine if a particular process is currently running on a computer running the UNIX or Linux operating systems that have the Operations Manager agent installed. When configuring a synthetic transaction type to determine if a process is running on a computer with a supported UNIX or Linux operating system installed, you must provide the following information:
Process name The name of the process.
Computer group The Operations Manager computer group that contains the UNIX or Linux hosts that you want to check for the process.
Alert sensitivity The sensitivity of the alert to raise if the process is not running.
You can also configure a regular expression to filter process arguments to separate multiple instances of a process with the same name.
More Info: UNIX or Linux Processes
You can learn more about performing tests against UNIX or Linux Processes at http://technet.microsoft.com/en-us/library/hh457572.aspx.
Web application availability
A web application availability synthetic transaction allows you to create a monitoring test for one or more web application URLs to determine that they respond to basic requests. To create a web application availability synthetic transaction, perform the following steps:
1. Click the Management Pack Templates node in the Authoring workspace of the Operations Manager console, and then click Add Monitoring Wizard on the ribbon.
2. On the Monitoring Type page, select Web Application Availability Monitoring, as shown in Figure 2-49, and click Next.
FIGURE 2-49 Web application availability monitoring
3. On the General page of the Add Monitoring Wizard, provide a name for the synthetic transaction monitor, and specify an unsealed management pack in which to store the transaction’s settings.
4. On the Enter URLs To Be Monitored page, specify the website name and the website address. Figure 2-50 shows the default IIS site of the server named Orchestrator.tailspintoys.internal.
FIGURE 2-50 URLs to monitor
5. On the Where To Monitor From page, specify which computers that have the Operations Manager agent installed will function as watcher hosts.
6. On the View And Validate Tests page, click Run Test to verify that the synthetic transaction works, as shown in Figure 2-51.
FIGURE 2-51 Test results
7. Complete the wizard to create the synthetic transaction.
More Info: Web Application Availability
You can learn more about performing tests against web application availability at http://technet.microsoft.com/en-us/library/hh881883.aspx.
Web application transaction
A web application transaction synthetic monitor goes further than a web application availability synthetic transaction as it not only verifies that the target web application is available, but that the web application responds to specific prompts and inputs, including authentication.
You can use the Web Recorder to record a browser session that includes multiple requests to a target web application. You can then use the information generated by the Web Recorder as the transaction used in the synthetic monitor.
To record a web application session and then create a synthetic monitor based on that information, perform the following steps:
1. In the Authoring workspace of the Operations Manager console, select Web Application Transaction Monitoring under Management Pack Templates.
2. In the Tasks menu, click Custom Actions, and then click Record A Browser Session.
3. On the Web Application Editor, shown in Figure 2-52, provide a name and select an unsealed management pack in which to store the session information.
FIGURE 2-52 Web application editor
4. On the Web Application Editor - Browsing Session dialog box, click Start Capture. Internet Explorer will launch. Browse to the web application and perform the interaction that you want to test.
5. When you complete the browsing session, close the browser, click Stop Capture, click Apply on the Web Application Editor, then select a watcher node, and click Apply again. Verify that the Web Application Data Imported Successfully message is displayed, as shown in Figure 2-53, and then close the Web Application Editor dialog box.
FIGURE 2-53 Web application editor
Clicking Apply creates the web application synthetic transaction. You can also create the web application synthetic transaction by performing the steps in the wizard.
More Info: Web Application Transactions
You can learn more about performing tests against web application Transactions at http://technet.microsoft.com/en-us/library/hh457553.aspx.
Windows Service
You can create a Windows Service synthetic transaction to determine the state of a service running on a Windows-based computer. When configuring the transaction, you need to provide the following information:
Service name
Operations Manager computer group
Once the service is selected, you can configure alerts to be triggered if specific CPU and memory thresholds are exceeded. Figure 2-54 shows a Windows Service synthetic transaction where an alert will be triggered if the CPU utilization exceeds 80 percent and the memory utilization exceeds 150 MB.
FIGURE 2-54 Performance data
More Info: Windows Service
You can learn more about performing tests against Windows Services at http://technet.microsoft.com/en-us/library/hh457595.aspx.
Exam Tip
Remember the different types of synthetic transactions that you can configure.
Using Global Service Monitor
System Center Global Service Monitor is a cloud service that allows you to perform outside-in monitoring of your organization’s external web-based applications. Outside-in monitoring is a type of monitoring that checks the availability and functionality of the monitored web-based application from a location external to your organization’s internal network. Rather than checking whether a web-based application is functioning from the perspective of a user and host on your organization’s internal network, a series of tests are performed against the web application from multiple locations around the world including:
Amsterdam, Netherlands
Chicago, United States
London, United Kingdom
Los Angeles, United States
Miami, United States
Moscow, Russia
Newark, United States
Paris, France
San Antonio, United States
Sao Paulo, Brazil
Singapore
Stockholm, Sweden
Sydney, Australia
Zurich, Switzerland
Global Service Monitor runs tests against the web application, rather than just verifying that the web server that hosts the application is responding to traffic requests. You can configure tests using Global Service Monitor where a test user signs on to the web application and performs certain tasks, such as ordering an item from an online store.
Global Service Monitor has the following conditions:
System Center 2012 Operations Manager or later must be deployed in your environment.
You must have a System Center Global Service Monitor subscription.
The Operations Manager servers in the management server pool that will be used with Global Service Monitor must be able to communicate with hosts on the Internet using the HTTP protocol.
Windows Identity Foundation must be installed on the management server that communicates with the Global Service Monitor servers in the cloud.
Global Service Monitor provides the following dashboards:
Summary Dashboard This dashboard provides simple availability information through a world map showing the locations that monitoring is being performed from. It also displays rollup test status for each location.
Detailed Dashboard This dashboard allows you to view the results of specific tests and alerts. For each web application that you are monitoring, you can check a location, and the tests performed from that location that you want to investigate.
Health Explorer This allows you to view the health status of a web application availability test on a per-location basis.
Test Visualization Dashboard This allows you to view Global Service Monitor web test results, including performance data.
More Info: Global Service Monitor
You can learn more about System Center Global Service Monitor at http://technet.microsoft.com/en-us/library/jj860368.aspx.
Application Performance Monitoring
Application Performance Monitoring (APM) allows you to monitor Internet Information Services (IIS) hosted .NET and Windows Communication Foundation (WCF) applications from both the server and client side perspectives. This allows you to use Operations Manager to collect detailed information about a specific application’s performance of reliability.
You use the .NET Application Performance Monitoring Template, available through the Authoring workspace of the Operations console, to configure Application Performance Monitoring. To view Application Performance Monitoring event details, it is necessary to have installed an instance of the Operations Manger web console. You’ll also have to import the following management packs and their dependencies:
Windows Server 2008 IIS 7.0
Operations Manager APM Web IIS 7
If monitoring Windows Server 2012 or Windows Server 2012 R2, you’ll need to import the following management packs and their dependencies:
Microsoft Windows Server 2012 IIS 8
Microsoft System Center APM Web IIS 8
Once these management packs are installed, you’ll be able to view the ASP.NET applications that Operations Manager finds in the Monitoring workspace, under Application Monitoring, under the .NET Monitoring node in the ASP.NET Web Application Inventory node. You’ll be able to view WCF applications under the IIS Hosted WCF Web Service Inventory node. Once APM discovers an application, IIS will usually need to be restarted. This allows the application pools to recycle, enabling the APM extensions, and allowing the APM function, to be registered with the application.
The server-side monitoring capabilities of APM include:
Performance event monitoring and alerting
Exception event monitoring and alerting
Modifying performance event threshold
Configuring performance event monitoring thresholds and sensitivity on a per-namespace or per-method basis
Configuring exception event monitoring types on a per-exception or per-exception handler basis.
The client-side monitoring capabilities of APM include:
Performance event monitoring and alerting
Exception event monitoring and alerting
Performance event thresholds for:
Page load
Asynchronous JavaScript and XML
WCF
Collecting data related to images, scripts, CSS, HTML, global variables, and exception stack
Collecting load balancer header data
To configure Application Performance Monitoring, perform the following steps:
1. In the Authoring workspace of the Operations Manager console, click Management Pack Templates, and then click Add Monitoring Wizard on the ribbon.
2. On the Monitoring Type page, shown in Figure 2-55, click .NET Application Performance Monitoring.
FIGURE 2-55 .NET Application Performance Monitoring template
3. On the General Properties page, provide the name of the monitor and specify an unsealed management pack in which to store the monitor files.
4. On the What To Monitor page, click Add. On the Object Search page, click Search. A list of web applications and services that have been discovered on servers that host the Operations Manager agent will be displayed. Select the applications that you want to manage, and click Add. This dialog box is shown in Figure 2-56.
FIGURE 2-56 Web application search
5. On the Server-Side configuration, select Enable Additional Configuration Options For Server-Side And Client-Side Monitoring, as shown in Figure 2-57, and then click Advanced Settings.
FIGURE 2-57 Server-side configuration
6. On the Advanced Settings page, review the current configuration, click Use Default Configuration, and then enable exception event monitoring for Application Failure Alerts, as shown in Figure 2-58.
FIGURE 2-58 Advanced monitoring settings
7. On the Server-Side Customization page, select the first segment, and click Customize. Verify that you can configure separate performance event monitoring settings for each application segment, and then click OK.
8. On the Client-Side Configuration page, enable performance event alerts and exception event alerts, as shown in Figure 2-59. Review the page load threshold, and Ajax and WCF threshold settings.
FIGURE 2-59 Client-side configuration
9. On the Enable Client-Side Monitoring, review the information presented, and then complete the wizard. Note that it is likely that you’ll need to restart IIS on the server that hosts the web application.
More Info: Application Performance Monitoring
You can learn more about Application Performance Monitoring at http://technet.microsoft.com/en-us/library/hh457578.aspx.
Creating distributed application models
A distributed application is one that consists of multiple objects. For example, a distributed application could comprise a database running on one monitored computer, a web server running on another computer, and a device that functions as a network load balancer. In Operations Manager, you can monitor each of the disparate objects that comprise the distributed application as a way of monitoring the overall health of the application. To be included in a distributed application, Operations Manager must already monitor each of these objects before you can add them to a distributed application using the Distributed Applications Designer, a tool available from the Operations Manager console.
The Distributed Application Designer allows you to create distributed applications using a graphical tool. This graphical tool is shown in Figure 2-60. The figure shows three groups named Databases, Management Servers, and Infrastructure.
FIGURE 2-60 Distributed Application Designer
You create distributed applications with the distributed application designer by using the following:
Objects Any object that has been discovered by Operations Manager can be used when building a distributed application.
Component Groups These are collections of objects. Before you can add an object to a distributed application, you need to add that object to the component group. Component groups can contain any type of object, though it’s also possible to restrict component groups to objects of a specific class.
Relationships These allow you to express that a relationship exists between two different component groups.
You can build a distributed application in the Distributed Application Designer from a blank template, or use one of the following built-in templates listed in Table 2-1.
TABLE 2-1 Distributed application templates
To create a distributed application, perform the following general steps:
1. In the Authoring workspace of the Operations Manager console, right-click Distributed Applications, and click Create A New Distributed Application.
FIGURE 2-61 Messaging distributed application
2. On the Create A Distributed Application dialog box, shown in Figure 2-62, provide a name for the distributed application, choose a template, and choose an unsealed management pack in which to store the application.
FIGURE 2-62 Blank application designer template
3. Click Add Component, to add a new component to the distributed application.
4. In the Create New Component Group, shown in Figure 2-63, specify the object classes that you want to include in the component group.
FIGURE 2-63 Component group objects
More Info: Distributed Applications
You can learn more about distributed applications at http://technet.microsoft.com/en-us/library/hh457612.aspx.
5. Populate the component group by dragging objects to it from the sidebar. Create relationships between component groups by clicking Create Relationship, and selecting the source and destination component groups.
Exam Tip
Remember that objects in the Distributed Application Designer must be members of component groups.
Thought experiment: Travel booking application at Margie’s Travel
The developers at Margie’s Travel have just deployed a .NET application across several virtual machines on your organization’s perimeter network. One VM hosts the IIS segment, and another hosts the web application’s database tier. This application is supposed to be available to users around the world.
With this information in mind, answer the following questions:
1. Which service should you configure to verify that the external web application is available to people around the world?
2. What would you configure to monitor the web application as a single entity?
3. What would you configure so that you can assess and monitor the performance of the web application?
Objective summary
You can tune a management pack so that it presents you with information that is relevant for your particular environment.
Tuning involves configuring overrides for monitors and rules that change how each of these work.
When tuning a sealed management pack, you store the overrides in a separate unsealed management pack
Synthetic transactions allow you to create monitors for a variety of items, including UNIX and Linux processes, Windows Services, web applications, and OLE DB data sources
Global Service Monitor allows you to configure remote monitoring of externally available web applications
Application Performance Monitoring allows you to configure advanced monitoring for .NET and WCF applications
Distributed application models allow you to create models of applications that depend upon multiple disparate segments.
Objective review
Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of the chapter.
1. Which type of synthetic transaction would you configure to verify that a SQL Server database was responding to remote queries?
A. Windows Service.
B. TCP Port.
C. OLE DB data source.
D. Web application availability.
2. Which type of synthetic transaction would you configure to verify that a specific web application was available? (choose the best answer)
A. TCP Port.
B. Windows Service.
C. OLE DB data source.
D. Web application availability.
3. Which type of synthetic transaction would you configure to verify that your ISP’s SMTP Smart Host was available to route outgoing email traffic?
A. OLE DB data source
B. Windows Service
C. Web application availability
D. TCP Port
Objective 2.3: Create monitoring reports and dashboards
Once you’ve configured the monitoring of the objects in your organization, you can view the monitoring data in a variety of ways. Service level tracking allows you to configure performance and availability benchmarks as a way of measuring whether the services that you are monitoring are meeting the availability and performance expectation of the stakeholders who use them. Reports allow you to generate visual representations of the information gathered by Operations Manager. Dashboards allow you to configure at-a-glance representations of important information.
This section covers the following topics:
Service-level tracking
Reports
Dashboards
Service level tracking
You can use Operations Manager to monitor how well your organization is meeting service level agreements (SLA) and/or operating level agreements (OLA). This is done by configuring Operations Manager to track service availability and performance against agreed upon benchmarks between the organizations participating in the SLA or OLA.
To perform service level tracking in Operations Manager, you define a specific service level objective (SLO) in terms of a set of monitors, such as performance and availability. You then schedule and access regular reports to verify that the SLOs are being met, or, if they aren’t, change processes so that the SLOs will be met.
More Info: Monitoring Service Level Objectives Using Operations Manager
You can learn more about monitoring service level objectives using Operations Manager at http://technet.microsoft.com/en-us/library/hh212753.aspx.
Application SLOs
Monitoring an application SLO with Operations Manager involves ensuring that availability and performance goals are being met. To define a SLO against an application, in this case the SQL Server 2012 database engine, which requires a SQL Server management pack, using Operations Manager, perform the following steps:
1. In the Authoring workspace of the Operations Manager console, click Service Level Tracking under Management Pack Objects.
2. On the ribbon, click Create.
3. On the General page of the Service Level Tracking Wizard, type the name SQL Server 2012 OpsMgr SLO.
4. On the Object To Track page, ensure that an unsealed management pack is selected, and then click Select.
5. On the Select A Target Class dialog box, click Distributed Application, and then click All. In the list of results, click SQL DB Engine, as shown in Figure 2-64, and then click OK.
FIGURE 2-64 Target class
6. On the Object To Track page, click a group or object that contains objects of the targeted class, and then click Select. On the Select An Object dialog box, select the SQL Server instance on the operations manager server that is of the class SQL 2012 DB Engine, as shown in Figure 2-65. This will ensure that the SLA only applies to this specific instance of the database engine.
FIGURE 2-65 Object selection
7. On the Service Level Objectives page, click Add, and then click Monitor State SLO. Monitor state SLOs allow you to track the availability of the application.
8. On the Service Level Objective (Monitor State) dialog box, provide a name for the objective, and list the states that qualify as downtime for the objective. The states that you select will be dependent on the agreement made between the stakeholders. Figure 2-66 shows a 99.99 percent service level objective goal where Unplanned Maintenance, Unmonitored, Monitoring Unavailable, and Monitoring Disabled count as downtime. Click OK.
FIGURE 2-66 SLO Monitor configuration
9. On the Service Level Objectives page, click Add, and then click Collection Rule SLO. Collection rule SLOs allow you to track the performance of the application.
Exam Tip
Remember the difference between Monitor State SLOs and Collection rule SLOs.
10. On the Service Level Objective (Collection Rule) dialog box, provide a name. Next to Performance Collection Rule, click Select. You can only select an existing performance collection rule. You can create rules from the Authoring workspace of the Operations Manager console. For example, if the SLO were about ensuring that the SQL Server DB engine never exceeded 90 percent processor utilization, you’d use a performance collection rule related to processor utilization.
11. On the Service Level Objective Goal drop down menu, select Less Than, and specify 90. This means that the engine should not exceed 90 percent processor utilization.
12. Complete the wizard.
More Info: Application SLOs
You can learn more about monitoring application related service level objectives using Operations Manager at http://technet.microsoft.com/en-us/library/hh212753.aspx.
Group SLOs
You can configure a SLO against a group of computers by monitoring the computer objects collectively. To create an SLO against a group of computers, perform the following tasks:
1. First create a group that contains the computers that you will monitor by clicking Create A New Group when the Groups node is selected in the Authoring workspace of the Operations Manager console.
2. On the General Properties page, enter a name for the group and specify an unsealed management pack in which to store the group settings.
3. On the Explicit Members page of the Create Group Wizard, click Add/Remove Objects. This will open the Object Selection dialog box.
4. On the Object Selection dialog box, enter the domain suffix, and click search. This will list all of the computers in a particular domain. You can use other search parameters as necessary. Add the Computer objects to the group. Figure 2-67 shows the computer objects for OpsMgr.tailspintoys.internal, Orchestrator.tailspintoys.internal, and SYD-DC.tailspintoys.internal.
FIGURE 2-67 Create group
5. Verify that the members that you want to monitor are members of the group, and complete the wizard.
6. In the Authoring workspace of the Operations Manager console, select Service Level Tracking under Management Pack Objects and on the ribbon, click Create.
7. Provide a name for the group SLO you are creating.
8. On the Objects To Track page, click Select.
9. On the Select A Target Class page, click Distributed Application, and click All. Type the name of the group that you created, and select that group, shown in Figure 2-68, and click OK.
FIGURE 2-68 Select a target class
10. On the Service Level Objectives page, click Add, and then click Monitor State SLO.
11. On the Service Level Objective (Monitor State) dialog box, provide the following information as shown in Figure 2-69.
Service Level Objective Name A name for the SLO.
Monitor In this scenario, this will be set to Availability.
Service Level Objective Goal The availability goal.
What counts as downtime Allows you to specify which states count as downtime towards measuring the SLO.
FIGURE 2-69 SLO Monitor State
12. Click OK and complete the wizard.
More Info: Group SLOs
You can learn more about monitoring group related service level objectives using Operations Manager at http://technet.microsoft.com/en-us/library/hh212877.aspx.
Service level tracking reports
Running a service level tracking report allows you to view how an application or group is performing in terms of the defined SLO. To create a service level tracking report, perform the following general steps:
1. In the Reporting workspace of the Operations Manager console, click the Microsoft Service Level Report Library under the Reporting node.
2. Click Service Level Tracking Summary Report, and click Open on the taskbar.
3. On the Service Level Tracking Summary Report dialog box, click Add, and click Search. The list of configured SLOs stored in the Operations Manager database will be listed as shown in Figure 2-70. Select the SLOs that you want to run the report on, and click Add.
FIGURE 2-70 Add Service Levels
4. On the Service Level Tracking Summary Report dialog box, specify the range that you want the report to encompass and the frequency that you want to use for data aggregation. Figure 2-71 shows a report that will be configured to be run over the last 24 hours using an hourly aggregation.
FIGURE 2-71 Report properties
5. Click Run, to run the Service Level Tracking Summary Report.
More Info: Service Level Tracking Reports
You can learn more about monitoring service level objectives using Operations Manager at http://technet.microsoft.com/en-us/library/hh212726.aspx.
Reports
Operations Manager leverages the functionality of SQL Server Reporting Services to provide comprehensive reporting functionality. Operations Manager ships with a large number of built-in reports. Importing management packs also adds to the available reports. Administrators can also create their own reports. Reports are available in the Reporting node. Figure 2-72 shows the reports in the Generic Report Library.
FIGURE 2-72 Generic Reports
The generic report library includes the following reports:
Alert Logging Latency Displays the logging latency of an alert for monitored objects over time.
Alerts Lists alerts raised during a specific duration for given filter parameters.
Availability Availability state for selected monitored objects.
Configuration Changes Changes in configuration for monitored objects over time.
Custom Configuration Configuration data filtered by specific parameters.
Custom Event Event data filtered by specific parameters.
Event Analysis Events and a count by monitored server filtered by specific parameters.
Health Health state for monitored objects based on overall entity health. Figure 2-73 shows a health report for three monitored computers over the last 24 hours.
FIGURE 2-73 Availability report
Most Common Alerts Most common alerts rose during report duration for given parameters.
Most Common Events Most common events rose during report duration for specific parameters.
Overrides Overrides applied to specific management packs over time.
Performance Performance counter values over time.
Performance Detail Detailed performance information over time.
Performance Top Instances Top or bottom set of instances for selected objects for a specific performance counter rule.
Performance Top Objects Top or bottom set of objects for selected objects for a specific performance counter rule.
More Info: Operations Manager Reports
You can learn more about reports in Operations Manager at http://technet.microsoft.com/en-us/library/hh212786.aspx.
Running reports
When running a report you’ll need to specify the report parameters. This includes specifying the objects you want the report run on, and the period that the report should recover. Other reports will require report specific parameters be configured.
For example, to run the generic Availability report for the last day, perform the following steps:
1. In the Reporting workspace of the Operations Manager console, expand the Reporting pane, click the Microsoft Generic Report Library node, and click the Availability Report.
2. On the ribbon, click Open.
3. On the Availability - Operations Manager - Report dialog box click Today under From, and then click Yesterday.
4. On the Availability - Operations Manager - Report dialog box, click Add Object.
5. On the Add Object dialog box, click Options. On the Options dialog box, click Add.
6. On the Add Class dialog box, type Computer, and click Search. Click Computer, and click Add, as shown in Figure 2-74, and click OK.
FIGURE 2-74 Computer class
7. On the Options dialog box, click OK, and on the Add Object dialog box, click Search.
8. A list of Computers that are monitored by Operations Manager will be displayed, as shown in Figure 2-75. Select the computers that you wish to generate the Availability Report for, and then click OK.
FIGURE 2-75 Add computer objects
9. In the list of Down Time items, select all of the options. Figure 2-76 shows an approximation of what this dialog box would look like if completed using these instructions for computers OpsMgr.tailspintoys.internal, Orchestrator.tailspintoys.internal, and SYD-DC.tailspintoys.internal.
FIGURE 2-76 Report properties
10. Click Run, to run the report. Figure 2-77 shows a sample of the report output.
FIGURE 2-77 Availability report
11. To view more detailed information about an individual computer’s availability, you can click the Availability Tracker hyperlink. This will generate a report similar to the one shown in Figure 2-78.
FIGURE 2-78 Detailed report information
12. You can save the report parameters by clicking Save To Favorites on the file menu once the report has run. When you do this, you provide a name for the report. Figure 2-79 shows the Save To Favorites dialog box.
FIGURE 2-79 Save To Favorites
More Info: Running Operations Manager Reports
You can learn more about running reports in Operations Manager at http://technet.microsoft.com/en-us/library/hh230683.aspx.
Scheduling reports
By scheduling reports, you can have reports periodically delivered through email or published to a file share. SQL Server’s report server also caches scheduled reports, making them quicker to access through the console. Prior to scheduling a report, you should create a template of the report that you wish to schedule and save it as a favorite report. If you want to email reports, you’ll need to create an email channel by specifying an SMTP server through the channel’s node, under notifications in the Administration workspace.
To create a scheduled report based on a report that has been saved as a favorite report, perform the following steps:
1. In the Reporting workspace of the Operations Manager console, click the Favorite Reports node, and then click the favorite report that you want to configure as a scheduled report.
2. On the Tasks menu, click Report, and then click Schedule.
3. On the Delivery Settings page, shown in Figure 2-80, specify the following information:
Description A description of the scheduled report.
Delivery Method How the report will be delivered. By default you can select a file share location, or, if configured, for the report to be emailed.
File Name The name associated with the report.
Path When using a network share, this will be the share that will host the report.
Render Format The format the report will be saved in. Options include Excel, HTML 4.0, Word, Data Feed, TIFF file, RPL Renderer, MHTML, PDF, Excel 2003, CSV, Word 2003, and XML file with report data.
Write Mode This determines whether the name of the report will be updated each time the report is run, whether any existing report will be overwritten, or if no report will be written if one already exists.
File Extension Determines if the appropriate file extension will be appended to the report name.
User Name and Password Credentials used to write the report to the shared folder.
FIGURE 2-80 Report subscription
4. On the Schedule page, shown in Figure 2-81, specify the report schedule. You can configure reports to be run once, hourly, daily, weekly, or monthly, as well as configuring how often each period the reports are generated.
FIGURE 2-81 Report schedule
5. On the Parameters page, you can review or alter the parameters of the report. For example, if you had a favorite report for availability that included four servers, but you wanted the scheduled report to only provide information on three, you could alter the parameters of the report to generate the desired report here. Figure 2-82 shows the parameters page of the Subscribe To A Report Wizard. Click Finish to create the report.
FIGURE 2-82 Report parameters
More Info: Scheduling Operations Manager Reports
You can learn more about scheduling reports in Operations Manager at http://technet.microsoft.com/en-us/library/hh230723.aspx.
Dashboards
Dashboards provide a method of quickly displaying relevant Operations Manager information by allowing you to present multiple types of data in a single view. Dashboards can be viewed using the Operations Manager console, or published to SharePoint.
When creating a dashboard, you can choose from one of the following templates, as shown in Figure 2-83:
Column Layout
Grid Layout
Service Level Dashboard
Summary Dashboard
FIGURE 2-83 Dashboard layout
Exam Tip
Remember the different types of template that you can use when creating a dashboard.
The service level dashboard allows you to display service level tracking information. The summary dashboard will display the top selected number of performance counters for chosen values. Column layouts consist of multiple columns. Grid layouts consist of multiple cells. Once you choose between a flow layout or a grid layout, you add widgets to the dashboard that display information. Operations Manager includes the following widgets:
State Allows you to view the state of monitored objects.
Performance Allows you to view performance metrics.
Alert Allows you to view alert information.
Details The properties of the item that is highlighted in the dashboard.
Instance Details Provides details of the instances related to the object.
Objects By Performance Performance counter data in tabular format for the selected object.
To create a grid layout dashboard view named Domain Controller Availability And Alerts in Operations Manager, perform the following tasks:
1. In the My Workspace view of the Operations Manager console, right-click New View, and then click Dashboard View.
2. On the Template page, click Grid Layout, and then click Next.
3. On the General Properties page, type the name Domain Controller Availability and Alerts, and click Next.
4. On the Layout page, click 2 Cells, and then click the layout on the left as shown in Figure 2-84, and click Next.
FIGURE 2-84 Dashboard cells
5. On the Summary page, click Create, and then click Close.
6. The new Dashboard will appear under the Favorite Views node. Click the new dashboard, in this case named Domain Controller Availability, and then click the text Click To Add Widget. This will open the New Dashboard And Widget Wizard. Click State Widget as shown in Figure 2-85, and click Next.
FIGURE 2-85 Dashboard widget
7. On the General Properties page, type Domain Controller State, and then click Next.
8. On the Scope page, click Add. On the Add Groups Or Objects dialog box, click Show All Objects And Groups. Type the domain suffix to limit the displayed items, and then navigate to the object that represents one of your organization’s domain controllers. Figure 2-86 shows SYD-DC.tailspintoys.internal selected. Click Add, and then click OK.
FIGURE 2-86 Add object
9. On the Scope page, verify that the domain controller computer object is listed.
10. On the Criteria page, select all of the available criteria except Display Only Objects In Maintenance Mode, as shown in Figure 2-87.
FIGURE 2-87 Dashboard criteria
11. On the Display page, select the Columns To Display, as shown in Figure 2-88, and then click Next.
FIGURE 2-88 Display configuration
12. On the Summary page, click Create, and then close.
13. With the Domain Controller Availability And Alerts node selected, click the Click To Add Widget text.
14. On the Select A Dashboard Layout Or Widget template page of the New Dashboard And Widget Wizard, click Alert Widget, as shown in Figure 2-89, and click Next.
FIGURE 2-89 Alert widget
15. On the General Properties page, type the name, Domain Controller Host Alerts, and click Next.
16. On the Select Group Or Object page, click the ellipsis button (...).
17. On the Select A Group Or Object dialog box, click Groups And Objects, and then type the domain name suffix, and click Search. Figure 2-90 shows the SYD-DC.tailspintoys.internal object, and the Health Service Watcher Class is selected. Click OK.
FIGURE 2-90 Health Service Watcher object
18. On the Criteria page, select the following check boxes as shown in Figure 2-91:
Display Alerts Only With The Specified Severities
Critical
Warning
FIGURE 2-91 Criteria selection
19. Review the options on the Display tab, and click Next. Then click Create, and click Close. The resultant dashboard will look similar to Figure 2-92.
FIGURE 2-92 Dashboard view
To be able to display a dashboard in SharePoint, you need to have installed the Operations Manager SharePoint Web Part on the SharePoint server. A user that has administrative permissions on the SharePoint server must install the Operations Manager SharePoint Web Part.
More Info: Operations Manager Dashboards
You can learn more about dashboards at http://blogs.technet.com/b/momteam/archive/2011/09/27/introducing-operations-manager-2012-dashboards.aspx.
Thought experiment: Performance dashboards at Contoso
You want to provide application administrators with dashboards, published on your organization’s SharePoint server that allows them to view performance counter data about services that you monitor in tabular format. With this information in mind, answer the following questions:
1. Which widget would you include in the dashboard to provide the appropriate information?
2. What steps must the SharePoint Administrator take before you can publish the dashboard to SharePoint?
Objective summary
You can use Operations Manager service level objectives (SLOs) to set availability and performance benchmarks.
You run service level tracking reports against SLOs to determine whether those availability and performance objectives have been met.
Operations Manager includes a number of built in reports that allow you to view the data collected by Operations Manager agents. Management packs contain additional reports.
Dashboards allow you to build “at-a-glance” summaries of important Operations Manager information. Dashboards can be published to SharePoint.
Objective review
Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of the chapter.
1. You want to perform service level tracking to verify the availability of your organization’s Exchange 2013 mailbox servers. You want to measure the availability of the virtual machines that host this role. Which of the following would you configure to accomplish this goal?
A. Windows Service synthetic transaction
B. Group SLO
C. Application SLO
D. Computer Group
2. Which of the following reports would you run to view figures for a group SLO used to measure the availability of a number of critical servers?
A. Availability
B. Service level tracking summary report
C. Overrides
D. Performance
3. You want to create a dashboard that provides performance and alert information for a group of computers. Which of the following widgets should you include when creating the dashboard?
A. State
B. Alert
C. Performance
D. Details
Answers
This section contains the solutions to the thought experiments and answers to the lesson review questions in this chapter.
Objective 2.1: Thought experiment
1. You must remove any management packs that have the management pack that you want to remove as a dependency.
2. An SNMP v3 Run As account includes User name, Context, Authentication Protocol, Authentication key, Privacy protocol, and Privacy key.
3. You use the MOMADAdmin.exe utility to configure automatic agent assignment.
Objective 2.1: Review
1. Correct answer: A
A. Correct: You must configure the Run As account with the SNMP v2 community string.
B. Incorrect: You do not have to configure the Run As account with the device name.
C. Incorrect: You do not have to configure the Run As account with the Device IP address.
D. Incorrect: You do not have to configure the Run As account with the Authentication key. This is only necessary with SNMP v3 Run As accounts.
2. Correct answers: A, B and D
A. Correct: For a domain joined computer to automatic connect to a management server, Active Directory must be configured.
B. Correct: This option will allow automatic agent installation, as long as Active Directory is configured and the other Global Management Server setting is configured.
C. Incorrect: This option, if configured, would not allow automatic agent installations.
D. Correct: You must configure the Review New Manual Agent Installations In Pending Management View before you can configure the Automatically Approve option.
3. Correct answer: A
A. Correct: You use MOMADAdmin.exe to configure Active Directory with management server settings.
B. Incorrect: Cmtrace.exe is a log file viewer usually used with Configuration Manager.
C. Incorrect: MOMagent.msi is used to manually install the Operations Manager agent.
D. Incorrect: Gpedit.msc is used to configure local Group Policy settings.
Objective 2.2: Thought experiment
1. You would configure Global Service Monitor to verify that the external web application is available to people around the world.
2. You would configure a distributed application model to monitor the disparate segments that make up the external web application.
3. You would configure Application Performance Monitoring to assess and monitor the performance of the web application.
Objective 2.2: Review
1. Correct answer: C
A. Incorrect: You use this type of synthetic transaction to verify that a service is running.
B. Incorrect: You use this type of synthetic transaction to verify that a TCP Port is available.
C. Correct: You can use this type of synthetic transaction to verify that an OLE DB compatible database is responding to remote queries.
D. Incorrect: You use this type of synthetic transaction to verify that a web application is responding to requests.
2. Correct answer: D
A. Incorrect: You use this type of synthetic transaction to verify that a TCP Port is available. While a TCP Port test would verify that a web server was present, you couldn’t use it to test the functionality of an application.
B. Incorrect: You use this type of synthetic transaction to verify that a service is running.
C. Incorrect: You use this type of synthetic transaction to verify that an OLE DB compatible database is responding to remote queries.
D. Correct: You use this type of synthetic transaction to verify that a web application is responding to requests.
3. Correct answer: D
A. Incorrect: You use this type of synthetic transaction to verify that an OLE DB compatible database is responding to remote queries.
B. Incorrect: You use this type of synthetic transaction to verify that a service is running.
C. Incorrect: You use this type of synthetic transaction to verify that a web application is responding to requests.
D. Correct: You use this type of synthetic transaction to verify that a TCP Port, such as port 25 on an SMTP smart host, is available.
Objective 2.3: Thought experiment
1. You would select the Object By Performance as this presents performance counter data in tabular format.
2. To be able to display a dashboard in SharePoint, you need to have installed the Operations Manager SharePoint Web Part on the SharePoint server.
Objective 2.3: Review
1. Correct answer: B and D
A. Incorrect: You want to measure the availability of a group of computers.
B. Correct: You should use a group SLO to measure the availability of a group of computers.
C. Incorrect: You use an application SLO to measure the availability of an application or service.
D. Correct: You must add the computers that you want to monitor to an Operations Manager group before you’ll be able to configure a group SLO.
2. Correct answer: B
A. Incorrect: While an availability report will provide availability information, it won’t provide information in terms of a specific service level benchmark.
B. Correct: The service level tracking summary report allows you to view information on an existing SLO.
C. Incorrect: The overrides report provides information on configured overrides.
D. Incorrect: The Performance report provides performance information, but does not measure this data against a specific service level benchmark.
3. Correct answers: B and C
A. Incorrect: The State widget allows you to view state information about a monitored object.
B. Correct: The alert object provides Alert information.
C. Correct: The performance widget provides performance information.
D. Incorrect: The details widget provides details of the instances related to an object.