This documentation is archived and is not being maintained.

Configuring Security for Operations Manager Integration and PRO in VMM

Updated: September 11, 2009

Applies To: Virtual Machine Manager 2008, Virtual Machine Manager 2008 R2, Virtual Machine Manager 2008 R2 SP1

This topic provides security guidance for integrating Operations Manager 2007 with System Center Virtual Machine Manager (VMM) 2008. To support Performance and Resource Optimization (PRO) in VMM, VMM requires tight integration with Operations Manager. Operations Manager also provides reporting for VMM.

Domain Requirements for Operations Manager Integration

To be integrated successfully with VMM, the Operations Manager deployment must meet the following requirements in Active Directory Domain Services (AD DS):

  • Operations Manager must be deployed in an Active Directory domain that has a two-way trust relationship with the domain that contains the VMM server. The integration requires Kerberos authentication between VMM and the Operations Manager management servers. Because of differences in the way that the two products handle Kerberos authentication, authentication issues can prevent successful enabling of PRO when the Operations Manager management servers are not in a trusted domain.

  • Each time the OpsMgr SDK service (known in Operations Manager 2007 R2 as the System Center Data Access service) starts on your Operations Manager root management server, the service must be able to register Service Principle Names (SPNs) for itself in Active Directory Domain Services (AD DS). If the SDK service runs as Local System, the account has the needed permissions to read and write the SPNs, and you don’t need to update any configurations. However, if you are using an Active Directory domain account as the run-as account for the service, either you must manually register the SPNs for the root management server or you must grant the SDK service account the permissions needed to read and write the SPNs when the service starts.

    The following procedures explain both methods for doing this.

To register SPNs for the root management server manually

  • At a command prompt on a domain-joined computer, running under an account that has Write SPN permission, run the following commands to create an SPN for the fully qualified domain name (FQDN) and the NetBIOS name of the root management server. If the root management server is in a cluster, use the virtual server name.

    SetSPN.exe –A MSOMSdkSvc/<RootManagementServerFQDN>  <domain>\<SDKServiceAccount>
    SetSPN.exe –A MSOMSdkSvc/<RootManagementServerNetBIOS>  <domain>\<SDKServiceAccount>
The Setspn tool is installed automatically with Windows Server 2008. For Windows Server 2003–based computers, you can install the tool with the Windows Server 2003 Support Tools from the product CD or from the Microsoft Download Center ( Setspn can be used with all releases of Windows Server 2003 and with Windows Server 2008 and later. For more information about how to install Windows Support Tools from the product CD, see Install Windows Support Tools (

To grant the SDK service account permission to read and write the SPNs

  1. On the domain controller, open ADSIEdit.msc.

  2. Navigate to your SDK service account. Right-click the account, and click Properties.

    • On an Operations Manager 2007 SP1 server, update the service account for the OpsMgr SDK service.

    • On an Operations Manager 2007 R2 server, update the service account for the System Center Data Access service.

  3. On the Security tab, click Advanced, click Add, type SELF, and then click OK.

  4. On the Properties tab, in the Apply Onto list, select This object only.

  5. In the properties list, scroll to Read servicePrincipleName and Write servicePrincipleName, and select Allow for each of them.

  6. After saving the new permissions, restart the Operations Manager SDK service (in Operations Manager 2007 SP1, the OpsMgr SDK service; in Operations Manager 2007 R2, the System Center Data Access Service) on the root management server.

To help enhance security, grant the most restrictive access permissions that you can. Although a domain administrator account can perform these actions by default, it is recommended that you do not use a domain administrator account for the Operations Manager SDK service account.

Configuring Security for PRO

This section describes the implementation of PRO, the connections used for PRO communications, account requirements in both Operations Manager and VMM, and the use of Windows PowerShell scripts to perform remedial actions for PRO tips.

How PRO Is Implemented

Performance and Resource Optimization (PRO) leverages performance and health monitoring in Operations Manager 2007 to implement remedial actions on the VMM server to return hosts, virtual machines, or other software or hardware in a virtualized environment to a healthy and optimized state.

PRO is implemented through specially designed PRO-enabled management packs that define PRO target classes and groups and provide monitors that collect data about virtual machines, hosts, applications, and hardware to identify opportunities to optimize a virtualized environment. Any Operations Manager alert that targets a PRO class generates a PRO tip in VMM. The definitions of the PRO tips can include remedial actions to return the virtualized environment to a healthy state. PRO remedial actions can be configured for automatic or manual implementation.

The VMM 2008 Management Pack, which provides basic PRO functionality, is installed during VMM setup by the Configure Operations Manager option. In addition to installing the management pack, the setup wizard performs other required configuration tasks for integrating Operations Manager with VMM.

Connections for PRO

For communications with Operations Manager, VMM uses a software-based connection to the Operations Manager root management server. This connection leverages the Operations Manager SDK to connect to and communicate with the Operations Manager Management Group. This is the same SDK that the Operation Manager console uses to connect to and communicate with the Operations Manager management servers. The underlying communications protocol for the Operations Manager SDK is based on Windows Communication Foundation (WCF).

VMM uses this connection for the following communications:

  • Run discoveries for managed hosts and virtual machines.

  • Retrieve and manipulate Operations Manager alerts that target PRO classes. Those alerts are PRO tips in VMM.

  • Initiate Operations Manager recoveries, which initiate PRO remediations, such as migrating a virtual machine.

Account Requirements for VMM and Operations Manager Integration

To support PRO, the VMM service account must be an administrator in Operations Manager, and the action account on each Operations Manager management server must be a member of the Administrator user role.

VMM Service Account

VMM connects to the Operations Manager server as the VMM service account. The service account can be either Local System or an Active Directory domain account with administrative rights in Operations Manager. The service account is specified during VMM server installation. To provide the VMM server access to the Operations Manager server, the Configure Operations Manager option of the Setup Wizard adds that account to the local Administrators group on the Operations Manager root management server. This level of access must be maintained to ensure VMM and Operations Manager can continue to communicate.

By default, the Operations Manager Administrator role is populated by the accounts in the local Administrators group. Therefore, adding the account to that group provides the administrator rights that VMM requires. However, the local group that populates the Administrator role is a configurable option in Operations Manager. If a different local group has been specified for this purpose, you must add the VMM service account to that group manually.

This is only required on your root management server. The VMM service account need not be an Operations Manager administrator on other management servers.

Action Accounts on Management Servers

To provide the credentials to perform PRO remedial actions in VMM, the Management Server action account on each of your Operations Manager management servers must be a member of the Administrator role in VMM.

The action account can be the Local System account, or it can be an Active Directory domain account that has administrative rights on the management server. You do not need to use the same action account on all of your management servers.

To make the account a VMM administrator, add it to the Administrator role in VMM. User roles are configured in the User Roles node of Administration view of the VMM Administrator Console. For a procedure, see Configuring Operations Manager Integration with VMM (

Enabling Remote Running of PRO Scripts

Many PRO tips include a remedial action that can be implemented automatically or manually to return a host or virtual machine to a healthy state. For example, if a host exceeds a CPU threshold, the remedial action might migrate the virtual machine with the highest CPU usage to a different host by using automatic placement in VMM.

PRO remedial actions run a script that connects to VMM by using the Windows PowerShell – Virtual Machine Manager command shell on the VMM server. The location where the script runs depends on the type of host VMM is managing:

  • For Hyper-V and Virtual Server hosts, the script runs on the Operations Manager management server that is managing the Operations Manager agent on the host or virtual machine.

    Each script connects to the VMM server that is managing the host or virtual machine to perform the appropriate remedial actions in VMM.

    To enable the PRO remedial actions, you must enable remote running of scripts in the Windows PowerShell – Virtual Machine Manager command shell on each of the Operations Manager management servers.

  • For a managed VMware environment, the script runs on the VMM server. In a managed VMware environment, Operations Manager agents are not required on the VirtualCenter Server or the ESX Server hosts. Instead, VMM manages the VMware environment remotely through the VirtualCenter server’s Web Service API. For this reason, the scripts for remedial actions run locally on the VMM server.

    Although no Operations Manager agents are required on ESX Server hosts, to monitor the guest computers you must install Operations Manager agents on the guest operating systems of the virtual machines on the hosts.

Configuring Security for Reporting

For reporting, VMM leverages the reporting engine for Operations Manager 2007. VMM reports are generated by the Operations Manager reporting server but are available in Reporting view of the VMM Administrator Console.

Connections for Reporting

The VMM Administrator Console connects directly to the SQL Reporting Services Web Services interface to generate the list of available reports in Reporting view of the VMM Administrator Console and to generate reports based on parameters that the VMM administrator enters. For these communications, VMM uses the HTTP protocol over default port 80. The URL, including the port of the Reporting Server, is specified in global settings for VMM. For more information, in VMM 2008 Help, see How to Specify the Reporting Server for VMM (

For more information about connections in Operations Manager 2007, see Authentication and Data Encryption for Windows Computers in Operations Manager 2007 (

Account Requirements for Reporting

By selecting a report, the VMM administrator opens a session with SQL Server Reporting Services on the Operations Manager reporting server. Therefore, authorization for VMM reports occurs in Operations Manager, through its user roles.

To enable VMM administrators to view and run reports in Reporting view, you must add their domain accounts to the Report Operators role in Operations Manager. For instructions, see How to Add Users or Groups to the Report Operator User Role in Operations Manager 2007 (

Add only trusted administrators to Report Operators user role. Role members have access to all report data in the Reporting Data Warehouse and are not limited by scope.

See Also