Known Issues and Troubleshooting

Applies To: Exchange Server, Operations Manager 2007 R2

This section lists the known issues in this management pack and also provides some troubleshooting information.

Test-OwaConnectivity May Fail When Domain Controllers Are Running Windows 2000 Server

The Test-OwaConnectivity cmdlet over CAS Servers may fail if you have any domain controllers running Windows 2000 Server in your Active Directory, with the following error:

Unable to obtain Test-OwaConnectivity result - The test mailbox was not initialized. Run new-TestCasConnectivityUser.ps1 to ensure that the test mailbox is created. Then run Test-ActiveSyncConnectivity ?ResetTestAccountCredentials under a system account to store this user's credentials for use in testing the Client Access services. More information: Mailbox Server:MailboxFQDNName [Microsoft.Exchange.Monitoring.CasHealthUserNotFoundException]: UserPrincipalName: CAS_XXXXXXXXXXX@smtpaddress.com is not found in Active Directory. Additional error information: [System.Security.SecurityException]: The Kerberos subsystem encountered an error. A service for user protocol request was made against a domain controller which does not support service for user.

This error appears because at the time that the cmdlet is executed, the Exchange 2007 CAS Server is using a domain controller running Windows 2000 Server as the Kerberos Key Distribution Center (KDC) server and this operation is using a Kerberos extension not supported in Windows 2000 Server.

To avoid this issue, you must force the Exchange servers to use a higher version domain controller as the KDC server by running the following command:

NLTest /dsgetdc:grupo.cm.es / KDC  /DS_6 /FORCE

Four Reports Do Not Export Data to CSV Format

The following four reports do not support exporting data to CSV format:

• Exchange 2007 SMTP Messages Sent

• Exchange 2007 SMTP Messages Received

• Exchange 2007 Mailbox Messages Sent

• Exchange 2007 Mailbox Messages Delivered

No Exchange 2007 Servers Are Discovered

You will need to enable the Server Role discovery scripts in order for the servers to be discovered. Depending on your preferences, you might also want to change the interval at which the discovery scripts run. By default, they run every 24 hours.

If you are using a low-privilege action account, ensure that you have populated the Run As profiles with the appropriate accounts, because some of the discoveries require higher privileges and use the Run As profiles defined by the management pack. It might take up to 24 hours from the time you populate the Run As account for the servers to be discovered. A way to work around this is to first import only the Library Management Pack and populate the Run As accounts and then import the other Exchange Server 2007 management packs.

The Exchange 2007 Topology Does Not Show Up

Discoveries of the organization, site, and site service components are done by the Exchange 2007 server roles. Ensure that your server roles are successfully discovered by selecting the Exchange 2007 Server State view. All agent-managed Exchange servers should show up in that view.

If these are discovered, it might take another 24 hours for the organization, site, and site service components to be discovered, because those discoveries run every 24 hours.

Verify that agent proxy is enabled on the Exchange servers.

To verify that agent proxy is enabled on managed Exchange 2007 servers

1. Click the Administration button in the Operations console, and then, in the navigation pane, click Agent Managed.

2. In the Agent Managed pane, right-click an Exchange server, click Properties, click the Security tab, and ensure that the Allow this agent to act as a proxy and discover managed objects on other computers check box is selected.

Client Access Server Site Services are Not Monitored

Client Access Server Site Services (such as the Outlook Web Access Service) will by default have a state of “Not Monitored”. Client Access Server Site Services reflect the health of Client Access server synthetic transactions only, and by default no such transactions are defined. You can resolve the “Not Monitored” state by setting up synthetic transactions to test Client Access server availability.

Duplication of Alerts Might Occur If You Co-locate Exchange 2007 Server Roles

If you co-locate several Exchange 2007 server roles (such as Mailbox and Client Access server roles) on the same server, there will be some duplication of alerts generated from both server roles—for example, from service monitors. Disk monitors will also generate duplicate alerts if you store transport queue, mailbox message database (MDB), and mailbox log files on the same logical disk.

Health Does Not Roll Up from Cluster Continuous Replication (CCR) Node Roles to the CCR Clustered Mailbox Role

Health will not roll up from the cluster continuous replication (CCR) node roles (the physical nodes making up the cluster) to the CCR clustered mailbox role (the clustered Mailbox server).

Health Does Not Roll Up From the Client Access Synthetic Transaction to the Mailbox Server

The health state of a Client Access synthetic transaction rolls up to the source server not to the target Mailbox server.

For example, if a Client Access synthetic transaction fails, the Health Explorer shows that the red health state of the synthetic transaction rolls up to the source server where the synthetic transaction originated.

The health state of the target Mailbox server is not affected by the failed synthetic transaction; the health state of the target Mailbox server remains in the green (healthy) state.

Synthetic Transactions that Run Against Network Load Balanced (NLB) URLs Might Return Health State for the Wrong Server

If you run synthetic transactions against Client Access servers that are configured against network load balanced (NLB) URLs, the health state reported might not reflect the actual health state of the server running the synthetic transaction. This can occur when the NLB reroutes the transaction to a different Client Access server in the NLB array. In this case, the health state returned is the health state of the other server.

Accuracy of the Service Level Objective Reports

When you run synthetic transactions at the 5-minute minimum recommended interval, the accuracy of service level objectives is measured to three significant figures, not five significant figures as indicated by the service level objective.

You May need to Override the Agent Restart Thresholds

The Operations Manager 2007 Management Pack tracks memory usage and handle count of the MonitoringHost.exe process. By default, the agent will be restarted automatically if memory usage for MonitoringHost.exe is above 100MB or handle count is above 2,000. On large Exchange 2007 systems, these thresholds may be too low. This management pack sets the thresholds to 600MB and 5000 handles. See Appendix: Overrides Enabled by Default. On very large Exchange 2007 systems, you may need to further increase these thresholds.

Conditions that Generate More Than 50 Alerts Per Minute Might Cause a Temporary Suspension of All Alerts

Any condition that generates more than 50 alerts per minute can trigger a temporary suspension of all alerts. For example, if there are 50 databases on an Exchange 2007 server, and the database store is offline for any reason, a unit monitor such as Test-MapiConnectivity will immediately generate one alert for each database. This results in 50 alerts generated within a minute, and can trigger an alerts blackout for 10 minutes.

The First Time Synthetic Transactions Run, You Might Receive Alerts and Error Health States

When you run synthetic transactions for the first time, initial latencies associated with loading data from Active Directory and making connections to new servers might exceed threshold values and result in alerts and error health states on the perspective and on the hosting Exchange 2007 server.

After the initial run, the information from Active Directory and about the server connections is cached so that subsequent synthetic transactions are completed under the threshold.

For synthetic transactions that are run less frequently, however, you might continue to experience this problem. If the interval between successive synthetic transactions has been long enough, the Exchange 2007 server might remove the data from the cache, causing the same latency problem as when you first ran the synthetic transaction. If this is the case, consider increasing the threshold for these synthetic transactions.

The First Time Synthetic Transactions Run, You Might See an Error Message About “Connection Cache Size”

When you set up multiple synthetic transactions on a Client Access server, you might see an error message similar to the one below when you run the synthetic transactions for the first time. The message is raised as an alert. When the synthetic transactions run again, if they are successful, you can safely ignore the original alert. If you should receive this error message again, you can adjust the Test Frequency and Time-out values for the synthetic transaction.

System.Management.Automation.CmdletInvocationException: The connection cache size can only be set once.At line:121 char:40+ $PopConnectivity = Test-PopConnectivity <<<< -MailboxServer:$MailboxServer -MonitoringContext:$true -ConnectionType:2 -TrustAnySSLCertificate:$TrustAnySSLCertificateBool -LightMode:$true -Timeout:$Timeout -PerConnectionTimeOut:$PerConnectionTimeOut -ResetTestAccountCredentials:$false at System.Management.Automation.Internal.PipelineProcessor.SynchronousExecuteEnumerate(Object input, Hashtable errorResults, Boolean enumerate) at System.Management.Automation.Parser.PipelineNode.Execute(Array input, Pipe outputPipe, ArrayList& resultList) at System.Management.Automation.Parser.PipelineNode.Execute(Array input, Pipe outputPipe) at System.Management.Automation.Parser.AssignmentStatementNode.Execute(Array input, Pipe outputPipe) at System.Management.Automation.Parser.StatementListNode.Execute(Array input, Pipe outputPipe, ArrayList& resultList)

The Clustered Mailbox Server is Missing Properties and Does Not Appear in the Configuration Templates

You may observe that the clustered Mailbox server is missing properties such as DNS Name and Active Directory Site. In addition, the clustered Mailbox server might not appear as a source or target server in the Mail Flow or Client Access server templates. A probable cause is that the Exchange 2007 CCR Clustered Mailbox Server Role Discovery is not enabled for the Discovery Helper instances representing the clustered Mailbox server, that is, the virtual server. To resolve this issue, ensure that the Exchange 2007 CCR Clustered Mailbox Server Role Discovery is enabled for clustered Mailbox server instances of Discovery Helper. If you are using a group of Windows-based computers to override the discovery, ensure that the computer objects representing the clustered mailbox server are part of that group.