Implementing Virtual Desktops (VDI): Desktop Migration – Phsyical To Virtual.

Introducing users to new virtual desktops (VDI – Citrix XenDesktop, VMware View) in a green-field scenario is a relatively pain-free process since there are no previous configuration or usage expectations from the user. However, migrating users from an existing physical desktop to a new virtual desktop or to a new operating system or application set can often lead to a user’s personal desktop settings being lost or corrupt in the process.  From the user’s perspective, they have been ‘made to move’ from a familiar, productive, personal environment to a new, sterile, non-personal environment.

 When moving to a new VDI environment, the user transition from desktop to desktop must occur seamlessly – as , moving users to standardized virtual desktops results in a new, sterile and impersonal experience for the user – a far cry from their fully personalized and familiar local desktop.  This tends to lead to a lack of user adoption, increased support costs and reduced productivity.  So how can IT realize the benefit of migrating users to a standardized environment while ensuring high user adoption?

With user environment management, user settings within the existing desktop are automatically identified, decoupled and moved to a central store. The user can then be moved to a standardized virtual desktop.  When the user accesses this desktop, these stored user settings are dynamically applied to the virtual desktop session, recreating their ‘PC environment’.  Subsequent personalization settings are persisted between virtual desktop sessions – even if those sessions themselves are not persisted (such as the componentized layered model from Citrix XenDesktop ) – ensuring the user has a familiar, personal experience at all times.

Since all aspects of the user are decoupled and stored independent of the desktop, organizations can now be more flexible in how desktops and applications are delivered to their users.  User settings can now be dynamically applied into any desktop and application regardless of how those components are delivered to the user.  This “Follow Me Personality” therefore enables IT to use the optimum method of desktop delivery, while ensuring the user always has a consistent, predictable and controlled working experience….even when off-line!

Reduce storage requirements for lower cost VDI…

SAN infrastructure often proves to be one of the most costly components in a VDI implementation and for a lot of organizations, has proven to be a serious barrier to VDI adoption… a real show stopper.

As we know, there are several ways in which a VDI environment can be implemented (1:1 Dedicated images, Pooled, Layered, Componentized, provisioned etc.. the list of terms is endless), yet only one deisgn will satisfy both the needs of the IT department (cost, management overhead, implementation time etc..), and more importantly, for it to be accepted, satisfy the needs of the user. 

From my experience, early VDI adoption was implemented by taking an existing desktop, creating a virtual image of it, and then placing it straight into a datacenter.  This approach was quick to migrate users to the new delivery mechanism, however unfortunately it did  not provide IT with a low cost, easy to manage environment.

In the above model, a huge amount of storage is required for a dedicated 1:1 relationship between the user and their desktop image – typically a minimum of 10GB per desktop, more realistically I would say 20GB per desktop.  Coupled with this, IT still have to manage the same amount of desktops, it just so happens all the desktops are now hosted in a datacenter as opposed to spread around the organization and out in the field.  Tasks such as patching and updating desktops still need to be done on a mass scale.

To reduce the amount of storage required, desktops can be pooled or provisioned, ideally from just a single master image of the Operating System and Application set.  While this reduces the management overhead and SAN requirements, it does however also significantly reduce the end user experience as all users are now working from a standard, un-personalized desktop.

From the organizations we have been working with, a true VDI environment works at low cost, using a small amount of storage, with minimal amount of management yet still provides a feature rich, personalized desktop that responds quickly to user actions.  This has been achieved through the use of user environment management (UEM) technologies.  

A UEM solution helps to reduce SAN requirements and also ensure user satisfaction by automatically applying user personality (a combination of tailored policy and user personalization) to desktops and applications, providing a familiar, personal working environment. 

A 1:1 relationship between user and desktop can now be achieved without the costly overheads of a large SAN infrastructure.  Making VDI is not only available at lower cost, but more importantly, accepted by the user population.

So to summarize, yes, SAN is a major consideration when looking at VDI, although it can be reduced if combined with a user environment management solution.

Disk Resource Management, Ensuring Access To Disk = Faster Desktops & Applications

Hard disks are often the cause of system bottlenecks as they are typically the slowest part of any computer system. This is exacerbated in SBC (Microsoft Terminal Server & Citrix XenApp) and VDI (Citrix XenDesktop & VMware View) environments as multiple users and applications simultaneously request disk access. When such bottlenecks occur, all users and applications on the server experience a prolonged wait as their disk access request is queued. This results in the application or desktop session hanging, and in some cases, becoming completely inoperable.

Disk bottlenecks occur when users or applications require disk access faster than what the disk can support. Before considering how best to remedy this common problem, let’s first detail what causes a disk bottleneck.

An application running on a server is enabled by a process, which typically includes a plurality of threads. These processes have a requirement to read and write to and from a disk, commonly referred to as an input/output (I/O) device (for the purposes of this paper, we will refer to the I/O device as a ‘disk’). The operating system creates an I/O Request Packet (IRP) for every thread read/ write request which is passed through the driver stack to be processed by the disk.

Everyday situations require disk read/write operations to be performed at a level greater than the disk can support. This is especially true when the server allows multiple processes or applications to run in parallel. When the number of IRP’s is greater than the number of IRP’s the disk can process, the disk is in a state of overload and IRP’s are queued to be processed.

As with CPU, individual applications, processes and threads can monopolize a disk and cause resource contention between the IRP’s. These IRP’s then become stuck in a queue, waiting to access the disk. During this time the user experiences a poor quality of service as the application or desktop session takes an unacceptable length of time to complete the task.

AppSense Performance Manager prevents disk I/O IRP bottlenecks from impacting mission critical applications. Disk I/O control prioritizes IRP’s in accordance to business policy, enabling Administrators to assign priorities to individual applications on a per user basis. To achieve this, AppSense Performance Manager uses a kernel level filter driver, through which all IRP’s are then passed. The driver monitors and compares the number of IRP’s passed down the driver stack against the number of completed I/O operations to determine if the disk is in a state of overload and a bottleneck is present.

When a bottleneck is present, AppSense Performance Manager then intercepts all IRP’s before they reach the target disk, and controls the flow rate by re-ordering the IRP’s in accordance to the priorities assigned to them. For example, an application with a higher priority than a second application will have preferential access to the disk if a bottleneck is present.

By assigning higher priorities to important applications, they no longer have to wait in a queue while less important processes consume disk activity. Ensuring key applications have priority access to the disk eliminates inconsistency in application response times, reduces the user’s time to wait, improves quality of service and maximizes the efficiency of hardware resources.

This proactive approach to disk resource management is used by thousands of organizations around the globe to ensure applications and desktops respond and perform at an optimal level.

Replacing Complex Logon Scripts For Faster Logon Times & Simplified Management

The traditional logon script has been the de-facto method to configure enterprise options for a user.  As its name suggests, the logon scripts executes during logon. This makes it a one stop ‘set and forget’ solution in that once the value has been applied the script has performed its job.

A typical logon script will connect network drive mappings, printers and perform other tasks such as ensuring corporate email clients are correctly configured as well as copying necessary files and / or folders into place within the user’s home directory or profile.

Logon scripts by their very design are synchronous in their approach, which can mean that while some of the actions required to be part of the script are completely unrelated, they are addressed in line with each other. This shows itself as a user logon taking an unacceptable length of time due to the number of actions, all of which are fed into the operating system line by line.

Furthermore, at the same time, because the script is an interpreted language, they are constructed differently from one person to the next!  This leaves the script subject to the administrator’s style and ability, meaning there is no standardization across the enterprise. The variations in styles of different authors can rapidly make the scripts difficult to read and follow, making debugging or alterations a very time consuming and costly task.

The above variables and computing conditions can often lead to scripts which take a long time to execute, even hanging or failing to complete. When this happens, the user is left disconnected from the system and the IT department plagued with support calls. Troubleshooting is often difficult as the support desk operator is unlikely to be the person who created the script, and as covered, has to learn the script before he can troubleshoot the issue or in some cases pass the call up to a higher level of support, either of which increases the time and cost spent on remedying the issue.

AppSense Environment Manager resolves the above issues, reducing complexity and saving on time and cost by completely replacing the troublesome scripting process with an easy to use graphical user interface, complete with wizard based actions. Actions can be selected and then applied at a user or device level, based on environment variables, without the need for any complex scripts. Furthermore, the GUI ensures consistency between Administrators, meaning any other support worker can quickly troubleshoot and amend any existing configuration..

AppSense Environment Manager is used by thousands of enterprise customers around the world to provide the flexibitily a logon script cannot give, reduce operational costs, and ensure users can log onto their system in the quickest time possible..

Profile Corruption, Last Write Wins, And Profile Rollback

One of the biggest problems in a SBC (Microsoft Terminal Services or Citrix XenApp) and VDI (Citrix XenDesktop and VMware View) environment is that of the issues caused by the dreaded Roaming Profile.  One such issue which plagues both users and IT Support desks alike is Profile Corruption.

Profile corruption is seen as innevitabele when using roaming profiles, and can leave a user locked out of their desktop for hours, support desks inundated and overwhelmed with support cases, and is a huge drain on resources at great cost to a business.

AppSense Environment Manager not only prevents Profile Corruption, but also enables IT Support desks to reduce other profile related support cases from being a 2 hour resolution process, to just 5 or 10 minutes.  This not only improves user satisfaction, but makes for a more efficient, and lower cost support desk.

Profile corruption can occur through the overwriting of user settings as a user logs off from concurrent working sessions and settings made in each separate desktop try and write back to a central store.  Often overwriting each other, causing conflict, and leading to corruption

With AppSense Environment Manager, when a user launches an application, regardless of how it is delivered to a user (local install, Citrix, Microsoft App-V, VMware ThinApp, InstallFree etc…), we inject a Profile Virtualization Component (PVC) into the running process which allows any personalized settings, i.e. writes to the registry or file system, to be virtualized and therefore effectively redirected to a ‘local virtualization cache’ located on the user’s endpoint or within the user session itself (in the case of TS/XenApp).  This is an automated process, no need for manually specifying which registry keys or settings to capture. 

When the application is closed (not just at user logoff), the contents of the ‘local virtualization cache’ (only those [delta] changes made by the user during this running instance of the application) are then synchronized to a back-end database server so that a centralized copy of the user’s personalization settings is now available and able to be streamed back into open concurrent sessions or across multiple delivery mechanisms.

This eliminates the last write wins at the session level by not writing back to NTUSER.DAT at logoff. Significantly reducing the window for corruption as settings are syncronized back throughout the user session, not all in their entirity at logoff. 

So now as an additional benefit, settings can be shared across concurrent sessions as the next time the user launches the same application, be it from the same or a different concurrent session, the contents of the ‘local virtual cache’ are checked to see if the settings are up-to-date.  If they are, the user will get their latest personalization settings from the local cache.  If the settings are out-of-date, then the new delta user personalization settings for that specific application will be streamed down to the endpoint device on-demand.

With remediation tools such as Profile Rollback, application settings (which are stored in the SQL database at a per application level for each user) can be rolled back with just a couple of clicks in the AppSense console.  This takes 2 hour support calls down to just 5 or 10 minutes, and the beauty is, as the user settings are virtualized and so are not part of the desktop itself, the user need not log off their session for the rollback to occur.  Merely close and re-open the application in question..

Enabling OFFLINE Personalization Support for SBC and VDI

One of the biggest problems faced with a server based computing or virtual desktop environment, is that of ensuring any user personalization settings made to the desktop or application set whilst on the SBC or VDI session, are then persisted and available to the user when the user goes offline and uses an external or roaming device such as a laptop.  This is then repeated in ensuring any personalization changes a user makes on an offline device are also replicated and present back on the SBC or VDI session.

AppSense Environment Manager’s solves this crucial problem by providing users with a ‘follow me’ personality, across all delivery mechanisms and devices.  AppSense Environment Manager’s unique Offline Mode ensures mobile users have access to the latest version of their personalization settings when not inside or connected to the corporate network.

The process behind this is relatively simple and utilizes a ‘local virtualization cache’ which resides on the end point device.  When a user is logged on to a managed computer, their personalization data is stored locally in the virtual cache on the endpoint device. By default, when the user logs off or shuts down the device, the cache is deleted, and recreated when they next log on.

To enable offline availability of the settings stored within the local virtualization cache, the AppSense Environment Manager Console provides an option for the administrator to specify, on a per-machine basis, that the user is working in offline mode and requires their cache to be permanently available on the device, thereby not deleting it at logoff or shut down.

The settings are now available to the user for the duration of their disconnected state, any further changes the user makes to their desktop or application set during this time are automatically captured, redirected from the local registry and file system, to the local virtualization cache.  Upon reconnection to the network, these new settings (the delta’s) are automatically synchronized back to a SQL database and are available to be streamed back into any other concurrent session.

As you may be aware, the personalization (profile) settings are only one half of the user personality, the other half being ‘policy’.  Policy remains on the end point device at all times, regardless of whether the managed computer has offline mode enabled or disabled.  Policy remains as it is part of the AppSense Environment Manager configuration, which resides on the endpoint device at all times to set up, maintain and self heal the environment.

If you would like any further information, please do ask.

Group Policy Objects (GPO’s) & AppSense Environment Manager

Background information on GPO’s
Group Policy Objects are a common part of most organizations IT policy, while they are a needed tool for controlling the desktop, applications and security settings presented to a user, they are also one of the most complicated and time consuming policies to set up and maintain in an enterprise environment.

The main challenge with GPO’s is quite simply the management overhead required to keep on top of the ever changing requirements of the enterprise. Given that Policy is typically applied [within the AD] at Domain level, Computer Organizational Unit (OU) level and at User OU level, it can easily and rapidly become a management nightmare to ensure that the complexity does not overcome the needs of policy configuration in the first place. This along with the GPO’s inability to have fine enough granularity (limited to AD Groups and OU as the means of depicting whether Policy is applied) make GPO’s a difficult method to accurately deliver the policy to the corporate end points and end users.
Managing GPO’s with AppSense Environment Manager.
AppSense Environment Manager resolves the above issues, reducing complexity and saving on time and cost by completely replacing the admin intensive process with an easy to use graphical user interface, complete with wizard based actions.

Actions can be selected and then applied at a user or device level, based on environment variables, without the need for any complex scripts. Furthermore, the GUI ensures consistency between Administrators, meaning any other support worker can quickly troubleshoot and amend any existing configuration.

AppSense Environment Manager builds on the GPO technology, but instead of relying on complex scripting and applying settings at an OU level or computer level, Environment Manager uses a GUI interface to present the administrator with an easy to read list of ADM templates and GPO settings, and then enables them to be applied at a user level based on a flexible rules list.

With the Environment Manager flexible rule set, Group Policy actions need not be applied at a group level.. but instead, to whoever or whatever you want..