Devin on Earth

A month ago, I posted about some of the limitations of Windows Mobile 5.0’s handling of certificates. In the comments, Exchange MVP Ben Winzenz informed me about a registry hack you can perform on your WM5.0 device that disables certificate checking. He posted more details on his own blog. This is pretty cool stuff, because it allows you to get SSL working even if your device doesn’t have the root certificate used by your Exchange SSL cert, or if you’re using a wildcard cert for Exchange (which many companies do).

However, there’s still a fly in the ointment — and that is that not everyone is going to be able to get to the registry. Ben and I are both using unlocked devices that give us management access to everything we need — the registry, the Trusted certficate store (so we can load new trusted root certificates), RAPI for firmware updates — to completely control our devices. Many of the users who will be buying devices from Verizon, T-Mobile, Cingular, and other carriers won’t be so lucky. Their devices will be locked; they won’t be able to mess with the registry, and many carriers are not rolling out the utilities to update the root certificate store, so they’ll be stuck with whatever CAs the carriers see fit to include.

Windows Mobile 5.0 is a great step forward, don’t get me wrong. I use it and love it, especially now that I have upgraded to the MSFP. However, it is important to remember the business model used for WM differs from standard Windows. Windows Mobile is not sold to end-users; it is sold to device manufacturers and telco carriers/operators. They are the ones who decide what the final feature loadout will be and how the devices will be configured, not the people who purchase them.

The moral of the story? Choose your OEMs and carriers carefully. Get test units and make sure you’re going to be able to get all the features you need working before doing a full deployment. If your carrier doesn’t offer a configuration that meets your needs — or won’t work with you to get the tools you need to modify the configuration — then find someone who does.

Sooner or later as an Exchange admin, you want to disable a mailbox-enabled user account in Active Directory while keeping the associated mailbox intact. Up until now, this caused problems, because as soon as the account was disabled, any mail sent to that alias (or any DL containing that alias) would generate an NDR and a 9548 event ID.

Fatal? No. Pain in the butt? Definitely. In some cases it could cause performance issues, the NDRs were annoying and confusing for non-technical users, and the constant nagging in the event log irritated admins left and right.

In fact, it was a widespread enough problem that Alex Seigler of Microsoft wrote the NoMAS tool, which is available from Microsoft PSS. This tool automatically populates the msExchMasterAccountSid attribute on disabled user accounts.

With this new hotfix, Exchange’s internal logic has been changed to automatically act as if the msExchMasterAccountSid attribute on a disabled account contains the SELF well-known SID if account doesn’t have the attribute already defined.

Note: this hotfix is currently available only for Exchange 2003 SP1; you can’t apply this to systems that are already running SP2. A SP2 version is expected soon.

Alex has written a blog article on the MS Exchange team blog about this if you want more detail. Note that the original article doesn’t state that this hotfix is for SP1 only; you have to read down in the comments to see that. I also don’t see any indication that this hotfix will be available for Exchange 2000…and I’m not holding my breath. Still, this is a welcome hotfix, and it’s a simple no-charge call in to PSS to get it.

Paul, Missy, and I will all be speakers at this spring’s Exchange Connections 2006 conference, held at the Walt Disney Swan Hotel in sunny Orlando this April 9-12. Not only will we have 8 sessions of Exchange goodness to share with you, we’ll also be having a book signing at the conference bookstore. Come find us at 3:30pm on Monday, April 10th — if you’re going to be at Connections, I’d love to hear from you!