VMware Horizon View Network Ports Illustrated pt. 2

As Carl pointed out, I left HTML Access (aka Blast) off of the first round of View network port diagrams.  So after going through the documents and making various connections while running TCPView, here’s the updated diagrams including the networks ports used by HTML Access and the Blast Secure Gateway.

Here’s the PDF

HTML Access & Blast Secure Gateway without Security Server
HTML Access Direct Connect without Security Server
HTML Access & Blast Secure Gateway with Security Server
HTML Access & Blast Secure Gateway with Security Server

Eww, curved, intersecting lines.

Once again, here’s the PDF


VMware Horizon View Network Ports Illustrated

I’ve recently had to attempt to describe the ports used in the various connection scenarios used by VMware View and found that a diagram really helped clear things up and have aided in producing accurate firewall rules.

A couple notes about the connections depicted though;

  • I only included v5.x. Previous versions behave differently, so use caution if you reference these in an environment where v4.x components are reused.
  • I did not depict the connection from the vCenter Server to hosts, LDAP etc. These diagrams are View-centric
  • Although the View client may connect to the View Connection Server over HTTP/TCP80, I did not depict it because we strongly prefer the HTTPS, encrypted connection.
  • Wyse MMR is not included since it is not supported on Windows 7 Virtual Desktops
  • Black arrows indicate TCP connection request and direction
  • Green arrows represent UDP traffic flow

Here’s the PDF

PCoIP with Secure Gateway on Security Server
PCoIP with Secure Gateway on Security Server

PCoIP with Secure Gateway on Connection Server
PCoIP with Secure Gateway on Connection Server

RDP with Secure Tunnel on Connection Server
RDP with Secure Tunnel on Connection Server

RDP with Secure Tunnel on Security Server
RDP with Secure Tunnel on Security Server

RDP Direct Connection without Security Server
RDP Direct Connection without Security Server

PCoIP Direct Connection without Security Server
PCoIP Direct Connection without Security Server

Once again, here’s the PDF

How to move a VMware View desktop from one Pool to Another

First, I doubt this procedure is supported. Second, if you follow these steps, you do so at your own risk. It worked for me, but your mileage may vary.

Ok, so let’s say that you have a pool of full desktops – no linked clones – using dedicated assignment. It has become necessary to split the desktops in the pool into two smaller pools for some reason. We don’t want to actually change the desktop VM itself in any way, just move it to a new pool.


  • Source and Destination Pools – full desktops, dedicated assignment
  • The names from View administrator of the desktops you want to move
  • Administrative rights on a View Connection Server


  1. Logon to a View Connection Server as an administrator
  2. Follow the steps here to open the View ADAM database in ADSIEdit
  3. Get the GUID for the Desktop VM
    1. Right-click the Connection View ADAM Database [localhost:389], and click New > Query.
    2. Under Root of Search, click Browse.. and select the Servers organizational unit.
    3. Click OK.
    4. In the Query String, paste this search string:(&(objectClass=pae-VM)(pae-displayname=VirtualMachineName))Where VirtualMachineName is the name of the virtual machine for which you are trying to locate the GUID. You may use * or ? as wildcards to match multiple desktops.
    5. Click OK to create the query.
    6. Click the query in the left pane. The virtual machines that match the search are displayed in the right pane.
    7. Record the GUID in cn=<GUID>.
  4. Expand View ADAM Database [localhost]
  5. Expand DC=vdi,dc=vmware,dc=int
  6. Click on OU=Server Groups.  Confirm that all your Desktop Pools appear on the right.
  7. Right-click the Server Group Object corresponding to your source desktop pool and choose Properties.
  8. In the Attribute Editor, scroll down to the “pae-memberDN” attribute.  Double-click to open it.
  9. This is the list of VMs currently in the pool.  Locate the GUID(s) matching the distinguished named and click “remove” to remove them from the pool.  I strongly suggest copying the removed value to notepad so you can paste it back it accurately in the coming steps.
  10. When finished removing the appropriate objects from the pae-memberDN attribute, click OK twice to close the attribute and the Server Group object
  11. Right-click the Server Group Object corresponding to your destination desktop pool and choose Properties.
  12. In the Attribute Editor, scroll down to the “pae-memberDN” attribute.  Double-click to open it.
  13. Paste the distinguished name value for the desktop GUID int the “Value to add” text box and click “Add”.  Repeat for additional desktops
  14. When finished adding records to the pae-memberDN attribute, click OK twice to close the attribute and the Server Group object
  15. Close ADSIEdit and launch View Administrator to see the results.

Good Luck, please let me know if you try this.
VMware KB 1008658
VMware KB 2012377

Three features I want to see added to VMware View

This week was VMware Partner Exchange 2012, there was a lot of focus on End User Computing.  I attended several breakout sessions on the delivery and optimization of virtual desktops and came away with not only a greater appreciation of the technology we have, but also a need for some missing features.

Stand-alone View Composer

The supported and recommended implementation of secure multi-tenant VDI-as-a-Service is extremely cumbersome.  There’s a great deal of isolation and complexity as a result of the inter-dependencies on Microsoft Active Directory.  As you know, View Composer is installed on your vCenter Server and must be a member of- or have a 2-way trust with- the domain in which the desktops will be deployed.  As a result, a separate vCenter Server with View Composer is needed for each Forest that must be isolated.  This drives up the management and administration challenges as well as the license cost.  Some, by no means all, of the complexity could be alleviated by not requiring View Composer run on the actual vCenter Server.   If a stand-alone View Composer virtual appliance were available, it would perform all of the Active Directory actions itself and submit appropriate requests to the vCenter Server for its provisioning and to execute vSphere SDK Guest Operations for customization.  This would help with multi-tenant solutions requiring separate Active Directory Forests.

Support for Linux Desktops

A significant portion of the total CapEx for VDI is the Microsoft licenses.  The VDA is not the ideal solution for a number of organizations and sometimes a full Windows Desktop is overkill.  It was discussed at length this week that delivering Windows to a user is irrelevant, the user is concerned with the applications they need to get their job done effectively, not the platform.  As more and more business applications are migrated to web apps, having  full Windows O/S seems unnecessary.  Imagine kiosk-mode virtual desktops running Firefox on Ubuntu.  Navigate to your web app, do what you need to and move on.  In addition, we may be able to deliver ThinApps to Linux desktops running Wine.  This seems like it would be rather more difficult for VMware to support than it sounds like.  For example, if we continue to depend on Active Directory for authentication and so on, the Linux client will obviously require SAMBA and various other components.  During provisioning, the desktop is customized by assigning a unique name, joining the domain and so on.  These steps are possible by way of the vSphere or VIX API and the VMware Tools, but may require that the prerequisites are in specific locations.

Support for Seamless Windows (Unity)

There is no VMware equivalent to Citrix XenApp.  I’m okay with that; XenApp requires a rather large commitment with farms of Terminal Servers, Web Servers, Database Servers and more to deliver a robust experience.  For me and a lot of customers, there is a need to consume an application remotely without the appearance of a remote environment.  In a number of ways this may be as simple as enabling the “Unity” feature (found in Fusion and Workstation) in the View Client.  This would allow us to create desktop pools (for example) where the application in question is configured as the “shell” and delivered in a seamless window to the end-user.  The benefit here is that the end-user experience feels like a native application but is still controlled by internal IT and never actually leaves the secure data center.  In my opinion, this would be preferential to Microsoft Terminal Services, because we could continue to utilize the existing Desktop solution as well as applications that have been delivered as ThinApps.  I also prefer the user-isolation of VDI over multiple concurrent sessions on a single Terminal Services Server.  Subsequent application launches would have to be detected and handled by the View components so that a new application is launched in the already-open session rather than attempting to connect to a new desktop.


These are just a few of the items that occurred to me this week.  I’d love to hear your suggestions, whether you agree/disagree or think that there are more important features than these that are missing.


Use a Post-Synchronization script to set the Windows 7 key and activate

I had a situation today where the parent desktop image had Kaspersky Anti-Virus installed and I could not modify it.  This product is known for breaking sysprep, so I had to use QuickPrep instead.  The problem I had was that without sysprep, the system was not getting its correct Multi-Access Key nor activating.  To work around this, I put together a tiny batch file that uses slmgr.vbs to set the key and activate.  I was pleasantly surprised to see that the script/batch file was successfully executed from a UNC path, so I did not have to make changes to the parent desktop image.

The batch file contents:

cscript C:\Windows\System32\slmgr.vbs /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
cscript C:\Windows\System32\slmgr.vbs /ato


Please be aware that the procedure is different when there is a Key Management Server in place with the appropriate Windows 7 Keys ready.

Configure Wyse Windows Embedded Standard thin client to load VMware View Client automatically


  • Faster time from power on to View logon prompt
  • User cannot access any other applications on the Windows Embedded O/S
  • Exiting the View Client automatically relaunches it
  • Administrator account is not affected


  1. Disable PXE boot
    1. As the thin client is booting, hit <delete> to enter the BIOS
    2. At the BIOS password prompt, enter “Fireport” (unless the BIOS password has been changed)
    3. Update the device boot order so Hard Drive is first
  2. Get “User” SID
    1. Reboot thin client, load Windows as default “user”
    2. Click “Start|Shutdown|Log off” while holding <shift>, continue holding <shift>
    3. At the logon prompt, logon as administrator using the password “Wyse#123”
    4. Launch Regedit, navigate to HKEY_USERS
    5. Examine the USERNAME value under each “HKEY_USERS\<SID>\Volatile Environment” to find which SID belongs to the default “user”.  A SID begins with “S-1-5-“.
    6. Double-click “Disable FBWF”, wait for system to reboot
  3. Create scripts
    1. Click “Start|Shutdown|Log off” while holding <shift>, continue holding <shift>
    2. At the logon prompt, logon as administrator using the password “Wyse#123
    3. Launch Windows Explorer
    4. Create a folder named” bat” in the root of C:\
    5. Launch Notepad; paste in the following:

      @echo off
      “C:\Program Files\VMware\VMware View\Client\bin\wswc.exe”
      goto View

    6. Save the file as C:\bat\View.cmd
    7. Launch Notepad; paste in the following:

      Set WshShell = CreateObject(“WScript.Shell”)
      WshShell.Run chr(34) & “C:\bat\view.cmd” & Chr(34), 0
      Set WshShell = Nothing

    8. Save the file as C:\bat\View.vbs
  4. Update Shell for “User”
    1. Launch Regedit
    2. Navigate to “HKEY_USERS\<SID>\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinLogon”
    3. If the “Shell” values does not exist, create it as a new String Value
    4. Update the “Shell” value to “wscript c:\bat\view.vbs”
    5. Close Regedit
    6. Double-click “Enable FBWF”
    7. Reboot thin client

Credits to Sparko Design, Free Wyse Monkeys and MidWest Wyse Guys.

VMware View 4.6 incompatible with VM v8 – correction

I’ve got an environment running vSphere 5.0 and VMware View 4.6 (because View 5.0 isn’t GA yet).  I found that when I upgrade the VM version and VMware Tools of my “Parent” Windows 7 VM, then recompose the Pool, the View client can no longer connect to the Desktop over PCoIP!

Here’s some more details, I’m using a security server in a separate VLAN from the Connection Server, but even if I connect the View client directly to the Connection Server, the behavior is the same.  It acts just like the PCoIP port is blocked (it’s not BTW); first the black screen, then the session dies.

If I choose the snapshot made before the HW version and Tools version upgrade, and re-recompose the pool,  the client connects as expected.  There are no other apparent differences between the “working” snapshot and the “not-working” snapshot, so I must conclude that VMware View 4.6 is incompatible with VM v8.

If this is, or is not the case, or you have a workaround, please let me know!


Edit: thanks to the very first comment, I reinstalled the View Agent on the parent VM an viola’, it worked like a charm.


vSphere 5 Licensing impact on VDI

Very quietly, VMware released some information about vSphere for Desktop. This is the licensing model you’re going to want… especially for VDI.

Here’s a link to the details:vSphere Desktop FAQ

There are a number of caveats explained in this FAQ, but the licensing strategy is beginning to make sense.

In short, if you run VMware View, you can get an unlimited vRAM entitlement.  You cannot upgrade to vSphere 5 for Desktop and if you’re running a third-party VDI solution on vSphere, you will have to use the “non-Desktop” editions and be subjected to vRAM license limits.

This is just my humble opinion and does not necessarily reflect the opinion of my employer or partners or anyone else for that matter

Not all smartcard readers are created equal

Recently, I was working with a customer site where they used smartcards to authenticate to applications. In this case, since the reader was not part of the VMware View session authentication, the USB reader itself had to be passed through via redirection.

I tried setting the “AllowSmartcards” value to true:
HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware VDM\USB AllowSmartcards=true

But the reader still wasn’t redirected to the View session. In this case, I ended up having to follow this KB article to recognize the device as one that can be redirected. The particular reader is identified as a “USB Keyboard”, which are typically not redirected. Obviously, you’ll have to make sure that you don’t redirect your actual keyboard.