Runtime Manager behaviour with terminal servers

I've noticed some odd behaviour of the runtime manager when running citect through terminal servers.

I'm using Citect 2018R2 with clients connecting as distinct remote desktop users to a terminal server with the Citect client (multiple terminal servers grouped for redundancy across clients, etc.). Operationally it works well, with a client (Thin Client) logging into a windows session on the terminal server, and then the runtime manager configured to automatically start which spawns the Citect Client process. All working well for 2 years...

Since the beginning I've noticed that when a client logs off (and thus the Citect client and runtime manager for that session are closed), a Runtime manager on a different session (but the same terminal server) will popup and state that all Citect processes have stopped. The Citect client on that computer is of course still running, but it seems the runtime manager is picking up the shutdown client signal from the other session and falsely interpreting this as belong to its own session.

This is an annoyance with my users wondering why they are occasionally getting this funny runtime manager window they never see. They only have to click ok, but obviously it's not ideal. It's also not great for a client which is a display only and doesn't have a keyboard or mouse (large alarm display), as the Runtime manager window obscures the display and I have to remotely connect and click ok.

As a work around I have modified the autostart on these clients to be client process only, and hence the runtime manager never starts. This means I lose the deployment server version update function though, so it's made deployment more tedious...

I suspect the runtime manager process is not correctly filtering the citect processes it is monitoring to only those in it's own session.

Anybody else noticed this? I have read the release notes for Citect 2018, Plant SCADA 2020 and 2023 and haven't found any reference to it being fixed.

Happy to raise as a support ticket, but thought I'd reach out first.

Parents
  • We use the /x as Jacky mentioned. But we do not run the runtime manager as a service.  We had issues with the System process (The client running under the service) hanging when client autologin set to 2. Now when we do a deployment, we RDP to the desktop of the application server and open a runtime. Then deployment works fine. after it's deployed, we just logout of the RDP session. 

Reply
  • We use the /x as Jacky mentioned. But we do not run the runtime manager as a service.  We had issues with the System process (The client running under the service) hanging when client autologin set to 2. Now when we do a deployment, we RDP to the desktop of the application server and open a runtime. Then deployment works fine. after it's deployed, we just logout of the RDP session. 

Children