One thing that can aid you in trouble next time is to create your self a
"Regular" session on the Sun Ray server. This will allow you to see
STDOUT messages and not have to parse through logs. You can do this,
even with your soft client by registering the pseudo token of your
softclient and utkioskutkiosk override.
On windows hit Ctrl-Pause-K and note the client ID, the part after S1.
Some big long number like 96d299a713c8c835d57302db005dc035
(hint, if you want to cut and paste this, use vdc.exe --client)
Then from a terminal do the following from /opt/SUNWut/bin:
utser -a "pseudo.96d299a713c8c835d57302db005dc035,localhost,0,OVDC
Mike,Mikes Laptop"
Now that your token is registered, you can use override the default
kiosk system policy.
utkioskoverride -r pseudo.96d299a713c8c835d57302db005dc035 -s regular
Now your OVDC will get a regular session, where you can log in and run
the same style of test you did from a local RDP client, but using uttsc
and all that comes with it.
On 9/2/10 12:56 PM, Michael Jinks wrote:
On Thu, Sep 02, 2010 at 12:42:14PM -0700, Craig Bender wrote:
Well, I'm not sure your test case from you linux system is valid. uttsc
stores the TS CALs it gets from windows in the SRDS. CAL problems are
just one possible problem that could lead to disconnects, but I'd say
it's probably a good chance.
That's something we're not sure of here: can a CAL be yanked out from
under a running session? I thought (and one of our Windows guys has
said) that licenses are only checked at session startup.
Data point: after running 'uttscadm -c' on the primary, I was able to
get a connection from the soft client. (Previous attempts had cycled
endlessly, making me wonder if the client was buggy or just not happy in
the environment where I'm running it.) Having established that session,
it's now been running for about half an hour with no input from me. So
either our trouble has gone away, or it doesn't apply to all cases.
Log noise has slowed down noticeably, too. Again, could be coincidence
but it's making me happy.
Hopefully you did the command on both servers?
Yep; well, last week on the secondary, today on the primary.
Maybe a cold restart of
Sun Ray Servers to get everything to a known good state now that the
proxy daemon and schema is updated.
Yeah, seems worth a try (no harm in it at least). That will have to
wait until after our last public location closes late tonight, unless we
get word that there's so much trouble with the system that it's better
to reboot mid-day.
Thanks for your help. I'm cautiously optimistic that the uttscadm
oversight was the cause of the trouble.
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
