When a token (a smartcard, or the token assigned to the user's id at the 
NSCM login GUI) is presented which already has an active Sun Ray[TM] 
session on one of the Sun Ray[TM] servers within the same failover group, 
the user gets a new login screen, or a new session, or no session at all,
rather than the most recently active session for that token.

Introduction to hot desking:
============================

Hot desking is a feature which works across all Sun Ray[TM] servers 
within a failover group. When a token is presented, the 
authentication manager checks whether there already exists
an active session for that token on any of the servers. 
If yes, then the user gets the most recently active session. 
If no, then a loadbalacing algorithm decides
on which server a new session will be created.
Note: only sessions where a user is logged in, the so-called "active"
  sessions, will be hot desked. Sessions waiting at the dtgreet
  screen might be ignored.

The Sun Ray[TM] Server Software was designed, in part, to provide hot
desking with smartcards. Configuring the Sun Ray[TM] Server Software 1.3
and higher with non-smartcard mobile (NSCM) sessions provides
the benefits of hot desking without the use of smartcards.

Both for smartcards and for NSCM, the hot desking feature requires that 
all Sun Ray servers in the same failover group have the same 
group signature. Hot desking is a very basic feature. If hot desking 
fails, it is likely that other important functionality will fail also,
because there is a misconfiguration, or because critical files
have been accidentially deleted or corrupted.


Related Patches:
================
The Sun Ray Server Software patch:
114880  Sun Ray Server version 2.0 Patch Update
111891  Sun Ray Server version 1.3 Patch Update
110666  Sun Ray enterprise server version 1.2 Update Patch
109127  Sun Ray enterprise server version 1.1 Update Patch
108303  Sun Ray Enterprise Server version 1.0 Update Patch

The dtlogin patch:
112807  CDE 1.5: dtlogin patch (Solaris 9)
108919  CDE 1.4: dtlogin patch (Solaris 8)
107180  CDE 1.3: dtlogin patch (Solaris 7)
105703  CDE 1.2: dtlogin patch (Solaris 2.6 without SDE)
106661  SDE 1.0: Solaris Desktop Extensions patch (Solaris 2.6 with SDE)

The dtsession patch:
113240  CDE 1.5: dtsession patch (Solaris 9)
109354  CDE 1.4: dtsession patch (Solaris 8)
107702  CDE 1.3: dtsession patch (Solaris 7)
106027  CDE 1.2 / SDE 1.0: dtsession patch (Solaris 2.6)

Note: these patches typically require other patches to be installed.
   Please refer to the patch READMEs before patch installation.


Possible hot desking failure scenarios:
=======================================

There exist several different failure scenarios, with different 
possible root causes, and different troubleshooting steps. 

1. Upon hot desking, the user gets neither a new session,
   nor the existing old session. Instead, one or several icons
   are displayed on the screen.

   These icons serve to identify error state. Note the sequence
   of icons. For the SRSS 2.0, see pages 195ff. of the SRSS 2.0
   Administration Guide for a detailed explanation of the icons.

   With the SRSS 1.3, the icons and the green newt are explained
   in Appendix A of the SRSS 1.3 Administration Guide, pages 95ff.

2. Upon hot desking, the user gets a new session, and the 
   old session does not exist any more. Here, the failing hot desking
   is just a symptom of the loss of the previous session. 
   Troubleshooting session loss is beyond the scope of this document.

3. The old session still exists. It is on the same Sun Ray server, but
   the user gets a new session upon hot desking.

   - Check for corruption of /tmp/SUNWut. Especially, check for
     rogue scripts or cronjobs which delete files from /tmp/SUNWut.
     /tmp/SUNWut contains crucial Sun Ray dynamic session data. Without 
     this data, both hot desking and creation of new sessions might fail.
   - Check that the dtlogin master process (its pid is stored in 
     /var/dt/Xpid) is still running, and that the Xsun process
     for the old session is a child process of the dtlogin master.
   - Check that the token which has been presented is the same as 
     the token for which an old session exists. For example,
     + the user might have inserted his smartcard the wrong way, 
       thus creating a "pseudo terminal" session, rather than 
       creating or accessing a session for his smartcard.
     + The smartcard might not have been identified correctly, 
       or the token translation for the smartcard is non-unique. 
       This issue has been observed with JavaBadge cards, where 
       the cards were recognized as one of two different types.
       4825808 is fixed in SRSS 2.0 patch 114880-01.

     To check this, get the existing sessions' actual token id
     from the corresponding file in /tmp/SUNWut/config/displays,
     and crosscheck with the corresponding lines from
     /var/opt/SUNWut/log/messages*.
   - Check whether the locale was changed, or whether
     an unusual locale was used.

4. The session still exists. It is on a different Sun Ray
   server, but the user gets a new session upon hot desking.
   This indicates a problem with the failover setup.
   Frequently, the server on which the old session resides
   simply was unreachable when hot desking was attempted.

   - Use utgstatus to check that all Sun Ray interfaces are up 
     and reachable, and that the servers are trusted.
   - On the user level, check whether utselect can be used 
     to access the existing session on the other server.
   - The policy on all servers must be the same,
     and the -g flag must be set.
   - In /etc/opt/SUNWut/auth.props, for failover to work properly
     useLocalPolicy must be false,
     enableLoadBalancing should be true, and
     enableGroupManager must be true.
   - Check /var/opt/SUNWut/log/auth_log for "token query timed out"
     messages. A network outage or an unusual loading situation 
     might be causing the authentication managers to not respond
     in a timely fashion to the token queries. 
   - Try to identify Sun Ray appliances where hot desking works,
     and Sun Ray appliances where hot desking fails. Look for
     patterns to identify network component failure.

   Example misconfiguration:

    ----------          ----------
   | Server 1 |--------| Server 2 |
    ----------          ----------
        |                   |
   Sun Rays 1            Sun Rays 2

   Sun Rays 1 are not reachable from Server 2, and
   Sun Rays 2 are not reachable from Server 1.

   Example outage scenario:


 ----------                                             ----------
|          | ge1/VLAN 1                            ge1 |          |
|          |-------------  ok network components  -----|          |
|          |                                           |          |
|          | ge2/VLAN 2                            ge2 |          |
| server A |-------------  ok network components  -----| server B |
|          |                                           |          |
|          |                                           |          |
|          | ge3/VLAN 3  ----------      --------- ge3 |          |
|          |------------|bad switch|----|ok switch|----|          |
 -----------      |      ----------      ---------      ----------
                  |             |||      |||     
          no appliances here    Sun Rays here

    Due to the bad switch, on VLAN 3 not all network traffic will get
    through from server A to server B and vice versa. Thus, both
    servers will think that the ge3 interface on the other server
    is down, or unreachable. In SRSS 2.0 utgstatus output on server A,
    you will see something like
    
serverA TN  10.10.10.1  U--  10.21.0.1  UAM  10.22.0.1 UAM  10.23.0.1  UAM
serverB TN  10.10.10.2  U--  10.21.1.1  UAM  10.22.1.1 UAM  10.23.1.1  -AM

    where the "-AM" for 10.23.1.1 indicates that this interface
    currently is unreachable or down. In such a scenario, hot desking
    to a session which resides on the other server would still work 
    on all Sun Ray appliances connected to VLAN 1 and VLAN 2, but 
    might fail on all Sun Ray appliances in VLAN 3.

5. The old session still exists, but it is a remote login session.

   Use utselect or utswitch to reaccess this session.


Steps to identify a user's token:
=================================
1. Have the user log in at the dtgreet screen.
2. Either 
   % echo $SUN_SUNRAY_TOKEN
   user.1234567890-1234    <---- the current token
   
   or
 
   % echo $DISPLAY
   :4.0

   and, as root user on the same server:
   
   # cat /tmp/SUNWut/config/displays/4
   SESSION=labhost:7007:2328000552891973400
   TOKEN=user.1234567890-1234   <----- the token
   SESSION_TYPE=default
   TOKEN_SET=MicroPayflex.5000f8ad00130100,user.1234567890-1234
   CALLBACK_COOKIE=487228897641666981
   DISPLAY=4
   INSERT_TOKEN=MicroPayflex.5000f8ad00130100

   will provide you with the user's token. You can then 
   grep through /tmp/SUNWut/config/displays on all servers 
   to check whether there exists another session for the same token.


Steps to find existing sessions for a user:
===========================================
1. using the user's unix id, grep the ps output
   for Xsun processes owned by the user to identify the 
   corresponding display number:

   # ps -ef | grep testuser | grep Xsun
    testuser 20041  1165  0 14:41:53 ?  0:04 /usr/openwin/bin/Xsun :4
-nobanner -auth /var/dt/A:4-39aOrc -dpms
   In this example, the display number is 4.

   In an environment where Xsun is not used, you can grep the ps 
   output for dtsession or other processes owned by the user,
   then use ptree to identify the corresponding dtlogin child process, 
   and get the display number from that process:

   # ps -ef | grep testuser | grep dtsession
   testuser 20343 20298  0 14:57:07 pts/15   0:00 /usr/dt/bin/dtsession
   

   # ptree 20343
   1165  /usr/dt/bin/dtlogin -daemon         <--- dtlogin master process
      20044 /usr/dt/bin/dtlogin -daemon      <--- dtlogin child process
         20220 /bin/ksh /usr/dt/bin/Xsession
            20296 /usr/dt/bin/sdt_shell -c unsetenv _ PWD; unsetenv DT;  
               20298 -csh -c unsetenv _ PWD; unsetenv DT;setenv DISP
                  20343 /usr/dt/bin/dtsession
                     20349 dtwm

   # /usr/ucb/ps -axuwww | grep dtlogin | grep 20044
   root     20044  0.0  0.7 7088 3824 ?        S 14:41:54  0:00 dtlogin<:4>        -daemon

2. Get the corresponding displays files from
   /tmp/SUNWut/config/displays, and extract the TOKEN.

3. Crosscheck whether there are other display files
   with tokens tied to this user. 



References:
utselect(1)
utswitch(1)
utgroupsig(1M)
Sun Ray[TM] Server Software 2.0 Administrator's Guide, chapters 5 and 11

See page 111 of the SRSS 2.0 Admin Guide for possible related network
configuration issues. Use utcapture to check for packet loss and latency.