Tuesday Apr 02, 2013

Oracle Desktop Virtualisation Information and Documentation Links

One of the most common requests people like me get is for "information" and "documentation" (and aren't they the same?) - so here goes a list of the most important and regularly referenced ones, kept up to date:


    The above all drill down into important pages, of which the below I refer a lot of people to very often:

    DOWNLOADS IN GENERAL (links above too)

    They are all here: edelivery.oracle.com, the "Oracle Software Delivery Cloud ". Just select "Oracle Desktop Virtualization Products" and your product of choice, VDI, SRS or SGD. The Oracle Virtual Desktop Client (OVDC) can also be downloaded from there, just pick a Sun Ray distro to download and you will be presented with the OVDC as a choice too. The OVDC for iPad is available through the Apple App Store.



    We have a dedicated Forum "Virtual Desktop Infrastructure and Sun Ray Clients" - Feel free to join!

    Note: Down under, we "Virtualise the Data Centre". I hear that elsewhere, they "Virtualize the Data Center".

    Wednesday Dec 22, 2010

    A simple Regional Hotdesking setup (AMGH)

    The simplest AMGH setup will have two Sun Ray servers (or potentially two Sun Ray Failover Groups, aka FOGs).

    In my scenario, there is a "landing" Sun Ray server, which in fact happens to be a OVDI 3.2 host, which is, of course, Solaris x64. This host is used primarily for presenting VDI desktops (Windows and Solaris) from a couple of different pools, and there is an allowance for Solaris desktops on the server itself, only for administration purposes. Let's call this server "OVDI".

    The second server in use for the AMGH group, is an OEL 5.5 host, running Sun Ray Software 5.1 for Linux (but it can be Solaris just as well.) A completely different beast from the above. Let's call this server "OELSR".

    The purpose is to be able to present "Sun Ray" native Solaris, Windows and Linux desktops onto the same Sun Ray(s), which of course makes for a rocking demo.

    Let's start with the work on the first server, the landing server, OVDI:

    1. Create the text file DB for tokens, stock standard so that the exsiting scripts don't need customising:
    touch /opt/SUNWutref/amgh/back_end_db

    2. Add a test token to the above file - if you are reading this blog entry, I'm sure you know how to get one! insert_token is the preferred vehicle as it covers registered token policies.
    insert_token=Payflex.500db85200230100 username=daniel host=OELSR

    3. Enable redirection on OVDI, using the stock standard demo script supplied with the software
    /opt/SUNWut/sbin/utamghadm -s /opt/SUNWutref/amgh/utamghref_allkeys_script

    4. Add other tokens as required. This is a demo after all.

    Believe it or not, that's it for this server.

    Now the second member of the RH group, OELSR:

    For OELSR, The job is actually easier, since no Sun Rays should "land" on it by default, so all we want is to redirect any Sun Ray that lands on it to return to its original server when the token is pulled out of the Sun Ray.

    1. Create a return script file, need to make it executable
    touch /opt/SUNWutref/amgh/utamghref_return
    chmod +x /opt/SUNWutref/amgh/utamghref_return

    2. Edit the file and copy the code below:
    echo "use_firstserver=true"
    exit 0

    3. Enable the above script as the redirection script:
    /opt/SUNWut/sbin/utamghadm -s /opt/SUNWutref/amgh/utamghref_return

    And that's it! Now you have two FOGs and one cool flexible platform.

    This has been useful to me in the past in particular for these scenarios:
    - There is a single strategy for Sun Ray server lookup (say DNS, by using sunray-servers) but multiple separate Sun Ray servers

    - Upgrading customers from an older Sun Ray (or VDI for that matter) platform to a newer one, on different hardware, while keeping a backup strategy in place
    - Sitting at one desk but needing instant access to multiple (very) different desktops on different infrastructure

    Thanks go to Bob Doolittle and his "Getting Started with AMGH" How-to.

    Thursday Apr 16, 2009

    Kiosks and Firefox: Overriding or disabling "Firefox has been updated", making Firefox the default browser, and fix the homepage

    I couldn't pass the opportunity of writing a note to myself on this one.

    Next time you are setting up Kiosk mode with Firefox as an application, here's how to get rid of the annoying behavior of Firefox telling you about the update...

    Just copy/paste this preference:
    user_pref("browser.startup.homepage_override.mstone", "ignore");

    In the most convenient location for you:
    1) prefs.js on your user profile
    2) prefs.js on the global profile (firefox/defaults/profile/prefs.js)
    3) user.js on the global profile (firefox/defaults/profile/user.js)

    And... making Firefox the default browser? Easy...
    user_pref("browser.shell.checkDefaultBrowser", false);

    And...another one of my favorites, to fix the homepage, (best to put it in user.js:)
    user_pref("browser.startup.homepage", "http://au.sun.com");

    or just copy/paste the lot...
    user_pref("browser.startup.homepage_override.mstone", "ignore");
    user_pref("browser.shell.checkDefaultBrowser", "false");
    user_pref("browser.startup.homepage", "http://au.sun.com");

    UPDATE 16-June-2009:
    And yet, sometimes Firefox stills asks if you want it as the default browser?

    Well, don't despair - this one seems to be the ultimate fix:
    - Edit [FIREFOX INSTALL DIR]/defaults/pref/firefox.js
    - Change browser.shell.checkDefaultBrowser from true to false

    Friday Feb 06, 2009

    Meta Kiosk: How to run multiple different types of kiosk modes on a Sun Ray Server/FOG

    "One Kiosk to Rule Them All"...

    One of the coolest features of the Sun Ray platform is "Kiosk Mode". Sadly, it typically only gets associated with running a "Library" type locked down session with a web browser, or when a Windows deployment takes advantage of it to deliver Windows based sessions, be it from Terminal Services or VDI.

    It is very common in demo environments and even in many production environments to have the need of presenting multiple different types of Kiosks served from the same infrastructure, which can be easily achieved by associating the token presented to the Sun Ray to the particular context required for the token. For example, you may want a number of users to get a session from a Windows Terminal Server, some others to get a Linux desktop, some users to leverage a VDI desktop, some Sun Rays in public areas to present a controlled desktop with a web browser for leasurely access and a Sun Ray in the foyer permanently running a presentation to a large LCD display. And of course, the administrator may want access to his Windows Vista desktop on a casual basis without having to rely on the Sun VDI broker. All of this from the Sun Ray Server or FOG.

    In my experience, it has been mighty useful to have a fixed framework I can use at PoCs and demos for a variety of things. The piece of work presented here is an aggregation of some of the work that grew from a requirement at a large PoC in South Australia when Sun VDi wasn't around and also from the current demo environment shown to customers at the Sydney Sun Solution Centre.  There is a WOW factor that still grips the imagination of most people when they see the Sun Ray platform in full action. I mean, who's ever seen a handful of different desktops presented on the same screen in less than 10 seconds???

    The purpose of this "Meta Kiosk" (or Kiosk Broker) is to provide multiple kiosk capabilities to the Sun Ray platform, which is typically constrained by the use of a single kiosk mode across the board. One day, Engineering may give me a pull down in the Token Administration GUI for me to choose what the token is supposed to do, but for now, this is the next best thing.

    So, how does this "Meta Kiosk" come together? Meta Kiosk leverages the "Other Info" field of any token (a smartcard ora  pseudo token of a Sun Ray) by letting you specify a string to identify what type of session that token is entitled to, for example UTTSC, JDSKIOSK, VDA, VDANOCARD, VNC, etc. Additionally, you can specify a default kiosk mode for non-registered tokens, by changing  the UNREG_TOKEN_ACTION variable in the script. After the script decides what Kiosk the token is entitled to, it actually instantiates that particular kiosk mode, as if it had been called naturally by the Sun Ray kiosk framework. Should the first string in the "Other Info" field not be recognised, the action indicated by the variable DEFAULT_ACTION will be undertaken (which can also modify. DEFAULT_ACTION for registered tokens in the script is to use VDA, which is convenient as the VDA script also makes use of this field as the placeholder for the poolname the token owner is entitled to from the available SOE pools.

    The only caveat to this is that typically, the arguments passed to the kiosk session are defined in the Sun Ray Admin GUI setup for the system-wide kiosk mode you choose, but since Meta Kiosk calls upon a large number of kiosks itself, this is no longer useful. To work around this, the script assumes that the parameteres you want for a specific kiosk mode are actually contained in the relevant "kiosk.conf file for that particular kiosk, typically found in /etc/opt/SUNWkio/sessions. For example, if I wanted to enable Full Screen to all the uttsc kiosk sessions, I would simply edit /etc/opt/SUNWkio/sessions/uttsc.conf and type something like KIOSK_SESSION_ARGS="-t 1800 -- -m mywindowsterminalserver".

    What options can I enter in the "Other Info" field of a Sun Ray token?
    Below are the different options available "out of the box" with the present release of Meta Kiosk, along with some of the features, that you can specify in the "Other Info" field of your tokens - and don't forget you can add any of your own easily by editing the script at /etc/opt/SUNWkio/sessions/meta-kiosk/meta-kiosk-session (and if you do and you consider it useful, please share it with me!):

    : for the traditional Solaris based locked down Sun Ray kiosk mode
    "Other Info" field specs: JDSKIOSK

    : to make a call upon a specified Windows (or RDP capable) system, whether it is a physical PC, a VM, a WTS or a session directory server or the console of a VirtualBox VM with VRDP...
    "Other Info" field specs: UTTSC [username [target system]]
    UTTSC can leverage the main system name passed in the uttsc.conf file, presented as the last field of KIOSK_SESSION_ARGS. If username is present, then this name will appear in the login box (where possible). If "target system" is specified this field will be stripped from the uttsc.conf definition and replaced by that found at "Other Info". Note that when you configure the uttsc kiosk mode, it is expected that you enter a system name at the end of the string. As such, Meta Kiosk expects this too.

    : In case you need or want to register it. Note that the script will treat this as the default mode for any \*registered\* token anyway.
    "Other Info" field specs: VDA
    the VDA kiosk script will later re-read and interpret this field as a pool name, so typing  any parameters would be useless! If this is used with VDA, then a default pool called VDA can be setup, unless you have already assigned the username a permanent virtual machine.

    : In case you need or want to register an existing token or  pseudo-token to use Dirk Grobler's "Non Card VDI for Sun Ray".
    "Other Info" field specs: VDANOCARD

    : In case you want to use VMware's broker in your environment separately. You will need to download the Sun Ray connector for VMware Virtual Desktop Manager and install it (guess what - it's a kiosk mode too!)
    "Other Info" field specs: VDM

    The next options are not not defined typically as kiosks. Their code is contained within the Meta Kiosk script itself:

    : Experimental at this point, useful mostly for MACs (not that you couldn't use with Solaris/Linux or even Windows), by way of leveraging  a VNC server or similar (the builtin ARD server does NOT work with standard VMC clients)
    "Other Info" field specs: VNC [system-name [password]]
    Both parameters are optional, although you can't specify password if you don't  specify a system name. Password will get written to a file and then the argument  passed through, and although this is not dramatically secure, it allows for a  quick demo of a MAC on a Sun Ray. A good VNC server to use is Vine. You may need to pass the port to the VNC service on the server as part of the system name, e.g. mymac:5901   

    : Let's you run a specified Solaris app, but take heed, there will be no Window manager for it. Otherwise, simply use JDSKIOSK and specify the app there.
    "Other Info" field specs: APPLICATION command-name <parameters>
    For example, you could run a full screen presentation on a dedicated Sun Ray like this, like we do at the foyer of the Sydney Sun Solution Centre:
    APPLICATION /usr/bin/staroffice -invisible - nologo -show /presentations/sunray-presso.od

    UTSWITCH: Need a token to get redirected without AMHG? This is it!
    "Other Info" field specs: UTSWITCH sunray-server-hostname
    Beware that the Sun Ray will remain attached to that other Sun Ray server when you pull the smartcard or disconnect the session, so it's important to remember to STOP-A the Sun Ray at the end of the session.

    : An Xsession. This will run Xnest within the Sun Ray X session canvas.
    "Other Info" field specs: X11 servername [geometry]
    NOTE: On your Sun Ray server, you may have to execute this: chmod 04755 /usr/openwin/bin/Xnest ulness Xephyr is available.

    : An X term (xterm) on the Sun Ray server. Good for testing!
    "Other Info" field specs: XTERM
    It also starts twm as the window manager. Just good to have...

    Meta Kiosk Workflow - how does a kiosk mode get chosen?
    The following diagram depicts the default actions chosen by the script based on the token conditions, i.e. Token registered or not and "Other Info" field contents:

    Putting it all into action
    The requirements are quite simple:

    • DOWNLOAD "Meta Kiosk" (TAR file)

    • Unpack the downloaded file on a Solaris Sun Ray server: the files are created from the root directory, straight into /etc/opt/SUNWkio/sessions.

    • Under the Sun Ray Web Admin go to Advanced -> Kiosk Mode.

    • Choose "Meta Kiosk Broker Session" from the kiosk options pull down.

    • Pick any Solaris apps you desire to run under the JDS kiosk mode (if at all) as part of the Meta Kiosk, instead of JDS.

    • For EACH and ALL kiosk modes you will be employing that requires it, make sure you edit the associated ".conf" file in /etc/opt/SUNWkio/sessions and include the parameters you want to regularly use: simply type them in for that kiosk mode under KIOSK_SESSION_ARGS (see example above for UTTSC.)

    • Pick the default action you desire for unregistered tokens (if your policy allows) by editing /etc/opt/SUNWkio/sessions/meta-kiosk/meta-kiosk-session and assigning it to UNREG_TOKEN_ACTION (see Flow Chart above.)
      NOTE: By default the script assumes that unregistered tokens get JDSKIOSK as the default, and if this is what you want, make sure you specify something like Firefox as a Critical app under the Meta Kiosk app pane.

    • Pick the default action you desire for registered tokens that do not present an identifiable string in "Other Info" by editing /etc/opt/SUNWkio/sessions/meta-kiosk/meta-kiosk-session and assigning it to DEFAULT_ACTION (see Flow Chart above.)
      NOTE: By default the script assumes this to be VDA, the Sun VDI broker

    • Don't forget you need to have the token registered AND set as a Kiosk token for any of this to work.

    • If you want to assign a kiosk mode to a Sun Ray without using  a smartcard, simply register the pseudo token of the Sun Ray through the Web Admin GUI. The token is always "pseudo.<MAC address>" of the Sun Ray you need. This is often done under VDA to present the same Windows VM to the same person at the same desk all the time (much like ... your PC.)

    Enjoy and make sure you share any other worthwhile uses you can think of...

    UPDATE 19/02/2009:
    Made some improvements on the X11 kiosk - it now works with Centos and OpenSolaris, thanks to the use of Xephyr on Solaris 10 x86

    UPDATE 02/07/2009:
    For a pure and supported methodology on assigning different kiosk sessions to different tokens, there's a new feature available since SRS 4.1 that allows individual Kiosk session assignment to different tokens. For more info, please visit Jörg Barfurth's blog entry "Using different Kiosk Sessions for different tokens". Thanks Jörg! While I'm on this subject, could engineering please deploy a kiosk selection pull-down on the token administration page in the Sun Ray web admin? Ta :)

    Thursday Jul 24, 2008

    A "USB Drive" daemon for Sun Ray sessions - AKA "usbdrived" (V2)

    Hopefully you are reading this because you either have a need to better present USB disks via the Sun Ray platform or because you are an "existing customer" of version 1, first blogged here.

    After looooong in the making and with careful analysis of requirements and listening to useful feedback from the likes of Brad Lackey, I am pleased to announce that "version 2" of the good old "usbdrived" is finally ready  (well, not really v2,  it has had more iterations than that...)

    Features that you will find in this version are:

    1. Multiple mount partitions & drives connected to the same Sun Ray

    2. Mount point "unwriteability" (Yeah!)

    3. Address Gnome/JDS and Windows sessions from the same script, automatically

    4. Polished Disk icons on Gnome/JDS (instead of links)

    5. No stale mount points presented to the end user

    6. Usage documentation provided as text files on the desktop/mountpoint (this can be switched off)

    7. Installer for system-wide or single user with no root permissions

    8. Single point of aggregation for all Windows mounts (Drive "USBDRVS")

    Simply download it, and then execute it (chmod +x first) on every Sun Ray server of your FOG, like so:

    ./usbdrived install

    Option 0 will give you generic install instructions... Enjoy!


    I get a lot of comments telling me "it doesn't work, can you help me?" - as it turns out usbdrived is actually a pretty simple beast, and if you think it's not working, you may be looking in the wrong place. Start with some of these hints:

    • Can you see usbdrived running in your Solaris session? (ps -ef | grep usbdrived)

    • Can you see a file called "Attaching USB Drives to your Sun Ray README.txt" on your Solaris desktop?

    • Did you install it properly? If so, can you see and what permissions does this have:
      It should be executable by everybody, something like rwxr-xr-x

    • When you plug in a USB drive, does it mount in /tmp/SUNWut/mnt/<username> under Solaris?

    • Under Windows, can you see in  "My Computer" a Network drive (In "Others") called "USBDRVS" and is there a file within that explains usage?

    • Have you hit refresh in file manager when looking at your USBDRVS mount?

    • Most important and useful of all: Do any mounts show up if on a Solaris Sun Ray session you issue:
      /opt/SUNWut/bin/utdiskadm -l

    • With Sun VDI 2.0, make sure that you have properly positioned your arguments in the kiosk call, as "-service hostname" needs to be the last parameter:
      -t 1800 -- -m -b -r disk:USBDRVS=$HOME/USBDRVS -service localhost

    • With Sun VDI 3.0, this works for me:
      -- -m -b -r disk:USBDRVS=$HOME/USBDRVS
      where the actual vda kiosk parameters go to the left of "--"

    • With the Sun Ray Connector for VMware View, this works for me:
      -s viewmanager-server -http -- -m -b -r disk:USBDRVS=$HOME/USBDRVS

    • Unfortunately, NOT ALL USB drives work. Some drives, Solaris refuses to mount (PCFS issues) either because the device is simply not "liked", or because Solaris can't read the file system. Look at "dmesg" for errors.

    • Is your drive FAT16/32 or is it NTFS? The latter does not work, the formatting mut be FAT.

    • Many people have asked me why passing the parameter does not work
      as explained within the script... It appears that people look at the guts of the
      script to understand the instructions and bump into the line that reads
      -r disk:USBDRVS=\\$HOME/USBDRVS
      and assume that that is the literal context. Noooooo! That "\\" is there
      so that when you read the instructions offered via the command line
      option of "usbdrived install" and press "0", the actual HOME directory
      of the user is not displayed...

    NOTE OF SUPPORT: This tool is provided as is. It is not supported by Oracle. If you find any issues, please contact me and will try to help!

      Monday Feb 18, 2008

      Reaping (culling) Sun Ray sessions after a disconnect

      Here's a simple way of conserving system resources under Solaris when you have a lot more users than Sun Rays. The idea is that if a user doesn't connect back to his session after a grace period, then his session is destroyed. Just make sure that your users know that their sessions have a limited time span, so they can save their work!

      First, create a script called "reap-session" somewhere in your system, let's say /opt/SUNWut/scripts/reap-session. Make sure that you make it executable for everybody. The script, although very simple, is just there to save me some time :) in coding. It should be something like:

      GRACEPERIOD=7200      #That's two hours.
      sleep $GRACEPERIOD
      pkill Xsun

      That's it for the little script.

      Now, you need to invoke the script in the following manner, for those users whose sessions will be culled within GRACEPERIOD seconds - typically by executing in the .profile of the user:

      /opt/SUNWut/bin/utaction -d /opt/SUNWut/scripts/reap-session -c "pkill reap-session " 1>/dev/null 2>&1 &

      The way it operates is quite simple: as soon as the smartcard is pulled out, the timer is started via the disconnect utaction. If the user plugs his card back into the system before the timer goes off, then the connect utaction kills the timer and forgets the whole thing, to start afresh upon next pull of the card.

      If, however, GRACEPERIOD elapses, then the timer goes off and the script kills the window manager for the user, and of course, with it, the whole session. Next time the user plugs his smartcard, he'll just see the login.


      Friday Dec 07, 2007

      Sydney Business and Travel Academy - A Cool and Heterogenous Sun Ray Setup

      After running a little proof of concept (I spent less than half a day there) at the Sydney Business and Travel Academy (SBTA) I was surprised with the speed at which things moved there to make Sun Ray the desktop platform of choice. That's when it became obvious to me the amount of pain they were going through with their current setup of about 200 PCs and servers running Linux, LTSP and Windows. Enter Sun Ray, and all of a sudden, it's a fresh start for them - three servers for the whole joint, nothing to manage at the desktop nevermore, Windows using the Sun Ray Windows Connector for those who must, and only those who must, and mobility to become a given.

      For students, there's little change, except the open source desktop they use on the new "workstations" is Solaris' JDS with StarOffice. Better yet, the students got locked down to printed smartcards with their student details on them, and access to the system only with a registered smartcard, hard tied to their login (no card sharing!) At the end of their tenure, their card is de-registered to revoke access forever, and so the card just becomes a memento.

      But by far the most interesting thing about their deployment (let's face it, the above functionality is just standard functionality of the Sun Ray framework)  is how they physically locked the Sun Rays down to the desks, using a clever little bracket dreamed by the systems integrator and Sun partner, Noveix, and made by Argent . Check the pictures below for a simple and fantastic way of providing "locked-down" access to a workstation:

      So, in the face of this, I decided to re-acronym SBTA: Special Bracket is Totally Awesome! And, monitors screwed to the desk too. Sweet!

      In closing, this is what the same room looked like before - sorry I can't reproduce the noise!

      Thursday Jul 19, 2007

      Sun Ray, x4600, VMWare ESX stories from the trenches

      There are stories about trenches - this a big trench! (well, in thin trench sort of way...)

      Friday Jul 13, 2007

      Enabling credentials pass-through to Windows TS running Novell Client

      It is often necessary (and useful) to be able to automate credentials pass-through from Secure Global Desktop and the Sun Ray Windows Connector to a Windows Terminal Server that uses the Novell login "GINA" (Graphical Identification and Authentication).

      Unfortunately, this doesn't work out of the box, unless you follow these instructions:

      1. Upgrade your Novell client to 4.91SP3
      2. Create the following registry entries in HKLM\\Software\\Novell\\Login
        TSClientAutoAdminLogon = 1
        DefaultLocationProfile = <LocationProfile> (Go for "Default")

      Thanks go to Jon Knight for this valuable information - and for putting it all together. I finally got a chance to test all this at a customer site and it worked instantly, and while some of this has been documented for other platforms, I wanted to make a special mention: it actually works flawlessly with both SGD AND the Sun Ray Windows Connector (which of course presents us with different challenges and opportunities!)

      Wednesday Jul 04, 2007

      Playing with the new KIOSK mode in SRS4u2

      I finally upgraded my SPARC box to Solaris 10u3 so I could install SRS4u2... it was up and running in no time and I had a go at the new interface and the new Kiosk mode. The interface is a lot slicker than I expected and some of the annoyances of the original have disappeared with it. 

      And the new Kiosk mode is also slick AND simple. The setup may take a bit of getting used to, but I had a go at setting up a JDS desktop with Firefox and it was  a breeze. Then I thought... let me add my USB drive daemon script to see how it would work, and there was no magic required- I simply added it as a critical application (from a central path) and voila! It all came to life pretty automagically - and the USB drive daemon didn't show up in the applications menu, which makes total sense. Now, if only I could lock Nautilus down...

      Further... there was some great work done in terms of locking the JDS session RIGHT down for the new Kiosk - like application execution restrictions should you happen to wander off into the forbidden woods, which should only happen if you let users do flexible things like run the file manager. Thanks go to Brad Lackey  for telling me that some features can be relaxed by passing "-s" as an option to the JDS kiosk. There's a wealth of info within the Kiosk based directories I just wasn't aware of!

      The other feature that blew me away is that regardless of your specification for Kiosk mode, you can have assigned tokens that will be granted a separate mode to the default. Next on my wish list: multiple Kiosk modes!


      A thin thinker down under


      « February 2017