What can the Sun Desktop Access Client do for you?

On November 10th we announced the release of Sun Ray Software 5. Among the fantastic set of new features, we included a new client called the Sun Desktop Access Client. Simply put, this is a software application that installs on Windows PCs, allowing you to access your desktop session on Sun's desktop virtualization technology. This sounds great, but what does it really mean for me or my customers? Let me explain...

A couple of fairly common scenarios I hear from customers is they believe only a portion of their end-users will fit the desktop or even laptop thin client model. Or many times customers have recently refreshed all their desktop systems and don't want to switch them out just yet. They all agree on the unequaled security and simplified management aspects of the architecture, but usually have concerns for mobile end-users who require a usable laptop even when offline, or maybe they need more graphical power locally, or simply are not ready to exchange their desktop systems for whatever the reason. With the Sun Desktop Access Client, users can now leverage their existing PCs to access the same virtual desktops any Sun Ray client user would. And with the added convenience of choosing between window mode or fullscreen, it's easy to work side-by-side on their current PC.

This now means all end-users, whether they're on a Sun Ray client or not, can access the same data and applications on the same secure architecture. And to make it even more convenient, you can "hot desk" or move your live session between any Sun Ray client and any Sun Desktop Access Client enabled PC.

This makes the Sun Desktop Access Client an extremely powerful and simple migration tool. For example, we have a customer that has several offices all over the world, some very small in remote locations, some large housing over a thousand employees. This makes training each group of employees on any new infrastructure a real challenge. With the Sun Desktop Access Client, they are able to provide everyone instant access from their current PCs to the new infrastructure, and roll out Sun Ray clients to groups in controlled stages. The option to deploy Sun Ray clients in this staged manner, allowed them to immediately standardize onto a single secure and scalable architecture on the back-end, providing every employee access to the same data, without spending all their money and IT resources trying to do a near-impossible replacement of all desktops in one big switch.

These examples use cases are just a sample of how the Sun Desktop Access Client might be able to help you and your business. I'll be posting many more use cases and customer examples in the weeks to come; however, for now, the best use case I can think of is to download the software and try it yourself! Of course you can contact your Sun sales reps and try out a Sun Ray client anytime you want. But for now, with the free 90 day trial period and the ability to use your Windows PC as a client, there's nothing stopping you from giving it a try right now!

-Jeff

Comments:

[Trackback] This post was mentioned on Twitter by jeffja: New Think Thin post: What can the Sun Desktop Access Client do for you? http://bit.ly/20fHOp

Posted by uberVU - social comments on November 12, 2009 at 10:22 AM PST #

Are there any plans for a similar client for Mac, OpenSolaris and/or Linux platforms?

Posted by Igor Minar on November 12, 2009 at 12:28 PM PST #

Yes, definitely. All of the above platforms. I'll be sure to post/tweet as new platforms become available!

Posted by Jeff on November 12, 2009 at 02:20 PM PST #

nice :)

Posted by Igor Minar on November 12, 2009 at 02:29 PM PST #

@jeff: Great news!
@jeff & @igor: I would also like to see a fast/responsive native Mac client! OSOL would be nice too :-)

Posted by gaw.in on November 12, 2009 at 03:42 PM PST #

Would it be possible to run that client in a web browser? Using Flash or something similar?

Posted by Kebabbert on November 12, 2009 at 06:27 PM PST #

@Kebabbert It is possible to start the SDAC via Sun Secure Global Desktop (SSGD). The VDI license contains also a SSGD license.

When working with VDI I would suggest to directly connect to the session via SSGD.

Posted by Remold Krol on November 12, 2009 at 06:37 PM PST #

What about smart card support in Desktop Access Client?

Posted by Bob Koutsky on November 12, 2009 at 08:44 PM PST #

Hi Bob,
It's being worked on.

Posted by Craig Bender on November 13, 2009 at 11:49 AM PST #

What would really be cool, esp for things like Kiosk Development.
Could you run Solaris + SRSS in a Virtual Box then use the Sun Desktop Access Client to access SRSS running in the VM ?
A "Howto" would be really usfull.

Posted by Alex Collins on November 13, 2009 at 11:47 PM PST #

I think that the Sun Desktop Access Client could be one of the most important developments for sunrays since they started 10 years ago.

When I talk to people about my experience of using sunrays, when I worked for sun a few years ago. I still get amazed and interested reaction, especially mobility between units using smart cards,

However the cost of migrating to sun rays instantly puts people off the idea totally. The software client goes a long way towards solves that problem.

Now I can demo the sunray concept for free and can say "you no longer have to replace every PC in one go, just as they break". This coupled with an exit option, think will help convince people to conduct more trials.

It would nice to see a live CD version of the soft client. As this would rapidly show the advantages of zero client administration.

The last physiological hurdle is that sunray 2 + RTU licence are more expensive than a low end Dell pc, the initial reaction is always the same, why are sunrays so expensive.

Currently have I have use vnc to get similar desktop mobility, but hopefully I will be show that sunrays are the way to go.

Posted by William flynn on November 18, 2009 at 08:52 PM PST #

A complete doc on what the real requirements are for using the SDAC would be useful.

I currently have the following setup:

A simple netgear router that supplies addresses and such for any DHCP client (FVS328) on my only network.

An x86 server running opensolaris 2009.06 that connects thru its main LAN if to that same network.

On that network I have 4 SunRay DTUs, and one Windows XP running Sun Desktop Access Client.

SRSS 4.2 has been configured as simply as I could manage.

no utadm -A or utadm -a, just utadm -L on.

The desktop access client has been enabled: utpolicy returns

# Current Policy:
-a -D -z both -u pseudo -g

The DTUs work nicely, getting their addresses from dhcp in the netgear box, and then discovering the server in whatever way they're supposed to.

the SDAC just doesn't work. a snoop shows NO traffic at all if the server address has been set in the SDAC config form. if the SDAC is set to discover its server, it sends a DHCPINFORM, but gets no answer.
It then sends a DHCPDISCOVER with severely mangled data, and that is repeated, with no success.

There are some obvious diffs between the true DTU DHCPDISCOVER and that from SDAC:

an excerpt from a snoop run for a DTU restarting shows the DTU asking for many more types of data in the DHCPINFORM than the SDAC does. E g SDAC doesn't ask for a no 49, XWindows server list, which a DTU will prompt for.

What kind of tests should I do, what must I add in the way of config, and so on and so forth.

Methinks the SDAC could have been documented much more exhaustively....

Posted by hans albertsson on February 18, 2010 at 01:26 AM PST #

Hans, have a look at this thread: http://www.mail-archive.com/sunray-users@filibeto.org/msg15128.html
(I'm just writing this using SDAC :-))

Posted by Hagen Heiduck on March 04, 2010 at 09:27 PM PST #

I just managed, around Feb 24, to get SunRayServer on ordinary DTUs working with Build133 of OSol. Lots of little fiddly stuff, so I had put it off for a few days. My reason was to get the ZFS dedup bits in place.

And then, as an unexpected benefit, the SDAC works: looking at /etc/sock2path, I find that it had now been changed to match what that thread suggested.

OK.

Thanks.

But the SDAC should be described in a more complete manner, methinks.

Posted by Hans Albertsson on March 05, 2010 at 04:17 PM PST #

OK, in B133, SDAC partly works. But it only works for a predetermined server address. It seems SDAC cannot actually find an SR server unless that server is identified by a DHCP server supplying SunRay specific info.

I'm not sure that's all there is to it: the DHCPINFORM and other packets arriving at the SR server are mangled and contains misspellings for the case where SDAC is supposed to seek out an SR server.

Posted by Hans Albertsson on March 07, 2010 at 06:10 AM PST #

SDAC keeps sending seemingly correct DHCPINFORM packets, but DHCPDISCOVER packets with the following odd misspelling of an Options field in the Bootstrap Protocol part:

Option: (t=60,l=14) Vendor class identifier = "mUNW.NewT.SUNW"

lower case "m" instead of upper case "S"?? Could this be a clue??

Posted by Hans Albertsson on March 07, 2010 at 04:40 PM PST #

I managed to find the problems I had had about SRSS utadm -A <subnet> config: a file contained extra chars and the primary i/f couldn't be identified. hostname.e1000g0 must say <hostname>.
This was at the root of my SDAC woes, and then I did

pntadm -R 192.168.1.0 /\* just to make sure \*/
/\* see, the SRSS stuff assumes the network has NOT been configged into DHCP\*/

utadm -A 192.168.1.0
/\* Accept defaults \*/
utfwadm -R /\* the above silly cmd unexpectedly configs in the non-GUI FW \*/
/\* So we have to remove those \*/
/\* we now config in the GUI versions instead, saying any DTUs encountered should all use the latest gui fw\*/
utfwadm -A -f /opt/SUNWut/lib/firmware_gui -N 192.168.1.0 -a

This then leaves us with two parallell DHCP servers on the same subnet 192.168.1.0: a netgear box handing out IP adresses and such, and the SRSS server's DHCP server giving the appropriate response to broadcast DHCPINFORM from SDAC and DTUs.

Now, even SDAC can find the SunRay server, fw updating works a charm, and I feel Su....Sorry, ORACLE should try and actually describe each situation envisaged in terms of "everything you really need" rather that "how it ought to look to the user". If the latter is actually sufficient, you could probably do just as well without any docs at all.

Posted by Hans Albertsson on March 11, 2010 at 05:12 AM PST #

The upshot of it all is that, unlike ordinary DTUs, SDAC actually NEEDS a DHCP server serving all the proper SunRay params.

Posted by Hans Albertsson on March 11, 2010 at 05:15 AM PST #

Post a Comment:
Comments are closed for this entry.
About

Think Thin is a collection of bloggers that work with Oracle's Virtual Desktop portfolio of products.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today