Why is Sun releasing a RDP Client?

I'm sure a lot of folks have asked themselves this question today.

There are plenty of 3rd party RDP solutions for Solaris (examples here, here, and here), and there's the very popular open source RDP client, RDesktop. We even bundled RDesktop on the Sun Ray Server Companion CD. Let's not forget our acquisition of Tarantella which became Sun Secure Global Desktop. So why go to all this trouble?

One reason was probably to get me to shut up. I've been after anyone who'd listen that we need to build or buy our own RDP client forever. As the capabilities of RDP increased, so did my pressure to make this happen. But that's not a good answer, here are some better ones.

Full compliance with the Microsoft Remote Desktop Protocol 5.2: This means smart cards, Windows Network Load Balancing Support, Terminal Server Session Directory Support. You won't find another RDP client for Solaris out there with the complete RDP 5.2 feature set.
Customers who don't want open source: As much as we love open source here at Sun, there is a large number of customers who will not deploy open source software
The legal question of RDesktop: There's a lot of customers who were scared of Microsoft's reaction to them using RDesktop. Though the legality has never been tested, these customers didn't want to be the first. My opinion has always been if Microsoft gets their money, it shouldn't matter. But a CIO of a Fortune 500 company has a lot more at risk and needs more assurance than my opinion (read indemnification).
Point and Shoot Simplicity: Sun Secure Global Desktop is a great product, but Windows access is only a small part of it. For customers that just want simple point and shoot access to their Windows environment from their Sun Ray, the Sun Ray Connector for Windows is much simpler.
Built by Sun: It's no secret that the US Government and Military is one of Sun's largest customers. They wanted Sun to provide the complete solution for their thin client of choice.
Built to Microsoft's RDP Spec: Customers told us they want a solution that won't be rendered useless with a Microsoft Hot Fix or Service Pack. They want a Microsoft Certified Solution. That's what we are delivering.
Performance: This is built for Sun Ray from the Ground up. First comes features, next comes performance. Our goal is to make this the best RDP client for Sun Ray. Not just for Solaris or for Linux, but for Sun Ray.

So give the Sun Ray Connector for Windows a spin. Check back here for updates, known issues, etc. I'll be blogging a lot about this in the months to come. I kind of feel like this is my baby, even though I didn't write one line of code.

Comments:

Only one real question left, how much? From the sounds of it this will go down really well, if it not silly in price!b

Posted by j.p.drawneek on February 25, 2006 at 06:51 PM PST #

I've got another couple of questions and remarks:
Session mobility - With each and any of the other solutions mentioned the TS windows become an integrated part of the desktop and therefore are as mobile as the Sun Rays itself.
Although I can see the license argument given in the readme, I'm not about to tell my users they've got to enter their username and password up to three times extra because that's whats needed for a lousy CAL to keep sync.

Smart Card pass-through still remains a bitch. We're using SafeSign and it's not working , but to be fair, it's not working under SGD either (I have reasons to assume this is more of a Sun Ray issue than a Connector issue).

Now, speaking of SGD: Wouldn't it be nice if you'd be able to combine the Tarantella module with the Connector to get that "seamless window" thing going on which we all love from SGD so much?

I do have to give kudo's to the programmers on the performance though, it's quite good. Now if only the Meta-key worked as a Windows key.

Posted by The Loeki on February 28, 2006 at 01:28 AM PST #

The Loeki,
The best place to have these questions/comments go for the beta is the email alias src-feedback-ext <at> sun.com. But I can address them here:

Behavior of the product will change by release time regarding the CAL's. We will only force reconnect if the DTU doesn't have a CAL yet. Workaround it to start a session on that DTU before going into production.
If your TS environment is in user CAL mode, we'll never disconnect.

Meta key is a bug and will be fixed.

Regarding the smart card, do you have the latest PC/SC Bypass installed? Are you using Solaris? Feel free to describe you problem more indepth as just saying it doesn't work doesn't help much.
Just describe to the beta feedback alias.

Posted by ThinGuy on February 28, 2006 at 06:53 AM PST #

Next big step...if Sun opensource the SunRay stack of software then we can all start innovating on this fantastic peace of hardware/software combination

Posted by Frans on February 28, 2006 at 12:31 PM PST #

ThinGuy, Thanks for the mail address (hadn't seen it yet), I've forwarded the post there. "Meta Key is a bug and will be fixxed" - Glad to hear it, I've dabbled around with pretty much everything but Citrix out there, and keys and especially key combos (Ctrl-Alt-F11, Shift-Alt-Pause, that kind of stuff) remain troublesome for most solutions. Regarding the smart card issues I can't tell you too much, because I'm honestly an absolute n00b in smart cards, digital signatures and the likes. However, we need to use a 3rd party middleware called SafeSign for some apps, and SafeSign has a Solaris version, which is not working (couldn't tell you why, but it was created for S9/SRSS2 w/certain patches). Also, the SGD maps the smart card through to the Windows SafeSign, but after that it either fails to recognize a SunRayDTU smart card reader or it starts reading but fails to recognize tokens or whatever on the smartcard. With the Sun Ray Connector beta there's an "unknown" card reader available with no smart card in it. I am using the latest bypass (the direct one, not the one through OCF), but I haven't patched the SRSS 3.1 yet. I saw some sc issues there, so maybe it'll work better then. In the meantime A.E.T., SafeSign developers, are working on the issue as well, and they mentioned that SRSS3.1 re-introduced a bug they apparently had fixxed in SRSS2.

Posted by The Loeki on March 02, 2006 at 03:41 AM PST #

Think Thin: Thin Client and Server Based Computing Group Blog