Known Issues and Troubleshooting

Applies To: Operations Manager 2007

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

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.

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.

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

You may observe that the clustered Mailbox server is missing properties such as DNS name and Active Directory site. A probable cause is that Windows computer discovery for the clustered virtual server has not completed successfully. Check the properties of the Windows computer that matches your Exchange Mailbox server’s name in Operations Manager and ensure the Active Directory site and DNS name are correctly discovered on the Windows computer object. Knowledge Base article 951380, Some computer properties for a cluster node may not be collected by the discovery process in System Center Operations Manager 2007 Service Pack 1 (https://go.microsoft.com/fwlink/?LinkId=169320) may be required to fix this issue.

It is also possible 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. You may observe that the clustered Mailbox server is missing properties such as DNS name and Active Directory site. 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.