5.1
Table Of Contents
- VMware View Architecture Planning
- Contents
- VMware View Architecture Planning
- Introduction to VMware View
- Planning a Rich User Experience
- Feature Support Matrix
- Choosing a Display Protocol
- Using View Persona Management to Retain User Data and Settings
- Benefits of Using View Desktops in Local Mode
- Accessing USB Devices Connected to a Local Computer
- Printing from a View Desktop
- Streaming Multimedia to a View Desktop
- Using Single Sign-On for Logging In to a View Desktop
- Using Multiple Monitors with a View Desktop
- Managing Desktop Pools from a Central Location
- Architecture Design Elements and Planning Guidelines
- Virtual Machine Requirements
- VMware View ESX/ESXi Node
- Desktop Pools for Specific Types of Workers
- Desktop Virtual Machine Configuration
- vCenter and View Composer Virtual Machine Configuration and Desktop Pool Maximums
- View Connection Server Maximums and Virtual Machine Configuration
- View Transfer Server Virtual Machine Configuration and Storage
- vSphere Clusters
- VMware View Building Blocks
- VMware View Pod
- Planning for Security Features
- Understanding Client Connections
- Choosing a User Authentication Method
- Restricting View Desktop Access
- Using Group Policy Settings to Secure View Desktops
- Implementing Best Practices to Secure Client Systems
- Assigning Administrator Roles
- Preparing to Use a Security Server
- Understanding VMware View Communications Protocols
- Overview of Steps to Setting Up a VMware View Environment
- Index
To configure a remote repository to store personas, you can use either a network share or an existing Active
Directory user profile path that you configured for Windows roaming profiles. The network share can be a
folder on a server, a network-attached storage (NAS) device, or a network server. To support a large View
deployment, you can configure separate repositories for different desktop pools.
With View 5.1 and later, you can install a standalone version of View Persona Management on physical
computers and virtual machines that are not managed by View, allowing you to accomplish these goals:
n
Share and manage profiles across standalone systems and View desktops.
n
Migrate user profiles from physical systems to View desktops.
n
Perform a staged migration from physical systems to View desktops.
n
Support up-to-date profiles when users go offline.
Limitations
View Persona Management has the following limitations and restrictions:
n
You must have a View license that includes the View Personal Management component.
n
View Persona Management requires a CIFS (Common Internet File System) share.
n
You cannot use View Persona Management with desktops that run in local mode.
n
A user cannot access the same profile if the user switches between desktops that have v1 user profiles and
v2 user profiles. However, redirected folders can be shared between v1 and v2 profiles. Windows XP uses
v1 profiles. Windows Vista and Windows 7 use v2 profiles.
Benefits of Using View Desktops in Local Mode
With View Client with Local Mode, users can check out and download a View desktop to a local system such
as a laptop. Administrators can manage these local View desktops by setting policies for the frequency of
backups and contact with the server, access to USB devices, and permission to check in desktops.
For employees at remote offices with poor network connections, applications run faster on a local View desktop
than on a remote desktop. Also, users can use the local version of the desktop with or without a network
connection.
If a network connection is present on the client system, the desktop that is checked out continues to
communicate with View Connection Server to provide policy updates, and ensure that locally cached
authentication criteria is current. By default, contact is attempted every 6 minutes.
View desktops in local mode behave in the same way as their remote desktop equivalents, yet can take
advantage of local resources. Latency is eliminated, and performance is enhanced. Users can disconnect from
their local View desktop and log in again without connecting to the View Connection Server. After network
access is restored, or when the user is ready, the checked-out virtual machine can be backed up, rolled back,
or checked in.
Local resource
utilization
After a local desktop is checked out, it can take advantage of the memory and
CPU capabilities of the local system. For example, memory available beyond
what is required for the host and guest operating systems is usually split
between the host and the local View desktop, regardless of the memory settings
that are specified for the virtual machine in vCenter Server. Similarly, the local
View desktop can automatically use up to two CPUs available on the local
system, and you can configure the local desktop to use up to four CPUs.
Chapter 2 Planning a Rich User Experience
VMware, Inc. 23