Blog Archive

Per-Core Licensing FAQ

Windows ServerWindows Server 2016 (Standard and Datacenter Editions) and System Center 2016 will be changing to per-core + client access licence (CAL) when they are released towards the latter part of 2016.  We briefly blogged about the change earlier and we’re seeing a lot of the same questions so why not use that as an excuse for another post?

Why change?

The world is becoming cloudier and these licensing changes enable customers to operate more easily across on-premises servers and private and public clouds because we can just use a consistent currency of cores that simplifies licensing of hybrid use cases.  For example, a two-processor licence of Windows Server 2012 R2 on-premises today is translated into 16 cores of Microsoft Azure use right benefit.  If both of these environments are core-based it’s a nice easy transition.

Will I Still be Able to Virtualise with Standard Edition?

The case for licensing Datacenter Edition is for high-density virtualization, private clouds and hybrid cloud use.  The keys to making that successful are automation and being able to define networking, storage and the like with software rather than physically connecting network cables.  So Datacenter Edition will provide advanced software defined datacenter capabilities to make it the ideal for highly virtualized or private cloud environments.

Standard edition will not these features or will have them in more limited form.  Hyper-V is still included in both editions however and you can still virtualise in Standard Edition.  It will continue to be ideal for low density virtualized scenarios, including the use of containers and in some instances it makes financial sense over Datacenter Edition.

If you’re concerned that your solutions running on Windows Server 2012 Standard edition may not work after an upgrade, fear not; no pre-existing features are being moved from Standard to Datacenter.  Datacenter will be a superset and contain all the features of Standard edition.

Even though we’re writing about licensing in this post, we should cover a couple of Windows Server features just because they might affect how you licence.  Namely, Hyper-V containers, Windows Server containers and Nano Server.

Hyper-V Containers and Windows Server Containers

Historically, each server application would run on its own physical server; a 1:1 application to server ratio to ensure no conflicts with existing applications and workloads.  This resulted in a large number of physical servers, all typically with low utilisation.

Virtualisation of multiple applications onto a single physical server is now prevalent and we enjoy significantly higher consolidation ratios, greater utilisation and faster application deployment times measured in minutes rather than hours or days in a purely physical datacenter.  Plus all the benefits of virtualisation such as higher levels of redundancy and mobility.

There is however, a new and increasingly popular way to build, ship, deploy and instantiate applications: containers.

Whereas virtualisation is still 1:1 application to OS, albeit a virtual OS, containers can run multiple isolated applications on a single OS known as the control host.  And containers can run on a host OS which itself could be physical or virtual, so that’s fantastic flexibility.

That’s the difference between a Windows container and a Hyper-V container.  A Hyper-V container has a virtual host OS.   A Windows container uses the physical OS as the host.

With Windows Server 2016 Datacenter, you can run unlimited containers just as you can perform unlimited virtualisation.  With Standard Edition you are entitled to have unlimited Windows Containers, because they run with the physical OS as the control host.  Hyper-V containers follow the same rules as virtual operating system environments (VOSE) in that you are allowed two virtual control hosts every time you completely licence all physical cores on the server.

 

Virtualisation Licensing for Windows Server 2016

 

But why do we need containers?  What do containers provide that virtual machines can’t?

For the developers, containers unlock the ability to build an application, package within a container, and deploy, knowing that wherever you deploy that container, it will run without modification, whether that is on-premises, in a service provider’s datacenter or in the public cloud such as Azure.  You can also have complex multi-tier applications, with each tier packaged in a container.

Nano Server

So that’s containers in a nutshell.  What about Nano Server?  Is that a special edition for my granny?

If you are hosting lots of VOSEs, the last thing you want is for the host OS to reboot because that means everything I’m running on that host either needs to migrate to another server or also reboot.  You want to minimise what’s running to reduce the resources used and the surface area open to bugs and attacks. Yes, I used the B word.

Windows Server 2008 came up with Server Core which was a hugely reduced installation intended to just support specific workloads such as hosting VOSEs.  Windows server 2012 improved Server Core so it was more modular and you could install and configure the server and then switch into Server Core whereas in 2008 it was an either-or choice at installation.

 

Windows Server Core between 2003 and 2012

 

Windows Server 2016 goes further with Nano Server.  Just to give you an idea of the scale here, the charts below compare setup time, disk footprint and VHD size between the already trimmed Server Core installation and the new Nano Server.

 

Windows Server 2016 Nano Server

 

Now the big question here is how do you licence Nano Server?

Well, Nano Server is a deployment option within Windows Server 2016.  It’s included as part of the licensing of both Standard and Datacenter editions so there is no unique or separate licensing for Nano Server.  Good news.

Look Like an Expert with these Extra Facts

Q – Will the Core Infrastructure Suite SKU also be core based licensing?

A – Yes, Core Infrastructure Suite is a single SKU incorporating both Windows Server and System Center at a discount.  This will also be core based when Windows Server and System Center are released.

Q – Is the Windows Server External Connector available at the release of Windows Server 2016?

A – Yes, the Windows Server External Connector license will still be available for external users’ access to Windows Server.   Just like it is today, an external connector is required for each Windows Server the external user is accessing.

Q – How should I think about hyper-threading in the core based licensing?

A – Just count the physical cores.  Windows Server and System Center 2016 are licensed by physical cores, not virtual cores.  So you only need to inventory and license the physical cores on the processors.

Q – If processors (and therefore cores) are disabled from Windows use, do I still need to license the cores?

A – No, if the processor is disabled for use by Windows, the cores on that processor don’t need to be licensed.  For example, if 2 processors in a 4 processor server (with 8 cores per processor) were disabled and not available for Windows Server use, only 16 cores would need to be licensed.  However, disabling hyper threading or disabling cores for specific programs does not relieve the need for a Windows Server license on the physical cores.

 

Don’t Forget CALs

Windows Server Standard and Datacenter editions will continue to require Windows Server CALs for every user or device accessing a server (See the Product Use Rights for exceptions).

Some additional or advanced functionality will continue to require the purchase of an additive CAL.  These are CALs that you need in addition to the Windows Server CAL to access functionality, such as Remote Desktop Services or Active Directory Rights Management Services.

Feel free to contact us if you have any questions – we love to hear from you!


How to Coexist A and D VMs in Azure

Microsoft Azure LogoMicrosoft Azure virtual machines are not the same as on-premises VMs.  Steve Plank’s excellent blog post on the difference between Azure Cloud Services and Azure VMs goes some way to explaining the reason why.  Bearing this in mind there are some common questions which only make sense when you think about how Azure services work.

Many customers have mentioned that they can’t change between an A series VM and a D series, or they can’t mix A and D series within the same cloud service.  However, it’s entirely possible to do both of those.

Firstly, why would you need to?  Let’s take a customer who has moved an on-premises line-of-business server application onto Microsoft Azure to take advantage of the cost-efficiency, super-reliable data centres and the ability to scale.  The customer has started with a Standard-tier A2 compute unit (11p per hour for 2 cores and 3.5GB RAM) but after their data volumes increase they find the IOPS from hard disk drives are becoming a bottleneck so they’d like to move the workload onto a D series to enjoy increased throughput from solid-state drives.

Having created the VM as an A2 in a new Azure virtual network or cloud service, they find that when they log on to the Azure portal and try to scale the VM up, D series machines aren’t available.

Scale Azure VMs

 

If the customer tried to create a new D series VM in the same VNet or cloud service, they will also receive the following warning message telling them the cloud service doesn’t support those compute units.

Warning for Azure A Series Cloud service

 

If you create an A series VM in a new cloud services, Azure’s cloud fabric will host that VM in a cluster that currently may only support A series.  That’s why you’ll see the behaviour that our customer has experienced.

It is not possible to move a VM between cloud services either so even if you had a service currently hosting D series VMs, the customer would need to delete their VM (but choosing the option to keep the attached disks) and recreate the VM from the attached disks in the other cloud service.

So our little trick would be for this customer to create the VM as a D series initially and as soon as it’s created, scale the VM down to an A2.  That way Azure will host the VM in a cluster capable of supporting both A and D series compute units.  The customer can scale up, down and mix VMs of A and D series to their heart’s content (with the exception of the A8-A11 compute sizes).  The image below shows a cloud service with both A and D series compute units.

Azure mixed VMs in a single cloud service

 

This doesn’t work with G series currently but at present they can only be hosted in the West US and East US 2 data centres anyway.  Of course the feature release cadence of Azure is rapid so it’s likely this will be possible at some point in the future.

How would the customer have known to create the D series first to avoid this trap?  We’d recommend utilising a Microsoft partner with experience in Azure services or attend one of our training courses; that’s what we’re here for.


Azure Cost Estimator v2.0

Azure cost toolThe most common question we get when running Microsoft Azure events is “why are you wearing those ridiculous trousers?”

The second most common question is “How much does Azure cost?”

My favourite analogy is to compare Azure to a box of Lego. Lego isn’t in the business of selling boxes of Lego; go into a toy store and you’ll see a racing car or spaceship or a cityscape or the Sydney Opera House. Think of Azure services like hundreds of Lego blocks and rather than trying to describe this to people (“I have a box of Lego, what would you like it to be?”), create your own scenarios and solutions (“I have a site-to-cloud VPN with 5TB bandwidth”, “I have a high availability SharePoint web farm”, “I have cloud protection for 20 Hyper-V virtual machines”).

The benefit of describing Azure in terms of solutions is that you can price them, market them to whomever is paying for them and very importantly, you can automate them with PowerShell and XML which makes them easy to set-up, move, scale, etc..

A big part of creating these solutions is determining how much they will cost. There are several Azure pricing tools available; Azure.com, a more detailed cost estimator, and the new Azure scenario tool which we’re describing in this blog post.

The tool has two sides to it.  The first is an agent which profiles real-world machine hardware usage and uses that information to recommend the most appropriate Azure set-up and generate a 31-day cost estimate.  The second side is to choose from a selection of Azure scenarios (some of which are pictured below) or putting together your own package.  This menu of scenarios will grow over time as more are added to Azure documentation or come to light from customer and partner suggestions.

Estimator scenarios

The tool can download current Azure pricing with a click of button and it works in multiple currencies (24 at the time of writing).  You can also generate a report on the detailed infrastructure cost broken down by compute, bandwidth, data, support, etc.  Scenarios can be exported to XML but unfortunately there’s no way yet to use this generated file with PowerShell to automate the set-up of a particular package.

The scan agent supports Microsoft technologies (Hyper-V, SCVMM), VMware technologies (vCenter, ESXi) and physical environments (Windows and Linux).  Future updates may include XEN Server support and the option to import workloads from from MAP and vSphere.

Download the tool today from and if you have any useful feedback or suggestions please email feedbackAzureCalc@microsoft.com.


Microsoft Azure RemoteApp Overview

Microsoft Azure Logo

We’ll cover a technical look at RemoteApp in an upcoming blog post but in this post we examine what Azure RemoteApp provides and how to licence it.

Why is RemoteApp Useful?

According to Microsoft, around 75% of employees bring technology of their own to work and nearly 30% of employees use three or more devices at work. These employees clearly want to access corporate resources from their devices. One way for IT to provide this is through desktop and application virtualization where the device is merely used as a ‘window’ to the user’s full Windows Desktop running remotely on a server somewhere. So a user could be sitting in their favourite coffee shop, using their iPad, viewing and interacting with their company pc desktop and applications.

There may be times when the employee doesn’t need access to an entire desktop session but just wants to run a business application virtually. Azure RemoteApp allows IT to deliver virtual application sessions from the cloud. If the distinction isn’t quite clear, imagine sitting in front of your pc or laptop and seeing your Windows start button, background picture and the huge amounts of icons and shortcuts on your messy desktop (unless you’re one of those tidy-desktop people). Now imagine doing exactly the same but from a different device, such as your home pc, iPad or Windows Tablet. You’re seeing your entire desktop and then you would run applications, etc.

Now imagine using your iPad, home PC or Windows tablet and you have a shortcut to a business application that you need for work. Your run that application and you see the application’s window on your device as if it was a native application installed locally. That’s RemoteApp.

You should now understand the first advantage; IT don’t need to virtualize and expose entire desktops, but just collections of applications.

Secondly, at the time of writing, Azure Virtual Machines (VMs) are primarily for hosting middle-tier applications. You wouldn’t spin up an Azure VM and pop client software on it and allow lots of users to remote desktop into it. Technically it can work but an Azure VM only includes 2 Remote Desktop Session (RDS) licences so any more than two people connecting at a time requires additional RDS licences. Azure VMs are good for hosting the middle-tier applications that client (front-end) applications will connect to. The front-end applications might be a Windows application or a web-based application.

Azure RemoteApp is designed to vitualise a client-application to multiple users from the cloud and all the necessary infrastructure licences are included, including all the RDS licences.

So could a customer deploy Microsoft Office 365 ProPlus onto Azure and deliver it virtually to users via RemoteApp. Yes, in fact here’s a nice little webcast from the Office team stating just that. Office on-premises is still licensed per-device and doesn’t allow licence mobility so Office licences acquired on-premises can’t be used for Azure RemoteApp service; it’s just Office 365 ProPlus.

We must be clear here about the applications that are supported; RemoteApp delivers applications running on Windows Server in Microsoft Azure. Applications must therefore be compatible with Windows Server 2012 R2.

Azure RemoteApp has a selection of pre-built application collections to choose from or IT can upload template images to the Azure management portal. Users obtain the appropriate Azure RemoteApp client for their device via http://remoteapp.azure.com. When they launch the client they are then prompted to login, where they can choose to authenticate with either their corporate credentials, Microsoft account (e.g. Outlook.com) or their Azure Active Directory account. After authenticating, the user will see the applications their IT Admin has given them access to and can then launch whichever application they require.

Each user has 50GB for persistent user data and because Microsoft is using RemoteFX technology here, users will get a great experience: applications will support keyboard, mouse, local storage, touch and some plug-and-play peripherals on Windows client devices. Other platforms will only support keyboard, mouse and touch. Local USB storage devices, smartcard readers, local and network printers are supported and the RemoteApp application will be able to utilize multiple monitors of the client the same way a local application can.

How is Azure RemoteApp Priced?

In order to get started with Azure RemoteApp, you will need an Azure account. Azure RemoteApp is priced per user and is billed on a monthly basis.

The service is offered at two tiers: Basic and Standard. Basic is designed for lighter weight applications (e.g. for task workers). Standard is designed for information workers to run productivity applications (e.g. Office).

The service price includes the required licensing cost for Windows Server and Remote Desktop Services but it doesn’t include the application licence, for example you still need an Office licence if you wish to use that. The bandwidth used to connect to the remote applications (both in and out) as well as bandwidth used by the applications themselves is also included with the service.

Each service has a starting price that includes 40 hours of connectivity per user. Thereafter, a per-hour charge is applied for each hour up to a capped price per user. You won’t pay for any additional usage after the capped price in a given month.  Azure RemoteApp billing is pro-rated per day in case you remove a user’s access part-way through a month.

Microsoft Azure RemoteApp

As we mentioned, you create app collections which contain the applications you wish to run and you can assign these collections to a set of users. Currently you can create up to 3 app collections per customer and each app collection will be billed at a minimum of 20 users. If you have less users, you’ll still be billed for 20. Hopefully this will change as it’s a bit of an Achilles’ heel for small businesses. RemoteApp basic scales to 400 users per collection and RemoteApp standard scales to 250. If you want to extend any of these limits, or if you want users to access more than one app collection, you’ll need to contact Azure support.

We must reiterate that the customer is responsible for complying with use rights of the applications they bring onto the RemoteApp service. This includes Office and as you can see at the bottom of this table, Office ProPlus can be utilized as one of the installs for licenced users and this is treated as Shared Computer Activation.

Most existing 32-bit or 64-bit Windows-based applications run “as is” in RemoteApp but there is a difference between running and running well.  There’s guidance on the RemoteApp documentation pages at azure.com.

So in summary:
• Azure RemoteApp is priced per user per month
• The service is offered at two tiers: Basic and Standard
• Basic is designed for light-weight applications
• Standard is designed to run productivity applications
• Each service has a starting price that includes 40 hours of service per user
• Thereafter, an hourly charge is applied for each user hour, up to a capped price per user
• No charge for any additional usage above the capped price in a given month


SQL Server 2012 Licensing

Just when you think Microsoft licensing is straightforward and you’ve got a pretty good grasp on it, along comes SQL Server which has historically been the exception to the licensing rules.  However with SQL Server 2012 Microsoft has done a great deal of simplification so it’s easy to understand the basics.  You’re going to approach licensing differently depending on whether you’re deploying SQL Server in a physical or virtual environment.

SQL Server Licensing in a physical environment.

SQL Server is available is three main editions; Standard, Business intelligence and Enterprise.  The Enterprise edition is licensed per core (no CALs required), Business Intelligence is licensed per server and client access licence (CALs) and the Standard edition can be licensed using either method.  This is summarised below.

SQL2012Editions

 

Before I present a little flowchart which might make you decision easier, let me clarify a few things about per-core licensing.  We are talking per-core here and not per-physical processor, unlike Windows Server 2012.  Currently SQL Server 2012 and BizTalk Server 2013 are the only Microsoft products licensed per-core.

To find out the appropriate number of cores you need to licence, simply count the number of cores in each physical processor in the physical server.  Software partitioning doesn’t reduce the number of cores you need to licence. Once you have that you need to remember three things:

1. You need a minimum of four core licences per processor.  So if you have a dual-core, dual-processor machine you would need to count that server as a dual, four-core processor and purchase licences for eight cores, despite only having four cores in total.

2. SQL Server 2012 core licences are sold in packs of two: each SKU covers two processors.  So in our example above we would purchase four SQL Core licence SKUs to cover eight cores.

3. Certain AMD processors need to have a multiplication factor of 0.75 applied to the core count.  See this link for the processors in question and what to do.

For server and CAL, SQL Server works in the same way as any other Microsoft server + CAL product.  Licence the server(s), determine the number of unique users and/or devices accessing the SQL Server and purchase the appropriate number and type of CALs.  SQL 2012 CALs will allow access to all previous versions of SQL Server.  Also you don’t require a separate CAL for every SQL Server; a SQL Server 2012 CAL allows access to all the SQL Servers within the organisation.

A simple way of determining the edition and licensing of SQL Server 2012 is below.

SQLEditionFlowchart

 

SQL Server Licensing in a virtual environment.

Regular readers of the licensing blog will be saying “I bet this has something to do with Software Assurance (SA)”.  Well, you’re partly correct.  I’m going to assume you’re running Windows Server 2012 Datacenter edition on these boxes just for simplicity and I haven’t included details of the VOSE OS.

For SQL Server Standard and Business Intelligence editions you can licence individual virtual machines (VMs) using the server + CAL model.  Simply purchase one server license for each VM running SQL Server software, regardless of the number of virtual processors allocated to the VM. Then purchase the appropriate number of CALs.

For example, a customer who wants to deploy the Business Intelligence edition running in six VOSEs, each allocated with four virtual cores, would need to assign six SQL Server 2012 Business Intelligence server licences to that server, plus the CALs to allow access.

For SQL Server Standard and Enterprise editions you can licence individual VMs using the per-core model.  Similar to physical OSEs, all virtual cores supporting virtual OSEs that are running instances of SQL Server 2012 must be licensed.  Customers must purchase a core license for each virtual core (aka virtual processor, virtual CPU, virtual thread) allocated to the VOSE.  Again, you are subject to the four core minimum, this time per VOSE. For licencing purposes, a virtual core maps to a hardware thread.  When licensing individual VMs, core factors (i.e. the AMD processor 0.75 factor) do not apply.

Two examples are shown below for clarification: SQL Server core licences required for a single VOSE on a dual, four-core processor server and for two VOSEs.

SQLVirtualisationExample1

 

SQLVirtualisationExample2

 

With the SQL Server 2012 Enterprise edition (note: not Standard edition), if you licence all the physical cores on the server, you can run an unlimited number of instances of SQL Server, physically or virtually as long as the number of OSEs with SQL doesn’t exceed the number of licensed cores.  For example, a four processor server with four cores per processor provides sixteen physical cores.  If you licence all sixteen cores, you can run SQL Server in up to sixteen VOSEs (or the physical OS and 15 VOSEs), regardless of the number of virtual cores allocated to each VM.  What if you want to run more than 16 VOSEs in this case?  Well, you are permitted to assign additional core licenses to the server; this is known as licence stacking.

Here’s where Software Assurance comes into play.  Licence all the physical cores with SQL Server 2012 Enterprise Edition and software assurance and your licence rights are expanded to allow any number of instances of the software to run in any number of OSEs (physical or virtual).  This SA benefit enables customers to deploy an unlimited number of VMs to handle dynamic workloads and fully utilize hardware computing capacity.  As with most SA benefits, this licence right ends if SA coverage on the SQL core licences expires.

Licensing for maximum virtualization can be an ideal solution if you’re looking to deploy SQL Server private-cloud scenarios with high VM density, Hyper-threading is being used so you’re looking at a lot of virtual cores to licence, or you’re using dynamic provisioning and de-provisioning of VM resources and you don’t want the headache of worrying about adjusting the licence count.  As you can see in the diagram below this can be very cost-effective.

SQLVirtualisationOptions

 

We run a regular licensing spotlight call on behalf of Microsoft where we cover this and other topics in more detail.  Please join us for the next call and you can view archived calls here.