What ever happened to Microsoft product release cycles with common sense, clear deployment paths and continuity of invested platforms?
Whether you thought it was a bombshell or uneventfully overdue, the July 2012 announcement of SBS 2011 Standard and Premium being retired as product designs signaled a course change for SMB IT Pros. And yet, the confusion now is even more ridiculous because of how Microsoft has failed to clearly state the obvious: Microsoft doesn’t have the new replacement elements ready to go yet.
Microsoft’s announcement left SMB Partners with the impression that SBS 2011 Standard and Premium are dead by announcing “end of life” as it announced new platforms which makes you think the two concepts meet in the middle? Not so much. I never hoped for another of the “single installed vertical stack” versions of SBS, I wanted the better alternative integrated design presented as a fully baked concept from Microsoft. I don’t mind integration opportunities and most SMB IT Pros don’t mind it if the parts fit together. Ultimately, I’m fine with the idea that IT Pro Experts will provide full integration solutions as guidance to replace SBS platforms, but the pieces are not quite fitting into place yet.
Here are the core points of this post:
- Windows 2012 RTM cannot run Exchange 2010 on it until the future date when Exchange 2010 SP3 releases, or at least that’s the current messaging from Microsoft on why you must deploy Windows 2008 R2 to deploy Exchange 2010 today. The required service pack is due “by mid-year 2013″, as stated by Microsoft.
- Exchange 2013 cannot currently be deployed into a forest/domain where there exists any prior version Exchange 2010 or earlier. In other words, you don’t have a continuity of domain, AD, and organization option to do a conventional Exchange migration without abandoning your domain/Forest or your Exchange Organization. The required Exchange 2010 SP3 release to do this is the very same one in the prior point, expected by mid-year 2013.
- Therefore, the current Windows 2008 R2 server/Exchange 2010 combination you can use to do a migration today, is exactly what is provided in SBS 2011, and the future support period is the same. Today, your migration alternative would be deploying Exchange 2010 on Windows 2008 R2, at least in this period until Microsoft solve the illogical technical problem of announcing operating system and exchange platforms that aren’t backward compatible without service packs coming in the future.
I see this backward compatibility gap in Exchange and Server as a temporary problem, probably to be solved in the next 3-6 months as far as we can tell now, but it’s a future solution now. Until more of this is clear, I don’t even want to commit to the next milestone, when the bleeding edge concerns for SMB IT Pros might be fully addressed. It’s not enough to have parts no longer blocked from installing with each other to justify a migration from a stable platform to a bleeding edge platform we can all see didn’t have a natural integration in the design…it’s requiring redesign after shipping.
Cost-wise, do the math and you likely will find the existing platforms stand alone or delivered in an “already integrated for you” SBS 2011 Standard are still a good fit. I’m really not trying to breath life into a dead SBS product-line, I frankly don’t see it as dead in the first place. I anticipate we will be doing migration support of SBS platforms for another 5 years. We still see substantial numbers of folks moving out of SBS 2003 only now….in 2013. SBS 2011 in the field for another 5 years seems like a no-brainer in SMB space.
In summary, for the first few months of 2013, we currently are not committing support to Windows 2012 DCs or Exchange 2013, but we are committing development efforts. Yet we announced the release of new and updated Kits for the full catalog of all established platforms. The update to all our Kits is bringing everything in our product line to a common design level which we will soon extend for the new platforms. (Read about our Jan 2013 full catalog release: http://itproexperts.com/blog/platform-migration-project-solutions-matrix/)
As soon as I can get a platform with Exchange 2013 to test migration with Exchange 2010 SP3 to determine what I need to know, we will move on that solution in our list of Kits. We likely will support Windows 2012 DC platforms much sooner for non-Exchange hosting duties, I suspect, and fulfill the Exchange migration as the next piece beyond resolution of the problem still in the hands of Microsoft to solve. Either way, I’m expecting to have the entire thing mapped out by mid-year if Microsoft stays on a proper timeline.
Meanwhile, in the absence of clearly defined solutions for these new platforms, we go with common sense:
- Common sense might suggest that if you must upgrade now, you choice could be to sell below the latest releases, or use downgrade rights to deploy Window 2008 R2 and Exchange 2010 even if you sell the licenses for “new product”. Call it “poor man’s” Software Assurance…and then remind me of when Microsoft ever made such great deals available instead of pushing you to their latest release as fast as possible. (Seems suspicious to me.)
- Common sense might suggest that if you could get another business cycle of 3-4 years on an SBS 2011 server this could well be less expensive than your alternative to deploy standard versions of the exact same products.
- Common sense might also suggest that you might wait until Microsoft resolves this complexity and compatibility problem with Exchange 2013 and Windows Server 2012, other wise you could be doing a PAIR OF MIGRATIONS back to back in one year if you really are squeamish about deploying Windows 2008 R2 or Exchange 2010 “this late in their lives!”
Let’s look at the multi-server aspect of this now.
Certainly you could choose to buy Windows 2012 Standard, then integrate the (2) VM instances that you are licensed for so you can have a pair of servers running as VMs on one server hardware chassis. But if you do this today, the implications are that you either downgrade both server’s to Windows 2008 R2, or you take on a new server deployment with one as Windows 2012 for DC, and the other as Windows 2008 R2 with Exchange 2010….and your plan to upgrade that again later to newer product.
Of course, this also assumes that virtualization is free of complications for your deployment situation, and in many SMB environments, that’s just not the case. I’m all in favor of VMs, and I’m not suggesting you avoid those deployments, but the reality is that deploying VMs isn’t universally simpler, it’s simpler and more complicated in different ways to get a great integrated solution for a small business as well as still on the early side of adoption comfort for many IT Pros.
I’ll leave you with a few questions:
- Does it make much sense to you, to mix server platforms just to be the first to deploy a Windows 2012 domain with Exchange 2010 on Windows 2008 R2?
- Does it make sense to rush deployment of the first combination of Windows and Exchange that are not backwards compatible to existing products in both lines?
- Does it feel like Microsoft moved these products out for reasons other than great integration has been achieved, and yet Microsoft has placed the burden on SMB IT Pros to solve integration that by all indications isn’t quite simple to address yet.
During the course of 2012 Microsoft was intentionally unclear and non-communicative about the strategy for new products and marketing during a major release year. As we enter 2013, as much as I would like to have faith that a future date with a future service pack is all going to make this clear, I’m not convinced to embrace this as a design condition at this time. Our goal is to make this easier for IT Pros, and that’s going to require products that have more cohesion and a bit more time and effort from Microsoft.
Jeff Middleton, Founder