SEMblog

Four guides for deploying Exchange 2007 are now available for download from the Microsoft Download Center.

They are all Word documents, so easily transportable.

Deploying a Standard Exchange Server 2007 Organization: http://go.microsoft.com/fwlink/?LinkId=82170
Deploying a Simple Exchange Server 2007 Organization: http://go.microsoft.com/fwlink/?LinkId=82171
Deploying a Large Exchange Server 2007 Organization: http://go.microsoft.com/fwlink/?LinkId=82172
Deploying a Complex Exchange Server 2007 Organization: http://go.microsoft.com/fwlink/?LinkId=82173
However I don't think you will be printing them out unless you really hate trees or own stock in your printer supplies company. The "Simple" guide alone is over 470 pages, the complex guide is almost 700!

As email becomes more critical to a company the issue of what happens with email if the server or internet connection fails is often raised.
One solution that is frequently mentioned is backup MX services. This is where a server located elsewhere is listed in your MX records with a higher MX value. The theory being that in the event of your server being available, the backup server will collect your email and then pass it on once the server has returned.
However a backup MX service will cause you grief outside of the times when it becomes useful, which basically makes the disadvantages outweigh the advantages considerably.
If you are having significant outages where a backup service becomes important to your business then you need to review the overall service of the primary server. A backup MX service should be something that is never used - or used once or twice a year at most.

What is the problem with Backup MX Services?

The number one problem with backup MX services is the fact that most spam goes to the higher MX records. Spammers have worked out that most higher MX records will not have the same level of spam protection and there is a higher chance of their message getting delivered.
As the most effective anti spam methods block the spam at the point of delivery, if you have the messages going through another server then you cannot use any of those methods. The only methods of dealing with spam is the traditional detection methods - which struggle with image based spam.
Furthermore dropping email delivered to non-existent users is almost impossible. Depending on the backup MX service that you use, they may insist on your server accepting all email, then dealing with it once it has been delivered. As most spam is spoofed, that means finding some way of dropping the messages once it has been delivered.

Do you need a backup solution at all?

SMTP email delivery has some robustness built in. Most email servers will attempt to deliver email for 48 hours, so as long as you can get something else in place in that time window you are fine. I work on the theory that if you cannot get an alternative solution in place in 48 hours then you have bigger problems to worry about.

Alternative Server Solutions

The way that I prefer to work is to put something in place in the event of something happening. I can have an alternative email service in place in less than 30 minutes. Obviously that is only setup if the outage is confirmed as being many hours or even days. If it is simply a power failure then I don't tend to bother.
However the biggest hurdle with dealing with alternative server solutions that are put in place after the event is DNS replication.
To get round the DNS issue, I use a dynamic DNS service.
I have my own domain registered with one of the dynamic DNS service providers. Each client has a host in my domain with that service and that host is pointing to their existing mail server's IP address. You could use one of the dynamic DNS provider's domains if you don't have a spare domain to use.
The host appears in their MX records.
Thus:
mail.domain.com cost: 10
client.mydomain.net cost: 20
mail.domain.com type: A IP Address: 123.123.123.123
client.mydomain.net type: A IP Address: 123.123.123.123
Note that both IP addresses are the same at this time.
In the event of a failure, I simply switch the dynamic DNS IP address to the address of the alternative server. That IP address change is live in less than 20 minutes, usually within two or three minutes, as the dynamic DNS services are configured for frequent changes to the IP addresses and make them accessible across the internet very quickly.
As the host is already in the DNS for the client's domain, I don't have to wait for any DNS changes to propagate.
When the primary server is available, the dynamic DNS host is switched back.

Alternative Server Software

For an alternative server, pretty much anything that supports SMTP can be used.
IIS makes a very good queueing only server. Someone with some asp skills could easily knock up a front-end that allows the messages in the queue to be viewed with a standard web browser. Access would need to be very restricted as it would show all messages in the queues.
You could even sign up with a host and create accounts in their email package. As long as the host has a decent web based front end for the email the end users can work with their email. When service is resumed, export the email to PST files and import it in to the mailbox.
If you are going to use a host, try and find one that supports IMAP connections. Then restrict the users to web based access and configure the server to store a copy of the sent items. That will ensure that you can download and import sent and received items in to Exchange when the server is available.

The Key is Forward Planning

As with many system failure procedures, the key is forward planning. By getting the DNS changes made in advance, you can reduce the downtime for email considerably, resulting in less downtime for your end users.  While it may not be a perfect solution, it will give you access to the email allowing phone calls to be made and business to operate - if not at optimum levels.

Scott Schnoll is reporting on his blog (http://blogs.technet.com/scottschnoll/archive/2007/01/24/exchange-2007-32-bit-management-tools-available-for-download.aspx) that Microsoft have released 32 bit management tools for Exchange 2007. This allows you to manage Exchange remotely in the same way that you could by installing Exchange 2003/2000 system tools on to other machines.

However the download is almost 700mb!

Apparently it includes the help file, the best practises tool, the help file etc.

Download the tools from here:

http://www.microsoft.com/downloads/details.aspx?FamilyID=6be38633-7248-4532-929b-76e9c677e802&DisplayLang=en

What the download does not include is the additional tools that you need to install first…

MMC 3.0
Net Framework 2.0 (plus an update)
Powershell

So you will need to download those.
Use the links I posted on my blog a little while ago (http://blog.sembee.co.uk/archive/2007/01/15/32.aspx).
If you installing the Exchange tools on Windows XP, make sure that you get the XP versions of the additional components, as the Windows 2003 versions do not install on XP.

You also need to install the core components of IIS. For Windows XP this is just 1mb, which is installed through Add/Remove Programs, Windows Components. Go in to IIS and choose "Common Files".

The installation defaults to Typical, which includes some server roles, which is very odd. You will need to change to custom installation and then select just the management tools.

Once installed, there is no change in the functionality - it is the same as the tools on the server itself.

http://blogs.technet.com/scottschnoll/archive/2007/01/24/exchange-2007-32-bit-management-tools-available-for-download.aspx

For the second year in a row, I have been named Expert of the year at Experts Exchange.
This is the third year I have one of the three prizes. I was Rookie of the year in 2005, Expert of the Year and Most Questions Answered last year and Expert of the Year again this year.

http://www.experts-exchange.com/expertAwards2007.jsp

I have also just crossed the 13 million points barrier.

If you haven't used Experts Exchange before, then you are missing out.
Despite how the site has been setup, it is free to join. If you answer questions, and earn 10,000 points (which can be earned by answering as few as 5 questions worth 500 points (there is a multiplier involved)) in a month, then 3,000 points every month thereafter, you will have full access to the site without having to pay anything.

30th May 2008
There is a new post elsewhere on this blog that I believe makes this post redudant. As SAN/UC certificates have come down in price it makes more sense to use those rather than the method I have outlined below. Furthermore this process does not work on Windows 2008 and Microsoft do not support Outlook Anywhere outside of the default web site.
To see the updated blog posting click here: http://blog.sembee.co.uk/archive/2008/05/30/78.aspx 

I will leave this post here for reference, but I suggest that you deploy a SAN/UC certificate using the guide I have written above.

1st October 2007
I am aware that at least one SSL vendor is sending some customers to this blog posting when asked about deploying their certificates with Exchange 2007. If you have been sent here by a vendor, then you should ask them why they are sending you to a blog rather than assisting you with resolving the problem.

Remember that this is one solution to the problem, and it is not a solution that Microsoft recommend. I have found that it works, but that does not mean it is the ONLY solution.

As of the time of writing this section (1st October 2007) it is still the way that I deploy Exchange 2007 and have found that it works. I constantly review my techniques and will change the article if I believe there is a better way.

If you care about network security, you will want to use SSL certificates with your Exchange deployment. SSL certificates could be used with OWA, Outlook Anywhere, ActiveSync and the Autodiscover Service.
However as you will quickly find, SSL Certificates for use with Exchange 2007 is a mess.

When Exchange 2007 is initially installed, the installation wizard creates a self generated SSL certificate for the default web site. While this is fine for initial use, you will quickly want to replace it with a commercial certificate to avoid certificate warnings when users browse to the OWA site and to avoid complications deploying Windows Mobile handhelds.

(I have discussed the reasons to use a commercial SSL certificate on my blog last year: http://blog.sembee.co.uk/archive/2006/03/05/Self-Generated-versus-Commercial-SSL-Certificates.aspx).

With Exchange 2003 it was quite simple to deploy a commercial certificate, simply request and deploy a certificate with your chosen external name. If you wanted the same name to work inside, then you would also configure split DNS (http://www.amset.info/netadmin/split-dns.asp).

If you remove the default certificate with Exchange 2007, it will initially appear to work. If your clients are on Outlook 2003, then most things will work correctly.

However when you introduce Outlook 2007, the complications start.

Outlook 2007 is the first client to support the new web based method of Address Book distribution. Previous versions of Outlook used system folders, part of the public folder structure. Microsoft have made no secret of their desire to kill off public folders and the change in address book distribution is a key step towards that goal.

If you replace the SSL certificate with a certificate that does not match the server's real name, then Outlook 2007 generates a certificate warning when it connects to your server on the LAN. It is expecting the SSL certificate to be on the server's real name.
However best practise for certificates is to use a generic name. You may also be in a position where the server's real name ends in .local.

Therefore you need a certificate that supports the additional name.

On a side issue - you will note that Outlook does not generate a warning message on your self generated certificate, which will not be trusted by the client. It has been confirmed that Outlook does not check the trust status when connecting to Exchange on the internal network.

Then you get the complication of the autodiscover service, which is new for Outlook 2007. That connects to autodiscover.domain.com (where domain.com is the domain name in your email address). Therefore your SSL certificate on host.domain.com will not be accepted because it doesn't match the address being accessed.

If you are fortunate enough to be using the same domain name for your AD domain, as your primary email domain, which is also accessible from outside (domain.com), then you might be thinking at this point to purchase a wildcard certificate - so that *.domain.com would work.
That would be fine, but if you want to support Windows Mobile devices, then you will need to think again, as Windows Mobile does not support wildcard SSL certificates.

Therefore what is the solution?

You could look to purchase an SSL certificate that supports the additional names. However none of the cheap SSL certificate providers (RapidSSL and GoDaddy) issue certificates that allow you to have the additional names. The only certificate that I have found that does is one of the US$600 certificates from Geotrust. Having to pay $600 for a certificate just to secure OWA seems very expensive and is not something that many sites will accept.

Therefore the resolution to this problem I have found is to use multiple web sites.

This isn't as hard as it may sound and I will give you the brief steps here. (More comprehensive instructions will appear on the amset.info web site at some point in the future).

1. Setup Outlook Anywhere as required. This is important as it is the one feature that cannot have its virtual directory recreated using the Exchange Management Shell.
   
2. Add an additional internal IP addresses to your Exchange server's network card. For example, if 192.168.1.1 was the default address for the server, you would add 192.168.1.2 as an additional address. It does not have to be the next address, just as long as it is on the same subnet (192.168.1.x)
   You need additional IP addresses as you cannot use host headers with SSL.
   
3. Adjust the configuration of IIS so that the default IP address is bound to the default web site. This is a change from the "All unassigned" setting.
   
4. Create a new web site in IIS Manager. In this example I will call it External. Set it to use the additional IP address, using the default ports. When asked for the path, use the same as the default (C:\Inetpub\wwwroot). When asked for permissions, select Read and Run Scripts only.
   
5. Open the Exchange Management Shell and run the following commands:
   If you are supporting Exchange 2007 Mailboxes ONLY:
   
   New-OWAVirtualDirectory -OwaVersion:Exchange2007 -Name "owa" -WebSite "External"
   
   If you are also supporting Exchange 2003 mailboxes, then you need to run these additional commands:
   
   New-OwaVirtualDirectory -OwaVersion:"Exchange2003or2000" -Name "Exchange" -WebSite "External" -VirtualDirectoryType:Mailboxes
   
   New-OwaVirtualDirectory -OwaVersion:"Exchange2003or2000" -Name "Public" -WebSite "External" -VirtualDirectoryType:PublicFolders
   
   New-OwaVirtualDirectory -OwaVersion:"Exchange2003or2000" -Name "Exadmin" -WebSite "External" -VirtualDirectoryType:Exadmin
   
   New-OwaVirtualDirectory -OwaVersion:"Exchange2003or2000" -Name "Exchweb" -WebSite "External" -VirtualDirectoryType:Exchweb
   
   For ActiveSync, run the following command:
   
   New-ActiveSyncVirtualDirectory -WebSiteName "External"
   
   When you refresh the configuration in Exchange Management Console, you should see two sets of virtual directories under Server Configuration, Client Access, Outlook Web Access and Exchange ActiveSync.
   
6. To add Outlook Anywhere to the web site, open up IIS Manager. In the default web site, find the /rpc virtual directory. Right click on it and choose All Tasks, Save Configuration to a File… and save the configuration.
   Then on the new web site that you have just created, right click on the root and choose New, Virtual Directory (from file)…
   When prompted select the file that you exported from the default web site.
   
   Important note - any configuration changes to Outlook Anywhere do not appear to be reflected in this exported file, so it is important that any configuration is done before the export/import. If you make any changes to the Outlook Anywhere configuration then the export/import will need to be repeated. Delete the imported virtual directory and replace it with a freshly exported configuration file.
   
7. Once you have created the virtual directories, you can then put an SSL certificate on to the new web site and then point external traffic to that address.
   Internal traffic can also be pointed to the new web site.
   Leave the self generated certificate on the default web site, as Outlook 2007 will continue to connect to it.

Autodiscover Service

For Autodiscover, you actually have two options.

1. Repeat the above process, with a new dedicated web site for autodiscover.
   The command for a new Autodiscover virtual directory is
   
   New-AutodiscoverVirtualDirectory -Websitename Autodiscover -BasicAuthentication:$true -WindowsAuthentication:$true
   
   That web site can then get its own SSL certificate.
   This could be useful if you use two different domains, one for email and one for external facing web services. Autodiscover uses the same domain as your email.
   However if you have multiple domains for email, you will need to use the redirect method.
   
2. Add to the external web site and configure a redirect.

To add the Autodiscover virtual directory to the External web site created in above:

New-AutodiscoverVirtualDirectory -Websitename External -BasicAuthentication:$true -WindowsAuthentication:$true

The redirection configuration is very important to ensure that it works correctly. The redirection method requires port 80 (http) traffic to come in. For internal traffic that is fine, but for external traffic you may want to look at a way of configuring the redirection using a public web site.

At the time of writing, this is Microsoft's article on redirection. It is covered under the section Hosted Environments and the Autodiscover Service, but would also be useful if you have more than one domain, or you use a different domain for email than you do for external facing web services.

http://www.microsoft.com/technet/prodtechnol/exchange/e2k7help/4172728f-bb70-4579-9d5d-fccdd4afcd80.mspx?mfr=true

Conclusion

Your control over the web services of Exchange 2007 provides you with many more options for using SSL than Exchange 2003. Unlike Exchange 2003, with the exception of Outlook Anywhere, these options are provided as part of the product, allowing you to use them with the confidence that they should work as expected and can be managed with other features of Exchange.