I see quite a few posts about this, and so thought I’d share some tips.
Funny the people that ask about the issue never thought of or knew about this solution. Perhaps the prevalence of Windows OS with options for remote desktop (RDP) have made RDP the de facto standard for remote access to Windows computers, especially since the bulk of GUI automation is run on Windows. Sigh…one should be enlightened with the other remote access technologies.
Anyhow, back to topic at hand. The issue with RDP when running GUI automation is that most GUI automation tools require an active desktop. So when you log out of RDP or lock the computer, automation is paused/stuck until you reconnect. Very bad. How to workaround this?
You need a way for the remote machine to have it’s head/desktop be unlocked and active. And the best way to do this that I know of and always use is the VNC protocol rather than RDP. There are numerous VNC software (server and client) available that are also free and/or open source. For Windows, you can use RealVNC, TightVNC, UltraVNC (the free versions are good enough, unless you need encrypted remote access, but we normally run automation within the LAN or via VPN anyways). For Windows 7, Vista, and 2008, you may need to use TightVNC or UltraVNC due to Windows UAC, which some clients like free RealVNC may not support.
Install VNC server on the Windows host machine that runs the GUI automation. Connect to said machine using VNC client (typically can be portable app, doesn’t need install, if you have the standalone executable).
Log in and keep logged in to desktop via VNC, run your automation, then disconnect VNC. Or you may opt to keep VNC client open to monitor progress. Even with VNC client closed, because it is simply a relay of the host’s screen to your desktop (works differently than RDP), when disconnected, it just stops relaying is all. And the relay works like a splitter connection, both the local head/monitor has access, and the VNC client has access, unlike with RDP where if you connect remotely, you lock the desktop on the head. Or with server OS versions, you connect separately via a separate desktop session that’s not shared with the head desktop. By this design VNC method will continue to run your automation even though you’re not connected over VNC, as long as the host desktop is logged in and not locked.
The only disadvantage of VNC is that when using it, it is somewhat slower than RDP because it’s not optimized for Windows unlike RDP.
VNC will work whether your host is a physical machine (regardless of whether you connect a monitor to it or not) or if it’s a virtual machine (VM). On VM, the head is simply a local connection to the VM via the VM software’s console. VNC will work as long as you have VNC server installed and networking to/from the host is working OK, and assuming Windows isn’t in a funky state.
In the case that automation can run even when desktop is locked, you can then use RDP as well, but need to connect as console or admin session (session 0). On end user desktop versions of Windows, you only get console session but on server versions, you get multiple session (i.e. like terminal server). If you use the other session on Windows server, on disconnect, your session stops and automation pauses.
FYI, I came across VNC because of my use of Windows during the early days (Windows 95, 98, 2000) back when remote desktop was only available on the server versions of Windows. So looked around for alternate solution and thus found VNC. Been useful since, even as a complement to normal RDP use.
Update 6/24/2013: nice to see a suggestion/recommendation to use VNC over remote desktop at the Selenium Conference 2013 (http://www.slideshare.net/dimakovalenko/selenium-conf-2013-presentation).
Update 05/07/2014: I came across an interesting article today that can be helpful when corporate network policies are strict and you can’t disable things like auto-lock on idle and screensaver passwords, etc. Kind of related to remote desktop but not quite and an alternative to VNC approach or a complement to it when combined together: http://www.allianceglobalservices.com/blog/executing-automation-suite-on-disconnectedlocked-machines
Update 09/29/2014: the following link is useful for Remote desktop and automation when minimizing remote desktop. Though I still prefer the 5/7/2014 solution overall: Running Tests in Minimized Remote Desktop Windows