Remote Desktop Services 2016 – Part 11 – Virtual Desktop Infrastructure (VDI)

This is the last piece of  the puzzle in our RDS series.  In this part we will discuss why or when to implement this insted of RDS Session Host environment. VDI stands for Virtual Desktop Infrastructure and it is built around the Windows Client OS while RDS is built around the Windows Server OS. When you configure VDI you are creating a pool of VMs and each user will get it’s own VM. This flexibility provides an isolated environment for the user. As each user enjoys a dedicated VM with an OS, they can install or uninstall applications with full or partial administration rights within the VM. When you configure RDS Session Host, all users will share that server and non of them will be able to make changes, install applications, make it personal. All of that is possible with VDI, specially if you have users that need to run heavy applications.

Some of the questions that we need to answer before deploying VDI are:

• Storage
• Servers
• Network
• What type of desktops we want to deploy?

 

1. Storage – Storage is a KEY item and usually what KILLS VDI. It is the biggest performance bottleneck in a virtual infrastructure. So this needs to be planned carefully especially if you will run persistent VDI.

Local vs Shared Storage

Big question. Do I run it on a local storage or do I run it on some form of shared storage?

Local -> If you’re using local storage, there are two scenarios you want to target, a pooled VDI and RD session host. RD session host is a single server. You can back it up. You can restore it. You can have farms of it. If it’s pooled VDI, the desktops are funds mentally replaceable. Because when the user logs off it reverts. So you can destroy and recreate desktops without having a real significant impact so having local direct attach storage is a viable option for that.

Shared -> Personal VDI, user profile disks, pooled VDI templates. All of these include clustering, CSV or SMB attached storage.

1. Servers – On how many hosts will you run these VMs on? A single one? What if it dies? Everything dies as well. When we are configuring VDIs a Hyper-V cluster is preferred.
2. Network – Another important piece in our deployment. Latency, redundancy, scalability are just some of the parts we need to plan before pulling the trigger on a VDI rollout.
3. Desktop Types – here we need to decide if we are going to implement Persistent-VDI or Non-Persistent VDI.

Persistent VDI – It is a 1:1 mapping which means that if you have 50 users you MUST have 50 VMs running. Every user get it’s own VDI. Each desktop runs from a separate disk image. The user’s settings are saved and appear each time at login. These types of desktops allow more personalization, each desktop may be as unique as you want, but they require more storage and backup. Persistent VDI is basically the same setup we have with our physical laptops. Persistent VDI is popular in static scenarios where individual end users are always the same and use the same workstations. They are coordinated with WSUS and Config manager to avoid patch storms through excessive disk I/O.

Non-Persistent VDI – In this deployment none of the users settings or data is saved once they log out. At the end of a session, the desktop reverts back to its original state and the user receives a fresh image the next time he/she logs in. With this deployment if you know you usually get only 20 users connected at any given time you can have a pool of 20 VMs instead of 50. This means less servers, less storage and so on.

When you are deploying non-persistent VDI’s you are creating a “Master Image” or a “Golden Image”. Since nonpersistent desktops are built from a master image, it’s easier for administrators to patch and update the image, back it up quickly and deploy company-wide applications to all end users. Users can’t alter desktop settings or install their own applications. Requirements are reduced because we have only one image to manage and we have support for user profile disks to persist user changes. When it comes to updating the golden image, if there’s an update that comes in, update the gold, reconstruct, update the gold, reconstruct. You do this as often as you want, and the tools within Windows make this completely transparent to the user because Server Manager
will allow you to roll these things out as people use them.

TIPS! I would recommend that (before you configure VDI deployment) you make sure that you focus on user profiles (you may not necessarily be on this same Windows install over and over again) and follow that by applications and then you can start talking about, okay, we’re going to give you a user session and a desktop, do I do that in a session desktop, do I do that in a personal VDI or a pooled VDI. Those are the first things you need to solve before you configure virtualization layer, storage etc.

Let’s see how we can deploy VDI’s. In a production environment, you will need to have a physical Hyper-V host (Cluster is preferred) that will host RD Virtualization Host role. My Hyper-V host is a VM (with nested virtualization enabled). No need for physical server because this is just a demo. All servers are domain joined.

Infrastructure

DC01 – Domain Controller

RDS-VDI – Connection Broker, Web Access

HV01-VDI – Hyper-V host (RD Virtualization Host) – 20 GB RAM, 10 vCPU

I already created new organizational unit called VDI. This will be the default OU which will host our VDI’s. Next, I have configured DHCP so that VDI’s get correct network settings. Make sure that you have this before you proceed.

Be sure to add all servers that will be part of the deployment to all servers in server manager on connection broker. Lets, start our deployment by starting server manager and clicking on Manage –> Add Roles and Features -> Remote Desktop Services Installation

Select Standard Deployment –> Next

On the Deployment Scenario select Virtual machine-based desktop deployment

Specify Connection Broker, Web Access and RD Virtualization Host servers. When you select RD Virtualization Host you will have the option to create a new virtual switch. Check this if you want to allow the wizard to create a new virtual switch within Hyper-V to be used for our virtual desktops.

And on the confirmation page tick Restart the destination server automatically if required and click on Deploy

First part is done.

Before we proceed and create a golden template and collection let’s jump into server manager and edit our RDS deployment.

You will notice 2 new sections. Active Directory and Export Location. On the Active Directory section we are configuring permissions so that our connection broker can join VDI’s do a domain. Broker will require full control. As I posted before I already created new OU called VDI. When you select your OU you will receive an error.

To fix this you can hit apply. In some cases if you are not using account that has the permissions to configure this you will need to click on generate script and run the script with account that has the permissions. If you use account that has required permissions, when you click on Apply, you will see the message like this.

Next we have Export Location. The export location is a global setting that applies to all collections in the deployment. When you create a managed collection (a collection that is based off of a gold image is a managed collection) , we have to export the gold image to this location and store it using the collection name. This is where your gold image will live for the lifetime of the collection, and it is not updated until you either re-create all desktops or delete that collection and create a new one, where we will export the gold image again (a gold image can only be used for one collection). Once done click OK

Our next step is to create a golden template. I will use Windows 10 Enterprise iso file and create a template with some applications on it. Now when you are done create a checkpoint before running sysprep. Doing this will give you option to revert to point before sysprep.

Once done run sysprep with command

%WINDIR%\system32\sysprep\sysprep.exe /generalize /shutdown /oobe

Now we are ready to create a collection.

On the Before you begin page click Next. On the Collection Name page specify the collection name and click next

On the Collection Type page choose what would you like to create. We already discussed about these options and if you feel unsecure about it please go back to the beginning of this post. I will keep the defaults and click next. (You will notice green checkmark which represent capabilities of the collection. If you click on Personal, those will change)

Now we need to select our Template. I have only one. Click next

On the Virtual Desktop Settings page keep the defaults and click next

Now we need to specify Time Zone, domain and the OU that we would like to use. Once done click next

On the Specify users and groups page you can specify which group will have access to VDIs, how many we would like to create and what prefix we would like to use.

I created a group called VDI_Users and I am going to create 2 VDI’s. Next for naming scheme I chose to use WIN10-1 for the first one.

On virtual desktop allocation page we can specify how many VDI’s will be created on specific host. I have only one Hyper-V host so there is not much to choose but if you have more then 1 you can select how many VDI’s are going to be created on each host

On this page we are deciding where are we going to store VDI’s. In my case that will be on a D: drive on the Hyper-v host. You will notice a checkbox Automatically roll back the virtual desktop when user logs off. We are creating a Pooled VDI collection so this is a good option. Keep it as is and click next

Now on this page I will uncheck User Profile Disks because I don’t care about user settings in my demo. Remember that if you want to save user settings in a pooled VDI collection you will need to have this.

On the Confirmation Page click Create

After a couple of minutes our collection is deployed with our VMs.

If we login to our DC we will see that VDI OU is populated with these 2 VMs and we can see those VMs in Hyper-V manager as well.

and we can see it in RD Web Access

Let’s explore the collection properties. Click on the collection and under Tasks click on Edit Properties.

General Section, Here we can change the Collection Name, we can decide if this collection will appear in Web access and we can enable save delay in minutes.

Enable save delay (in minutes): If you enable this option, when the user logoff the machine will rollback and after x min it will go into the save state.

Virtual Desktops Section, This will give us information about our configuration

User Groups section, here you edit who will be able to access collection.

Client Section, Here we can configure/change settings for clients and decide if they will be able to access drives, clipboard etc.

User Profile Disks –> UPD’s can be configured here

On the Collection main page we have option to configure Remote Apps

and if you scroll down you will see Virtual Desktop Template section. This will tell us which golden image we are using and some additional info. We will discuss more about this when we will be talking about golden image update and re-creation of VDI’s.

Last but not least is the Virtual Desktops section. Here we can see our VDI’s, who is logged on and the connection status. We can see that a user called N is logged on WIN10-2 and that connection is Active. If you click on tasks you will be able to add more desktops, recreate all desktops (later on this one) etc..

If you right click on a VDI you will be able to do things like save and delete.

 

UPDATE GOLDEN IMAGE AND RECREATE ALL DESKTOPS

What if we need to add new applications to our VDI’s in pooled collection? What if we need to change something or what if we need to update our golden template? These are the steps that we need to go through when updating/modifying our golden template.

If you remember I created a checkpoint before running sysprep. I did that to revert back to a normal state before I ran sysprep. So our first step is to revert back to normal state.

If you get a warning message Are you sure you want to apply the selected checkpoint hit YES. Once done start the template VM and install apps, update it or make changes to it. I will install some apps on it and then we need to run sysprep again. Before running sysprep I will create a new checkpoint. When new updates are available I will revert to this point and update the image.

Once done run sysprep with shutdown, oobe and generalize options.

%WINDIR%\system32\sysprep\sysprep.exe /generalize /shutdown /oobe

Our VM is sysprepped and ready to be deployed. Login to Connection Broker and start the server manager. Click on RDMS and click on the collection. Under the Virtual Desktop section click on TASKS and Recreate All Virtual Desktops.

First step is to select the template. Once done, click next

User Logoff Policy section, here we have 2 options. The first option

• When the user logs off from the virtual dsktop: this will re-create all desktops with no user. If there are users that are logged on the re-creation will begin when they log off. We have time frame as well that we can use to force re-creation of the desktops regardless if the user is logged in or not. If there are any users logged in between the dates we choose they will be logged off and re-creation will start.

Second option

Based on a schedule: 

• Recreate virtual desktops now and log off all users -> this will force recreation immediatelly regardless of user activity.
• Recreate virtual desktops now and log off users at a specified time –> here we can choose specific time to start with the re-creation.

I will choose Recreate virtual desktops now and log off all users, once done click next and click CREATE.

Process of exporting the template will begin. Once done all desktops will be re-created. During this period all VMs will be deleted and then recreated.

If we connect to our Hyper-V host we can see the process. I am connected to one of my VM’s as well.

Re-creation will first delete the VM and then re-create it.

Now if I try to connect again we will see that the VM is going through the sysprep process.

Once done the VM’s will first be in a saved state and then they will boot up and users will be able to connect to them.

That’s it. I hope this has been informative for you.

Stay Tuned!

Cheers,

Nedim