Exchange Server 2007 introduces many new and really well defined recipient types. One of them is the one my customer asked me about. The process to create a Shared Mailbox will create a disable Active Directory user as there is no point to have it - that is not the purpose of this recipient. On the old and still actual days of Exchange Server 2003 or older, when we created a Shared Mailbox we basically created an Active Directory account with an associated mailbox and those credentials would be shared within who needed to use it. What is the issue here? Security! Was never a good idea to more than one individual login with same credentials. Control on it would be inexistent.
So in Exchange Server 2007 what we have is a mailbox with a disabled user and in a way we can give access to users or distributions lists we just add the proper permissions to the mailbox and it is done.
First of all we need to create our Shared Mailbox and to do that we need to use the Exchange Management Shell!
[PS] C:\>New-Mailbox -Name "mailbox" -Database "database" -UserPrincipalName mailbox@domain.com -Shared
At this stage we have our mailbox created and our active directory user disabled...
However now we need to give the right permissions...
Let's start by giving instructions to the shared mailbox that a few users should have Full Access on it, otherwise won't work. Advice here is do this to a Security Group more than to individual users by the same reasons referred above. Let's do it then to the users on the Sales Team!
[PS] C:\>Add-MailboxPermission "mailbox" -User "user" -Access Rights FullAccess
Almost done but a couple more things to do. At this stage the users on the Sales Team can access totally the mailbox however they still can't send e-mails from the shared mailbox. To do that we need to give them some permissions in Active Directory side...
[PS] C:\>Add-ADPermission "mailbox" -User "user" -ExtendedRights Send-As
At this stage the Sales Users are GOD within the Sales Team Shared Mailbox.
With Exchange Server 2007 Service Pack 1 we can actually setup the Full Access and Send As permissions. Basically we just right click on the Shared Mailbox and add the recipients to the desired permission or just select the account, and on the right hand side of the console you will see the same options.
And that's it!
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:
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:
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: TrueDefaultScope:PreferredGlobalCatalog:ConfigurationDomainController: server1.domain.comPreferredDomainControllers: {}
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:
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.
In this post I will try to bring you the way that all Recipient Lists, such as Address Lists or Distribution Lists behave in Exchange Server 2007 and what should we do with our old ones from Exchange Server 2003 and a few advices to some possible issues you may experience.
Distribution Lists Types
Most of the distribution lists types that you can get in Exchange Server 2007 are familiar if you have been dealing with Exchange Server 2003 as we can see below:
Automatic Group Conversion
By definition, universal distribution groups and universal security groups are groups of recipients that are created to expedite the mass sending of e-mail messages and other information. However, unlike universal distribution groups, universal security groups can also be used to assign permissions. In Exchange, only the Active Directory objects that have security principals can be used to grant permission to a public folder or to a mailbox folder. However, it is possible for an Outlook user to use a universal distribution group to grant permission to a public folder or to a mailbox folder. In this case, the universal distribution group is automatically converted to a universal security group by the Information Store service. This is the default behavior in Exchange Server 2007. This can potentially growth user security token.
It is possible to modify this behavior to prevent the automatic conversion of universal distribution groups to universal security groups. The msExchDisableUDGConversion attribute of your Exchange Organization object in Active Directory is used to control how the Information Store service responds to requests for conversion of universal distribution groups to universal security groups. The following are the acceptable values for the msExchDisableUDGConversion attribute that you can edit on ADSIEdit tool:
Exchange Server 2003 Coexistence
The Dynamic Distribution Groups created in Exchange Server 2003 won’t be displayed in the management console. This is caused by the fact that in Exchange 2003 they use an LDAP filter while in Exchange Server 2007 they use an OPATH filter. In order to find which dynamic distribution groups needs an upgrade you may run the Exchange Management Shell cmdlet Get-DynamicDistributionGroup | Format-List Name,*RecipientFilter*,ExchangeVersion and look for these properties:
In order to solve this issue you have to set the RecipientFilter property by using the cmdlet Set-DynamicDistributionGroup –recipientfilter {... } –forceupgrade $true (the parameter –forceupgrade will disable the compatibility notification). After the upgrade you will be able to manage the Dynamic Distribution Groups using only the Exchange Management Console. Distribution Lists with Global or Domain Local scope cannot be created in Exchange Server 2007. Preexisting mail-enabled non-universal groups will be kept but you will have limited management capabilitites. Using mail-enabled non-universal distribution groups may lead to unpredictable membership expansion. This is due to the way group membership is replicated across Global Catalogs in multi-domain environments. In order to have full compatibility you should change the scope of the group or create a new one with universal scope.
Distribution Lists Common Issues
A couple of common issues that you may experience are, either you are unable to send an email to a distribution list if you are sending that from an external email address to your organization, or simply you can't see the distribution list at all using Exchange Management Console.
On the first issue, generally that behaviour occurs if you enable the option "Require that all senders are authenticated“ in the Distribution List properties on Mail Flow Settings on Message Delivery Restrictions. This flag will refuse all mails from non-authenticated users. This issue can be easily tested using a telnet session or Outlook Express to send a message using non-authenticated SMTP session. It can be solved from the Exchange Management Console as described above or through Exchange Management Shell cmdlet Set-DistributionList –RequireSenderAuthenticationEnabled $true.
On the second one this issue occurs if the group scope is Global or Domain Local. It can be easily checked using Active Directory Users and Computers. It can be solved by changing the group scope to Universal or by creating a new group with Universal scope.
Address Lists Types
An address list is a collection of recipients and other Active Directory objects. Each address list can contain one or more types of objects (e.g. users, contacts, groups, public folders, conference rooms and other resources). You can use address lists to organize recipients and resources, making it easier to find the recipients and resources you want. Address lists are updated dynamically. Therefore, when new recipients are added to your organization, they are automatically added to the appropriate address lists. Address lists reside in Active Directory, therefore, mobile users who are disconnected from the network are also disconnected from these server-side address lists, however, you can create Offline Address Books for users who are disconnected from the network. These can be downloaded to a user's hard disk drive. Frequently, to conserve resources, Offline Address Books are subsets of the information in the actual address lists that reside on your servers.
When users want to use their client application to find recipient information, they can select from available address lists. Several address lists, such as the Global Address List, are created by default. Exchange Server 2007 contains the following default address lists, which are then automatically populated with new users, contacts, groups, or rooms as they are added to your organization: Global Address List: This address list contains all recipients in the organization. During setup, Exchange creates various default address lists. The most familiar address list is the Global Address List. By default, the it contains all recipients in an Exchange Organization. In other words, any mailbox-enabled or mail-enabled object in an Active Directory forest that has Exchange installed is listed here. For ease of use, it is organized by name, not by e-mail address. All Contacts: This address list contains all contacts in your organization. Contacts are those recipients who have an external -mail address. If you want a contact information to be available to all users in your organization, you must include the contact in the GAL. All Groups: This address list contains all mail-enabled groups in your organization. Mail-enabled groups are a group of recipients that are created to expedite the mass e-mailing of messages and other information. When an e-mail message is sent to a mail-enabled group all members of that list receive a copy of the message. All Rooms: This address list contains all resources that have been designated as a room in your organization. Rooms are resources in your organization that can be scheduled by sending a meeting request from a client application. The user account that is associated with a room is disabled. All Users: This address list contains all mail and mailbox-enabled users in your organization including equipment mailboxes. A mail-enabled user represents a user outside your Exchange Organization with an external e-mail address. All messages sent to mail-enabled users are routed to this external e-mail address. A mail-enabled user is similar to a contact, except that a mail-enabled user has Active Directory logon credentials and can access resources. A mailbox-enabled user as referred before has a mailbox on your Exchange Organization and obviously Active Directory credentials. Last but not least Equipment Mailboxes work as Rooms but are more related to video or audio equipment you may want to reserver, and so these ones have a disabled Active Directory user. Public Folders: This address list contains all mail-enabled public folders in your organization. Access permissions determine who can view and use the folders. Public folders are stored on computers running Exchange. Populating Address Lists Address lisys are no longer dependent on the Recipient Update Service. In earlier versions of Exchange, the Recipient Update Service (a component within System Attendant service) updated the address lists and e-mail addresses in Active Directory. In Exchange Server 2007, changes to e-mail addresses and address lists are applied directly to Active Directory. As a result, when changes are made to address lists, you can immediately see the changes in Active Directory Users and Computers without having to wait for Recipient Update Service to perform the update. In Exchange Server 2003 and Exchange Server 2000, the graphical user interface for filtering address lists was complex, containing nested lists that had hundreds of properties. In Exchange Server 2007, the most common filters are defined as precanned filters, which contain a simple and intuitive filter control. Besides the predefined ones there were some improvements on the customized ones too. For the few administrators that require advanced filtering requirements not met by precanned filters, you can create custom filters that can be defined by using the OPATH filter syntax in the Exchange Management Shell. OPATH is a querying language designed to query object data sources. Exchange Server 2007 allows you to filter the results of a command by using the recipient type. For example, the Get-User, Get-Recipient, Get-Mailbox, Get-MailUser, Get-Contact, Get-MailContact, Get-Group, Get-DistributionGroup, and Get-DynamicDistributionGroup Exchange Management Shell cmdlets have a -Filter parameter with which you can specify the users or groups to retrieve with the command. When combined with the Set-AddressList or New-AddressList cmdlets, you can specify a set of users or groups to retrieve by using a filter string. This type of filter does not modify any configuration or attributes of objects. It only modifies the set of objects that the command returns. As said before any change is applied directly and immediately, however if by any chance you want to do it off of labour hours Exchange Server 2007 has the ability to schedule the application of address lists at a later time. You can specify when changes to the address list should be applied. You can also specify the amount of time that the tasks should run. If you prefer to do it using Exchange Management Shell you can use the Update-AddressList cmdlet to schedule or simply apply it with immediate effects. Address Lists Common Issues A couple of common issues that you may experience are, either you are unable to edit an address list properties, or changes you have done on an address list don't show up when you see them. On the first issue if address lists have been created using Exchange Server 2003 they must be upgraded in order to be able to modify them using Exchange Management Console. This is due to the fact that Exchange Server 2007 uses OPATH filters based on the Exchange Management Shell instead of using LDAP filters as in Exchange Server 2003. In order to have a list of the address lists which should be upgraded you may use Get-AddressList | Format-List Name,*RecipientFilter*,ExchangeVersion or Get-GlobalAddressList | Format-List Name,*RecipientFilter*,ExchangeVersion Exchange Management Shell cmdlets. If one of the below conditions occurs you will have to upgrade the Address Lists: LDAPRecipientFilter: Populated but RecipientFilter is empty (Exchange Server 2003 doesn't populate RecipientFilter); RecipientFilterType: Legacy; ExchangeVersion: 0.0 (6.5.6500.0) At least three of the basic Address Lists can be corrected using precanned filters: Set-AddressList "All Users" -IncludedRecipients MailboxUsers Set-AddressList "All Groups" -IncludedRecipients MailGroups Set-AddressList "All Contacts" -IncludedRecipients MailContacts Others may need custom filters (Public Folders and Global Address List) Set-AddressList "Public Folders" -RecipientFilter { RecipientType -eq 'PublicFolder' } Set-GlobalAddressList "Default Global Address List" -RecipientFilter {(Alias -ne $null -and (ObjectClass -eq 'user' -or ObjectClass -eq 'contact' -or ObjectClass -eq 'msExchSystemMailbox' -or ObjectClass -eq 'msExchDynamicDistributionList' -or ObjectClass -eq 'group' -or ObjectClass -eq 'publicFolder'))} On the second issue since Exchange Server 2007 has no Recipient Update Service, the address lists must be manually updated if you experience the described issue, using Exchange Management Console or the Exchange Management Shell cmdlet Update-AddressList. If that still doesn't work and in order to troubleshoot issues related to the Recipient Update Service API you may enable diagnostic logging of the Recipient Update Service API using the cmdlets Get-EventLogLevel MSExchangeAL and Set-EventLogLevel.
When users want to use their client application to find recipient information, they can select from available address lists. Several address lists, such as the Global Address List, are created by default. Exchange Server 2007 contains the following default address lists, which are then automatically populated with new users, contacts, groups, or rooms as they are added to your organization:
Populating Address Lists
Address lisys are no longer dependent on the Recipient Update Service. In earlier versions of Exchange, the Recipient Update Service (a component within System Attendant service) updated the address lists and e-mail addresses in Active Directory. In Exchange Server 2007, changes to e-mail addresses and address lists are applied directly to Active Directory. As a result, when changes are made to address lists, you can immediately see the changes in Active Directory Users and Computers without having to wait for Recipient Update Service to perform the update. In Exchange Server 2003 and Exchange Server 2000, the graphical user interface for filtering address lists was complex, containing nested lists that had hundreds of properties. In Exchange Server 2007, the most common filters are defined as precanned filters, which contain a simple and intuitive filter control.
Besides the predefined ones there were some improvements on the customized ones too. For the few administrators that require advanced filtering requirements not met by precanned filters, you can create custom filters that can be defined by using the OPATH filter syntax in the Exchange Management Shell. OPATH is a querying language designed to query object data sources.
Exchange Server 2007 allows you to filter the results of a command by using the recipient type. For example, the Get-User, Get-Recipient, Get-Mailbox, Get-MailUser, Get-Contact, Get-MailContact, Get-Group, Get-DistributionGroup, and Get-DynamicDistributionGroup Exchange Management Shell cmdlets have a -Filter parameter with which you can specify the users or groups to retrieve with the command. When combined with the Set-AddressList or New-AddressList cmdlets, you can specify a set of users or groups to retrieve by using a filter string. This type of filter does not modify any configuration or attributes of objects. It only modifies the set of objects that the command returns.
As said before any change is applied directly and immediately, however if by any chance you want to do it off of labour hours Exchange Server 2007 has the ability to schedule the application of address lists at a later time. You can specify when changes to the address list should be applied. You can also specify the amount of time that the tasks should run. If you prefer to do it using Exchange Management Shell you can use the Update-AddressList cmdlet to schedule or simply apply it with immediate effects.
Address Lists Common Issues
A couple of common issues that you may experience are, either you are unable to edit an address list properties, or changes you have done on an address list don't show up when you see them.
On the first issue if address lists have been created using Exchange Server 2003 they must be upgraded in order to be able to modify them using Exchange Management Console. This is due to the fact that Exchange Server 2007 uses OPATH filters based on the Exchange Management Shell instead of using LDAP filters as in Exchange Server 2003. In order to have a list of the address lists which should be upgraded you may use Get-AddressList | Format-List Name,*RecipientFilter*,ExchangeVersion or Get-GlobalAddressList | Format-List Name,*RecipientFilter*,ExchangeVersion Exchange Management Shell cmdlets. If one of the below conditions occurs you will have to upgrade the Address Lists:
At least three of the basic Address Lists can be corrected using precanned filters:
Others may need custom filters (Public Folders and Global Address List)
On the second issue since Exchange Server 2007 has no Recipient Update Service, the address lists must be manually updated if you experience the described issue, using Exchange Management Console or the Exchange Management Shell cmdlet Update-AddressList. If that still doesn't work and in order to troubleshoot issues related to the Recipient Update Service API you may enable diagnostic logging of the Recipient Update Service API using the cmdlets Get-EventLogLevel MSExchangeAL and Set-EventLogLevel.
In continuation of my last post, Exchange Recipients, I brought this one to kind of complement a bit more and go deep on the troubleshoot side. Besides that will try to show differences or what we have new since Exchange Server 2003 to Exchange Server 2007.
Mailbox Management Tasks
We can split these ones between the functionalities that we brought from Exchange Server 2003 (even these ones having now Exchange Management Shell cmdlets) and the new ones that we got with Exchange Server 2007.
New Mailbox
With this one you can use the New Mailbox wizard in the Exchange Management Console or use the New-Mailbox Exchange Management Console cmdlet. To be able to create accounts you must be delegated Exchange Recipient Administrator role and Account Operator role for the applicable Active Directory containers. Administrators can create a new mailbox by creating a new user and mail or mailbox enabling it in one step, or by mail or mailbox enabling an existing user (in this last bit if using Exchange Management Console you use New Mailbox task, if using Exchange Management Shell you should use Enable-Mailbox cmdlet).
Move Mailbox
You can move mailboxes across mailbox databases, servers, domains, sites, and forests. You can also move mailboxes among different versions of Exchange Server 200x. To move mailboxes, you can use either the Move Mailbox wizard in the Exchange Management Console or use the Move-Mailbox Exchange Management Console command. To the specific scenario of moving mailboxes between forests you need to use the Exchange Management Shell.
Remove Mailbox
With this task the Exchange Management Shell cmdlet Remove-Mailbox will delete the user account (however if we use the Exchange Management Shell cmdlet Disable-Mailbox will remove the Exchange atributes between the user account and the mailbox - but at the end any of the cmdlets which can be performed through the Exchange Management Console too make the mailbox account orphan during the retention period, unless you use the Exchange Management cmdlet Remove-Mailbox -Permanent).
Change Mailbox
The properties of a mailbox can be modified from the Exchange Mailbox Console or using the Exchange Management Console cmdlet Set-Mailbox.
The new mailbox management tasks that we got with Exchange Server 2007 have a more staistical focus than the operational one found in the above tasks. These tasks can only be performed through Exchange Management Shell.
Get-LogonStatistics
With this task you can get the open item counts which tell us about the number of messaging operations, progress operations, table operations, transfer operations, total operations and successful Remote Procedure Calls operations. Besides that you can get the number of open attachments, folders and messages and names and identities associated with the database such as server, storage group, and full mailbox directory names. Last but not least you still can get other information such as latency, client version, client address and logon times.
Get-MailboxStatistics
This task can show you the size of the mailbox, number of messages it contains and last time it was accessed.
Get-MailboxFolderStatistics
Finally this one brings you information about the folders in a specified mailbox, including the number and size of items in the folder, the folder name and other information.
Mailbox Access Troubleshoot
We can troubleshoot a mailbox access issue in many ways, some of them known from the past, others not that much such as cmdlets from the Exchange Management Shell. Here are a few examples.
Test-MAPIConnectivity
This Exchange Management Shell cmdlet serves you basically to verify server functionality. It will log on to the mailbox that you specify (using the credentials of the account with which you are logged on to the local computer), or to the system mailbox if you do not specify the -Identity parameter, and retrieve a list of items in the Inbox. Logging on to the mailbox tests two critical protocols that are used when a client connects to a mailbox server: MAPI and LDAP. During authentication, the command indirectly verifies if the MAPI server, Exchange Store, and Directory Service Access are working. After a successful authentication, the command accesses the mailbox to verify that the database is working. If a successful connection to a mailbox is made, the command also determines the time that the logon attempt occurred. You have three levels of granularity here that it can be used through parameters: -Database: will take a database identity and tests the ability to log on to the system mailbox on the specified database; -Identity: will take a mailbox identity and tests the ability to log on to a specific mailbox; and finally -Server: which will take a server identity and tests the ability to log on to each system mailbox on the specified server.
Outlook Logging
Outlook logging can be enabled on the client side from the Outlook client or through the registry. By default the file is created in “\Documents and Settings\<username>\Local Settings\Temp”. The following article explains how to enable this logging: http://support.microsoft.com/kb/831053/en-us.
Network Trace
It is a good idea to reproduce the issue (try to logon from a local computer and see if the problem can be reproduced) while you monitor network traffic, on both the client and the server, at the same time. When you analyze the data, look for retransmits. A retransmit occurs when the client or the server has to send the same packet of information again, typically because the packets are being dropped between the client and the server. Therefore, when you analyze network captures, determine if the client request is actually getting to the server or if the server is responding but the response is lost before the client receives it.
Moving Mailbox
As said before, but it is always great to remember you can move mailboxes across mailbox databases, servers, domains, sites, and forests. You can also move mailboxes among different versions of Exchange Server 200x. To move mailboxes, you can use either the Move Mailbox wizard in the Exchange Management Console or use the Move-Mailbox Exchange Management Console command. To the specific scenario of moving mailboxes between forests you need to use the Exchange Management Shell.
One good thing that Exchange Server 2007 Move Mailbox task brings you is what is called the Pre Validation. Basically Move Mailbox task will perform a series of checks before actually trying to move the mailbox in a way it saves time by identifying errors right away, rather than waiting until they happen during the move process. Those tests will be user existence verification, source and target credential (done by connecting to the server), mailbox size limit against target database, system mailbox moves blocking, failure if source user does not have a mailbox and finaly verification if the target mailbox is mounted. Administrators can run the validation directly from the Exchange Management Shell cmdlet Move-Mailbox -ValidateOnly. In addition, validation is always executed before a “real” move, i.e. even when running moves using the Exchange Management Console Move Mailbox wizard, a Pre-Validation will be performed and any errors will be reported right away. Some other advanced options you can use with this Exchange Management Shell cmdlet are: -GlobalCatalog: Sets Global Catalog to be used during migration; -DomainController: Sets Domain Catalog to be used during migration; -MaxThreads: Number of mailboxes to be moved simultaneously (default is four); -ValidateOnly: Only runs validation code as so mailbox is not moved; -ReportFile: Used for changing the directory and/or file name for the XML report; -IgnoreRuleLimitErrors: Used for migrations from Exchange Server 2007 to Exchange Server 2003. This relates to the 32 Kb limit for rules in Exchange Server 2003, allowing Exchange Server 2007 mailboxes that exceed this limit to be moved back to Exchange Server 2003 successfully. If this option is used the mailbox will be moved without rules. Exchange Server 2007 Move Mailbox task improves on the existing Exchange Server 2003 logging functionality (event logs and XML report) and adds one new log feature, i.e. the troubleshooting log. All logs are enabled by default and are saved into this path: “<Exchange Install Root>\Logging\MigrationLogs\”.
Administrators can run the validation directly from the Exchange Management Shell cmdlet Move-Mailbox -ValidateOnly. In addition, validation is always executed before a “real” move, i.e. even when running moves using the Exchange Management Console Move Mailbox wizard, a Pre-Validation will be performed and any errors will be reported right away.
Some other advanced options you can use with this Exchange Management Shell cmdlet are:
Move Mailbox Troubleshoot
Email Address Enforcement If you move a mailbox from Exchange Server 2003 or Exchange Server 2000 to Exchange Server 2007, and the mailbox is part of an e-mail address policy, the e-mail addresses for that mailbox will be automatically updated based on the configuration of the e-mail address policy. If the mailbox had a primary Simple Mail Transfer Protocol (SMTP) address that differs from the e-mail address enforced by the e-mail address policy, that SMTP address will become a secondary SMTP address and the e-mail address generated by the e-mail address policy will become the primary SMTP address. This behavior is different from what used to happen before when mailboxes were moved to Exchange Server 2003 or Exchange Server 2000. In Exchange Server 2003 or Exchange Server 2000, the e-mail address policy is not applied to a mailbox when it is moved. To prevent accidentally changing the primary SMTP address of a mailbox in an Exchange Server 2007 environment, you must configure the mailbox so that is does not automatically update e-mail addresses based on e-mail address policy. To configure Exchange Server 2003 or Exchange Server 2000 mailboxes, in Active Directory Users and Computers, right-click the recipient, and then select Properties. On the E-mail Addresses tab, clear the Automatically update e-mail addresses based on e-mail address policy check box. Move-Mailbox -IgnoreRuleLimitErrors You can specify this parameter to avoid the Outlook 32 Kb rules limit. By default, the Move-Mailbox cmdlet will move rules, both in single forest and cross-forest moves. Using this Exchange Management Shell cmdle you will allow Exchange Server 2007 mailboxes that exceed this limit to be moved back to Exchange Server 2003 successfully. If this option is used the mailbox will be moved without rules. Damaged or Corrupted Messages If you are willing to lose the corrupted message, you can skip it when you rerun the Move Mailbox operation using the Exchange Management Console wizard or the Move-Mailbox cmdlet in Exchange Management Shell. In the Move Mailbox wizard, under Move options, you can decide to skip the corrupted message while with the Move-Mailbox cmdlet you can use the -BadItemLimit parameter. Other way of trying to troubleshoot this would be running the ISInteg to check for and fix the corrupted messages. A useful tip would be to you to verify if the antivirus software is not scanning the database where the mailbox you are trying to move at that moment is. Last but not least you can always use MFCMAPI to delete the corrupted message. ExMerge Replacement There are a few reasons we can point why is ExMerge not being shiped with Exchange Server 2007. Being separate code from the Exchange Server 2007 is one of them. One of the goals for Exchange Server 2007 is to reduce the number of separate tools and code bases supported for migration operations. ExMerge has always been completely separate from all shared Exchange migration code, as so this has caused several technical problems like the need to support an independent PST file provider and so on. These issues have caused delays in updates, limited functionality and extra support costs for customers and Microsoft as well. Besides that being an independent tool didn't help either. The fact that ExMerge is an independent tool has caused a lot of unintended consequences regarding the scenarios where it is used. Every time a tool is used for something it was not designed for, the risk of unintended consequences and bugs increase. Also, over use of the Exmerge tool works as an incentive to under use our other migration tools where they are better suited. This adds extra cost to the management of Exchange. Obviously if we didn't ship ExMerge with Exchange Server 2007 we still needed to provide some replacement to our customers in the areas that out tools from previous versions of Exchange would not cover what ExMerge could cover. Regarding that the export and import PST files options in the Exchange Management Shell are another way in which we are investing in PowerShell as a scripting platform for Exchange Server 2007. The good news with the replacements is that Administrators can bypass Outlook when attempting to restore and backup a mailbox directly from a PST file and it will support Unicode PST files. In practical terms those replacements, or in more appropriate words, those Exchange Management Shell cmdlets will be the following ones: Export-Mailbox Is a task developed by the migration team to allow Administrators to export content from active mailboxes to a folder inside other active mailboxes. The initial idea for this task was to be a complete replacement for ExMerge. The implementation of some of this functionalities was problematic and it required more time than initially planned. It deletes content from source mailbox after exporting it to target mailbox and also automatically exports dumpster items as regular messages in the target mailbox. Messages from the dumpster are converted to regular items in the folder or .pst file to which you export data. If you want to export from a PST file you need to run this cmdlet from a 32 bits box. Import-Mailbox To import data from a PST file to a mailbox, you need to run this cmdlet from a 32 bits box. You cannot import data by using the Import-Mailbox Exchange Management Shell cmdlet to a mailbox that is on a server running Exchange 2003 or Exchange 2000. To import data from a PST file to a mailbox on a server that is running Exchange 2003 or Exchange 2000, you must use the ExMerge tool. By default, the Import-Mailbox Exchange Management Shell cmdlet exports all empty folders, special folders, and subfolders to the target location. To specify folders to either include in, or exclude from the export, use the -IncludeFolders or -ExcludeFolders parameter. The Import-Mailbox cmdlet imports all associated folder messages if they exist in the PST file. Associated messages contain hidden data with information about rules, views, and forms. The Import-Mailbox cmdlet imports all message types, including messages, calendar items, contacts, distribution lists, journal entries, tasks, notes, and documents. When data is imported from a PST file, it is merged into the existing mailbox. If a message from the PST file already exists, it will not be imported as a duplicate message. Restore-Mailbox This Exchange Management Shell cmdlet is used to recover mailbox content from databases in the Recovery Storage Group. It ca only be used to copy data from a disconnected mailbox to an active one.
Email Address Enforcement
If you move a mailbox from Exchange Server 2003 or Exchange Server 2000 to Exchange Server 2007, and the mailbox is part of an e-mail address policy, the e-mail addresses for that mailbox will be automatically updated based on the configuration of the e-mail address policy. If the mailbox had a primary Simple Mail Transfer Protocol (SMTP) address that differs from the e-mail address enforced by the e-mail address policy, that SMTP address will become a secondary SMTP address and the e-mail address generated by the e-mail address policy will become the primary SMTP address. This behavior is different from what used to happen before when mailboxes were moved to Exchange Server 2003 or Exchange Server 2000. In Exchange Server 2003 or Exchange Server 2000, the e-mail address policy is not applied to a mailbox when it is moved. To prevent accidentally changing the primary SMTP address of a mailbox in an Exchange Server 2007 environment, you must configure the mailbox so that is does not automatically update e-mail addresses based on e-mail address policy. To configure Exchange Server 2003 or Exchange Server 2000 mailboxes, in Active Directory Users and Computers, right-click the recipient, and then select Properties. On the E-mail Addresses tab, clear the Automatically update e-mail addresses based on e-mail address policy check box.
Move-Mailbox -IgnoreRuleLimitErrors
You can specify this parameter to avoid the Outlook 32 Kb rules limit. By default, the Move-Mailbox cmdlet will move rules, both in single forest and cross-forest moves. Using this Exchange Management Shell cmdle you will allow Exchange Server 2007 mailboxes that exceed this limit to be moved back to Exchange Server 2003 successfully. If this option is used the mailbox will be moved without rules.
Damaged or Corrupted Messages
If you are willing to lose the corrupted message, you can skip it when you rerun the Move Mailbox operation using the Exchange Management Console wizard or the Move-Mailbox cmdlet in Exchange Management Shell. In the Move Mailbox wizard, under Move options, you can decide to skip the corrupted message while with the Move-Mailbox cmdlet you can use the -BadItemLimit parameter. Other way of trying to troubleshoot this would be running the ISInteg to check for and fix the corrupted messages. A useful tip would be to you to verify if the antivirus software is not scanning the database where the mailbox you are trying to move at that moment is. Last but not least you can always use MFCMAPI to delete the corrupted message.
ExMerge Replacement There are a few reasons we can point why is ExMerge not being shiped with Exchange Server 2007. Being separate code from the Exchange Server 2007 is one of them. One of the goals for Exchange Server 2007 is to reduce the number of separate tools and code bases supported for migration operations. ExMerge has always been completely separate from all shared Exchange migration code, as so this has caused several technical problems like the need to support an independent PST file provider and so on. These issues have caused delays in updates, limited functionality and extra support costs for customers and Microsoft as well. Besides that being an independent tool didn't help either. The fact that ExMerge is an independent tool has caused a lot of unintended consequences regarding the scenarios where it is used. Every time a tool is used for something it was not designed for, the risk of unintended consequences and bugs increase. Also, over use of the Exmerge tool works as an incentive to under use our other migration tools where they are better suited. This adds extra cost to the management of Exchange. Obviously if we didn't ship ExMerge with Exchange Server 2007 we still needed to provide some replacement to our customers in the areas that out tools from previous versions of Exchange would not cover what ExMerge could cover. Regarding that the export and import PST files options in the Exchange Management Shell are another way in which we are investing in PowerShell as a scripting platform for Exchange Server 2007. The good news with the replacements is that Administrators can bypass Outlook when attempting to restore and backup a mailbox directly from a PST file and it will support Unicode PST files. In practical terms those replacements, or in more appropriate words, those Exchange Management Shell cmdlets will be the following ones: Export-Mailbox Is a task developed by the migration team to allow Administrators to export content from active mailboxes to a folder inside other active mailboxes. The initial idea for this task was to be a complete replacement for ExMerge. The implementation of some of this functionalities was problematic and it required more time than initially planned. It deletes content from source mailbox after exporting it to target mailbox and also automatically exports dumpster items as regular messages in the target mailbox. Messages from the dumpster are converted to regular items in the folder or .pst file to which you export data. If you want to export from a PST file you need to run this cmdlet from a 32 bits box. Import-Mailbox To import data from a PST file to a mailbox, you need to run this cmdlet from a 32 bits box. You cannot import data by using the Import-Mailbox Exchange Management Shell cmdlet to a mailbox that is on a server running Exchange 2003 or Exchange 2000. To import data from a PST file to a mailbox on a server that is running Exchange 2003 or Exchange 2000, you must use the ExMerge tool. By default, the Import-Mailbox Exchange Management Shell cmdlet exports all empty folders, special folders, and subfolders to the target location. To specify folders to either include in, or exclude from the export, use the -IncludeFolders or -ExcludeFolders parameter. The Import-Mailbox cmdlet imports all associated folder messages if they exist in the PST file. Associated messages contain hidden data with information about rules, views, and forms. The Import-Mailbox cmdlet imports all message types, including messages, calendar items, contacts, distribution lists, journal entries, tasks, notes, and documents. When data is imported from a PST file, it is merged into the existing mailbox. If a message from the PST file already exists, it will not be imported as a duplicate message. Restore-Mailbox This Exchange Management Shell cmdlet is used to recover mailbox content from databases in the Recovery Storage Group. It ca only be used to copy data from a disconnected mailbox to an active one.
ExMerge Replacement
There are a few reasons we can point why is ExMerge not being shiped with Exchange Server 2007. Being separate code from the Exchange Server 2007 is one of them. One of the goals for Exchange Server 2007 is to reduce the number of separate tools and code bases supported for migration operations. ExMerge has always been completely separate from all shared Exchange migration code, as so this has caused several technical problems like the need to support an independent PST file provider and so on. These issues have caused delays in updates, limited functionality and extra support costs for customers and Microsoft as well. Besides that being an independent tool didn't help either. The fact that ExMerge is an independent tool has caused a lot of unintended consequences regarding the scenarios where it is used. Every time a tool is used for something it was not designed for, the risk of unintended consequences and bugs increase. Also, over use of the Exmerge tool works as an incentive to under use our other migration tools where they are better suited. This adds extra cost to the management of Exchange.
Obviously if we didn't ship ExMerge with Exchange Server 2007 we still needed to provide some replacement to our customers in the areas that out tools from previous versions of Exchange would not cover what ExMerge could cover. Regarding that the export and import PST files options in the Exchange Management Shell are another way in which we are investing in PowerShell as a scripting platform for Exchange Server 2007. The good news with the replacements is that Administrators can bypass Outlook when attempting to restore and backup a mailbox directly from a PST file and it will support Unicode PST files.
In practical terms those replacements, or in more appropriate words, those Exchange Management Shell cmdlets will be the following ones:
Export-Mailbox
Is a task developed by the migration team to allow Administrators to export content from active mailboxes to a folder inside other active mailboxes. The initial idea for this task was to be a complete replacement for ExMerge. The implementation of some of this functionalities was problematic and it required more time than initially planned. It deletes content from source mailbox after exporting it to target mailbox and also automatically exports dumpster items as regular messages in the target mailbox. Messages from the dumpster are converted to regular items in the folder or .pst file to which you export data. If you want to export from a PST file you need to run this cmdlet from a 32 bits box.
Import-Mailbox
To import data from a PST file to a mailbox, you need to run this cmdlet from a 32 bits box. You cannot import data by using the Import-Mailbox Exchange Management Shell cmdlet to a mailbox that is on a server running Exchange 2003 or Exchange 2000. To import data from a PST file to a mailbox on a server that is running Exchange 2003 or Exchange 2000, you must use the ExMerge tool. By default, the Import-Mailbox Exchange Management Shell cmdlet exports all empty folders, special folders, and subfolders to the target location. To specify folders to either include in, or exclude from the export, use the -IncludeFolders or -ExcludeFolders parameter. The Import-Mailbox cmdlet imports all associated folder messages if they exist in the PST file. Associated messages contain hidden data with information about rules, views, and forms. The Import-Mailbox cmdlet imports all message types, including messages, calendar items, contacts, distribution lists, journal entries, tasks, notes, and documents. When data is imported from a PST file, it is merged into the existing mailbox. If a message from the PST file already exists, it will not be imported as a duplicate message.
Restore-Mailbox
This Exchange Management Shell cmdlet is used to recover mailbox content from databases in the Recovery Storage Group. It ca only be used to copy data from a disconnected mailbox to an active one.