When you run the rules manually they execute as the logged in user. Scheduled tasks run as local system by default
You need to set the Managed Planet Core Scan service to run as a user that has rights locally to the server and try again.
What rules are you trying to run?
Thanks for input. I checked, and the same Data Map, and Data Rule sets were running via the system account, on my old LANDesk 9.5 server. However, I nevertheless tried running them using a domain account that has elevated privileges on the server, and I got the same result as before. Whatever the source of the problem is, it has nothing tdo with my specific rules. I can run of one of the rules that LD supplies as a scheduled task, I will get the same result: rule does not produce result.
2 of 2 people found this helpful
When you schedule a rule or rule group, a Custom Script is created (Via the Toolbox - Manage Scripts). This script runs a LOCALEXEC meaning it will start a command on the Core Server, in this case the MPRUNSCHED.EXE followed by the custom ID of the rule or the group. As any other custom script, this is run under the local system account. The Interactive Services Detection Service on the Core Server will generate a popup asking if you want to see what's running in the background. However, in Windows Server2012, this service has changed behavior. It is stopped and set to Manual by default. If you try to start is, you will get the error about the incorrect function like the one in your log.
To be able to start the service, try setting this registry key:
Change the value “1” to “0”
I'm not sure if this will actually solve the problem of the outcome of the rules, but at least you will be able to see better if the rule starts and get rid of that specific error.
If the rule starts, you might also want to check the logs in the MP_Logs map in the ManagementSuite map on the Core for more information.
Frank Wils's response on Jun 27 did indeed resolve the error log entry every time a Data_Map rule was run via scheduled task. However, some of the rules were still not accomplishing their intended purpose when running as scheduled tasks. But, with the error log entry out of the way, I was able to isolate the cause. The rules that were not working were written to run on All Targets. When they rules are run inactively, that is the default when no targets are provided. However, that turns out not to be the case when run via scheduled tasks. So, the final part of the solution was to provide explicit targets for each rule, and if the targets were indeed All, then a simple query that resulted in All Targets being selected met the need.
Hi @hparker, have you filed a case for this issue yet? Technically these rules should work, when scheduled, and with or without a target. The reason I ask is because I believe that this would be a bug that should get filed through our frontline support team.