VCAP-DTD | Objective 2.2 | Determine Session Integration Requirements for a Desktop Pool Design

Based on customer requirements, establish the number and types of pools to be included in the design

The information gathered from capacity planning will be used here, alongside the previous work completed defining use cases. At this stage of the design process we need to be able to map the use cases to an instance of VMware View. A View instance is commonly defined by:

  • Location
  • Remote Access
  • Number of Users
A View instance can only exist in one location and cannot be split across physical data centres
  • View Connection Servers communicate using the Java Messaging Service which requires timely response message to be sent (See Simon Long’s awesome post here to understand why)
  • View Connection servers must be connected by LAN in the data centre.
VMware recommend that if a View deployment needs to span multiple data centres then separate View instances should be used.
View instances are limited to 10,000 desktops. If greater number of desktops are required then separate instances should be used.
For some use cases that are in a remote location with poor network access, consider deploying a View instance closer to those users, alternatively consider using local mode desktops.
For ease of management, try to keep the number of pools to a minimum, try not to overcomplicate the design as this can come back to haunt you.

Establish the detailed pool characteristics

Pools in View have the following attributes:

  • Pool Type – Automated, Manual or Terminal Services
  • User Assignment – Dedicated or floating
  • Full or linked clone desktops
  • User Experience Settings – Power, Desktop Reset, display protocol
  • Pool Size – number of spare desktops, master image
  • Performance – VMware vSphere ESXi hosts and datastores
  • AD groups and containers
Pool Type
Use-case characteristics
  • Users have existing desktops that must be retained
  • Administrators want the ability to manually assign desktops because of security or BC/DR requirements
Design Decisions
  • Automated pools are a VMware recommendation, they reduce operational overhead
  • Manual assignment in an automated pool is an admin overhead and is not generally recommended
  • Terminal Services pools can be used for legacy users
User Assignment
  • Dedicated desktops can be assigned automatically or manually
Use-case characteristics
  • User data and profile is or is not stored on the network
  • User is required to install applications locally
  • User has a current virtual desktop
Design Decisions
  • Floating desktops are recommended where possible for management and resource efficiency
  • Dedicated desktops are normally required for users who have specific applications or data on an existing desktop
  • Dedicated desktops complicate management and BC/DR
Full or Linked Clones
 
vCenter server manages both full clone and View composer linked clone desktops
Use-case characteristics
  • Number of changes the users will make to the system disk
Design Desicions
  • Linked clones will significantly reduce storage requirements. They are recommended if the user have limited write access to the OS disk
  • Consider where to store profile, data and applications. Using linked clones you will want to avoid writes to the OS disk as it will grow
  • If users require elevated permissions to change OS properties to install applications, full clones are recommended
User Experience Settings
– Power Policies
  • Take no action (default power policy, desktop remains on at all times)
  • Ensure desktops are always powered on, suspended or powered off
Use-case characteristics
  • Users require fast/instant access to desktops
  • Large numbers of users will logon at the same time
Design Descions
  • Powering off the desktops can lead to increased wait times, but reduces power consumption
  • Suspending desktops increases storage consumption but has faster resume times
  • VMware recommend the default setting for quickest access to desktops
– Ability to reset desktop
Do you allow your users the ability to rest their own desktops?
Use-case characteristics
  • Some users may require the ability to reboot their desktops, especially developer/power users
Design Desicions
  • Generally not recommended, unless there is a specific requirement
  • May need to be enabled because of existing modes of operation
  • Remember, a desktop reset add load on storage and compute resources
  • VMware recommend that if a subset of users require this capability you create another pool
– Protocol Choice
PCoIP vs RDP
Use-case characteristics
  • User require multimedia applications or video
Design Decisions
  • Protocol choice requires a solid understanding go the user applications as well as network performance
  • PCoIP improves the user multimedia experience
  • PCoIP is better over high latency networks however had a higher bandwidth requirement than RDP
  • You can allow users to choose their own protocol (only a good idea with power users and knowledge workers)
  • View client with local mode is an option if display performance is critical
– Windows 7 3D Rendering
Is 3D rendering enabled or disabled
Use-case characteristics
  •  Windows 7 users require Aero, Office 2010 or Google Earth
Design Decisions
  • Pool deployment must meet the following requirements:
    • Desktops must run on ESXi 5.0 or later
    • Desktops must be managed by vCenter 5.0 or later
    • Desktops must have virtual hardware version 8 or higher
    • The pool must use PCoIP as it’s display protocol
    • User must not have the ability to change the display protocol
  • vRam on desktops must be configured between 64Mb and 128MB depending on the use case
– Persistant Disk
A persistant disk is an option when using dedicated linked clone desktops. You are able to configure the disk size and drive assignment.
Use-case characteristics
  • User has a local profile
  • User has a local mode desktop
Design Decisions
  • A persistant disk redirects the user’s profile to a separate persistent disk to ensure that any user changes are not lost when the OS disk is refreshed or recomposed
  • Use View Persona Management to implement roaming profiles and folder redirection, which will eliminate the need for persistent disks
– Maximum number of desktops per pool
Use-case characteristics
  • Maximum number of concurrently connected users in the pool
Design Decisions
  • A linked clone pool should not exceed 1000 desktops
  • A number of pools may be required with the same configuration to reach the required number of desktops
– Desktop Provisioning
Are desktops provisioned ahead of time or on demand?
  • If desktops are provisioned on demand, configure the ‘Min number of desktops’ setting  to ensure the setup is able to meet the expected immediate demand. Provisioning a desktop takes longer than powering on a desktop.
Use-case characteristics
  • Expect large numbers of users to logon at any one time
  • Minimum number of concurrently connected users
Design Descions
  • Up front provisioning ensures that all desktops are provisioned and enabled ensuring no delays in logon times
  • On demand provisioning is suitable if logins are spread through the day, meaning that the number of peak logons at one time is very low
 – Default Image
Any desktops that utilise linked clone technology are linked to a parent master image.
Use-case characteristics
  • Additional parent virtual machines are required in the following cases:
    • Users have an application that cannot be virtualised and must be installed on the parent virtual machine
    • Users require a desktop with more memory or more CPUs, or access to a different network
Design Decisions
  • Pools are unique when a use case has a different OS, application set, VM configuration, or network requirement
  • VMware recommend keeping the number of parent VMs to a minimum.

– Infrastructure – Hosts and Clusters

Use-case characteristics
  •  User applications require dedicated CPU or memory
Design Decisions
  • Use case requirements could mean only one per per host/cluster and lower the density per host
  • Based on capacity management , allocate each pool to a certain cluster
  • Some pools can be allocated in clusters that have less resource contention as determined by the View connection servers or View Composer
– Infrastructure – Datastores
All datstores will be managed by vCenter server.
  • You are able to use tiered storage to segregate linked clone replicas, OS disks and persistent disks
  • Note – the linked clone disposable disk is always stored with the OS disk
Use-case characteristics
  • Users require specific I/O performance
Design Desicions
  • A use case may require unique I/O performance, which can be satisfied by certain datastores
  • A pool may be placed on different storage tiers
– User Entitlement
Use-case characteristics
  • Groups of similar users are contained with AD groups
Design Desicions
  • Group similar users (same use case) into AD groups and map the groups to pools
  • Grouping reduces the admin overhead of mapping users to pools
 – ThinApp Assignments
ThinApp packages can be assigned to specific desktops or all desktops within a pool
  • A ThinApp package can be fully installed on a desktop or streamed from a ThinApp repository
Use-case characteristics
  • A user has a set of applications that are available as ThinApp packages
  • User requires local mode desktops
Design Decisions
  • VMware generally recommend streaming ThinApp packages to the desktops
  • If local mode is a retirement then ThinApp packages myst be fully installed before the desktop is checked out

Identify delegated administration of roles

View allows you to lock down certain administrative elements to allow certain groups of users to manage and perform certain administrative functions on certain desktop pools. These requirements should have already been identified during interviews and from the functional and non functional requirements.

Try to use active directory security groups to delegate permissions. This makes ensure easier management and enables auditing to be carried out.

Determine monitoring requirements

At this stage of the design we should already be aware if monitoring is required, be it of the infrastructure or the virtual desktops or both. We should also be aware of any existing monitoring software that could be in place, it’s ability to mange virtual desktops and any licensing and software requirements (will agents in desktops be required).

Try and avoid products that require agents to be installed in desktops and look to utilise applications that use host based monitoring such as VMware vCenter Ops for View.

Establish persona management

Persona management has no system requirements other than VMware View itself. VMware does recommend particular configuration for server, network sped, and file server memory to provide you with the best performance for person management of user profiles.

  • Servers – One or more file servers, each storing a maximum of 1000 user profiles. If a VM is used as a file server, the volume storing the profiles works optimally if striped across four virtual disks each with its own SCSI controller. (Physical file servers work best with the same configuration)
  • Network Speed – At least 1Gps between the desktops and the file servers
  • RAM – 8GB per file server

Results will vary depending on the following:

  • Storage Capability
  • Network speed and latency
  • Number of users
  • Frequency that users access data stored within the profiles
  • Storage Capacity
  • Storage Performance (IOPS)
Ensure folder redirection is configured correctly for the appropriate OS types being supported.
Ensure View Persona Management is enabled within the View Agent on the desktop
Don’t use AV scanning products on the persona repository
Do not use backup tools with VSS enabled to backup the persona repository. View already backs up the profile during user sessions. Multiple pieces of software backing up with the VSS provider can cause file corruption.
If desktops are provisioned with ThinApp applications, remember to configure View Persona management to include the ThinApp sandbox for any packages that have large files.
If you implement View Persona Management of a Windows XP desktop you must install and run the UPHClean
Remember to account for the restriction that a user cannot access the same profile if they switch between desktops that have a v1 user profile and a v2 profile (Unless using third party tools such a Liquidware Labs)
When configuring a user profile repository remember:
  • The folder does not have to be in the same domain as a View Connection Server
  • The folder must be in the same AD forest as the users who store profiles in the folder
  • The folder must be large enough for all users profiles (Separate repositories may be configured for separate pools, however pools that are accessed by the same users must be configured with the same repository)
  • Create the full profile path under which the user profile folders with be created so that permissions are correctly assigned
Determine whether to remove the local user profiles at logout
  • By default, profiles are not deleted at logout, which reduces I/O
  • If floating assignment pools are refreshed or deleted at logout, keep ‘Remove local persona at logoff’ disabled
Handling deployments that include View Persona Management and Windows Roaming Proifles:
  • If you use View Persona Management for desktops and roaming profiles for standard desktops, ensure you use different profiles for the two environments
  • If AD GPOs are used, then enable the ‘Persona repository location’ setting and select ‘Override Active Directory user profile path’
Configuring paths for redirected folders:
  • Configure the folder path to include %username% and the name of the redirected folder
    • For example, \\<file_server>\Documents\%username%\My Documents
For antivirus:
  • Use the default behaviour and do not scan offline files
  • If an AV scan of the desktop is required, ensure files and folders are preloaded
Use persistent disks if users generate a large amount of persona information and they use dedicated desktops. If persistent disks are used then ensure the ‘Remove local persona at logoff’ policy is disabled. Enabling this policy deletes user data from the persistent disk when a user logs out.

Determine an appropriate anti-virus solution for a desktop pool design

Try and utilise an antivirus solution that makes use of VMware vShield to offload some of the overhead associated with AV products from the virtual desktops. VMware have a number of partners offering different solutions, so hopefully you will be able to match a product to your customer needs/requirements.  vShield endpoint consolidates and offloads all antivirus operations into one centralised security virtual appliance. Once vShield appliance is required per host.

vShield provides the following benefits:

  • Improves consolidation ratios of desktops
  • Provides agent less security
  • Always On
  • Simplifies maintenance of desktops to be protected
  • Simplifies deployment if you change AV vendor
  • Satisfies audit requirements by providing detailed logging
To avoid resource storms when initiating an AV or update or scan:
  • Stagger AV scans to avoid resource contention within the cluster
  • Apply any large AV updates only to the parent VM
  • Configure AV not to scan View logs

Based on customer requirements, identify appropriate firewall policies for the design

Most firewall requirements will come from your customers security and compliance teams. This information like much of the design, will come from interviews and requirements. Firewall requirements will not always be the responsibility of the network and security teams, there will be a number of elements that will need to be considered in the View design itself:

  • ESXi Host Firewall
  • vCenter server hardening
  • Security server hardening
  • Desktop OS firewall configuration
  • Network security (vShield endpoint can be used to manage traffic)
  • DMZ configuration for Security Server
  • VMware View tags (to route users to specific pools)
  • Protocol port requirements (RDP and PCoIP)

Establish application management

For the purpose of these study notes (as it is a VMware exam) we will only look at ThinApp for application management. ThinApp packages are created as part of the setup capture process. During this process, the application files and registry are combined with administrative settings that are embedded into the final package ready for distribution. As applications are updated and changed, the packages are rebuilt to embed the changes into the package.

Three folders are recommended to be used to house these packages, namely Source, UAT and Production. These folders will act as repositories for ThinApp packages.

The source folder contains project directories created by the ThinApp setup capture. In effect this will be the source code for any packaged application. These directories should be part of a regular backup schedule and should have relevant security added to ensure strict control.

The UAT folder provides an intermediary location to perform testing and QA procedures. To ensure quality testing and real life results the location of the UAT folder should match that of the production folder.

The production folder is the main ThinApp file repository. It should be setup as a read-only file share made available to end users for packages that are run in streaming execution mode. End users run the applications directly form this location. Since this folder is critical and user facing it should be strictly monitored for availability and performance.Clustering/Replication technologies that make the sure highly available are recommended.

Establish OS patching process

When using full clone desktops you will need to manage the desktops individually as you would in a physical world. So products such as SCCM, Shavlik or Altiris should be used. Patch time will need to be planned differently to that of a physical world as all the desktops will reside on a shared infrastructure as opposed to individual compute resources, thus causing potential issues with high I/O and increased CPU requests.

When using linked clones you are able to utilise View composer to manage and patch a set of single images rather than hundreds and thousand of individual desktops. Operating system patches, updates and fixes can be propagated to linked clone desktops in a number of ways.

  • View Recompose – Patch and update the desktop
    • Incorporates a new system image
  • View Refresh – Revert the operating system disk to the base image snapshot
    • Reduces the potential for datastore exhaustion and improves performance
  • View Rebalance – Datastore Capacity Management
    • Add or Remove datastores
    • Redistribute linked clones among datastores

Leave a Reply to Mike Cancel reply

Your email address will not be published. Required fields are marked *