I'm not going to lie. Trying to get a Windows Mobile 6 device to activate against an RMS installation is never a highlight of my day. There are strange *quirks* with these devices that need to be accounted for. I'm going to use this post as a dumping ground for different things I've found in regards to this.
- The very first thing you need to do is go to C:\Intetpub\WWWRoot\_wmcs\Certification\MobileDeviceCertification.asmx, and go to the Security tab of its file properties. Click on the 'Advanced' button, and check the box for 'Allow inheritable permissions from parent to propogate to this object...'This will give you the correct access settings for the file, which by default, we remove.
- Make sure that from the host machine you are using to activate the device, that you can get to https://rms.domain.com/_wmcs/certification/mobiledevicecertification.asmx with *no* errors, including certificate errors.
- If your users are on laptops (i.e. will be at some point be leaving the 'Intranet' and moving to the 'Internet') you need to set the registry overrides for the location of the Licensing and Certification URLs in the registry:
Windows Registry Editor Version 5.00
- If you have an ISA publishing rule that is set to only allow authenticated users to the RMS server, change it to 'All Users', and let the RMS server handle the authentication.Honestly, I don't know why this is, but just yesterday I had a customer call and regardless of anything we tried we could not get the device to activate if ISA was handling the authentication request. The user could even get to the page from the browser. When we let the auth go straight through, and be handled by IIS on the RMS server, everything worked like a charm. UPDATE: Apparently you *can* use 'Basic Authentication' on ISA, just make sure that you forward all requests via HTTPS, otherwise you'll be sending your 'shiznit' in the clear. I'd just let the RMS server handle it though.
- If you are using a dot stuffed intranet cluster URL (i.e. rms.domain.com) you can set an exception rule on the device by going to Start>Settings>Connections>Connection>Advanced and clicking on the 'Exceptions' button. You can then add *.domain.com or rms.domain.com to the exceptions list to allow users to authenticate to the site. I believe if the name has dots in it, the device thinks it is an internet site, and will not pass creds...but I've had varying mileage out of this setting.
- Change your device setting from 'Automatic' to 'Work' mode if things aren't working. You can also try setting it from 'Work' to 'Automatic', maybe even 'Internet'. The point is that you should make sure you try all of them (disconnecting and reconnecting the device at each change), to see if any of them work for you. I have figured out neither the ryhme, nor reason why one works sometimes, but not others.
- If still a no-go, try using the short name of the server in the above registry keys. For instance if the FQDN to your RMS server is 'rms.domain.com', just set the above registry keys on the machine using just 'rms', then try to activate the machine again. This will remove the problem associated with dot stuffing. WARNING: ONCE THE DEVICE IS ACTIVATED REMOVE OR SET THIS KEY BACK TO THE ACTUAL SETTINGS. IF YOU DON'T IT WILL BREAK OFFICE ON THE LOCAL MACHINE BECAUSE THE CLUSTER URL IN THE CLC WILL MISMATCH THE REGISTRY KEYS< AND YOU WILL START GETTING ERRORS AND MULTIPLE CLCs IN YOUR DRM FOLDER.
I'll post more later, but hopefully this will get you going.
The Start>Settings>Connections>Connection>Advanced trick doesn't work for me. Are the registry overrides necessary? Windows Mobile Device Center is finding RMS via the SCP.
No. There are some known issues with authentication on these devices that I have filed a bug on. Hopefully the mobile device team will fix it soon.
Try this trick to work around it.
Create an entry in your hosts file that points a short name to your rms server like this:
Then set the registry entries as specified in this blog, but use the short name specified in the hosts file. Try to activate your device again. This is a temporary fix if it works, because if the short name doesn't match the actual cluster URL, OFfice won't like it on the machine, and will fail to obtain a local CLC.