PowerShell - How to overcome Azure VM's fixed resolution limitation

Intro

This is the first in a series of PowerShell blogposts. I don't know a lot of PowerShell so I'm going to cover this part very short. What is PowerShell? PowerShell is a very powerful framework you can use to automate tasks. For more info, use Google or check the Wiki: https://en.wikipedia.org/wiki/PowerShell
For my current project we use Azure VM's that we use as selenium-grid (hub and nodes). And Visual Studio Online for kicking off builds. So I started to use a fair share of PowerShell in my test automation process. During the setup I came accross a couple of problems that I want to share with you all which I'll spread across a couple of posts.
And we start with Azure VM's that have a fixed resolution of 1024 x 768 and how to overcome this issue/limitation.

Azure VM's resolution limitation 

Let's start with the problem we faced. Our website under test, requires the test machine to have at least a certain resolution ( Which is > 1024 x 768). If you don't meet this resolution requirement, the website will show you the tablet/mobile version. Scaling the browser does not resolve the issue. It really does look at the machine resolution. Of course we did not want to add any additional steps in our build process, but none of the solutions we found worked for us. We do start the machines automatically before we run the tests and close them down right after the tests. This to reduce the cost of the Azure VM's. We looked at all kinds of solutions, like these:

• https://social.msdn.microsoft.com/Forums/azure/en-US/1c215514-aeef-41d9-b47b-5c838a0bf83f/how-to-change-the-vm-default-screen-resolution?forum=WAVirtualMachinesforWindows
• https://social.technet.microsoft.com/Forums/en-US/c7decd2e-2755-4a27-8665-aa107f27a011/azure-vm-screen-resolution?forum=websitesvirtualmachinesonwinserver
• https://docs.microsoft.com/en-us/powershell/module/servercore/set-displayresolution?view=win10-ps

Also in the official documentation we could not find the answer. But there was one answer that always came back as a solution. Setup a RDP session before you start the test. So we did some more digging in how to automate the RDP session. This is a bit of a struggle if you're new to these kind of things. But we managed to find a way.

Solution

Actually I already posted the answer on stackoverflow (do read this answer as well if the blog is not clear), but I wanted to add a bit more information due to a new issue I found today.

There was only one solution left. Figure out how to setup a RDP connection before starting the tests and adding this as a building block before we execute the test automation.

The biggest challenge here was to figure out how to automate this incl. the login. We still need to refine the setup a bit but in general you need to think about there things:

• Perform a check on the VM to wait for the RDP service to be up and running (depending on the VM this might take up to 15 minutes or longer after you triggered the machine to start in the Azure Resource Group Deployment block to start all machines)
• Start the RDP session to each machine, which needs to be automated completely and requires knowledge of certificates and storing the credentials in the Windows Credential Manager on the machine that performs this task
• Validate that the RDP session is actually up and running otherwise the session is only started and if it fails or not will not be visible in the build server
• Run your tests
• Close the RDP session will already be done because we shutdown all machines after our tests

It's basically a slightly different version of this blogpost. Our solution looks like below.
The code for the check can be found here: https://github.com/mark0203/RDPServiceRunCheck

VSO Build definition block - RDP check Azure VM chrome

The code for the session can be found here: https://github.com/mark0203/ResolutionRDPRemoting

VSO Build definition block - RDP session to Azure VM chrome

The last part which is not mentioned on stackoverflow and until this day is also not yet covered in the part where we start the RDP session, is a check if the session is actually up and running. Initially we thought that this was already covered, but it turned out the executable is only fired, keeps on running and we move on to the next build block. Meaning, if the RDP session for whatever reason fails, the build server does not show this.
At the moment of writing this blogpost I don't have a solution to present yet. But at least you know that this is still missing in the solution I show you above, so you could also build it yourself. When I have a bit more time to dig into this again, I'll make a part 2. But until then, please upvote this uservoice idea in the hope they will build in support to set a fixed higher resolution in the future without the need for an RDP connection: https://visualstudio.uservoice.com/forums/330519-visual-studio-team-services/suggestions/31957210-vsts-run-functional-tests-ui-tests-make-it-pos