Sync issues with scheduled tasks

Could you verify if you get a log in RDM that the task was executed?

Regards

Hi David, sorry it took me a while to get back to this issue but I'm still facing this problem with all of my scheduled sync tasks for RDM, even with a newer version of RDM.
Actually, I don't know where to look in RDM to figure out what happens during the run of such a scheduled task.
I can only see in Windows Task Manager that RDM consumes lots of CPU and sometimes 1GB+ RAM for hours but eventually never gets anything done until it gets terminated by the task scheduler timeout of 2 hours.
Like before, when I execute RDM with the same parameters and user as defined in the scheduled task from a command box, the RDM GUI fires up for a few seconds, displays a floating "synchronizing" box and terminates itself some more seconds later.

And I have absolutely no clue how to figure out what RDM is doing when getting launched by the scheduled task.

Help... please?


Running RDM 11.7.2.0 - SQL DB Data Source - Multi User setup

Hi,
Could you give more details about the task you try to use? Could you try to create a batch file that execute RDM and verify if it makes a difference?

Regards

As written in my first post, the task is supposed to synchronize AD computer (server) objects with RDM RDP sessions. I have other tasks that should synchronize RDM with CSV sources. However, none of them is working when launched using the Windows Task Scheduler. Whereas starting the exact same command with the same parameter and the same user works flawlessly.
The command would be

Start a program: "C:\Program Files (x86)\Devolutions\Remote Desktop Manager\RemoteDesktopManager64.exe"
Parameters: /DataSource:208755c3-b586-428f-ad66-c9fa73ae5a97 /Session:5e0a0488-a1e5-44a7-b30c-5924d98fad0c /CloseOnDisconnect


I've also attached two screenshots from the actual scheduled task and a line from the task manager which show cpu and ram usage for RDM but essentially does nothing.

I created a cmd file with this exact command line and started it from a command box, launched with the credentials of the GA4214 user which is also used for running the scheduled task.
"C:\Program Files (x86)\Devolutions\Remote Desktop Manager\RemoteDesktopManager64.exe" /DataSource:208755c3-b586-428f-ad66-c9fa73ae5a97 /Session:93cffc2b-375f-469a-ac61-aeb2b471c500 /CloseOnDisconnect

Execution works flawless, first a text message appears in the command box then the GUI comes up, does its sync, saves something to an offline file and then shuts down again, all within 30 seconds.

Could it be possible that you need to have a user logged? I suspect that RDM does not work if it's not the case.

What do you think?

You mean having an interactive session? But that would render the use of scheduled tasks totally unusable? And would be a total disaster to my highly automated RDM environment. :\:

I've set up the sync with scheduled tasks employing a separate service account according to your recommendation here: https://help.remotedesktopmanager.com/index.html?entrytype_synchronizer.htm

Can you maybe include someone from your tech team who is responsible for the RDM sync/task scheduling topic?

This is just a theory, I'm not sure this is the problem. I will check if somebody is able to reproduce it. The other solution could be with PowerShell.

Hello,

The quotes around the "service account" are meaningfull, it is to be a user account that is in defined in RDM. It has nothing to do with a Windows Account, apart from if you are using integrated security.

Have you removed the right to interact with desktop to the account that you are using?

I will enrich the documentation to clarify.

A late feedback on this as it might help others who are stuck with the same problem.

I finally figured out, that it is CRUCIAL to configure the scheduled task to be "Run with highest privileges".

Otherwise the above mentioned behaviour of RDM getting started, consuming some CPU and RAM for some seconds then declining to around 50MB RAM usage with 0 CPU consumption and stays there forever, eventually getting killed manually or by the task scheduler configured run timeout. And actually no sync is ever performed.