I was writing to inquire if there is an outstanding bug with the User Session Configuration - Change console resolution setting. I noticed this was posted in the feedback portal, but I hadn't found an update to this post: https://feedback.telerik.com/teststudio/1457711-change-console-resolution-option-is-not-working
I currently have a remote server that we remote into to run our test and schedule test runs. I noticed that when I disconnect and a schedule test list run is ran some of my test fail and looking at the graphic of the failure it looks like the screen resolution might have been reduced. (see attached). I have set the 'user session configuration' settings set as follows: keep machine awake - on; reconnect to console on disconnect - on; and change console resolution to 1920x1080 - on
When I am connected to the server through remote desktop and the test run the list doesn't have any failures and the web app doesn't looked condensed to smaller resolution. It's when I disconnect that I notice is it gives the errors and possibly changes. I did verify that our server is not connected to a physical monitor, so I am unsure what would cause the resolution to change.
Thanks in Advanced
8 Answers, 1 is accepted
Hello Jessica,
I am sorry to hear about the encountered misbehavior when you close the remote connection to the execution server. We started investigating this issue from the lined bug report, but could not reproduce it on our end and debug it further. This is why I would like to ask you for some additional details that could help us figure out what is happening. Please follow up on the topics below.
- Clear the Test Studio application log on the execution server and reproduce the misbehavior, by closing the remote desktop connection. Gather the generated log and attach it as .zip file to your next reply. I want to analyze the behavior of the reconnect to console action for errors.
- Check the Windows Event Viewer Log (under Windows Logs -> Applications) for any errors around the time of the reconnect to console action, on both the execution server. There might be errors from a Test Studio related process or .NET error. If there is, please share all details about the issue, so we can analyze them on our end.
- Please let me know what is the exact Windows build and version on the execution machine. Are there any specific security settings or company policies that could be restricting resolution changes? All details about the environment could be helpful for the investigation.
- Make sure that the Test Runner on the execution server is started with full administrator permissions, so that it can make changes to the resolution.
When you close the remote desktop connection, Windows will restore a console session with some default resolution. Test Studio will try to change the resolution, so that it matches your expected resolution and the test runs smoothly. Some other users, that had similar issue, gave us the feedback that they setup a new VM. I am not sure how the new VM is configured and what are the security restrictions there, but the issue was resolved.
This is indeed a tough scenario to reproduce and debug, but I hope we can find what is casing the issue and resolve it. I am looking forward to hearing from you.
Regards,
Plamen Mitrev
Progress Telerik
Our thoughts here at Progress are with those affected by the outbreak.
Hello Plamen,
I am attaching the TS application log from the execution server when I re-ran the list. I also went through the event log on the server and realized that there was an an Event 4098 about the time I disconnected . I have attached a screenshot of the event properties (see attached screenshot). As far as I know the user is using admin privileges, because when I launch the execution server it doesn't give me the warning about needing admin privileges. I do believe however that even though we added the user to the administration group it might get wiped when reconnecting to the server because at the moment I don't see the user in the administration group anymore. I am not getting the admin required error when I restarted the execution server so perhaps it's still acting on the administrative privileges and wouldn't be wiped until I log off the user. We are in the process of adding that particular user to have local administrative privileges.
Our windows edition is Windows Server 2019 Standard
Version: 1809
OS build: 17763.1282
Please let me know if I need to submit any more information.
Hello Jessica,
I analyzed the application log and it has details about the test execution and failed steps. That is to be expected, since the resolution is not changed according to the configuration and we are trying to troubleshoot that. I noticed that the log stats from 15:58 directly with the test list execution, and the event error is from 14:41. It seems that you have closed the remote desktop connection at around 14:41, but there is nothing in the log from that time. Actually this is the part that I am interested in, so please follow the below steps to get the necessary log.
- Establish a remote desktop connection to the execution machine and make sure that the User Session Configuration settings are enabled and set as you need them.
- Clear the application log on the machine that you connected to.
- Close the remote desktop connection. That should force the Test Runner to reconnect to the remote desktop and set the specified resolution.
- Give it a minute and connect to the remote machine again to gather the generated application log. You don't have to execute any scheduled test lists.
I hope that log will give us some information about where the process is failing.
As you mentioned, the user is missing from the administrator group, but you seem to have no restrictions for some actions. That could be a configuration to your user, but it might have restrictions for something that is preventing the resolution change. Please discuss with the IT team and ask them to grant this user full administrator level permissions.
Another way to ensure that our product is started as administrator is to right click on the shortcut and select "Run as administrator" (see runAsAdministrator.png). Please give that a try as well and let me know if the behavior is different.
I am looking forward to hearing from you and continue investigating this issue.
Regards,
Plamen Mitrev
Progress Telerik
Our thoughts here at Progress are with those affected by the outbreak.
Hi Plamen,
I have some more information to share. I did as you instructed and generated the log with connecting to the server and disconnecting. You are right it does say there was an error trying to change from 1024 x 768 to 1920 x 1080. I thought maybe it would be the user permission so I logged into the server, I have admin privileges on the server and I launched the execution server and disconnected from the server, and it gave me the same error that it couldn't change the resolution.
I decided to look at the Event Viewer and only noticed some warnings. I have included the details that could possibly be relevant as we troubleshoot.
Thank you in advanced.
Hi Jessica,
Thank you for sharing the application log and additional details about your environment.
It seems that the issue is the same as the public bug report that I linked before. Our engineering team is working on a possible solution for the communication issue that occurs in some Windows builds, like the Windows Server 2019 build 17763.1282 that you have. I can't promise you when we will have a solution for this issue, but I can keep you updated. If you are interested in a possible custom build, please let me know and I will note to link that to you as soon as we have it.
Thank you for your patience and cooperation.
Regards,
Plamen Mitrev
Progress Telerik
Our thoughts here at Progress are with those affected by the outbreak.
Thanks so much Plamen,
Yes, please keep me updated on this fix.
Hello Jessica,
I wanted to update this thread with the progress on the change resolution issue on Windows Server 2019.
We are testing different possible solutions on our end, but so far the issue still remains. Our engineering team will continue working to resolve the issue and I hope that it will be available for the next release of Test Studio. I will keep you posted if there is a custom build that you can try out ahead of time, but it might take some additional time.
Thank you for your cooperation and patience.
Regards,
Plamen Mitrev
Progress Telerik
Our thoughts here at Progress are with those affected by the outbreak.
Hello Jessica,
I believe we have found what is causing the issue and fixed it. I created a private ticket for you and will attach the custom build there.
If everything work on your end, as it works in our testing environment, this fix will be release in the upcoming release soon. Please check your support tickets and we can continue our discussion there.
Thank you for your patience and understanding.
Regards,
Plamen Mitrev
Progress Telerik
Our thoughts here at Progress are with those affected by the outbreak.