Monitoring Exchange Server 2010

10/15/2010

Contents

Before You Begin
Lesson 1: Monitoring Exchange Databases
Lesson 2: Monitoring Mail Flow
Lesson 3: Monitoring Exchange Connectivity
Chapter Review
Suggested Practices
Take a Practice Test

Lesson 3: Monitoring Exchange Connectivity

This lesson looks at communication between the various server and client computers that make up an Exchange Server organization. Computers need to be correctly configured so that they can communicate with each other over IP networks and (unless your email requirements are fully internal) with external networks such as extranets or the Internet. Clients need to be able to connect to servers using the appropriate client protocols, and servers need to be able to communicate with each other.

After this lesson, you will be able to:

Test and debug network connectivity.
Use the Telnet tool to test protocol connectivity over various ports and particularly SMTP and Extended Simple Mail Transfer Protocol (ESMTP) connectivity over port 25.
Test connectivity using the various client-to-server and server-to-server protocols that enable users to access and read email messages.
Test Microsoft Exchange Web Services (EWS), Microsoft Outlook Anywhere, and Microsoft Exchange ActiveSync operation.

Estimated lesson time: 40 minutes

Debugging Network Connectivity

The standard tools for troubleshooting network connectivity, such as Ping, Tracert, Nslookup, and Ipconfig, are well known but sometimes do not provide the answers you are looking for, particularly on servers such as Windows Server 2008 and Windows Server 2008 R2, whose internal firewalls by default block the Internet Control Message Protocol Echo command.

However, the main thrust of this lesson is the use of the Telnet tool and EMS cmdlets to obtain network connection information and to test connectivity over the various client-to-server and server-to-server protocols used to implement an Exchange Server 2010 organization.

Using Telnet to Test SMTP Communication

On client computers that have a Telnet client installed, you can use the Telnet tool to test connectivity for protocols defined by their port numbers. For example, opening a Telnet session and entering open VAN-EX1.contoso.com 25 tests connectivity to server VAN-EX1.contoso.com on port 25, and if this connection can be made, the Telnet command EHLO tests that ESMTP connections can be made to that server.

You can use the Telnet utility to connect to and verify the functionality of the SMTP service on an Edge Transport server and to test whether this server is able to receive email sent from other SMTP servers on the Internet. By default, SMTP listens on port 25. If you use Telnet on port 25, you can enter the SMTP commands that are used to connect to an SMTP server and send a message exactly as if your Telnet session were an SMTP messaging server.

However, before you use Telnet to test SMTP communication, you need to consider a number of factors. For example, message transfers that occur between Hub Transport servers are encrypted and authenticated by default. You can use Telnet on port 25 to submit messages only to an internal Hub Transport server that has a Receive connector configured to allow anonymous access or basic authentication. Anonymous access is required for Internet-facing servers. When you send a message to a Receive connector that accepts basic authentication, you must have a utility to convert the text strings that are used for the user name and password into the Base64 format. Chapter 7, “Routing and Transport Rules,” discusses Receive connectors.

Typically, Internet-facing SMTP messaging servers are configured to validate the source IP address, the corresponding Domain Name System (DNS) domain name, and the reverse-lookup IP address of any Internet host that tries to send a message to the server. If you connect a client computer to the Internet and try to send a test message to a remote messaging server by using Telnet on port 25, your message is likely to be rejected. In this case, you should connect to the remote messaging server from your Edge Transport server. The accepted domains that are configured on the Edge Transport server have the appropriate DNS mail exchanger (MX) records, address (A) records, and reverse-lookup records that identify the Edge Transport server as a legitimate and traceable email message source.

You can use Telnet to connect to your organization’s Edge Transport server from a host that is located outside your perimeter network and send a test message. You can also use Telnet to connect to a remote messaging server from your organization’s Edge Transport server and send a test message. Note that the syntax of Telnet commands may differ depending on the third-party Telnet client you use. Remember that you cannot use the backspace key after you have connected to a destination SMTP server within the Telnet session. If you make a mistake as you type an SMTP command, you must press Enter and then type the command again.

To use Telnet on port 25 to connect to a destination SMTP server, you must first discover the fully qualified domain name (FQDN) or the IP address of the SMTP server. You can use the Nslookup command-line tool to find the MX record for the destination domain and hence the address of the SMTP server by carrying out the following procedure:

On the computer you are using to run the Telnet session and to connect to a remote SMTP server on the Internet, right-click Command Prompt on the Accessories menu and click Run As Administrator. If you are not logged on with an Administrator-level account, you need to supply credentials.
Enter the following command:
```
nslookup
```
Enter the following command:
```
set type=mx
```
Enter the following command:
```
set timeout=20
```
NOTE: DNS QUERY TIME-OUT

By default, Windows DNS servers have a 15-second recursive DNS query time-out limit.
Enter the name of the domain for which you want to find the MX record, followed by a trailing period. For example, to find the MX record for the contoso.com domain, enter the following command:
```
contoso.com.
```
NOTE: USING A TRAILING PERIOD

The trailing period indicates a FQDN. The use of the trailing period prevents any default DNS suffixes configured for your network from being unintentionally added to the domain name. Note also that the domain must be reachable on the Internet and must contain at least one messaging server.
Obtain the FQDN and IP address for the server to which you want to connect. The portion of the command’s output that is of significance to you should look similar to the following (note that the IP addresses will be public Internet addresses and not the private addresses shown here as an illustration):
```
contoso.com mx preference=10, mail exchanger = mail1.contoso.com
contoso.com mx preference=20, mail exchanger = mail2.contoso.com
mail1.contoso.com internet address = 10.0.10.20
mail2 contoso.com internet address = 10.0.10.30
```
To end the Nslookup session, enter the following command:
```
exit
```

The above procedure discovers the FQDNs and IP addresses of messaging servers in an external Exchange organization reachable over the Internet. To find the FQDNs of Hub Transport and Edge Transport servers within your internal Exchange Server 2010 organization, enter the following command in the EMS:

Get-ExchangeServer | where {$_.isHubTransportServer -eq $true -or $_.isEdgeServer -eq
$true} | FL Fqdn,ServerRole

Figure 9-23 shows the output from this command.

Figure 9-23 Messaging servers in the adatum.com internal organization

When you have obtained the FQDN of the target messaging server, you can use Telnet on port 25 to test SMTP communication (assuming that a Telnet client is installed in your source computer—remember that Microsoft Windows Vista and Microsoft Windows 7 client computers do not have a Telnet client installed by default). The procedure described below uses the following values:

Destination SMTP server mail01.contoso.com
Source domain adatum.com
Sender’s email address KimAkers@adatum.com
Recipient’s email address TerryAdams@contoso.com
Message subject Test from Adatum
Message body Test message

To use Telnet on port 25 to test SMTP communication, carry out the following procedure:

On an Edge Transport server in the Adatum.com domain, open a command prompt by specifying Run As Administrator and enter the following command to open the Telnet session:
```
telnet
```
Optionally, to view the characters as you type them, enter the following command:
```
set localecho
```
Optionally, to enable logging of the Telnet session to the log file telnet.log, enter the following command:
```
set logfile C:\Logfiles\telnet.log
```
To access the server mail01.contoso.com on port 25, enter the following command:
```
open mail01.contoso.com 25
```
If access is successful, you receive a response similar to the following:
```
220 mail01.contoso.com Microsoft ESMTP MAIL Service ready at <day-date-time>
```
To test that ESMTP is operating in the Contoso.com domain, enter the following command:
```
EHLO contoso.com
```
If ESMTP is working correctly, you receive a response similar to the following:
```
250 mail01.contoso.com Hello [<sourceIPaddress>]
```
To specify the sender’s email address, enter the following command:
```
MAIL FROM:KimAkers@adatum.com
```
If the sender’s email address is recognized as valid, you receive a response similar to the following:
```
250 2.1.0 Sender OK
```
To specify the recipient’s email address and to define the particular delivery status notification (DSN) messages that the destination SMTP server must provide to the sender, enter the following command:
```
RCPT TO:TerryAdams@fabrikam.com NOTIFY=success,failure
```
If the recipient’s email address is recognized as valid, you receive a response similar to the following:
```
250 2.1.5 Recipient OK
```
MORE INFO: DSN MESSAGES

DSN messages are defined in RFC 1891. For more information, see http://www.faqs.org/rfcs/rfc1891.html.
To start mail input, enter the following command:
```
DATA
```
You receive a response similar to the following:
```
354 start mail input; end with <CLRF>.<CLRF>
```
Enter Subject: Test from Adatum.
Press Enter. You need a blank line between the Subject: header field and the message body.
Enter Test message.
Press Enter, type a period, and then press Enter again. You receive a response similar to the following:
```
250 2.6.0 <GUID> Queued mail for delivery
```
To disconnect from the destination SMTP server, enter the following command:
```
QUIT
```
You receive a response similar to the following:
```
221 2.0.0 Service closing transmission channel
```
To close the Telnet session, enter the following command:
```
QUIT
```

Using Nslookup to Test MX Record Configuration

You can use the Nslookup tool to verify MX record configuration on an external or Internet DNS server. In order to receive incoming email, an MX record for each of your mail servers that you use as bridgehead servers or Internet mail servers must exist on your external DNS server or servers. For external DNS servers to resolve a mail server’s MX record and contact that mail server, the mail server must be accessible from the Internet and must be configured to contact a correctly configured DNS server to resolve DNS names.

In order to send outgoing mail, you can configure Exchange Server 2010 to use internal DNS servers that resolve external names locally or use a forwarder to an external DNS server. Typically, you configure computers running Exchange Server 2010 as DNS clients of your internal DNS server. On your internal DNS server, you can configure an external forwarder to point to trusted external DNS servers. Alternatively, to send outgoing mail, you can configure computers running Exchange Server 2010 to use a dedicated external DNS server.

To use Nslookup to verify that your MX records are configured correctly for ingoing and outgoing email, you can perform the following procedure on your Mailbox server:

Open the Command Prompt console and enter the following command:
```
nslookup
```
Where <IP address> is the IP address of the external DNS server, enter the following command:
```
server <IP address>
```
Enter the following command:
```
set q=MX
```
Type the name of your domain (for example, contoso.com) and then press Enter. If DNS is configured correctly, the MX record for the domain you entered is displayed.

Viewing Network Adapter Configuration

If you are experiencing network connectivity problems on a particular Exchange Server 2010 server, you can use a command based on the Get-NetworkConnectionInfo EMS cmdlet to view the network configuration information for all network adapters configured on that server. Typically, you run this cmdlet locally, and it returns information about the network adapters on the server on which it runs. You can optionally specify another server on the network and the FQDN of the domain controller that retrieves data from AD DS. Note that you cannot use the DomainController parameter when obtaining configuration information on an Edge Transport server.

Commands based on the Get-NetworkConnectionInfo cmdlet can display the following fields:

RunspaceID This displays a GUID that uniquely identifies the session in which an event occurs.
Name This displays the name of the network adapter. This can indicate the manufacturer and model of the network adapter or an administrator-specified network adapter name.
DnsServers This displays the DNS servers the network adapter uses. If more than one DNS server exists, the server names are separated by commas.
IPAddresses This displays the IP addresses used by the network adapter.
AdapterGuid This displays the GUID that Microsoft Windows assigns to the network adapter.
MacAddress This displays the media access control address of the network adapter.

The following command returns network connection information for the local server:

Get-NetworkConnectionInfo

Figure 9-24 shows the output from this command. Some of the fields on the Exchange Server 2010 server on your test network will return different information.

Figure 9-24 Connection information

Testing Post Office Protocol Version 3 (POP3) Connectivity

The POP3 service provides email access to clients on port 110. Secure Socket Layer (SSL)-protected POP3 uses port 995. POP3 is a client-to-server protocol in which email is received and held for the user on the Client Access server. Periodically, users check their mailboxes and download mail using the POP3 service. POP3 is built into, for example, Microsoft Outlook Express. It is also built into the Microsoft Internet Explorer browser.

You can use commands based on the Test-PopConnectivity EMS cmdlet to verify that the POP3 service is running correctly. The Test-PopConnectivity cmdlet can be used to test the POP3 functionality on a specified Client Access server for all mailboxes on servers running Exchange Server 2010 in the same AD DS site. You can also specify a single Mailbox server in the site by using the MailboxServer parameter. You can identify a single mailbox by using the MailboxCredential parameter, but to do this, you need to first get the credential information for a specific mailbox by using the Get-Credential PowerShell cmdlet.

For example, the following command prompts for the credentials for the Kim Akers mailbox user and tests POP3 connectivity to the Kim Akers mailbox on the VAN-EX1 Mailbox server:

Test-PopConnectivity -MailboxServer:VAN-EX1 -MailboxCredential:(Get-Credential "adatumKim Akers") | FL

Note that this command prompts for credentials even when you are logged on with the Kim Akers user. Figure 9-25 shows that connectivity failed in this instance because the MSExchangePOP3 service is not running.

Figure 9-25 POP3 connectivity failure message

Commands based on the Test-PopConnectivity cmdlet are typically run against the Client Access server on which they are entered. However, you can specify a remote Client Access server in the same Exchange Server 2010 organization by using the ClientAccessServer parameter. You can also use the ConnectionType parameter to specify whether the connection type is Plaintext, SSL, or Transport Layer Security (TLS). For example, the following command tests POP3 connectivity between the Client Access server CAS01 and all mailboxes on all Mailbox servers in the same organization and specifies the connection type as SSL:

Test-PopConnectivity -ClientAccessServer:CAS01 -ConnectionType:SSL

NOTE: CREATING A USER TO TEST CLIENT ACCESS SERVER CONNECTIVITY

You need to create a test user account to test connectivity to Client Access servers. To do this, enter the following command in the EMS and follow the prompts:

New-TestCasConnectivityUser.ps1

You can use the TrustAnySSLCertificate parameter to instruct the command to check the POP3 service without generating an error when the SSL certificate does not match the URL of the Client Access server. You can use the MonitoringContext parameter to specify whether the command is run by System Center Operations Manager 2007. Take care, however, that if System Center Operations Manager 2007 is not running, including this parameter causes the command to fail.

If you want to perform only a test logon to a Mailbox server using the POP3 protocol and do not require the command to test the sending and receiving of a message, you can specify the LightMode parameter. If you are using a port other than port 110 to connect to the Client Access server, you need to use the PortClientAccessServer parameter to specify the port used.

Testing Internet Message Access Protocol Version 4 (IMAP4) Connectivity

IMAP4 is a standard client-to-server protocol for accessing email from an Exchange Server 2010 server local to the email client. Email messages are received and held by the server. A mailbox user can view the heading and the sender of the message and then decide whether to download it. A user can create and manipulate multiple folders or mailboxes on the server, delete messages, or search for messages. IMAP4 requires continual access to the server during the time that a user is working with his or her email messages.

The default port for IMAP4 is 143. SSL-protected IMAP4 uses TCP port 993 to retrieve email through a Client Access server. Note that both POP3 and IMAP4 enable users to receive email messages. SMTP or ESMTP enables users to send email messages.

You can use commands based on the Test-ImapConnectivity EMS cmdlet to verify that the IMAP4 service is working as expected. You can test IMAP4 functionality on a specified Client Access server for all mailboxes on Exchange Server 2010 Mailbox servers in the same Active Directory site, for a specific Mailbox server, or for a specific mailbox identified by its credentials.

The Test-ImapConnectivity cmdlet supports the MailboxServer, -MailboxCredential, ClientAccessServer, ConnectionType, TrustAnySSLCertificate, MonitoringContext, LightMode, and PortClientAccessServer parameters in the same way as previously described for the Test-PopConnectivity cmdlet. For example, the following command tests IMAP4 connectivity from the Client Access server on which it is entered to all mailboxes on the Mailbox server VAN-EX1:

Test-ImapConnectivity -MailboxServer:VAN-EX1 | FL

The following example tests IMAP4 connectivity from the Client Access server CAS01 to all mailboxes on all Mailbox servers on the local site:

Test-ImapConnectivity -ClientAccessServer:CAS01 | FL

The following example tests IMAP4 SSL-protected connectivity from the Client Access server CAS01 to all mailboxes on all Mailbox servers on the local site:

Test-ImapConnectivity -ClientAccessServer:CAS01 -ConnectionType:SSL
-PortClientAccessServer:993 | FL

Testing Messaging Application Programming Interface (MAPI) Connectivity

MAPI is a messaging architecture and Component Object Model designed by Microsoft and based on the Application Programming Interface for Microsoft Windows. It allows client programs to become email messaging enabled or aware by calling MAPI subsystem routines that interface with messaging servers. While MAPI is designed to be protocol independent, it is usually used with the RPC protocol. MAPI/RPC is the proprietary protocol that Microsoft Outlook uses to communicate with Microsoft Exchange and is usually termed the MAPI protocol. MAPI uses a negotiated dynamic port (above 1024). RPC uses port 135.

The MAPI version that ships with Exchange Server 2010 and Microsoft Office Outlook is sometimes known as Extended MAPI. It allows complete control over the messaging system on the client computer, creation and management of messages, management of the client mailbox, and so on. Extended MAPI includes facilities to access message transports, message stores, and directories.

You can use commands based on the Test-MapiConnectivity EMS cmdlet to test MAPI connectivity and verify server functionality. You use the Identity parameter to specify a logon mailbox. The SystemMailbox is used if you do not include the Identity parameter. The cmdlet retrieves a list of items in the Inbox. Logging on to the mailbox tests two protocols used when a client connects to a Mailbox server: MAPI and Lightweight Directory Application Protocol. During authentication, the Test-MapiConnectivity cmdlet verifies that the MAPI server, Exchange store, and Directory Service Access (DSAccess) service are working.

Commands based on the Test-MapiConnectivity cmdlet log on to the specified mailbox using the credentials of the account with which you are logged on to the local computer. After successful authentication, the command accesses the mailbox to verify that the database is working. Note that you do not run the Test-MapiConnectivity cmdlet against the Client Access server. This cmdlet must be run against the Mailbox server.

The Test-MapiConnectivity cmdlet supports the Database parameter. This parameter specifies a mailbox database identity so that the command can test whether it is possible to log on to the system mailbox on the specified database. The cmdlet also supports the Identity parameter, which specifies a mailbox identity so that the command can test whether it is possible to log on to a specific mailbox. The Server parameter specifies a server identity and tests whether it is possible to log on to each system mailbox on the specified server.

For example, the following command tests MAPI connectivity to the system mailboxes in each mailbox database on the Mailbox server VAN-EX1 and returns detailed results:

Test-MapiConnectivity -Server VAN-EX1 | FL

Figure 9-26 shows the output of this command.

Figure 9-26 Testing MAPI connectivity

The following command tests MAPI connectivity to the system mailbox in the mailbox database Research and returns detailed results:

Test-MapiConnectivity -Database Research | FL

The following command tests MAPI connectivity to the Don Hall mailbox in the Adatum.com domain and returns detailed results:

Test-MapiConnectivity -Identity "adatum\Don Hall" | FL

Testing EWS and Outlook Anywhere

The EWS-managed API provides a managed interface for developing client applications that use EWS. This API communicates with the Exchange Client Access server by means of EWS Simple Object Access Protocol (SOAP) messages.

EWS uses standard industry protocols that provide interoperability between servers and client applications. SOAP XML messages provide the communication between the computer that is running Exchange Server 2010 and web services client applications. The following changes and enhancements are included in Exchange Server 2010 EWS:

Distribution Lists are renamed Contact Groups.
The FindItems interface is redesigned.
The Autodiscover implementation supports DNS SRV record lookup.
The notifications interface is redesigned.
New methods have been added for getting and setting free or busy information.

Outlook Anywhere enables Microsoft Office Outlook clients to connect to their Exchange servers over the Internet by using the RPC-over-HTTP networking component. It integrates RPCs with an HTTP layer and allows email traffic to traverse network firewalls without requiring RPC ports to be opened. To deploy Outlook Anywhere in your Exchange messaging environment, you need to enable at least one Client Access server by using the Enable Outlook Anywhere Wizard.

You can use the Enable Outlook Anywhere Wizard on an Exchange Server 2010 Client Access server to allow a user to connect to his or her Exchange mailbox from the Internet. Outlook Anywhere eliminates the need for mobile users or users in remote offices or to use a virtual private network to connect to Exchange servers.

Outlook Anywhere is enabled on your Client Access server after a configuration period of approximately 15 minutes. To verify that Outlook Anywhere has been enabled, you can check the application event log on the Client Access server. Before you can use Outlook Anywhere, you need to do the following:

Install a valid SSL certificate from a certification authority trusted by the client.
Install the Microsoft Windows RPC-over-HTTP Proxy component (if this not installed by default). Note that if you use the XML files included with Exchange Server 2010 and the install and setup instructions in the Appendix A, you should not need to install RPC-over-HTTP Proxy.
Enable Outlook Anywhere on the Client Access server.

If you use Outlook Anywhere, you must allow port 443 through your firewall because Outlook Anywhere requests use HTTP-over-SSL. If you already use Outlook Web App (OWA) with SSL or Exchange ActiveSync with SSL, you do not need to open any additional ports from the Internet. By default, when you enable Outlook Anywhere on a Client Access server, all users who have mailboxes on Mailbox servers are enabled for Outlook Anywhere.

You can test the connectivity needed for EWS and Outlook Anywhere to work by entering commands based on the Test-WebServicesConnectivity EMS cmdlet. You can use such commands to verify the functionality of EWS on an Exchange Server 2010 Client Access server. The Test-WebServicesConnectivity cmdlet tests the functionality of EWS and performs basic operations to verify the functionality of Outlook Anywhere. By default, the following operations are tested:

GetFolder
CreateItem
DeleteItem
SyncFolderItems

However, if you specify the LightMode parameter in the command, only the GetFolder operation is tested.

By default, the test runs on the Client Access server on which the command is entered. However, you can use the ClientAccessServer parameter to specify a remote Client Access server in the same Exchange organization. As with other test cmdlets described earlier in this lesson, you can use the MailboxServer and MailboxCredential parameters to test connectivity to a specific Mailbox server or to a specific user mailbox. The MonitoringContext parameter specifies whether the test result is passed to System Center Operations Manager 2007. If this parameter is set to a value of $false, the test result appears only on the command line.

The Timeout parameter specifies the amount of time, in seconds, allowed for the test operation to finish. The default value for the Timeout parameter is 300 seconds. The time-out value you specify must be greater than 0 seconds. Microsoft recommends configuring this parameter with a value of 5 seconds or greater.

The ResetTestAccountCredentials parameter resets the password for the test account used to run Test-WebServicesConnectivity commands. This is typically reset every seven days. When the ResetTestAccountCredential parameter is used, a password reset is forced any time it is required for security reasons. You can specify whether a secure SSL channel is required or whether the test can run over an unsecured channel by using the AllowUnsecureAccess switch parameter. If the test runs over a secure channel, the TrustAnySSLCertificate parameter allows it to use any SSL certificate available.

The UseAutodiscoverForClientAccessServer parameter specifies whether the test uses the Autodiscover service to locate the Client Access server. The Autodiscover service configures client computers that are running Outlook 2007 or Outlook 2010. The service can also configure supported mobile devices. It provides access to Exchange Server 2010 features for Outlook clients that are connected to the Exchange Server 2010 messaging environment. The service enables clients to automatically connect to features, such as the Outlook Address Book (OAB), the Availability service, and Unified Messaging (UM). The service uses the user’s email address and password to provide profile settings to Outlook clients and supported mobile devices. If the Outlook client is joined to the domain, the user’s domain account credentials are used.

The following command tests Web services continuity for the Getfolder operation between the Client Access server on which it is entered and all mailboxes in the same Exchange organization. The test operates over a secure channel authenticated by any available SSL certificate; if a secure channel cannot be established, the command attempts to test connectivity over an insecure channel:

Test-WebServicesConnectivity -LightMode:$true -TrustAnySSLCertificate:$true
-AllowUnsecureAccess:$true | FL

Figure 9-27 shows the output from this command.

Figure 9-27 Testing web services connectivity

You can use commands based on the Test-OutlookWebServices EMS cmdlet to verify that the Autodiscover settings for Microsoft Outlook are configured correctly. This cmdlet supports an Identity parameter that can specify any valid email address in the forest, and this address is used to test the Outlook provider. It is typically an SMTP address, but you can specify the domain and user name or an Active Directory GUID, and the command resolves this information to an SMTP address. The TargetAddress parameter specifies the recipient used to test whether Availability service data can be retrieved.

Typically, commands based on this cmdlet run against the Client Access server on which they are entered, but, as with previously described cmdlets, you can use the ClientAccessServer parameter to specify the Client Access server that the client accesses. The MonitoringContext parameter specifies whether the results of the command include monitoring events and performance counters. If you specify this parameter with the value $true, the test results include monitoring events and performance counters in addition to information about the MAPI transaction.

The following command verifies the service information returned to the Outlook client from the Autodiscover service for the user DonHall@adatum.com:

Test-OutlookWebServices -Identity:DonHall@adatum.com -MonitoringContext:$true | FL

The above command tests the following:

The Availability service
Outlook Anywhere
The OAB
UM

Figure 9-28 shows the output from this command.

Figure 9-28 Verifying Autodiscover settings

Using Exchange Server ActiveSync

Exchange Server ActiveSync is the messaging component of Exchange Server 2010 that relays messages to mobile devices. Windows Server 2008 and Windows Server 2008 R2 use Windows Mobile Device Center version 6.1, which is a version of ActiveSync.

You can use the EMS to create a Microsoft Exchange ActiveSync virtual directory in Microsoft Exchange Server 2010. When Exchange server 2010 is installed, a new ActiveSync virtual directory named Microsoft-Server-ActiveSync is created in the default Internet Information Services (IIS) website. You can optionally create additional Exchange Server 2010 ActiveSync virtual directories in websites other than the default website. All the ActiveSync virtual directories you create have the name Microsoft-Server-ActiveSync.

For example, the following EMS command creates a new ActiveSync virtual directory in the adatum.com website:

New-ActiveSyncVirtualDirectory -WebSiteName "Adatum.com"

When you install the Client Access server role on Exchange Server 2010, ActiveSync is enabled by default, and an ActiveSync virtual directory is created on the Client Access server. You can then configure the virtual directory using either the EMC or the EMS.

To use the EMC to configure ActiveSync virtual directory properties, open the EMC, expand the Console tree, and carry out the following procedure:

In the console tree under Server Configuration, click Client Access.
In the Work pane, click the Exchange ActiveSync tab. Right-click Microsoft-Server-ActiveSync and click Properties.
In the General tab, you can view display-only information about the ActiveSync virtual directory and set internal and external URLs.
On the Authentication tab, shown in Figure 9-29, you can control the authentication methods for the Exchange ActiveSync virtual directory.

Figure 9-29 Authentication methods for the Exchange ActiveSync virtual directory
On the Remote File Servers tab, you specify allowed and blocked host names for ActiveSync clients. This tab also allows you to configure which domains are treated as internal. You can use the Block List to configure a list of host names of servers to which clients are denied access and the Allow List to configure a list of host names of servers on which clients are allowed to access files. The Block list takes precedence over the Allow list. You can use the Unknown Servers list to specify how to access files from host names not listed in either the Block list or the Allow list. The default value is Allow. Use the Enter The Domain Suffixes That Should Be Treated As Internal control to configure specific host names as internal host names.

You can also use the EMS to configure the Exchange ActiveSync virtual directory properties. For example, the following command configures the Exchange ActiveSync virtual directory with Basic authentication and an External URL of http://adatum.com/Microsoft-Server-ActiveSync:

Set-ActiveSyncVirtualDirectory -Identity "http://adatum/microsoft-server-activesync"
-BasicAuthEnabled:$true -ExternalURL http://adatum.com/Microsoft-Server-ActiveSync

The following example configures the Exchange ActiveSync virtual directory with Basic authentication:

Set-ActiveSyncVirtualDirectory -Identity "adatum\microsoft-server-activesync"
-BasicAuthEnabled:$true

By default, users are enabled for ActiveSync in Exchange Server 2010. You can disable Exchange ActiveSync for a user by using the EMC or the EMS.

To use the EMC to disable Exchange ActiveSync for a user, open the EMC and expand the Console tree, then carry out the following procedure:

Click Mailbox under Recipient Configuration in the Console tree.
Right-click the user’s mailbox and then click Properties.
Click the Mailbox Features tab.
Click Exchange ActiveSync and then click Disable.
Click OK.

To enable Exchange ActiveSync for a user for whom it has previously been disabled, you carry out the same procedure except that you click Enable after you have clicked Exchange ActiveSync.

You can also use the EMS to disable Exchange ActiveSync for a user. The following command disables Exchange ActiveSync for the mailbox user Don Hall in the Adatum.com domain:

Set-CASMailbox -Identity DonHall@adatum.com -ActiveSyncEnabled $false

To use the EMS to enable Exchange ActiveSync for a user for whom it has previously been disabled, you would enter a command similar to the following:

Set-CASMailbox -Identity DonHall@adatum.com -ActiveSyncEnabled $true

You can restrict access to ActiveSync by using the device ID. This feature prevents users from synchronizing, for example, unauthorized mobile phones with Exchange Server 2010. By default, if ActiveSync is enabled for a user, that user can synchronize the Exchange mailbox with any mobile phone. To restrict a user to a specific mobile phone, you use the ActiveSyncAllowedDeviceIDs parameter of the Set-CASMailbox cmdlet. For example, the following command permits Don Hall to synchronize two mobile phones identified by their device IDs, where these IDs are specified by the variables <DeviceID_01> and <DeviceID_02>”:

Set-CASMailbox -Identity: -Identity DonHall@adatum.com -ActiveSyncAllowedDeviceIDs:
"<DeviceID_01>","<DeviceID_02>"

Lesson Summary

You can use the Telnet tool from a computer that has a Telnet client installed to test SMTP and ESMTP connectivity on Port 25.
EMS commands are available to enable you to display network adapter settings and test POP3, IMAP4, and MAPI connectivity.
You can also use EMS commands to test EWS connectivity and Outlook Anywhere operability. You can use either the EMC or the EMS to configure Exchange Server ActiveSync.

Lesson Review

You can use the following questions to test your knowledge of the information in Lesson 2, “Monitoring Exchange Connectivity.” The questions are also available on the companion CD if you prefer to review them in electronic form.

You have opened a Telnet session on an Edge Transport server and want to access the Mailbox server Mailbox02.fabricam.com in the remote Fabrikam.com domain using SMTP and ESMTP. What Telnet session command do you enter to access the server Mailbox02.fabricam.com?
1. open Mailbox02.fabrikam.com
2. EHLO fabrikam.com
3. open Mailbox02.fabricam.com 25
4. set localecho
You want to view the network configuration information for all network adapters configured on a Mailbox server. What EMS cmdlet enables you to do so?
1. Get-NetworkConnectionInfo
2. Test-WebServicesConnectivity
3. Test-OutlookWebServices
4. Set-ActiveSyncVirtualDirectory
You want to test POP3 connectivity over an SSL connection between the Client Access server VAN-CAS01 and all mailboxes in your Exchange organization. What EMS command do you use?
1. Test-PopConnectivity -MailboxServer:VAN-CAS01 –ConnectionType:TLS
2. Test-PopConnectivity -ClientAccessServer:VAN-CAS01 –ConnectionType:TLS
3. Test-PopConnectivity -MailboxServer:VAN-CAS01 –ConnectionType:SSL
4. Test-PopConnectivity -ClientAccessServer:VAN-CAS01 –ConnectionType:SSL
Your organization provides email access to third-party email clients on TCP port 143 on the Client Access server NY-CAS01. Some clients are unable to retrieve email. What EMS cmdlet would you use to verify that the relevant service on MY-CAS01 is functioning correctly?
1. Test-ImapConnectivity
2. Test-PopConnectivity
3. Test-MapiConnectivity
4. Test-WebServicesConnectivity
You want to test Web services continuity for only the Getfolder operation between a Client Access server and all mailboxes in the same Exchange organization. You want the test to operate over a secure channel authenticated by any available SSL certificate. What EMS command do you enter on the Client Access server?
1. Test-WebServicesConnectivity –TrustAnySSLCertificate:$true | FL
2. Test-WebServicesConnectivity –LightMode:$true –TrustAnySSLCertificate:$true | FL
3. Test-WebServicesConnectivity –AllowUnsecureAccess:$true | FL
4. Test-WebServicesConnectivity –LightMode:$true–AllowUnsecureAccess:$true | FL

Practice: Creating a Mailbox Database and Obtaining Mailbox Database Information and Statistics

In this practice session, you will create a mailbox database (if necessary), obtain general information about this database, and view mailbox database statistics, The information and statistics you obtain for a mailbox database in an isolated test network are not especially interesting, but the same procedure can be used to obtain significant data in a production environment.

EXERCISE 1 Creating and Configuring a Mailbox Database (Optional)

If you already created and configured the Research mailbox database in Chapter 2, “Exchange Databases and Address Lists,” you do not need to carry out this exercise. If not, create and configure this mailbox database using the following procedure:

Log on to the Mailbox server VAN-EX1 using the Kim Akers account with the password Pa$$w0rd.
Open Computer and create the folders C:\MyDatabaseFiles and C:\MyLogFolder. Note that if you have a second hard drive, you can optionally create the folder D:\MyLogFolder instead of C:\MyLogFolder and amend the command in step 5 accordingly.
Click Start, click All Programs, and then click Microsoft Exchange Server 2010.
Right-click Exchange Management Shell and click Run As Administrator.

To create a mailbox database named Research, enter the following command:

New-MailboxDatabase -Name Research -Server VAN-EX1 -EdbFilePath
C:\MyDatabaseFiles\Research.edb -LogFolderPath C:\MyLogFolder

To configure the maintenance schedule, warning quota level, and deleted item retention time for the Research mailbox database, enter the following command:
```
Set-MailboxDatabase -Identity Research -MaintenanceSchedule 6.21:00-6.23:15
-IssueWarningQuota 2GB -DeletedItemRetention 21
```
Check that the Research mailbox database has been created and configured, as shown in Figure 9-30.

Figure 9-30 Creating and configuring the Research mailbox database

EXERCISE 2 Obtaining Mailbox Database Information and Statistics

In order to carry out this exercise, you need to have created the Research mailbox database either by carrying out Exercise 1 or previously in Chapter 2. Obtain general information for this mailbox database using the following procedure:

If necessary, log on to the Mailbox server VAN-EX1 using the Kim Akers account with the password Pa$$w0rd. Open the EMS using Run As Administrator, as described in the previous exercise.
To obtain detailed information about the Research mailbox database, enter the following command:
```
Get-MailboxDatabase -Identity Research | FL
```
Figure 9-31 shows some of the output from this command.

Figure 9-31 Detailed information about the Research mailbox database
To obtain mailbox statistics, enter the following command:
```
Get-MailboxStatistics -Database Research | FL
```
Figure 9-32 shows some of the output from this command.

Figure 9-32 Statistics for the Research mailbox database

Practice: Configuring the Size and Age of Message Tracking Log Files on a Hub Transport and a Mailbox Server

The Exchange Server 2010 server VAN-EX1 is configured with both the Hub Transport and the Mailbox server roles. You need to configure the size and age of message tracking log files and the size of the message tracking log file directory separately for each role. You perform these tasks in this practice session.

EXERCISE 1 Configuring Message Tracking Log File Settings on a Hub Transport Server

In this exercise, you change the maximum size of each message tracking log file on the Hub Transport server VAN-EX1 to 25 MB and the maximum age of each message tracking log file to 45 days. You change the maximum size of the message tracking log file directory on the same server to 350 MB. To complete these tasks, carry out the following procedure:

If necessary, log on to the Mailbox server VAN-EX1 using the Kim Akers account with the password Pa$$w0rd. Open the EMS using Run As Administrator, as described in the previous practice session.
To change the maximum size of each message tracking log file to 25 MB, enter the following command:
```
Set-TransportServer -Identity VAN-EX1 -MessageTrackingLogMaxFileSize 25MB
```
To change the maximum age of each message tracking log file to 45 days, enter the following command:
```
Set-TransportServer -Identity VAN-EX1 -MessageTrackingLogMaxAge 45.00:00:00
```
To change the maximum size of the message tracking log file directory to 350 MB, enter the following command:
```
Set-TransportServer -Identity VAN-EX1 -MessageTrackingLogMaxDirectorySize 350MB
```
If all three commands complete without error, as shown in Figure 9-33, you have successfully made the changes.

Figure 9-33 The Hub Transport server configuration changes have been successfully made.

EXERCISE 2 Configuring Message Tracking Log File Settings on a Mailbox Server

In this exercise, you change the maximum size of each message tracking log file on the Mailbox server VAN-EX1 to 35 MB and the maximum age of each message tracking log file to 40 days. You change the maximum size of the message tracking log file directory on the same server to 400 MB. To complete these tasks, carry out the following procedure:

If necessary, log on to the Mailbox server VAN-EX1 using the Kim Akers account with the password Pa$$w0rd. Open the EMS using Run As Administrator, as described in the previous practice session.
To change the maximum size of each message tracking log file to 35 MB, enter the following command:
```
Set-MailboxServer -Identity VAN-EX1 -MessageTrackingLogMaxFileSize 35MB
```
To change the maximum age of each message tracking log file to 40 days, enter the following command:
```
Set-MailboxServer -Identity VAN-EX1 -MessageTrackingLogMaxAge 40.00:00:00
```
To change the maximum size of the message tracking log file directory to 400 MB, enter the following command:
```
Set-MailboxServer -Identity VAN-EX1 -MessageTrackingLogMaxDirectorySize 400MB
```
If all three commands complete without error, as shown in Figure 9-34, you have successfully made the changes.

Figure 9-34 The Mailbox server configuration changes have been successfully made.

Practice: Testing MAPI Connectivity to a Mailbox Database and to a Specific Mailbox

In this practice session, you test MAPI connectivity from the Client Access server VAN-EX1 to the Research mailbox database and to the Kim Akers mailbox in the adatum.com domain. The Research mailbox database and the Kim Akers mailbox must exist on the server VAN-EX1 before you can carry out this practice.

EXERCISE Testing MAPI Connectivity

To test MAPI connectivity to a specified mailbox database, you connect to the system mailbox in the mailbox database. To test MAPI connectivity to a specified mailbox in a domain, you specify the mailbox name and the domain. To perform both these tasks, carry out the following procedure:

If necessary, log on to the Client Access server VAN-EX1 using the Kim Akers account with the password Pa$$w0rd. Open the EMS using Run As Administrator, as described in the previous practice session.
Enter the following command to test MAPI connectivity to the Research mailbox database and return detailed results:
```
Test-MapiConnectivity -Database Research | FL
```
Figure 9-35 shows the output of this command.

Figure 9-35 Testing MAPI connectivity to the Research mailbox database

Enter the following command to test MAPI connectivity to the Kim Akers mailbox in the Adatum.com domain and return detailed results:
```
Test-MapiConnectivity -Identity "adatum\Kim_Akers" | FL
```
Figure 9-36 shows the output of this command.

Figure 9-36 Testing MAPI connectivity to the Kim Akers mailbox