What the {Censored} Do I Install for Exchange 2010??!!

This is a complaint I have heard over and over again from clients going to install Exchange 2010l and even earlier versions.  The level of profanity depends a lot on the individual, but I have heard some rather prim and proper folks resort to very short words when it comes to Exchange pre-requisites. Come to think of it, they've resorted to some long words as well, but none fit for publication in family-friendly venues.

Exchange prerequisites have typically been confusing and difficult to master.  Starting with Exchange 2000 and 2003, the pre-flight checks built into the setup protocols became intelligent enough to figure out what was missing for the most part.  However, the installer didn’t tell you what those things were unless you started playing with the install options and suddenly got a popup which detailed what wasn’t there.  Exchange 2007 and now 2010 both have extensive pre-flight checks that occur before you do any form of installation, just after you tell the installer which components you’d like to put on the box.  They check for everything from your .NET versioning to Active Directory connectivity, but once they tell you all the different things that are not present, how do you figure out what to install in order to make those things present?

Thankfully, Microsoft has had TechNet pages that detail prerequisites for Exchange installations, starting back in Exchange 2000.  Up until 2007, it was up to you to install each of the components listed, but with the advent of newer server management tools in Server 2008, the process can be automated.

For example, to pre-stage Server 2008 R2 for Exchange 2010, you can invoke a series of PowerShell commands to set up nearly all the prerequisites in one shot.  First run:

Import-Module ServerManager

inside a PowerShell window in order to load the correct command modules into the session.  Then, use the correct sequence of commands in the same PowerShell window to load the prerequisites for the roles you need to run on this particular server.  For example, if you wanted to run Hub/Transport, Client Access Services and Mailbox Services; you would execute the following block of commands:

Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy –Restart

The specific commands (and the tool to call them) will change based on three things:

1. The version of Exchange (2007, 2010, etc)
2. The version of Windows (2003, 2008, 2008 R2)
3. The Roles you intend to install (Hub/Transport, Client Access, Mailbox, Unified Messaging, etc.)

Some things, like installing the 2007 Office System Converter Filter Pack; still have to be done manually, but most of the basic pre-installations can easily be automated using these combinations of command window and PowerShell scripts.

Microsoft has put up all the commands and processes for all the Server OS’s that Exchange 2010 can run on in this TechNet article.  Similar articles exist for previous versions of Exchange too, so you can get your prerequisites onto the server before you even start the Exchange 2010 installation executable.

View from the field: Exchange 2010 adoption

Since Exchange Server 2010 has been on the street for a few months now, data is beginning to trickle in on the adoption rates of the new platform.  While there are many very-well constructed polls and surveys out there, I’ve had the privilege of talking to many clients about their future plans, and these are my – horrifically unscientific – results of those conversations.

1 – Exchange 2010 is on nearly everyone’s radar.  Universally, every organization I’m talking to is actively planning out what they will be doing with Exchange 2010.

2 – But, most folks are not moving just yet.  About 8 of every 10 organizations I talk with are looking to begin their migration no sooner than Q4 of this year. Most are looking at Q2 of 2011 as their start-date.  A few here and there are indeed moving already, but not the majority.

3 – The migration curve of Exchange 2010 is moving much faster than it did for Exchange 2007.  I have a couple of theories as to why this is happening:

A – Exchange 2003 is going to be end of life soon.  Mainstream Support ends in April, 2009 according to the Support Lifecycle FAQ. Support for Exchange 2000 has already ended.

B – Most clients were in the process of rolling out (or just about to roll out) Exchange 2007 this year.  Since the Roles and overall framework of Exchange is very similar, it was easy to adapt these plans and roll out Exchange 2010 instead.

Overall, I’m guessing it will take about half as much time for Exchange 2010 to reach wide adoption as it took for Exchange 2003 or 2007.

4 – More clients are planning on jumping from Exchange 2003 to 2010 than were considering going from 2003 to 2007.  Many of the clients I’m talking with were not in a hurry to move to Exchange 2007, but are now actively planning their move to 2010.

While this is no way a good overall analysis of the Exchange market (as I’m only speaking with a few dozen clients a month about this), I’d be interested to see how this informal review matches up with formal polls and surveys over time.  If I am allowed to quote any of those formal studies here, I will, so we can track how accurate I was =)

Outlook Mail stuck? It may not be your profile.

During a recent Exchange 2010 training, our instructor went through a couple of things that could be causing mail to not leave an Outlook or OWA client during normal operations.  When I did a few searches on this topic, I was alarmed to see that many people suggest that the problem is the Outlook offline storage file or PST.  While that does sometimes cause these issues (especially if you’re on Exchange 2003 or earlier), there are a couple of quick checks you should make against the server first.

On Exchange 2007 and 2010, if mail is getting stuck in users’ Outboxes on various clients, check two things:

1 – Is there less than 4GB of disk space available on any volume on the servers that contains Exchange data and/or queues? If there is less than 4GB, Backpressure protocols kick in, and Transport Services won’t move mail anywhere, leaving new messages stuck in users’ Outboxes. This is fixed by freeing up drive space or moving the database and/or queues to another volume with more room.

2 – If the disk space is ok, check to see if the Transport Services (which vary depending on your Exchange version) are running.  Any service that isn’t started can cause mail routing to fail, and messages to stay on the client software.  Obviously, to fix this you either need to get the services up or bring another Hub/Transport system online to handle mail flow.

Additionally, if you are using Exchange 2010, mail may get stuck in the Drafts folder.  That is to say, it leaves the Outbox and immediately appears in the Drafts folder in Outlook.  If you see this behavior, check to ensure that the Mail Submission service is running on your CAS server.  If it isn’t, mail can’t be properly picked up from the Outlook client, and the resulting error shoves the email into the Drafts folder.

Granted, if these issues are not the cause of your issue, or if it only seems to be happening to one user, then rebuilding the OST or PST might be in order.  However before you disrupt clients day-to-day activities, a quick check of the server might uncover a correctable error that can be quickly contained.  In the case of lack of disk space, it can even expose a growing problem that must be dealt with in the near future to avoid much more wide-spread downtime.

Two for tea, and tea for 2007?

Those following my twitter feed (http://www.twitter.com/talonnyc) already know I’m in an Exchange 2010 training this week at New Horizons here in NYC.  During the class, someone had asked if you could run both the Exchange 2007 and 2010 admin tools on the same system, and our trainer (though extremely well versed on just about any other topic we threw at him) wasn’t sure on that one.  Luckily, the twitterverse came to the rescue and Henrik Walther the Editor of MSExchange.org sent over an article that went through the details on this, and many other topics on Exchange 2010 management.  The article found here is definitely worth the read, but since it covers several other topics, here’s the skinny on multiple client tools installs:

2003 Tools: Cannot be installed on the same system as 2007 or 2010.

2007: x86 tools can’t be installed with the 2010 tools, but the 64-bit versions can co-exist

2010: Only available in 64-bit versions, and can co-exist with the x64 versions of the 2007 tools

To use both the 2007 and 2010 tools, install all pre-requisites for the 2010 versions.  This includes PowerShell 2 and the .NET 3.5 (go with 3.5.1) Framework package, along with others.  Consult the install guides at MSExchange.org for more in-depth details on what you need to have on your workstation ahead of time.  The Exchange 2007 tools are compatible with these upgraded pre-requisites, and so can either be left in place (if already installed) or installed first.  Then install your Exchange 2010 tools and you are on your way.

Always remember to use the Exchange 2010 tools whenever possible.  Certain configuration specific to Exchange 2010 (Like Moderation rules) will be ignored by the earlier tool kit, even though it will let you do many operations with either version.  This could lead to you accidentally ignoring a vital configuration or management step along the way.

Thanks to Mr.. Walther for the excellent information!

Whoops! OK, the RSS feed is working again.

Dear Readers:

Apparently, even though I’m using Blogspot (which is Google/Feedburner’s own blog system), the RSS feed did not properly move with the blog. Go figure.

Long story short, you may not have received the updates to my blog since February 1, 2010.  So, have a look at BeingExchanged.com and catch up on past columns, and now that I have the feed manually fixed, you’ll start getting my weekly updates again =)

An update on the Kindle subscriptions: So far I have 2 folks who have subscribed, when I hit 5, I will – as promised – start making regular contributions to the American Red Cross each month, equal to the amount of money Amazon pays me less the fees they charge me. In case you’re wondering, before I get about 5 folks subscribed, the payments will be less than the processing fees, and so I won’t actually see any payments =)

Check the links at the right to find out how to subscribe via RSS or your Kindle, and why I cannot make the Kindle delivery a free service, as much as I’d like to.

Public Folders continue to be whittled away

With each new release of Exchange Server, Microsoft de-emphasizes available Public Folder functionality and restricts Public Folders from participating in the newer technologies of the current release. Of course, they also announce that they make no promises as to Public Folders even being included in the next release down the line.  Exchange Server 2010 is no exception to these rules, and while Public Folder technologies are still in the release, they are restricted and downplayed overall.

With the RTM version of Exchange 2007, you needed to use Outlook or other tools to manage folders, but the backlash from end-users was so fierce that Microsoft put the tools back into Exchange with the SP1 release. Still stinging from that set of events, the Exchange Team seems to have built at least basic Public Folder functions into the shipping release of 2010, but with some limits.  A few of these were limited in 2007, some are new.

As with 2007, Outlook and Outlook Web Access are about the only remaining methods to connect to Public Folder trees.  Gone are the days of NNTP and IMAP access to folders, and apparently gone to stay.  Since most users who need Public Folder access use Outlook anyway, this wasn’t a huge issue, but it did hamper 3rd-Party Public Folder integration unless the vendor was - or is - using MAPI connectivity.

The new clustering solution set that was introduced in Exchange 2010 (Database Availability Groups, or DAG) doesn’t support Public Folder databases either.  You can, however, host Public Folder databases on MBX servers that are using DAG for their Mailbox Stores.  You simply have to use some other replication system to protect the data (either Public Folder Replication or a 3rd-Party system – see disclaimer at the end of this blog).  More info on this can be found on TechNet.

So, while Public Folders are still not dead yet, they are systematically becoming a very difficult feature-set to continue using.  Microsoft has been actively encouraging Exchange users to leverage the functionality of a SharePoint Server to replace what was once stored in Public Folders, and for the most part you can do much more with SharePoint overall.  There are several 3rd-Party tools available to move your Public Folders to SharePoint, and once there you have a great deal more control over content, accessibility and general functionality.

If your organization uses a great deal of Public Folders, and you intend to move to Exchange 2010, consider migration of the folder information and functions to SharePoint.  Doing so as part of an overall migration strategy is a lot better than trying to rush the job after you find out that Public Folder functions in Exchange 2010 may no longer do what you need.