Windows Server 2012 R2 Datacenter – Today Versus Tomorrow's VIrtualisation Requirements Part 1


Today's post and the next in this series continues on the Windows Server Datacenter focus, but this time round the emphasis is on the reasons why you may have deployed it traditionally, versus tomorrow's requirements. I will address the current on-premises Microsoft technologies you may have been using, as well as moving through the various stages of using different Microsoft cloud technologies alongside your existing infrastructure.

Starting with the tradtional uses of Microsoft products in virtualised environments we usually see workloads such as Remote Desktop Services, Line Of Business Applications that might have a SQL Server requreent, Exchange Server and Domain Controllers split out into seperate virtual machines where possible, and for many organisations these are elements that still make sense. For customers with a requirement for a high speed local file server and Active Directory providing services such as Group Policy to domain joined machines, these aren't necessarily things that your internet connection can provide, unless you happen to be blessed with bandwidth outside of the scope of most Australian SMB customers.

There are some workloads, however, where the impact of removing them from the on-premises insfrastructure, and taking advantange of cloud scale and accessibility make sense for many, such as migrating email capabilities to Exchange Online in Office 365. Then you can also start leveraging the other capabilites in Office 365 that may have been out of reach of the budget of the typical SMB customer, such as SharePoint and Skype For Business, just to name two additional components of Office 365.At this stage your virtualisation requirements may start changing, especially when you start looking at leveraging additional capabilities Microsoft provides in their range of online services.

If we go back to when Small Business Server was available in the marketplace, there were alsways interesting additional products that could be added to the network, but sometimes getting an official response about supportabilityu in an SBS environment were hard to find. Something may have been happy to run alongside SBS, but the support story would change if you asked about installing this on the SBS hardware or virtual machineitself, as opposied to running the new service on dedicated hardware or its own virtual machine. Some of these questions even started being raised around whether or not the Microsoft software for synchronising from on-premises Active Directory to Azure Active Directory (upon which Office 365 relies upon) could run alongside the other services that Small Business Server ran.

Why the confusion? First of all, it was never explicitly stated whether or not SBS was a supported platform, instead it refered to various versions of Windows Server. Those who played it safe would read that as saying SBS definitely was not supported, while those looking to minimise costs would look at from the point of view that SBS was not called out by name as not being supported. In cases like this, you need to generally need to focus on what is being explicitly listed as supported, which SBS was not. Where this was made more confusing for some was that changes were made to allow the directory synchronisation software run on a domain controller, which of course grabbed the attention of those running SBS, as it was a definitely a domain controller.

However, SBS was much more than a domain controler. Ignoring everything else that SBS did, even if we just focus on the other major piece of software that was running, Exchange Server, it was never mentioned or suggested anywhere in system requirements that directory synchronisation would run alongisde Exchange Server. In a production environmnt this isn't the type of risk most would be willing to make, and would understand that isolating workloads defintely had a role to play.. We even run into a similar situation with the Windows Server Essentials role and product, which I'll explain next.

With SBS having reached end of sale a while back, and now having the Essentials role being available to Windows Server 2012 R2 and available as a seperate product, there may be times when you need to run the latest version of the Azure AD/Office 365 synchronisation tool, Azure Active Directory Connect, we find the following information on its requirements page – "Azure AD Connect cannot be installed on Small Business Server or Windows Server Essentials. The server must be using Windows Server standard or better." This makes it clear that even at this point we still need to thinkg about workload isolation, and that's what we get with the virtualisation rights of Windows Server Datacenter.

In the next post I'll focus on the adoption of new cloud workloads, and how integrating them with on premises technologies can affect your virtualisation requirements.

Comments (2)
  1. Anonymous says:

    In the last post I briefly discussed some of the traditional workloads we virtualised for SMB customers

  2. Anonymous says:

    In the final of a three part series I will discuss some of the Windows Server roles that you may not

Comments are closed.

Skip to main content