Posted on

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!

Posted on

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!