Skip to Content
author's profile photo Former Member
Former Member

SAP IDM 7.2 dispatcher loop


I am experiencing a weird problem with my SAP IDM 7.2 SP10 running with an MSSQL 2012 database on Windows 2012 R2. While for the first time trying to provision a user into our productive active directory, the dispatcher suddenly went "out of order". It has not stopped, but it seems to be stuck in a loop. The task it was trying to enter was the provisioning of the user's password, which probably did not work, because we have not yet set up correctly the ssl connection to our productive active directory.

Nevertheless, I have tried everything I could find in this forum, checking the mx_provision, the audit_ID table and even killing running processes. The only thing that worked was actually recreating the dispatcher, meaning not only un-installing it and creating new skripts, but really creating a whole new dispatcher and deleting the old one. But because I still have not figured out the ssl connection entirely, the dispatcher is now stuck again. For many obvious reasons, creating a new dispatcher each time this happens, is not a good work-around, so I am desperate for some advice.

When I stop the dispatcher and test it, the cmd is filled with this command:

run_ms: C:\SAP_IDM\...\Identity Center\dsert.exe PMCSQL/ukd_prov:{DES3CBC} followed by a long string of numbers and letters

dsert.exe is the DSE windows runtime engine, but I am not exactly sure, what is happening there. The only thing that I can still find in terms of tasks/jobs that might be stuck somewhere, is that I can see the password job in the mc_taskjob_queue, could this be causing the loop? And if yes, how do I get rid of it?

Thanks everyone in advance,

kind regards

Lisa Zimmermann

Add comment
10|10000 characters needed characters exceeded

2 Answers

  • Posted on Feb 23, 2017 at 09:41 PM

    Hello Lisa,

    so the job is running into an error and re-tries again and again or what do you mean by "loop"? Or don't you get any errors in the job log? If yes, you could check how many repeats after an error are set on the task/job. I've seen task where someone put 1000, so if the task runs on an error and nobody resolves the error, that task will be tried and tried again... 1000 times!




    Add comment
    10|10000 characters needed characters exceeded

  • author's profile photo Former Member
    Former Member
    Posted on Feb 24, 2017 at 11:04 AM

    Hi Steffi,

    thank you, but the retries field is set to 1 only for all our jobs. You can see the loop in the cmd console when testing the dispatcher (after stopping it), it is as if it is trying over and over to start the job of setting the password, but never actually managing to. I'll attach a screenshot here. screen-shot-02-24-17-at-1155-am.png

    I figured out now that if I first clear the respective entries in the provisioning queue, then set the audit flags to 1100, then clear the entry from mc_taskjob queue and finally killing all running processes, I can "free" the dispatcher again, leaving me, of course, with some broken identites, because the provisioning hasn't finished. But at least this way I do not need to re-create the dispatchers.

    Nevertheless, this loop only occurs with this password setting job. I do not get an error from the job, it actually never really starts and the job before runs through cleanly. But in the provisioning audit table the overall task group is in the state "running".

    Kind regards


    Add comment
    10|10000 characters needed characters exceeded