I definitely have the cams script set to critical. And we are using the default RDP (not TS), but we are using one VMWare instance for each user. So the user is tied to the instance and won't get to a different session, though they could always fire off an RDP connection to the back end side if they knew what it was in the first place.
I just disconnected my session and voila, it's doing it again. It has worked fine the past couple days (since I rebooted on Tuesday), and we only have 3 DTU's connected right now. I have disconnected my session several times and it has always come back fine since Tuesday, until this morning. While a reboot will perhaps fix the issue, I will leave it like this and hopefully can investigate the issue a little further. Actually, interesting enough, when I try to access the admin webpage, it says "Your login has timed out", but I haven't logged in (and it hasn't prompted me too). It takes forever to load the main page, so perhaps I am having a bigger issue with the server itself. Daniel --- Craig Bender <[EMAIL PROTECTED]> wrote: > Another thing to check is that you have enabled TS > (Control Panel, > Add/Remove, Windows Components) and are not just > using the default admin > RDP connections that allow for only two connections. > This would result > in each DTU stealing the last connection and would > duplicate your > symptoms exactly. > > Curtis Cunningham wrote: > > Daniel, > > > > do you definitely have your CAM script set to > critical? > > > > Curtis. > > > > Daniel Doby wrote: > >> I am setting it up in CAM config mode, with a > custom > >> script to point the user to their desktop (vmware > >> windows xp instance). I have also setup a new > script > >> to do exactly what you say and just start an > xterm > >> window and it still resets. > >> > >> By resetting, here is what I see. I power on the > DTU, > >> it gets an IP address from the DHCP server, gets > it's > >> configuration, then starts whatever session is > thinks > >> it should start (uttsc or the pre-outlined xterm > >> window). No matter what the script calls to do, > it > >> starts it then about 3-5 seconds later > (regardless if > >> you do anything or not) it resets, and does the > DHCP > >> all over again (basically like from power-on). > >> > >> I did fix it, by rebooting the Sun Ray Server > itself, > >> but it has done this in the past (previously > thought > >> it was the script) so I am sure it will happen > again > >> in a few days. > >> > >> Any ideas what could be causing the issue though? > >> > >> > >> --- Curtis Cunningham <[EMAIL PROTECTED]> > >> wrote: > >> > >> > >>> Daniel .. > >>> > >>> are you setup in a CAM configuration with a > script > >>> that starts ttatsc to > >>> point at a WTS server? Your email would imply > that. > >>> You also say you > >>> constantly get the WTS login screen and then it > >>> resets. Please confirm. > >>> > >>> If this is not what you see, please describe > exactly > >>> what you see from > >>> power on of the DTU. What's the last OSD icon > you > >>> see before the reset? > >>> i.e. is it getting DHCP address, finding Sun Ray > >>> server, connecting, etc. > >>> > >>> Are you running a CAM script? If so, make a new > >>> script for CAM mode that > >>> just launches an xterm. Start that script and if > you > >>> get the xterm as > >>> expected, try executing the previous problem CAM > >>> script (that makes > >>> connection to WTS using ttatsc) from the command > >>> line inside the xterm > >>> and see what failure you get. > >>> > >>> Curtis. > >>> > >>> Daniel Doby wrote: > >>> > >>>> Anyone have any experience with the SunRay > DTU's > >>>> constantly resetting? Everything was working > fine > >>>> > >>> this > >>> > >>>> morning, I was testing out some USB hot > plugging > >>>> > >>> and > >>> > >>>> after I disconnected my current session (uttsc > >>>> session) and the DTU recycled, came back to > >>>> > >>> windows > >>> > >>>> login screen and reset. It's been doing that > ever > >>>> since. I did a utrestart -c and now all of them > >>>> > >>> are > >>> > >>>> resetting (just three test). > >>>> > >>>> It's done this several times before and each > time > >>>> > >>> we > >>> > >>>> thought it was just our script to control where > >>>> > >>> the > >>> > >>>> user's session is directed, but if I put > >>>> /usr/openwin/bin/xterm at the top of the script > >>>> > >>> before > >>> > >>>> it actually does anything else, it still > >>>> > >>> resets(and > >>> > >>>> resets, etc, etc). > >>>> > >>>> Any ideas? I am wondering if our DHCP setup > isn't > >>>> > >>> the > >>> > >>>> culprit. We are using our regular desktop dhcp > >>>> > >>> server > >>> > >>>> with the option 49 set to the ip address of our > >>>> > >>> sunray > >>> > >>>> server, which is running dhcp, just not leasing > >>>> > >>> out > >>> > >>>> the ip addresses to the DTUs. > >>>> > >>>> While I am sure it's something minute and an > >>>> > >>> oversight > >>> > >>>> for our implementation, but I have yet to > pinpoint > >>>> > >>> the > >>> > >>>> cause. > >>>> > >>>> Daniel > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >> > ____________________________________________________________________________________ > >> > >>>> Sucker-punch spam with award-winning > protection. > >>>> Try the free Yahoo! Mail Beta. > >>>> > >>>> > >> > http://advision.webevents.yahoo.com/mailbeta/features_spam.html > >> > >>>> _______________________________________________ > >>>> SunRay-Users mailing list > >>>> [email protected] > >>>> > >>>> > >> > http://node1.filibeto.org/mailman/listinfo/sunray-users > >> > >>>> > >>>> > >>> -- > >>> > >>> > >>> Desktop Technical Specialist > >>> Sun Microsystems > === message truncated === ____________________________________________________________________________________Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 _______________________________________________ SunRay-Users mailing list [email protected] http://node1.filibeto.org/mailman/listinfo/sunray-users
