Hi Chad,
Your best shot is the DMCFG file and some expert advise from the Schneider
service engineers.
We have computer names tied to environments and DM names in the DMCFG, so an
operator can only open the "operator" environment and only use a ltd number of
dedicated DM names, so he cannot "consume" all of the available RDP foxview
licenses.
But we don't use session time out's.
Maybe someone has a script that identifies the DMname used on the remote
station and closes this session after a given time. It's not something we use,
but I guess it's not very difficult to setup for an experienced service
engineer.
Rgds,
Dirk
-----Oorspronkelijk bericht-----
Van: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] Namens ;
Chad Ziesemer
Verzonden: woensdag 24 augustus 2016 17:28
Aan: foxboro@xxxxxxxxxxxxx
Onderwerp: Re: [foxboro] Remote Desktop Smurfing All Graphics
Brahm, this sounds promising. At the top of my current foxview window from an
RDP session I see "FoxView GNAW01:RDM013". I logged out and back in and got
"FoxView GNAW01:RDM010". This looks like the 'floating' sessions you
mentioned, so I dove in to try to make the change you suggested and got a bit
stuck. In my dmcfg file I have 20 lines in a row of "NAME GNAWO1 RDM001 -
foxDefault" with RDM001 incrementing from 01 to 20. GNAW01 is the letterbug of
the server we are remoting into. I'm assuming somehow I have to replace all
the GANW01's with the individual thin client id's? Where/how do I get the
individual thin clients to be identified as something else besides GNAW01 when
they log-on?
Dirk, we train users to File->Exit, but that doesn't happen when the idle
session limit is reached and the RDP session is disconnected them terminated.
Any chance there's a script or way to automate the "File->Exit" after a period
of idle time rather than allowing the RDP server to disconnect and log them off?
Thanks!
Chad
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Neufeld, Brahm
Sent: Wednesday, August 24, 2016 9:01 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Remote Desktop Smurfing All Graphics
Chad, we had an issue very similar to what you were describing. "Random"
lockups on the server, freezing all sessions. The specific behavior we observed
is the display would look fine, then we'd navigate to a new page and it would
just hang. Can't recall if it went cyan. Server had to be rebooted, which was a
PITA as several thin clients are used for regular ops, and the box is also our
AIM historian.
Troubleshooting was very frustrating until we correlated the freezes with one
of our process engineers logging on and off improperly and using more sessions
than should be allowed.
We eliminated the problem by eliminating "floating" sessions. We configured
usr/fox/customer/hi/dmcfg so that each thin client was allowed to open a
specific FoxView DM. The problem instantly disappeared; we haven't seen it in
~2 years. The thin clients can disconnect or power down in any number of messy
ways, but since they each had their own DM to return to, there was no potential
for session-stealing lockups.
Brahm Neufeld
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Dirk Pauwels
Sent: Wednesday, August 24, 2016 7:29 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Remote Desktop Smurfing All Graphics
Hi Chad,
Seems like a foxview problem, not an RDP problem.
Have you tried exiting the foxview session before you disconnect the RDP
session?
We have appr 10 RDP sessions, the operator sessions are always active, the
engineering sessions are closed manually by closing the foxview session and
then selecting the windows log off function. No problems with smurfed foxview
displays.
I8.7
ICC
Foxview 10.2.3
Rgds
Dirk
-----Oorspronkelijk bericht-----
Van: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] Namens ;
Chad Ziesemer
Verzonden: woensdag 24 augustus 2016 15:04
Aan: foxboro@xxxxxxxxxxxxx
Onderwerp: [foxboro] Remote Desktop Smurfing All Graphics
Hi List,
We are having issues with graphics on remote desktop connections "smurfing" or
turning cyan. After a fresh reboot of the server users are remoting into,
everything works very well for the first 24-48 hours. Then when a user calls a
new display most or the entire display turns into cyan boxes as if we have a
bad connection. On-mesh WP's are not affected, no control is affected, only the
remote desktop connections.
After lots of scouring the list archives, I have a hunch that this has
something to do with how we are terminating the RDP sessions and leaving om
lists or something like that open behind the scenes. If a user is idle for
more than 30 minutes, the terminal service manager first "disconnects" the
user, than "ends" the disconnected session after 1 minutes. The reason I think
this may be the cause is 2 years ago we had to reboot the server perhaps once a
week. As the number of users grew it became every other day, then once per
day. Is there a more appropriate/clean way to end idle sessions?
A service tech was here, scoured GCS on the issue and tried to install
QF1222429 that referenced solving some smurfing issues but that did not work.
The work around I have in place is a daily automatic reboot in the middle of
the night when the plant is least active. I attempted to use som and rsom to
investigate, I was able to see lists, but I have no idea what is normal or
problematic or if this is even the right path to investigate. I'm resurrecting
because I'm concerned as I left the auto-reboot off to see how long it would
last and it was only 28 hours, I can't let this go until we are rebooting
multiple times per day.
Other info/details:
I/A 8.4.2
ICC
Foxview/Foxdraw
10 on-mesh WPs which are not affected by this issue, never rebooted unless
power lost.
RDP: up to 20 users are in multiple times a day. We use these sessions for
lower use areas or less critical areas where someone needs to perform tasks for
a few minutes then they are out of the area. Discipline to File->Exit once
done with those tasks eludes us, so we quickly would get all 20 RDP sessions
used up and then get calls for no available license, hence the reason we
terminate idle sessions.
As always, thanks for the support!!
Chad Ziesemer
Control Systems Engineer
Cell: 920.427.9147
Desk: 920.886.2376
Galloway Company
601 South Commercial Street
PO Box 609, Neenah, WI 54957-0609
_________________________________________________________________________
This mailing list is neither sponsored nor endorsed by Schneider Electric
(formerly The Foxboro Company). Use the info you obtain here at your own
risks. See the disclaimer at www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
________________________________
Lawter Notice: The information (including any attachments) contained in this
communication is confidential, private and proprietary, may be privileged or
otherwise protected by applicable law or legal rule, and is intended only for
the use of the addressee(s). Unauthorized use, disclosure, distribution or
copying is strictly prohibited and may be unlawful. If you have received this
communication in error, please notify the sender immediately by reply e-mail,
or by calling the sender, and then delete it completely from your system.
_________________________________________________________________________
This mailing list is neither sponsored nor endorsed by Schneider Electric
(formerly The Foxboro Company). Use the info you obtain here at your own
risks. See the disclaimer at www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
________________________________
For more information on Agrium’s E-Mail Policy or to unsubscribe, click here:
http://www.agrium.com/email_footer_en.jsp
Pour plus de renseignements sur la politique de courrier électronique d’Agrium
ou pour vous désabonnez, cliquez ici : http://www.agrium.com/email_footer_fr.jsp
_________________________________________________________________________
This mailing list is neither sponsored nor endorsed by Schneider Electric
(formerly The Foxboro Company). Use the info you obtain here at your own
risks. See the disclaimer at www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
_________________________________________________________________________
This mailing list is neither sponsored nor endorsed by Schneider Electric
(formerly The Foxboro Company). Use the info you obtain here at your own
risks. See the disclaimer at www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
________________________________
Lawter Notice: The information (including any attachments) contained in this
communication is confidential, private and proprietary, may be privileged or
otherwise protected by applicable law or legal rule, and is intended only for
the use of the addressee(s). Unauthorized use, disclosure, distribution or
copying is strictly prohibited and may be unlawful. If you have received this
communication in error, please notify the sender immediately by reply e-mail,
or by calling the sender, and then delete it completely from your system.
_________________________________________________________________________
This mailing list is neither sponsored nor endorsed by Schneider Electric
(formerly The Foxboro Company). Use the info you obtain here at your own
risks. See the disclaimer at www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
