Think Thin: Thin Client and Server Based Computing Group Blog

Not too long ago a customer asked me what was the limitation for a Windows XP desktop as delivered from a VM to a Sun Ray. I didn't know what were the limitations for Windows XP itself and I had never had the opportunity of experiencing it myself, so I went on a techo quest to "do it".

The question has a few implications, and I'll explain as I go, but the first one is, what is Windows XP really capable of? The answer as found here, is 4096x2048, as long as your client can handle it. As it turns out, the Sun Ray Windows Connector can.

The next thing was to match that to something that could be handled by the Sun Ray Display capabilities. If you look at the largest resolution from the Sun Ray range, a Sun Ray 2FS maxes out at 3840x1200... (that's 2 x 1920x1200). Not quite big enough. This is a job for the multihead feature!

So the next avenue of exploration was to figure out a multihead config that made sense. Instead of doing the maths, I went and ruffled through the Sydney Solution Centre to see what my test base would look like, and found a number of Sun Ray 1 and 1G units and a few 19" monitors. As the monitors were 1280x1024, the best possible fit came to be 6 monitors in 3x2, with a total resolution of 3840x2048. Close enough this time :)

After creating a multihead group with the right configuration, I connected this to my Windows XP VM, and this is the result!

And yes, this was done using 4-8 year old Sun Rays... Doesn't get better than this! The only way I was able to showcase performance on a screen this size, was to run a screen saver. This is now a permanent demo at the Sydney Sun Solution Centre.

While I was lurking around Brian Madden's site, I stumbled upon a free tool called ReconnACT from Log*in Consultants out of the Netherlands.

Like utaction it performs actions on a session start, a disconnect, and a reconnect.  Except it does this based on session starts, disconnects and reconnects of a terminal server session

If you couple this with Device based TS CAL's,  Sun Ray Connector for Windows, and you don't use the optimized hot desking switch (i.e the -O option) you can do some pretty cool things should you hot desk to another DTU.  Like tell an application that the client has changed, or perhaps a utaction on the Sun Ray Server side could call a script that would scribble information into a text file on a mapped drive.  Then you could run a windows based script based on the information in that text file.  Maybe it's a COM port change, or a printer change.  Maybe it's someone connecting from a DTU on a disallowed subnet so you end their Windows session.

You can download Reconnact 1.3 here:
http://portal.loginconsultants.nl/forum/index.php?board=16;action=display;threadid=685

Extract the file ReconnAct!.exe (Don't use ReconnAct!2K.exe as that is only for windows 2K) and place it in C:\Windows\system32

You can download some sample scripts I put together here::
http://blogs.sun.com/ThinGuy/resource/reconnact/reconnact.zip

Extract my scripts to the the root of the C: drive on your terminal server.  It will create a directory structure called C:\reconnact.

Then set your logon script (via whatever method you like, GPO would be best) for windows to run c:\reconnact\reconnact.cmd.  If implementing on a domain, move the reconnact directory to a public share somewhere.   You'll have to change the scripts up a bit to reflect the new location.

Reconnact will then run:
C:\reconnact\start.cmd on startup
C:\reconnact\discon.cmd on a disconnect
C:\reconnact\recon.cmd on a reconnect.

Under the C:\reconnact you will see folders called S, D, and R.  (S for Start, D for disconnect and R for reconnect).  Just simple naming, play along for the how to, then change to what ever suits your needs.

The start, discon, and recon scripts look in these directories for script (cmd files) and runs each one it finds.  So if you wanted to add another disconnect action you wouldn't have to edit the login script, you'd just drop a command file in the the D file.

Right now I have a sample script in each directory to pops up a message stating "Start Message", "Reconnect Message", etc.  The disconnect message won't show, unless you happen to shadow the disconnected sessions since you have to be connected to see it work.  If you'd like to see it do something on a disconnect change C:\reconnact\D\hello.cmd to do something like launch the control panel (i.e. replace the script contents with the words "control.exe")

Here's a screen shot from a new connection. Nothing much to see here that you couldn't do with a login script, something under the Run registry key, or even the Startup programs group.

The coolness factor comes into play when you disconnect or reconnect.  If you are using non-optimized hot desking with the Sun Ray Connector for Windows to a Terminal Server in Device Mode for TS CAL's, we actually disconnect and then reconnected you to ensure proper allocation of CAL's .  The following image shows the above mention change to run control panel on a disconnect and then you also see the reconnect message.

Note this will not work if you are in User licensing mode for your TS CAL's.  Your session will not get disconnected regardless of the optimized hot desking switch as we do not need to track device based CAL's.  You could however use xvkbd via utaction to send a disconnect sequence or even kill your Sun Ray Connector PID as a work-around.

Would be great in the world of VDI, except it does not run on XP.  I've exchanged a few emails with Log*in Consultants, but nothing much has transpired.  I'd love to see something agent based that could be called from the Sun Ray Session that would do certain windows functions based on DTU connects and disconnects.  Most likely that's something Sun will have to write themselves.

Nonetheless, it's still worth checking out.  It's a great tool for terminal server if for nothing else than to forcefully log off those timed out disconnected sessions!

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.