Create a Unified Outgoing VDI Gateway with Windows Server 2008 R2 and ObserveIT

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:

• Ease of administration and lower costs for managing multiple access methods
• Full audit visibility of all actions performed on your clients’ servers during any remote support session

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:
Drawbacks

• Remote Desktop Gateway VDI is far more complex to set up and manage. In order to set up such a solution you will need to extend your existing Terminal Services infrastructure to a product that supports VDI, and to invest in virtualization hosts that can carry the load of all the concurrent Virtual Desktops.
• Remote Desktop Gateway VDI requires more hardware resources. This means that unlike regular Terminal Services where one or more physical server are used to host all the user sessions, you need to finely tune your hardware to host many concurrent Virtual Desktop machines, which, in most cases, require a lot more resources.
• Remote Desktop Gateway VDI is often more expensive as you are required to add licenses and hardware for the extra components.
• Remote desktop performance might be limited in comparison with regular Terminal Services. This is because when using the remote control tools built into virtualization products to connect to the VDI desktops, the remote connection protocol used y these tools is far less tuned for user experience. Sound (in and out), file copying operations and even printer redirection is limited or non-present, while RDP and ICA connections used with regular Terminal Services allow this and are better tuned for slow connection speeds.

Benefits

• Remote Desktop Gateway VDI allows customization of working environment, which includes the users’ profiles, desktop, installed applications and environment settings. This means that each user receives an entire personal operating system, and not just a “slice” of the Terminal Server’s operating system, allowing customization of many more settings that are available with the regular Terminal Server restrictions. In addition, users can choose to shut down or reboot their own VDI machines, something that cannot be done with regular Terminal Server.
• Remote Desktop Gateway VDI allows isolation of the user environment, and the user session can be configured not to be a part of the providers network. In such a solution, the VDI desktop can be configured not to connect to the same network as the users is located on, and to be totally dedicated and/or isolated to the client’s network. To connect to the VDI machine, the service provider users use a virtualization remote control mechanism such as the remote control built into virtualization products.
• Remote Desktop Gateway VDI allows you to install various VPN clients without conflicts. This is most useful when service providers connect to various clients, each with their own set of VPN and remote connection requirements. When installed on one machine, some VPN clients and settings might interfere with each other, causing conflicts and configuration errors.
• Remote Desktop Gateway VDI allows the creation and configuration of different access methods, based on the customers’ requirements. As stated above, this is useful when users need to connect to many clients, each with different settings and configurations.
• Remote Desktop Gateway VDI grants the ability to install custom applications that may cause conflicts if installed on a regular Terminal Server. This allows service providers to give their users the exact tools they need to perform their job when connecting to the client networks.
• Remote Desktop Gateway VDI can be fully configured based upon clients’ NAP/NAQ enforcement policies, and without conflicting with other clients’ requirements. One client can thus require that the vendor use a specific Anti-Virus product, while another client can request a different product and system configuration settings. Each VDI desktop can be customized to the clients’ needs, and these settings can also be pushed to the VDI desktop on demand, based upon the connection type.
• Remote Desktop Gateway VDI allows can be “reset” to a default image after usage, which means that no state is saved, and the computer is always “fresh”. If the user infects the computer with a virus, messes with the system settings, or even causes serious errors to the machine, the moment it is shut down and rebooted, it is reverted and rested to a pre-defined state.

Summary
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.