Can I install a Ranorex Agent on a virtual machine?
Yes, a Ranorex Agent can be installed on virtual as well as on physical machines.
Can I install more than one Ranorex Agent on the same machine?
If you want to run more than one Ranorex Agent on a physical machine, you have to set up more operating systems on that machine.
Which type of licenses do I need for Ranorex Remote?
How many licenses do I need for remote test execution on a Ranorex Agent?
How do I deploy settings to a Ranorex Agent?
Settings which were configured on your local machine, e.g. technology plugin settings, can be deployed to the remote machine with the Ranorex Solution. Follow these steps to do so:
- Open Windows Explorer and navigate to %appdata% on your local machine.
- Copy file 'RanorexConfig6.xml'.
- Open the file system directory of your Test Suite Project.
- Paste 'RanorexConfig6.xml' in this Folder.
- Switch back to Ranorex Studio and enable showing all files in Projects View.
The configuration file should be visible in the list.
- Include the configuration file in the project.
- Open Properties pane for the file.
Use the context menu or press F4 to do so.
- Change property 'Copy to output directory' to 'PreserveNewest'.
With this Setting, the configuration file will always be deployed to the Ranorex Agent.
If you change any setting after this procedure, you have to manually update the file in this project. Repeat steps 1 to 4 to do so.
How do I make sure that my user session keeps unlocked if I close my remote session?
Ranorex Remote requires an active user session to run tests on a remote machine. You can connect to a remote machine using a remote desktop connection (RDP). As long as this remote connection is active, the remote machine is unlocked and tests can be executed. If you disconnect the RDP session, your remote machine will be locked. As no GUI is available in locked mode, your remote tests will fail.
Ranorex Agent shipped with Ranorex 6.0.1 and later includes the setting 'Keep Session Active', which is enabled by default. So no further steps are required.
Find more information in section Configure Ranorex Agent.
To keep the remote session unlocked even if you've disconnected the RDP session in Ranorex 6.0, please follow these instructions:
Create a batch file on your remote machine and insert the code below:
for /f "skip=1 tokens=3 usebackq" %%s in (
`query user %username%`
) do (
%windir%\System32\tscon.exe %%s /dest:console
- Save this batch file on the desktop of your remote machine and name it: 'KeepSessionOpen.bat'.
- If you need to disconnect the RDP session, you can now simply run this batch file using administrator privileges and your remote machine will remain unlocked.
Note As this mechanism will keep your remote machine unlocked even if you've disconnected your RDP session, an essential security mechanism is now disabled. Please beware that your remote machine can now easily be accessed as the system security is disabled. We advise you to not store sensitive data on your remote machine.
Note When ending your active RDP session and switching to an unlocked remote session, the remote machine may change to a different screen resolution. This may happen in particular if your remote machine is a virtual machine. In this case, the default screen resolution of the virtual machine will likely be used. This may affect your tests.
How to overcome NAT issues
If the machine with the installed Ranorex Studio and the machine with the Ranorex Agent are connected to different networks, this agent may not automatically appear in your Agent List and you may not be able to manually add it using the IP address. By default, machines do not have the routing information to connect to a machine outside its own network.
To overcome this issue, a network route has to be configured either on the gateways between the networks, or on each machine.
Below, we've showcased an example in which Ranorex Studio and the Ranorex Agent are installed on machines which are connected to different networks and have provided a solution on how to create a network route between them.
As you can see in the image above, our exemplary networks are starting with 192.168.x.x. One has the gateway 192.168.2.1, the other 192.168.3.1. Both gateways share the subnet 192.168.1.x. This subnet has the gateway 192.168.1.1., which is connected to the internet.
The network of gateway 192.168.3.1 contains two computers, one of which with three virtual machines (VMs) running on it. All of them have 192.168.3.x IP addresses.
On the 192.168.2.1 network there is a router, and just two computers.
All of these computers have 192.168.2.x IP addresses.
If you ping '192.168.2.2' (PC 2) from computer '192.168.3.6' (VM C), then the request will time out, unless you enable a proper route across the gateways. Assuming the 192.168.3.6 (VM C) is running Windows 7, type one of the following commands on 192.168.3.6 (VM C):
- route add 192.168.2.0 mask 255.255.255.0 192.168.1.2 metric 2
(add whole network to the route table)
- route add 192.168.2.2 mask 255.255.255.0 192.168.1.2 metric 2
(add single computer to the route table)
Once the command has been entered, the ping/communication would successfully go from 192.168.3.6 (VM C) to 192.168.2.2 (PC 2), but 192.168.2.2 (PC 2) would still not be able to ping 192.168.3.6 (VM C). There are two workarounds to enable communication between these two networks:
- Set up a route on the gateways
- Set up the route on the machines that need to communicate across networks
Please consider the gateway firewalls when setting up the routes, as they may block cross-traffic from the machines. If this is the case, you will need a network admin to either set up the route on the gateway instead or to set up port forwarding to allow traffic through the firewall.
As most gateways behind corporate internet firewalls function as bridges, not much internal traffic is firewalled on the local network. To check if your connection is firewalled, try 'tracert 192.168.2.2'. If stars '*' appear in the 'trace route' instead of IP addresses, then either the connection went through the firewall, or it has been misdirected into the internet.
Please beware that a standard subnet has been chosen in this scenario: 255.255.255.0
You’ll need to confirm the subnet on either side of the gateways, and adjust your route setup commands as needed.
The route metric (last number in command) is assigned to a route and is used to identify its priority – with 1 being of the highest priority. Usually network admins base the router metric on the amount of hops in a route, as the route with the least hops is usually the best. As the route in our example contains two hops, our router metric is 2.
Note A route command is only persistent (it will stay after reboot) if you add the ‘-p’ argument to it. Thus, you can easily try route commands at no risk beforehand, and simply reboot if you’d like to make them undone. Once you’ve found the right route, you can make the commands persistent after reboot.