 | |||
|
|
||
| |||
| |||
| |
|
Home > Prevent SSL-related synchronization errors on emulated mobile devices |
| |
|
|
|
|
| Tutorial: |
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
|||||||||||||||||||||||||||
Note: If you don't have basic network connectivity between the Windows Mobile device emulator and the Exchange Client Access server (CAS), these troubleshooting techniques won't work. Trust between Exchange CAS and the emulated Windows Mobile device If you're using a commercial certificate authority (CA), such as VeriSign, Thawte, Go Daddy, etc., your emulated Windows Mobile device should be able to trust your Exchange Client Access server. However, an administrator may try to save a few bucks by creating an enterprise CA and using it to supply the SSL certificate for the CAS. Although this technique works, the emulated mobile device will not automatically trust the certificate. This will cause the synchronization process to fail. First, you must configure the Windows Mobile device to trust your enterprise certificate authority, which is easier than it sounds. When you create an enterprise CA, Windows automatically creates a special website that is hosted by that server. You can use this website to request a copy of the server's certificate, which will cause the emulated mobile device to trust the certificate authority and all servers bearing a certificate from that certificate authority. To access the certificate authority:
Performing the following steps ensures that the emulated mobile device trusts your enterprise CA:
Exchange ActiveSync settings Now that you've downloaded the necessary certificate, synchronization should work. If it doesn't, there are two additional settings you can check. To do so, open Exchange ActiveSync and go to Menu -> Configure Server (Figure D).
The first thing you should notice in Figure D is the server name. If you aren't using SSL encryption, then Exchange ActiveSync is easy to configure. You can use a NetBIOS name, a fully qualified domain name (FQDN) or an IP address. When you use SSL, however, the name that you specify here must match the name that is specified in the Exchange server's SSL certificate. Note: I've entered Mirage in the Server Address field. Mirage is a lab server that is hosting the client access server role; it's also acting as an enterprise certificate authority. You would never have a configuration like this in a real-world scenario. The name you specify here should be the name of your CAS, not the name of your enterprise certificate authority. Try entering the Client Access server's fully qualified domain name first. If that doesn't work, then use its NetBIOS name as I have done in the Figure D. You'll also want to make sure that the This Server Requires an Encrypted (SSL) Connection check box is selected. If you don't select this check box, synchronization will fail -- even if all of the settings are correct. About the author: Brien M. Posey, MCSE, is a five-time recipient of Microsoft's Most Valuable Professional award for his work with Exchange Server, Windows Server, Internet Information Server (IIS) and File Systems and Storage. Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, he has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal website at www.brienposey.com. Do you have comments on this tip? Let us know. Please let others know how useful this tip was via the rating scale below. Do you know a helpful Exchange Server, Microsoft Outlook or SharePoint tip, timesaver or workaround? Email the editors to talk about writing for SearchExchange.com.
|
|
|
|
|||||||||||||||||||||||||
|
|
 |  |  | |  | |  | |  | |  | |  | |  | |  | |
|
|
About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
|
|
||
|
|||||||
