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.

No comments:

Post a Comment