Exchange Recipients have changed a quite a bit since Exchange Server 2003. With this post I will try to give you an overview of how it works now and eventually a few tips regarding troubleshooting.
Recipient Management
One thing that definitely will make Exchange Administrators life easier is the Recipient Configuration container as it brings such a simplified recipient provisioning for them, such asthe fact that we can split permissions in a single forest, or by other words we have the ability to delegate recipient management to a lower level Administrator as in we will not need to give unnecessary permissions to someone that should just deal with Recipients Management; other ability is we can now create Active Directory objects and mail or mailbox enable them without the need to use Active Directory Users and Computers.
We have improved a lot in terms of scoping as we can now choose between Domain or Forest scoping which basically will allow the Administrator to see only the objects relevant to him, and it can go down to a Organizational Unit level.
Finally seems that Exchange Server was the clear distinctions software starting on the server roles and yes, even here on Recipient Management. We now have very clear and distinct recipient types such as User Mailbox, Room Mailbox, Equipment Mailbox, Linked Mailbox and Shared Mailbox.
There is no longer a need to wait for a recipient to be populated or stamped from Recipient Update Service. Once a user is created from the Exchange Management Console or the Exchange Management Shell, the user is ready to go. If you use the Exchange Management Console for this task, the Edit Email Address Policy wizard will guide you through the process of editing and applying the policy. If you use the Exchange Management Shell, you will use the Set-EmailAddressPolicy cmdlet to edit the policy settings and the Update-EmailAddressPolicy to apply the policy to the intended recipients.
The policy is created with the mailbox now, and once it's created it takes effect immediately for users. For a recipient to receive or send email messages, the recipient must have an email address. Email Address Policies generate the primary and secondary email addresses for your recipients (which include users, contacts, and groups) so they can receive and send e-mail. By default, Microsoft Exchange contains an Email Address Policy that specifies the recipient's alias as the local part of the email address and uses the default accepted domain. The local part of an e-mail address is the name that appears before the at sign (@). For Email Address Policies, you define how the recipients' e-mail addresses will display. For example, you may want to have all of your e-mail addresses display as firstname.lastname@domain.com. In Exchange Server 2007, recipient policies (which were part of Exchange Server 2003) are divided into two separate features: accepted domains and email address policies.
Working With Recipients
In Exchange Server 2007, recipients are comprised of mailbox users, mail-enabled users, mail contacts, distribution groups, security groups, dynamic distribution groups and mail-enabled public folders. In previous versions of Exchange Server, you performed recipient management tasks in Active Directory Users and Computers. You can actually now create Active Directory user accounts from within the Exchange Management Console or Exchange Management Shell when these are mail or mailbox enabled. However, although you can perform all recipient management tasks in the Exchange Management Shell, only some are performed in the Exchange Management Console.
Working With Recipients And Active Directory Users And Computers
Have you ever asked yourself if having Exchange Server 2003 and Exchange Server 2007 in your Exchange Organization and using Active Directory Users and Computers extensions from Exchange Server 2003 to create a mailbox in an Exchange Server 2007 database, would work?
Answer is quite simple... or not. We do not have any way to block creating mailboxes on Exchange Server 2007 from Exchange Server 2007 Active Directory Users and Computers extensions, but it is not supported. There are negative consequences to doing this for the mailbox – principally that Exchange Server 2007 will see this mailbox as a “legacy” mailbox rather than a true Exchange Server 2007 mailbox and that will block various Exchange Server 2007 actions and properties from being edited.
To retrieve and fix all mailboxes wrongly set on the Exchange Server 2007 we need to run the Set-Mailbox -ApplyMandatoryProperties cmdlet. That parameter applies the mandatory properties to the "legacy" mailbox, such as version and type metadata associated with the mailbox. When you apply it a few steps happen:
-
Check whether the mailbox is hosted on Exchange Server 2007 by verifying its ServerLegacyDN (by the prefix “/o=<OrganizationName>/ou=<DefaultAdministrativeGroupName>/”);
-
If it is, we do both of the following things: the ExchangeVersion value is changed to Exchange Server 2007, "0.1 (8.0.535.0)"; the RecipientTypeDetails/RecipientDisplayType is updated according the value of “IsResource/IsLinked/IsShared”;
-
Otherwise, we error out to tell that the task cannot do it because it is hosted on legacy server;
The end result is that the mailbox will have its ExchangeVersion, RecipientTypeDetails, and RecipientDisplayType updated to match reality. When you create a mailbox through Exchange Server 2007 tools, all this process happens automatically. When you create an Exchange Server 2003 mailbox with Exchange Server 2003 tools and move it to Exchange Server 2007, it still happens automatically. However, if you create an Exchange Server 2007 mailbox using the Exchange Server 2003 Active Directory Users and Computers extensions, it will not happen automatically. Run this cmdlet against a mailbox where it's already been run will just reset the values to the same (correct, and presumably current) value, so no problem at all.
Scoping
The default scope for the admin session (whether in the Exchange Management Console or Exchange Management Shell) is what's called Domain Scope. This means that your admin session is configured to talk to a Domain Controler (not to the Global Catalog port, even if it's also a Global Catalog). And it means that your reads/writes will only operate within this Domain's Domain Controlers. This is pretty much how Active Directory Users and Computers snap-in handled scope too. Scope for the admin session only applies to first class objects. If I do Get-Mailbox cmdlet while I'm in Domain Scope, I'll only get back mailboxes (the first class object requested) for the current Domain Scope.
The Forest Scope is a little different. When you're in Forest Scope, the admin session talks to a Global Catalog for all reads (to get the whole Forest view), but does any writes back to a Domain Controller in the appropriate Domain. This is great because it means it's possible to get a view of all mailboxes in the whole Forest, for instance. But it's also bad, because when you're in this mode, replication latency can make things in your view be out of date - since you're reading from a Global Catalog and writing to a Domain Controller in the object's Domain, it's quite possible you won't read the latest data if it has just been changed. So, short version - Forest Scope is great because it lets you see a unified, Forest wide view. But beware of replication latency in some cases.
Administrators can control the scope of recipients shown to be the whole Forest, a whole Domain, or by Organizational Unit within a Domain by using the Modify Recipient Scope context menu of the Recipient Configuration node. Setting your scope controls which recipient objects will be displayed in the Graphic User Interface result panes and also controls which recipient objects will be found by the Graphical User Interface pickers in many cases. For instance, if you configure your scope to be a particular Organizational Unit, then you will only be able to specify this Organizational Unit or one of its children as the target of a new mailbox creation and you will only be able to select a user from this Organizational Unit or one of its children while enabling a mailbox. This can help to reduce the size of the result set you have to filter through while doing administrative tasks if your tasks are easily scoped to a particular part of the directory. In the Active Directory Users and Computers you see objects only under an Organizational Unit Scope, while Exchange Server 2007 Recipient Management allows you to define your scope to be an Organizational Unit, Domain, or even Forest wide increasing administrative flexibility.
$AdminSessionADSettings is a variable exposed by the Exchange Management Shell to allow you to control a number of aspects of the admin session:
-
ViewEntireForest is a boolean (set with $true or $false) that controls whether we're in Forest Scope ($true) or Domain Scope ($false);
-
DefaultScope is the path you're scoped to (i.e. domain.com, domain.com/users, domain.com/users/department). It's ignored if you're in Forest Scope;
-
PreferredGlobalCatalog is how you can hardcode a Global Catalog server to be used for anything that requires it (Forest Scope, and also doing resolution of any global objects you're referencing in the admin session);
-
ConfigurationDomainController is how you can hardcode a configuration Domain Controller;
-
PreferredDomainControllers is how you can configure one (or more) Domain Controllers to be used by the admin session any time as it is required (Domain Scope, or writes while in Forest Scope). This is a multivalued entry, so you can add more than one. If you need a Domain Controler for a Domain where there isn't Domain Controllers specified here, Active Directory Driver will go find one automatically and ignore this list;
The easiest way to manipulate this variable is just like you'd manipulate any other variable. Here's a syntax example:
[PS] C:\Documents and Settings\Administrator>$AdminSessionADSettings.ViewEntireForest = $true
[PS] C:\Documents and Settings\Administrator>$AdminSessionADSettings
ViewEntireForest: True
DefaultScope:
PreferredGlobalCatalog:
ConfigurationDomainController: server1.domain.com
PreferredDomainControllers: {}
Enable/Disable vs New/Remove
In Exchange Server 2007 each mailbox consists of an Active Directory user and the mailbox data that is stored in the Exchange mailbox database. All configuration data for a mailbox is stored in the Exchange attributes of the Active Directory user object. The mailbox database contains the mail data that is in the mailbox associated with the user account. Any of these operations can be done either on Exchange Management Console or Exchange Management Shell.
The Enable and Disable tasks are used against existing objects to remove attributes. When you enable, Enable-Mailbox, a mailbox you are adding Exchange attributes to an existent Active Directory object - mail or mailbox enable. When you disable, Disable-Mailbox, you remove those atributes leaving the mailbox orphan during the retention period after which it will be purged.
The New and Remove tasks need to have windows Account Operator permissions, otherwise the task will fail when trying to perform. Those tasks act directly on the Active Directory objects - mail or mailbox enable. When you create a mailbox, New-Mailbox, you will create a user on the Active Directory and respective mailbox if mailbox enabled or respective external SMTP address if mail enabled. When you remove a mailbox, Remove-Mailbox, you will be actually removing the Active Directory user and leave the mailbox orphan during the retention period, or you can actually through the Remove-Mailbox -Permanent cmdlet purge it with immediately efects. This last operation can only be done through Exchange Management Shell.
Last but not least we have the cmdlet Connect-Mailbox. Use it to connect a disconnected (disabled/removed) mailbox to an Active Directory object. Make sure that mailboxes have been used before at least once otherwise you will not see them here at all.
Email Address Policies
By default, Exchange contains an Email Address Policy for every mail or mailbox enabled user. This default policy specifies the recipient's alias as the local part of the email address and uses the default accepted domain. The local part of an e-mail address is the name that appears before the at sign (@). However you can change how your recipients' email addresses will display. For example, you can specify that your recipients' email addresses display as firstname.lastname@domain.com. Furthermore, if you want to specify additional email addresses for all recipients or just a subset, you can modify the default policy or create additional policies. In Exchange Server 2007, each time a recipient object is modified and saved, Exchange Server 2007 enforces the correct application of the email address criteria and settings. When an Email Address Policy is modified and saved, all associated recipients are updated with the change. In addition, if a recipient object is modified, that recipient's Email Address Policy membership is re-evaluated and enforced.
Exchange Server 2007 brings already some Pre-Canned filters to be used on the creation of Email Address Policies:
-
State or Province - Select this check box if you want the Email Address Policy to only include recipients from specific states or provinces. This information is contained on the Address and Phone tab in the recipient's properties;
-
Department - Select this check box if you want the Email Address Policy to include only recipients in specific departments. This information is contained on the Organization tab in the recipient's properties;
-
Company - Select this check box if you want the Email Address Policy to include only recipients in specific companies. This information is contained on the Organization tab in the recipient's properties.
-
Custom - Select this check box if you want the Email Address Policy to include only recipients in specific customized fields you have defined in your users' information. This information is contained on the Organization tab in the recipient's properties. This information will be visible on the Exchange Management Console, however to be edited you need to use Exchange Management Shell.
In addition Email Address Policies once created have to be applied to a set of users, but don’t have to be applied at that very moment. A schedule in the Exchange Management Console allows the Administrator to have the Email Address Policy to take effect after business hours. Exchange Server 2007 has eliminated the asynchronous behavior of the Exchange Server 2003 Recipient Update Service in favor of a more predictable and synchronous provisioning process. Use the Update-AddressList and Update-EmailAddressPolicy Exchange Management Shell cmdlets. To replace the full functionality of Recipient Update Service, you can schedule these Exchange Management Shell cmdlets by using the Task Scheduler in Windows Server 2003.
Mailbox Manager functionality has been separated from Email Address Policies as in Recipient Policies used to be all in one. It has been replaced by Messaging Records Management functionality.
![clip_image002[1]](http://blogs.technet.com/cfs-file.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-65-99-metablogapi/4431.clip_5F00_image0021.jpg "clip_image002[1]")
![clip_image004[1]](http://blogs.technet.com/cfs-file.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-65-99-metablogapi/0880.clip_5F00_image0041.jpg "clip_image004[1]")
![clip_image006[1]](http://blogs.technet.com/cfs-file.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-65-99-metablogapi/7217.clip_5F00_image0061.jpg "clip_image006[1]")
