In Exchange 2007, recipient management is incorporated into the Exchange Management Console and Exchange Management Shell based on Windows PowerShell technology. Shell based management for these recipients allows us to overcome several current challenges of Exchange 2003.
Challenges in Exchange 2003
There are a couple of key challenges in Exchange 2003 that we have specifically addressed with the Exchange 2007 recipient management model:
- Poor separation between Windows Active Directory administrators and Exchange administrators
- Split permissions model hard to implement, not available out of the box
- Automating user management and provisioning is difficult
- Recipient Update Service is a black box and not deterministic
How we've addressed these specific Exchange 2003 challenges
Split Permissions:
In Exchange 2003, splitting permissions for AD operations and Exchange recipient operations required some additional effort. ACLs had to be set throughout the AD to control which users had access to which objects and properties. In many cases, customers simply accepted that Exchange Recipient Administrators would need to be granted the "Account Operator" rights for the AD.
To address the split permissions separation difficulties of Exchange 2003, we've added a new Exchange Administrator role (formerly Delegation) just for recipient management: the "Exchange Recipient Administrator" role!
In Exchange 2007, Exchange-specific AD property sets were created to host the Exchange-related AD properties on recipient objects. Having these additional AD property sets, segregated from the standard AD property set, allows distinct ACLs to be placed on these property sets to allow for controlled access by an "Exchange Recipient Administrator" role, right out of the box.
You can grant someone the "Exchange Recipient Administrator" Exchange Administrator role directly through the console (image below) or the shell (Add-ExchangeAdministrator cmdlet) and they will be able to manage the Exchange-specific properties on the recipients without requiring additional AD permissions such as Account Operator, etc.
Automating Recipient Management:
Doing bulk recipient management in Exchange 2003 was no fun. Either you were forced to use tools like CSVDE/LDIFDE/ADSIEDIT/CDOEXM, or you ended up clicking, and clicking, and clicking, and clicking to work through the GUI for repetitive tasks. Doing these actions by clicking through the GUI might scale to 5 or 10 repetitions, but it definitely doesn't scale to 10,000!
In Exchange 2007, the inclusion of recipient management cmdlets in the EMS allows you unprecedented power and control over your bulk recipient management operations. Using the flexible filtering criteria and powershell object pipelining, you can easily build powerful bulk actions in a single line of "code" - an Exchange powershell "one-liner"!
For example, let's suppose you need to change the mailbox "send quota" for 1,000 mailboxes from 100mb to 200mb. Suppose these are the executives, and that all executives are identified as such by their "title" in the GAL. At its root, this bulk change requires just two basic actions:
1) Collecting the list of mailboxes to be modified
2) Making the change to the mailbox property on all of these collected mailboxes
In Exchange 2003, both of these actions may cause you some trouble. Building the collection in ADUC is not too difficult if you can figure out how to build the proper query with the "Find" command. Unfortunately, once you have your selection of mailboxes, you will need to open up the properties page, switch to Exchange General tab, click on Storage Limits button, uncheck the "use defaults" checkbox, enter the amount (in bytes!), and click ok... FOR EACH MAILBOX, ONE AT A TIME! Can you imagine doing that 1,000 times?
For Exchange 2007 in the shell, the process is much simpler. First, to collect the list of mailboxes to be modified. Execute a command like:
Get-User -Filter { Title -like '*executive*' }
That will return the object of all users in your current scope who have "title" that is "like" "*executive*" (ie - that has "executive" anywhere in the title string). For our simple example, let's assume that we don't have users who match the query which are not also mailbox-enabled. So that means the result of this cmdlet is our 1,000 executive mailboxes! Step one complete!
The second step is to take the action of setting the ProhibitSendQuota to 200mb on these 1,000 mailboxes. For a single mailbox, the syntax would be something like this:
Set-Mailbox Mailbox1 -ProhibitSendQuota 200mb
But the real power is when you bring these two actions together using the power of pipelining, like this:
Get-User -Filter { Title -like '*executive' } | Set-Mailbox -ProhibitSendQuota 200mb
With one line of "code" you've just changed the quota for all 1,000 mailboxes (and saved yourself a lot of time and clicking!)
Couple of quick answers for questions you may be asking:
How did I know to use Get-User vs Get-Mailbox? "Title" is in the Windows AD property set, and the Windows AD property set properties are available on all users, not just mailboxes, so they live on Get/Set-User. Exchange AD property set for mailbox-enabled users is accessed through Get/Set-Mailbox.
What's the filter syntax for PowerShell? There'll be a future blog post on this, but you can get started with some samples that are currently posted to: http://exchangeninjas.com/OPATHSyntaxforDynamicDistributionGroups
How did I know that the property was "ProhibitSendQuota"? I used Get-Mailbox cmdlet and looked for the one that sounded right (and/or I consulted the Get-Mailbox cmdlet help). I could also have gone to the property pages->Mailbox Settings->Storage Quotas and set the "Prohibit Send At (KB):" value for one mailbox to 200mb and then used Get-Mailbox cmdlet to find the property that had been so changed.
Removal of Recipient Update Service:
In Exchange 2003, provisioning a recipient was a bit of a black box. You'd use ADUC to set a couple of properties on an object, and the Recipient Update Service would come along some time later to set the rest of the properties (address list membership, email address proxies, etc). Depending on the complexity of your environment, this process could take several minutes or longer - during which the user could not logon to the mailbox or receive email. Worse yet, if the Recipient Update Service was non-functional for some reason, it was quite hard to tell that it was "not working" rather than just "being slow"!
Exchange 2007 has eliminated the asynchronous behavior of the Recipient Update Service in favor of a more predictable, synchronous provisioning process. When the Shell cmdlet is finished running successfully, the recipient object is fully provisioned (note that this also applies to the GUI since it's just running cmdlets underneath). The mailbox is INSTANTLY ready to be logged on to... go ahead, try it!
Further, in Exchange 2003 it was very easy for a Recipient Policy to be modified such that a number of recipients should have updated proxy addresses and yet these proxy addresses are not updated. The policy was very loosely enforced, and these proxy addresses would only be updated (often, at some unexpected future date) when the policy is specifically "applied" through Exchange 2003 ESM.
Email Address Policies (EAP) in Exchange 2007 (formerly called Recipient Policy) will no longer allow this unexpected b ehavior. If a recipient is part of an Email Address Policy it is expected that the enforced configuration of the policy would apply to this recipient. Exchange 2007 enforces the correct application of EAP criteria and settings at each save of the recipient object *OR* the EAP object. When an EAP is saved, all associated recipients must be updated with the change. Similarly, any time a recipient object is changed, its EAP membership is reevaluated and enforced. This closes the loop and makes the EAP apply reliably and like an actual "policy"!
Note that the same enforcement applies to AddressList(AL) and Global AddressList (GAL) objects as well.
Realizing that it can be a performance concern to apply these changes during working hours, a scheduling control is available to set these actions to run "after-hours":
