Create a new managed unit for OU's

You can definitely programmatically create MUs.  There is a sample script under the "SDK" folder in your installed AR instance. I would be very hesitant to create 1000 of them as this could have some significant performance implications on the AR admin service.

Maybe you can tell us a bit about the use case that makes you think you need this many?

Thanks Jonny, I've found the relevant script. The SDK folder will definitely be a useful resource.

The business is a retailer with getting on for 500 stores. They need DL's for each store, region and country.

At the moment, the only way I can see to do this and ensure new DL's are created when a new store is created is to get AR to create the MU's when a new OU is created for the new store. I have suggested using Entra dynamic groups, but the company is hesitant for that because they use AR for dynamic groups.

If each store has its own OU, I would suggest you make a change workflow that reacts to the creation of the store's native OU and provisions the relevant groups for you (via script activity - i.e. scripted creation of AR dynamic groups) based on the name of the OU or whatever other store-specific parameters you want to rely on.

PS Interestingly enough, the programmatic creation of AR dynamic groups and MUs is very similar.

From a performance point of view, it would be better still to have a provisioning policy created for each new OU that has an embedded Group Membership Auto Provisioning Rule to statically insert the OU's users into the appropriate groups.

This approach creates much less overhead on the AR server.

The only (minor) drawback to this approach is that you would want to have a change workflow that strips any store specific group memberships from a user when they get transferred from one OU another.  Group Membership Auto Provisioning is not "self cleaning" out of the box.

PS Interestingly enough, the programmatic creation of AR dynamic groups and MUs is very similar.

From a performance point of view, it would be better still to have a provisioning policy created for each new OU that has an embedded Group Membership Auto Provisioning Rule to statically insert the OU's users into the appropriate groups.

This approach creates much less overhead on the AR server.

The only (minor) drawback to this approach is that you would want to have a change workflow that strips any store specific group memberships from a user when they get transferred from one OU another.  Group Membership Auto Provisioning is not "self cleaning" out of the box.

Thanks again Johnny.

What are your thoughts on dynamic groups for these? Is that any easier on the server than MU's?

They have about the same performance impact.

Brill. Thank you Johnny.