I know that Exchange 2013 doesn't list Server 2012 R2 Standard on the supported OS list (yet...) but I'm operating under the assumption that it will be supported after RTM.
I also know that Exchange 2013 on a DC isn't a recommended configuration, but it's not an unsupported configuration either, so please hold off with answers that ask me why I'd want to do this. Just run under the assumption that I have good reasons. There is nothing worse than asking a straightforward question and getting a pile of "better" solutions that don't answer the original question.
So, with this in mind, I ask this: Is it going to be possible to install Server Standard 2012 R2, Enable the Essentials Experience Role and Install Exchange 2013 in such a way that all the features work properly? Is this going to be a supported configuration or not? I'm well aware that it's not supported on an Essentials server, but what about Standard w/ Essentials Role?Monday, July 15, 2013 3:44 PM
I'm asking for an official post on the topic from someone at Microsoft, but I would not expect this to be supported.
Remember with Standard server you have two vm rights. So there's absofreakinglutely no reason to WANT this "SBS" like setup that adds complexity, adds an IIS web site that competes with Exchanges IIS config and just in general adds a lot of baggage where you really don't want this baggage from the get go.
With one 2012 r2, you can lay down HyperV, install two 2012 R2 instances, one for the Essentials role/DC, the other for Exchange.Wednesday, July 17, 2013 6:43 PM
With all due respect (and please know that there's an immense amount of respect coming from me - I have been following the SBS Diva blog for a long time and from time to time you've saved my butt, big time) I'm un-proposing your reply as the answer, because I want to validly know if the configuration I've mentioned will be supported.
Don't get me wrong, I've built a few essentials based environments with the HyperV configuration as you've mentioned and it's a great option, but I want to know about other options. In our competitive market, I need to consider every single build environment I can and weigh them. I'm not stupid enough to deploy something that's not supported, but there's a huge gulf between Best Practice and Unsupported and I'm not convinced that the overhead of 3 servers suits every small business.
As a partner, I've also inherited many, many, many broken configurations that have been unloaded on unsuspecting customers (SBS w/ Trusts and/or terminal services DLL's patched in and much worse) - I need to know if I see a box like this (and I will, I promise it) whether I'm telling prospective customers that it's best effort support or whether we have some kind of help from Microsoft if it's beyond my abilities.
Maybe it's my bias from being in an area where most of my business customers are GLAD to get 2Mbps down and 0.2Mbps up and pay through the nose for it (no, not a typo), but I'm also getting sick of Microsoft's push for Cloud and Private Cloud. Since most of my customers can't sustain an offsite backup on a single server and a good portion of them can't use Office 365 without major frustrations, they're not options I have available. With this in mind, does a 10 person org really NEED 3 servers? Microsoft tells me that putting all the roles and services on one box is TOO much, but it's perfectly fine to duplicate a pile of local and network services on 3 OS instances just so you can run all the exact same roles on 3 virtual machines on the same box? It doesn't make sense there's no way that 1 OS footprint + AD + Exchange + Essentials is less resource intensive as 3 OS footprints + Hyper-V + AD + Exchange + Essentials. I also can't believe that 3 servers is any less of a house of cards than a single mutt server. Sure, I get it, on paper, you beef up the hypervisor box and it's like you get 3 machines for the price of about one and a half, but if you beef up the hypervisor box, wouldn't this beefed up server now just have sufficient power to handle the load of all these services for a 10 person org? Understandably, this paragraph is not directed at you, but I'm more than fed up with how Microsoft is handling this.
Furthermore, if my mandate is to build an environment I can hand over to a non-enthusiast, a 3 server conglomeration with Hyper-V is not for that person.
Ultimately, I doubt that this configuration will be supported - and if it's not supported, I'm not stupid/dishonest enough to set up that kind of environment for my customers. I appreciate your helpfulness in suggesting the textbook way to do it, and in most every case, it's the solution I want to advocate and configure, but I need to keep this question alive until I know if there's any possible way a single server configuration will be supported. If not, c'est la vie - move on, adapt and figure out the best way to trudge on.
That said, I really appreciate your insights and that you took the time to reply. I just don't want to close the thread until I get something official from MS.Thursday, July 18, 2013 3:46 AM
If it was supported, they'd still be selling SBS.
I'm not telling you to deploy three servers. I'm telling you to deploy one - a single server, with the hyperV role on it. On that single server, you then deploy one copy of Standard and make it have the Essentials role. On the second copy you then install Exchange. All legal. All supported. All without anything blowing up on Patch Tuesday (Exchange patching notwithstanding, of course). You yourself are ready to fork over the price for Standard. What you want is doable on one single piece of hardware, just not on one single server instance.
The "SBS" one single server experience will not be supported. The Essentials married to an Exchange member server is and will be.
That said, I know this question will be asked so I've asked for an official statement because I know that you want official. (and you and the broader community, deserves official)
There's documentation in the Essentials 2012 currently deployment docs to even use one single IP address and ARR (http://technet.microsoft.com/en-us/library/jj200172.aspx ) so that you don't have to have a multiple IP setup and can be "SBS" like with one IP. This will work as well with R2.
Thursday, July 18, 2013 5:33 AM
- Edited by Susan BradleyMVP Thursday, July 18, 2013 5:48 AM Edited
Now keeping in mind that 2012 R2 is not RTM yet, so things may change, I can tell you that as of now this doesn't work and I wouldn't expect it to in the near future. Specifically, you added the caveat "in such a way that all the features work properly" ....RWA and OWA both want to do things to IIS, and they do create conflicts. So one feature will be broken. I don't expect that to change in RTM.
No can I point to documentation from MS that states this? No. But there also isn't documentation that you can't coexist the Lync edge role with the Exchange CAS role. Or that the DirectAccess Role can break SharePoint. In the enterprise, it is *assumed* that these roles would be installed discreetly, and it is only in the small business space that people seem to try to cram more onto a box. And with virtualization, that just isn't necessary anymore.
Which brings me to a small desire to respond some of the things you brought up in your follow-up to Susan. First, in several places you mentioned 3 VMs. But Susan's solution only requires 2 VMs. 1 Essentials/DC, 1 Exchange. And with 2012 (and presumably 2012 R2's) VM licensing, you can do that with one Standard license, so the licensing costs are not any different than trying to cram everything onto one physical or VM instance. The "three VM" argument seems to be coming out of thin air and doesn't seem applicable, and seems to intentionally complicate the proposed solution.
But to the underlying premise of your argument: " Microsoft tells me that putting all the roles and services on one box is TOO much" ....where have they said that? I think the best you can go with is that it has been inferred that it is too complicated, and to that I must say I agree, and it is the fundamental difference that none of the exposition of your position addresses. As already illustrated above, one machine running Essentials and Exchange CAS causes issues because both want to manage IIS. Split that into two VMs and you get two discreet installations of IIS. Let's expand that into your theoretical 3 VM solution vs 3 servers. Let's say you wanted that 3rd VM to split off the Essentials role from the ADDS role. A perfectly reasonable decision honestly, as less access to a DC (even via RWA) I think is a laudible security practice. But at that point you aren't making the decision to split those because there is "too much" on the DC from a workload standpoint, but the two VMs provide a logical memory and storage split that increases security. A very different proposition.
Or you wanted to run SharePoint. Again, a service that *really* likes to install accounts, change IIS, and install all sorts of patchable .Net bits. With your theoretical "all on one machine" solution, one bad .Net patch now brings down your DC, your messaging platform, and SharePoint. Split into discreet VMs, a bad SharePoint patch limits the scope of the patch to that one VM. Your environment can continue to run while you pull and restore a backup. Yay for virtualization.
So no, I've not ever seen an official stance that splitting these apart is because there is "too much" on one box, at least not from the perspective of how much CPU, memory, or other resources each individual role requires. But loading them all onto one machine, be it physical or virtual, *does* add unnecessary complication. These services, which run just fine discreetly, can adversely interact with each other causing all sorts of havoc. You need look no further that the last version of the SBS Standard stack we had for proof of this. SBS 2011 Standard was a fine product. But Exchange and SQL both want memory. Had they been in separate VMs, the nature of VM management provides very granular memory allocation and control. But putting them together....the SBS team did a fantastic job of making them work. BUT it only took one extra service to cause SBS to become unstable and freeze due to memory constraints. Whether that was an antivirus app that used SQL for managing remote patching or incident tracking. Or whether it was someone (again in the small business space) deciding to load a LOB CRM app or QuickBooks, trying to cram everything into one instance. Those types of apps grab the little remaining memory and ...poof... SBS freezes on a regular basis. If you read the forums, you'll see just how often this happens, and how ...when the sysadmin bothers to reply and take the troubleshooting steps recommended... it can almost always be traced back to a LOB app taking the last bit of free memory. In a VM world? Throw that LOB app into its own VM. It can't take the virtual memory allocated to SBS, so SBS stays stable in its VM, and the LOB app has a VM of its own with all of its own resources to take advantage of.
So hopefully the "footprint" of a hyper-v host, + AD + 3 (or more) OSes + Exchange + AD + DHCP + SharePoint + LOB + <insert favorite service here> now makes more sense as to why virtualizing does make more sense than 1 OS + AD + Exchange + DHCP + SharePoint + LOB. Even though you are removing Hyper-V and 2 (or more) OS installs from the equation, which at first blush seems to logically reduce workload on the hardware, it is *how* those workloads are managed that makes the difference. All on one OS, the OS now must try to keep all the moving parts in sync, and that isn't always even possible. In separate VMs, even with the (slight) added overhead of the extra pieces, now each OS can manage their own pieces, which is (perhaps paradoxically) less complex because of how virtualization partitions things. There is some added pressure for the sysadmin to learn Hyper-v. And there is a shift of manual work from managing all the apps on one server and the juggling that must happen to do so to patching multiple OS installs. But I submit to you that the end result is the same amount of actual work...perhaps actually slightly less, because you relieve yourself of the burden of wondering if an Exchange patch will kill your DC, and patch testing becomes easier and more modular. So the net result is not an increase in work, just a displacement of work from one silo to another.
As such, I will say that I believe Susan's answer is the correct one in this instance. The question you asked is very easy to specifically answer. Not all features will work. And the underlying subtext behind your question, which you expanded on in your reply to Susan, can now also be addressed and...hopefully...be understood where the misconception lies. I can think of no legitimate reason, given the current licensing model of 2012 (and presumably 2012 R2) why you'd do this any other way.Thursday, July 18, 2013 11:59 AM
Thank you for the thoughtful and detailed reply.
I spoke of 3 servers, not 3 vms because the HyperV host itself is going to need to consume some resources. (Though, one could always use core and try to bring that footprint down - but once again, core isn't exactly the environment to pass on to an SMB non-enthusiast)
As I've mentioned, I've deployed a few servers that fit the best practice here (I used Essentials transmog) and I've liked this approach, but I feel it's important to know and understand what other approaches are allowed, if not from a deployment standard, but from an "I've inherited the stupidest possible configuration - what can I do now?" approach.
I appreciate your replies as well. I've also used ARR in situations where I only have one Static IP available - it is really a sweet configuration. Don't get me wrong, I understand that you're presenting the best configuration (in terms of stability, cost and supportability) - and I appreciate that wholeheartedly. If anything, the official response (even if it's a no) will make it easier to explain it to my customers why we can / can't recommend that configuration and why we can / can't support that configuration if we come across it. Thank you for going through the process of getting an official statement from Microsoft.Thursday, July 18, 2013 3:11 PM
Sorry for not responding sooner, Richard. Susan and I (and others) have been discussing this offline.
Per the previously stated position that Exchange on a DC is not a recommended configuration (but not unsupported), that same advice applies whether you are running the Windows Server Essentials Experience role or not. In general, regardless of Essentials, Exchange on a DC introduces potential behavior that can create difficult to support scenarios that don't surface if you are running on a domain member instead.
Having said that, our support statement is no different than that of Windows Server Standard without our role enabled in this case - it is supported but not recommended. Instead we would recommend that you stand-up your Exchange server in one of the guest VMs on your Standard Server.
JasonTuesday, August 06, 2013 1:18 AM
Jason - Thank you for the response. I am completely shocked to see that the response was not just a hard no.
Since it is supported, am I to assume that at some point after RTM, we'll see documentation on how to make IIS coexist for the essentials instance and the exchange instance? Or is Microsoft leaving that up to us?
At this point, I'm fully sold on the idea of multiple VMs, but I KNOW that given a clear OK from you folks that this is supported, I'll run into servers like these in the wild and will have to repair them. To be honest, that's the concern that made me start this topic - I end up fixing a lot of screwed up servers.
Touching on your last paragraph "our support statement is no different than that of Windows Server Standard without our role enabled" - am I to assume that any roles supported in Server Standard are supported w/ Essentials Role Enabled, or is this on a case-by-case basis? Specifically, what's your take on Hyper-V on a Server Std w/ Essentials Role box?Thursday, August 08, 2013 5:59 PM
Well I'm not Jason...so you can take my response for what's its worth
Jason replied with the following " In general, regardless of Essentials, Exchange on a DC introduces potential behavior that can create difficult to support scenarios that don't surface if you are running on a domain member instead. " So given that from the beginning you're told the potential is there for difficult to support scenarios, why would you consider going down that road? As someone somewhere once said, "Just because you can, doesn't mean you should".
And given that they don't recommend the scenario...it's hard to imagine that they'd write up a guide on how to do it, but you can always hold out hope.
Cris Hanna, Microsoft SBS MVP, Owner-CPU Services, Belleville, ILThursday, August 08, 2013 9:00 PM
Cris, I appreciate your candor and the response.
I get it - I really do, but, I know, all too well, how hard it is for SMBs to find a competent partner to help them navigate the best practices. I don't know if it's something in the water here, but you would not believe the kind of servers I've inherited.
Ultimately, what I need to know is, when confronted with a 2012 R2 server with everything jammed onto it, if I can tell the customer "This isn't the best way to do it, but we can do this, this and this and get it somewhere stable enough to get some return on your investment" or "Microsoft won't even support this, we need to consider scrapping and starting over"
Now that I know the official answer is that it's supported, but not recommended, it would be nice to know if there's going to be some documentation/tools to help us repair/assess/maintain these edge case scenarios when we come across them. I just know the major pain point is going to be IIS co-existence, so I'm holding out hope that Microsoft is going to release some kind of documentation on how to make these services coexist if it's going to be supported. (I always thought supported implies that it will work, just not optimally - if you install both roles as it stands, either exchange or RWA/exchange integration will undoubtedly be broken)
For what it's worth, I've researched and reconsidered my earlier opinion quite a bit over the last month and I've come to better understand the concept of breaking this scenario into multiple VMs. There's advantages (as above) and disadvantages (complexity for smaller businesses) - and I find myself buying into the multi-vm configuration more and more over time (the first step is denial, right?) - I'm past the point where I want to "create difficult to support scenarios" - but I can't turn away from the fact that I've "inherited difficult to support scenarios" in the past and will probably continue to do so. Part of the planning process is understanding how much information is going to come from Microsoft and how much is going to come from trial and error.Thursday, August 08, 2013 9:38 PM
You're not the only one inheriting servers where the "consultant" had less than a credible knowledge of what he/she was doing. I'm we could burn hours sharing war stories. While each of us has a goal to be profitable in our business you don't strike me as the kind who would change a customer's environment, just to create billable hours.
So I think you're on track in presenting to your customers that the configuration they are in which is giving them so much trouble is not a recommended configuration. That's a true statement. You can then present them with options a) I can get on the phone with Microsoft, because according to statements I've received it should be supported. This will result in not only the cost of the support call plus all the hours I'll be tied up with them, and in the end, we might never actually resolve it and have to go with Plan B anyway. or b) we can take a weekend, and we can reconfigure the server setup, creating several separate server setups, all on the same physical hardware you have now. When the work is completed, you will find that the network is operating as it should, and in a manner recommended by Microsoft with the potential additional benefit of quicker recovery in the event of a disaster. It will mean the network being down for the weekend, but we know where we'll be at the other end. I can't imagine anyone not going for plan B
Cris Hanna, Microsoft SBS MVP, Owner-CPU Services, Belleville, ILThursday, August 08, 2013 9:51 PM
We don't have any plans currently to put out any further documentation on how to best address these situations that you may inherit here... I get your pain on this. I'll talk with the team on this, but as you know we have a never-ending list of articles we'd like to write so need to balance accordingly.
To your question on role support between the Windows Server Essentials Experience Role and others - we have no other roles that are not supported when the Essentials Experience Role is enabled. Hyper-V is for sure fine in this case.
JasonMonday, August 12, 2013 9:37 AM
I am currently designing a new server setup. We would like to go with Essentials and Exchange. I understand the VM advantages explained above and was thinking on the scenario Hyper-V with 2 VM's, would this be considered the preferred setup or are there better setup's possible without spending too much extra?
Also, what would be the licensing fees in this scenario assuming 35 users with email (this includes 20 remote users that are never onsite) and 15 users with remote logins to the server? Would that be 35 Server CAL's + 35 Exchange CAL's and 15 RDP CAL's?
GaryFriday, September 27, 2013 2:10 PM