Something I have noticed over the years is a tendency for organizations to duplicate effort by having separate security and distribution groups for the same people.
For example, in one organization a security group is used to grant permissions to register new devices with the BYOD mobile email service. A staff member who wishes to get their work email on their iPhone is added to that security group so that they can enrol their device.
In addition to that, another group exists for notifications to be sent to BYOD users, for example when there is upcoming planned maintenance.
The help desk for this organization has to manage the memberships of two groups that will, in all likelihood, always be exactly the same. The reason they have two groups is because the security group follows an IT-centric naming standard, such as “SEC_MobileDevice_BYOD“, whereas the distribution group has a more user friendly name such as “BYOD Mobile Device Users” that looks nicer in the global address list.
If the only reason for having two groups is for naming purposes then you can solve that by changing the display name of the distribution group.
To demonstrate, I have a universal security group in Active Directory called App_Tier2_ABCDEF.
When I mail-enable the group using the New Distribution Group wizard, it still has the name App_Tier2_ABCDEF, and that is how it will appear in the GAL.
However, if I then use the Exchange management console to change the display name of the group to ABCDEF Users, then that is how it will appear in the GAL (note: you may need to wait for the offline address book to update before you see this change. If in doubt, use OWA to verify it).
Now the help desk would only need to manage membership of a single group to serve both purposes.
However, this does not suit every situation. In one organization I have worked with there was a group used for this dual purpose. One day an administrator was looking to grant a group of people access to a resource. Reviewing the existing groups with access to that resource they decided to nest the new group in the existing one. However they did not realise that both groups were also mail-enabled, so in effect they had just added thousands of people to a mailing list that was not relevant to them.
Of course one day this situation blew up when an harmless group email was sent out, and a few thousand people who weren’t interested in it also received it, kicking off one of those glorious “reply all” storms as a handful of people request to be removed from the list, and then others begin replying all to scold them for replying all, and so on and so on.
So as you can see, although this approach can be used to reduce administrative overhead, you also need to be cautious of situations where it will cause even bigger problems. My view is that fewer groups to manage are better, and most of the risks can be avoided by good admin processes that avoid reckless actions like nesting of groups where the relationship between them is not understood.