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":

- Evan Dodds

Not applicable
I'm sorry, I would rather use mailbox limit policies set on mailbox stores that are easily viewable in the GUI, like it is now in Exchange 2003.  Your comment about setting mailbox limits for 1,000 people one at a time completely ignores the use of policies set through ESM.

How do you set any kind of standards to mailbox limits across mailbox stores if you're piecemealing them through a shell and can't see how they are applied in the GUI, where most of the work is done?  You're losing functionality here, not gaining.
Not applicable
So does this imply that to programatically mailbox enable a user you will need to invoke the Exchange 2007 APIs? Right now you can do CDOEXM or take the route of writing a few attributes and that will trip the RUS.
Not applicable
A little concerned about the EAP statements in regards to a hosting enviornment.
In 2003 - we actually liked the fact that we could have 2000 users fall under a recipient policy (Company = X, Department = Y), but that the RUS would NOT update their addresses unless the object had the special update GUID on it. This allowed us to maintain legacy addresses on those users (including a 1 off default reply SMTP address), while ensuring any new accounts were stamped correctly.
The way I ready your statements about EAP, those 2000 pre-existing users will get re-stamped to match the policy exactly, even if we want them to be ignored by default. So day 1, we will have to perform a lot of work to keep the EAP from doing its job, or tell the thousands of legacy users that they will have their SMTP addresses changed (which will fly over like a brick).

Please clarify how we can get the EAP to ignore legacy users that fall within the same LDAP filter?
Not applicable
As you said before "Exchange 2007 has eliminated the asynchronous behavior of the Recipient Update Service in favor of a more predictable, synchronous provisioning process". In our provisioning system that behaviour is very very very welcome!
Not applicable

You still have two options:
1) The easy way – use the powershell cmdlets and it’s all done for you magically
2) The hard way – populate the same attributes you used to do in E2k3, then call the Update-AddressList and Update-EmailAddressPolicy cmdlets to properly provision these objects (sort of like manually invoking “the RUS” in E2k3 terms).
Not applicable

I am trying to understand what you mean - do you mean that Exchange 2003 way (asynchronous) is good in your environment or the new behaviour (synchronous) is better for you? If it is asynchronous that you prefer, can you explain a little as to why that works better for you?
Not applicable
Evan, I think you may have missed the question here.  At least how I read it there was an unanswered question left:

"Exchange said:

You still have two options:
1) The easy way – use the powershell cmdlets and it’s all done for you magically
2) The hard way – populate the same attributes you used to do in E2k3, then call the Update-AddressList and Update-EmailAddressPolicy cmdlets to properly provision these objects (sort of like manually invoking “the RUS” in E2k3 terms).

Brian had asked about API's and I take that to ask about provisioning from non-windows machines.  

"Why would anyone want to do that?" you might ask.

Surprisingly, not everyone runs just Windows for their systems.  More and more there are people that need to provision across platforms and want something other than MIIS to do it.  

Does this mean that an API that is callable from a non-windows platform won't be available?  i.e. purely ldap based provisioning of Exchange?  What about ldif? Will that be supported in Exchange 2007?

Not applicable
Al - there's no way to get 100% around the powershell API. Even if you partially provision these objects with LDAP and schedule a job to run the various Update-* cmdlets at the server, powershell (on the server) is still coming into play to complete the provisioning. Note that powershell *IS* the API that is exposed for this management in Exchange 2007.

Not applicable
I mean synchronous is very welcome because our automated mailbox provisioning system is having problems with recipient policies. Sometimes we need to apply the recipient policies manually to force Exchange to write the correct smtp addresses.
Not applicable
Is it possible in Exchange 2007 to deny an administrator, that has full access on users in one OU, to manage the e-mail related properties of a user?

We have the problem, that administrators want to manage the users. But they should not create mailboxes or change emailaddresses.
Not applicable

Were did you put 'mailbox rights' administration?


Not applicable

Policies in Exchange are designed to enable flexible administration of large numbers of Exchange objects....
Not applicable
I have previously listed the progress we've been making in posting ITPro focused Systems Management blog