Get wild with wildcard certificates

Most organizations that are considering securing their email systems are also looking at SSL certificates to aid in that effort.  Security certificates allow for encrypted communications using Outlook Web Access, Outlook Anywhere (RPC over HTTPS) and ActiveSync devices like Windows Mobile Smartphones. The issue is that a normal SSL certificate is bound to a single server, which means you'd have to obtain a signed certificate from a provider for each server you want to put into the solution.

You could use self-signed certificates to get around the issue of having to purchase individual certificates, but only at a cost.  Many applications will not accept self-signed certificates, and even Microsoft-controlled systems like OWA will kick up several layers of security errors - which will increase support headaches for you and your staff.

Alternately, you can obtain a Wildcard Certificate from a provider, which will allow you to use one certificate for multiple servers in your organization.  These certificates are more expensive than single-server options, but can give you much more flexibility with things like server rebuilds, migrations, and failover.  The only restriction is that the servers will have to be part of the same organization. That means that all the servers will have to be part of the same domain and/or forest in the sense of Active Directory.

Wildcard certificates can be defined at either the organizational level - such as *.wildcarddomain.com - or masked at another level, www*.wildcarddomain.com for example.  With the first example, all server identities that are part of wilddcarddomain.com will be able to share the certificate.  In the second, www1, www2 and even wwweb.wildcarddomain.com will be able to share the masked certificate.  Which you use will depend on the depth of security you are looking to implement, as more specific masks allow for less chance of someone spoofing the certificate for a foreign machine.

Once you install the wildcard certificates, you can allow services to move between servers within the same organization without breaking security. This can be extremely helpful for both migrations and disaster recovery, as you can have both of the servers shielded under the same certificate, and therefore you will not get naming errors when the users move or fail over. 

In a worst-case scenario, you can use single-server certificates on a migration or failover target, but your end users will get errors about the certificate being valid, but assigned to a different server name than the one they are connecting to.  You can then purchase another certificate after the fact and assign it to the target server to remove the error if/when needed.  However, wildcard certificates give a much better option for flexibility to you and your team.

No x64 for you! (on Exchange 2003 that is)

A whole slew of clients has been asking me about this one, so let me set the record straight.  Exchange 2003 will *not* run on x64 OS's.  For those who do not believe me:

MSFT TechNet article on Supported OS for Exchange 2003

Which spells out:

"Note: Exchange Server 2003 does not run on 64-bit editions of Windows Server 2003."

So what does this mean?

1 - You CAN install Exchange 2003 on x64 hardware, just not on the x64 editions of Windows

2 - You CANNOT do an in-place upgrade to 2007, since that needs x64 to run in production environments

So, while you can buy new hardware safely and continue to install and run Exchange 2003 properly with an x86 OS, you can't leverage the 64-bit framework. 

Also, you can't run 2003 on Server 2008 - at least not yet.  This means that the advanced clustering and other 2008 features are not available for Exchange 2003.  It also means that if you buy a new server and get an OEM version of Windows, you will have to specify that you need Windows 2003 x86, otherwise they'll send it with 2008.

Sorry to deflate everyone's balloons at once, but hopefully this will help a few bets pay out between Exchange techies.

Dial-tone revisited

The theory of Dial-Tone Recovery (DTR) is one that has often been overlooked in the world of Disaster Recovery (DR) for Exchange Server.  However, even in Exchange 2007, DTR can provide a great method for immediate restoration of email services, though with a few things to keep in mind.

For those who haven't heard of DTR before, here's a primer:

If a primary Exchange 2000, 2003 or 2007 server fails, you can attempt to restore services by deleting the corrupted databases and re-starting Exchange services.  This will create blank databases and allow users to send and receive new mail, access new calendar items and access all shared contact information.  Running a /disasterrecovery install of Exchange on a rebuilt box with no data will do the same thing.  Though end-users can access their email systems again, there will be no historical data, so this isn't a total solution set for true DR, but gives you some options for immediate availability.

In an emergency, this can give you time to perform restoration steps - which could take quite a while to finish - without making everyone wait to get back basic send/receive capability. You can restore a copy of the historical data via several methods, taking the time you need to do it right.

If you used a brick-level tape or disk backup solution, you can restore mailboxes via that tool's recovery system. Archiving solutions and Continuous Data Recovery systems (like TimeData from Double-Take - see disclaimer below), can let you move mailbox, folder and other data back over time as well.  If neither of those tools are at your disposal, but you to have a backup of the database and logs, you can restore those to a Recovery Storage Group, and use ExMerge or Exchange 2007 tools to bring back mailbox data and merge it with the new information on the DTR-recovered server.

If no backup is available at all, you can still provide Exchange services from the point of DTR onward.  While no historical info will be available to them, the end-users will be able to send and receive new email, calendar entries and Public Folder data.

Distributed clustering plusses and minuses

In the new Server 2008 platform offering from Microsoft, another option for Failover Clustering (Multi-Site Clustering or MSC) has become available.  This is a great option for distributing a cluster amongst multiple, physical locations; but does have some limitations.  As it may be used as a platform for creating Exchange 2007 site redundancy, I'll go over some of the basic stuff here.

First and foremost, you're network will need to be ready to handle this kind of failover solution.  Since the subnet and latency limitations of 2003 clustering - for the most place - don't exist in 2008, this isn't as much of a barrier to entry as it used to be.  However, you will still need enough bandwidth to handle replication traffic, and you'll need to be able to support your end-user population when they need to work on the other side of link if the production node dies.  This is different than normal DR solution sets in that it is expected that you'll run off the secondary node at least some of the time during normal production operations, instead of only during an emergency.  So instead of preparing for only having a sub-set of users running on the other node, you'll have to be ready to have all your users running on it from time to time.

You're also going to need at least one more server in the equation to act as the File Share Witness.  FSW is a solution designed by Microsoft that can allow a cluster to arbitrate which nodes are allowed to take over if the nodes themselves suddenly can't see each other.  It's critical that the server that holds the FSW, therefore, can see both servers, and can see the correct server (the one you want to take over) in the event of a site failure.

On the subject of networking, you'll want to take a quick look at this KB article, which goes into some great tips for properly setting up DNS entries, etc:

http://support.microsoft.com/kb/947048/en-us

Now, once you have all this in place, using MSC for site redundancy is an incredible solution set.  With the right third-party tools, you can not only protect Exchange 2007 (which natively replicates via SCR), but SQL, File, IIS, and anything else that can use Server 2008 Clustering platforms. It provides both the standard cluster tool-set (now called Failover Clustering or Shared Copy Clustering), and new Network Load Balancing options in addition to the Multi-Site solutions.  For those familiar with clustering - or those who want to become familiar with it - this is a superb failover platform for any application is cluster aware.

While it's not for everyone, especially smaller IT shops that may not have Clustering expertise, MSC is a robust platform built on well-tested technologies.  It is not only a logical next-step for Microsoft, but a great way to integrate Clustering into your organization to provide for more than just single-site availability

LiveJournal Tags: Clustering Server 2008 Availability multi-site multi-subnet

.