Q & A – Running Tests and Benchmarks on Remote Computers

WizConnect

Running Tests and Benchmarks on Remote Computers

What is remote execution and why does it matter?

Remote execution allows you to run tasks (in this case Sandra) on remote computers (be they on LAN, WAN or Internet) as if you were running on your local computer. You can thus test, benchmark or get information on those computers without being physically present in front of them.

You can run multiple (Sandra) clients and connect to multiple computers at the same time (subject to license).

Why not use Remote Desktop, VNC, Log-me-In, etc?

You can – but there are drawbacks:

  • Additional software may be required (e.g. VNC, Log-me-In) on both remote computer and client – and thus possible additional cost and maintenance.
  • Additional security considerations, e.g. additional ports to be opened in the firewall and credential management (user/password). Sandra uses built-in RPC and integrates with both Active Directory (Kerberos) and NTLM built-in security.
  • Specialised (remote desktop) video driver – not the one used by the physical graphics/GPGPU card – thus DirectX/OpenGL/OpenCL may be unavailable on the card to be tested/benchmarked.

What are the differences between running Sandra against a remote computer and local one?

Sandra is client/server – thus running a client (GUI) and service (agent) – you are already “connecting” the client to the (local) service even when you run it on your local computer! (it uses shared memory buffers for data transfer thus minor latency)

Note: On 64-bit systems, this also allows you to connect to either the 64-bit service or 32-bit service, e.g. if you want to see the differences in performance when running 64-bit code vs. 32-bit code.

The experience is thus exactly the same but for the delays due to network latencies – which are generally not noticeable on a LAN; only when running over Internet connections you will experience some delays.

Note: By default, remote services are disabled, thus remote connections are not possible. You need to specifically enable them to allow remote clients to connect to your Sandra service. (thus your system’s security remains the same, no additional security attack surface)

Note 2: The remote services use impersonation, thus run in the context of the connected user. Thus the user needs Administrator credentials to start/run Sandra’s remote services. (if an attacker has that then they “owe” your machine anyway)

What do you need to install/configure on the remote computer?

There are only two things you need to do on the remote computer to enable your Sandra client to connect to it:


connect_xa

  • Install Sandra on the remote computer by any means, e.g. physically, remote desktop, Active Directory deployment, etc. You can install it silently.
  • During setup, ensure Enable Network Services is selected (see picture above).
  • If you are running a different firewall from Windows Firewall, ensure that Windows RPC or Named Pipes services are allowed.

How do I connect to a remote computer?

You use the Connect Wizard to connect to the remote computer instead of the local computer.


connect_0a
Click Disconnect button on the toolbar to disconnect. By default, the client automatically connects to the local service (aka computer) on start so you’re already connected.

Click Connect button on the toolbar to run the connect wizard.


connect_1a
Select Remote Computer as the source. You can also connect the client to a Virtual Machine (computer), database (ADO/ODBC) or a device (phone, music player, etc.).


connect_2a
Enter the computer name or IP address in the “Host Name” field. You can search for computers in Active Directory using the “…” button.

Select ncacn_np (named pipe) if connecting to a LAN computer and ncacn_ip_tcp (TCP/IP) if connecting to an Internet computer.

You can also use ncacn_http if you enable RPC-over-HTTP tunnelling (no additional software is required) but that requires some work; the main advantage is that you don’t need to open RPC/other ports but the normal HTTP/HTTPS (80/443 by default).

Generally use Windows as security manager unless you want to use Kerberos in an Active Directory domain. If using Kerberos, you may need to enable “trust workstation for Kerberos” depending on your domain/forest configuration.

Generally use Default as security level – this encrypts the connection by default. You turn it off or select from various encryption levels.


connect_3a
If both computers are part of the same domain/forest in Active Directory check Use Log-on Credentials to authenticate to the remote computer. The remote Sandra service will run in your user context.

If the computers are not part of the same domain, enter the user/password credentials to connect to it. The “domain” should be the name of the domain the remote computer belongs to or its name if not part of a domain.

Note: You need to have Administrator rights on the remote computer, i.e. on the computer the Sandra service is running. Guest/anonymous or a normal user cannot use these services.

You don’t need Administrator rights on the computer you are running the client on.


connect_4a
Done! Observe how both the title-bar and status-bar both show you are connected to the remote computer.

Troubleshooting: When things don’t work

Due to the huge increase in number of attacks against computers in the last decade, many security measures have been introduced which also affect legitimate programs use network services. Thus you may run into issues that require additional configuration and the intervention of network support staff.

  • Golden Rule Try connecting “locally” first on the remote computer, i.e. run the Sandra client on the remote computer and connect to the remote service using the same settings by entering the remote computer host name as the computer to connect to.
  • Check Network Services is enabled in Sandra on the remote computer. By default, they are disabled to maintain security (services not required should be disabled).
  • Check you can ping remote computer or connect to it via Explorer.
  • Check your user has the authority to connect remotely, e.g. connect via Remote Desktop. It also needs to be part of Administrators in order to start/run the service.
  • If the remote computer is not using Windows Firewall, ensure that the firewall installed allows either RPC named pipes or RPC ports to be connectable from your IP. If possible, try disabling the firewall to test and then re-enable it immediately afterwards.
  • Good luck!

Comments are closed.