JasonPearceAtRi's Posts

PeterB, Again, thanks for the advice you have offered. Test 1 I rolled back to a working snapshot. I uninstalled View Agent and VMware Tools normally. I then installed VMware Tools followed by View Agent. The recomposed desktop pool lost USB pass-though. Test 2 I rolled back to a working snapshot. I made no change to View Agent or VMware Tools. I instead updated some applications (Java, Flash, etc.). The recomposed desktop pool retained is ability to perform USB pass-through. Test 3 I rolled back to a working snapshot. I made no change to View Agent or VMware Tools. I applied the past three months of Microsoft Updates (sans IE10). The recomposed desktop pool lost USB pass-though. Test 4 I rolled back to a working snapshot. I uninstalled View Agent and VMware Tools aggressively, deleting every VMware folder, product, driver I could find (per this KB). I then installed VMware Tools followed by View Agent. I was able to install all parts of the View Agent except for USB Redirection. USB Redirection refuses to install, giving this error. Next I'm going to just build a brand new parent virtual machine from scratch (not an upgrade). I simply want proof that the version of VMware Tools and View Agent that I have work. I'll apply all Microsoft Updates. If this works, then your theory of legacy drivers that are not removed during an upgrade of Tools and Agent is most likely my issue. I then just have to figure out how to upgrade Tools and Agent on my existing parent virtual machines without losing USB Redirection.

I attempted to completely remove both VMware View Agent and VMware Tools. Then perform a fresh install of both. Everything installs correctly except for View's USB Redirection. Here are the steps I took. Uninstalled VMware View Agent Rebooted Uninstalled VMware Tools Rebooted Deleted c:\ProgramData\VMware Deleted c:\Program Files\VMware Deleted c:\Windows\System32\drivers\vmw*.sys Deleted c:\Windows\System32\DriverStore\FileRepository\vmwvhub*.* Rebooted Installed VMware Tools complete install Rebooted Installed VMware View Agent complete install Error from VMware View Agent Installer Information. "Error 28030. The installer failed to install the USB driver. To ensure a successful installation, please restart your machine and relaunch this installer." Rebooted Installed VMware View Agent complete install Same Error 28030 Rebooted Installed VMware View Agent complete install except for USB Redirection Successful installation Rebooted Installed VMware View Agent > Modify > added USB Redirection Same Error 28030

Peter, Perhaps. I'll will give it a try. Though my problem is a change in VMware Tools, not the VMware View Agent. I'm using the same version of the VMware View Agent, and am instead upgrading to a newer version of VMware Tools to match the recently-patched ESXi hosts. I uninstall the View Agent, upgrade to the newer VMware Tools, and then re-install the exact same View Agent. I do appreciate the KB and will research to see if it helps. Thank you.

The root cause of our problem was the fact that the consolidation of our ASAs into a single physical platform resulted in there being "trusted internal" addresses appearing on our "untrusted external" ports on Palo Alto. Previous versions of the VMware View Agent were not encrypting all packets, so Palo Alto could recognize the PCoIP application, which made correlations easy. However, the new VMware View Agent v5.2 has more encrypted content, so the amount of searchable information that Palo Alto can access is limited. We ended up creating a new Palo Alto policy to specifically allow SSL traffic from our two VMware View Security Servers.

slricogisd. Thanks for the KB. I've provided VMware Support two desktop pools (5.1.3 and 5.2.0), Wireshark, and netcat. So far, we've been unable to resolve this issue. I will post the resolution once we figure it out. Thank you all for the help.

Sure meyner22. Here are the settings for my Security and Connection servers. View Admin > Security Server (only ***SECURE2 is in use): View Admin > Connection Server (***CONNECT4 is paired to ****SECURE2, others are internal):

Meyner22: Thanks for responding. At first, I performed an in-place upgrade of the View Agent in my Parent Virtual Machine from 4.6.0 to 5.2.0. When that failed (externally, internal PCoIP works) I build a brand new Windows 7 PVM with a fresh install of the View 5.2.0 Agent. I tried having the Windows Firewall Service started with profiles disabled, as well as the Windows Firewall Service started with profiles enabled, before installing the View 5.2.0 Agent. I then skipped all Windows 7 optimization scripts and put the new pool in a new Active Directory OU with no Group Policies. No luck. External/WAN PCoIP connections fail. If I downgrade to the View 5.1.3 Agent (uninstall, reboot, install), external/WAN PCoIP connections work. Markbenson: Thanks for sticking with me. I agree. If external/WAN PCoIP connections work to desktops with the 5.1.3 Agent, then my DMZ/firewall rules, Security to Connection Server pairing, SSL Certs, and even Windows Firewall rules should all be correct. My test desktop pools are in the same VLANs/subnets as my production desktop pools. I even recomposed my production virtual machine (just my machine, not the entire department’s pool) to the View 5.2.0 Agent. Same result. I can connect internally but not externally. I have only one Security Server to Connection Server pairing, so all tests are going through the same servers and network paths. Regarding the PCoIP black screen, I don’t quite make it to a black screen. I get the dark gray remote desktop border with a hollow/transparent inside (it’s not filled with black and instead shows my desktop) for 1 second before the connection is closed. I am certain that the last thing that I install on my PVMs is the View Agent, but thank you for reminding everyone that the Agent must be installed after Tools. For display resolution, here’s how I have things configured. vSphere > PVM > Edit Settings > Hardware > Video Card > Auto-detect video settings View Admin > Inventory > Pools > Test 5.2.0 pool > Edit > Pool Settings > Max number of monitors = 2 AND Max resolution = 1920x1200 Most of my external testing has been done via a Windows 8 x64 virtual machine I have at home. When I perform the test I select “Windows – Small” for the display. I’ve also tested externally via my iPad and iPhone, both with the newest VMware View Client. My iPad is able to connect internally to a 5.2.0 desktop at work but not externally from home. I have provided VMware Support eight Wireshark packet captures: Security Server > External Client to a 5.1.3 Agent Security Server > External Client to a 5.2.0 Agent Virtual Desktop with 5.2.0 Agent > Internal connection via a 5.2.0 Client Virtual Desktop with 5.2.0 Agent > External connection via a 5.2.0 Client Work Laptop/Client > Internal connection to a 5.1.3 Agent Work Laptop/Client > Internal connection to a 5.2.0 Agent Home Lab/Client > External connection to a 5.1.3 Agent Home Lab/Client > External connection to a 5.2.0 Agent What we find is no UDP traffic for external attempts to the 5.2.0 Agents. VMware Support is still reviewing this data. I appreciate everyone’s ideas. If you have any more, I’ll be happy to test. In the meantime, I’ll continue to work with VMware Support. Thank you.

Thanks markbenson. Yes, VMware View Composer, Connection Servers, and Security Servers were all upgraded from View 4.6.0 to View 5.2.0. Next I began upgrading the View Agents from 4.6.0 to 5.2.0 in my parent virtual machines and rebuilding those desktop pools when I discovered that external PCoIP stopped working for the desktops with the newest agent. I eventually downgraded to the View 5.1.3 Agent, which works and is holding me over as I troubleshoot getting the View 5.2.0 Agent to work.

In addition to paying attention to the VMware Product Interoperability Matrixes, you should also reference Update sequence for vSphere 5.1 Update 1 and its compatible VMware products (2037630) to determine the proper upgrade order.

Following this KB Troubleshooting PCoIP Secure Gateway (PSG) issues (1034825) I'm still unable to resolve my issue: Resolution To troubleshoot issues starting a PCoIP session using PSG: 1. Check the operating system's version of the Security Server and Connection Server. Security Server OS: Windows 2008 R2 SP1 Connection Server OS: Windows 2008 R2 SP1 2. Check if the correct Security or Connection server is configured for PSG. VMware View PCoIP Secure Gateway service is present and started on both the Security Server and the Connection Server View Admin > View Config > Servers > Security Servers > viewsecure2 reports PCoIP Secure Gateway is Installed View Admin > View Config > Servers > Connection Servers > viewconnect4 reports PCoIP Secure Gateway is Installed 3. Check that the Security Server and Connection Server are paired. View Admin > View Config > Servers > Security Servers > viewsecure2 is paired with viewconnect4 4. Ensure that the PSG is enabled in the Connection Server. View Admin > View Config > Servers > Connection Servers > viewconnect4 > General > PCoIP Secure Gateway is Enabled (checked) 5. Check the configuration of PSG settings. View Admin > View Config > Servers > Connection Servers > viewconnect4 > General > HTTPS Secure Tunnel > Use Secure Tunnel connection to desktop is Enabled (checked) > External URL > https://desktops.example.com:443 View Admin > View Config > Servers > Connection Servers > viewconnect4 > General > PCoIP Secure Gateway > Use PCoIP Secure Gateway for PCoIP connections to desktop is Enabled (checked) > PCoIP External URL > 68.xxx.xxx.xxx:4172 (same IP found at View Admin > View Config > Servers > Security Servers > viewsecure2 > PCoIP Secure Gateway > PCoIP External URL (e.g. 68.xxx.xxx.xxx:4172) 6. Check communicating and firewall rules. Front-end and back-end firewall rules are vaild since View 5.1.3 Agents and lower can estabilish external PCoIP connections to the same resources

Chris, Thanks for offering to help. Here's my configuration... Security Server Server Name: viewsecure2 Paired With: viewconnect4 HTTPS Secure Gateway > PCoIP External URL: https://desktops.example.com:443 PCoIP Secure Gateway > PCoIP External URL: 68.xxx.xxx.xxx:4172 (help says "An IP address must be specified, not a server name.") Blast Secure Gateway Blast External URL: https://desktops.example.com:8443 Connection Server Server Name: viewconnect4 Paired With: viewsecure2 HTTPS Secure Tunnel > External URL: https://desktops.example.com:443 PCoIP Secure Gateway > PCoIP External URL: 172.xxx.xxx.xxx:4172 (I also tried the same external IP 68.xxx.xxx.xxx:4172 as the Security Server) Blast Secure Gateway Blast External URL: https://desktops.example.com:8443 I restart the VMware View Connection Server service on viewconnect4 after making changes. Results are the same. View 5.1.3 agents can connect with all attempted settings. View 5.2.0 agents via PCoIP fail all attempted settings.

Changing the "C:\Windows\System32\drivers\etc\hosts" file on viewconnect4.example.local didn't make a difference. I tried both of these values (not at the same time): 127.0.0.1 desktops.example.com 172.22.55.55 desktops.example.com I then flushed my DNS cache "CMD > ipconfig /flushdns" and made sure that if I pinged desktops.example.com on viewconnect4.example.local that it responded correctly and did not respond with an IP from viewconnect1, 2, or 3. In View Admin > View Configuration > Servers > Connection Servers > viewconnect4 > Edit > General > HTTPS Secure Tunnel > External URL > I tried both https://desktops.example.com:443 and https://viewconnect4.example.local:443. Same result for all four tests. Desktops with the View Agent 5.1.3 and below all work. Desktops with the View Agent 5.2.0 fail to connect via PCoIP.

Linjo, I thought that you'd might have something there regarding the HTTPS Secure Tunnel > External URL, but it doesn't appear to be the case. The help button next to this setting reads: The setting is disabled if Use Secure Tunnel connection to desktop is unchecked. View Clients use the External URL to establish a secure tunnel to this View Connection Server instance. If a server name is specified, it must be resolvable by each View Client. The External URL must not be load balanced. In my testing, it doesn't seem to matter if the External URL for the Connection Broker is set to https://desktops.example.com:443 (friendly external URL) or https://viewconnect4.example.local:443 (internal FQDN). In either case, the result remains the same. View 5.1.3 Agents and below can connect externally via PCoIP but the View 5.2.0 Agent cannot. The last line of the help pop-out concerns me though: "The External URL must not be load balanced." My objective is to have all employees learn and use a single URL -- https://desktops.example.com:443 -- regardless of location. Internally, I use DNS load balancing by having three A records servers viewconnect1.example.com, viewconnect2.example.com, and viewconnect3.example.com. Externally, I have just one https://desktops.example.com DNS A record that points to just one Security Server that is paired to viewconnect4.example.com. My concern is that the Connection Broker viewconnect4.example.com is inside the domain and would thus listen to my internal DNS servers that are performing load balancing tasks for desktops.example.com, to servers that do not have the HTTPS Secure Tunnel enabled and are not paired to the external Security Server. While older View Agents were accepting of this configuration, perhaps the View 5.2.0 Agent is not. If not, how do others use DNS load balancing with View 5.2.0 to present just a single URL for internal and external access? Perhaps modifying the "hosts" file on viewconnect4 be a solution to prevent it from accessing our internal DNS servers.

In my experience, the VMware View Agent is to be upgraded after VMware View Composer, Connection, and Security servers are upgraded. It's okay to have lower Agents, but not greater. If your servers are View 5.1.3, then your View Agent should be 5.1.3 or lower. I find that View Clients, however, can often be a higher version than the servers or agents.

My best out-of-the box solution was to just give all VMs two vCPUs to speed up ThinPrint mapping. Neither HP nor Xerox cared to improve the printer installation time. Mostly because the typical desktop user installs a printer once, so who cares if it takes 45 seconds. But when VDI users need to install five printers every time a desktop moves, it's a problem. I think a user virtualization solution like AppSense would help, but we weren't ready to make the financial committment.