Deploying Server 2012 R2 desktops through VMware Horizon View

There are a lot of moving parts when it comes to desktop virtualisation, as I’m sure many will tell you. One of the ways you can drastically simplify things is by using VMware’s desktop virtualisation product, Horizon View.

Some might say that it’s more complex than its competitors, however if you’re already using VMware products and are familiar with vSphere, is there really any other choice?

Licencing

TLDR;

• Even if you’re using PCoIP or Blast, you will still need to buy RDS CALs (here’s their licencing FAQ). It’s a real grey area, because in the brief it states you only need RDS CALs if you’re using RDS roles – in this case, we aren’t, but it still needs to be licensed.
• If you’ve licensed the physical hosts for Datacenter edition, you can have as many desktops as you want running on it, so you only need the CALs, and not VDA.
• We bought Server 2016 and used downgrade rights to run exclusively in Server 2012 R2, not mixing. There is no clear answer on whether you can mix 2012 R2 and 2016 VMs in clusters, so it’s a lot simpler to just keep the whole environment consistent.

Licencing is probably the worst part of the whole thing, a) because it’s expensive and b) well, Microsoft. If you’re using Windows in your environment, and there’s a pretty good chance that’s the case.

I’ve been involved with quite a few of these solutions, most with Windows desktop operating systems, but one recently with Server 2012 R2 as the desktop OS.

There’s a good reason for this; this solution will eventually replace their Microsoft RDS environment. They currently have around 60-70 RDS servers which accommodates around 2000-2500 users. The servers are very beefy of course and are VMs on a large vSphere platform. Moving users to the platform means decommissioning other servers and moving the CALs.

I used this performance information to size up the VDI environment, which is going to start at 200 users. Why Server 2012 R2? Instead of buying Windows 10 licences, we saved money by using their existing Server 2012 R2 licences and licensing the new VDI hosts instead, meaning that we have enough Server 2012 R2 licences to eventually move everyone over to VDI. As long as the physical host is running Datacenter, you can run as many VMs as you want. 14 physical servers, expensive stuff.

So instead of people logging into a shared server, each person will get their own VM on the same OS so things will be very familiar. This is another tick in the box, as users won’t need to change the way they do stuff (some need a bit of hand holding when moving between operating systems for example).

RDS CALs? They’re already owned! Savings again.

We bought Server 2016 licences and exercised the downgrade rights to switch them all to 2012 R2. Tricky thing is that you can’t mix and match if you’re clustering – they must all be the same. Microsoft themselves (or their “expert” partners) really weren’t too helpful with how this works. I could, of course, be wrong here, but this is what I was told.

Hardware

I chose to size the physical hosts based on having 50 VDI sessions at a time (up to 100 if in a DR scenario with servers clustered across local datacentres). While memory is never usually a problem for this type of scenario (50x 4-8GB = ~400GB tops), CPU contention can become a problem pretty quickly. As it was designed for 50 users per server for normal operations, with their current RDS environment doing a lot more, things look good. Why is the RAM so high? The users are heavy on browsers, and have multiple tabs open across all 3 main web browsers simultaneously.

Storage

It’s very convenient that VMware bundles VSAN into the Horizon 7 licencing, so this was a total no-brainer.

VSAN is incredibly simple to set up, and is very quick too in terms of performance. For this particular environment, where desktops will be static apart from their monthly recompositing / updating (OOH), we chose hybrid rather than full flash.

On VSAN sizing, make sure your flash is sized to 10% of your usable total storage. VSAN, by default, sets its FTT policy to 1, meaning that you’ll lose 50% of your total raw disk space. For persistent data, such as persistent disks, this is a good idea. For non-persistent data, such as linked-clones, set the FTT policy to 0. View can just rebuild crashed desktops.

For VSAN, bear in mind some of your hosts’ resources will also be consumed, therefore ensure that you account for this.

Lastly, if any of this is wrong, please drop me a comment and I’ll update it.