Friday, September 23, 2016

Coded UI Running On MS Lab Center Does Not Play Well With Private Network Screens!

Hey Friends,

Recently I came back from vacation and found all of our GUI tests in a non running state. Understandably I freaked out, and needed to do a bit (a week!) of investigation with respect to what was causing the problem. I figured it out eventually, and wanted to share the fix with you in case you ever run into this.

When running GUI automation on a Microsoft Lab Center environment, communication between the test controller and test agent cannot be established for GUI automation, when the agent (machine being utilized for GUI testing) presents a "Private Network Screen". More specifically, the remote user session which is necessary for GUI testing cannot be established. You can tell whether the private network screen is enabled by manually initiating a remote desktop session to your test agent. If you see the screen below, you will not have a good time.

Troubleshooting From Lab Center: Ensure The Private Network Screen Is The Cause
Sometimes test agents lose session connectivity with the test controller, leading to "Not Ready" test lab states. In most situations, these states can be remedied by "Repairing", right clicking on the test lab and choosing "Repair".

Attempt Repair
This is  the first thing you should try. Right click on the name of the test lab, enter the appropriate credentials and initiate the repair. You should see the test lab take action as evidenced in the screenshot below. Basically, the test controller will attempt to restart the machine and re-establish the session, even re-install the agent. The controller is pretty smart.... :)

Oh No. It Won't Repair
A typical repair will return your lab to a "Ready" state relatively quickly. Usually a little longer than it takes to reboot your test agent. If you are sitting around for a while, watching the repair process and noticing a long pause on the  "Waiting for agent to restart" state, leading to an eventual "Waiting for test agent to respond" state, start cursing, because the private network screen is blocking your session.



Solution Implementation

Hacky Option: Part 1
Run a powershell script which is kicked off by the windows scheduler to remove a few registry keys on a regular basis. The regular basis is required if your test machine (agent) is influenced by an active directory policy, specifically one which implements the logon screen. The task screenshot can be found below. I had a few problems with the arguments so I am providing them below too. The arguments will start the script and spit out a log of errors.

Arguments: .\RemoveLogonBanner >> c:\RemoveLogonBanners.log
Start In: C:\Users\User1\Desktop\ScriptFolder

Hacky Option: Part 2

Write a script to remove the registry keys for the private network (logon) screen. An example of such a script can be found can be found on my github. Please note this script requires PowerShell 2.0 and the "PSRemoteRegistry" module, which can be found in the PowerShell Gallery.

Best Option

I had to live with the hacky option for a few days, before my awesome server dudes were able to get the policy change implemented. But they got rid of the screen by removing the test agent(s) from the AD policy which controls the "Logon screen". Talk to your IT admin, or server admin to help you with this, unless you have control over it yourself. After the policy is changed you may need to run the command line "gpupdate /force" to implement the policy change right away, otherwise you will need to wait for the regular policy update cycle.

Until next time!

No comments:

Post a Comment