Automation with Citrix and other VDI technologies

The background

Virtual desktop infrastructure (VDI) is a desktop virtualization technology wherein a desktop operating system, typically Microsoft Windows, runs and is managed in a data center.

In VDI setups, the user normally does not know the actual machine their desktop is running, and that machine can change between sessions. It is good to note that this is quite different from Virtual Machine setups where the user is still connecting to the same machine instance every time, so only the hardware level is virtualized here.

Commonly, the VDI systems are accessed via a special application or a website interface, which means that the user never directly interacts with the machine but only gets the Desktop UI canvas, mouse and keyboard functionality.

Citrix is one such technology.

It is also good to note that there is no "one way" of setting up a VDI or Citrix; the setups and mechanisms behind the VDI system can vary greatly.

The limitations

For automating desktop applications, the main level limitation that VDI's introduce is that they force the automation to be image-based. Because the user does not interact directly with the application, they cannot access the element trees, etc. Image-based automation makes the automations over VDI slower, harder to implement, and more brittle, as any change in the UI can break things.

Another technical level limitation can be posed by how the VDI setup handles replicating or syncing the user folders. If a user saves a file, closes the connection, and opens a new one, the VDI system needs to get the file to the new machine to which the session was routed. There are several ways we have seen this setup; this can work nicely, with a significant delay, or be totally blocked. For automation tooling, having some persistent file storage is vital. For the Robocorp tool stack, features like pre-built environments and environment caching would also need to use common folders on the machine to share data between users, and this is quite often totally blocked in VDI setups.

Because there is no actual "machine" in VDI, setting up a Windows Service is another thing that is usually just blocked, so setting up a Windows Worker that spins up only when it is needed is not possible.

Possibilities and recommendations

For unattended automation, the clear recommendation is not to use VDI's but to go the VM route or run in Cloud Workers. Cloud Workers offer much faster scalability and lower costs than VDI solutions. For Self-hosted running, having dedicated VMs provides a much more stable and faster way of executing automations, which is also almost always cheaper than the VDI options. Other benefits are that the other users cannot starve the automation of resources and vice-versa. On a VM, you can also control much more precisely what apps are installed, who has access, and when updates happen; these are all critical points in setting up stable automation runs.

The only way to run unattended automations on VDI would be to get Robocorp Setup Utility -application installed on the VDI and set up a Demo Worker on the wanted users. This requires a persistent user home folder to store the linking data to the Control Room. To start the worker, you need someone to open the user session.

For attended automations, you can get Robocorp Assistant -application installed on the VDI, just like any application. This does require a persistent user home folder to store the linking data to the Control Room.

The general rule we have seen more than once is: 👉 If you are using VDI or Citrix to automate, you are perhaps trying too much to automate the existing human process "exactly like the human does it". In most cases, taking a step back enables you to detach the process from the human process, suddenly enabling a much simpler, faster, and more reliable result. This means automating via APIs or webpages and scoping down the human input to the minimum, unlocking capabilities like parallel running and improved security.