Primary / Secondary Owners inheritance

I'm looking to automate the primary/secondary owners of Security Groups - based on the primary/secondary owners of the OU that the Security Group is contained within.

Security Groups (top ou)

--Application Groups (sub ou)

-- --Application Team1 (sub ou)

Application Team1 OU will have a primary owner (the manager of the application team1 "team")

Application Team1 OU will have a secondary owner (the security group Application Team1)

I want all groups created in the Application Team1 OU to be auto populated with the primary/secondary owner from the parent OU. If the manager is ever replaced, we could change the owner of the Application Team1 OU and it will automatically update all the security groups below it.


Hopefully that makes sense. Seems like it would be easy to do, but I'm struggling a little bit.


  • IMO, the solution consists of two parts:

    1) The initial population could easily done by a property generation & validation rule within a group provisioning policy that applies these values at group provisioning time.

    2) For updates, I would setup an AR workflow that watches for changes in these values on the parent OU (start condition) and then finds all the groups in the OU (search activity) and updates the owner attributes (update activity).
  • #1 - I figured there was a way to do this with a group provisioning policy - took me a bit to figure out how but now it completely makes sense. Works like a champ.

    #2 - Having a hard time wrapping my head around the workflow part.

    Created new workflow
    - Operation Conditions (I think this is correct) - Modify Properties of type Organizational Unit - managedby and edsvaSecondaryOwners properites

    -Initiator Conditions (I think this is where my problem lies)
    Initiator - Any User
    Container - I'm assuming this is the OU that I want the workflow to "watch" for modification? or is this the OU for the "initiator users" ?
  • -- Initiator is a way to filter by who made the change, Any User is just that, any use that makes the change will trigger the workflow as long as it meets the scope of the other filters.
    -- Container is the location of the objects you are monitoring for the changes -NOT the Users Making the Changes.

    Hope this helps!
  • Thanks, definitely helps.

    I actually configured the "search" and "update" - it worked ONCE. I made a change and now I have no idea how to get it to work again. The more I read, the more confused I seem to get.

    Search Activity - Search in the OU or container - find Groups - IN Parent OU of Workflow Target. Retrieve any objects held in OU or Container (I think all this is fine??)

    Update Activity - This is where it gets a bit confusing. I'm completely new to workflows, so don't be afraid to treat me like a 3 year old.
    Activity target - Found object ("Search for objects")
    Target properties - property "managedBy" set Value Found Object (search for objects")/Parent OU/Manager

    Obviously this doesn't work, but am I at least on the right track?
  • Sounds like you probably are.

    The Update Activity has to be a "child" of the Search - it has to live right in the Search's extended gray box in the workflow workspace area. (Can be hard to see on some screens) When physically positioned that way, you are telling the Activity to act upon each of the objects returned by the Search.

    The internals of your Update activity sound right.