Auto Logoff in Remote HMI using RDP connection

Hi,

I am Looking for help in below issue.

While using DeltaV with local monitor, we will be able to Auto Logoff DeltaV user after specified idle time passes (Using DeltaVScreenSaver).
The same settings are not working when I connect my workstation to P&F HMI using Remote desktop protocol.

Please share any ideas so that it will be possible to Auto Logoff DeltaV user in remote HMI after he/she leaves the workstation idle for pre-defined time.

Thanks in advance.


Thanks & Regards,

Chetan Bhangale.
+91 8983500746

12 Replies

  • Hi Chetan,

    The behavior that you are seeing is normal from a Windows perspective.  By design, the screen saver is disabled in RDP no matter what kind of settings you try to apply.  Additionally, the "On idle" detection capability in Windows Task Scheduler is disabled as well; again by design.  Yes, it will drive you nuts!

    I was able to solve this particular problem by using a 3rd party Task Scheduler. In my case, I use System Scheduler Professional from Splinterware.com.  You must use the Professional version as it has the ability to execute a task on idle even in an RDP session.

    This software is easy to use.  In your case, you will:

    1. Set up a new task to activate on System Idle
    2. Execute the following program: "C:\WIndows\System32\DeltaVScreenSaver.scr" 
      1. Parameters: " /s"

    Good Luck,

    Dave

  • Microsoft allows you to configure RDP idle timeout behavior inside the Remote Desktop Services Host Configuration.

  • Hello Mr. Dave,

    Thank you for the suggestion.

    I will implement the same and update the results.

    Thanks & Regards,

    Chetan Bhangale

  • In reply to Ben Bishop:

    Hi Ben,

    That is not quite the same thing.  The article you linked is for auto-dumping an RDP connection from the host.  What Chetan is trying to do is allow a screensaver to activate inside the RDP session.  He wants to keep the session connected, but use the DeltaV screensaver to auto-logout the user from DeltaV Operate, not the RDP session.  

    When you think about it, you can see why Microsoft disabled that capability.  There isn't much use for a screen saver to run on a RDP host - the connecting client can just run its own screen saver.  If there were another way to auto-logout a DeltaV user without using the DeltaV screensaver, then that would be very handy.

    Dave

  • In reply to dave_marshall:

    Dave,

    RDP sessions can exist in several states. When the end user finishes with the session, they may exit in one of two ways: disconnect or logoff. When a user disconnects from a session (i.e. clicking the "x" button in the upper right of the RDP client), the session remains running on the server and all of the software remains in the state in which the user left it but the remote connection to visualize the desktop is closed. When a user logs off from a session (i.e. Start->Log Off/Sign Out), the session terminates all of the software running inside the session and then ends the session. The Remote Desktop Host Configuration allows you to decide if you want to just disconnect the idle session or log it out. Some customers choose to force idle RDP sessions to logout from a cybersecurity standpoint, others choose idle disconnect.

    What is the intent of the screen saver? After a predetermined idle period, you want to lock the HMI until someone logs back in. If the same user logs in, you want the software to be presented as it was left. This is the behavior that would be exhibited if you choose the idle disconnect option.

    The Remote Desktop Session Host Configuration and Windows Group Policies are functionality that is embedded inside of Windows. Your solution involves installing unsupported third-party software. There is almost always more than one way to solve a problem in DeltaV, I was just offering another option.

    Ben
  • In reply to Ben Bishop:

    I'm late to this discussion, but as I am fighting with DeltaVScreen saver on terminal services again, I thought I would put in my two cents.

    In my typical client's scenario, the terminal session is a dedicated operator workstation in a secure location on a dedicated isolated network that needs to remain connected to the windows session 24/7. The only thing that needs to happen from a security standpoint is to log off the current user from the DeltaV application when 15 minutes of idle time transpires, and log in a non-privileged non-person user for the sole reason of allowing alarms to continue to show up. The replacement log in is a necessary evil due to the alarm filtering strategy of DeltaV. If I could change that to an option, I would. (already submitted to UDEP). I think Dave and I are on the same page with Chetan with this.

    Initially, when Remote Client was introduced (v.7.2 I think), this replacement log in would not happen because the DVSS did not know which session to use. Once the Flexlock 'Autologin' feature was introduced (v.9.3?), it could now pick a session (though the criteria for selection is not clear, which is why we end up using the 'reserved for node' feature to force it to a particular session for a particular remote client among other reasons like alarm and control restriction).

    I typically set up a domain group policy to enforce the screensaver for all users and all computers since this is a user-based profile setting, but I have also had trouble with this. Back in Server 2003, it didn't seem to want to pass a screen saver name that was more then 8 characters long (you'll may still see it in the user's registry for value SCRNSAVE.EXE as
    c:\Windows\system32\DELTAV~1.SCR, so I renamed the executable to DVSS.scr and that worked back in 2003; maybe I'll have to try that again?)

    I think I solved a problem I've had for months now where the user's applied screensaver registry settings are not being written by policy despite the UI showing me that DeltaVScreenSaver is indeed selected. Changing the registry setting manually seems to have corrected it for me, for now.

  • In reply to dave_marshall:

    Hello,

    I need help on this issue, am using System Scheduler Professional from Splinterware for my clients stations with RDP protocol HMI, and from Windows desktop am able to auto logoff without any issue but if i am using Deltav desktop then auto logoff doesn't work.
    What i found out is the task which i am running in System scheduler its getting triggered when we are using Windows desktop might be windows property or something i dont know. But in Deltav desktop that task will not trigger, as if deltav desktop stops or closes system scheduler.
    And if i cross check in services there i can see system scheduler service in automatic mode and running.

    Regards,
    Arbaz
  • In reply to arbazk:

    Arbaz,
    Could you tell me about your requirement? Do you need the RDP client to log off of the terminal services Windows session, or simply log off the deltav application login? As described previously, neither problem should require additional software if set up properly. I've noticed that in recent versions of deltav, invocation of programs while on the deltav desktop has some erraticness depending on how they are launched.
  • In reply to Youssef.El-Bahtimy:

    Hello Youssef,

    I just simply want to log off from deltav, having no change in remote session. As RDP doesn't support Deltav screensaver am using this 3rd party software. If any other solution is available then m more then happy to try.

    Regards,
    Arbaz
  • In reply to arbazk:

    Despite problems I had with this several years ago, I did eventually make it work. The key was to ensure that if I had the same windows user account logged into multiple rdp sessions, once configured (either through policy or manually) I had to log all sessions of that user out of windows in order to allow the profile to reload fully. Regarding whether supported, I believe it is for terminal services, regardless of the troubles.
  • In reply to Youssef.El-Bahtimy:

    Hi Youssef,

    Let me explain the requirements at this site:
    We have operator station having Win 10, DeltaV 14.3.1, which will connect to HMI in field.
    HMI is from P&F which connects to Operator station on RDP.
    Requirement is for Auto Logoff to work in DeltaV Operate.
    We have taken System Scheduler s/w as mentioned in above inputs by Arbaz.
    Problem is:
    1. when we run DeltaV Operate from Windows desktop, system scheduler running as windows service & auto logoff works.
    2. when we run DeltaV Operate from DeltaV desktop, system scheduler running as windows service & auto logoff doesn't works.

    We are not using any terminal sessions to connect to HMI.

    So do you have any other methods to solve this issue of making auto logoff work thru system scheduler work for DeltaV Operate from DeltaV desktop ? Waiting for your help in same.

    Regards,
    Rishi.
  • In reply to Rishi Prajapati:

    Rishi, I think I was confused about your statement of setup:

    "We have operator station having Win 10, DeltaV 14.3.1, which will connect to HMI in field.

    HMI is from P&F which connects to Operator station on RDP."

    I tend to use RDP and terminal services/sessions interchangeably as they are the same thing, but the difference here is your Operator workstation OS.

    I assume you mean the P&F "HMI" is an RDP client running linux, windows, or some other embedded OS and via RDP connects to the Win10 workstation. 

    As I understand, connecting via RDP to a WIn10 workstation running DeltaV is not a supported set up for running a plant.

    You would require a server OS and the appropriate licensing.

    Instead, your should consider a KVM over IP device to connect a dumb HMI (monitor, keyboard, speaker) to the workstation over the network.  I've seen this solution in place previously in the days before virtualization and when the client had given up on RDP in the DeltaV Terminal Services environment.   They are not very expensive.  

    If your operator workstation is indeed virtualized, then your remote connection options are greater, and the screensaver should work in KVM and these cases.

    Regarding the screensaver, yes windows 10 and RDP screensavers are a known issue.  I have employed idle time detection through User.fxg / other persistent Workspace documents before, but I need to find my references.