This is a minor release that includes:

* Support for secure PCoIP tunneling

* Over 160 bug fixes

* Improvements in using Windows 7 SP1 RC as a remote desktop OS

* Better keyboard mapping support

* Enhanced USB device compatibility

This release will be available as a free upgrade to customers with a currently active VMware View support and subscription contract. Please refer to the release notes for vSphere and View compatibility guidelines.

VMware View 4.6.0 client code will available for download at the Partner Central web portal on 2/24/2011.

Source for this was at http://www.sbcprojects.com/news/73-vmware-view-46-to-be-released.html

Unfortunately, a high available configuration to access VMware View while being outside the corporate network can be very different between organizations. I have been doing some research reading the VMware VDM 2 Load Balancing Guide to find out more about load balancing and secure remote access. In today’s enterprise environments, gateway devices like Citrix Netscaler/Access Gateway or Cisco ASA are more or less common practice. They are configured as a mandatory termination point for sessions originating from outside the corporate network connecting to resources inside the corporate network.

Initially, two http sessions are set up between the client and the Connection Servers to which the load balancer redirected the client request. One session is for communication with the web page, the View Portal, and one is for the RDP connection that can be configured to be packed into http or https. By default, a Connection Server replies to the client http request with a response in which its own hostname is sent back to the client. Using the default configuration of a Connection Server would then result in having to open up the necessary ports on the firewalls between the Gateway device and all Connection servers as the client will try to communicate directly with the Connection Server once it received the Connection Servers’ hostname in the http response. In the configuration page of the View Administrator however, you can modify the default behavior by configuring an ‘External URL’ that will be given back to the client. The External URL will have to be configured on each Connection Server that you have.

Picture 16 – Part of the screen that appears when clicking a Connection Server and choosing ‘Edit’.

An External URL can be configured and also a direct connection to desktops, resulting in bypassing the Connection Server for direct communication with the virtual machine that a user needs. If you configure the External URL to be the DNS name of the load balancer, you will have two moments on which load balancing will take place; initially to set up the communication to the View Portal, and subsequently, if a session to a Virtual Machine is started.

According to VMware in the Load Balancing Guide, for proper load balancing to work the load balancer needs to be configured for SSL Offloading. SSL Offloading is necessary because a load balancer cannot see what’s inside an SSL request. All requests are coming from one Gateway device, which means that all the load would go to the initially chosen Connection Server. Also, sticky sessions need to be configured on the load balancer to support RDP connections over http. This means that SSL connections can be setup to the load balancer, but the load balancer will strip off the encryption and forward the requests to the Connection Servers as http. This actually means that communication from the load balancer to a Connection Server is going over HTTP where, for example, a cookie insert by the load balancing device will result in being able to provide RDP sessions consistently going to the same Connection Server

1. This also means two more things:
2. Username and password are passed to the Connection Server in clear text between the load balancing device and the Connection Server.

As the Connection Server is configured for http and not https, the RDP sessions will be packed in http as well. This might not be a problem because the connection from the internet to the Gateway device is already tunneled in https, but I wanted to point that out anyway.

Compared with Citrix Web Interface, where integrated logon with Kerberos authentication is an option, this seems like an issue that VMware could address better. Also to get a Cisco ASA to work, probably a View Plugin for ASA would be a GREAT idea…

Server Provisioning

When I made the comparison of View 3.0 with Citrix Provisioning Server, I wondered how View 3.0 could be used to deploy Terminal Servers or even Citrix Servers. The official line from VMware says that only Desktop Operating Systems are supported. I tried it for myself and, indeed, a Virtual Server with a snapshot and a View Agent installed is not ‘discovered’ in a desktop pool deployment wizard. Too bad, because a tool for cloning Citrix servers, like the one from CitrixTools.net could do a good job here, handling all Citrix specific services and settings with Sysprep being used by Virtual Center to deploy uniquely identifiably virtual machines. Active Directory policies could be adjusted to make all this work without further administrative interaction.

Maybe I’m going too far here comparing View with XenDesktop/Provisioning Server? I see a lot of similarity between the two products, even though entirely different techniques are used. I might say that putting OS changes in a ‘memory state cache’ as Provisioning Server does is a more elegant solution than creating and deleting snapshots, but the result can be the same; Instantly provisioned machines that are deleted as soon as they reboot.

Machine Account password

A virtual machine with a snapshot can only be used by View 3.0 (or probably VMware ESX) as a master image if the machine is joined to a domain. For this reason, I would apply the same local policy as I would normally do with a sequencing or packaging machine, and then disable Windows machine account password resets. If your company policy or personal preference requires machine account password changes, you can change the default ‘change password interval’ to the maximum of 999 days. Both of these options can be changed in the Group Policy editor:

Start/run/gpedit.msc >

Computer configuration/Windows settings/Security settings/local policies/Security options:

- Domain member: Disable machine account password changes – enabled

- Domain member: Maximum machine account password age – 999 days

Display Protocol

I have to mention that I was at least a little disappointed when I noticed that nothing was done about optimizing RDP. It is especially important if you plan to deploy Windows XP, which probably has the worst version of RDP still available, and you have to provide desktops to users over high latency connections. I must admit that I haven’t yet tested performance using RDP with a typical Indian latency of (so the story goes) up to 300 milliseconds, but I can image implementations being cancelled because of this shortcoming. The Group Policy Administrative Templates provided with View will really be necessary to optimize RDP as far as possible, but of course the advanced options available in ICA are really an entirely different story.

In the Reference Architecture Kit on the VMware site, VMware actually acknowledges this problem by stating that RDP is a good protocol for LAN connections or WAN connections with up to 150 ms latency. If you have to provide virtual desktops over high latency connections however, using RDP might not be a good idea. VMware mentions solutions like Sun Microsystems’ Appliance Link Protocol™ (ALP) used in Sun Ray™ thin client implementations and Pano Logic’s Console Direct, but getting into those is out of the scope of this document. I did find a network tool that can configure latency up to 400 ms, so I will test this in the near future.

Sizing

Also in the Reference Architecture Kit, a setup is described for separate ESX clusters for VDI. For my customer, I will also use separate ESX clusters. Although, since clusters cannot contain more than 8 nodes, my customer will have to change from their standard cluster configuration of 13 hosts per cluster. I found that approximately 17 power users can be placed on a machine with two quad core CPU’s and 24 Gb of memory. Because of the memory sharing feature, ESX even promises to be the best option on which to run VDI environments, as other hypervisors do not support memory sharing. I plan to use the same Virtual Center that I already have running for my server environment, which already is one of the largest in Europe. However I will probably have to keep a close eye on performance, as Virtual Center probably also has its limits.

User experience monitoring

When you are planning to use VMware View, I recommend looking at ‘User Experience Monitoring’ products. Products from eG Innovations and RTO PinPoint can provide valuable information on both frond end and back end performance, giving you great insight in what delay is caused where. Implementing that could save you a lot of time in the end.

A final word or two…

VMware did a good job with View 3.0. They put all configuration options for the View 3.0 product into one console, which is really excellent work. The console is intuitive and fast. Options are logically grouped and put into only four distinct console windows. The new linked clone technology is probably a bit harder to understand as consequences for disk space usage are not properly documented by VMware. (Linked clones were covered in Part 2 of this article series)

The term ‘persistent desktop’ needs some explanation because it can be misunderstood as a desktop for power users – like a dedicated desktop. In actuality, it means that all the desktops are kept in a consistent state by the administrator, which is certainly not a “power user” type desktop.

Furthermore, most essential options are available; universal printing, single sign-on, instant and automatic desktop creation, even the experimental ´offline desktop feature´ can be used. Unfortunately, optimizations on the RDP protocol are lacking, which in some cases might result in unworkable situations because of network latency. Customers using VMware ESX could strategically choose for View 3.0 because of the tight integration with Virtual Infrastructure. With the Premier license bundles that also includes ThinApp/Thinstall, the combination makes for a promising offering in the VDI market. I wonder what VMware´s next move will be.

Useful links

VMware VDM 2 Load Balancing Guide

Administration Guide – View Manager 3.0

VMware View Reference Architecture Kit

The big question to most people is probably: ‘What are linked clones and how do they work?’. Some of you may expect similar functionality to Citrix Provisioning Server where optimization in disk space can be significantly realized, and indeed VMware does somewhat the same, but with very different technology. Let’s see how VMware does it.

The essence of linked clones is Thin Provisioning; saving on expensive storage cost. Thin provisioning with View 3.0 can be realized using a “master virtual machine”, which is just a regular virtual machine that you create and then take a snapshot. That virtual machine will be used as the basis for rapid and thin OS deployment. Please notice that I mentioned a virtual machine “snapshot”, not a virtual machine “template”.

You prepare a virtual machine with the Desktop OS of your choice (Server Operating Systems are not supported) exactly the way that you like your master image to be. When all components and settings are properly set, you then have to install the VMware View Agent (which contains the components mentioned in the previous article), shut down the virtual machine and take a (first) snapshot. I might add that the master virtual machine has to be domain joined, for which I could not find the reason. After that, desktop deployment can start.

In the View Administrator console, choose the ‘Desktops and Pools’, as this is where desktops and desktop pools can be added and/or edited. In the right pane of the ‘Desktops and Pools’ tab, five other tabs appear, the most left being the ‘Desktops and Pools’ view. Here you can choose ‘Add’ to start a wizard that guides you through the steps necessary for adding a desktop or a desktop pool. The following choices are presented:

• Individual Desktop, this option will start a wizard to provide users with access to a single virtual or physical computer on which the View Agent is installed.
• Automated Desktop Pool, this option starts a wizard to automatically create one or more desktops in a pool. The explanatory text for this option states that desktops are based on “virtual machine templates,” which is wrong.  You need to have a normal virtual machine from which you will take a snapshot (as mentioned above). 
• Manual Desktop Pool, this option will start a wizard to provide access to an existing set of virtual or physical PC’s that have the View Agent installed.
• Microsoft Terminal Services Desktop Pool, this option starts a wizard to publish Terminal Server desktops to View Portal users.

I don’t want to get into details with every option mentioned, but continue with the most eye catching option, the Automated Desktop Pool. The automated desktop pool can consist of any number of persistent or non-persistent desktops.

After a persistent desktop pool is created and a user is assigned a certain desktop, the mapping between user and assigned desktop is written to the ADAM database (see Part 1 for more information on how ADAM is used). Every time the user logs on to the View Portal, the same desktop will be available and the state of the virtual machine is exactly the way he or she left it with the previous logoff. This option is similar to the ‘permanent disk’ in Citrix Provisioning Server. A persistent desktop pool can contain any number of desktops, and once created, the pool can also be edited to increase the number of desktops in the pool. In the wizard, as depicted below, the initial number of desktops to be created is set to 5, the total number of desktops in the pool is set to 100 and as soon as the number of available desktops falls below 5, the number of available desktops is matched to meet the configured criteria by creating more machines in the pool, until the maximum number of desktops in the pool is reached.

Picture 6 – Advanced configuration of the number of desktops in a pool in the Deployment Wizard

Both persistent and non persistent desktops can be created using the ‘linked clone’ technology, which in fact means that deployed desktops can be altered by assigning the desktops to a different snapshot or even to an entirely different virtual machine. The main difference between a persistent and a non persistent desktop is that persistent desktops can contain a second virtual disk to which the ‘Documents and settings’ folder is moved. User data is effectively put on another disk, so in case an administrator decides to assign a different snapshot or image to a user, all user data in the ‘Documents and Settings’ folder will still be available. Of course, this can also be accomplished by modifying the User Shell Folders of each user with Active Directory GPO or script to alter all default folders, but with the View 3.0 option, user data will be locally available, presumably resulting in better performance.

I wonder if this is really a useful option, as user data can only be reached by going to the machine itself and opening the folder, whereas with folder redirection, all user data can be redirected to a central network share, substantially simplifying central administration, in my opinion. If the central network share is located on fast NAS heads, performance might still decrease a little, but management of user data only locally available on virtual machines is not a very attractive option in larger environments.

Picture 7 – A separate disk for personal data, available in a linked clone.

What actually happens as the wizard is finished is that a copy of the master virtual machine is made, together with a copy of the snapshot. The size of the copies, however, is not a complete copy of the master virtual machine. I deployed a master image with a system drive of 20 GB with a snapshot, which resulted in a copy of 6 GB for the system drive and a few Kb for the snapshot.

Picture 8 – User data drive of a persistent desktop for a specific user.

The folders and disks are automatically created and the folders and files contain some GUID that is associated with master desktop and user.

To (hopefully) clarify the components, the following Virtual Center folder arrangement is depicted:

.jpg”>

Picture 9 – Virtual Center containing all folders necessary for a View 3.0 deployment.

The above picture shows that

• VMware virtual machine templates can be used to deploy master images
• Master images with at least one snapshot are best placed in a separate folder to make sure you don’t mix things up
• Linked Clones are best placed in a separate folder, where subfolders can be created to place non persistent and persistent linked clones
• You can (and probably will) have other virtual pc’s or virtual servers in your Virtual Center
• On the bottom of Picture 9 the automatically generated folders are shown, which are all created by View 3.0 as a result of a desktop pool deployment wizard in the View Administrator console. A replica folder and a source folder are created for each desktop pool that uses linked clone technology. All folders created automatically are fully managed by View 3.0 and are only to be administered through the View Administrator console.

Linked Clone disk characteristics

So, how does View 3.0 handle disks and disk space for linked clones?

In my tests I created a Windows XP SP2 image with a system drive of 20 GB. In the Automated desktop pool wizard, I chose to configure 5 linked clones, where initially 1 linked clone was created immediately after finishing the wizard, and where always 1 desktop would be available for new user logon until the maximum number of desktops in the pool has been reached. Also I chose to create a separate User data disk of 2 GB for the ‘Documents and Settings’ folder to be placed.

Picture 10 – Step in deployment wizard where OS Data and User Data stores can be selected with.

After finishing the wizard, a replica folder and a source folder are created which are used as templates, of which clones are created by View 3.0

Picture 11 – Replica folder of an automated, persistent desktop pool, derived from a 20 GB system disk

Picture 12 – Source folder of an automated, persistent desktop pool with a configured user data disk of 2 GB

Picture 13 – System disk of a linked clone, available to an end user using a system disk of 20 GB

Picture 14 – User data disks, mapped as D-drive in the users’ virtual desktop, for two users with a maximum of 2 GB per user

In the table below, all components are mentioned to deploy at least one desktop pool based on one Desktop Operating System. The ‘linked clone system disk’ will initially be around 100 MB and can grow up to the original size of the Master VM. A Desktop Refresh (discussed below) can be scheduled or executed manually to return the linked clone system disks to its’ original size.

Table 2 – Linked Clone disk size example

Desktop recompose, refresh, rebalance

At all times, deployed desktops can be altered when created using the linked clone technology.

A Desktop Recompose means that a deployed desktop state is altered. It can be assigned a different snapshot of possibly even entirely an different master virtual machine.

A Desktop Refresh means that a linked clone desktop is brought back to the state of initial roll out. This actually means that the system disk is reverted to the moment it was deployed, including its size and contents. If a separate user disk was used in the deployment wizard, all user data on that disk remains intact.

A Desktop Rebalance means balancing virtual machine disks across available data stores (LUN’s). If a VMware ESX data reaches its capacity, a rebalance can take care of automatic data migration of deployed virtual machine disks to different ESX data stores.

Picture 15 – View on a persistent desktop in the ‘Persistent’ desktop pool, which can be removed, reset (OS reset), edited (recomposed or refreshed) or rebalanced

Linked clones, persistent desktops and OS maintenance; 1 + 1 + 1 = 1?

Another thought came to mind worth mentioning. In my test I created a desktop pool with the combined technologies of linked clones and persistent desktops. Of course on these desktops, I do have to perform maintenance, as Microsoft hotfixes come out the second Tuesday of the month and who knows what else needs to be updated. Initially I thought I could use the linked clone technology for this; update my master virtual machine with hotfixes, take a new snapshot and link all deployed desktop to the new snapshot. If all is well this will work, however, what happens to my ‘persistent desktops’ if I do that? In fact, all users having made changes to the OS (I chose to allow certain users to install their own applications) lose their OS customizations and their applications.

After linking desktops to a new snapshot, it appears that the only thing that is really persistent about the ‘persistent desktop’ is what is on the user data disk, which contains the ‘documents and settings folder’ and maybe some data, but not the entire installed application the user needed. Ergo, if I want to maintain my OS with hotfixes using linked clone technology or ‘Desktop Recompose’, while at the same time keeping users’ customizations to the OS, I will have to use a tool like SMS/SCCM, Radia or whatever your standard corporate application distribution method is. My question then is: what does ‘Persistent Desktop’ really mean?

I performed one more test to see how intelligent the linked clone snapshotting technology really is when it comes to managing disk space. I started off with a Persistent Desktop:

- System disk: 230 MB

After I logged on as an administrative user, I copied an installation of Eclipse, sized 354 MB, to the System disk of my virtual machine.After the file copy, my System disk looked like this:

- System disk: 607 MB

I decided to delete the Eclipse folder. After deletion, the system disk looked like this:

- System disk: 607 MB

Conclusion: The Eclipse folder doesn’t seem to be deleted and the data is still available in the snapshot.

I decided to copy the exact same Eclipse folder again to the same destination on the system disk, which then looked like this (I also tested another destination; c:\temp, which had the same result):

- System disk: 623 MB

Apparently, some check was done as the linked clone disk reused the data that was marked as ‘deleted’.

After I removed Eclipse again, the system disk looked like this:

- System disk: 640 MB

Now since Eclipse is deleted off disk and the system disk still has the size of 640 MB, which means the data is still there, maybe the snapshot technology is intelligent enough to mark the space as deleted so it can be filled up with other data. I copy some other data to the system disk that is smaller than the size of the data that could be ‘marked for deletion’. After copying a 219 MB folder, the disk looks like this:

- System disk: 852 MB

Conclusions:

1. Providing linked clones to users that have full control to the system, resulting in user initiated changes to the OS like copying data, removing it, etc., will end up in a system disk that eventually has a bigger size than if the OS was provided to the user without the linked cloning technology.
2. If a View Administrator decided to refresh the OS because he added some hotfixes or extra software, all user modifications to the OS are deleted. In fact the System Disk is simply deleted and a new linked clone is generated off the new state of the ‘master image’.
3. What ‘Persistent desktop’ actually means is that the state of a disk provided by a View Administrator is ‘persistent’. A desktop can be made persistent by recomposing or (scheduled) refreshing the deployed linked clones, resulting in exactly the state that a View Administrators expects it to be. From the view of end users using Linked Cloned Desktops, no persistence can actually be guaranteed, because all user actions will be undone by ‘Desktop Refresh’ or ‘Desktop Recompose’.
4. As soon as user modifications to the System Disk need to be persistent, no linked clone technology should be used. Instead, 1-on-1 desktops need to be provided, in which deployment tools like SCCM or Altiris will have to be available to maintain the system.

Early December 2008, VMware released their new product for the VDI market, VMware View 3.0. As a rather substantial update to the former version, VMware VDM 2.0, apparently the product name also had to undergo a change to underline the differences between the new product and its predecessor. In this article I will discuss the (new) features in View 3.0 and the way they work. I will first describe the components on which the product is based. Then I will focus on the different deployment types possible with View 3.0 and what happens during and after deploying different types of ‘desktop pools’.

My experience with the new product is mainly based on an implementation that I did for a customer, who had a specific use case to provide desktop operating systems to developers around the globe. I will sometimes refer to other use cases as there are quite a few, however perhaps the biggest question that everyone probably has will remain unanswered, as the technology that makes up VDI is still developing. Where we can speak of an accepted and well known technology like Citrix XenApp, VDI is not nearly there yet. The question of how VDI will result in better return on investment than desktop deployment methods being used for many years now is not clear. It all depends on use cases and things like high availability requirements and hardware cost. Financial differences and justifications for using VDI or a traditional desktop model are not discussed in this article.

Let’s first start with a description that VMware uses to describe the product and take it from there.

VMware describes View 3.0 as follows:

‘The Next Generation of VDI, delivering rich, personalized desktops to any device with all benefits of centralized management’.

View 3.0 was created using different technologies that are found in other VMware products. Examples of technology used in View 3.0 include snapshotting as seen in VMware Workstation (see picture 1); VMware OS cloning as used in ESX; and Tomcat is used for the Web based administration console, which we have seen before in the free VMware Server product (including the “self-signed, untrusted certificates” ‘feature,’ which is enabled by default .

Managing View 3.0 is fairly straightforward. It is quite easy to use once you are accustomed to the components and terminology used with this product. Troubleshooting might turn out different, so let’s hope this product is as stable as should be.

Picture 1 – Snapshotting in VMware Workstation

VMware View 3.0 only supports VMware Infrastructure and is not a hypervisor-independent product. In fact, due to the new technologies that were added to View 3.0, it also imposes some requirements to the Virtual Infrastructure you are using. Before installing the first bit of View 3.0, you should check the version you are running on. View 3.0 is supported starting with VMware Infrastructure 3.02, however VI 3.5 u3 is recommended since linked clones are supported, which is probably the part raising most questions but also promising the best use cases. Both ESX 3.5 as ESX 3.5i can be used for View 3.0.

Components and terminology

Although setting up View 3.0 in fact can be quite straightforward, at first I found it difficult to figure out which components were doing what, communicating where, and for what purpose. I will try to explain the product by naming and describing all of the important components and terms used in the product.

View Connection Server

A connection server is a server acting as desktop broker. It facilitates two web sites; one for users that want to access a virtual desktop and one for administrators managing the View 3.0 environment. The Connection Server communicates with Active directory and maps Active Directory users and groups to virtual desktops and desktop pools. This information, together with configuration data, is stored in a local LDAP database, for which VMware decided to use ADAM (Active Directory Application Mode). The ADAM database can be viewed through the locally installed ADAM AdsiEdit.

Although the choice for ADAM as a database seems a good choice, unfortunately this also causes confusion, as with ADAM, a second LDAP database is introduced next to Active Directory. Confusion can arise when looking at the log messages in the Event log of the View Administrator console, where sometimes errors point to the ADAM LDAP database, while the actual error might be caused in communication towards Active Directory or vice versa.

When the Connection Server software is installed, the ‘VMware View Connection Server’ service is added, running under ‘local system’.

View Replica Server

The installation package for the Connection Server also contains the installation source for the ‘View Replica Server’. A View Replica Server is a Connection Server with its own replica of the ADAM database stored locally. All configuration data and changes are instantaneously replicated to all replica servers, resulting in entirely independent Connection Servers, being able to act on their own in case of failure of other replica servers.

View Security Server

The installation package for the Connection Server also contains the installation source for a ‘View Security Server’. A View Security Server acts somewhat like a Citrix Secure Gateway Server (the free software version) and is typically placed in a DMZ. Installation is very straightforward and the only important thing to configure is a 1-on-1 connection to a View Connection Server. After having connected a Security Server to a Connection Server, all instances of all Connection Servers are added to the configuration of the Security Server, not introducing awkward availability situations where a Security Server is available but its attached Connection Server is not. No ADAM database is stored locally and in fact the Security Server only function is to tunnel communication from the outside world users to the internal Connection servers over SSL. By simply entering the hostname of the security server in a web browser, the View Portal page is displayed, which actually is the View Portal page of a connection server.

View Portal

View Portal is the web page that facilitates users in accessing their desktops and is run on the Connection Server. After pointing a web browser to https://connectionservername, a logon screen appears in which all domains are available that are trusted by the domain to which the Connection Server was added. View Portal is the default web page on each Connection Server and is secured with self-signed certificates out of the box. Unfortunately with View 3.0, access to the View Portal is still not possible from Windows Server 2003 R2 machines, as was the case with VDM 2. Surprisingly enough, it is possible to access virtual desktops from Windows Server 2003, but only with the View Client software installed.

View Administrator/View Manager

The console from which all View management can be done, like View configuration, desktop deployment, user session management and log event viewing has in fact two names; ‘View Administrator’ and ‘View Manager’, as can be seen when the web based console is started. To start managing View 3.0, point a web browser to https://servername.domain/admin. Make sure you read that correctly; it is NOT https://servername.domain/adm, a little something that could eat you up for awhile if you don’t pay attention . View configuration is done from one console that contains all possible configuration settings; a relief if you are accustomed to the different consoles that Citrix offers with their VDI product (see picture 2). Licenses, the connection to the Virtual Center server(s) and the account to perform all necessary actions in Virtual Center, the accounts to use that have permissions to add computer accounts in Active Directory, smart card support, a current usage overview, session timeout settings, SSL communication to the broker, login messages and more, it can all be accomplished using this one console which is even conveniently arranged. Hurray for VMware!

Perhaps a disadvantage would be that no real delegation of control can be configured; either you are a View administrator or you are not. No room for user session management only, or permissions to only modify specific desktops or pools; one down for VMware…

The four tabs in the administration console are:

• Desktops and Pools – An overview of all desktop pools and other resources like Terminal Severs or bare metal pc’s, which can also be offered to users if the View Agent is installed. If the tab for Desktops and Pools is selected, sub windows appear on which all active sessions, accessible desktops, offline desktops and desktop policies can be viewed and managed.
• Users and Groups – An overview of desktop entitlements to Active Directory users and groups
• Configuration – All configuration for View 3.0 can be done here as mentioned before
• Events – All events about desktop pool creation, desktop refresh etc. Events can be searched and filtered on number of days through the always-good-to-know symbol that VMware uses to show that more options are available: the triangle which looks like this:

Picture 2 – VMware View Administrator, configuration tab

Picture 3 – An view on the ‘Desktops and Pools’ tab in the View Administrator console, showing two desktop pools; one non persistent, one persistent

View Composer

View composer is a separate piece of software that has to be installed on the Virtual Center server if you want to use linked clones. Prior to doing that, a database needs to be created for which I used an MS SQL 2005 database, but SQL Express is also supported. You might consider using a separate account for the View Composer to run under, however I used the Active Directory Service account that Virtual Center is running under and granted the account dbowner rights on the LinkedClones database.

While installing the View Composer software, the ‘VMware View Composer’ service is added as a Windows Service, however I could not finish the installation until I changed the logon credentials to run under the same account that ‘VMware Virtual Center Server’ service is running on. In the Administrators’ guide for View Manager 3.0, page 104 or in Table 1 below, you can see exactly which permissions are needed for View Composer to work.

Table 1 - View Composer Account – Minimal Privileges in Virtual Center

View Agent

View Agent is the component that you install inside the virtual machine that you want to use as a master VM. With the machine that you decide to make the ‘Master Virtual Machine’, you can deploy other virtual machines that are cloned from the Master VM. The VMware view agent consists of the following components:

Picture 4 – Custom setup window of the View agent which is installed on the master VM

· VDM Secure Authentication – This feature will install a piece of software that handles single sign-on. A user has to enter his credentials either on the View Portal or in the View Agent that is installed locally on his computer, and these credentials can be passed to the virtual desktop provided by View 3.0. This works in conjunction with the View Client, in which you can configure to use SSL for your communication or not.

· USB Redirection – This feature handles connections from the clients’ desktop USB devices to the virtual machine. I’ve already found out that HP USB keyboards with integrated smart card readers are not supported and requested an update for that particular device. There are probably more devices that are not yet supported, so make sure you test the devices that you might plan to use in your company’s View 3.0 future.

· VMware View Composer Agent – This feature needs to be installed if you plan to use linked clones, more on that in Part 2 of this article.

· Virtual Printing – This feature installs ThinPrint universal printing software. I found version 7.8.0.3 of the ThinPrint Output Gateway, dated 07/12/2007 and version 1.0.0.11 of the PostScript driver, which is more recent, dating from 6/18/2008. I concluded that with advanced multi-functional devices, not all options like stapling your papers are supported, in contrast to the Citrix Universal Printer driver, in which you can open the client devices’ local printer properties window and access all options available in the native client driver. However, most options like paper size, orientation and duplex printing are available with the Virtual Printing feature.

View Client

View client is the component that end users have to install on their own system. With this client, USB redirection and single sign-on are supported. The View client installation package is automatically pushed if users having logged on to View Portal do not have the Client installed. The installation is straightforward, but unfortunately not available as web plug-in, so administrative permissions are required for the end user to install it. The view agent looks a bit like the regular RDP client from Microsoft; you start the client, enter the connection server that you want to logon to and after successful authentication, available resources are displayed in the View Client (see picture 5).

Picture 5 – Logon screens of the View Client, which needs to be installed on the client pc of end users.

Part 2 will be released in the next few days and cover Linked Clones.  Part 3, available early next week, will discuss VMware View 3 best practices.