Mud, yeah. Still not clear where the portmapper runs. There's no
reason for the printer name as mapped to windows should ever change.
You should have a utaction set to update the default printer for the
user on the Sun Ray session. The name should never change as far the
user or Windows is concerned as it's just a pass-through. This is
really just follow-me printing that's been done forever.
On 9/27/11 6:29 PM, Paul Whitener wrote:
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]
<mailto:[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]>
<mailto:[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>
<tel:%2B46-13-21%2046%2000>
_________________________________________________
SunRay-Users mailing list
[email protected] <mailto:[email protected]>
http://www.filibeto.org/__mailman/listinfo/sunray-users
<http://www.filibeto.org/mailman/listinfo/sunray-users>
_________________________________________________
SunRay-Users mailing list
[email protected] <mailto:[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
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
