Step-by-Step Guide to Deploying Windows Mobile-based Devices with Microsoft Exchange Server 2003 SP2
Appendix C: Troubleshooting a Mobile Messaging Solution
This section provides information about troubleshooting tools and detailed information and specific troubleshooting steps around Microsoft direct push technology so that you can better isolate mobility issues within your network infrastructure. This section contains information on the following subjects:
Logging and Troubleshooting ToolsThe following troubleshooting and logging tools should help you track and resolve mobility issues. Monitoring Mobile Performance on Exchange Server 2003 SP2To track the performance, availability, and reliability of Exchange ActiveSync and other mobile messaging components, you can use the Exchange Server Management Pack. The Exchange Server Management pack includes rules and script components that validate the availability of communication services, send test e-mails to verify operations, and measure actual delivery times. With Exchange Server 2003 SP2, the following new rules were added:
The Exchange Management Pack Configuration Wizard provides a graphical user interface (GUI) to configure Exchange 2000 and Exchange 2003 Management Packs, including test mailboxes, message tracking, and monitoring services. You can download the Exchange Management Pack from the Microsoft Web site: http://go.microsoft.com/fwlink/?LinkId=55885. The Exchange Server Management Pack Guide for MOM 2005 explains how to use the Exchange Management Pack to monitor and maintain messaging resources. You can download the management pack guide from the Microsoft Web site: http://go.microsoft.com/fwlink/?LinkId=58794. ISA Server Best Practices AnalyzerTo determine the overall health and diagnose common configuration errors, download and run the Microsoft ISA Server Best Practices Analyzer Tool at the Microsoft Download Center. Issues Related to Direct Push TechnologyRefer to Understanding the Direct Push Technology in this document for details on how direct push works. General Direct Push Troubleshooting TipsIn general, there are three troubleshooting steps that an administrator can take to troubleshoot connectivity issues:
Path Troubleshooting Direct PushIn many cases, a single firewall or gateway in the network can cause timing issues that impede the direct push path.
In all mobile messaging scenarios, you will need to ensure that your firewall configuration is set to work correctly with Exchange ActiveSync and direct push technology. While each network infrastructure varies, the following illustration depicts a typical network infrastructure where the firewall idle session timeouts need to be adjusted to 30 minutes. Using a heartbeat interval of 30 minutes has positive implications for battery life and bandwidth consumption. When direct push sessions are permitted to live longer (such as 30 minutes), there are fewer HTTP round trips, less data sent and received, and less power consumed by the device. In other infrastructure scenarios, idle session time out settings may also include any other packet-forwarding networking devices or web appliances between the Exchange 2003 Server and mobile device. To modify the idle session timeout settings for your third party firewall or reverse proxy device, please refer to the hardware manufacturer’s documentation to do so. Additionally, Microsoft has worked with mobile operators to increase the idle connection timeouts on their outgoing firewalls, but the enterprises that are deploying direct push technology will also need to increase those timeouts on their incoming firewalls per the instructions above. In Microsoft’s own deployment, the timeouts on the firewall are set to thirty minutes. Verify Direct Push InitializationThe Exchange Product team has written an article that explains steps that an administrator can take to help isolate direct push technology issues. For additional information and the full context of this article please visit the following link. http://go.microsoft.com/fwlink/?LinkId=67080.
Before Proto Local Address Foreign Address State PID UDP 0.0.0.0:1985 *:* 1928 UDP 0.0.0.0:3456 *:* 3356 After Proto Local Address Foreign Address State PID UDP 0.0.0.0:1985 *:* 1928 UDP 0.0.0.0:2883 *:* 3048 UDP 0.0.0.0:3456 *:* 3356 Netstat provides the Process ID which matches the EAS process per the initialization event in the application log. Another way to check if the server is listening on the AUTD port is to use PortQry (available on Microsoft.com). The following lists the process that is listening on the port: Process ID: 3048 (w3wp.exe) PID Port Local IP State Remote IP:Port 3048 TCP 31479 172.29.8.222 ESTABLISHED 172.29.9.107:3268 3048 TCP 31480 172.29.8.222 ESTABLISHED 172.29.9.107:389 3048 UDP 2883 0.0.0.0 *:* Troubleshooting Direct Push Using Logs
 NoteThe AUTDState.XML is created on receipt of the 1st PING request and is updated only when the heartbeat or folder list changes. So you may not see this command for every Ping request. AUTD state information is maintained on the mailbox server in the NON_IPM_SUBTREE of each user's mailbox. In IE, you can Choose File, Open, check the box to "Open as Web Folder" and type in http://server/exchange/user/NON_IPM_SUBTREE/Microsoft-Server-ActiveSync/Autd-State.XML The following is a sample AUTDState.XML file. <?xml version="1.0" encoding="utf-8"?>
<AutdState xmlns="Ping:">
<Version>1.0</Version>
<HeartbeatInterval>680</HeartbeatInterval>
<Folders>
<Folder>
<Id>7529a5b36290aa458b9e1fc2d5ff85a6-3aaa2</Id>
<Class>Email</Class>
</Folder>
<Folder>
<Id>7529a5b36290aa458b9e1fc2d5ff85a6-2cfb8</Id>
<Class>Calendar</Class>
</Folder>
</Folders>
</AutdState>
Push Mail and GAL Lookup missing when syncing to Exchange 2003 SP2 with a MSFP Device.The following is a reprint of a blog on Microsoft TechNet that explains steps that an administrator can take to help isolate issues around direct push email and GAL Lookup when synching to Exchange 2003. For additional information and the full context of this article, please see the following TechNet blog. http://blogs.technet.com/vik/archive/2006/10/17/push-mail-and-gal-lookup-missing-when-syncing-to-exchange-2003-sp2-with-a-msfp-device.aspx. During deployments you may run into the issue where your server is up and you are syncing without a problem but you aren’t getting the option to sync as items arrive as well as the option to do Lookup Online is missing. This is normally caused by a firewall issue where the Options verb is being blocked. We see we are not returning the expected response for the OPTIONS command from the following entry on the device logs. Enable Verbose logging on the device from server settings in Advanced in device to see these logs.
The HTTP 500 is the response from the server for the OPTIONS command sent by the device. We normally get this response if URLScan is blocking the verb. So we have to check for URLScan in the server. If URLScan is present, then we can add OPTIONS to the AllowVerb section of URLScan.ini file. The above symptom is confirmed from the IIS logs as well.
Notice the entry Log=V1 in the above log entry. It indicates that Airsync protocol version 1.0 is being used, whereas with Push functionality Airsync version 2.5 is the latest and to be used. Ideally we should use Airsync protocol version 2.5 which will be represented as Log=V4. So permitting the OPTIONS verb in URLScan or whatever software is blocking it should resolve the issue.
Based on the list of commands returned by the server as above, the device will decide which version of AirSync protocol to use. Different features like direct push technology or AUTD etc depend on the version of the protocol being used for communication. Check for URLScan on your Exchange server and check if any other device or software device is blocking OPTIONS command. URLScan is an add-on tool that can be used by Web site administrators. The administrators can control the actions of URLScan and can restrict the type of HTTP requests that the server processes. URLscan.ini file is the configuration file of this tool and URLscan tool will not function after we rename this file and once we rename it back it will start working again, nothing else will be affected. For more information see the Microsoft Knowledge Base article, "Using URLScan on IIS" (http://support.microsoft.com/kb/307608/). The purpose of this article is to ensure effective distribution of the Internet Information Services (IIS) security tool URLScan. After you edit your URLSCAN.ini file a Server reboot is not required just restart the IIS & WWW services. Issues Related to ISA Server 2006The following issues have been discovered in early deployment of ISA Server 2006. Double Authentication Required after Upgrading from ISA Server 2004After upgrading from ISA Server 2004, when an Exchange publishing rule was defined with forms-based authentication, users are prompted twice for their credentials. In ISA Server 2004, when you create a rule with the New Mail Server Publishing Rule Wizard, authentication delegation is not required, because it is handled by ISA Server itself. When this rule is upgraded to ISA Server 2006, authentication delegation for the rule is set to No delegation. The solution is to manually configure authentication delegation for the affected rule to Basic Authentication. Log Off when the User Leaves Site Feature RemovedThe Log off when the user leaves site setting has been removed from ISA Server 2006. Users should always use the log off button to properly log off from Outlook Web Access. Windows Mobile Users Receive Error 401 UnauthorizedWhen a Windows Mobile user tries to access a published Outlook Web Access or Windows Mobile Access Web site published with the New Exchange Publishing Rule Wizard, the user receives error 401 instead of the Exchange logon forms. This error appears when the required HTML form directories for Windows Mobile access are missing from the Exchange HTML form set directory The solution is to manually create the two directories, cHTML and xHTML, in the %programfiles%\Microsoft ISA Server\CookieAuthTemplate\Exchange folder. Then, copy the contents of the %programfiles%\Microsoft ISA Server\CookieAuthTemplate\Exchange\HTML folder to the cHTML and xHTML folders. Users Receive Access Denied Error MessageWhen a user attempts to connect to a published Outlook Web Access site and does not add the /exchange suffix to the end of the URL, such as https://mail.contoso.com, instead of receiving the forms-based authentication logon screen, the user receives an "Access denied" error message. This error can be difficult to troubleshoot because ISA Server is behaving as expected. A workaround is to publish the root of the Exchange front-end server, with an action of Deny, and redirect users to the proper URL, such as https://mail.contoso.com/exchange. Perform the following procedure to automatically redirect users to the proper Outlook Web Access URL. To create an Exchange Web client access publishing rule
Certificate Implementation Issues on the ServerFor information about troubleshooting Certificate implementation on Server, see "Certificate Revocation and Status Checking" on the Microsoft TechNet Web site. http://www.microsoft.com/technet/prodtechnol/winxppro/support/tshtcrl.mspx Communication Issues between the Front-end and Back-end Exchange ServersFor information about front-end and back-end communication issues, see the Microsoft Support Webcast, "Troubleshooting Microsoft Exchange Server 2003 ActiveSync Issues." Frequently Asked QuestionsThe Exchange Product team has written an article that explains steps that an administrator can take to help isolate direct push technology issues. For more information about the deployment of direct push technology, see the Exchange Server blog article "Direct push is just a heartbeat away" at http://go.microsoft.com/fwlink/?LinkId=67080.
|
In This Article
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Important
