As you probably know, Outlook 2003 and older use Exchange Public Folders for their Free/Busy data and Offline Address Book. You may also know that Exchange 2007 and Exchange 2010 have deprecated Public Folders in favour of an HTTP-based distribution method for the data, which Outlook 2007 & 2010 fully support.

One could then reasonably conclude that removing public folders in an Exchange 2007 or Exchange 2010 environment might negatively affect Outlook 2003 and older clients. This is technically correct, though the reality is slightly more dramatic; it completely blocks Pre-Outlook 2007 clients from connecting to your Exchange servers and presents the users with a handy “Your administrator has blocked this version of Outlook from connecting” message.

What this all means is that if your support team have spent the last year lying to you every time you’ve asked them how they’re progressing on upgrading all the remaining Outlook 2003 installs to 2007/2010 then when you remove the last public folder store from your Exchange environment you’ll suddenly have hundreds of people whose can no longer access their emails. This, for some reason, upsets them.

The moral of this story is that you should never trust what people tell you, because they’re almost always lying bastards, and make sure you verify the information for yourself before making any changes. Yes, it’s a lot of work and no, you shouldn’t have to do it, but it’s always you that gets the flak when it all hits the fan.



Update: There is a hotfix now available to address this issue, though you have to ring MS support directly to get hold of it at the moment. The plan is to roll it into an IE9 update in the near future. More details can be found here

There is a known issue with the Exchange 2007 and Exchange 2010 Management Consoles on machines with Internet Explorer 9 installed. This issue causes you to recieve the error: “You must close all dialog boxes before you can close Exchange Management Console.” when trying to close the EMC even though there aren’t any dialog boxes open.

As it stands, there are several workarounds: You can uninstall IE9, you can kill the MMC process from task manager every time and a few people have reported success with turning off “Internet Explorer Enhanced Security Configuration” for Administrators and Users (Servers only) and then adding https://localhost to the “trusted sites” in IE.

According to the Senior Program Manager for Internet Explorer Product Quality, Mark Feetham:

[…]we do now understand what’s occuring between the EMC, MMC and MSHTML. We have enough information to complete the investigation and have moved to looking at ways to improve this situation.

Rumoured ETA for a fix is Q4 2011.



Uninstall Exchange Server 2007 from Passive node

  • Login to passive node and check whether Exchange CMS is located on active node with Get-ClusteredMailboxServerStatus cmdlet from EMS
  • Run:
    C:\Program Files\Microsoft\Exchange Server\bin\Setup.com /mode:uninstall

Evict pasive node from Windows Cluster

  • Stop the Cluster service by running:
    net stop clussvc
  • After the Cluster service has been stopped, evict the node by running:
    Cluster <ClusterName> node <NodeName> /evict

Remove CMS from Active Node, uninstall Mailbox role & destroy Cluster

  • Login to active node and run:
    C:\Program Files\Microsoft\Exchange Server\Bin\Setup.com /mode:uninstall /removeCMS /CMSName:<CMSName>
  • Destroy Windows Cluster (Right click on the cluster name then choose More Actions > Destroy Cluster in Failover Cluster Management)


#Get current DB Checkpoint File
$((eseutil /mk ".chk")[13]).split("x")[1].split(",")[0]

#Get current DB Checkpoint File (Decimal)
[Convert]::ToInt32($($((eseutil /mk ".chk")[13]).split("x")[1].split(",")[0]),16)


So, you’ve got an Exchange 2007 CCR Cluster set up and all is well in the world; your data is safely replicated offsite so that in the event of a disaster, you can have your users back up and emailing in the time it takes a DNS record to update.

But then, disaster! A different disaster to the previously mentioned one, obviously, because this disaster causes a cluster failover and the connection between nodes is down for just long enough that they get out of sync and require a reseed to fix.

At this point I’d like to jump off on a slight tangent to bemoan the inconsistency with which Exchange 2007 handles the interruption of replication traffic. On the one hand, you can shut down one node for a couple of hours and when you bring it back up again replication resumes quite happily, but on the other hand if you have 5 minutes of iffy network connectivity, suddenly the databases* are irrevocably out of sync and need to be reseeded.

Anyway, you’re not too concerned by this turn of events because, while a reseed of your ~90Gb database takes a few hours it’s not like the cluster is going to fail back while you’ve got databases in an inconsistent state, is it?

Well, it shouldn’t have happened, but it did; the bloody thing failed back while halfway through reseeding the database and then, obviously, couldn’t mount it at the other end. This posed something of a problem, because Move-ClusteredMailboxServer (or the GUI equivalent) gets upset when your databases aren’t in sync and refuses to let you fail over and Restore-StorageGroupCopy would have forcibly mounted the database sans up-to-date logs and effectively reverted it to the state it was in before it all failed over the first time, binning a lot of emails in the process.

Thankfully, Move-ClusteredMailboxServer has a very handy -IgnoreDismounted option which allows you, when you’re really sure, to skip all replication health checks on Dismounted databases, allowing you to fail the server over and remount the (more) up-to-date version of the database, whereupon you can attempt to re-reseed it. So, if you find yourself in a similar quandary, with your databases all out of sync and at risk of losing hours or even days worth of data, before starting a restore from tape & printing your CV, you can always try: Move-ClusteredMailboxServer -Identity <CCR Cluster Name> -TargetMachine <Target Cluster Node> -IgnoreDismounted Just remember that there’s a good chance of at least some data loss, but if you’re in a position to need to use it, the alternative is probably a lot of data loss so it’s a risk that might be worth taking.

* I know that technically Exchange 2007 CCR replicates at the Storage Group level rather than Database level, but as you can only have a single database in a CCR replicated Storage Group and “database” is easier to type, I’ve used it instead.



As someone in the middle of a transition between Exchange 2007 SP3 and Exchange 2010 SP1, I have to ask; MS Exchange Team, what were you smoking when you came up with the interoperability options here?

2003 to 2007 was pretty decent, you could deploy your 2007 CAS servers more-or-less directly in place of your 2003 OWA front-end servers and they would happily serve 2003 mailboxes up to people. Management tool interop was lacking a bit, but that was excusable as 2007 was, at least, a totally new set of tools based on .NET/Powershell and they generally wouldn’t let you do anything to a 2003 mailbox that would break it horribly.

With 2007 to 2010 though, you can’t do any of that. You have to keep your 2007 CAS and HT servers around because the 2010 ones won’t play nice with 2007 mailbox servers, but then the 2010 CAS servers can’t connect to 2007 mailboxes. Except they can, if you copy the 2007 binaries onto them. Except that only works if there isn’t a 2007 CAS server in the same AD site as the 2010 CAS server. So, short of creating new AD sites for all your 2010 mailbox servers you have to have at least one AD site with both 2010 & 2007 CAS servers, which works OK internally, but if you’re publishing to the internets (and who isn’t these days?) then you start to run into issues. There are various articles about this (like this one) but basically you have to create a new internet-facing DNS entry for the 2007 CAS, move the 2010 to the old internet-facing DNS name, change the ExternalURL value on the 2007 CAS to match the new DNS name, change the internal DNS so that there’s an entry for the new DNS name (because Exchange treats other AD sites as “External” as well), buy a new trusted SSL Certificate for the new DNS name (or wildcard it) and pray to God that you’re only publishing 2007 CAS servers from a single AD site; otherwise it gets so complicated that your brain will try and kill itself to escape.

If you think that sounds bad, then wait; it gets better! You can’t use the 2010 management tools (which are now 64-bit only – unless you enjoy Powershell Remoting) to manage 2007 mailboxes. Well that’s not entirely true, you can so some things, just not everything and it’s the same with using the 2007 tools on 2010 mailboxes. It’s all documented on The MSExchangeTeam Blog and it’s a huge mess – if your helpdesk staff (or whoever else manages your mailboxes day-to-day) aren’t really on the ball there’s a good chance you’ll run into problems while the 2007->2010 transition is in progress.

All this is in addition to all the subtle syntax changes they’ve made to a lot of the management Cmdlets so that things which were valid commands in 2007 don’t quite work properly in 2010; I’m looking at you, Import-ExchangeCertificate – let’s go from importing a CA-supplied .cer file to importing the binary contents of said file as a Byte Array supplied as a command line argument, because that’s much easier.

I really like Exchange – 2007 SP1 onwards was top-notch – and 2010 has some great new functionality, but they’ve really dropped the ball when it comes to installation, upgrading, migrating and transitioning.