Tooting our own horn time!

Double-Take Software's virtual systems tools (Virtual Recovery Assistant, Double-Take for Virtual Systems and Double-Take for Virtual Infrastructure) are up for Readers' Choice awards at SysCon!  As most of my readers know, I work for Double-Take Software, so I am jazzed about another potential award for us.  Back to the Exchange stuff shortly, but in the meantime, you can find out more and vote here:

Virtualization Readers Choice Awards sponsored by Sys-Con

Link to voting at http://virtualization.sys-con.com/general/vote.htm

Here are the categories we were nominated in:

· Best Application Virtualization – Double-Take and VRA

· Best P2V Migration – VRA

· Best Virtualization Platforms high Availability – VRA, Double-Take for VMware Infrastructure, Double-Take

To MTA or not to MTA?

Possibly the longest running debate in the history of Exchange 2003 is if you should disable the MTA Stacks service on an Exchange 2003 Cluster.  There are some very valid reasons to remove it, and one HUGE reason to leave it alone.

First, what is the MTA?  The Message Transfer Agent is a compatibility solution put in place by Microsoft to allow the movement of messages from Exchange 2000 and 2003 Servers (stand-alone and clustered) to other messaging platforms.  That could be an Exchange 5.5 Server, Lotus Notes, etc.  This is not the only method that could be used to move information between server platforms, but especially for 5.5 it is the preferred method.

You may be tempted to remove the MTA Stacks resource from a cluster, as it's one more resource that could go sideways on you, and it does offer an additional attack surface for those who would try to hack your system.  You may also try to remove it when you move to a pure Exchange 2003 environment, as such a configuration would seemingly not require it at all.

In theory, you'd be technically correct.  Reducing potential problems and removing avenues to attack are generally considered good things.  But an explicit ruling from Microsoft on the matter and the pain caused by the operations required to reinstall it if you need it in future can make you think twice.

The Microsoft Knowledge Base is pretty explicit that removing the MTA is not supported.  You can read about it here:

KB 810489 "MTA Stacks service supportability guidelines for Exchange 2000 Server and Exchange Server 2003"

Within that KB, along with the explicit note that removing the MTA is a bad idea, is the problem of reinstallation later on.  Most notably, if you ever want to re-install the MTA Resource, you have to delete the Exchange Virtual Server entirely (by deleting the SA Resource) and reinstall the whole EVA.  So, if you have to call into support, they'll tell you that you need the MTA resource in place. And in order to put it back in place, you have to first destroy the live clustered Exchange server.  That's a catch-22 you can avoid by not removing the MTA at all.

Long story short, keeping the MTA does offer a potential avenue for attack, but removing it creates an absolute headache if you need support later on.  For now, at least, leaving the MTA in place is a much better option - just make sure you have set up your firewall to block potential attacks!

I Luv Exchange.

Over the years that I've been working with Exchange Server, one of the more common questions I get asked is "Why Exchange?"  With all the other messaging systems out there, it's a valid inquiry.  The short answer is, "I am a masochist."

Yes, that was a joke, please do not send any more of those really weird emails my way...

So why do I stand by Exchange Server year after year, even as yet another version releases without a SQL back-end, forces hardware upgrades and has a difficult migration path?  Because - at its heart - it does what I and my clients need it to do.

Exchange Server is a complex animal, but one that other vendors have not yet been able to completely match in terms of what it does.  There are tools that do messaging and shared calendars well - some might even say better.  There are collaboration tools that are superb!  There are even Unified Messaging platforms that rival the best efforts of the guys in Redmond.  There are not, however, many total packages that can do it all, and do it well enough that you can rely on them.

The combination of Exchange Server, Office Communication Server, SharePoint Server and Outlook (well, all of Office) creates a solution set that does everything that most businesses would require for messaging and collaboration.  Add in the new Groove systems and now you're moving well past what most Enterprise Messaging solutions can provide.

Yes, it is true that Exchange is challenging. It is also true that the Messaging and Collaboration Platform is complex and overwhelming for inexperienced users.  However, I challenge a novice to take Lotus or SendMail and get it working without either a little help or a lot of reading.

So, enough with the Exchange bashing!  Reach out to others in the community, search knowledge bases and web forums, and generally let others who have been in your shoes before help you.  In most cases you can find someone who has experienced the same problem you have, and who found a way to fix it.  And in any case you'll learn a lot more about how the platform works.

No, it's not perfect - not by a long shot - but Exchange is the best Messaging and Collaboration platform (with its eco-system software tools) that I have used in my time as a Systems Consultant and Engineer.  So yea, I do enjoy working with it, and there might even be some luv in there too.

Quite a stretch for clustering in 2008

Microsoft Clustering Services (MSCS) have existed in one form or another since NT4, but have always suffered from a significant limitation.  All cluster resources had to exist within the same logical subnet, or else you couldn't create the cluster itself.  Windows Server 2008 allows for some flexibility in that regard, with the ability to create nodes of a contiguous cluster in different logical subnets.

Before we dive too far into that, you may want to see the official MSFT information here:

http://technet.microsoft.com/en-us/library/cc770625.aspx

So what does this mean for you and I?  It means that we can create CCR clusters on Exchange 2007 that stretch between physical locations and subnets.  However, to do this you'll need to be on Server 2008, the function just isn't available in Server 2003. This allows you to provide basic availability for Mailbox Role (MBX) servers in your Exchange environment, but doesn't take care of everything when it comes to DR planning.

First off, this applies only to Exchange 2007 Enterprise Edition, and then only to MBX role servers.  While most other roles are natively fault-tolerant with multiple servers installed with the same role able to stand in for each other, organizational or regulatory rules might not make that kind of redundancy possible.  Edge servers are the biggest example of this.  Since they're not tied into the domain structures, they don't contain any way to quickly flip traffic from one Edge server to another in different sites.  Third-party tools (see disclaimer below) can often take care of that function for you, as can working with your DNS provider to facilitate moving the MX records in the event of an emergency.

If you have legacy Exchange 2000/2003 servers, you're also not able to take advantage of this new MSCS feature set on those boxes.  The same goes with any non-Exchange tools, like SQL, anti-virus servers, anti-spam servers, etc.  Even if these servers run on Server 2008 clusters, they'll require some third-party intervention to handle the data replication for those systems.  This would include things like Blackberry servers, GoodLink systems and other non-Exchange remote email tools.

Finally, keep in mind that CCR clusters can only extend to Active/Passive, 2-node configurations. That will mean you can't use these solutions if you need to go beyond that model - which Exchange 2007 easily allows without CCR involved.

Server 2008 Failover Clustering is a great method for basic High Availability for Exchange 2007 CCR systems - even across subnets.  With some additional tools, it can become the center of an Exchange DR solution set that can help your organization withstand even site-wide emergencies.

More than zero?

There are a ton of interesting settings and switches in Exchange 2000/2003, but one of the more unusual is the "Zero Out Deleted Database Pages."

Exchange 2000 and higher all have several levels of potential access points for un-delete operations.  When anything is deleted from a mailbox, the data isn't truly removed, but rather marked as scheduled for delete at some later date.  The default settings keep mail items for 15 days and mailboxes for 30, after which point they're removed from the server.

Data pages within the ESE database are another story; however.  They get deleted all the time, but not removed from disk.  They're simply marked as deleted, ready to be overwritten as needed.  Normally, this doesn't pose any specific security threat, as File servers and most other Windows servers do the same thing when data is deleted.  In higher-security environments; however, this could be a policy violation, as the data would be stored "in the clear" and vulnerable  to anyone able to get their hands on the physical disk devices.

Microsoft has taken steps to natively remove the potential for security breaches, but at a cost.  Built into every version of Exchange supported today is the ability to literally overwrite each deleted ESE page with zeros.  The processes is therefore referred to as "zeroing out" the pages, and the "Zero Out Deleted Database Pages" setting controls this behavior.  By default, the setting is not turned on, but can be enabled via the Exchange System Manager GUI, Powershell or via Active Directory.

The problem is that the benefits rarely outweigh the costs in the real world.  Zeroing out pages takes up a good chunk of processor time, and Exchange deletes pages - quite literally - all the time.  Zeroing out will also have a huge impact on any form of replication, just because a large amount of data change is required for the process to work.  In addition, this method of secure wipe meets only very low-level security concerns.  Most regulatory requirements require multiple overwrite passes (7, 15, sometimes even more) and mandate random data be used, not just zeroes. 

So, while you might feel like you'll gain some security by using this setting, the extra overhead and falling short of regulatory compliance should make you think twice before you turn it on.