I seldom leap in to criticize people who write about Exchange because a) everyone is perfectly entitled to their own opinion about technology (good or bad as that might be) and b) it’s up to the reader of any article to put its content into context with their own operational circumstances. In other words, never take anything as the absolute truth. Always think through a statement or recommendation in the light of your experience and the business and operational requirements that Exchange has to satisfy in your company.

But there’s always an exception that floats up to grab your attention, which leads me to an article written by File Systems MVP Brien Posey for the SearchExchange.techtarget.com site entitled “Four essential tasks to complete before migrating to Exchange 2013.” I believe that Brien was an Exchange MVP in the past but I can never remember him having very much to do with the product or interacting with the development group. I’m sure he does a great job with the File Systems group to help advance the cause of important technology such as Windows Explorer and maybe OneDrive and that kind of file system thingie. But I think he might not have fully grasped some of the finer details of Exchange 2013. Or maybe it’s just me (always a possibility).

For the third step outlined in his article, Brien recommends that you set up “a temporary virtual machine (VM) to use for your first Exchange Server 2013 deployment,” something that caused me to splutter on my cornflakes. The recommendation might be acceptable if this was your first deployment (as in a test organization that you set up to become accustomed to Exchange 2013) but as you read down through the piece, it becomes clear that this statement refers to the first Exchange 2013 server deployed into an existing Exchange 2010 organization. That’s a very different scenario. It would be nice if the text had been better edited for clarity. But then again, perhaps the get-out clause is the note that this approach does not follow “official Microsoft best practice,” whatever that might be. Perhaps Microsoft has both unofficial and official best practice that it gives to customers depending on how good they are at using Microsoft technology.

In any event, he goes on to explain that this is because the Exchange 2013 CAS doesn’t do very much at all and relies on the mailbox server role to execute the remote PowerShell commands used to manage Exchange. Absolutely spot-on. He then asserts that the “first Exchange 2013 server you bring into an Exchange 2010 organization must contain both the Client Access Server and the Mailbox Server roles” and notes that this is not a desirable configuration for organizations “that want to separate these roles.”

Well, I’m not sure what kind of Exchange deployments Brien has seen lately, but the only large-scale Exchange 2013 deployment that I can think of that uses dedicated server roles is Exchange Online, and we all know just how representative Office 365 is of any on-premises deployment. And it doesn’t make much sense for small-scale Exchange 2013 deployments to even consider the notion of dedicated CAS servers.

I’ll go further and say that anyone who does not deploy multirole Exchange 2013 servers needs to come up with a really good reason why not, if only because it is wasteful to go long the single-role route. In the case of Office 365, I understand the reason to be due to their unique operational and management requirements. Indeed, the inestimable Greg Taylor of Microsoft noted at Exchange Connections in 2013 that using single-role servers was wasteful and invariably required more servers to be deployed to achieve the same level of robustness and resilience within an organization.

I also disagree with Brien’s rather throwaway conclusion to his point when he says that you can “simply remove Exchange Server from your temporary VM.” Perhaps this simplification is unintended, but removing the first Exchange server of a new version from any organization requires a tad more care than a simple deletion. Things like arbitration mailboxes, for instance, need to be checked and moved to another database. Connectors might also need to be relocated. In short, a rush to delete might create an opportunity to rue.

Other assertions in the article also caused my eyebrows to quiver. The statement that “You should be able to install the cumulative update without first installing Exchange Server 2013” is interesting because one of the big advantages of a cumulative update is that it is a full-blown version of Exchange 2013. Thus, if you install Exchange 2013 SP1 (CU4 in reality), you perform one installation to created a fully-updated Exchange server. I guess this is an example where better editing would improve clarity. It would be regrettable if people read it and assumed that they had to first install Exchange 2013 RTM and then apply the latest cumulative update.

All of this goes to prove that the text in any article really does have to be examined, parsed, and assessed in the light of your experience. Never accept anything just because it’s written in an article published by a well-respected web site. All writers, myself included, have a nasty habit of getting things wrong from time to time (ah, the consequences of a slip of the keyboard…). Even my colleagues in the ranks of the File Systems MVPs.

I note that Brien is not on the list of MVPs who have registered to attend the Microsoft Exchange Conference (MEC) in Austin (March 30-April 2). Seems like a missed opportunity to catch up on all that official Microsoft best practice… Looking forward to seeing you all there!

Follow Tony @12Knocksinna