Showing results for 
Show  only  | Search instead for 
Did you mean: 

Managing ESM agents


Hello Forum

I am in charge to deploy ES agents in a national institution with several agencies covering all major cities of the country.

I am facing lot of issues, in which a very basic one.

For what I understood, agent must be alive all the time. I have checked by myself, if the agent is not connected to a RDP session, it stops to run scripts. I am using default recorder.

In order to control agents, I am using Remote Desktop.

I always keep alive agent sessions using RDCMAN but it's not easy to manage and I am facing lot of failures, particularly at agent restart.

I have tried several tricks (windows autologon, disconnect from remote desktop while maintaining login [ for /f "skip=1 tokens=3" %%s in 'query user %USERNAME% do( %windir%\system32\tscon.exe %%s /dest:console ) ] , nothing works fine.

Furthermore RDCman has limitations and cannot manage a huge number of session at once.

Reading the forum, I see that some of you guys have 20 and even more agents on duty. I will have to cover at least 30 agents when entering in production.

So what are the best practice to keep alive all the agents, except by putting a keyboard and mouse since in my case, it's not possible.

Thanks for your help



Dynatrace Pro
Dynatrace Pro

Hi Daniel,

I've worked at customers who've got a similar agent setup to what you are planning, with over 100 agents all around the country, so I know a thing or two about managing Enterprise Synthetic.

Remote Desktop doesn't work well with Enterprise Synthetic, because it interferes with the local Windows user session that the agent needs to control the keyboard and mouse.

The customers that I've worked with use VMWare ESXi to host the agents virtually, and use the Console feature within the vSphere client for control and management. The Console doesn't interfere with the user session - it's as if the VM was a physical workstation. This means that the agent doesn't need to have an always-on connection to the agent manager (although of course that would mean that the agent manager can't collect results if it can't connect to the agent, at least until connectivity is restored). ESXi allows controls over who can access the VMs, e.g. to only a few people within the monitoring team, and this also means that you can disable Remote Desktop on the agents for better security.

VNC would also be worth looking at if VMWare isn't an option, as it also doesn't interfere with the user's session. I don't have any real experience with Hyper-V, so I can't comment if there's a way in Hyper-V to achieve this.

Feel free to reach out to me for further questions about managing large Enterprise Synthetic deployments.



Hello Luke

Many thanks for your answer, I will evaluate this option with my customer IT support - I am not a VMware expert - but I am afraid it won't be a good answer to their needs.

They want to evaluate subsidiaries user experience by simulating the connection from end-user like machines (same kind of hardware, OS, browser, resolution ) in the true condition of their network environment and furthermore, as far as I know, there don't have VM farms in their subsidiaries, just workstations PC's.

What is remain unclear to me is why do I need to display the runs, the best option should be to run the scripts in silent mode on the agent workstations, and to connect it only in case of need.

Is there any way to get this result ?



Dynatrace Pro
Dynatrace Pro


Because the robots actually use the keyboard/mouse/screen to execute the scripts, the session must be logged on and not locked, no screen savers etc.

(If you are using only autochecks, this is not required)

As you've discovered using Remote Desktop (RDP) is not suitable, because it'll often lock the session when you disconnect preventing the scripts from running. There are ways to prevent this, but in my experience it's not reliable, and certainly won't work if the session isn't gracefully disconnected.

As Luke mentions, a real remote console solution is required. With VMWare/HyperV you get the real (as far as Windows is concerned) console and you can leave it unlocked, and still secure because it's behind virtualisation, there's no keyboard/mouse/screen for a local user/attacker to get to. Third party options like VNC (various free ware/open source implementations are available), Dameware, Tivoli Remote Control etc. etc. provide the same functionality.

Lastly, you need to ensure the workstations are not subject to screen savers or inactivity lockouts. In most corporate environments the group policy for workstations will enforce these, you need to get the robot workstations placed into another OU which disables screen savers and lockouts.

Synthetic robots today are very high maintenance, development are working towards being able to run scripted transactions with locked screens in the next major release.

VM's are usually a good idea for robots, you can still configure them to have the same CPU and memory resources and OS/applications as the real desktops, but you gain in areas of security (no unsecure desktops sitting around, or taking up data centre space), remote management is easy, as is recovery if it breaks, just redeploy an image and you're running again quickly.



Hi Daniel,

Let me start with the fact that both the application being monitored and the
Recorder need an interactive Windows desktop. Your problem is how to keep
the desktop open. When the desktop
becomes unavailable, a problem commonly knows as “locked screen” arises. If you use autologon and VNC, without combining it with RDP, you most
likely will not have any problems with keeping the desktop available. But, as I understand, you and your customer
are not comfortable with using this approach with physical machines.

Using RDP with the Recorder is not easy, even though some, but very few, customers
do it. I might not know everything it
takes, for instance I’ve never used RDCMAN. But I can give you some information that
might help you.

The loop around tscon
you presented in your question aims to switch the remote desktop to become a
console desktop. I doubt this is what
you are really trying to achieve.

One of the problems of using RDP is that by default it enforces the screen size
of the RDP client machine to be the size of the desktop of the user
session. You can, though, specify the parameters
to mstsc
so that the desktop size would be the same as default size of your agent’s
desktop. To find out default size of
your agent’s desktop execute autologon, then VNC to it, run msinfo32, and go to

With everything said above, let me remind you that using RDP is not a
recommended way for desktop creation/retention.

If you provide more details on what you tried and the problems you faced, you might
get more specific answers.

Hopefully you will be able to find a solution that would satisfy your customer
by reviewing the answers to you post and other Forum posts on the subject.

Thank you,



All, many thanks for your useful recommendations.

Best regards - Daniel