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:
Good Luck,
Dave
Microsoft allows you to configure RDP idle timeout behavior inside the Remote Desktop Services Host Configuration.
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.
In reply to dave_marshall:
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 arbazk:
In reply to Youssef.El-Bahtimy:
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.