Yesterday VMware has published the latest version (5.1.1) of VMware View.

Resolved Issues in View 5.1.1:

View Administrator

• When the number of View entities managed by one group of View Connection Server instances exceeded 10,000, View Administrator had intermittent problems displaying desktop pools, desktops, and user/group references. The intermittent display problems caused many administrative operations to fail. A View entity can be a desktop pool, desktop, or user/group reference.

View Persona Management

• View Persona Management failed to replicate a user profile that contained very large files to the remote profile repository. The incomplete replication could result in data loss or data corruption in the user profile.

User Profile Management in View

The following resolved issues concern desktop session management by View Agent and View Connection Server. In certain situations, View closed sessions prematurely, affecting user profile synchronization. In View 5.1.1, View Agent and View Connection Server wait for user profile replication to be completed before closing desktop sessions.

• When a user logged off soon after adding a large amount of data to the user profile, View shut down the View desktop before the user profile had finished being replicated to the remote profile repository. The incomplete replication could result in data loss or data corruption in the user profile. This issue is resolved when PCoIP or RDP is used.
• If a user logged off from a View desktop and immediately logged in to a new desktop session within the same pool, user profile data that was created in the new session could not be saved. The user could also lose data that was created in the previous session. This issue applied to desktops running Windows Vista, Windows 7, Windows Server 2008, or later Windows operating system releases.

Link: https://www.vmware.com/support/view51/doc/view-511-release-notes.html

A great article published by Joshua Townsend over at VMtoday.com about a lag when dragging a windows between multi monitors in VMware View. A brilliant read whenever you face those issue in your virtual desktop infrastructure.

Link: http://vmtoday.com/2012/07/lag-when-dragging-a-window-between-monitors-in-vmware-view/

When you have to configure your firewall policies for a VMware View environment it’s sometimes a little bit hard to find a simple overview of all the necessary ports and firewall settings.

To help you doing your job, I provide you here a comprehensive overview of all important communication flows of such an implementation.

This documents is a consolidated aggregation of the information you can find in the following documents:

• VMware View Architecture Planning Guide (View 4.6)
• KB1012382 – TCP and UDP Ports required to access vCenter Server, ESX hosts and other network components

Perimeter Firewall Rules

DMZ Firewall Rules

Connection Server Rules

Transfer Server Rules

View Agent Rules

View Client Rules (internal / without using Security Server)

View Client Rules (external / using Security Server)

HTTP and HTTPS-Traffic can be proxied on the application layer.

Every other protocol should only be proxied using a transparent TCP-/UDP-Proxy.

If you’re running a VMware View proof of concept you might run into an issue which I’ve seen very rarely in the last few years. After a successful installation of all components you’re connecting to a virtual desktop for the first time and everything seems to be fine. You logoff the user and you may login again to your dedicated desktop from a automated pool. But then you spot that you’re getting a new desktop every time you logon to the View Manager. Strange you might think, because you’ve configured a dedicated desktop for the user. In the next step you login to the View Administrator and you check the configuration. It seems to be finde but then you figure out, that you can’t see the session information for a user who’s currently connected to a virtual desktop. I didn’t see this issue for a long time now but today my colleague Kim from the Global Desktop team came to me with it again. I thought it might be worth sharing the information with you so please go on with reading if you’re interested.

As I said, the session information for active sessions to the virtual desktops  is not shown in  the Session tab, which has the same root cause as the issue with the dedicated desktop described above.

The reason for this is a process which is not running, but needed on the virtual desktop. As you know may know there is a software component called the View Agent, which must run on the virtual desktop in order to connect to it via the View Manager/View Client. The View Agent manages loads of tasks on the virtual desktop, i.e. starts the PCoIP server, controls the USB redirection and also sending information about the current status/user to the broker component. And here is the root cause! The user/session information is managed by a process called wssm.exe which is running in the user’s context. This process will be started every time the operating system starts up, by a registry key called userinit.

When everything is ok, you’ll see the wssm.exe process via the Task Manager on your Windows box, if not, you should check the Windows registry key: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit.

Can you see the wssm.exe here? If not, this is your problem. But don’t worry if it is there and it’s still not working. In that case you should check if each entry is separated from each other by a comma. This issue may occur if you’re using software on the virtual desktop which modifies the userinit key. Sysprep for example could do that.

Printing in a VMware View environment does almost look like printing on a physical desktop for the user. For example the user works with some office application and wants to print the document on his local connected Canon iP5300 printer. This is an ink jet printer and it does have some special features integrated with the original Canon printer driver. The user does press the print button and wants to set some properties for printing the document.

Read the rest of this entry »

Back in the days of View 3.0 the USB redirection was done over a virtual channel in the RDP protocol. This changed with View 3.1 as of this release there were a second way of USB data transportation added. You can still use the RDP virtual channels and it is used as a fallback if the preferred option, a TCP connection is not available. The TCP connection is listening on port 32111 in the guest. The configuration can be seen in the virtual desktops Windows Registry at HKLM\Software\VMware, Inc.\VMware VDM\Agent\Configuration\Listener. The parameter FRAMEWORKCHANNEL defines the port number which is 32111 as default. Both connections, the virtual channels and also the TCP connection can be tunnelled via the VMware View Security Server. With the USB Redirection you can use USB device filters on a class, hardware ID a specific device basis. The Registry keys for those are:

HKLM\Software\Vmware, Inc.\VMware VDM\USB\ClassFilters

HKLM\Software\Vmware, Inc.\VMware VDM\USB\ HardwareIDFilters

HKLM\Software\Vmware, Inc.\VMware VDM \USB\AllowHardwareIDs

The format of each entry in HEX is: Vid_xxxx&Pid_xxxx  -> xxxx. If a device is excluded by the class, you can specifically include it again by the hardware ID. The ClassGUID’s and hardware ID’s ca be found in the machine log file on each client.

To learn more about HID devices with VMware View please check one of my older articles. This article also gives you a quick overview of the USB log file entries.

Have a customer that is implementing View4 with PCoIP and dual screens.

They are very happy with the solution except for one thing, performance of Oracle Forms was bad, there was some extra latency when typing and moving between different input fields and they suspected PCoIP and asked if there where some settings to tweak.

After some investigation it turned out to be a problem with the Java version and Oracle Forms in the virtual machine and had nothing to do with the display protocol.

The solution was to start Oracle Forms with this extra parameter:

-Dsun.java2d.noddraw=true

That will tell the JVM not to use direct draw for the 2d rendering required by the Forms client.

A few folks have run into issues with View 4 where PCoIP doesn’t work exactly as they expect. This manifests itself in a couple of different ways:

- Inability to resize the screen at all
- Resizing that only works down instead of up.
- Resizing that responds very slowly or that crashes after several resize attempts.
- Inability to switch between full-screen and windowed.

There are also known issues with the .NET framework, where applications based on this code will not render correctly if it was installed before the View Agent.

The following is a set of steps which will ensure that a pool that you create will have all of the correct PCoIP functionality:

1. Install View4 on a supported platform. (vSphere U1 or VC/ESX 2.5/3.5 U3-U4)
2. Create your VM (Windows XP, Vista or Windows 7)
3. Make sure the VMtools was installed first, then the View Agent and then .NET framework.
   (If any of this was done in the wrong order, or if you don’t know for sure, uninstall all 3, and install from scratch in that order)
4. In View Manager, set this desktop up as an “individual desktop” and entitle it.
5. Make sure you have the PCoIP settings for monitor and max resolution set the way you want them in the pool.
6. Log in once and make sure the basics work.
7. If PCoIP/Screen resizing isn’t already working (VI3.5), logout of the desktop, and use the “reset” option from inside of View Manager.
   (If you rebooted by clicking shutdown>restart in the VM, re-read the previous line.)
8. Log in again and make sure screen resizing works.
9. Shutdown the VM
10. Take a Snapshot
11. Remove the individual VM assignment from View Manager
    (If you don’t do the previous step, it won’t show up as an available parent in the pool creation process.)
12. Create your pool normally and it should work as expected.

PCoIP is very dependent upon the appropriate amount of video memory being allocated to the VM.  Since this is a virtual hardware setting (that needs to be in place before the VM starts up), it is applied as a change in the VMX file.   If the VM has already been started, it’s essential that this VM be restarted so that the VMX file is re-read and the changes are used.   Simply using “Shutdown>Restart” inside the VM will not force the VMX to be re-read, as this doesn’t cold boot the machine (from the VC perspective) to refresh the virtual hardware.

Using the Shutdown/Reset from either VC or View Manager (which issues the command via VC) is the best way to make sure this file gets read properly.

Once the appropriate video memory settings are in place for your parent VM, you can create a pool based on this VM and machines in that pool will properly inherit these VMX settings on first boot.

(Kudos to my colleague Todd Dayton who wrote all this down!)

// Joel

VMware View 4 with vSphere for Desktops is the leading desktop virtualization solution on the market. It includes several of new features but the main highlight is the software PCoIP integration which offers a great user experience on LAN and WAN networks. See this article for the complete new feature list.

Read the rest of this entry »

Finally its here, View4 is now available for download:

https://www.vmware.com/tryvmware/p/download.php?p=view4&lp=1

Release notes are here:

https://www.vmware.com/support/view40/doc/releasenotes_viewmanager40.html