Hi Craig, Our print setup is simply a function of the rdesktop command line. When you login to Rhel5, we use an .Xclient script to launch rdesktop in full screen with printers being passed on the command line. Every user gets the same command line. They login to Win2008 and it then launches the medical application the doctors use.
We noticed that when we tried to use uttsc and kiosk mode, the portmapper file would have the printers set on one set of ports. When a card was pulled and reinserted on a different DTU, the ports in the file changed, causing the printers to have different numbers associated with them. So for example, on first card insert a printer in the list may look like laserjet(3). When the card is moved to a different DTU and the user prints again, the printer may say laserjet(7). It also would not always print. We do not see this behavior with rdesktop. But now we see occasional lockups as I mentioned. Clear as mud huh? /paul On Tue, Sep 27, 2011 at 9:46 AM, Craig Bender <[email protected]>wrote: > Can you clarify what you mean by port mapper? Are you talking about follow > me printing? > > > On 9/27/11 6:43 AM, Paul Whitener wrote: > >> Thanks Peter! I will check it out! >> >> On Tue, Sep 27, 2011 at 8:31 AM, Peter Åstrand <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> I have a RHEL5 server with 4GB ram running SRSS 5.1. We have >> about 10 users across 15 DTUs. We "were" using uttsc to >> connect to a remote (states >> away) Win2008R2 termserver that once logged in pushes a single >> app. We >> found that when a user pulled their card to move to another DTU, >> the >> portmapper in RHEL5 changed the printer ports from the original >> session used to new ports. This caused printers not to redirect >> to the new session >> correctly and caused all kind of print fun for the users! If >> they did >> redirect, the "printer number" changed and the this confused the >> users. >> >> So we moved to using RHEL5's rdesktop implementation. It does >> not seem to >> have issues with the mapper and the session and printers stay >> statefull. >> Printers work great. However, as DTU usage has increased with >> students in >> full session, we are seeing lockups on the DTUs. The lockups >> seem to be >> random. We can not pin it to any one operation done on the >> Win2008R2 >> server. Interestingly enough, if the user goes to a laptop and >> pulls the >> rdesktop session to it, the session unfreezes and they can >> work. They then pull it back to the DTUs and continue. >> >> >> Are you running rdesktop in full screen mode, or in a window? RHEL5 >> ships with rdesktop 1.6.0, which does not work very well with 2008 >> R2. I suggest that you try rdesktop 1.7.0 instead. If the problem >> persists, try a "strace" on the rdesktop process. That should give you >> a clue about what's going on. >> >> Best regards, --- >> Peter Åstrand ThinLinc Chief Developer >> Cendio AB http://www.cendio.com >> Wallenbergs gata 4 >> 583 30 Linköping Phone: +46-13-21 46 00 >> <tel:%2B46-13-21%2046%2000> >> >> >> >> >> ______________________________**_________________ >> SunRay-Users mailing list >> [email protected] >> http://www.filibeto.org/**mailman/listinfo/sunray-users<http://www.filibeto.org/mailman/listinfo/sunray-users> >> > ______________________________**_________________ > SunRay-Users mailing list > [email protected] > http://www.filibeto.org/**mailman/listinfo/sunray-users<http://www.filibeto.org/mailman/listinfo/sunray-users> >
_______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users
