Synthetic Transactions in the Management Pack
Applies To: Exchange Server, Operations Manager 2007 R2
This management pack improves the support for the Exchange 2007 synthetic transactions in a number of ways:
The synthetic transactions are more flexible because they run against the appropriate class. For example, test-mapiconnectivity measures database connectivity latency and the availability of each mailbox database on a Mailbox server by default. Because this transaction runs against the database class, the administrator can configure the databases to be monitored on each Exchange Mailbox server in a granular way.
The synthetic transactions instances can be represented in custom distributed applications.
This section lists the Exchange Server 2007 synthetic transactions in the management pack, how often they run, and where they run. Note that in some cases the synthetic transaction is not enabled by default. There are performance views that show the latencies recorded by the synthetic transaction.
Note
You can override the frequency of the synthetic transactions, if required in your environment.
| Transaction name | Enabled | Purpose | Target | Frequency (minutes) |
|---|---|---|---|---|
Yes |
Test availability and response time of each mailbox database on a Mailbox server. |
Exchange 2007 Mailbox Database |
10 |
|
Yes (local) |
Test the ability to send mail to itself or another Mailbox server. The cmdlet waits for a delivery receipt and records availability and response times. |
Exchange 2007 Mailbox Role |
15 (local), 30 (remote) |
|
Yes |
Use the Test-SystemHealth cmdlet to gather data about your Microsoft Exchange system and to analyze the data according to best practices (Exchange BPA). |
All Server Roles except CCR Node and Edge |
1440 (daily) |
|
No |
The Test-ActiveSyncConnectivity cmdlet lets you perform a full synchronization against a specified mailbox to test the configuration of Microsoft Exchange ActiveSync. |
Client Access Server |
15 |
|
No |
Use the Test-OwaConnectivity cmdlet to verify that Microsoft Office Outlook Web Access (OWA) is running as expected. The Test-OwaConnectivity cmdlet can be used to test OWA connectivity for Microsoft Exchange 2007 Client Access servers to Exchange 2007 Mailbox servers that are in the same Active Directory site. Test-OwaConnectivity can also be used to test the connectivity for an individual Exchange 2007 OWA URL. |
Client Access Server |
15 (internal and external) |
|
No |
Use the Test-ImapConnectivity cmdlet to verify that the IMAP4 service is running as expected. The Test-ImapConnectivity cmdlet can be used to test the IMAP4 functionality for a specified Client Access server to selected Exchange 2007 Mailbox servers in the same Active Directory site. |
Client Access Server |
15 |
|
No |
Use the Test-PopConnectivity cmdlet to verify that the POP3 service is running as expected. The Test-PopConnectivity cmdlet can be used to test the POP3 functionality for a specified Client Access server. |
Client Access Server |
15 |
|
No |
The Test-WebServicesConnectivity cmdlet performs basic operations to verify the functionality of Outlook anywhere on a Microsoft Exchange Server 2007 computer that has the Client Access server role installed. |
Client Access Server |
15 |
|
Yes |
The Test-ExchangeSearch cmdlet performs basic operations to verify that search is enabled and is indexing messages in a timely manner. |
Mailbox Server |
720 (twice per day) |
|
Yes |
The Test-ReplicationHealth cmdlet performs basic operations to verify replication, cluster services, storage group replication, and replay status. |
Log Shipping |
15 |
|
Yes (except remote voice) |
The Test-UMConnectivity cmdlet verifies the operation of a Unified Messaging server. Three monitors verify local voice, local fax, and remote voice. For more information, see Enabling Remote Unified Messaging Connectivity Monitoring. |
Unified Messaging (UM) Server |
15 |
Synthetic Transactions and Maintenance Mode
By default, synthetic transactions are Maintenance Mode–aware and will not generate false alerts if the target of a synthetic transaction is in Maintenance Mode. For example, if the target of a mail flow synthetic transaction is in Maintenance Mode, the source server does not run the transaction and does not generate a false alert related to the target being unavailable.
This aspect of synthetic transactions functionality is activated through the RMS Target Relationship Discovery that is targeted at the Root Management server. The discovery runs twice daily, using a PowerShell-based discovery script that creates a containment relationship between the relevant synthetic transactions and the target server. The containment relationship ensures that when the target of the synthetic transaction is put in Maintenance Mode, the transaction will also be put in Maintenance Mode. This is the reason that there is a requirement to install PowerShell on the Root Management Server.
Note
When you remove synthetic transactions, you may notice that the synthetic transactions do not immediately disappear from the Operations console. This delay is due to the fact that both the discovery on the agent-managed Exchange 2007 server and the RMS Target Relationship Discovery must run in order to remove the synthetic transaction. The maximum delay for this process is 36 hours using the default discovery frequencies (24 hours for the discovery on the Exchange 2007 server and 12 hours for the RMS Target Relationship Discovery).
Note
Any synthetic transactions that you create will not be aware of Maintenance Mode until the RMS Target Relationship Discovery runs—by default this discovery is scheduled to run twice daily.