Saving the users OU

Question

Hi

Using the latest 2018.1 build, I have a user deprovision task which stores relevant information about the user to the custom attributes before disabling and moving it.
I've tried a number of options, but I don't seem to be able to write the users originating OU to their account :|

The best result I can get, is to set custom attribute text 1 to %ou%, as I don't get any errors, but at the end of the event log, there is an entry which says that the first business rule is it clearing this same attribute!

There is nothing in the business rule to do this, it simply sets this attribute and then moves the user to a deprovision user OU for further processing. Any thoughts on why this is happening?

Thanks

Matt

Comments

Hello Matt,

For troubleshooting purposes, could you post here or send us (support[at]adaxes.com) the following screenshots:

• A screenshot of the Execution log you get when deprovisioning a user.
• A screenshot of your deprovision task.
• A screenshot of the Business Rule that is specified as clearing the custom attribute.

---

Hi, I've just emailed you.

Thanks

Answer 1

Hello Matt,

Thank you for the provided details. You see clearing the custom attribute in the Execution log because the ou property is empty for the user. This behavior is by design.

To save the distinguished name of the container where the user is located before it gets moved to another location, use the %adm-ParentDN% value reference. Your action will look like the following:

Comments

Brilliant, I shall give it a go.

So the %ou% attribute isn't used by Adaxes for anything?

---

Hello,

Actually, the ou property is used to store the name of an Organizational Unit. It is not automatically populated for users unlike for OUs. You need to set the property value manually if required. This behavior comes from Active Directory, not Adaxes. You can check details about this property in the following article by Microsoft: https://msdn.microsoft.com/en-us/library/cc221049.aspx.

---

Thanks for the info.

---

Just to confirm, using the %adm-ParentDN% attributed worked a treat.

Thanks as always for your help :D