Mike Stacy's Blog

OT: Blackjack 2 does not connect to WMDC

Now that the official release of Windows Mobile 6.1 is finally out for the Blackjack 2, I discovered that I could not connect my phone to Vista's Windows Mobile Device Center (WMDC), which is a requirement for the upgrade.  I always connect as a modem or via bluetooth, so I hadn't actually come across this before.  I saw a number of other folks that had complained about the same thing and had not gotten resolution so rather than create logons and posts on each forum I figured I'd post here and hope that the search engines picked it up.  The fix was pretty easy - just install the WMDC driver update from here (or, if you run 64 bit like I do, here).  Once that was complete my phone was immediately recognized by WMDC.

Common Certificate issue with Vista

I got a call from an industry colleague yesterday who was trying to set up an OCS lab environment.  He hit what has become an increasingly common issue as Vista becomes more heavily adopted in the enterprise.  The scenario is almost always the same - "My XP computers can download the address book without a problem but Vista cannot."  User Account Control is commonly suspected as the problem, but in this case it has nothing to do with the actual issue.  In fact, the issue is actually a default setting in IE7:  Check for server certificate revocation.

The error that you'll see is:
"Cannot Synchronize with the corporate address book. This may be because the proxy server setting in your web browser does not allow access to the address book. If the problem persists, contact your system administrator."

The error message is a bit misleading.  What is actually happening is that IE is checking the CRL Distribution Points property of the certificate that is provided by the web conferencing server and trying to connect to the paths specified.  If it cannot connect to any of these it will fail with the above error message.  The reason this does not cause Communicator logons to fail is because the the address book download process uses the WinInet API just like IE since the connection is https.  Communicator does not use WinInet for its logon, so the logon succeeds as long as the certificate is trusted by the client.

This scenario is most common in lab environments because the lab will often use a separate AD environment but users whose machines are joined to the production AD forest will try to connect with Communicator.  Without any trusts and/or DNS replication of the test forest, the client will not be able to connect to either the LDAP or HTTP paths referenced in the CRL Distribution Points property.  Here is an example of a CRL DP from a certificate generated by a Windows CA:

[1]CRL Distribution Point

Distribution Point Name:

Full Name:

URL=ldap:///CN=EVAN-CA,CN=EVAN-DC1,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=corp,DC=evangelyze,DC=net?certificateRevocationList?base?objectClass=cRLDistributionPoint

URL=http://evan-dc1.corp.evangelyze.net/CertEnroll/EVAN-CA.crl

You can imagine by looking at the paths above that a computer without any knowledge of the namespaces used would have a problem connecting to them.  This problem can also manifest itself in a production environment if you have machines that are not members of the same forest or for any other reason cannot resolve or connect to the paths referenced in the CRL DP.  In any case there are only 3 options:

1) Disable certificate revocation checking in IE.  This can be done manually or via group policy.  The setting can be found in the Security section of the Advanced tab in Internet Options.

2) Modify your infrastructure in such a way as to make the CRL DP accessible to all users.

3) Use a public CA to issue the certificate rather than an internal CA.  This is the best solution if you have non-domain joined users connecting to your internal pool.