When I connect to my Windows Server 2012R2 Azure VM via RDP, I have resolution 1600x900, which corresponds to my client PC resolution. However, when I run selenium UI tests on this machine with VSO agent, they are failing because screen resolution for agent session is 1024x768. In Device manager I can see that display adapter is Microsoft Hyper-V Video. When I access Screen Resolution section when connected via RDP, I can see only my resolution selected and grayed out and also message "The display settings can't be changed from a remote session".
Is it possible to change default screen resolution for Windows Server 2012R2 running on Azure VM?
I tried adding DefaultSettings.XResolution and DefaultSettings.YResolution values to registry but it didn't help.
Try loading the site in an iFrame and declaring the width/height attributes in the iFrame tag. The resulting window opens outside the boundary of the viewable desktop resolution and allows testing more screen resolutions than the desktop resolution would otherwise support.
Calling the iFrame:
driver.Navigate().GoToUrl("file:///E:/iframe.html");
Example iFrame content:
<iframe id="theiframe" src="https://www.SomeSiteToTest.com" width=1800 height=750 align="center" frameBorder="0" ></iframe>
Switch the Selenium driver focus over to the iFrame:
driver.SwitchTo().Frame(driver.FindElement(By.Id("theiframe")));
From here you can now use FindElement or whatever you need using the content inside the iFrame.
I ran into the same issue and could not manually setup a RDP connection prior to starting the tests. Also the website we test is looking at machine resolution rather than browser size. What I did was make sure the RDP session was setup automatically in the build process to each machine I need to test on.
See this answer
Related
We are using Guacamole for developing an application with RDP. We did POC using code from the following GitHub repositories:
https://github.com/wwt/guac
https://github.com/wwt/guac-vue
Configuration details are:
Windows Server 2016. RDP service is running here.
With this setup, we could successfully access the application remotely, however, the "minimize" action is not behaving as we expected. That is, the remote app window vanishes when we press the "minimize" button and a black screen is shown.
We could get back to the app by pressing 'Alt+Tab' combination but what we are expecting here is that the app getting placed at the bottom of the window showing three buttons: "Minimize, Restore and Close", so that we can take the further action. (As shown below.)
Has someone come across such a scenario and was able to address the need? Any help will be highly appreciated.
We came across this thread that talks about a similar problem but it doesn't have a solution.
We also explored official documentation of guacamole but had no luck.
Thanks in advance!
I believe you are starting the application using RemoteApp mechanism. The RemoteApp means that the remote application will be started integrated with the local computer desktop. The local computer desktop, or better window manager, will handle the minimise action.
In case of the Guacamole, the "local computer desktop" is the browser window, which does not have window manager. This means that there is no place for app to go when minimised.
You may try the Guacamole parameter "initial-program" instead of "remote-app". This parameter will launch the application immediately upon the connection is established, but the session will also have full desktop from the remote machine.
I am trying to get the Horizon View Client to work with dual monitors on a Chrome Box. There are no options in the Horizon View Client to turn on dual monitors, only to change the screen resolution. I am struggling to find any sources online about the issue as well. I am running VMware 4.7 which seems to be the newest on Chrome OS. Has anyone been able to accomplish this?
With the multiple monitor feature, you can extend a remote desktop to one external monitor.
About this task
To enable the multiple monitor feature for Horizon Client, you install a helper extension and enable Unified Desktop Mode on your Chromebook.
You must install the helper extension to make the remote desktop window display correctly on an external monitor when the Chromebook display and the external display have different width-to-length ratios.
Procedure
Log in to your Chromebook.
Download and install the VMware Horizon Client Helper extension from the Chrome Web Store.
Open a browser window on your Chromebook and type chrome://flags in the URL bar.
Scroll down to Unified desktop mode and tap Enable.
Tap Restart Now to restart your Chromebook and make the change take effect.
What to do next
After your Chromebook restarts, you can open the Chromebook Settings and tap Display settings to configure Unified Desktop display options.
To extend a remote desktop window to the external monitor, tap the Maximize button. You can tap the Restore button to make the remote desktop window go back to the Chromebook monitor.
I'm setting up Selenium Grid. We have a separate machine for each version of the browser.
Each node is started as System Service running on LocalSystem account with interactions with user desktop enabled.
This is required because Selenium Grid node starting Internet Explorer have problems making screenshots and transferring them when there was no interaction with user desktop.
As far as I was able to check, it looks like that interactions with user desktop for service are only allowed for LocalSystem account. Event changing manually flags in registry does not seem to works (as it was in windows 2008)
Everything is working fine except the test where I need to perform upload of the file. When there is an action to open dialog for file browsing, following popup appears
Is there any way to prevent this (creation of folder Desktop does not seem to work) ?
From the other hand, if there is a way to run service under different account with interactions with user desktop enabled, that would also be a case.
I would appreciate any help because I'm stuck with the problem
I have checked some additional solutions, like running selenium grid nodes via PowerShell Invoke-Command and this did not worked too.
I have managed to run selenium grid nodes as Windows Service with desktop interactions using 3rd party tool FireDaemon Pro Service Manager.
I didn't try this but PsExec -s should work
https://technet.microsoft.com/en-us/sysinternals/bb897553
I have this code in my WinJS default.html:
<x-ms-webview src="http://localhost/"></x-ms-webview>
<x-ms-webview src="http://display/"></x-ms-webview>
<x-ms-webview src="http://192.168.1.2/"></x-ms-webview>
display is defined in the hosts file:
127.0.0.1 display
and 192.168.1.2 -- the one that is successful -- is another computer on the network.
This is in my appx.manifest:
display and localhost successfully load in IE on the desktop and metro.
My OS is Windows 8.1 Enterprise. I have also completely disabled the Windows Firewall and this has had no effect.
What else can I do?
Microsoft blocks connections to the local machine except while running from the Visual Studio debugger.[1]
There is, however, a workaround tool. Quoting from this post on an MSDN blog:
Immersive applications (and IE11 on the Desktop) run inside isolated processes known as “AppContainers.” By default, AppContainers are forbidden from sending network traffic to the local computer (loopback).
[...]
I have built a GUI tool that allows you to very easily reconfigure an AppContainer to enable loopback traffic. This tool requires Windows 8 and runs on the .NET Framework v4. When launched, the utility scans your computer’s AppContainers and displays them in a list view. Each entry has a checkbox to the left of it, indicating whether the AppContainer may send loopback traffic. You can toggle these checkboxes individually, or use the buttons at the top to set all of the checkboxes at once. Click Save Changes to commit the configuration changes you’ve made, or click Refresh to reload the current configuration settings.
The aforementioned standalone tool is available from here.
I am using the below JAVA code to capture the desktop of a remote machine
Robot robot = new Robot();
BufferedImage screenShot = robot.createScreenCapture(new Rectangle(Toolkit.getDefaultToolkit().getScreenSize()));
ByteArrayOutputStream imageBytes = new ByteArrayOutputStream();
ImageIO.write(screenShot, "PNG", imageBytes);
return imageBytes.toByteArray();
However the captured image is blank, when the terminal session to the remote machine is either minimized or disconnected. I appreciate your help in resolving the issue, at the very least the minimized scenario.
Configuration:
I have the same issues with a physical machine running windows 7 and a virtual machine running windows server 2008 R2.
More insights from MSDN:
Why you get black screen when you disconnect from RDP ?
http://msdn.microsoft.com/en-us/library/aa383015%28VS.85%29.aspx
Here is my attempt to make things work, but none of the following did the trick:
How to get data when RDP window minimized ?
You can force the RDP display driver to send data when minized, try these steps and let me know how it goes:
1) Add the following key
HKEY_LOCAL_MACHINE\Software\Microsoft\Terminal Server Client\ Created a new DWORD value and named it RemoteDesktop_SuppressWhenMinimized. Specified 2 as the value data.
Note: Also tried adding the registry key to HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Terminal Server Client\
2) Disable bitmap caching (http://technet.microsoft.com/en-us/library/cc737325(WS.10).aspx)
In the Remote Desktop Connection window, click Options.
On the Experience tab, verify that the Bitmap caching check box is selected. Or, to disable bitmap caching, clear theBitmap caching check box
If you minimize the Remote Desktop window, Windows switches the remote session to the GUI-less mode and does not display windows and controls. As a result, TestComplete (or TestExecute) will be unable to interact with the tested application’s GUI, as it does not exist and your automated GUI test will fail.
To work around the issue, you can change the Remote Desktop’s registry settings on your local computer (where you launch the Remote Desktop):
On your local computer, close all open Remote Desktop sessions.
Launch the Registry editor (regedit.exe).
Navigate to one of the following Registry keys, depending on whether you wish to modify the Remote Desktop settings only for the current user or for all users on the computer:
HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client
HKEY_LOCAL_MACHINE\Software\Microsoft\Terminal Server Client
Create a DWORD value named RemoteDesktop_SuppressWhenMinimized and set it to 2.
Or you can do it programmatically by following steps:
Transparent the window
Restore the Window
Capture
Minimize it again
Remove transparency
We had similar problem in our project last year...we could find any stable and permanent solution....however here is how a work around worked for us...
We had to run on 5 remote desktops (which will take screens capture as well during failure) ..however as you have figured already if we disconnect session or minimise the RDC Window blank screenshot is captured. Therefore we had added one more VM to connect those other five test boxes. The task for that VM is to keep session active and resized to other 5 boxes...this worked for us.
If you connect a remote desktop to the test machine, make sure to reboot the machine when you are done, otherwise the desktop will remain locked and screen captures will not work.
I don't believe there is any other way around the issue.
I just configured the clients to auto logon, disabled the screen saver and installed a VNC server on each client.
Basically, make sure the screen is always on, and don't RDP into them.
This worked on both physical PCs and on virtual machines hosted on a Hyper-V server.
I even wrote a small .NET desktop client that ran multiple VNC clients inside a single window, so we could see what was happening on all the clients. We had an old PC running this with it's monitor on top of a cupboard to (a) let the developers see if any client had hung, had hundreds of browser windows open, etc. and (b) to look impressive for any non-developers walking past.
A simpler alternative to the above answers to to transmute the terminal session (RDP) into the console session. The session will then display to the physical screen (Switching the user of anyone currently logged into the physical machine). The following command does this:
for /f "skip=1 tokens=3" %%s in ('query user %USERNAME%') do (tscon.exe %%s /dest:console)