Exchange 2010 implements a change to managing security distribution lists, especially in SP1. When using the Exchange Management Console (EMC) in the RTM version, changes made to membership or ownership of a security distribution list are successful when you are not the owner. This is because a parameter of the Set-DistributionGroup cmdlet is tacitly added that allows someone with the RBAC management role of Security Group Creation and Membership to update the DL. Starting with Exchange 2010 SP1, the console no longer adds this parameter (-BypassSecurityGroupManagerCheck).

The result is that, despite being an administrator (by being in the Organization Management role), if you are not explicitly listed as an owner of a security DL, you will not be able to makes changes to ownership or members via the console…period. This goes against the functionality that has existed in the Exchange console since 1996. And better yet, Microsoft says this is by design. The fact that it worked in RTM is the bug, not the other way around in SP1. I think that is one of the most boneheaded changes made in 2010. The solution is to either add the administrators as explicit owners or have them use the shell and manually add -BypassSecurityGroupManagerCheck.

Both options are impractical. If your help desk manages DLs you can’t just add all members as owners. For one thing, even though Exchange 2010 supports multiple owners, Outlook (even 2010) only displays the first entry. This means end users won’t know who to contact because the listed owners could be one or two “real” owners and all the rest are help desk. The other option, using the shell, isn’t the easiest for anyone that isn’t a dedicated Exchange admin.

My solution for the help desk staff is a PowerShell script that uses Windows forms to provide a GUI that lets you search for a DL, display the ownership, add and remove owners, then apply the changes. It includes username validation so it won’t let you add a user that isn’t mailbox-enabled.

The one place I struggled is connecting to Exchange. The script checks for the Exchange cmdlets being in memory. If they are not, it will connect remotely to a designated server. Because that is done when the form is activated, it causes the painting of the fields and labels to be delayed until the connection is complete. I tried to find a way to wait until the painting is complete before connecting, but you can’t detect that when the fields are drawn by Windows directly and not the application.

The code is listed here, but you can also download a zip file of it:

  Change-DLOwner.zip (3.3 KiB)

Update 6/28/12: Microsoft has finally fixed this issue as of SP2 Update Rollup 3, as noted in KB 2510607.

While working with conference room calendars at my company, I set the Default user permission to Reviewer so that anyone can open the calendar to see meetings in a layout that is far easier to work with than the scheduling assistant. If you set the permission with Outlook, everything works well. If you use EMS to do it with Set-MailboxFolderPermission (Exchange 2010 SP1), it runs successfully, but not everything works well. The main thing I have noticed is that users can’t print the calendar.

I used MAPI Editor (née MFCMAPI) to see what is different when using Outlook versus PowerShell. The permission set on the Calendar folder is the same with both methods, so I suspected it had something to do with the Freebusy Data folder. I charted what permission is set on this folder with both methods with different users, and also adding a user and changing an existing one.

What I have found is that both Add-MailboxFolderPermission and Set-MailboxFolderPermission work correctly when applying permissions for named users. Setting any permission on the calendar results in the person being granted Editor permission to the Freebusy Data folder. (If you remove the permission on the calendar, the Editor permission remains on the Freebusy Data folder, which isn’t a problem.)

There is an issue, however, when setting the permission for the Default user entry which, of course, is a special user that simply represents any user who isn’t explicitly listed in the ACL. Permission on the Freebusy Data folder is not updated when setting the permission for the Default user entry on the Calendar folder, leaving the entry with a bitmask value of 0 (no rights) as seen in MAPI Editor.

To work around this issue, I looked into using Exchange Web Services and also the EWS Managed API. I ran into problems enumerating the ACL on the Freebusy Data folder (it is listed as empty). While trying to resolve that I ended up finding a much simpler solution which doesn’t need anything more than Set-MailboxFolderPermission. You can access the Non_IPM_Subtree with the cmdlet just by including it as part of the path. The workaround is to manually set the permission on the Freebusy Data folder after you do it on Calendar. This is only necessary when setting the permission for the Default user entry.

Set-MailboxFolderPermission ‘MB Identity:\calendar’ -User default -AccessRights reviewer
Set-MailboxFolderPermission ‘MB Identity:\non_ipm_subtree\freebusy data’ -User default -AccessRights reviewer

The installation script, originally referenced here, has been updated to version 1.5. It adds support for installing just the management tools, including on Windows 7. I was in the process of making it work on Vista as well, but it got messy because dism doesn’t come with Vista and I didn’t want to have separate installation routines for Windows 7 and Vista. So I am making the assumption that anyone who wants to install the management tools on a workstation has long given up on Vista.

To detect the OS (which is actually difficult and not uniform by any means) and make sure it is 64-bit, this sections is added:

Getting the processor as an array makes it work with both single and multi-processors. As a reader kindly pointed out, when run on an R2 server, it kept thinking WinRM wasn’t installed. This is because WinRM is preinstalled on R2 so the check for the hotfix KB installation will always fail. It now skips the WinRM check for an R2 server.

I also updated the menu so you can select the management tools, and made it so you only are given the option of selecting the management tools when run on Windows 7. (Only the menu reflects this restriction. If you select a different option the script will still try and run that command.) The download link is below.

  Prepare-Exchange2010Install.zip (4.7 KiB)

One of the new features in Exchange 2010 is the use of cmdlet extension agents, as described in this post. Using the Scripting Agent you can have Exchange ActiveSync disabled whenever a mailbox is created for a new or existing user. This removes the need to do it directly against Active Directory through some workflow mechanism or scheduling a task to run that does it with the Set-CASMailbox cmdlet.

There is almost no documentation on the use of the provisioning handler for Exchange 2010, leaving me to do a lot of trial and error to get it working for new mailboxes for both new and existing users. It doesn’t look like the provisioning handler has access to any of the information returned by the success of the New-Mailbox and Enable-Mailbox cmdlets. This means it only has access to the information submitted by the user in a cmdlet. Because you supply different information when creating a mailbox for a new user compared to an existing one, the code has to be different for each.

Copy the code below into the ScriptingAgentConfig.xml file and, as Pat Richard’s post details, put it in the CmdletExtensionAgents directory and enable the Scripting Agent.