Background

Environment is a domain environment with a 2003 Exchange Server (Std Ed) and a separate POP/SMTP server with about 200 users. Datastore size is getting close to 70 GB. We decided to add an Exchange 2010 server and migrate the users to it.

Only some users were using the Exchange Server. Most users were using the POP/SMTP server as their only e-mail server. In the beginning the Exchange Server was installed to only support Blackberry Users and a couple of users that needed to share calenders. Overall this setup proved to be very stable. To make this work properly, the old exchange server was configured to not be authoritative for the main domain. This means that whenever an e-mail is received by the exchange server and the recipients address is not know to the exchange server it does not generate an undeliverable message. Instead it sends the message to the next server, in this case the POP/SMTP server and it decides if the address is valid or not. There is a little more to this part of the setup but that is not what this blog entry is all about. Just be aware that if you have a configuration like the one I am describing above, you will not be able to successfully add another Exchange Server and migrate your users to it while maintaining mail flow for users on all three servers, i.e. the POP/SMTP, the old Exchange and the new Exchange Server at the same time. You will be forced to get the stand alone POP/SMTP server out of the loop prior to doing the Exchange Upgrade. So at this point, assume a single Exchange Server (2003 in our case) that is the final authority for e-mail delivery to the domain and that the server works normally (if there is such as thing for Microsoft products.)

The Upgrade

I'm sure that you probably already know that there is no true Upgrade per se for Exchange. The Operating System requirements etc. are different and given the complexity of the install, I can assure you that you do not want this installation to crash half way through and thereby messing up your old setup and not giving you new functional e-mail server. For most of us that would be a bad day. The good thing with Exchange 2007 and 2010 is that when you are done adding the server to the environment, your old server is still humming and for the most part the configuration on it is not even touched. There are many changes to the Active Directory Structure and there are a couple of new routing groups added to the old machine but that's pretty much it. There are many documents that talks about the upgrade process so I'm not going to dig deep into that process either. Instead I'm going to talk about some nagging problems that people encounter after they think that everything they have done is correct and that the installation is complete and successful.

Problem Types

There are several categories of problems that are coming up time after time. There are some differences between how Exchange 2007 and Exchange 2010 works when it comes to some of these potential problems. I'm only going discuss this from Exchange 2010 point of view because if you follow those guidelines it will work on Exchange 2007 but not the other way around.

SSL Certificates

You must use an SSL Certificate from a Trusted Source. The cheapest, hassle free source for this that I have found is GoDaddy. Their help is good and their support is good. This coupled with a low price made them my favorite. You must also use a UCC Certificate. It will allow you to add something called "Subject Alternative Names" or SAN. As you probably know, an SSL certificate has an association with the server's hardware and its DNS name. For instance if the server is called EXCH2 and it's on ACME.COM domain, the FQDN is EXCH2.ACME.COM. The SSL Certificate's Common Name (CN) should be issued to EXCH2.ACME.COM and the organization (O) should be the same. I then normally set up both internal and external DNS so that they resolve correctly when using this Common Name. If you are running an Exchange 2007 server this would be sufficient in nearly all instances and especially if your Domain's function level is held back to Windows 2000 Native Mode but for 2010 this isn't good enough.

You must add Subject Alternative Names (SAN) to the certificate. In order to do this you must pay the extra money for the UCC Certificate. You should add the following SAN's:

  • legacy.acme.com
  • acme.com
  • autodiscover.acme.com

All three are important and especially the bottom two. When you have imported the certificate, associate the certificate with IIS, POP, SMTP and IMAP. Get this right or you will have problems with iPhones, Out of Office alerts etc.

Exchange Installation Prerequisites

There are specific windows features that must be installed for Exchange to work correctly. What is sad is that the many of these are not discovered by Exchange's Best Practice Analyzer. The good thing is that some of these items can be installed after the fact. The easiest is to do it before you start the Exchange Install. Here is a monster command but it'll get the job done:

Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy

If you have already installed exchange, many of these are going to be installed already in which case you are better off using more of a "surgical method". Instead of this command, try to install Window Authentication, Basic Authentication, Digest Authentication, Dynamic Content Compression and IIS6 Management Compatibillity and all subcomponents including the IIS 6 Management Console. In the Server Manager for Windows 2008 you go to the IIS section and these "Role Enhancements" are addded by clicking the "Add Role Service" link. Take your time and make sure you cover all the bases. The components that deals with authentication are super critical for a smoothly functioning end product. What is odd is that you can get everything to almost work without all of these prerequisites. A common problem is that when you start Outlook, a dialog box pops up asking for your windows credentials. It gives you an option to save them but they do not seam to stick. This is typically a problem where the Autodicover Service is trying to talk to IIS and authentication is not working correctly. If you look at the Authentication section for the "Autodiscover" folder under IIS you should see Windows and Basic Authentication Enabled. If You don't see them, the roles are simply not installed.

If you have problems with "Out of Office Assistant" we are normally on the same track as in the above discussion. Is the certificate correct? Are the prerequisites installed, especially the ones dealing with security and authentication. If you go under IIS on the exchange server, locate the EWS folder and verify its security settings too. It should be the same as the settings you find under the Autodiscover folder's security settings.

If you are here, with a correct SSL certificate and all prerequisites including the ones listed above, you would need to take a deeper dive into DNS and firewall settings. A good tool to use when testing these things can be found at: http://www.testexchangeconnectivity.com. It is free service hosted by Microsoft. It'll mimic many of Outlook's features and report on the results. You are also encouraged to turn on loggin in Outlook. In many cases it will not report much when it comes to security issues but occationally it will give you a hint. Another good tool when trouble shooting is the "Test e-mail Autoconfiguration" and "Connection Status" tools in Outlook. You can get to these tools by clicking on the Outlook icon in the task bar while you hold down the CTRL key on the keyboard. A menu pops up and both of these tools are listed on that menu.

Tags:Software Windows Solutions

Mike Lundstrom


Related Posts