Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

Error message when you try to synchronize a Windows Mobile-based device by using Exchange ActiveSync for Exchange 2003 or for Exchange 2007 or for Exchange 2010: "Synchronization failed"


View products that this article applies to.

Symptoms

When you try to synchronize a Microsoft Windows Mobile-based device by using Microsoft Exchange ActiveSync together with Microsoft Exchange Server 2003, Microsoft Exchange Server 2007, or Microsoft Exchange Server 2010, synchronization is not successful. Additionally, you receive one of the following error messages:

Error message 1

Synchronization failed. The security certificate on the server has expired. Check that the date and time on the device is correct and try again. Error Code: 80072f05 or 0x80072f05

Error message 2

The security certificate on the server is invalid. Contact your Exchange Server administrator or ISP to install a valid certificate on the server. Support Code: 80072F0D or 0x80072f0d

↑ Back to the top


Cause

This issue occurs because an intermediate certification authority (CA) certificate is not present on the device or on the server with which you are synchronizing, and this server is running Exchange Server.

Windows Mobile-based devices do not generally contain intermediate CA certificates in their certificate store. Internet Information Services (IIS) sends the whole certificate chain to the device. However, IIS does this only if it can verify the whole chain. By default, the device does not contain these certificates. Therefore, the server must send them. The device must contain only the root certificate in its certificate store.

Frequently, this issue occurs with GoDaddy certificates because either the root CA certificate or the intermediate CA certificate is missing from the certificate store on the server that is running Windows Server 2003. For more information, visit the following website:Frequently, this issue occurs with VeriSign certificates because the intermediate CA certificate is expired in the certificate store on the Windows Server 2003 server.

For more information, click the following article number to view the article in the Microsoft Knowledge Base:
834438 Update VeriSign Web Server Certificates Now for IIS: An expired VeriSign intermediate certificate can result in non-validated connections to sites using SSL

↑ Back to the top


Resolution

To resolve this issue, use one of the following methods, as appropriate for your situation.

Note To obtain the information about the certificate that you are using, type the Microsoft Office Outlook Web Access URL for the server into the address bar for Windows Internet Explorer, and then click the lock icon. You may have to export one or more of the certificates in the �Certification Path� to complete the remaining steps. Additionally, you may be able to obtain these files and more specific instructions from your certificate vendor.

Method 1: Use a Group Policy configuration

Use a Group Policy configuration to distribute certificates that will be trusted by all member computers of the domain. For more information about how to add a trusted root CA to a Group Policy Object (GPO), visit the following Microsoft website:

Method 2: Manually install certificates on Exchange Server

  1. Use an account that has Domain Administrator credentials to log on to the Exchange Server that is used for Outlook Web Access. Frequently, this server will be the front-end server.
  2. Click Start, click Run, type mmc.exe, and then click OK.
  3. On the File menu, click Add/Remove Snap-in.
  4. Click Add.
  5. Click Certificates, and then click Add.
  6. Click My user account, and then click Finish.
  7. Click Add, click Computer account, click Next, and then click Finish.
  8. Click Close, and then click OK. The list of certificate categories for the local computer appears in the snap-in window.
  9. Expand Certificates - Current User, right-click Intermediate Certification Authorities, point to All Tasks, and then click Import.
  10. Verify that all certificates in the chain are in the Intermediate Certification Authorities container. Also verify that no certificates are disabled or expired.
  11. If a certificate is missing, point to All Tasks, and then click Import. Use the wizard to import the file that you obtained from your CA.
  12. Expand Certificates - Local Computer, right-click Intermediate Certification Authorities, point to All Tasks, and then click Import.
  13. Use the wizard to import the file that you obtained from your CA.

    Note The root certificate will be in the Third Party Root Certification Authorities container instead of in the Intermediate Certification Authorities container.
  14. Repeat steps 9 through 13 for the trusted root CA certificate.
  15. Restart the IIS service for the changes to take effect.
Notes
  • Make sure that the certificates are installed for the local computer account.
  • The certificates do not have to be installed on the device if the certificates are installed on the servers with which you are synchronizing.
  • You can use the SSLChainSaver utility to determine which certificates are missing.

    For more information about the SSLChainSaver utility, visit the following Microsoft website:

↑ Back to the top


More information

Exchange Server 2003 and Exchange Server 2007 require you to add the trust chain to the administrator account and to the local computer accounts. A trust chain can have more than one intermediate CA. After you add the trust chain, the certification path is available to Exchange Server to send to the device. This allows for S/MIME to work successfully.

The information and the solution in this document represents the current view of Microsoft Corporation on these issues as of the date of publication. This solution is available through Microsoft or through a third-party provider. Microsoft does not specifically recommend any third-party provider or third-party solution that this article might describe. There might also be other third-party providers or third-party solutions that this article does not describe. Because Microsoft must respond to changing market conditions, this information should not be interpreted to be a commitment by Microsoft. Microsoft cannot guarantee or endorse the accuracy of any information or of any solution that is presented by Microsoft or by any mentioned third-party provider.

Microsoft makes no warranties and excludes all representations, warranties, and conditions whether express, implied, or statutory. These include but are not limited to representations, warranties, or conditions of title, non-infringement, satisfactory condition, merchantability, and fitness for a particular purpose, with regard to any service, solution, product, or any other materials or information. In no event will Microsoft be liable for any third-party solution that this article mentions.

Visit our Windows Phone Forums for more helpful hints and ideas.

↑ Back to the top


Keywords: kbtshoot, kbprb, kberrmsg, kbexchmobility, kbwp7sync, kbwp7, kbwindowsphone7, KB927465

↑ Back to the top

Article Info
Article ID : 927465
Revision : 6
Created on : 11/1/2011
Published on : 11/1/2011
Exists online : False
Views : 613