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

VMware View 3.1.2 download

Release notes

What’s New in View Manager 3.1.2

VMware View Manager 3.1.2 is a maintenance release that resolves some known issues in the previous releases. Refer the Resolved Issues section for more details.

This release also includes one new feature.
Virtual Printing Multi Session Support

In this release, the virtual printing (ThinPrint) feature is updated to provide support to the users connected to multiple virtual desktops. With this update, the ThinPrint client enables users to map the printers on each virtual desktop that you are connected to.

Resolved Issues

The resolved issues are grouped as follows:

* Install and Upgrade
* View Administrator
* View Client
* View Composer
* Miscellaneous

Install and Upgrade

* When creating and preparing the guest system, you must install View Agent, after all other third-party applications are installed. If you uninstall View Agent after installing additional third-party applications, certain registry entries for the third-party applications might be lost. After installing View Agent, if you want to install additional third-party applications on the guest, you must first uninstall the View Agent. Applications known to be affected by the installation order include Microsoft AppV, vmSight ConnectorID, and Citrix XenApp.
This issue is resolved in this release.
* Effect of stopping VMwareVDMDS service on View 3.1 upgrade (KB 1012990)
* Upgrading View 3.1 to 3.1.1 clears View Connection Server settings from LDAP (KB 1013300)

View Administrator

* On rare occasions, View Administrator might display IllegalStateException errors (KB 1011392)
* View displays incorrect backup-time of View server (KB 1011390).

View Client

Desktop connections become slow when a View Client is running in a Citrix ICA session
When you connect virtual desktops using a View Client that is running in a Citrix ICA session, the virtual desktop connections are very slow compared to the connections using native RDP (mstsc.exe). This issue occurs because when the View Client runs in full-screen mode, it does not use the native full-screen mode of RDP ActiveX controls, and non full-screen mode does not function properly with Citrix ICA session.
This issue is resolved in this release.
View Composer

* View fails to automatically delete virtual machines in a multi-broker environment

In a multi-broker environment, when the Power off and delete virtual machine after first use option is enabled for non persistent pool, and many users log out of the virtual machines at the same time, View Manager sometimes fails to delete the virtual machines due to a race condition.
The issue is resolved in this release.
* View takes more time to delete virtual machines from a non-persistent pool if you enable Power off and delete virtual machine after first use (KB 1013760)
Miscellaneous

* If the Power off and delete virtual machine after first use option is enabled, virtual machines in non-persistent pools are disabled when accessed through direct Windows RDP/VI Client
When an administrator accesses a virtual machine through a direct Windows RDP client or VI Client console and then logs out, View Agent disables the virtual machine. Due to this issue, the virtual machine becomes inaccessible, and the number of unusable virtual machines in the desktop pool increases. When a desktop user tries to log in to that pool using View Client or Web Access, the following message might appear on the Connection Server even if some of the virtual machines in that desktop pool is in a Ready state:
All connections are busy, please try again
This issue occurs when you use RDP to access a virtual machine on which the Power off and delete virtual machine after first use option is enabled.
The issue is resolved in this release.
* In full-screen mode Windows special key combinations are not redirected to virtual desktops
In full-screen mode, View Client does not redirect Windows special key combinations (Windows+<Key>) to the remote desktop. This issue is inconsistent with the direct RDP.
The issue is resolved in this release.
* The vdmadmin.exe -L option does not remove existing pool assignments (KB 1008838)
* Each time a user logs in to a virtual machine that is deployed from a template on which the View 3.1 Agent is installed, a Windows Explorer window opens in the host machine.
This issue is resolved in this release.
* Network vulnerability scan shows View Manager accepting weak cipher
A network vulnerability scan shows that a pair of weak cipher-suites are being accepted by View Connection Servers. The two weak cipher-suites are now excluded from the list of enabled cipher-suites.

VMware just released the Version 3.1.1, a new maintenance release of VMware View. You’ll find the details on the VMware View web site.

Read the rest of this entry »