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.
Eww, curved, intersecting lines.
Once again, here’s the PDF
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;
Once again, here’s the PDF
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:
Steps:
(&(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.cn=<GUID>.Good Luck, please let me know if you try this.
References:
VMware KB 1008658
VMware KB 2012377
This information will probably be outdated quickly, but for now (9/14/2012), here are my suggestions and tips concerning vCloud Suite 5.1
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.
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.
Objectives:
Procedure:
@echo off
:View
“C:\Program Files\VMware\VMware View\Client\bin\wswc.exe”
goto View
Set WshShell = CreateObject(“WScript.Shell”)
WshShell.Run chr(34) & “C:\bat\view.cmd” & Chr(34), 0
Set WshShell = Nothing
Credits to Sparko Design, Free Wyse Monkeys and MidWest Wyse Guys.
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.
Brian Ragazzi 