Applies to: Windows Server 2012 and 2012 R2
In previous articles, we looked at the deployment steps of a traditional form of Remote Desktop Services (RDS) for 2012 and 2012 R2. Now let’s take a look at the setup of VDI for a 2012 RDS farm. This will be broken down into three parts. In this first part, we will go through the process of deploying the RD Virtualization Host role to a single Hyper-V server in an existing 2012 RDS farm. Then in the second part, we will go through the process of creating a desktop collection and publishing a Windows 7 pooled VDI desktop. Finally in part three, we will go through the process of maintaining a desktop image for a pooled desktop. This portion will cover the maintenance and updating of the main image in a pooled VDI desktop environment.
Before we begin, we will first need a physical 2012 server with the Hyper-V role installed. In a production environment, a Hyper-V cluster is preferred, however for this example, we will be using a single Hyper-V server for our deployment. This is a single physical domain joined 2012 R2 server running Hyper-V called Lab01. The server must be physical and not a virtual machine. We will add this new RD virtualization host (RDVH) server to our existing RD farm.
To begin, open Server Manager and add the designated RDVH server to be managed.
Once added, go to Manage and select Add Roles and Features.
On the Before you Begin Screen, hit next.
On the select installation type screen, select Remote Desktop Services installation and hit next.
Since we are adding the Virtualization Host to an existing RDS farm which is already being managed with Server Manager in the server pool, it will automatically find the RD connection broker as it will be listed in the drop down. Select standard type and hit next.
For the deployment scenario, select virtual machine-based desktop deployment and hit next.
On the review role services page, hit next.
Since our farm is already configured, on the “Select RD Connection Broker server” and the “Select RD Web Access server” screens, the information is automatically added for you. Click next on both screens.
On the Specify RD Virtualization Host Server screen, let’s add our designated Hyper-V server. In this scenario, we are also going to allow the wizard to create a new virtual switch within Hyper-V to be used for our virtual desktops. This step is not required if a virtual switch was already configured on the Hyper-V server. To do so, check the box which says “Create a new virtual switch on the selected servers” and hit next.
On the confirmation screen, review the settings, then check the box “Restart the destination server automatically if required”. Hit Deploy.
Once it is finished, hit Close to close out of the wizard. If you now look in Hyper-V Manager, you will see a new virtual switch was created and will be used for the virtual desktops.
Now that we have our RD Virtualization Host server deployed, let’s go back into RDMS within Server Manager and edit the deployment properties of our farm.
Within the deployment properties, we now have two new sections. One is called Active Directory and the other Export Location.
Within the Active Directory section, this is where we can specify the default Active Directory Organizational Unit which will house our VDI desktops. In order for this to work, the RD Connection Brokers will require full control on the security of the OU. Ive already pre-created an OU called VDI, and when I select it, it will give me an error stating the permissions are not correct.
Depending on the level of security with the account you are logged in as, you can hit apply for the correct security permissions to be applied to the OU. In some cases, you may be using an account which does not have access to make this change. In these cases, you can click on Generate Script and it will generate a PowerShell script you can copy and send to an admin who has the correct administrative privileges who can run the script to apply to appropriate permissions.
When the correct permissions are made, you will see the following message stating it is configured with the appropriate permissions.
If we look at the security settings for the OU, you can see the correct permissions have been made. It will apply these permissions for each of the RD Connection Brokers in the farm since these will be the servers which will be facilitating the creation and deletion of the virtual desktops.
Finally, let’s look at the Export Location section. Here we can specify the folder where the virtual template, which is used to create the desktops, will be copied to. The default location will be shared on the active RD Connection Broker to a folder called RDVirtualDesktopTemplate. If you already have a folder designated for the virtual template, you can change it here and apply the changes.
Now with our RD Virtualization Host deployed, we are ready to move on and create a new collection to publish our VDI desktops.
© 2014 Eddie Kwasnik “the Wolf” All Rights Reserved
#1 by Derek on September 22, 2014 - 1:09 pm
First off – thank you for all of your helpful information – it has been great!
I have followed your tutorial to get my VDI based RDS deployment up and running however I have an issue. I have setup the RDS farm on internal servers with internal IP addresses (on a .local domain). When I originally setup the farm I did not have a wildcard public SSL certificate in place, so I used a self signed cert. Once I was finished, I went ahead and secured the public wildcard certificate and went into deployment properties and changed it to the new one.
In my scenario, I am trying to provide VDI desktops to remote users without needing them to VPN into my network first, so for example, I just want them to connect to: rds.mycompany.com and be presented with the web access login, at which point they would login and see my virtual desktop collection link and click on it to execute a session.
I am able to access the public URL and login just fine, but when I click on the virtual desktop icon, it throws an error saying that it can’t find “rds.internaldomain.local”. I think I just need to make a configuration change somewhere to tell it to point to the public URL of rds.mycompany.com.
Here is what the error says exactly,
“Remote Desktop can’t find the computer “rds.internaldomain.local”. This might mean that “rds.internaldomain.local” does not belong to the specified network. Verify the computer name and domain that you are trying to connect to.”
Again, I think the problem is that the deployment is referencing my internal server name for the remote client to connect to, and clearly if the client isn’t part of my internal network with the correct DNS entries, it will fail every time.
#2 by Eddie Kwasnik on September 23, 2014 - 8:54 am
Are you using an RD Gateway server for the external users?
#3 by Derek on September 23, 2014 - 12:12 pm
Correct, my main objective is to provide VDI sessions for users outside of our network. I ended up finding a cmdlet which allows you to change the web access URL from whatever you originally set it up as, in my case, rds.internaldomain.local, to a public URL, rds.mycompany.com.
So now I am able to get pretty far but a new problem has surfaced. When I log into the web access from it’s public URL on a host outside of our internal network and click on my virtual desktop collection icon, it begins loading and even says it is preparing the virtual machine, loading the virtual machine, etc, but then it hangs on “initiating remote connection” and then throws an error:
“Remote Desktop can’t connect to the remote computer for one of these reasons:
1) Remote access to the server is not enabled
2) The remote computer is turned off
3) The remote computer is not available on the network
Make sure the remote computer is turned on and connected to the network, and that remote access is enabled.”
I have verified the ports opened in my SonicWall, which are ports 80, 443 and 3389 – all of which are pointed to the broker/gateway/web access server. It is my understanding that you point all of those ports to the broker/gateway/web access server and then it redirects the session to the virtualization server to begin the virtual machine.
It appears that it attempts to do this and gets pretty far, but then fails. If I do the same thing from a computer/client here on the internal network it works just fine and spins up the VDI session flawlessly, even if I access the web access from it’s public URL and not the internal URL of the broker. That is what makes me think there is a port issue with my SonicWall.
I also wondered if there was some sort of timeout limit whereby it takes too long for the VDI to be prepared and the client times out… I have no idea at this point.
#4 by Eddie Kwasnik on September 23, 2014 - 1:26 pm
Can you verify the RD Gateway is configured for use? Typically when a connection failure occurs from a connection through the gateway, the error message will state something regarding the RD Gateway server. So from the errors you are receiving, it almost sounds as if the users are trying to connect directly to the RDSH servers versus going through the gateway. If they are going through the gateway and it still is failing, make sure the gateway server has full connectivity to the farm.
#5 by Derek on September 23, 2014 - 12:57 pm
Update – I just temporarily turned off the firewall functionality of the SonicWall and tried it again from a remote computer outside of this network and it did not help. So it appears that it is something else internally of which I have no idea. The user account I am using is in the specified AD group, is there anything else which might cause a remote computer to have an issue? No belonging to the domain, etc?
#6 by Derek on September 23, 2014 - 2:21 pm
Perhaps you are right. How would I verify that the RD Gateway is being used? I just went into Deployment Properties and under RD Gateway I selected “Do not use an RD Gateway server”. Then I went back to the Web Access from a remote computer and refreshed the page and tried again and it still fails at the exact same spot in the process.
#7 by Eddie Kwasnik on September 23, 2014 - 2:44 pm
You want to make sure it is enabled and then test.
#8 by kelemvor33 on July 6, 2015 - 4:31 pm
Can these machines be VMs themselves or do some of them have to be physical boxes? We generally have everything as VMs other than the actual Hyper-V hosts but I get an error about hardware virtualization something so I’m wondering if the Virtualzation Host has to be a separate physical box.
#9 by Eddie Kwasnik on July 6, 2015 - 4:42 pm
I use all vms aside from the physical Hyper-V hosts. The virtualization role for VDI is installed on the hyper-v host, however it needs to be the gui installation of windows and not the core install.
#10 by kelemvor33 on July 6, 2015 - 4:49 pm
So do you have a separate Hyper-V server/cluster just for these virtual desktops compared to the Hyper-V cluster you have for all your other servers? Our Virtual Desktops would just be used as training machines so they aren’t mission critical and could potentially just run on a stand alone Hyper-V server if needed.
#11 by Eddie Kwasnik on July 6, 2015 - 6:24 pm
A single cluster for your environment is fine.
#12 by kelemvor33 on July 7, 2015 - 11:27 am
We have a 5-node Hyper-V cluster that runs our entire environment. Do I need to install the role on each host individually?
#13 by Eddie Kwasnik on July 7, 2015 - 1:31 pm
For the RD Virtualization Host role? It should only go on the hosts housing the VDI vms. If you are using just RDSH, then you will not require that role.
#14 by kelemvor33 on July 7, 2015 - 2:06 pm
Howdy. Any chance I could shoot you a direct message or email somehow to get your opinion on something? We’re trying to use the various RDS components but we have never used them before and aren’t really sure which pieces we need to do what we’re trying to do. I’d love to be able to type it out and see if you can point us in the right direction. Feel free to email me by removing the numbers from my Username and putting gmail at the end. 🙂
#15 by rafa on November 26, 2015 - 7:43 am
Hello, first of all, thanks for this good tutorial, then, my question is in the case where we use 2 clustered Hyper V (RDVirtualization Host) with CSV Volume, and the other roles (Connection Broker & Web Access) are installed in another server not member of cluster, how can we store the pooled collection in that CSV Volume ?
#16 by al ferrod on February 9, 2017 - 4:43 pm
Eddie, I have a new client that has a virtual environment. We are getting a c:windows\system32\config\systemprofile\desktop is unavailable when some users try to log in. Also, when I create a new user and when that user tries to log in remotely from outside, we get “the user profile service service failed the sign-in. user profile cannot be loaded.”. Thank you in advance for any help.
#17 by Shoutcast centova dedicated servers on May 14, 2018 - 3:28 pm
Hey! This iis my first comment here so I just wanted to givce a quick shout out and tell you
I really enjoy reading through your posts. Can you recommend any othrr blogs/websites/forums that go
over the same subjects? Thank you so much!
#18 by Mike on December 1, 2018 - 12:33 pm
Have you ever run into an issue when creating a collection and the broker not having permission to add the computer object to the OU? I googled everywhere and applied permissions correctly and it tells me it has the permissions but then fails with the below.
VM Provisioning operation [Create] failed for pool [RA_Windows_7]. Connection Broker could not create the machine account [RA-WIN7-0] in the specified OU [OU=Computers – VDI,DC=mydomain,DC=com], error: [Task: Acquire Offline Domain Join blob: failed, ErrorCode [0x80070002]]
Microsoft is of no help so far and will not call me back