Microsoft KB Archive/927465

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

Article ID: 927465

Article Last Modified on 10/25/2007

-

APPLIES TO


 * Microsoft Exchange Server 2003 Enterprise Edition
 * Microsoft Exchange Server 2003 Standard Edition
 * Microsoft Exchange Server 2007 Enterprise Edition
 * Microsoft Exchange Server 2007 Standard Edition

-



SYMPTOMS
When you try to synchronize a Microsoft Windows Mobile-based device by using Exchange ActiveSync for Microsoft Exchange Server 2003 or for Microsoft Exchange Server 2007, 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

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



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

Windows Mobile-based devices do not generally contain intermediate CA certificates in their certificate store. Internet Information Services (IIS) will send the whole certificate chain to the device. However, IIS will do 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 Web site:

https://certificates.godaddy.com/InstallationInstructions_alt.go

Frequently, this issue occurs with VeriSign certificates because the intermediate CA certificate in the certificate store on the Windows Server 2003 server is expired.

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



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 Outlook Web Access URL for the server into 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, visit the following Microsoft Web site:

http://technet2.microsoft.com/WindowsServer/en/Library/4b7ea7f9-311a-479b-aecc-c856165b97c11033.mspx

Method 2: Manually install certificates on the 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 none of the 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.
 * 1) Repeat steps 9 through 13 for the trusted root CA certificate.
 * 2) 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 Web site:

http://blogs.msdn.com/windowsmobile/archive/2006/08/11/sslchainsaver.aspx





MORE INFORMATION
Exchange Server 2003 and Exchange 2007 require that you 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.

Additional query words: xccc 0x80072f05 0x80072F0D

Keywords: kberrmsg kbtshoot kbprb kbexchmobility KB927465

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.