by
Brian Madden
Last week VMware released View 4.6. It's a minor release with the main new feature being the "VMware View Security Server" which is a security proxy that lets users connect via PCoIP without needing a corporate VPN. But perhaps the bigger news is what's not there, specifically View 4.6 still doesn't include the profile virtualization VMware got when they bought RTO Software.
Let's take a look at what each of these means.
VMware View Security Server: A secure proxy for PCoIP that does not use SSL
One of the limitations with PCoIP in past versions of View was that users connecting from outside the firewall required a direct connection to their View desktops. Since pretty much no company on Earth allows this, outside users typically had to connect to a VPN first. While this in-and-of-itself wasn't all that bad, the real problem was that most VPNs are made for TCP, and PCoIP is a UDP protocol. That means that there's a lot of overhead spent to wrap the UDP packets in TCP, not to mention that since TCP is reliable and UDP isn't, you're getting even more overhead with all the acknowledgements and retransmits and everything of TCP that you don't need for PCoIP. (I wrote about the UDP versus TCP issue on SearchVirtualDesktop.com a few months ago.)
So now in View 4.6 you can install a View Connection Server in a "Security Server mode" which is basically a special mode where the Connection Server sits in the DMZ and acts as a PCoIP proxy server that lets users connect through it to their back-end View desktops. It does all the things a server in a DMZ should, namely, it doesn't allow anyone to get through that hasn't been authenticated, and it only allows them to access specific resources on the inside that they're allowed to access.
Now here's the surprising thing about this Security Server: It does NOT use SSL. Repeat: The VMware View Security Server is a proxy for UDP-based PCoIP. It is NOT an SSL gateway and it's not an SSL-VPN.
From a pure security standpoint this is fine, since like I said it only allows authenticated users through and the PCoIP protocol is already AES 128-bit encrypted. The main downside is that while SSL is allowed from anywhere, users' PCoIP connections to the View Security Server are via port 4172. (First via TCP, then the connection runs over UDP.) And some companies aren't going to allow that. That was actually a problem for me at TechTarget. I had to put in a helpdesk ticket to get them to open up 4172 at our office. I'll keep you posted as to how much of a problem that is elsewhere. So far it's fine for my 3G connection, but who knows whether this will be a problem in other offices and hotels?
Even though the Security Server doesn't encrypt the traffic stream with SSL, you do still have the option of installing an SSL certificate for initial FQDN authentication to prevent man-in-the-middle attacks, so that's cool.
So the bottom line with the View Security Server is a mix of good and bad news. Using UDP all the way to the endpoint is great because that's how PCoIP was designed, and since the Security Server is just a proxy and not adding extra encryption/decryption, it shouldn't slow things down or add any more size to the protocol. But despite all that, I'm still slightly worried about finding TCP/UDP 4172 open everywhere.
Ok, now where the hell's Persona?
Seriously guys. It's been a year. (Here's my story from back then, and VMware Desktop CTO Scott Davis' blog post.) At this point I don't think anyone's buying the excuse that they're working on "integration," so can someone just come out and tell the truth? Where is RTO Virtual Profiles? Why is it not part of View 4.6? (Remember we saw the beta version way back in View 4.5, but then it disappeared at the last minute. The excuse VMware gave at the time was that it was not compatible with Windows 7, but given that RTO's Virtual Profiles product was compatible with Vista and VMware got RTO Software (and BriForum presenter) Kevin Goodman as part of the deal, I can't imagine that Windows 7 is the real reason.
Regardless of the reason, VMware's starting to look pretty silly around this. They talk about how awesome profile virtualization is in their blogs and the RTO transition documentation, but then it's actually not available from them. (And in a masochistic twist, VMware's View reference architecture linked to from the View 4.6 announcement recommends using "profile management software like RTO Software or Liquidware Labs" (Pages 7 and 24). Except when VMware bought RTO Software, they immediately stopped selling RTO Virtual Profiles (VMware's RTO Acquisition FAQ, Page 3). Soooo..... I guess they want us all to use Liquidware Labs Profile Unity now?
I asked VMware PR where Persona was and why it's not in View 4.6. All I got was this answer:
Profile management is a key component of VMware's strategy to modernize the enterprise desktop and will be offered in future releases of View. The release of View 4.6 focuses on PCoIP support for VMware View Security Server which provides a simple and secure way for users to access their VMware View desktops remotely, while taking advantage of a superior PCoIP experience. VMware View currently supports third-party persona management capabilities from several VMware partners. Customers can expect further innovation and integration of persona management as VMware continues to advance its model for end user computing within the enterprise.
That was some nice tap dancing that in no way answers the question that I asked.
But hey, you can sync your iPhone!
One of the cool little updates to View 4.6 is that you can now sync your iOS device (iPhone/iPod/iPad) with iTunes running in your View VM that's connected to the client via USB.
Bottom line
+1 for the PCoIP proxy. That's really cool.
-1 for still no profile virtualization and for a super lame non-answer on why.
So I guess they cancel out, and View 4.6 is.... fine. (In related news, I'll be installing View 4.6 this week for my second month of full-time VDI usage. I'll keep you posted!)
(Note: You must be logged in to post a comment.)
If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.