The Exchange development team do not offer any in-place upgrade from Exchange Server 2007 or previous versions. The option was dropped for Exchange2007 because, for the first time, it was available only as a 64-bit release. Microsoft thus opted to force a clean installation.
It seems that while this may have caused mild stress or inconvenience to Windows server admins the Exchange developers themselves felt it relieved such a burden by not having to ensure the many possible upgrade routes would work. As such they've brought this into Exchange 2010 too.
As such, there will be young admins out there installing Exchange server for the first time and will be confronted by the perennial problem of certifying authorities.
Exchange is no different from web servers, commerce servers and other products which perform sensitive online communications and transactions. It's essential that security and privacy is maintained, and that users can trust the server they're dealing with is trustworthy.
Here is where secure socket layer (SSL) certificates come in to play. Here is why and how to get one.
To use Exchange's 'Outlook Anywhere' (formerly known as RPC over HTTP) and secure OWA (Outlook Web App, formerly known as Outlook Web Access) you really need a third-party certificate from a trusted certifying authority.
To buy a certificate you need to find a reputable seller. Digicert, Verisign, Thawte and others are well known and safe choices.
I've been using DigiCert because I find them straightforward to use with helpful explanatory processes. I have no relationship to DigiCert so you should find one you are comfortable with and compare prices. The instructions following ought to be largely similar irrespective of the certifying authority you use.
To begin, choose the certificate type you are interested in. The lowest price option generally includes one single name (eg mail.domain.com) but for maximum compatibility you will want a SAN certificate for Exchange Server, which DigiCert list under Unified Communications.
This is because your server has a number of identities. For one, it has a local, internal network, name, typically of the form server.domain.local. It also has the public-facing Internet fully qualified domain name (FQDN) of mail.domain.com and possibly others if you host other domains or use different aliases.
If you are using Outlook Anywhere you will also want to ensure your certificate includes autodiscover.domain.com, which also ought to be registered as a valid address in your DNS zone.
After choosing the type of certificate you will be asked to list the FQDNs you need to cater for. Be sure to include the variations above, namely mail.domain.com, server.domain.local, autodiscover.domain.com and any others.
DigiCert helpfully provides a tool to create the necessary PowerShell command for Exchange 2007 and Exchange 2010.
This command will be of the form
New-ExchangeCertificate -GenerateRequest -KeySize 2048 -SubjectName "c=US, s=TX, l=Houston, o=Company Name, cn=mail.domain.com " -DomainName server.domain.local, autodiscover.domain.com -PrivateKeyExportable $True
depending on the FQDNs you supply.
Open an Exchange shell window and paste this in. You will be greeted with a response that contains rows of coded text. Copy this by using the console window's Mark/Copy option. Paste it into your certificate provider's CSR entry box.
After submitting the CSR you need to wait. Any good certifier will perform tests to verify you have the authority to be ordering such a certificate. How this happens may vary but should generally include a request for confirmation addressed to the postmaster address of the domain in question, or to the authorised contact listed in its domain registration.
If all proceeds efficiently, you will receive a zip file contained your certificate file (a .cer file) by e-mail.
Users may double-click on this certificate to install it on their computers or it can be pushed out automatically via group policy.
Of course, having client computers accept the certificate is only part of the equation; your server must also issue it.
Again you can refer to instructions online for Exchange Server 2007 and Exchange Server 2010. Actually, the Exchange Server 2007 instructions are PowerShell commands which work for both 2007 and 2010 but 2010 also offers a GUI method.
The next time your users try to access your Exchange server from somewhere on the Internet, out of the office, they'll find it to be business as usual, with full continuity and no strange errors or disruptions.
For you, the admin, the only remaining task is to note one year ahead in your calendar so that you renew the certificate and ensure no downtime.