Monday Nov 16, 2009

Sharing is Nice: The User Tested USB Redirection List

We all learn at an early age that sharing is the right thing to do.  I get to constantly remind my 3- and 5-year old girls about this very important aspect about being a good person.

How do I get from small kids sharing to the new Sun Ray Software 5 release?  Wait for it...wait for it....

It's another ThinkThin update about the Sun Ray Software wiki!

In my earlier posts, I talked about how you can use the Comment feature on any page to leave feedback. And, I still encourage everyone to keep doing that.

But, since the SRS 5 Early Access releases, we've provided the following User Tested page for all wiki users to share the USB devices they've tested with the new USB redirection feature.



Currently, Sun supports USB redirection for all USB devices that fall within the following device types:  flash drives, printers, scanners, USB-to-serial adapters, and USB-to-parallel adapters.

The USB Redirection User Tested List lets you (the Sun Ray user community) share what devices are working for you, including USB devices not in the supported device type categories.

This page already has over 200 edits and over 100 entries from a number of users. And, I just added a Recent Contributors section that dynamically shows who has made the latest edits to the page.

So, what are you waiting for?  If you are using the USB redirection feature and you want to share the devices you are using with this cool new feature, share away! 

- Paul, SRS documentation lead

Friday Feb 01, 2008

SRWC 2.0 -01 Patch Released

The first patch for the Sun Ray Windows Connector (SRWC) 2.0 was released on 11 Jan 2008

127556-01 for SPARC/Solaris
127557-01 for x86/Solaris
127558-01 for Linux

Monday Jul 30, 2007

Time Zone Redirection and Sun Ray Connector

Suppose you had a centrally located Windows Terminal Server, but you had clients that accessed this terminal server that resided in different time zones than the terminal server.  By default, the time that their programs see would be the time zone of the terminal server.  This can can cause problems with Outlook, or other time sensitive applications.

Microsoft supports a feature called Time Zone Redirection, however it's disabled by default.  Typically if you are doing things the right way you'd have an Organizational Unit (OU) of Terminal Servers (TS) and you could enable TZ Redirection only for that OU via the AD Users and Computer snap in.  However, you can also do it on a TS by TS basis by firing up MMC and doing a local group policy.  Here's the changes you want to make to either the local or group policy:

  1. Select the group policy object you want to edit.
  2. Click Computer configuration, Administrative Templates, Windows Components, Terminal Services, Client Server Data Redirection.
  3. Open Allow Time Zone Redirection.
  4. Click Enabled.
  5. Click OK.

Note:  Changes to this setting only apply to new Windows Terminal Server sessions.

Now, let's throw another wrench in the fan.  The above works great when you have a fat client (that includes Wyse, Neoware, etc) as they keep their own clock because they have an OS and on that local OS the RDP client  runs so that's where the time zone is determined.

What if you had a Sun Ray Server on the West Coast, a Terminal Server in the midwest, and a Sun Ray on the East Coast?  Even with the above changes, the TS Session is going to reflect the Pacific time zone since the Sun Ray Server is the client because that's where the RDP client runs and therefore where the TZ is determined.

What we want though is to have the TS Session reflect the Eastern time zone, otherwise the users time sensitive applications are going to be really messed up.  Mail will have the wrong time stamps, they'll be late for appointments, etc.

What you can do is change the time zone variable on the fly.  You can even automate this so a look up is done in the Sun Ray Data store for this particular Sun Ray.  Meaning you could store the time zone information in the other or location field of the DTU.  If you only had a few you could do a simple if/then script based on the MAC address as well.

For the sake of this example let's say that we stored the time zone information in the location field of the Sun Ray Data Store for a particular Sun Ray that is on the East Coast.  That means in the location field for this Sun Ray we have the words "US/Eastern".  Then we could do the following script:

#!/bin/sh
MYDISP=`echo $DISPLAY | awk -F: '{print $2}' | awk -F. '{print $1}'`
MYMAC=`grep TERMINAL /tmp/SUNWut/config/dispinfo/$MYDISP | awk -F. '{print $2}'`
MYTZ=`/opt/SUNWut/sbin/utdesktop -Lc |grep $MYMAC | awk '{print $5}'`
if [ "$MYTZ" ];then
TZ=$MYTZ;export TZ
fi
/opt/SUNWuttsc/bin/uttsc <options>

What you'd get then is what is demonstrated in the screen shot below.  While the Sun Ray Server is actually on the Pacific time zone, we've changed the TZ variable under Solaris (or Linux) to reflect the Eastern time zone and that's what is reflected in the Terminal Server Session.  This works just fine in Kiosk/CAM mode as well, it's just easier to illustrate from a normal session since we can see both clocks.  Remember though, you must have TZ Redirection enabled on the Terminal Server and Sun Ray Windows Connector 1.1 or greater for this to work.



 

Thursday Feb 15, 2007

Sun Ray Serial Port Mapping

Mapping the serial or com ports from a Sun Ray to a Windows Session using the Sun Ray Connector for Windows doesn't have to be confusing.  Here's a handy little "how to".

First we need to determine what ports we want to map.

On a Sun Ray 2 or 2FS there is one serial port.  On a Sun Ray 170 and 270 there are two ports.  We need to know the path in order to provide it to the Sun Ray Windows Connector.

For Sun Ray 2 or 2FS the serial port is:

$DTDEVROOT/unit/dev/term/a

For Sun Ray 170 and 270 the serial ports are:

$DTDEVROOT/unit/dev/term/a

$DTDEVROOT/unit/dev/term/b

Now we need to pass those ports to the Sun Ray Windows Connector:

/opt/SUNWuttsc/bin/uttsc -r comport:COM1=$DTDEVROOT/unit/dev/term/a Windows_Server

Now what will that look like from your windows session?

Open up a command prompt and type change port /query.  You will see

Note the mapping for COM1.  That means it's going through the Sun Ray Windows Connector down to your Sun Ray.

But does it work?  Yes.  What you don't have serial device to try it?  No problem.  Telnet ssh to the Sun Ray Server.  If you need a  free ssh client for windows, give PuTTY a shot.  Sign in and then su to root (or an account that has privileges to run truss).  Find the child process for utseriald (it will be the one that does not have a parent PID of 1).  Note that while it's not doing anything you'll see a lot of pollsys' going by.  The more Sun Rays you have with serial ports the more of these you will see.

Now go back to your command prompt that you issued the change port /query command in and type dir > COM1


Watch the ssh session that you are running truss in.  You will see a flurry of activity.

 Make sure you break out of your truss before closing the ssh window.

How do you map two ports?  Easy,  we just need to pass both ports to the Sun Ray Windows Connector:

/opt/SUNWuttsc/bin/uttsc -r comport:COM1=$DTDEVROOT/unit/dev/term/a -r comport:COM2=$DTDEVROOT/unit/dev/term/b Windows_Server

Same other steps from above.  Note the difference now in the change port /query command.

You can do your same truss test as above, just for fun send the directory listing out to COM2.

I can hear it now.  That's all well and good but I don't have Sun Ray 2 series or a Sun Ray 170.  Well in this case you'll need to get a supported USB to Serial Adapter.  Let's repeat (some) of the steps with an Inside Out Networks Edgeport/2.

The serial ports live in the same place, they just don't have as friendly of names.  If you want to cheat and make the names really friendly, check out this handy dandy serial port mapping script.

# ls $DTDEVROOT/unit/dev/term
Inside_Out_Networks.V53072798-0a 
Inside_Out_Networks.V53072798-0b

Now we just need to pass those ports to Windows via the Sun Ray Windows Connector (all on one line of course).

/opt/SUNWuttsc/bin/uttsc -m -A 24 -r
comport:COM1=$DTDEVROOT/unit/dev/term/Inside_Out_Networks.V53072798-0a -r  comport:COM2=$DTDEVROOT/unit/dev/term/Inside_Out_Networks.V53072798-0b

Lather, rinse, repeat on the steps above if you want to see it in action.


Tuesday Aug 15, 2006

Sun Ray Connector for Windows OS 1.1 - Beta

The beta for the Sun Ray Connector for Windows OS 1.1 is now available on the Sun Download Center.

This release contains support for Windows Terminal Server Session Directory for session affinity/resumption. It supports both Routing token and IP based redirection.

The download is part of the Sun Ray Software 4 Update 1 Beta:


Monday Jun 05, 2006

Sending passwords using the Sun Ray Connector for Windows


When we were designing the Sun Ray Connector for Windows, we made a conscious decision not to allow users to send the password via the command line.

Why you may ask?  Perhaps this will shed some light.

$ ps -ef |grep rdesktop
craig 20344 20334 0 20:16:48 ? 0:00 /opt/SUNWrdp/bin/rdesktop -a 24 -f -u craig -p SunRay123 margaritaville

steve 20123 20111 0 20:16:45 ? 0:00 /opt/SUNWrdp/bin/rdesktop -a 24 -f -u steve -p T3mecu!a margaritaville

For those that don't understand the above concern, it means that anyone who has access to run "ps" can read the password should someone choose to pass it on the command line.  That pretty much means anyone who is logged on to the \*nix server.

If you want to safely pass the password to the Sun Ray Windows Connector (or RDesktop for that matter) from the command line, you can do so with expect.

#!/opt/sfw/bin/expect
spawn /opt/SUNWuttsc/bin/uttsc -m -A 24 -u craig -p Margaritaville
sleep 1
expect "Password: "
send "SunRay123\\r\\n"
wait -i $spawn_id
#end of script

This will allow you to safely send the password via a script and not worry about snoopy people out there.

Hope that helps!

Tuesday Apr 04, 2006

RDP Beta Refresh!


The Sun Ray Connector for Windows Beta 2 is available today!
Check it out.

Thursday Feb 23, 2006

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.

Wednesday Feb 22, 2006

Sun Ray RDP Client


In beta now, check it out.

Sun Ray Connector for Windows Beta
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