We’ve written a Before Provisioning Rule in IDN/ISC to update/ placeholder the AC_NewName attribute in Active Directory during a name change scenario.
However, we’re seeing this error in UI and IQService Logs:
[“Failed to update attribute AC_NewName Error - There is no such object on the server.\n”.
Has anyone experienced this with custom AD attributes? Could this be to a stale DN or timing issue in the provisioning plan?
Any insights or recommendations are appreciated - especially if you’ve dealt with similar scenarios involving custom attributes or object not found errors.
If you’re changing the user’s name (which might change the DN) and trying to update AC_NewName in the same provisioning plan, the order of operations might be wrong — AD may not find the object under the old DN after the rename.. Ensure AC_NewName is properly extended in your AD schema and reflected in the IQService configuration (custom schema and allowed attributes for update). first process the rename (changing DN), and only after that succeeds, send a second provisioning call to update AC_NewName.Add logging inside your rule to output the DN being used and whether the object exists before performing the update.
Thank you for the reply. I double checked our provisioning plan and the order of operations. The provisioning plan is set up exactly the same way as you described here, including logging the rename and DN update.
Thank you for sharing the guidance! Unfortunately it doesn’t offer comprehensive resolution on how to fix various errors. Our provisioning plan was working fine at the implementation stage and we started getting above mentioned error few months ago.
I understand but the user is changing only last name not a department. The before provisioning rule we have states if users last name or first name is changed it will look for attribute AC_NewName. If users department is changed it will look for AC_NewParent. In our specific case we are having issue with last name changes.
Hi Nara,
AC_NewParent and AC_NewName are internal to IdentityNow. These are special attributes which helps the connector identify if the OU or CN. If you want to changed only the AC_NewName you will also need to add AC_NewParent. Is your requirement to only change AC_NewName. If so can you try to also add AC_NewParent with the same value you currently have and see if the issue gets resolved ?
Yes, I’m aware of the both attributes. I’m confused in the part where we need to add AC_NewParent? AC_NewParent attribute is part of our before Provisioning plan as well. Below attached are screenshots of our provisioning plan.
Make sure you add AC_NewName to the accountRequest first, and then add AC_NewParentafter that, to avoid the issue.
Why AC_NewName should be set before AC_NewParent?
Setting AC_NewName before AC_NewParent ensures that the object is renamed (CN change) before it is moved to a new OU. This sequence is important because:
AC_NewName (CN) changes the Distinguished Name (DN).
AC_NewParent (OU) changes the parent container, altering the path (DN) where the object resides.
If we reverse the order and set AC_NewParent first:
The system will move the object using its old name (CN).
When it then tries to rename it (AC_NewName), it may fail to find the object at its original location, because it has already been moved.
As a result:
The OU change will succeed.
The rename may fail, depending on how the provisioning engine tracks object state post-move.
Therefore, we set AC_NewName first to ensure:
The object is renamed in place (same OU).
Then safely moved to the new OU using the updated name.
I checked and yes, AC_NewName is added to the accountRequest, but the order of operations is not as described here. I read your post as well. You had similar error AC_NewName error a year ago. Have you fixed the error by reversing order of operations: first setting AC_NewName and then AC_NewParent.
