Do not move RBAC Role Groups out of the Exchange Security Group OU

Exchange 2010 has a massively improved admin permission model. It’s called Role Based Access Control and with it you can use predefined roles or make very customized roles if needed.

I won’t go into details how it works, for the purpose of this issue you only need to know that the RBAC roles are assigned via RBAC Role Groups. These are actual Security groups within Active Directory and when assigned a RBAC Role Group within Exchange, the user is a member of the corresponding Role Group.

The Exchange RBAC Role Groups are stored in the Microsoft Exchange Security Groups OU, which can be seen with Active Directory Users and Computers (ADUC) MMC. See image below at the left pane.

In the right-hand pane the RBAC Role Groups are listed. On the top are several custom Role Groups starting with ADM_.

The environment in question had designed a elaborate Delegation of Control model, in which all relevant groups would reside in controllable OU’s. Even for administrative roles with specific permissions to the infrastructure. To stay complaint to this model, we wanted to move the custom Role Groups to the specific IT-Infrastructure OU with other Security Groups.

Unfortunately this wasn’t possible with RBAC Role Groups. When moved out of this OU, Exchange will not list them as a valid Role Group and you cannot assign it.

Get-RoleGroup before moving my custom Role Groups via ADUC to another OU:

After moving:

Luckily it is probably more cosmetic than an functional issue, I could still assign users to the Role Group with Add-RoleGroupMember. Probably Get-RoleGroup is scoped to this specific OU. See below that assigning still works:

Checking with ADUC confirmed that the users was assigned to the role, although I didn’t check whether the role was actually working.

In any case, concluding: I wouldn’t move the Exchange Role Groups out of the Exchange Security Group OU. It could possibly break scripts or other mechanisms that count on those groups to be present in this specific OU.

This was an environment with Exchange 2010 Service Pack 1 RU4v2. Unfortunately I couldn’t check other patch levels.