Hi Sathish, I'm not sure about your setup but on a bit of research, as well as having the remote loader running successfully in our AD, I have some suggestions on what may be preventing this.

You may already have this implemented, but the remote loader must be on a domain controller. With setting the password, and the tightening of security on Microsoft platforms, you may need to make sure that the connection to the remote loader is using TLS (ssl=yes) which may require using the AD server FQDN by name rather than IP address so the certificate can be verified.

Have you checked your remote loader log file? Might be worth checking that to get a picture from both sides. Remember to set a decent log level to get some detail. Might be worth checking to see if the account you are using has the privileges to set the password. Log on to the controller that the remote loader is running on and try to set the password manually -  with the admin account in question.

Jon

It is not about the reason of that error. but how to handle the error in the Input Transformation Policy. 

My apologies Sathish, I didn't realise you had resolved the password setting issue. I have limited experience in the rule creation process. I did do some writing of rules for my test network but it was limited in scope.

Why do you have of XML Expression @level=success?  You want @level=error with appropriate punctation to work.

Then the contents under the <status> node (the current operation so in XPATH, . (period) is the error.  Most drivers dump text.  AD dropes some XML as you show.

I have a use case based on the status.

If success, send mail & If error create a ticket in service-now.

As the policy is getting executed 3 times with 1 success and 2 errors. Now 2 tickets are created in service-now. 

There is a token for xml attribute that may help you avoid the XPath entirely in the if conditions.

However, if you need to inspect / compare / modify the status of sibling statuses, you may need to read up on my series regarding the current-op

Delving into and beyond the current-op – Part 1 - Identity Manager Tips & Information - OpenText NetIQ Identity Manager (microfocus.com)

Delving into and beyond the current-op - Part 2 - Identity Manager Tips & Information - OpenText NetIQ Identity Manager (microfocus.com)

Delving into and beyond the current-op – Part 3 - Identity Manager Tips & Information - OpenText NetIQ Identity Manager (microfocus.com)

Input Transformation Policy is the correct place to locate this.

The operation data  enable-36M1admAccount is not present in your source example, on any of the all three statuses, so that part will never be triggered no matter what.

Are you sure your fragment of DirXML-Script policy is the one that is actually being triggered in this scenario?

enable-36M1admAccount is another example. I just posted here to highlight the xpath expression that I use.

My only concern is that the rule is running 3 times becoz of the 3 nodes in the output which i posted.

As it is running 3 times, 2 actions are triggered for the same event. 

[08/19/24 11:53:25.566]:MFGFactory PT:Applying policy: %+C%14CVCC-Pub-IPT-Status-36Accounts%-C.
[08/19/24 11:53:25.566]:MFGFactory PT: Applying to status #1.
[08/19/24 11:53:25.566]:MFGFactory PT: Evaluating selection criteria for rule 'Status Tracking - Success - 36 Accounts Creation'.
[08/19/24 11:53:25.566]:MFGFactory PT: (if-operation equal "status") = TRUE.

*******************************
********************************

Again 

[******************]:MFGFactory PT: Applying to status #2.

*******************************
********************************

Again 

[******************]:MFGFactory PT: Applying to status #3.

It is running 3 times because the initial transaction from IDM resulted in three actual transactions in AD, so you get three status responses. The trace you show above is "working as intended"

I strongly suggest you read my three articles linked above. I think they might help you better understand how this all works and how to solve this. 

I agree with AlexM. I think the confusion is around the nature of an 'event' vs an 'operation'.

You thought you sent in an <add> operation.  But betcha there were some groups, or or other things, and the password was peeled out of the <add> and sent instead in a <modify-password> event.  So your one 'event' got split into 3 events, which also are 3 seperate operations, each of which returns a <status> operation.

Your rule for reacting to <status> operations, will run once for each <status> in the <output> node.