Windows Mobile 5 and SBS 2003 Premium

If you need to set up Windows Mobile 5 devices on your Small Business Server 2003 network then Microsoft have published an excellent whitepaper Deploying Windows Mobile 5.0 with Small Business Server 2003.

I ran in to a small problem when setting up a new WM5 device on our network where the device would sync OK over the air but not in the cradle. The solution involved creating an unusual split DNS configuration and learning more about SSL certificates.

In our office environment we are running SBS 2003 Premium from the Microsoft Action Pack with SBS 2003 SP1 and ISA 2004 installed. Our Internet connection is via a PPPoA DSL connection and we use a Cisco DSL router which NATs internal traffic. Our public IP address is on the Cisco and it is configured to forward ports 443, 444, and 4125 for Remote Web Workplace (RWW), Outlook Web Access (OWA), Outlook Mobile Access (OMA), and Sharepoint to the external interface on the SBS box.

I had followed the instructions in the whitepaper and entered the public DNS name in the Server address field in Activesync and on attempting to sync got the following error.

Microsoft Activesync, The server could not be reached. This can be caused by temporary network conditions. Support Code:80072eff.

This occurred because our public DNS name resolved to the external interface on the Cisco and being a standards compliant router it wouldn't loop back internal traffic. At this point the device could sync over the air without error.

No problem, like the whitepaper troubleshooting suggests, I created a split DNS and had our public DNS name resolve to the LAN IP address of the SBS box.

This would have worked had we been running SBS 2003 Standard without ISA because in that configuration there is only one SSL certificate. The SBS Standard SSL certificate matches the following addresses. Public DNS name, companyweb, ServerName, localhost, and ServerName.domain.local.

SBS 2003 Premium with ISA uses two SSL certificates. One which matches the public DNS name which ISA uses, and another which matches publishing.domain.local, companyweb, ServerName, localhost, and ServerName.domain.local which is used internally on IIS.

I had installed the SSL certificate matching our public DNS name on the WM5 device but now we were resolving to our internal network which used the other certificate and Activesync gave us a new error.

Microsoft Activesync. 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.

So I installed the other certificate on the device but got another error.

Microsoft Activesync. You have an incorrect SSL certificate common name in the Host Name field. For example, you may have entered www.tailspintoys.com when the common name on the certificate is actually www.wingtiptoys.com. Make sure the server name is entered correctly. Support Code:80072f06.

So now the problem was the internal certificate didn't match the public DNS name. I considered manually creating a new internal certificate which included the public DNS name and went as far as finding a couple of utilities, makecert and SelfSSL, and tested them in a Virtual PC environment. Although this worked it felt more complicated than was necessary considering other people had reported it working in similar environments.

The clue I needed was a response to a newsgroup post where the posters environment was nearly identical to ours except their public IP address was on the external NIC of the SBS box. I tested browsing to https://External_NIC_IP_Address/oma and was able to successfully log on to OMA.

I revised our split DNS configuration and changed the IP address that the public DNS name resolved to internally to the external NIC IP address. And Activesync now works both in the cradle and over the air.