outgoing vdi gateways

8/3/2019 Outgoing VDI Gateways

http://slidepdf.com/reader/full/outgoing-vdi-gateways 1/5

`

Outgoing VDI Gateways:

Creating a Unified Outgoing Virtual Desktop Infrastructure

with Windows Server 2008 R2 and ObserveIT

Daniel Petri

January

© Copyright 2010 ObserveIT



Whitepaper: Outgoing VDI Architecturewww.observeit-sys.com

Table of Contents Executive Summary .............................................................................................................................. 2

How it Works ........................................................................................................................................ 2

Remote Desktop Gateway VDI vs. “Old School” Terminal Services ........................................ ................ 4

Benefits of the VDI Solution ....................................................................................................... 4

Drawbacks to the VDI Solution................................................................................................... 4

Conclusion ............................................................................................................................................ 5

About ObserveIT................................................................................................................................... 5

Executive Summary

It is very common for enterprises to use a Terminal

Server or Citrix gateway in order to give external

vendors access to internal servers or resources.

However, we are starting to see a growing

adoption of a “mirror-image” of this solution:

Service providers that need to connect to multiple

customer locations (using different protocols,

according to customer requirements) who 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

client servers during remote support sessions

How it Works

In order to fulfill this requirement, service

providers are using an approach that includes a VDI

gateway to initiate remote connections, and

ObserveIT software in order to audit of the session

activities.

In this scenario, service providers use a

combination of Virtual Desktop Infrastructure (VDI)client machines that are stored on one or 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 current state (running, saved, shut

down etc.), and the status of existing anddisconnected 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

(metadata) about what is happening on the screen

at any given moment. The recordings and metadata

are stored in a central SQL Server database, where

they are fully indexed and available for replay. The

extensive textual metadata allows for very detailed

reports of all user sessions, the applications theyused, and the files that were accessed.

Users can connect to the VDI broker either

internally (located on the same LAN), or remotely.

For remote access, users will be required to

establish a secure connection by using either a

regular 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 two ways:

OPTION 1: 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.

Once 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 userinfects a VM with a virus, installs software, deletes

files on the local drive, or any other does any

unapproved action, as soon as they logoff the VM's

hard drive will revert back to what it was before

they logged on.

OPTION 2: 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 runningon the virtualization host(s). Similar to 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 the 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 as 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 withthe 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:

Benefits of the VDI Solution

• Remote Desktop Gateway VDI allows

customization of the 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

provider’s network. In such a solution, the VDIdesktop 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 customer 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 can be “reset”

to a default image after usage, which meansthat 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.




Drawbacks to the VDI Solution

• Remote Desktop Gateway VDI is 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 by thesetools 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.

Conclusion

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.

About ObserveIT

ObserveIT is an innovator and leader in Terminal,

Citrix and Console session recording, with solutions

for Windows, Desktop and Virtual Machine

environments.

ObserveIT software visually records and replays all

user sessions, providing detailed insight into all

activities on the network.

Founded in 2006, ObserveIT has a worldwide

customer base that spans many industry segments,

including financial, insurance, healthcare,

manufacturing, telecommunications, government

and IT services.

outgoing vdi gateways

Documents