In a Remote Desktop Services lab setup involving a gateway to allow connections to our virtual desktops over the internet we are going to need to use an SSL certificate to secure traffic between the remote devices and the gateway. Typically in the past we would have gone into a server running IIS and made a self signed certificate in IIS Manager and while this still works in IIS8.5 (the one that ships with Windows Server 2012R2) there is better way and that is PowerShell 4 that is also included in Server 2012R2. Why is it better? More control specifically we can add alternate names to correspond to all the DNS entries we might need in something like RDS. We also get all the other benefits of using PowerShell like repeatability and like all ne PowerShell commands it’s easy to understand what it’s doing..
To make a certificate:
New-SelfSignedCertificate ` -CertStoreLocation cert:\LocalMachine\My ` -DnsName rds-Broker.contoso.com,rds.contoso.com,rds-gateway.com
where the new certificate is going to be stored on the local machine in the “my” folder and it has two alternate names. By the way not everyone knows this but the ` character is the line continuation character and means I can format code that’s easier for you to read.
The new certificate is not much use where it is so we can also export it and if we want the private key we’ll need to password protect it. First we need to find it and to do that we can simply browse the certificates just as we might for any other kind file on a hard drive except that for certificates we are navigating through the certs: drive not the C drive. Get-ChildItem is the proper PowerShell command for navigating folders of any kind but it also has aliases dir ls, gci etc. I mention this because in some IT departments it is considered best practice not to use aliases but the root PowerShell commands to provide clarity, perhaps in the same way as we don’t use the word ain’t in an English class!
$Cert = Get-ChildItem -Path cert:\localmachine\My | ` where subject -EQ "CN=RDS-Broker.contoso.com, CN=RDS-Web.contoso.com, CN=rds.contoso.com"
Now we can setup a password and export it
$pwd = ConvertTo-SecureString -String "Passw0rd!" -Force –AsPlainTextExport-PfxCertificate ` -cert $cert ` -FilePath '\\rds-DC\c$\RDS-Web self signed certificate.pfx' ` -Password $pwd
We could then import this into our VDI deployment with PowerShell as well, but there is a simple UI in the deployment properties in Server Manager.
where we can check our certificates are installed and recognised as part of the deployment. Of course there is proper PowerShell for this..
set-rdcertificate ` -Role RDGateway ` -ConnectionBroker RDS-Broker.contoso.com ` -ImportPath 'C:\RDS-Web self signed certificate.pfx'` -Password $pwd #same as password above
which not only puts the certificate where it need to go but put makes the RD Broker aware of it.
Creating certificates is also going to be useful if we want to manage any evals , demos and labs we might want to work with in Azure but that is a story for another post , not least because I need spend more time in the cloud myself!
In the meantime do have a look at the PowerShell content in MVA, and if you aren’t running Server 2012R2 where you are you can install it on older operating systems back to Windows Server 2008 R2/ Windows 7 from here
If you are following me on Twitter then you may have noticed that a few of my friends are reviewing a book I am writing on VDI for PackT. I wanted to write this up as a one shop stop on all you needed to know about implementing Microsoft based VDI using the various Remote Desktop Services server roles in Windows Server 2012R2 with Windows 8.1 as the Virtual desktop OS. You would be forgiven for thinking that the hardest part of this book would be the last chapter Licensing, which I wanted to include precisely because it is widely touted as being hard and because you do need to know this stuff to implement it.
In the course of my research and my day job I have been doing some work with 10Zig and in fact it was as a result of some events we did together that I thought that Microsoft VDI needed to be written up properly and in one place. Prior to this I thought that thin clients were pretty much of a muchness and I certainly didn’t appreciate that they came in different types or how they have come on since I joined Microsoft. So I have asked Kevin Greenway from 10Zig to explain the world of the thin client and how your choice might affect the licensing..
The ever growing debate over which flavour of Thin Client is the right choice in relation to cost, performance, user experience, peripheral support, management, etc, etc, continues to fill blogs and review sites. Recent news from Microsoft on changes to Virtual Desktop Access (VDA) licensing to Windows Embedded throws a really interesting perspective on using a Windows Embedded based Thin Client for Virtual Desktop Infrastructure (VDI).
VDA, Thin Clients and PC’s
As of today if you wanted to use a Thin Client, which includes ‘Zero’, ‘Linux’ or ‘Windows Embedded’ based Thin Clients in conjunction with Virtual Desktop Infrastructure (VDI), you are also required to use Virtual Desktop Access (VDA) licensing. VDA licensing is charged at $100 per year for each device using this license. Couple that with the initial acquisition cost of any of the above types of Thin Clients which all require VDA licensing, the costs suddenly start to rack up and can exceed that of a traditional PC.
The VDA licensing does not apply if you use Microsoft Software Assurance (SA), which also includes some desktop virtualisation rights. Most commonly if a Windows PC is used as your endpoint for connecting to VDI and you have SA, this negates the need for VDA licensing. The downside to this is that by using a Windows PC as an endpoint, this doesn’t leverage any of the true benefits of VDI, most specifically the system administrator is now administering two desktops instead of one. There are options to alleviate this somewhat with products, such as Windows Thin PC*, but what if you want to realise the benefits of Thin Clients? These include Manageability, Ease of Deployment, Small Footprint, Power Savings, and Lifespan due to no moving parts.
*This only applies to repurposing windows OS, not OS agnostic repurposing solutions.
This is where the recent news from Microsoft comes into play.
VDA, Software Assurance and Windows Embedded Thin Clients
If you use Microsoft Software Assurance and you have a Windows Embedded Thin Client (Windows Embedded 7/Windows Embedded 8), then you can now move this into your SA, thus negating the need for VDA licensing. This means the total acquisition cost is potentially lower than equivalent PC’s and even Linux based Thin Clients or Zero Clients due to the Annual Charge of VDA.
Windows Embedded, Linux or Zero
As mentioned there is always the ongoing debate over which flavour of Thin Client is right. One of the biggest arguments against Windows Embedded based Thin Clients has traditionally been the Cost, User Experience (We’ll cover this one in a moment) and Manageability. However the biggest argument for use of Windows Embedded Thin Clients, is that typically the majority of VDI vendors including Microsoft, Citrix, and VMware will focus their efforts primarily around the compatibility, support and feature set available within the Windows version of their clients for connecting to VDI.
You typically see a greater feature set and an earlier adoption of new features within the relevant Windows clients, than you will against say Linux, Android or IOS equivalents. Additionally the ever growing list of peripherals required to either work locally within the Thin Client or be redirected into the VDI session, will typically be more pain free from a Windows based Thin Client, than they will from an equivalent Linux or Zero Client.
More recently we’ve also started to see more and more emergence of client based plugins to redirect Real Time Transport Protocols (RTP/RTVP), such as the Microsoft Lync 2013 VDI plugin, which is only available as a Windows Plugin. We also have the various Media offloading capabilities such as those within the RemoteFX, Citrix HDX and VMware PCoIP stacks, which often still result in a greater tick list of features within these stacks from a Windows Client than their Linux or Zero counterparts.
Let’s shift back to the topic of User Experience. Whilst adopting VDI one of the easiest ways to get user buy-in is ensuring that their use experience, including access and entry remains the same as it has been with a PC. You want to ensure ultimately that the user only has access to their VDI desktop, not the local operating system. This way there is no retraining involved, or risk that the user can access/break the local operating system. The end goal is that you want their access device to serve simply as a launch pad to their VDI desktop, whilst also leveraging the performance that they achieved from their local PC.
This is where Windows Embedded 8 really comes into great effect. Windows Embedded 8 includes some really great features including HORM (Hibernate Once, Resume Many) for shrinking boot speeds, as well as Unified Write Filter (UWF) for protecting Disk Volumes/Folders/Registry. Embedded Lockdown Manager is also available for Windows Embedded 8 and includes several lockdown features. Examples of features include Keyboard Filter, Gesture Filter, USB Filter and most prolifically the Shell Launcher. The Shell Launcher can be configured to provide the user with a launch pad to their desired VDI session and restricts access to the underlying local operating system.
There are several management tools available for managing Windows Embedded 8, including Microsoft based and 3rd Party tools such as those provided by 10ZiG Technology within Windows Embedded 8 based Thin Clients (5818V/6818V) and the Enterprise Free 10ZiG Manager.
[added 12/05/14 by Andrew] the official Microsoft guidance on licensing Windows 8 embedded can be found here.
To conclude this exciting news from Microsoft regarding the addition of Windows Embedded into Software Assurance (SA) and negating the need for Virtual Desktop Access License (VDA), thus dramatically reducing the overall acquisition cost per Thin Client device against a PC. Additionally the adoption of new and exciting features into Windows Embedded 8 heralds a potential shift in the VDI/Thin Client space towards Windows Embedded 8.
Couple it all together with HORM, UWF, ELM and Client offload techniques powered by modern multi core CPU Thin Clients such as those from 10ZiG Technology (5818V/6818V). We are now equipped with what is fast becoming a Hybrid of traditional Thin Client and PC Technology into one.
It’s an interesting space to watch in the ever evolving world of VDI and Thin Client Technology.
For more on VDI there’s some great content on the Microsoft Virtual Academy.