Archive

Posts Tagged ‘VMware View’

VMware Horizon View Network Ports Illustrated pt. 2

08/12/2013 Comments off

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

Advertisements

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

10/19/2012 Comments off

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.

Prerequisites:

  • 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

Steps:

  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.
References:
VMware KB 1008658
VMware KB 2012377

Categories: VMware View Tags: , , ,

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

01/04/2012 Comments off

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

Replace XXXXX-XXXXX-XXXXX-XXXXX-XXXXX with your MAK.

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

Objectives:

  • 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

Procedure:

  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
      :View
      “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.