Guru Tips

 

05/28/2010 Multiple vDesk Administration Servers
04/28/2010 Distributed Storage
02/25/2010 Security Best Practices
01/27/2010 Single Sign In
12/15/2009 Workspace Encryption
 

Multiple vDesk Administration Servers 05/28/2010

vDesk enables enterprises to create a hierarchical desktop virtualization management system by distributing multiple administration servers that connect to a shared database for policies and configurations. Using a multiple vDesk Administration Server configuration, customers can scale vDesk to manage thousands of workspaces and distribute servers closer to where vDesk workspaces are executed to minimize network traffic.

vDesk Remote Servers Overview

The vDesk Remote Servers configuration provides for the establishment of links between multiple admin servers so that master workspaces can be distributed between the admin servers. Each link establishes a parent-child relationship between two admin servers. When Master Workspaces are created in the parent admin server, the Master Workspace can be pushed to the child admin server. The remote server link can be configured so that new master workspaces created on the parent can be sent to the child automatically or be initiated manually. The operation of replicating Master Workspaces from parent to child admin servers can be controlled for each workspace family or for all Master Workspaces.

Linking vDesk Admin Servers (Parent/Child)

Establishing Remote Server links has few rules and is very flexible. A parent-child relationship can be established between any two admin servers (however, an admin server cannot be linked to itself). Each admin server can be a parent to multiple admin servers or a child to other admin servers. An admin server can be a parent to an admin server and a child of the same admin server. Parent-child relationships can also be of any depth (parent child/parentchild/ parent, etc.). This provides a very flexible structure for deploying multiple master workspaces across a collection of admin servers.

Common Remote Server Scenarios

Although there is great flexibility for configuring Remote Servers, some common configurations will be most prevalent. Establishing Remote Server links is particularly useful in the following vDesk deployment scenarios.
  • Where Master Workspaces need to be distributed to remote locations over a relatively slow network connection.
  • Where Master Workspaces need to be shared across different functional domains.
  • Where Master Workspaces are created is a staging environment then deployed to a production environment at the end of workspace test.

Deployment to Remote Locations

In this scenario, Workspace Studios and Master Workspaces are initially created and tested at a centralized corporate location. Ultimately, the masters will be deployed to one or more admin servers that are at remote locations. The remote locations are connected to the central corporation office by relatively slow, inter-site connections (see Figure 13-1). By defining Remote Server parent-child relationships between the local admin server and the remote admin servers, the master workspaces can be distributed to the remote locations with ease.

Deployment between Multiple Functional Domains

In this scenario, Workspace Studios and Master Workspaces are created and tested in two separate functional organizations. However, the masters created in one organization will be deployed to the other functional organization (see Figure 13-2). By defining Remote Server parent-child relationships between the two functional admin servers, the master workspaces can be distributed between organizations.

Deployment from Staging to Production Servers

In this scenario, Workspace Studios and Master Workspaces are created and tested in staging environment then deployed to a production server (see Figure 13-3). By defining a Remote Server parent-child relationship between the staging and production admin servers, the master workspaces can be distributed from staging to production.

Deploying Multiple Distributed Admin Servers for Scalability and Performance

Multiple Administration Servers can be configured to run against a single Administration Database. This can provide the highest level of vDesk scaling while enabling flexible network access from locations across the enterprise. For example, a globally distributed organization could deploy admin servers in North America, Asia and Europe to minimize the WAN traffic that would otherwise occur when a single admin server communicated with a vDesk workspace instance.

If multiple Administration Servers are deployed, it is important that only one be used by vDesk administrators for web access to the administrative console. This is due to the caching of configuration parameters by the administrative context of Administration Server and because of the background maintenance jobs that must be run in only a single location.
 
Back to top

Distributed Storage 04/28/2010

If you’re planning to store vDesk workspaces on a file server and your users are distributed, you might want to consider using vDesk’s Network Storage Manager.  With the vDesk Network Storage Manager, you can locate each user’s workspaces close to their physical location to increase performance and minimize network traffic. In addition, distributing storage enables you to take advantage of existing storage capacity rather than purchasing additional storage.

Why do you need Network Storage if you are using vDesk on a PC or Drive?

Even if you plan to deploy vDesk on a PC or Drive, you might want to take advantage of vDesk MobileSync to backup vDesk workspaces to a network file share or enable users to move their vDesk workspaces between multiple PCs and Drives. To use vDesk MobileSync, you will need to define a network storage location for your vDesk workspaces. The closer to the user’s network location you store vDesk, the faster vDesk MobileSync will be able to backup and synchronize the user’s workspace.

In addition to MobileSync, Network Storage is required to predeploy workspaces. Predeploying workspaces to a Network Storage location speeds up the process of creating new vDesk Workspace Instance for the first time.

Configuring Network Storage

vDesk Network Storage provides the ability to define multiple storage locations where vDesk over the Network Workspace Studios and Workspace Instances (including backup copies of PC and Drive workspace instances) can be stored and executed. These network locations are also used for synchronizing and for predeploying workspaces for future activation by individual users.

Multiple Network Storage locations can be defined so that storage space and the execution of workspace instances can be controlled incrementally. Network storage locations can be defined for multiple locations on the same drive, for multiple locations on different drives on the same file server, and for multiple file servers that are used to store vDesk workspaces.

Associating Network Storage Locations

Network Storage locations can be associated with Workspace Studios and specific Master Workspace families, Master Workspace versions, users, and groups. For each association, minimum and maximum predeployment values and precedent values can be defined. A Network Storage location can also be specified as a default location.

Workspace Predeployment

When master workspaces are created (either directly on an admin server or by being pushed from parent to child via a Remote Server relationship), vDesk over the Network Instances can be created for future activation by individual users. This process, called predeployment, greatly decreases the time needed to create and activate a workspace for an individual user. When using Workspace Predeployment, it is important to understand the amount of storage that will be consumed at the various storage locations specified in the Network Storage Manager to ensure that you have sufficient storage space available. 

Predeployed Workspace Creation

Predeployed workspaces are created using background jobs executed by the admin server. When a Network Storage association is first created, a Max number of Workspace Instances are predeployed. After the initial predeployment, the actual number of predeployed instances will float between the Min and Max values. Background predeployment activity is triggered by the following activity:

  • Scheduled job, every 2 hours
  • Creation of a new master (including import from a remote server)
  • Change of a family default
  • Adding any new Network Storage association
  • Editing any Network Storage location so that the min/max predeploy counts change

Monitoring Predeployed Workspaces

The predeployment process can be monitored in two ways:

  • By viewing predeployment activity in the Event Log
  • By viewing counts of predeployed workspaces on the Network Storage and on the Master Workspace summary pages

Predeployment Caveats

Some admin server behavior may be unexpected during predeployment activity.

  • Only one workspace is every copied at a time during the backgrounds jobs that create predeployed workspaces. Even with only one workspace being copied it can be a CPU and IO intensive. So, beware of what you’re doing if the admin server is very underpowered.
  • Secondly, new predeployed workspaces are copied from existing predeployed workspace instances. During the copy process, the predeployed workspace used for the copy is temporarily removed from service and the count of predeployed workspaces is decremented by one. When the copy completes, both predeployed workspaces are put into service and the count is incremented by two.

Note:

Starting with vDesk 3.0, more fine grain control over workspace predeployment is provided. This is in contrast to prior versions of vDesk where a single “bulk predeploy” model where a single predeployment value was provided for all workspaces. Note also that predeployment adds an additional (but natural) step in the assignment of workspaces to users and groups. After creating a Master Workspace, the following steps will be performed:

  • Assign Master Workspace to group or user using the Masters tab in the corresponding details panel.
  • Determine where the master should be predeployed (chose a network storage location using the Network Storage tab in the corresponding details panel), and configure a number to predeploy for that user or group.

Common Predeployment Usage

There are many ways to use the predeployment feature, but the following are the expected common uses of predeployed workspaces:

  • Assign a Network Storage location to a group then predeploy a certain number of a specific Master Workspace to that location.
  • Designate that a particular Master Workspace family should always be deployed to a certain Network Storage location, and then predeploy a certain number there.
  • Predeploy one instance of a particular version of a master to a particular network storage location then allow an administrator to test that version before advancing it to be the default.
Back to top

Security Best Practices 02/25/2010

Implementing desktop virtualization can increase control, reduce exposure and avoid unnecessary risks to the enterprise desktop computing environment. vDesk is designed to secure corporate data and provides many isolation, encryption, access control, operating system checks and host security scanning policy options.

Isolation

The vDesk virtual environment, by itself, provides a significant level of isolation between the host and the guest desktop computing environments. When an application running inside the vDesk environment tries to access the host operating system resources (file system, registry, kernel objects), the application is virtualized and restricted to the virtual resources and therefore does not directly interact with the host operating system.

vDesk enables administrators to set several isolation policies. These policies can be applied by workspace instance, master, user or group to allow for different levels of isolation for different types of workers, individual users or workspaces. When considering which policy options to enable/disable, you should weigh the flexibility required by each use case against the confidentiality of the data in the workspace and the level of trust placed on the host PC. For most users, the security best practice is to make the vDesk workspace the primary desktop computing environment and then maximize the isolation between the vDesk workspace and the host PC. Depending on the level of restriction the system administrator wants to enforce, some or all of these options can be enabled:

  • Prevent Switching to Host PC
  • Isolate Clipboard
  • Clear Clipboard on Switch to Host
  • Clear Clipboard on Switch to vDesk
  • Block vDesk from Using Host Printers
  • Disable vDesk Printers
  • Disable Print Screen
  • Disable Access to Optical Drives
  • Disable Access to Fixed and Removable Devices
  • Disable Access to Network Devices
  • Disable Access to vDesk File System from Host

 Host Security Scan

Prior to launching vDesk, it is recommended that you verify the security of the host PC by running a Host Security Scan. The Host Security Scan checks that the computer is protected with the required endpoint security software and that the software is up-to-date prior to launching the vDesk workspace. There are several host security scan policy enforcement options available in vDesk. Depending on the level of security the system administrator wants to enforce, some or all of these options can be enabled:

  • Check for Host Antivirus Software
  • Validate Last Antivirus Scan (Days)
  • Validate Antivirus Definition Update (Days)
  • Check for Host Antispyware Software
  • Validate Last Antispyware Scan (Days)
  • Validate Antispyware Definition Update (Days)
  • Check for Host Firewall
  • Allow Login even if Host Check Fails
  • Custom Remediation message

 Operating System Check

Prior to launching vDesk, it is recommended that you check that the operating system meets a minimum patch level required by your organization to ensure that it is not vulnerable to compromise. vDesk enables administrators to enforce a minimum service pack level requirement for supported Operating Systems including Windows XP, Windows Vista and Windows 7*.

*Windows 7 available in vDesk 3.0 and later

Encryption

When you use vDesk workspaces on a laptop or removable drive, RingCube recommends encrypting the workspace to ensure confidential data is not exposed if the device is lost. If you are in the financial services, retail, government, or healthcare industries, you may be required to encrypt your workspaces just as you would be required to encrypt the file system or hard drive of a physical PC. vDesk provides integrated encryption when deploying workspaces to a portable drive or on to a PC.

For more information on vDesk Workspace Encryption, please see the Workspace Encryption GuruTip

Workspace Access Control and Protection

In addition to the isolation policy options described above, there are additional virtual desktop policy controls regarding updates, personalization, and application installation features under the 'General' tab in the 'Create Policy' section. These policies enable administrators to further lock down the vDesk workspace environmnent:

  • Prohibit Change to Automatic Update Settings
  • Disable Data Import/Export
  • Prohibit Application Installation
  • Administrator vs. Limited Privileges

 Network Security

These options determine whether vDesk shares the network stack and the network adapters from the host PC, or uses a virtual adapter.

Enable vDeskNet
When this option is selected, the network stack of vDesk is virtualized and a virtual network adapter, with a separate MAC address and an IP address, bridged to one of the host.s physical network adapters, is available inside vDesk. This option enables network traffic isolation between the host applications and vDesk applications. It also enables several VPN clients to be used in vDesk isolated from the host.

Join Domain
With the 'Enable vDeskNet' option selected, and a domain specified in this field, vDesk workspaces will automatically join to this domain. The host PC doesn't have to be joined to a domain. GPOs are automatically applied as well.

Remote Access Security

Connecting an unmanaged host PC to the corporate network over a VPN can result in malware propagation over the VPN from an infected host PC. When providing remote access, it is recommended that you verify that the user is running the VPN client from within vDesk workspace and not directly on the host PC. This can be accomplished by using the pre-authentication host checking (aka Network Access Control) functionality of the VPN product to verify that the vDesk process, registry keys and/or a hidden binary file inside the vDesk workspace.

In addition, it is recommended that organizations use some type of strong authentication such as RSA SecurID token and/or client-side certificates which can be securely stored and encrypted inside the vDesk virtual workspace.

For VPN client distribution, it is recommended that organizations use the vDesk image update feature so that VPN clients are only installed in vDesk workspaces and not on unmanaged host PCs.

vDesk Studio: Master Image Windows Security Settings

In addition to the policy options described above, vDesk administrators can modify specific Windows Security Settings to remove or disable areas of functionality that limit the end users ability to circumvent the security protection and enforcement policies of the virtual desktop. Below is a list of commonly used Windows Security Settings that can be modified within a Master Workspace image during a vDesk Studio session:

Windows Security Settings modified within vDesk Master Workspace

Back to top

Single Sign In 01/27/2010

Why should you use vDesk SSI?

When you think of using Desktop Virtualization, you usually think of running a virtual desktop on top of an existing physical Windows PC environment. Normally, you start the physical PC, login to the OS installed on the physical PC and then repeat the login process again for the virtual desktop. If users don't have multiple virtual desktops, why make them login twice with the same credentials?

With vDesk Single Sign-in (SSI), IT administrators can streamline the login process for users with a single vDesk virtual workspace. The process of implementing SSI is as simple as writing a login script that invokes the vDesk Client and calls a command line option start the default workspace of the authenticated user.

Once SSI is implemented, users are automatically logged into their default vDesk workspace based on the credentials used to login to their PC.

How do you implement vDesk Single Sign-in?

At a high-level, there steps required to implement SSI:

  1. Install the vDesk Client
  2. Create the Login Script (*optional)
  3. Edit the Registry

 Installing vDesk Client

1. The first thing you will want to do is install vDesk Client from the client portal

  1. Login to the Windows operating system using an admin account on the PC
  2. Go to your Client Portal "https://<ip address>:<port>/client"
  3. Log in using valid credentials
  4. Click "Launch vDesk Client"
  5. After the client launches, you can close both your web browser and vDesk Client

 Creating the Login Script

2. Next, we will want to create a script that launches vDesk client when the computer starts. You can use notepad or any other text editor. You will want to do this if you also need to launch other applications before/after vDesk or if you want to shutdown the computer after logout.

  1. Write the script (see example below) 
    @ECHO OFF

REM Launch vDesk Client and wait for exit before proceeding
start /wait /min /d "C:Program FilesRingCubevDeskClient" vDeskClient.exe /ssi

REM Shutdown the computer when the user logs out of vDeesk
shutdown -s -t 0
  2. Save this file to a known location such as "C:LaunchvDesk.bat"

 Edit the Registry

3. Next, you will want to open your registry editor

  1. Click Start
  2. Select Run
  3. Type "regedit" in the box and click "OK"
  4. Now you will want to add vDesk Client to the run key for when your user logs in. You can do this on a per user basis or for all users. For the simplicity of this tip, we will just do it for all users.
  5. Navigate to
    HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRun
  6. You will want to create a new string value named "vDesk" and enter the path to your script as the data. (See Figure 1)
  7. Alternatively, if you did not create a script, you can enter the following data into the registry key:
    "C:Program FilesRingCubevDeskClientvDeskClient.exe" /ssi /hostlogout Figure 1: Edit the Registry
    Figure 1: Add the path of your script to the registry Run key.
  8. Now you can exit regedit and restart your computer. The next time you login to the Windows OS, the vDesk workspace of that user will automatically launch

 Using SSI with MobileSync for Automated Network Backup

If you want to use vDesk MobileSync with SSI to backup the user's default vDesk virtual workspace to a network file share, you should select MobileSync option "On Exit" to automatically backup the user's workspace. (See Figure 2)
Figure 2: Sync on Exit
Figure 2: Configure Sync on Exit for the vDesk workspaces

Back to top

Workspace Encryption 12/15/2009

Why should you encrypt vDesk workspaces?

When you use vDesk workspaces on a laptop or removable drive, RingCube recommends encrypting the workspace to ensure confidential data is not exposed if the device is lost. If you are in the financial services, retail, government, or healthcare industries, you may be required to encrypt your workspaces just as you would be required to encrypt the file system or hard drive of a physical PC.

Compliance initiatives that require encrypting data or the full disk:

PCI DSS(Retail,Financial): PCI DSS is a security standard that includes requirements for encryption of cardholder data.

GLBA(Financial): The Gramm-Leach-Bliley Act requires financial institutions to determine when encryption of customer information in transit or in storage is appropriate and if so, to implement it.

HIPPA(Healthcare): The Health Insurance Portability and Accountability Act includes security standards that require encryption and protect the confidentiality and integrity of individually identifiable health information.

HSPD-12(Government and Defence): Homeland Security Presidential Directive 12 requires encryption to prevent unauthorized users from obtaining secret, sensitive, or confidential data.

SB-1386(Retail, Financial): California law regulating the privacy of personal information, which includes encryption of customer information.

EU Data Protection: European Union directive which regulates the processing of personal data within the European Union including encryption of personal data at rest.

How Does vDesk integrated Encryption Work?

vDesk supports integrated encryption for vDesk on a Drive and vDesk on a PC. vDesk Integrated Encryption currently supports two open source encryption products:

Both open source products create encrypted containers on a PC or a drive that can be used for deploying a vDesk Workspace Instance where all of the files contained in the Workspace are encrypted. The administrator can choose to require that workspaces are encrypted or give the user the option to encrypt the workspace. The vDesk Administration Server automates the process of installing the encryption software, creating the encrypted container and activating new vDesk workspaces inside the encrypted container (See Image 1). Once activated, encrypted workspaces are shown in the vDesk client with an orange lock icon in the vDesk Client workspace list (See Image 2).

Image 1: Workspace Activation with a vDesk Integrated Encryption
Image 1: Workspace Activation with a vDesk Integrated Encryption

Image 2: Encrypted Workspace (Orange Lock Indicated Encryption)
Image 2: Encrypted Workspace (Orange Lock Indicates Encryption)

Configuration for vDesk Integrated Encryption is a multi-step process:
  1. Select a supported encryption product to be used to create encrypted containers for vDesk Workspace Instance deployment. Note that only one encryption product is supported by the vDesk admin server at a time. Install the encryption product using the installation executable from the product web site.
  2. Create an Encryption subdirectory in the vDesk Administration Server storage-root directory. In the Encryption subdirectory, create subdirectories that contain the encryption product installation, executable, configuration, and container files.
  3. Create one or more encryption containers of sizes that will be appropriate for the Workspaces Instances that will be deployed.
  4. Add encryption product files to the Encryption directory.
  5. Update the vDesk Administration Server system properties to configure the admin server for a specific encryption product.
  6. Update Master Workspace details to enable encryption.
For detailed steps on implementing encryption, please visit the “Configuring vDesk Integrated Encryption” chapter of the vDesk Administrator’s Guide.

Back to top

 

Demo vDesk Overview
Watch Demo
Demo vDesk over VDI
Watch Demo
Demo vDesk Performance
Watch Demo | Details