Complexity of Microsoft Exchange bites us again
Recently I've been involved with a migration from one Exchange 2010 server to another, and the project is still ongoing at the moment. I've written before about how overly complicated Exchange is, when compared to other open source mail server alternatives. I came across more examples of how Exchange and Outlook have caused a large increase in help desk calls, because of features of Exchange that are complex and shouldn't really be there for an email server.
One Exchange 2010 server is in an old Windows domain, and another Exchange 2010 server is in a new Windows domain. The reason? The domain name is being changed. It was decided to bring up a new domain in parallel, and migrate users over time to the new domain. This is a huge multi-month project, as the more PCs and servers and members of the domain that there are, the more complex a domain change can be. So far, the two Exchange servers are happy and we have them sending and receiving mail to/from each other just fine. But, there are some quirks with Outlook that have caused much grief.
- Outlook autocomplete. This is the feature that saves previous email addresses in the "To" field in Outlook, so that if you type in some characters in the To field, it will show a list of recipients that you have previously sent to. This sounds like a great feature, but believe it or not causes a high number of help desk calls. Why? Because for some reason, Outlook stores these entries however it also identifies them via unique address book entries with X500. Yes, I did say X500. For some unknown reason, even with the latest version of Exchange 2010, X500 is still used. So, in our case where users are migrated from one Exchange organization to another, autocomplete breaks because the object that is still stored in the autocomplete list doesn't exist on the new Exchange server, even though we have both servers synchronized with the Global Address list. We've replicated the Global Address List from the old Exchange server to the new one, shouldn't that get it working? Nope. If a user sends to an entry in the autocomplete list in Outlook, they will get an undeliverable message back. Even though the Global Address List has an entry for the same exact entry and SMTP address on the new Exchange server. This means that when moving to a new Exchange server, entries contained in the autocomplete list in Outlook become invalid. This also happens when deleting and recreating objects in Active Directory. Very confusing and very difficult to fix. So far, our best fix is to search for any .NK2 files in the users' profiles on each and every PC, and delete it. This allows Outlook to build a new autocomplete list based on entries in the Global Address list from the new Exchange server and get rid of stale entries still hanging around. One of my colleagues and myself have compared Exchange to open source IMAP servers and Thunderbird, where everything is strictly using SMTP. In that scenario, none of these issues exist because the email software associates objects by their SMTP address, not Active Directory and X500 entries. This greatly simplifies the overall structure and especially makes migrating from one mail server to another a very smooth process.
- Outlook Offline Address Book. This one has caused us grief in the past. The Offline Address Book (or OAB), is an offline copy of the Global Address list in Exchange. When updates are made to the Global Address list, by default it the offline copy of it (OAB) gets regenerated at 4 AM every night, then Outlook selects a random time once per day to download its copy of the OAB. Making updates to this can cause us grief because changes can take up to 24 hours or more for clients to see them. We've found that forcing the OAB to generate in Exchange helps, but then there's the delay of Outlook randomly downloading its copy of it. With this Exchange server change, we've found that as soon as the users were switched from one Exchange server to another, their Outlook refused to download a new copy of the OAB from the new Exchange server they were moved to. This issue is still not resolved. One option is a registry change that forces Outlook to always look at the online version of the Global Address list, therefore bypassing the OAB or offline copy and getting a live list. But, this is not the recommendation from Microsoft. It's hard to say which method is correct, without further load testing on the Exchange server. Again, my colleague and I recall using Thunderbird with open source mail servers that use LDAP, and Thunderbird can query LDAP directly by default (similar to the registry fix for Outlook mentioned above). But, in the case of Thunderbird, no registry fixes are needed to make it work, it works out of the box.
- Synchronizing phones with Exchange. This has worked for the most part, despite some early problems with Android phones and compatibility with Exchange. But, recently another ugly issue popped up where a couple users started seeing multiple calendars appear on their phones. It turned out that in their Exchange mailbox, they had their main default Calendar folder, but within that folder sat two additional calendar folders. How and why? Nobody knows to this day as we've not been able to reproduce the issue. Since we've had the issue with more than one user and more than one phone type, we are led to believe it's an Exchange problem. Again, my colleague and I have seen far less issues with mobile phones synchronizing with open source IMAP servers that work in a similar fashion. This problem certainly has not come up with the open source mail server alternatives.
- Exchange service pack levels. In Exchange 2010, it seems that the build levels for Exchange server must match the build level of any computers running the Exchange management tools. So, if you install a service pack on either the server or the clients, and that build version changes on either side, the Exchange management tools will no longer be able to connect to the Exchange server. Luckily, the tools on the server continue to work since the tools and server components are on the same box. While this doesn't sound like a major issue, it is not, but it's a very inconvenient one when trying to install a service pack for Exchange, knowing that each and every PC that runs the tools needs to be upgraded otherwise the tools will break for them.
Overall, when looking at Help Desk calls, Outlook is the number one program that needs troubleshooting more than any other program used. It was originally thought that the calls were all related to training issues, but after further investigation, it was found that the issues are all software problems.