This last couple weeks I’ve been slowly setting up a new install of Exchange 2010. Needless to say, it was a very interesting experience. My job description may not be “Administrator” but I do enjoy setting up systems like that. Even more-so when it adds structure to an organization, like I feel Exchange does.
Google apps is very powerful and comparable to Exchange these days, and is becoming even more powerful as they continue working on the product suite. However, the fact that google still calls most of their products “beta” is bothersome to me. If they are calling it beta just so that they can make updates to the products whenever they want, that’s pretty lame. Isn’t that a reason to make an application web-based, instead of a desktop app? But regardless, the feature-set is still unpolished compared to Exchange (especially 2010).
In any event, here are some things I discovered when setting up Exchange that MIGHT help the next person along:
- Exchange relies heavily on having DNS properly setup. In the environment I setup, the server it is running on is also a domain controller, which has its own DNS role. When you are in the install screens of Exchange, it will ask you for a public address to host Exchange on, to which I entered mail.XXX.com. However, in my case, I forgot that the DNS entry didn’t exist yet for the mail host. So, when Exchange setup finished, it gave an error saying it couldn’t start, and then displayed a very odd, seemingly random error message. This was because the domain controller was relying on itself (not public DNS records) to determine where mail.XXX.com was. Once I added the mail host record to the DNS entries on the domain controller, this issue disappeared and the services would start up. This may seem obvious to some, but myself AND a seasoned Exchange administrator couldn’t figure this out for at least an hour; and it pretty seriously delayed the entire install process. In addition to this, you might still experience problems if you don’t flush your DNS after adding the host record to the DNS entries on the domain controller.
- The Windows 2008 OS was installed on a VM hosted by a VMWare server, which didn’t have DHCP for IPv6. Interestingly enough, setting up the server as a domain controller required that IPv6 have a static address or be turned off, so I turned off IPv6 since I wasn’t going to use it anyways (so I thought). However, I later discovered that another error I received was simply due to having IPv6 disabled. Make sure any IPv6 interfaces you have are turned on, regardless of whether you assigned it an IP staticly or dynamically.
- IIS was hosting a website prior to installing Exchange. Once Exchange was done installing, I found that the website was inaccessible. This was because Exchange turned on the “Require SSL” feature of the default website. It is perfectly find to turn of “Require SSL”, it won’t break anything.
- One major feature I find with Exchange, is that Outlook users can have their email accounts automatically setup by just providing an email address and password. In order for this feature to work, I found that I had to have an “autodiscover” public DNS entry for my domain (Ex: autodiscover.mydomain.com) which also pointed to my server. Microsoft documentation SAYS that it should work without the DNS record, but I didn’t experience the same results.
- Install your SSL certificates through Exchange Management Console, not through the MMC or through IIS. The EMC will automatically set the certificate up for IIS and the rest of your server, pretty much hassle-free.
- In order for calendars to be publicly shared via ical files, I had to install “Federated Trust”. It is not exactly obvious where this feature is located… I found it directly in the Exchange Management Console’s “Organization” node. Setting up federated trust will require you to have a valid SSL certificate from a valid certificate authority (such as Verisign or Godaddy) and it will require you to add a TXT record to the DNS that the Exchange server uses.
A few weeks ago I made a standards expert a little angry by saying that Exchange was a standard. They’re argument was that Exchange wasn’t recognized as a standard by any primary standards organization. Well, although that’s true, Exchange is recognized by almost every good smart-phone out there, is supported by several desktop mail clients (even the iPad supports Exchange), google apps supports the exchange “feature” to provide synchronization of calendar and contacts, and the list goes on. So, if the only problem is that it hasn’t been deemed a standard from a major standards organization, then they should get on it, because quite a few others are treating it like a standard (and for good reason, as far as I’m concerned).
Overall, Exchange is awesome! I’m excited to have it put to use in our organization as I think it will add a lot of benefit.