In Exchange 2010 distribution groups must be universal. This is supported by documentation
You can create or mail-enable only universal distribution groups.
I am trying to create a role based security group structure so that if someone leaves or changes jobs you only have to change the groups membership of a users "role" (Where the role is just another security group). In its simplest form roles would have users for members and the role would itself be a member of other resource-centric security groups e.g. a read-write group for a share. There is more to the model than that but it should be enough for the purpose of this question.
The problem comes from when I want to add these role groups as distribution members. If I try and add a "Marketing Manager" role to the "[email protected]" distribution list it will not forward mail to the role members unless the role security group is universal.
Universal groups cannot be members of global groups though. So, if I wanted to convert my role groups to universal so that I can mail enable them I would then also have to change the groups the role itself is a member of as well. This means that I would be converting near all my security groups in AD to universal to support my proposed structure.
We are a single domain forest with about 1000 users and I would expect once all the groups for this are made to have 1000+. Functional level of the domain is 2008R2
I honestly don't know of the impact this might have in our active directory environment. Is making all the group universal really the only way to do this if I wanted to add my roles to distribution groups? The answer appears to be yes if I want them to be used for mail. I do want this so that way help desk users don't have to worry about what groups users need. They just need to know their "role".
The linked question answers why I cannot just have simple security groups but I want to know if my proposed structure, meaning that I will be converting near all my groups to universal, has any negative implications or is maybe considered a bad practice.
If you only have a single domain and all of your domain controllers are global catalogs, there isn't much impact. Best practice is all domain controllers should be GC's.
In large forests with multiple domains, it can be advantageous to limit what groups are universal. This is due to the member attribute of universal groups are replicated to the global catalog. Consider a scenario with a large forest, multiple domains, a large number of universal groups with a high member count, all of those members would exist in the global catalog and be replicated to every domain controller/domain. This replication and the resulting increase in the database size could be minimized by creating a global group in each domain, and having a single universal group where the members are the global groups.
This is less of an issue today than in the past. Prior to Windows Server 2003, all group members were replicated ever time the group membership was updated. It wasn't unusual for large universal groups to be in a constant state of replication. Now only the added/removed members are replicated.
If your AD environment and groups are very old (created prior to Windows 2003), it's possible they may not yet support the new Linked Value Replication capability to replicate only the added/removed members, but that can be fixed by removing/re-adding the members. You can confirm this by running repadmin /showobjmeta for the group. If a group member appears as "LEGACY" instead of "PRESENT", it should be fixed before converting to a universal group.
Another way to think it would be to create dynamic distribution group if you don't want to change your groups.
That way if in AD you type for a User X an attribute, like, show there for the Office, then Exchange do the rest.. (image took from there)
You add the attribute;
You create the group;
Exchange do the rest, as long you keep your attribute up to date when a user quit for another job/office.