Optional Configurations

Topic Last Modified: 2012-11-26

The Microsoft Exchange Server 2010 Monitoring Management Pack has been deployed at Microsoft for more than two years in a wide range of environments. These deployments have helped us make significant improvements to the Management Pack. They've also helped us improve the overall monitoring capability of Exchange Server 2010.

The Monitoring Management Pack works effectively in most Exchange configurations by using the default configuration. Although some fine-tuning may be required for certain environments, the Exchange 2010 Monitoring Management Pack discovery process generally loads the correct monitors on the various servers in an Exchange organization. For example, performance threshold rules are based on scalable calculations and not on fixed-digit thresholds.

In the Exchange 2010 Monitoring Management Pack, you’ll find a number of rate and percentile counters that are designed to let the Management Pack scale from small deployments to large datacenter environments.

Create Test Mailboxes for Synthetic Transaction Tests

The Exchange 2010 Monitoring Management Pack can run synthetic transactions to help you measure the performance of monitored objects in your Exchange organization. The Exchange 2010 Monitoring Management Pack uses the Test-OwaConnectivity, Test-ActiveSyncConnectivity, and Test-WebServicesConnectivity cmdlets to test Microsoft Office Outlook Web App, Exchange ActiveSync, and Exchange Web Services connectivity from Client Access servers to Mailbox servers. These cmdlets require that a test mailbox be created in each Active Directory site that you want to test. For more information about synthetic transactions, see Monitoring by Using Synthetic Transactions in the System Center Operations Manager 2007 R2 documentation.

Warning

If you don't create a test mailbox on one or more Mailbox servers, the Management Pack will return the following warning: “The test mailbox was not initialized. Run new-TestCasConnectivityUser.ps1 to ensure that the test mailbox is created.” Perform the following steps to create a test mailbox for Outlook Web App, Exchange ActiveSync, and Exchange Web Services connectivity monitoring.

In this procedure you create test mailboxes for Outlook Web App, Exchange ActiveSync, and Exchange Web Services to monitor connectivity by using PowerShell to run the New-TestCasConnectivityUser.ps1 script.

  1. Open the Exchange Management Shell.

  2. In the Shell, change directory to the C:\ Program Files\Microsoft\Exchange Server\V14\Scripts folder by running the following command:

    Set-Location C:\Program Files\Microsoft\Exchange Server\V14\Scripts

  3. Run the test-user script using the following command:

    New-TestCasConnectivityUser.ps1

  4. Follow the on-screen installation instructions in the Shell to create the test mailbox. You'll be prompted to enter a temporary secure password for creating test users. You'll also be prompted to specify the Mailbox server where you want the test user created.

  5. Repeat this process on an Exchange 2010 Mailbox server in each Active Directory site that you want to test.

Create test mailboxes for synthetic transaction tests when operating in a split permissions model

  1. Use an account that has domain administrator credentials to add Exchange Trusted Subsystem as a member of the Exchange Windows Permissions security group.

  2. Use an account that has domain administrator credentials to create an organizational unit that will contain your synthetic transaction mailboxes.

  3. Use an account that has domain administrator credentials to grant the Exchange Windows Permissions security group the permissions that are required for the organizational unit. To do this, follow these steps:

    1. Open a local PowerShell session.

    2. To add the Exchange 2010 PSS Snap-in, type the following PowerShell cmdlet, and then press Enter: add-pssnapin Microsoft.exchange.management.powershell.E2010

    3. Copy the following script to a text file and then save the file with the name perms.ps1.

      Param([string] $OUDN)
      if ($OUDN -eq "") {"Usage: perms.ps1 <OU distinguished name>"; return}
      
      Add-ADPermission $OUDN -user "Exchange Windows Permissions" -Properties "WWW-Home-Page","Managed-By","SAM-Account-Name","Member","User-Account-Control","Pwd-Last-Set","Country-Code" -AccessRights "WriteProperty" -InheritanceType All
      
      Add-ADPermission $OUDN -user "Exchange Windows Permissions" -AccessRights "ExtendedRight" -ExtendedRights "User-Change-Password" -InheritedObjectType User
      
      Add-ADPermission $OUDN -user "Exchange Windows Permissions" -AccessRights "ExtendedRight" -ExtendedRights "User-Force-Change-Password" -InheritanceType All -InheritedObjectType User
      
      Add-ADPermission $OUDN -user "Exchange Windows Permissions" -AccessRights 'WriteDacl, DeleteTree' -InheritedObjectType User  -InheritanceType All
      
      Add-ADPermission $OUDN -user "Exchange Windows Permissions" -AccessRights 'CreateChild', 'DeleteChild' -ChildObjectTypes User -InheritanceType All
      
    4. Type the following PowerShell cmdlet, and then press Enter: perms.ps1 “ou=<Organizational_Unit_Name>,dc=<Domain_Name>” where <Organizational_Unit_Name> and <Domain_Name> are replaced with the appropriate values.

  4. Repeat Steps 2 to 3 for each domain in the environment that contains Exchange 2010 servers.

  5. Use an account that has Exchange Organization Management credentials to start the Exchange 2010 Remote Powershell.

    Type the following cmdlet, and the press Enter: New-RoleGroup -Name "SCOM SynTran Mailbox Creators" -Roles "Mail Recipient Creation" -RecipientOrganizationalUnitScope "<FQDN_Of_Your_Domain>/<Organizational_Object_Name>" where <FQDN_Of_Your_Domain> and <Organizational_Object_Name> are replaced with the appropriate values.

  6. Add the members that you want to the SCOM SynTran Mailbox Creators security group.

  7. Wait for Active Directory replication to complete.

  8. Log off and then log back on to reset the security token of the user object if you are currently logged on a user that was added to the group in step 6.

  9. In PowerShell, type the following command, and then press Enter: new-TestCasConnectivityUser –OU <Organizational_Unit>

Disable the Automatic Alert Resolution Feature in the Correlation Engine

The Automatic Alert Resolution feature automatically closes related alerts when the Exchange 2010 Monitoring Management Pack determines that the underlying issue is no longer a problem. This feature is provided by the Correlation Engine, and is enabled by default. Using Automatic Alert Resolution can cause multiple alerts to be logged if the same alert is logged again for another instance of the problem before the associated ticket has been resolved by support teams.

You may also want to disable this feature under the following or other conditions:

  • If you're using ticketing or another support system that wouldn't work correctly if alerts are automatically resolved.

  • If you're using a connector with Operations Manager 2007. A connector is a custom service or program that allows Operations Manager to communicate with external systems. For example, you may want to disable this feature if you're using a connector that allows an external application to track Exchange 2010 Monitoring Management Pack alerts.

To disable Automatic Alert Resolution, perform the following steps:

  1. Log on to the server that's hosting the Microsoft Exchange Monitoring Correlation Engine service.

  2. Locate the Correlation Engine configuration file named Microsoft.Exchange.Monitoring.CorrelationEngine.exe.config. By default, the file is located in C:\Program Files\Microsoft\Exchange Server\V14\Bin\, where C:\ is the Exchange installation directory.

  3. Open Microsoft.Exchange.Monitoring.CorrelationEngine.exe.config in a text editor such as Notepad.

  4. Locate the following line in the configuration file:

    <add key="AutoResolveAlerts" value="true" />
    
  5. Change <add key="AutoResolveAlerts" value="true" /> to <add key="AutoResolveAlerts" value="false" />

  6. Restart the Microsoft Exchange Monitoring Correlation Engine service.

Enable Event Collection for Synthetic Transaction Rules

The Exchange 2010 Monitoring Management Pack uses synthetic transactions, for example, running the Test-MapiConnectivity, Test-OwaConnectivity, and other commands, to scan your Exchange organization for basic connection responses and to test simple operations such as signing in to a mailbox. Whether these tests succeed or fail, their output is useful for investigating the state of the Exchange environment. However, because there is a large amount of output for each task, the event output isn't stored by default. The views for these tests in the Operations Console are populated if you enable the event collection rules for each respective test. For more information about synthetic transactions, see Monitoring by Using Synthetic Transactions in the System Center Operations Manager 2007 R2 documentation.

Warning

When you enable these collection rules, make sure you have sufficient disk space to accommodate the additional data. Each task creates from 4 to 12 event messages every time it runs. By default, each test runs every five minutes. To enable the event collection rules for synthetic transaction output:

  1. In System Center Operations Manager 2007, click Authoring.

  2. In the Authoring pane, expand Management Pack Objects, and then click Rules.

  3. In the Rules pane, click Change Scope.

  4. In the Scope Management Pack Target(s) by object dialog box, in the Look for box, type "Exchange Server 2010."

  5. Click View all targets.

  6. Click Select All if it’s not disabled (it is only disabled when all rows are already selected).

  7. Click OK to close the dialog box.

  8. After the rules have loaded, type "Script event collection" in the Look for box near the top of the console.

  9. For each test task that you would like to enable, perform the following steps:

    1. Right-click the rule and select Overrides > Override the Rule > For all objects of class: <class name>.

    2. Select the Override check box.

    3. Set the override value to True.

    4. Click OK.

    It will take some time for the overrides to be picked up by the agents and for events to appear in the built-in views.

Enable an Optional Monitor If You're Using Kerberos Authentication with a Client Access Server Array

If your organization is using Kerberos authentication with a Client Access server array, you'll need to manage the shared alternate service account credential password. Exchange 2010 Service Pack 1 contains a management script that helps automate the distribution and updating of the alternate service account credential (ASA credential) to all Client Access servers within the scope of the script. For more information about this script, see Configuring Kerberos Authentication for Load-Balanced Client Access Servers.

If you're using the RollAlternateServiceAccountPassword.ps1 script to perform regular password maintenance, the Exchange 2010 Monitoring Management Pack includes two monitors to help you make sure that the script is running correctly. The following two monitors are only helpful if you're relying on the script to perform regular password maintenance and you have the script running as a scheduled task.

  • The powershell script rolling out alternate service account password for CAS array Kerberos authentication has failed - RollAlternateServiceAccountPassword.ps1   This monitor is enabled by default. The alert for this monitor is logged when the script fails. This monitor detects script failures by watching for failure event IDs in Application and Services Logs.

  • Kerberos Authentication for CAS array - shared alternate service account credential password for Kerberos authentication has not been updated in 28 days and may be stale   This monitor isn't enabled by default because most Exchange deployments don't use a shared ASA credential and therefore don't need to run the RollAlternateServiceAccountCredential.ps1 script as a scheduled task. The alert for this monitor will fire if it doesn't detect that the script has been successfully run in the past 28 days. The alert reminds you to check the credential to make sure it won't expire and cause a Kerberos authentication outage.

    This monitor detects whether the script has been running by monitoring the Application and Services Logs on the computer that is running the scheduled task. This alert can be logged, for example, when the user name and password that are being used to run the scheduled task need to be updated. This monitor must be enabled for the specific Client Access server computer that's running the scheduled task.

    Note

    This monitor is internal, and it can’t be modified for customer environments.

To enable this monitor, use the following steps:

  1. In System Center Operations Manager 2007, click Authoring.

  2. In the Authoring pane, expand Management Pack Objects, and then click Monitors.

  3. On the toolbar, click Scope.

  4. In the Scope Management Pack Target(s) by object dialog box, in the Look for box, type "Outlook Service Availability."

  5. Click View all targets.

  6. Click Select All if it’s not disabled (it's only disabled when all rows are already selected).

  7. Click OK to close the dialog box.

  8. After the rules have loaded, click Outlook Service Availability > Entity Health > Availability.

  9. Under Availability, right-click the rule Kerberos Authentication for CAS array - shared alternate service account credential password for Kerberos authentication has not been updated in 28 days and may be stale, and then click Overrides > Override the Monitor > For a specific objects of type: Outlook Service Availability.

  10. In the Select Object dialog box, select the instance of the rule that includes the server on which you're running the RollAlternateServiceAccountPassword.ps1 script, and then click OK.

  11. In the Override Properties dialog box, select the Override check box.

  12. Under Management pack, select the destination management pack.

  13. Set the override value to True.

  14. Click OK.

It will take some time for the overrides to be picked up by the agents and for events to appear in the built-in views.