It is very common for enterprises to use a Terminal Server/Citrix gateway in order to give access to external vendors to your internal servers/resources.
However, I am starting to see a growing adoption of “mirror-image” solution: Service providers that need to connect to multiple customer locations (using different protocols, according to customer requirements) want to provide a single access point through which all outgoing traffic is routed.
Just as with an incoming gateway solution for enterprises, these service providers have achieved two important benefits with their outgoing gateway architecture:
In order to fulfill this requirement, the service providers are using a different approach that includes a VDI gateway solution to initiate the remote connections, and ObserveIT software in order to provide the full audit of the user session activities. In this scenario, service providers use a combination of Virtual Desktop Infrastructure (VDI) client machines that are stored on one of more virtualization hosts. These computers are stored in a saved or even shut down state, and are woken up when one or more users connect to them. This VDI implementation is combined with a central remote access mechanism that the users connect to. That mechanism serves as a session broker, a central component that “knows” where the VDI clients are stored, their state (running, saved, shut down and so on), and the status of existing and disconnected sessions. When users connect to that broker, they are then redirected to a VDI machine, where they log on and get their working environment.
On the VDI machine, the ObserveIT Agent is installed and records all the user actions that are performed during that session. In addition, ObserveIT captures a lot of extra information about what is happening on the screen at any given moment. The recordings and provided metadata are stored in a central SQL server database, where they are fully indexed and available for replay. Because of the extensive textual metadata that is provided by the ObserveIT Agent, the system allows for very detailed reports of all the user sessions, the applications they’ve used, files that were accessed and so on.
Read more and download a free copy of ObserveIT
Users can connect to the VDI broker either internally (located on the same LAN), or remotely. In that case, users will be required to establish a secure connection by using either a regular-type VPN connection, SSL VPN, or by using other types of secure connections.
The question of what machines do the users connect to can be answered in 2 ways. One option is to create a “pool” of virtual machines, similar to a “rack” of identical PCs that you install and clone. Their configuration is identical except that they each have a unique computer name and IP address. The process of creating such an image is identical to the one you’d use for cloning a physical computer, including the installation of custom applications and programs, running sysprep to prepare the system for cloning, and automating it all with unattended answer files. One deployed, these machines are available on-demand, which means that the users will get the first available Virtual Desktop from the pool (and if no available machine is turned on, a new machine can be turned on demand or resumed from a saved state). One of the nice features of such a configuration is the ability to roll back to their default image state once the user disconnects and closes the session. This means is that if a user infects a VM with a virus, installs software, deletes files on the local drive, etc., as soon as they logoff the VM’s hard drive will revert back to what it was before they logged on.
The other option is to assign a user a single Personal Virtual Desktop, which means if they choose to connect to My Desktop they will connect to a specific VM that you designate. This is similar to having a PC sitting on a rack that you would like a user to use remotely. When the user logs on to the Remote Desktop Web Access site and chooses to connect to My Desktop they will be connected to this specific PC (VM) that is running on the virtualization host(s). Like in the previous option, machines need to be cloned and assigned a unique name and IP address. However, when calculating the overall resource usage for such a solution, it is clear that by using personal desktops you are required to deploy many more machines, because each user must have its own Virtual Desktop. This is unlike using a pool of Virtual Desktops, where you are only required to have as many VMs as you will have concurrent users.
As you can see from the above examples you still need to configure each unique virtual machine, because in effect they are separate computers. For example, you still need to load the operating system on each, install applications, join them to the domain, etc–just like you would do with real PCs. You can use the same techniques for automating this process as you would if you needed to deploy multiple physical machines with the same hardware/software. Windows 7 includes new image deployment techniques that make this type of scenario easier than before.
Remote Desktop Gateway VDI vs. old school Terminal Services
It’s worth noting that there are some substantial differences between Remote Desktop Gateway VDI and “old school” Terminal Services. Some include:
Because of the complexity of this solution, it is most suited for service providers that have customers that demand high security with connection isolation. Using this approach, service providers achieve ease of administration and lower costs for managing multiple access methods, plus full audit visibility of all actions performed on your clients’ servers during any remote support session.