Deploying VDI for RDS 2012 / 2012R2 – Part I

Deploying VDI for RDS 2012 / 2012R2 – Part I

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.

Part I

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.

Deploying VDI for RDS 2012 / 2012R2 – Part II – Publishing a Windows 7 Pooled Desktop

Applies to: Windows Server 2012 and 2012 R2

Part II

Now with our RD Virtualization Host deployed as per Part I of deploying VDI for RDS 2012, we are ready to publish a Windows 7 pooled VDI desktop. This section will cover the deployment of a pooled desktop and the options available when deploying the desktop. The first thing we will need is a Windows 7 virtual machine. I’ve pre-created this machine along with some applications installed on the image. Once you are done installing applications and configuring the Windows 7 image, we will need to prepare the image for deployment. In order to do this, we will need to run sysprep with the following options.

Before running sysprep, it is a good practice to take a snapshot of the soon to be virtual template. This way should any changes need to be made to the image at a later time, you can simply revert back to the checkpoint prior to running sysprep.

Within the Windows 7 virtual machine, launch sysprep located in: %windir%\system32\sysprep\sysprep.exe

You can also run the following command line:

Windows 7: %windir%\system32\sysprep\sysprep.exe /generalize /oobe /shutdown

Windows 8: %windir%\system32\sysprep\sysprep.exe /generalize /oobe /shutdown /mode:vm

Once Sysprep is completed, it will shut down the virtual machine.

Now that we have our virtual template ready, we will first need to create a new Collection for the Windows 7 desktop. Within RDMS in Server Manager on the Deployment Overview section, right-click on RD Virtualization Host and select the option “Create Virtual Desktop Collection”

On the Before you Begin Screen, hit next.

On the Collection Name screen, go ahead and name the collection. Here I named the collection Windows 7 Desktop. Hit next.

On the collection type screen we are presented with 2 options. One is a pooled desktop and the other is a personal desktop. A pooled desktop is a desktop which is based on a shared desktop image. When a user logs out, the desktop is reverted back to its original state. A personal desktop is one which will be assigned to a user and the user will use this desktop going forward. Any changes made to a personal desktop is retained. For our example, we will choose the pooled virtual desktop collection.

The other option is to allow the RDS farm to automatically create and manage the virtual desktops. When this option is selected the RDS farm will create new virtual desktops based on the virtual template, recreate the virtual desktop based on changes made to the virtual desktop template, and store user settings on a user profile disk. If the option is not checked, it will assume all virtual desktops have already been pre-created and only require an assignment. For our example, we will leave the option checked. Hit Next.

Should you decide not to use user profile disks, ensure some mechanism is in place to store user settings because once the user logs out, all changes to the pooled desktop will be removed.

NOTE: If you play around with the options on this screen, the wizard will display the capabilities of the collection by placing a green check mark next to it.

On the specify Virtual Desktop Template screen, select the sys-preped virtual machine and hit next. In our example, the sys-preped virtual machine is called Win7Master. When the virtual machine is selected, the wizard will validate the virtual machine’s status to ensure sysprep has been properly executed. If the virtual machine is not configured properly, you will be presented with an error stating what is wrong with it.

On the specify virtual desktop settings screen, select the option “Provide unattended installation settings” and hit next. Should you have an answer file already prepared, you can browse for it on this screen. Since we do not have an answer file, will provide the installation options within the wizard.

For the unattended installation settings screen, select the appropriate time zone, correct domain, and the designated OU where the virtual machines computer accounts will reside. Hit next.

On the specify users and user groups screen, we can add the user group(s) which will have access to the virtual desktop collection. To keep things simple, I’ve added domain users. Here we also need to specify how many desktops we want created along with the naming scheme for the desktops. For this example, I’ve set it to create 2 virtual desktops. As for the naming scheme, I’ve set the prefix to Win7- and the suffix to start with the number 1. This means the desktops will be named Win7-1 and Win7-2. Hit next.

For the Virtual Desktop Allocation screen, here we can specify which hosts we want the virtual machines to reside on. In this example, I only have one virtualization host so there is not much I can change, however if there were multiple virtualization hosts, you can specify how many machines you want created on each host. So if we were creating 100 desktops across 4 RD Virtualization Hosts, we can even out the distribution by putting 25 virtual desktops on each virtualization host. Hit next.

For the Virtual Desktop Storage screen, we can specify the type of storage as well the path where the virtual desktops will be stored. In a production environment, a cluster shared volume will be the best option. Since I am using a single Hyper-V host, I will select the directory where I want the virtual desktops to be stored. I set it to store my machines in the directory D:\VMs. At the bottom of the screen there is a roll back option. Since this is a pooled desktop, we want the virtual desktop to roll back to its previous state when a user logs off. Check this box and hit next.

NOTE: If I had multiple RD Virtualization Hosts which were not part of a cluster, the virtual desktops would be stored in the same directory structure on each individual hosts. However, these virtual desktops when created will be assigned to an individual host since the storage is not shared amongst all hosts. When using multiple hosts, a cluster shared volume is preferred.

Since we are not using a third party solution to handle user settings, let’s go ahead and enable user profile disks. Specify the correct directory for the profile disks and hit next. Should you use a third party solution to handle user settings (user profiles), deselect the option “Enable user profile disks”. More information on configuring profile disks can be found here.

On the confirmation screen, confirm the settings and hit Create.

Once completed, hit close.

Now that we have our Virtual Desktop Collection created, let’s look at the environment and see what actually happened.

Virtual Desktop Export Location

In Part I, after we deployed out RD Virtualization host, we specified the virtual desktop export location within the RD farm deployment properties. This is where the virtual desktop template is copied. If we browse to the location, we can see the virtual desktop template and its associated files:

New Virtual Machines

If we look at our Hyper-V host, we can see the two new virtual machines (desktops) the wizard created.

If we browse to the folder location on the Hyper-V host (RD Virtualization Host) where we specified the virtual desktop storage, we see a new folder which matches the name of our Virtual Desktop Collection. Underneath this folder is where the actual virtual machines will reside.

  

And if we look in our designated Active Directory OU, we see the two new machine accounts created.

Server Manager – RDMS

Within RDMS in Server Manager, we see our new collection. If we select the collection, most of the sections on the screen look the same as the ones previously shown for the traditional RDS collection, but there are a few differences.

In the properties section, we can see and edit the properties of the collection. Here we have the ability to rename the collection, hide the collection for the RD Web Access server, view the virtual desktop configuration, modify the user groups which have access to the collection, set the client settings, and modify the user profile disks. Here are the screen shots for each of collection properties.

    

For the RemoteApp Programs section, we can unpublish the virtual desktop and instead publish individual RemoteApp programs which are installed on the virtual desktops. This option could be used for applications which are not compatible to run on a server OS and require a client operating system like Windows 7.

In the Virtual Desktops section we can do many things. We can view who is connected to the virtual desktops, view the state of the virtual desktops, start or stop the desktops, and even delete the desktops. Here we can also recreate the virtual desktops in the event a change is made to the master virtual template. This will be covered in the part III of our VDI deployment.

 

Finally, we have the virtual desktop template section. Here we can see the virtual desktop template which is being used as well can recreate the virtual desktops should we make a change to the virtual desktop template.

And if we log into RD Web Access, we will see our new Windows 7 Virtual Pooled Desktop.

Deploying VDI for RDS 2012 / 2012R2 – Part III – Updating a Pooled Desktop Image

Applies to: Windows Server 2012 and 2012 R2

Part III

In part II we saw how to deploy and publish a Windows 7 pooled virtual desktop. Now let’s take a look at the steps needed in making a change or update to our image and making it available to users. To recap our environment, we have a Windows 7 pooled desktop collection available to our users. This was created from our master virtual machine called Win7master. Part of the process needed when we created our collection was to run sysprep on our master image. As a good practice measure, I created a checkpoint of the virtual machine prior to running sysprep. This was done so I can easily revert the virtual machine back to a normal state prior to when I ran sys-prep.

Within the Hyper-V console, revert to the correct checkpoint.

Start the virtual machine.

Once the virtual machine is started, you can login and make your change(s) to the image. For this example, I am updating the Microsoft Office application to the latest version. Once I have completed the update of Microsoft Office and made all of my changes, we will need to run Sysprep again. Prior to running sysprep, let’s create a new checkpoint for the virtual machine so we have a checkpoint to come back to when we are ready to make our next update to the image.

It is also a good practice to rename the checkpoint to a name which references the update made.

Once the checkpoint is created and renamed, we can run sysprep. Within the Windows 7 virtual machine, launch sysprep located in: %windir%\system32\sysprep\sysprep.exe

You can also run the following command line:

Windows 7: %windir%\system32\sysprep\sysprep.exe /generalize /oobe /shutdown

Windows 8: %windir%\system32\sysprep\sysprep.exe /generalize /oobe /shutdown /mode:vm

Once Sysprep is completed, it will shut down the virtual machine.

Now that our virtual machine is sys-prepped and ready, let’s go back to RDMS within Server Manager. Within RDMS, click on our Virtual Desktop Collection.

Under the Virtual Desktop section on the right, click on tasks and select the option “Recreate All Virtual Desktops”.

Once the Wizard initializes, we can select our virtual desktop template. Highlight the master virtual machine and hit next. (Win7Master)

On the User Logoff Policy screen, we are presented with a few options. These options will allow us to schedule the re-creation of our virtual desktops. The first option will begin recreating any desktops which have no users currently connected. However, any users who are connected, the re-creation will not occur until they logoff. If the user doesn’t logoff, we can set a time frame which will force the re-creation of the desktop regardless if the user is logged in. So based on the following schedule, if the user is logged in between the dates listed, they will be automatically logged off and the desktop will be recreated using the latest update to our master virtual image.

The other option will allow us to force a specific time to recreate all the desktops regardless if a user is logged in or not. You can set it to perform the re-creation right away, or pick a specific time to start the re-creation. This is good in the event users were logged in. You would have to ability to schedule the re-creation during non-business hours so users are not disrupted. Since I currently do not have any users logged in, we will schedule the re-creation to occur now. Select “Recreate virtual desktops now and log off all users” and hit next.

On the confirmation screen, confirm the options selected and hit Create.

During the creation process, the process of exporting the virtual desktop template will begin. Once this is completed, the virtual desktops will be recreated based off the virtual desktop template.

After the virtual desktop template is exported, the option of closing the wizard is available. You can close out of the wizard and let the process run in the background. If you wish to come back and view the progress of the desktop re-creation, you can go back to the virtual desktop collection within RDMS and under the virtual desktop section, click on tasks and select “Task Status Details”.

During the re-creation of the virtual desktops, the actual virtual machines will be deleted and recreated from the RD Virtualization Host. After they are recreated, the machines will boot up and go through the sysprep process. This will use the settings configured for sysprep which were done during the creation of the virtual desktop collection. You can witness this process as it is happens. Here I am connected to the console of one of the virtual desktops Win7-2. Since I am connected to the console of the virtual desktop, when the virtual machine is deleted, Hyper-V will send a pop-up stating the machine was deleted.

After a few seconds, the machine will reappear back in the Hyper-V console. Within the Hyper-V console, reconnect to the newly recreated virtual machine.

Here we can see the virtual desktop is going through the sys-prep process.

Once the virtual desktops are finished with the re-creation process, users will be able to connect to the updated virtual desktops.

Here is a quick rundown of the re-creation process:

1. Make the necessary changes and updates to the master desktop image.
2. Create a new checkpoint once all changes and updates are made.
3. Run sysprep on the master virtual image with the following options:

Windows 7: %windir%\system32\sysprep\sysprep.exe /generalize /oobe /shutdown

Windows 8: %windir%\system32\sysprep\sysprep.exe /generalize /oobe /shutdown /mode:vm

4. Once sysprep is completed, go to RDMS and within the Virtual Desktop collection select the action to recreate all desktops.
5. Choose the virtual desktop template
6. Schedule the desktop re-creation
7. Recreate the virtual desktops