Question
TCS
CA
Last activity: 6 Nov 2018 20:02 EST
Disconnecting from VDI while running automation - Loosing clipboard data
Hello team,
Our set up - OS run time is installed in a lot of Virtual Machines (VMs) in both QA & prod environments.
Issue - When testing the automation, as long as we are logged on to the VD machines and "active" the automation is able to read the data from clipboard without any issue. QA Testers log on to the VD, start the automation and then log off because the automation would go on for a couple of hours. What we noticed is that as soon as they disconnect (not logoff), clipboard on the VM becomes empty and all further cases would fail from the point testers disconnect from the VMs (not log off). Our automation uses a small script to read data from clipboard.
Can you help us understand why, upon disconnecting from the Virtual machines, automation is not able to read the clipboard data?
Please note that the testers only disconnecting from the remote session. Not logging off. The automation continues as normal. But since the critical data in clipboard comes back empty, all cases start to fail.
Script to read clipboard data -
Thread staThread = new Thread(
delegate ()
{
try
{
idat = Clipboard.GetText();
}
catch (Exception ex)
{
threadEx = ex;
}
});
staThread.SetApartmentState(ApartmentState.STA);
staThread.Start();
staThread.Join();
Pegasystems Inc.
US
I would suggest that you disconnect from the VDI without locking it. There's a post listed below that might help.
https://collaborate.pega.com/discussion/how-disconnect-rdp-session-without-locking-machine
TCS
CA
Hello,
Should we try the script from within the remote machine or outside ?? In either case, I am getting the below error.
Could not connect sessionID 10 to sessionname console, Error code 5
Error [5]:Access is denied.
TCS
CA
Hello team,
We have a task scheduled to run on a Virtual Machine at 2AM every day. The machine is set to auto logon using the user credentials stored in the registry. And the task is scheduled to run only if a given user is logged on. From the logs, we could notice that the auto logon is working as expected and the task starts as expected at 2AM. However, all the resulting cases start to fail.
The automation that runs as a part of the task selects a text in a non .NET based control and clicks on a COPY button which copies the text to the clipboard and attempts the read the text to proceed with next steps.
The issue is, once the task is scheduled, automation fails to read the clipboard text. Logs show empty clipboard data.
The same automation works as expected if we run the task manually while logged on to the remote machine. The way we read clipboard data is through the script I provided earlier in this thread.
Can you help us understand why the clipboard is coming back empty on a schedule automation task? Any help is greatly appreciated. Thank you.
Pegasystems Inc.
US
Can you confirm that the issue only occurs when locked? Create a test of your code on your machine and run it while unlocked to conform it works.
Run it again while locked. You might want to add a 30 second or so pause after your trigger event before you read the clipboard to allow time for you to lock the screen. Leave the screen locked until you know the automation has completed. I suspect the issue is with the clipboard behavior while the system is locked. If that is the case, there really is no suggestion that I could offer except to ensure the system was unlocked.
Pegasystems Inc.
US
What VM technology are you using? The behavior you describe sounds like the interactive session is going away when you disconnect and your session is becoming a console session. Windows does this automatically in some cases when it believes that there is no active user session needed. The tip that Thomas shared concerning disconnecting from RDP without locking the machine may not work for you if you are using a different virtualization technology but there may be a way to do the same thing.
Here is a post concerning your error message. This seems to support my premise.
TCS
CA
Thank you Thomas & Jeff for the revert.
Just to provide some additional info, these are production machines (Virtual) with no monitor plugged in. Users (with restricted access) would occasionally remote in to check some logs etc. But, the main use of these machines to run schedules tasks which would trigger automation at a pre-defined time.