Tag Archives: PCoIP

VMware View / PCoIP / PowerPoint bug

We just went live with a 400-seat View deployment at a school district. They have Wyse P20 zero clients which have dual DVI monitor ports. The project was a complete rip-and-replace – routers, switches, wiring, all Mac computers replaced with P20s, and two new racks full of gear in the server closet.

The teachers arrived this past week and started working on transferring their files off the Macs. One of them brought a problem to my attention – when he was trying to run his PowerPoint in presenter mode, the projector showed nothing but a black screen. Interestingly enough, if he used the marker tool to draw on his side of the presentation, the slide on the projector suddenly appeared.

Slideshow Ribbon in PowerPoint 2010

Slideshow ribbon in Powerpoint 2010

A Google search for the View release notes turned up with this, listed as a known issue in every View release since 4.5:

In Windows 7 desktops when connected using PCoIP in multiple-monitor display mode, if you choose Show On: Monitor Generic Non-PnP Monitor for any monitor other than the primary monitor in PowerPoint 2010, a black screen is displayed instead of a slide show.

Workaround: If you are using PowerPoint 2010 in a Windows 7 desktop, you must use Show On: Primary Monitor for a slide show.

One immediate workaround that other engineers at my company suggested is to use the RDP protocol. This does work, the issue does not exist when using RDP. However, it wasn’t an option at this client as the user endpoints were PCoIP Zero clients.

This was a huge problem for user acceptance of the project. Most of the teachers were used to presenter mode for delivery of their slideshows. The only workaround was to connect the projector directly to DVI output #1 and have the teacher present directly from the projector. Many teacher desks were oriented such that the teacher couldn’t even see the projection – either we got the presenter mode to work or we were asking dozens of teachers to rotate their entire classroom one day before students arrived. It wasn’t really a good workaround for teachers who could see the projection anyway. This district uses hosted PowerSchool for their student information system. They take attendance online and you generally wouldn’t want to project the process of logging into the system. A teacher could easily reveal credentials and allow students to log in and change grades. So we were down to having to switch video cables from the projector back to your monitor many times a day – a bit frustrating to say the least. We discussed a DVI splitter but that wasn’t a great option either, it would be a little easier to disconnect the projector when you didn’t want to project, but it was still kludgy.

I opened up support tickets with VMware and Teradici at 7:30 PM. The client paid for 9×5 support, so I wasn’t going to get an answer from VMware for quite some time. Teradici was a different story. They are the creators of the PCoIP protocol and maintain firmware and management software for zero clients. You can log on to http://www.teradici.com and get support if you’re running a PCoIP solution.

I went home and woke up to discover that e-mails from Teradici support had arrived in my inbox at 7:30AM. The support tech had already tested the bug out in his lab and had a way to resolve the issue. That’s a completely free 12-hour turnaround with resolution!

The fix was to enable 3D rendering. First you enable it in the pool. Doing so means you can no longer support RDP connections to the pool, so you have to turn off “Allow users to choose protocol.” Then enable 3D Rendering.

Enable 3D in View Pool

Enabling 3D rendering in View

Next, enable 3D support on your template VM. For me, Performance was unacceptable with less than 64MB of video RAM, and it got better with more. You might want to experiment with various RAM settings to determine the best setting in your environment.

Enable 3D support on a VM

Enabling 3D support on a VM

Then inside your template, enable Aero. The quickest way I found is to search for aero, then click “Find and fix problems with transparency and other visual effects.”

Enable Aero in Windows 7

Enabling Aero in Windows 7

 

 

 

 

 

 

 

 

 

 

 

 

Enabling Aero turns on the “pretty” features of Windows 7, which suck up memory and CPU cycles. I found the VM to be sluggish with Aero enabled, so I set the VM’s visual effects to Best Performance.

Adjust for Best Performance

Adjusting Windows for Best Performance

I recomposed my pool, tested it out, and it worked! There is definitely a penalty here in the form of increased resource use, but it gets the technology out of the way and lets the teachers focus on teaching the lesson.

Many thanks to the folks over at Teradici for this fix!

Configuring View security servers

I recently spent a very long time troubleshooting a View security server, documented in this post. As part of my sanity checking, I checked and rechecked all of the necessary settings for a security server paired up with a connection server. I didn’t find any helpfile or blog post that clearly spelled out what I needed to have configured, so I’m putting up a quick post.

This is the View connection broker that’s paired with the security server. The external URL and the PCoIP external URL are the private IPs of the connection broker itself. The security server in the DMZ must have access to these IPs. I won’t rewrite the firewall rules required, but check out KB1027217 for a detailed list of ports. The IP here is the IP that the security server sees for the connection broker. If you’re doing some kind of NAT from your DMZ to the inside, you’re going to have to key in the IP address on the DMZ side of the NAT.

View Connection Server

This is the paired security server. Here we use public IP addresses. This IP must be NATed externally to the private IP of your security server… unless of course you use public IP addressing inside your DMZ (yikes).

View Security Server

 

 

 

 

 

 

 

 

It’s not easy to test your changes externally. You could work remotely with multiple computers, one on the VPN to make your configuration changes and another testing connectivity from the public internet. That’s not always a feasible option for a consultant. You will typically not have a good way to test externally while inside the client’s network. I do a lot of work in education and many schools are built like bunkers – no cellular signal at all, so a MiFi or tethering is out as well. One easy way to test communication from the DMZ to the inside is to put a temporary VM in your DMZ segment. Give it an IP in the same subnet as your security server, and install the View client. In View, configure the security server to use the private DMZ IP instead of the public IP for the external URL and the PCoIP external URL. You can then test from your temporary VM. Once you get it working, change the external URL and the PCoIP external URL back to the public IP. Then you can get the external NAT and external firewall rules working – this is not a complex configuration and won’t require much trial and error.

Check the path – A lesson in PCoIP troubleshooting

I’ll start with the moral of the story – when you’re having network issues, check the entire path.

I had an ongoing issue on a client’s network involving VMware View 5 and PCoIP. All internal traffic worked fine. Any PCoIP traffic that passed through the Cisco ASA firewall timed out. I could not get PCoIP traffic to work externally through the DMZ. It was the same behavior you get when the firewall has blocked ports. However, the firewall rules all seemed to be correct. When I switched the View client to use RDP, it connected to the desktop.

I opened a ticket with VMware support. They performed a bunch of troubleshooting, including running custom utilities to validate that all firewall ports were open. Everything checked out, and they blamed the Cisco ASA. I found a View-related bugfix on the Cisco website and tried flashing the ASA, but the problem persisted. So I opened up a ticket with Cisco TAC. They did their troubleshooting including packet captures and found nothing wrong. Their analysis was that the internal View connection broker was sending a FIN message to terminate the PCoIP session.

Back I went to VMware support, and they again failed to come up with a solution. So I was sitting there one day and my eyes floated over to the network diagram hanging on the wall. BAM. The cause of the problem was staring me right in the face. The customer has a Cymphonix web filter device, it functions as a bridge between the Cisco ASA and the internal network core. I tried digging through the logs on the Cymphonix but found no evidence of any packets being dropped. I put in a call to Cymphonix support anyway. I discovered that the Cymphonix was definitely dropping the PCoIP packets.

I had run afoul of a feature called Anonymous Proxy Guard. It’s designed to prevent a user from bypassing the Cymphonix by using another proxy server. The feature detects the PCoIP protocol as an anonymous proxy and drops the packets. Cymphonix support couldn’t give me a satisfactory explanation for why the device didn’t/couldn’t log the drops. I reconfigured the Cymphonix to stop using Anonymous Proxy Guard for all traffic inbound and outbound from the View Security servers. Problem solved.

The next time you’re having a problem like this, trace the entire network path!