Looking to try out Lync Mobile on Windows Phone 7, but don’t have a Windows Phone? That was my scenario when I needed to troubleshoot a sign-in issue specific to WP7. I figured it would be as easy as firing up the WP7 emulator, but there are a few roadblocks here such as the fact that a WP7 emulator exists, but you can’t access the Marketplace in it. There are some workarounds for that, but even if manage you launch the Marketplace you can’t actually sign in with a Live ID to download anything.
So, Phone7Market to the rescue. This freebie application allows you to download an app from the Marketplace and load it into the emulator. The first thing you’ll need is the Windows Phone 7 emulator so start by downloading and installing the Windows Phone 7 SDK from Microsoft.
Now that you have the SDK installed you can launch the emulator, but as you can see there’s not much you can do with it out of the box:
Next you’ll need to download and install the Phone7Market application in order to load Lync Mobile.
After installing, open the Phone7Market program and search for Lync.
Right-click the Lync 2010 result, select Quick actions, and select Deploy to Emulator.
This should launch your WP7 emulator and you’ll see the Lync 2010 application loaded for you:
Tip: Press Page Up once to enable keyboard entry from the host PC. You should be able to sign-in successfully:
Quick update here for those of you publishing Lync web services with TMG and having trouble with mobile clients:
If you’re following the Mobility load balancing requirements you’ll find that cookie-based persistence is recommended in order to ensure the clients are always directed to the same Front-End server and session. This isn’t an issue for a single FE, but once you start publishing a farm of FEs within TMG you’ll notice the Lync mobile clients can’t sign in. Android clients can for some reason, but WP7 and iPhone cannot.
The issue you’ll face is that while TMG offers you cookie persistence when publishing a web farm, it really only works when the web listener is enabled for forms-based authentication. Since the Lync Web Services cannot be published via FBA the cookie never gets inserted. The end result is that TMG will now round-robin requests between the published farm members and the mobile clients will never sign in due to a ping-pong behavior. You can verify this behavior by draining all Front-End servers from the farm except for one and you’ll see the clients can now sign in.
For a small deployment where a single FE can handle your entire user load I recommend switching your TMG persistence to source IP. All requests will hit a single FE, but the mobile clients can now maintain their session. And if an FE fails TMG will then fail over to the next server in the farm automatically. For the folks where multiple FEs are used more for capacity reasons you’ll need to use something other than TMG for publishing Lync going forward.
Recently I ran into a situation where we had purchased an Exchange certificate from a fairly common certificate authority (GeoTrust) and everything worked well with browsers automatically trusting the certificate… and then we picked up a Windows Mobile 6.0 device from Verizon. For whatever reason, Verizon or Microsoft has decided this particular CA was not trustworthy and isn’t in the default list, so ActiveSync fails to connect to the Exchange server. Fortunately, we can force the device to trust the certificate.
Windows Mobile 6.0 brought a change in how to install certificates. Users cannot install a certificate into the root certificates store on a phone unless the certificate is self-signed. This ensures that only true root certificates exist in the root store.
The pain here is that when you try installing a certificate such as the one used to secure Outlook Web Access it gets dumped in the personal store, and ActiveSync won’t connect because it can’t verify the certificate authority associated with the certificate. The solution is to get the certificate authority’s self-signed certificate into the root store. We can do this with the following steps:
Open Internet Explorer and navigate to the site securing OWA. Click the lock next to the address bar.
Click the View Certificates link.
Click the Certification Path tab at the top.
Click the top certificate name first (the root CA) and then click View Certificate.
Click the Details tab.
Click the Copy to File… button.
Click Next to start the Certificate Export Wizard.
Click Next to export the certificate as a DER encoded binary X.509 (.CER)
Browse to a location where you’d like to save the certificate and give it a name.
Click Finish to complete the Certificate Export Wizard.
You should see a dialog that the export was successful.
Now copy that .cer file you created to the device in some way. Via a storage card, USB cable, Bluetooth, whatever. Just get the .cer in the file structure of the phone somehow.
Power up the phone and click Start.
Find and open File Explorer.
Locate the .cer file you copied to the phone. I called mine root.cer.
Press Menu and then Install.
You should see a dialog that the install was successful. I’ve seen it fail on the first attempt before, so try a few times if you get an error. Press OK.
Navigate to the phone’s Settings option.
Click on Security and press OK.
Click on Certificates and press OK.
Click on Root and press OK.
Scroll to the end of the certificates list or keep pressing More. You should see the certificate you installed listed at the very end of the list. If it’s not there, try starting over and making sure you’re exporting the certificate authority’s certificate, and not yours.
You can now test ActiveSync and it should be able to connect to the Exchange server without ever needing to install your OWA certificate. It’s automatically trusted because the certificate authority now exists in your root certificates store.
