Thursday, December 17, 2015

Creating a Hyper-V Guest Cluster using SCVMM - Part 2

In part one of the series, we went over creating a Service Template using System Center Virtual Machine Manager for the purpose of creating a virtual guest cluster using Shared VHDX. In part two, we'll be going over provisioning the virtual servers from the Service Template. This process will create two virtual servers based on the settings we specified in the Service Template. When we are complete, you'll have two fully functional virtual servers utilizing Shared VHDX files, that you can then use to create a failover cluster.

Deploying The Service

Now that the Service Template has been created, you’ll want to deploy the new service. This process will provision the virtual machines specified in the Service Template. In SCVMM, right-click the Service Template and select Configure Deployment.

Give the Service a name (the name of the cluster works well) and specify where to deploy the service. Then click OK.

Tuesday, December 15, 2015

Improved Remote Desktop Connection Broker Performance with Windows Server 2016 and Windows Server 2012 R2 Hotfix (KB3091411)

Microsoft recently released a new hotfix for the RD Connection Broker role in Server 2012 R2 that significantly increases performance when brokering connections. It changes some of the algorithms that the Connection Broker role uses to process redirection requests, as well as modifies how the broker talks to the SQL database in an HA mode deployment.

At the recommendation of one of Microsoft's Premier Field Engineers, I installed this hotfix in my test RDS environment a few days ago, and have not run into any issues so far.

From the article for KB3091411:

This hotfix contains the following improvements:
  • Improves the number of successful user connections when many user connections are coming in (especially in peak logon periods).
  • Decreases CPU usage on SQL Server that's used in a High Availability-based Connection Broker deployment.
  • Optimizes the number of SQL calls that are invoked by Connection Broker when it processes RD user connections.
This hotfix improves the overall performance of the Connection Broker by being able to scale more user connections that typically occur during peak logon periods. 
This hotfix applies to both RD Session Host and Virtual Desktop Infrastructure (VDI)-based deployments.

The announcement on MSDN includes some additional metrics to help quantify some of the performance improvements:

Logon Storm
100% connection success with initial burst of 100 connections at a rate of 2 connections per second
0.2 second average connection time through RD Connection Broker, down from over a minute 
RDSH Add/Restart
100% success adding/restarting servers at rate of 1 server per second with 5 sessions per server
2 second average add/restart time, down from over thirty minutes 
MSTSC End to End
100% connection success at a rate of 100 connections per minute
25 second average connection time, down from over seven minutes
Link to the MSDN announcement -

Link to KB3091411 for Windows Server 2012 R2 -

Wednesday, December 9, 2015

Creating a Hyper-V Guest Cluster using SCVMM - Part 1

One of the really cool features that was added to Hyper-V in Windows Server 2012 R2 is something called Shared VHDX. Basically, this feature allows you to share a VHDX file between multiple guest VM's. With this, you can create a failover cluster between the guest VM's, using the Shared VHDX file as your shared storage for the cluster.

There are many great guides and articles out on the Internet for how to setup a Shared VHDX for your Hyper-V guests. Some even go so far as showing how to setup the failover cluster once the Shared VHDX is in place. However, most of these guides and blogs describe how to set this up using only Failover Cluster Manager.

If you have a larger Hyper-V implementation and are using System Center Virtual Machine Manager to help manage your Hyper-V environment, there is a caveat you need to be aware of when using Shared VHDX. If you setup a Shared VHDX outside of SCVMM, you'll be unable to use SCVMM to manage your guest VM's, as SCVMM will throw error 23317 anytime you try to modify the properties of the guest VM's.

SCVMM Error 23317 when using Shared VHDX
SCVMM Error 23317 when using Shared VHDX
Of the blog posts that mention this error, the common solution is to make your changes using PowerShell instead. While this is certainly valid, it's not always practical depending on the change you wish to make. There must be a better way...

And there is! Service Templates allow you to define an entire “service” that could consist of multiple servers and multiple tiers of servers (i.e. database tier, application tier, webserver tier, etc.). Using the SCVMM services functionality, we can create our guest cluster and Shared VHDX from directly within SCVMM, rather than using Failover Cluster Manager. Once we do this, SCVMM is now fully aware of the Shared VHDX and can continue to manage the VM's like normal.

Saturday, November 28, 2015

Finding users who still have the RDP 7.1 client

As an RDS administrator, one of the frequent problems I deal with is the fact that users have difficulty launching an RDS RemoteApp from home. Maybe they receive an error message, maybe single sign-on isn't working to a pooled desktop collection, or possibly a RemoteApp launches, but there is display corruption of some sort.

An extremely common problem I see is that many users with Windows 7 at home have not read our instructions and installed the RDP 8.1 client. Microsoft was able to add some pretty cool functionality and fix a ton of bugs with the RDP 8.1 client - at this point, it's basically a must-have piece of software for RDS administrators. If a user if having an RDS issue and they don't have the RDP 8.1 client, that's the first thing I recommend installing.

The challenge is how to determine when a user is still using the RDP 7.1 client, especially in remote access scenarios where you can't look at their PC or run a report using SCCM. I've found one place in the RDS logs where you can grab this information and I'll be showing a couple of different methods on how to easily search out and grab that info.

Thursday, October 22, 2015

RDS/RDP Support for TLS 1.1 and TLS 1.2 - KB3080079

Great news!

It appears Microsoft has finally released a patch for Windows 7/Server 2008 R2 that adds support for TLS 1.1 and 1.2 to the RDP protocol. The patch can be found at

But what about enabling TLS 1.2 support in your RDS 2012 R2 farm? When you set the security options on a Session Collection, clearly it lists support for TLS 1.0 only, as shown below.
TLS 1.0 support in the RDS console
TLS 1.0 support in the RDS console
Well, apparently RDS already supports TLS 1.2, despite what the GUI states. Microsoft also recently published another KB article explaining this -

Consider the following scenario:
  • You have a computer that's running Windows Server 2008 R2, Windows Server 2012, or Windows Server 2012 R2.
  • You have the Remote Desktop Connection Broker (RDCB) role configured on this computer.
  • You try to secure the RDP connections to the target computers by using SSL encryption (Transport Layer Security (TLS)).In this scenario, you may notice that the Security Layer list displays SSL (TLS 1.0), even though it's actually using TLS 1.2
This issue is caused by a bug in the Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 GUIs. You can safely ignore the TLS version that's displayed in the GUI because this does not reflect the version of TLS that's being used for client connections.
This is a welcome security improvement from Microsoft. Weaknesses have recently been found in the TLS 1.0 protocol, and any companies that require PCI compliance must phase out the usage of the TLS 1.0 protocol by June 2016, as mandated by PCI DSS 3.1.


After receiving a comment that this patch was not working, I spun up a quick lab environment to test out KB3080079 and ensure it actually worked as advertised. I enabled verbose Schannel logging to determine which version of TLS was in use when a RemoteApp was launched. I was using RDS on Server 2012 R2 - I did not test RDS on Server 2008 R2. My testing was successful - TLS 1.0 was used as expected before the patch was installed, and TLS 1.2 was used afterwards. This was tested both with and without RD Gateway. See my results below.

Without KB3080079, TLS 1.0 is used
Without KB3080079, TLS 1.0 is used
After installing KB3080079, TLS 1.2 is used
After installing KB3080079, TLS 1.2 is used

Wednesday, October 14, 2015

Hyper-V dynamic MAC addressing is a cluster...

Hyper-V dynamic MAC addressing is a cluster. There - I said it.

Microsoft has been making great strides with Hyper-V by adding new features and functionality. If you compare Hyper-V on Server 2012 R2 to VMware 5.5, most people would agree that Hyper-V is "good enough" and has most of the features that the majority of businesses require. Unfortunately Microsoft has overlooked a small detail - MAC addresses. Yes, MAC addresses - something you'd think would have already been a solved problem. If you've used Hyper-V in any capacity, you probably know that there are two methods for handling MAC addresses for your virtual guests:

  • Static addresses - where you can permanently set whichever MAC address you want
  • Dynamic addresses - where each guest pulls from a dynamic pool of MAC addresses that is defined automatically on a host.
MAC address options in Hyper-V Manager
MAC address options in Hyper-V Manager

Most organizations are likely utilizing dynamic MAC addresses for their virtual guests, as it's kind of the default "set it and forget it" method. This is fine for most purposes, especially if you statically set IP addresses inside your guests, or if you only have single Hyper-V hosts with local storage.

The dynamic MAC address range is set automatically on each host based on the IP address of the host, to ensure ranges do not conflict on multiple hosts. You can view the MAC address range for a host by opening Hyper-V Manager, and in the Actions pane, clicking on Virtual Switch Manager, and then by selecting the MAC Address Range option in the left pane of the Virtual Switch Manager.

Defining the dynamic MAC address pool on each host
Defining the dynamic MAC address pool on each host

The problem comes when you have multiple Hyper-V hosts in a failover cluster. When a VM using dynamic MAC addressing live migrates to a new node in a failover cluster, it retains the same MAC address to prevent network disruptions. However, as soon as that VM is rebooted, it will grab a new MAC address from the node it's currently on.

Now, in most scenarios that's fine. If you have servers that are using statically set IP addresses, the MAC address changing on reboot will have little effect. If you are hosting virtual desktops using DHCP, this shouldn't matter much either, as it's expected for the IP address of a desktop to change when using DHCP.

Thursday, October 8, 2015

IE Trusted Sites Not Working in RDS

Ran into a fun issue this week. For some reason, Internet Explorer Trusted Sites were not applying correctly when using Internet Explorer as an RDS RemoteApp. When looking at the Trusted Sites list, it would appear blank, yet you would be prevented from modifying the list because it was controlled by Group Policy. This caused all sorts of problems with internal websites that must be in the Trusted Sites zone to work properly.

In order to manage the Trusted Sites list, we utilized the Site to Zone Assignment GPO setting, and had quite an extensive list of entries. GPUpdate was showing the GPO was applying successfully. This was further confirmed by looking in the registry and finding the entries listed correctly under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap.

So there were no Group Policy errors, and the sites were being written to the registry correctly, yet it still wasn't working. It was time to pull out ProcessMonitor and figure out what was happening. First, a healthy and working session.

A working ProcMon capture
A working ProcMon capture
As we can see above, the user is successfully reading from the registry, including the subkeys Ranges and Domains. Next, through sheer dumb luck, I discovered that when IE Enhanced Security Configuration is enabled, the Trusted Sites list is not read from the registry. Here's a ProcMon from a system with IE ESC enabled.

A ProcMon showing IE ESC enabled
A ProcMon showing IE ESC enabled
The two screenshots are distinctly different. Notice in this capture that the system looks for the EscRanges and EscDomains subkeys, something that wasn't occurring on a working session with IE ESC disabled. Now, in my instance, IE ESC was disabled for users, so that shouldn't be the issue. Let's take a look at the ProcMon from an IE RemoteApp session...

A ProcMon taken from an IE RemoteApp session
A ProcMon taken from an IE RemoteApp session

Well that certainly looks familiar, doesn't it? We can see that Internet Explorer is looking up the EscRanges and EscDomains subkeys again, almost as if Enhanced Security Configuration is enabled, despite it clearly being off as shown by Server Manager and in the registry.

After doing some research (aka Googling), I discovered a TechNet forum post where someone offered a solution to this issue. There is an extremely deep registry key that needs to be changed.
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap
Under this registry key, you may find a DWORD called IEHarden. It was set to 1 on my RDS servers. By changing this value to 0, and resetting the user's profile (either delete their roaming profile or delete their User Profile Disk), this resolved the issue, and IE Trusted Sites were read correctly from the registry when using the IE RemoteApp.

The problem registry setting...
The problem registry setting...
This one caused me a day and a half of pain - I hope this post shows up in Google for someone else and helps them out!

Friday, August 28, 2015

RDS Pooled Virtual Desktops and Computer Startup Scripts

While troubleshooting an issue recently, I suddenly had a requirement to implement a computer startup script to run on a collection of pooled virtual desktops. No big deal, I thought. Computer startup scripts are common, and have been used in countless scenarios before. The script was written. The GPO was modified. Everything looked good. But, lo and behold, it wasn't working. This should have been easy, so why the failure?

To understand why the startup script wasn't processing for pooled desktops, we have to better understand exactly what a pooled desktop is, and how it functions under the hood.

What is a pooled desktop?

The idea behind pooled desktops is that you can create a golden image, and use that to deploy many identical virtual desktops. If you are using rollback (most people will, I'd imagine), then every time your user logs off from the desktop, the virtual desktop will be reset back to the state of the golden image. This allows you to provide a consistent desktop experience to your end users and is perfect for training classrooms or task workers, for example.

Pooled VDI collections use a key technology to enable rollback - a differencing disk. When you add additional virtual desktops to a pooled VDI collection, a small disk is created for each desktop - this allows each desktop to be somewhat unique and a separate entity. RDS then instructs Hyper-V to create a differencing disk. When a user logs off from the desktop, the differencing is deleted and the desktop reverts back to it's original state. You can see the disk (*.VHDX) and the differencing disk (*.AVHDX) when browsing the folder structure of the pooled desktops, as shown below.

Looking at the disks for a pooled virtual desktop
Looking at the disks for a pooled virtual desktop

The VDI is reverting, but not actually rebooting...

The reason computer startup scripts don't work as expected for pooled VDI when rollback is enabled is because of the fundamental technologies in use. As a user logs off of the pooled VDI, the checkpoint is restored, bringing the VDI back to it's original state. So the VDI isn't actually rebooting, it jumps back in time - right back to the Ctrl + Alt + Del screen - and the computer startup script never processes.

An alternative to computer startup scripts

You can use Group Policy to set a logon script, and that should function as expected. But one of the key differences between a computer startup script and a logon script is the context under which it runs. Startup scripts run as SYSTEM, while logon scripts run as the user. Due to security permissions, you may have a requirement to execute the script with SYSTEM context.

You can simulate a computer startup script for pooled VDI by using a combination of Group Policy and Scheduled Tasks. Use Group Policy Preferences to create a Scheduled Task that is set to run at logon. However, set it to run as SYSTEM context.
Create a new Scheduled Task using Group Policy Preferences
Create a new Scheduled Task using Group Policy Preferences

Run the Scheduled Task under the SYSTEM context
Run the Scheduled Task under the SYSTEM context
 You'll want to set the trigger for the Scheduled Task to be on user logon. Since the desktops never actually reboot, you can't set a trigger of "At startup", as this never happens except the very first time you power on the virtual desktop.

Trigger the task at log on of any user
Trigger the task at log on of any user
There you have it. This is a quick and dirty way of simulating a Computer Startup script for RDS pooled virtual desktops. While not ideal, it gets the job done.

Saturday, August 15, 2015

Troubleshooting Internet Explorer Site to Zone Assignment Failures

Hello everyone!

Another week complete, another set of challenges presented, and as always, many new things have been learned. Friday I was presented with a problem I've run across in the past, but was never able to successfully solve. The wonderful Site to Zone Assignment Group Policy setting, and more specifically, this error:

The dreaded zonemapping failure...
The dreaded zonemapping failure...

I've worked for several organizations that centrally managed the list of Internet Explorer Trusted Sites using the Site to Zone Assignment Group Policy setting. And inevitably, something would go wrong, and we'd experience zonemapping failures as manifested by event ID 1085.

Unfortunately the error message that is presented in event viewer is not terribly useful. Why is the zonemapping failing to apply? Point us in the right direction! Searches weren't turning up much either. This is a common GPO setting, and a common problem, yet a solution doesn't appear to be readily available.
Another manifestation of the error
Another manifestation of the error

So how do we troubleshoot this error? What are the possible causes? We need to better understand the rules surrounding Trusted Sites in Internet Explorer.

Friday, July 31, 2015

RDP Client Not Authenticating to RD Gateway & NTLM Settings

Here's a particularly troublesome error you might run across if utilizing RD Gateway to provide external access to your RDS 2012 R2 environment.

The Error

A user cannot connect to RDS applications and/or Virtual Desktops through RD Gateway. While trying to connect, the user receives an error message stating “Your computer can’t connect to the remote computer because an error occurred on the remote computer that you want to connect to. Contact your network administrator for assistance.”

Error message seen by the user
Error message seen by the user

The Symptoms

While looking in the RD Gateway logs (Microsoft-Windows-TerminalServices-Gateway/Operational), you can see incoming connection requests, indicated by event ID’s 312 & 313, but the connection does not authenticate successfully (not seeing an event ID 200 for the user). After the initial connection request, nothing else happens, the connection just seems to disappear.

The Fix

RD Gateway utilizes NTLM to authenticate user connections. NTLMv2 is used by default with Windows Server 2012 R2. It is possible the user has disabled the NTLMv2 authentication protocol on their machine.

In order to check this, on the client machine, open regedit and browse to HKLM\SYSTEM\CurrentControlSet\Control\Lsa and look for a DWORD value called LMCompatibilityLevel. If LMCompatibilityLevel is present, and it is set to anything under a value of 3, the user will fail to authenticate to the RD Gateway server. Instruct the user to either change the value to 3, or delete the DWORD entirely. Then reboot the computer and try again.

The culprit - LMCompatibilityLevel

By default, the LMCompatibilityLevel DWORD does not exist on Windows 7 and above. However, often time companies set LMCompatibilityLevel to only use NTLMv1 through a login script or Group Policy. This was most likely done for compatibility with legacy applications.

If you'd like more information about LMCompatibilityLevel and what the values mean, check out this TechNet article -

Friday, June 5, 2015

Securing RD Gateway with Web Application Proxy - Part 2

Picking up where we left off...

Welcome to Part 2 of my series "Securing RD Gateway with Web Application Proxy." In Part 1 of the series, we had left off after installing AD Federation Services and Web Application Proxy. In addition to the installation, we also performed basic configuration of both products. In Part 2 of the series, we'll start configuring the pieces needed specifically to get RD Web Access and RD Gateway working behind Web Application Proxy.

Creating the Relying Party Trust in ADFS

Now that ADFS and WAP are both installed, the next step is to create a trust relationship between ADFS and RDS. This is accomplished by creating a Relying Party Trust within the ADFS Management console. Switch to the ADFS server, and from Server Manager, click Tools and select AD FS Management. In the ADFS Management console, expand Trust Relationships, right-click on Relying Party Trusts, and select Add Relying Party Trust from the context menu.

***NOTE*** - I originally tried adding a Non-Claims-Aware trust, but this was unsuccessful. After speaking with an engineer from Microsoft, he explained that RDS actually isn't fully claims-aware, but to create a claims-aware trust anyways to get everything working behind Web Application Proxy.
Adding the Relying Party Trust

Saturday, May 30, 2015

Securing RD Gateway with Web Application Proxy - Part 1


So you've spun up an RDS 2012 R2 environment and you are allowing external access via RD Gateway. You've trained your users on how to use RD Web Access to login in order to access their applications and virtual desktops from home. Maybe you've even installed a two-factor authentication product that integrates with RD Web Access to add an additional layer of protection for your environment. Great!

Wait a minute....

Here's what's not always clear. In regards to remote access to your enterprise environment, RD Web Access is really just a front-end for RD Gateway. RD Web Access is completely optional. You can still gain access to your production environment by interacting with RD Gateway directly using mstsc.exe or the Remote Desktop App on an Android or IPhone device. You don't need to use RD Web Access at all.

So what happens when your two-factor authentication software only integrates with RD Web Access, and not RD Gateway directly? Doesn't that mean someone could access your environment remotely without requiring 2FA by using one of the methods listed above?


This could be a huge problem for your company depending on your internal security policies or compliance requirements. So what options do you have if your vendor doesn't do RD Gateway? Switching vendors is not always feasible, depending on your timeline and budget. There must be something else we can do...

Enter Web Application Proxy

Web Application Proxy is a role in Windows Server 2012 and 2012 R2 that replaces some of the functionality found in Microsoft's UAG and TMG products. It acts as a reverse proxy to allow you to securely deliver your internal web applications to external users. As of the August 2014 Update Rollup for Server 2012 R2, Web Application Proxy (here on out referred to as WAP) supports securely publishing RD Gateway, as can be seen in this TechNet blog post. Finally a supported solution to secure RD Gateway without switching to a 2FA vendor that supports direct integration with RD Gateway!

WAP Graphic from TechNet

But how do we setup and configure WAP to host RD Gateway connections? Microsoft is still working on their official documentation. Besides the aforementioned blog post, there is only a single article I could find on TechNet detailing how to configure WAP for RD Gateway - and the details are very sparse.

This blog post will serve as one of the first resources for installing and configuring the necessary infrastructure components required to host RD Gateway connections behind WAP. Please be warned that these posts will be long and screenshot-heavy.

Tuesday, May 26, 2015

An authentication error has occurred (Code: 0x607)

Authentication error 0x607 when launching a RemoteApp
Authentication error 0x607 when launching a RemoteApp
If a user receives error message 0x607 - An authentication error has occurred when attempting to launch a published RemoteApp, check the logs on the client PC.

This is likely due to the client PC not trusting your certificate. Either procure a certificate from a trusted third-party certificate authority, or the user will need to install and trust the root certificate authority and any intermediate certificate authorities in the certificate chain.


A secondary cause has been found for this error message. If the user is unable to contact the certificate revocation list that is listed on the certificate to verify the revocation status of the certificate, they will receive the 0x607 error. So for example, if the URL of your certificate vendor is being blocked by a corporate web filter, you will have receive this error when launching a RemoteApp.

Friday, April 24, 2015

Bachelor's Degree Complete!

I woke up to a terrific email email this morning:

From: WGU Records Office
Subject: Graduation Application for Thomas Murphy
Dear Thomas,

Congratulations! Your mentor has recommended you for graduation. To apply and be considered for graduation, you must complete the online Graduation Application.
We cannot process your graduation until this application has been completed, so please complete your application as soon as possible.
To access the Graduation Application please click here.
If you have any trouble accessing the Graduation Application, please contact the Records Office at


Records Office Staff

I am finally done with my degree program! I started this journey in in early 2014, after being turned down for a job interview with a great company because of my lack of four-year degree. I began my first term with Western Governor's University on April 1, 2014. And now, just over a year later, I've completed the program! It has been challenging at times to keep focused and complete the work, but as I moved closer to the end, it became easier to focus and concentrate on the goal ahead.

Now it's time for a short break. My wife is also finishing up her bachelor's degree. It wasn't easy having both us studying, working full time (with a new job for me) and raising two kids, but we are almost there!


My degree is here! Woohoo!
My degree is here! Woohoo!

Update Rollup 6 for VMM 2012 R2 - April 28

Update Rollup 6 for System Center Virtual Machine Manager 2012 R2 is scheduled to be released on Tuesday, April 28. Check out this video posted on the official VMM blog about some of the new features coming in UR6.

Tuesday, April 21, 2015

PowerShell Summit 2015 North America - YouTube Videos Released

Starting earlier this week, PowerShell enthusiasts, MVP's and product team members converged in North Carolina for the North American PowerShell Summit 2015 organized by the folks at Now that the Summit is complete, they have released videos from all the presentations directly to the YouTube channel.

Check out the videos at - looks like there is plenty of great presentations and content to consume!

Thursday, April 16, 2015

Connect to the Administrative Session of a Machine Through RDWeb (mstsc.exe /admin for RDWeb!)

As a follow up to my previous post Add Multi Monitor Support to RDWeb, today I'll be showing you how to add an option to RDWeb to allow users to connect to the administrative session on a machine, or in other words, to connect to the console session. This is the equivalent of using mstsc.exe /admin but will instead function when using the "Connect to a remote PC" link in RDWeb.

Why would we need this ability? Sometimes you just need to connect directly to the console of a machine. For our environment, we needed the ability to remote directly into an RDS Session Host server. If you try to RDP into a Session Host server that is a part of a collection, there is a possibility of being redirected to a different server in the collection. The RDP client will typically throw an error message, as the server you are being redirected to was not the server you requested. By forcing the connection to the administrative session, the RDP client will bypass the redirection and connect you to the server you specified.

As with the previous article, we'll add the option to connect to the administrative session of a computer to the Options section of the Desktops.aspx page, as shown below.

Add option to connect to the administrative session of a machine
Add option to connect to the administrative session of a machine

Tuesday, March 10, 2015

Add Multi Monitor Support to RDWeb

When a user connects to RDWeb and uses the "Connect to a remote PC" link, the resultant RDP session only uses a single monitor. Many of my users have expressed the desire to use both of their monitors when working from home. Out of the box, there is not a way to use multiple monitors on the RDP session. This post will show you how to modify the RDWeb files to add support for multiple monitors.

We'll add the option to enable multi-monitor support to the Options section of the Desktops.aspx page, as shown below.

After adding multiple monitor support to RDWeb
After adding multiple monitor support to RDWeb

Saturday, February 21, 2015

Passed Project+ Certification Exam

Another class done towards my bachelor's degree, another certification attained. The Project+ exam was relatively straightforward. The training material provided by my university was much more difficult than the actual exam, which I suppose was a good thing - it prepared me well for the test. It also helped that I am engaged in projects at work, and utilize project management methodologies every day.

I now move onto my final two courses - Technical Writing and then my capstone project. The end is near!

Monday, February 16, 2015

Reuse AD machine accounts for RDS VDI

Just a quick tip. When you recreate pooled VDI in RDS, such as when updating the golden image, RDS will actually delete the Hyper-V VM and create a new one, as well as delete the AD machine account, and create a new one. This can pose a problem if you place your VDI machine accounts as members of AD security groups - that group membership will be lost when the VDI is updated.

In order to prevent this behavior, you can use the Enable-RDVirtualDesktopADMachineAccountReuse PowerShell cmdlet. This cmdlet prevents the RD connection broker from creating a new AD machine account, instead opting to reuse the existing machine account. This way, any existing group memberships will still be present after the VDI has recomposed.

Thursday, February 12, 2015

Upgrade RDS 2012 to 2012 R2

Recently I was tasked with upgrading an RDS 2012 environment to RDS 2012 R2. We had been having issues with the connection brokers and the Virtualization Host Agent Service on several VDI hosts. After consulting with several Microsoft Solution Architects and our TAM, the decision was made to upgrade the connection brokers and VDI hosts to 2012 R2 in order to address some of the issues we were experiencing.

In researching the upgrade path from RDS 2012 to 2012 R2, I discovered that Microsoft had published a series of TechNet articles describing the steps required to perform an upgrade to a live environment. Those articles can be found here -

Reading through these articles, I found the descriptions of several of the steps to be quite vague. Certain steps had little detail, and I was having trouble following the upgrade procedure. I also performed several searches and couldn't find any solid articles or blog postings detailing how to perform an in-place upgrade. There were several guides available on how to setup an RDS 2012 R2 environment from scratch, but not much in the way of performing an upgrade to an existing RDS 2012 environment.

After some trial and error, I was able to successfully upgrade the connection broker servers from 2012 to 2012 R2, with minimal downtime to the RDS environment. I wanted to share my upgrade experience in more detail than what is contained solely in the TechNet articles.

Saturday, January 31, 2015

Install-RDPCert - Remotely install RDP certificate

I have uploaded my first submission to the TechNet Script Gallery!

I'm in the middle of deploying a large RDS 2012 farm - we're currently sitting at around 80+ Session Host servers. One of the things we noticed was that when connecting to the RDS farm from external computers via RD Gateway, you receive a certificate warning because the Session Host servers utilize self-signed certificates. We wanted to eliminate these certificate warnings by purchasing a wildcard certificate and install on all of the Session Host servers. But how to go about deploying it?

Ryan Mangan, RDS MVP, had written a PowerShell script to replace the self-signed certificate with a certificate from a trusted third-party certificate authority. The problem with his script was that the script only worked on the local machine. So in my scenario, I would have to copy the script and certificate to 80+ individual servers, and run the script 80+ times. No way I'm doing that.

Instead of that, I used his script as inspiration and wrote my own version that allows you to install the the certificate remotely against multiple computers simultaneously. This allows you to install your wildcard certificate across your entire RDS farm with a single command!

Check out the script on the TechNet Script Gallery -

As always, I'm always looking for feedback, so if you have any questions or comments about the script, don't hesitate to ask!

Monday, January 12, 2015

RDS 2012 Pooled VDI Machine Account Password Change

Coming into work late last week, I was greeted by a nice surprise: about a dozen pooled VDI had fallen out of the domain and users were receiving trust relationship errors when trying to log in. How about spending half your morning removing and rejoining VDI to the domain?

Every computer account in Active Directory has a password, the same as user accounts have passwords. Typically these machine account passwords are handled automatically in the background, as a function of the domain and the client operating system. However in the case of pooled VDI, which are clones built from a master template, the RD connection brokers handle updating the machine account password for pooled VDI.

By default, the RD connection broker will update the pooled VDI's machine account password every 31 days. This value is not customizable when creating VDI's pools through Server Manager. But you can change the value with PowerShell. In order to create a new pooled VDI collection, you use the New-RDVirtualDesktopCollection cmdlet and the VirtualDesktopPasswordAge parameter. See below for an example:
New-RDVirtualDesktopCollection -CollectionName "VDIPool" -PooledManaged -VirtualDesktopTemplateName "VDITemplate" -VirtualDesktopTemplateHostServer "" -VirtualDesktopAllocation @{""=1} -StorageType LocalStorage -UserGroups "contoso\domain users" -ConnectionBroker "" -VirtualDesktopNamePrefix "PVM" -VirtualDesktopPasswordAge 31
It's worth mentioning that 31 days is the default value for the VirtualDesktopPasswordAge parameter, and it's also the minimum value you can set. If you try to set a value lower than 31, PowerShell will throw a validation error.

Validation error on New-RDVirtualDesktopCollection cmdlet

This was a problem for us because our IT Security team had setup Group Policy to set the maximum machine account password age to be 30 days. So our VDI were hitting this limit, and the trust relationship between the VDI and domain were breaking a mere day before the RD connection brokers would have updated the password. I tried creating a test pool with a lower password age, such as 7 days, when I discovered the 31 day minimum.

Maximum machine account password age GPO setting

I hope this helps other to be careful when changing the default maximum machine password age in your domain. If can easily cause problems if you set the value too low, especially in RDS VDI where the value cannot be lowered.

Friday, January 2, 2015

KB3000850 breaks access to RDS on Windows 8.1

Just wanted to post a heads up for an issue I came across this week. If you use Windows 8.1 to connect to an RDS 2008 R2/2012/2012 R2 environment, you'll want to stay clear of KB3000850 as it breaks access to your RDS environment. We experienced the following behavior:

  1. When launching a RemoteApp, we receive an additional credentials prompt asking us to authenticate to our RD Connection Broker address, almost like the single sign-on certificate is not working properly.
  2. As the RemoteApp begins launching, it appears to hang. If you click the details drop-down, it will show nothing but a black screen. Approximately two minutes later, the RemoteApp will close.
Uninstalling KB3000850 resolved the issues I was having trying to launch RemoteApps. I also found a thread on the TechNet forums with others experiencing the same issue -