Exchange 2010 Post-Upgrade weirdness: can’t edit Mail Non-Universal Group or Security Group
By: Evan Hoffman
Tags: Migration, Exchange 2010, Exchange, Ad, Active Directory

Now that everyone’s been moved to Exchange 2010 we’ve started using the 2010 Exchange Managment Console/Shell exclusively which has revealed some weirdness. First, we created a new group in AD using an old script (which used LDAP) and created a Mail-enabled Global Security group. We put people in the group, and everything seemed to be working fine until it was discovered that users in the group couldn’t see the group in the Global Address List. Users not in the group had no problem seeing the group. Additionally, users in the group couldn’t see users added directly in 2010. This only appeared to affect the GAL; the users were able to send/receive email fine with the full SMTP addresses.

My first guess was that I was being punished for having forgotten to upgrade the LDAP address lists to OPATH. I don’t really know what that even means, but when I attempted to edit the address lists in EMC I’d get an error that they needed to be upgraded. Fortunately, this Technet article lists the commands needed to upgrade the lists. I did it but this didn’t appear to resolve all the issues.

At this point, after some Googling, I came across this tidbit:

If you’re moving from Exchange 2000/2003 to Exchange 2007 or Exchange 2010, you’re going to want to convert all your domain local and global distribution and mail-enabled security groups to universal groups so they can be managed using the Exchange management tools.

This explains a few things we’ve noticed — inability to add Global (Non-Universal) groups to a newly created (Universal) group, for one. So it appears what we should do is upgrade all the Global groups to Universal. First, how do we get a list of all the Global groups? EMS/PowerShell to the rescue:

[PS] C:\Windows\system32>Get-Group | Where {$_.GroupType -Like "Global*" -AND $_.RecipientType -eq "MailNonUniversalGroup"} |

Export-Csv -encoding "utf8" -Path \\fileserver\Tech\groups1.csv

You can refine the filter further, and when it looks correct you can just pipe the output to Set-Group:

Get-Group | Where {$_.GroupType -Like "Global*" -AND $_.RecipientType -eq "MailNonUniversalGroup"} | Set-Group -Universal

But now for the most important question: will this break anything? I have no idea. We only have a single domain in our AD forest so we’ve never had need to use Universal, and I don’t think there should be a problem, but I don’t really have any idea.

I ran the Get-Group/Set-Group commands and they seemed to work as intended for all but about 60 of the target groups. The groups that didn’t get converted all had weird issues — aliases that contained illegal characters (which I fixed), or some of them complained that a particular user (I think the Owner of the group in AD) was not found (even though it was in the exact location it was saying it wasn’t, though the user was disabled). I “manually” converted these groups to Universal via the radio button in the properties dialog in Active Dir Users & Groups. Not the most elegant solution but it worked. So all the groups in question are now Universal Security groups. Will this solve the problem? Well, I’ll have to wait until tomorrow to find out.

Reference links: