Exchange

Managing Exchange recipients

Exchange Server has two options with which an administrator can successfully manage the environment. These options are accessed through the EAC, which replaces the Exchange Management Console (EMC), the Exchange Control Panel (ECP) in Exchange 2010, and the Exchange Management Shell (EMS). The EAC is a web browser-based that you use to manage Exchange and can be used for administrators and end-users to perform various management tasks. Administrative tasks that can be completed in EAC including managing mailboxes, contacts, groups and User and Administrator roles. However, if you want to perform many tasks or have greater control over the Exchange environment, you need to become familiar with the EMS, especially when performing bulk administration.

EMS has been designed so that you can automate repetitive administrative tasks, and it’s a best practice to become familiar with how EMS can be used in your Exchange organization. EMS is used to manage any Exchange objects, including those in a cloud tenant domain that is linked to an on-premises organization.

What are Exchange recipients? In any messaging system, some Active Directory objects are mailbox-enabled or mail-enabled. These objects are referred to as Exchange recipients. Exchange recipients include the following:

  • User mailboxes: User mailboxes are mailboxes assigned to an Active Directory object that can represent a person who uses the network. Each user in Active Directory can be mailbox-enabled, mail-enabled, or neither. Each user’s mailbox is a private area that allows an individual user to send, receive, and store messages.
  • Room mailboxes: A room mailbox is an Active Directory object that can be used to manage meeting rooms such as conference rooms, training rooms, or any location where you want scheduling to occur so as to prevent double booking. Room lists can be managed only by using EMS.
  • Equipment mailboxes: These types of mailboxes are also Active Directory objects. Equipment accounts have the user account disabled and are used for items such as company cars for travel, projectors, or loaner laptops.
  • Linked mailboxes: This type of mailbox is accessed by an external account. This comes in handy if an organization has many resources and needs to consolidate them into a resource forest for a simplified management solution. EAC can be used to manage such cross-forest or multi forest deployments.
  • Contacts: These are Active Directory objects that contain information about a person or an organization outside of your Exchange organization. These objects can appear in distribution groups and the Global Address List (GAL).
  • Mail-enabled distribution and security groups: A mail-enabled Active Directory security group object can be used to grant access permissions to Active Directory resources as well as to distribute messages to multiple recipients. You can use a mail-enabled Active Directory distribution group object to distribute messages to a group of recipients.
  • Dynamic distribution groups: A dynamic distribution group uses a recipient filter and conditions to determine its membership at the time messages are sent.
  • Microsoft Exchange recipients: This replaces the System Administrator sender used for system-generated messages in earlier versions of Exchange.
  • Shared mailboxes: A mailbox that is not primarily associated with a single user. In most cases, a shared mailbox allows access for multiple users.
  • Site mailboxes: This type of mailbox consists of an Exchange mailbox to store email messages and document libraries within a SharePoint 2013 site. Users can access repositories using the same client interface, such as Outlook 2013, and by using a browser to access the SharePoint team site.
  • Office 365 mailboxes: A mailbox that exists in hybrid deployments. This mailbox consists of a mail user in an Active Directory on-premises organization and an associated mailbox in Exchange Online.

Managing mail-enabled users and mailboxes

Mailboxes and mail-enabled users are Active Directory objects that contain information about users and also provide credentials to log on to the organization and access resources. Being able to use the credentials to access resources is one of the major differences between a mail-enabled user and a mail-enabled contact. Many tasks are performed when managing user mailboxes, including the following:

  • Creating mailboxes
  • Adding an email address for a user mailbox
  • Creating a linked mailbox
  • Connecting a mailbox
  • Configuring anti-spam on mailbox servers
  • Deleting mailboxes
  • Disabling mailboxes
  • Configuring mail forwarding
  • Configuring message size limits
  • Configuring storage quotas
  • Updating recipient’s information
  • Configuring Exchange ActiveSync
  • Configuring Single Item Recovery

Many of these tasks are straightforward and often control what best practices should be—such as for creating new mailboxes. Nevertheless, you should pay close attention when managing and designing an Exchange organization. The next several sections touch on a few of the major tasks that are performed on a regular basis.

Moderated recipients

Moderated recipients basically include the functionality to approve or disapprove messages sent to a specific recipient. Depending on your organization’s requirements, you may to control messages that are sent to executive mailboxes or partner contacts. In this case you can use moderated recipients so all messages sent to that recipient are subject to approval by the designated moderators. You can use the EAC and EMS to configure moderated recipients. For example, to enable recipient moderation for Carol Troup, which is moderated by Evan Dodds, use the following cmdlet:

Set-Mailbox -Identity “Carol Troup” -ModerationEnabled $true -ModeratedBy “Evan Dodds” -SendModerationNotification Always

The parameter SendModerationNotification means that all senders will receive a status notification when they send a message to the moderated recipient.

Creating mailboxes

The New-Mailbox cmdlet in the Exchange Management Shell prompts you through the entire process of creating a new mailbox or mail user. This cmdlet creates a user account inActive Directory and mailbox-enables it. However, thought must be given to naming conventions and also to deciding which database the mailbox will reside in.

When determining user and display name, a best practice is to use a convention that works well if you have several users that have the same first name or last name. A mailbox alias should follow the same standards because these can be used with Outlook and OWA to find user information.

When you create a mailbox with the New-Mailbox cmdlet, the default wizard prompts you for three parameters which are required:

  • Name: DisplayName for the new mailbox.
  • Password: Password for the new mailbox.
  • UserPrincipalName: UPN for the new mailbox, commonly used is the e-mail address as UPN.

All other attributes are set automatically, such as the alias based on the email address policy, or the default assignment policy and the default sharing policy are assigned.

One issue when just running New-Mailbox is that the new AD account is created in the default Users OU, which is probably not where you want these accounts to be created. For this reason you should consider defining additional parameters when using the New-Mailbox cmdlet.

Choosing an appropriate database for the mailbox to reside on also requires some thought. When creating multiple mailboxes, consider placing them into multiple databases as this provides the following benefits:

  • Decreases the time to restore a database from backup because each database is smaller
  • Reduces the impact on the Exchange environment if a database goes offline, because each database has fewer mailboxes
  • Allows you to separate your users based on conditions such as mailbox size, organization divisions, or titles
  • Allows for simpler mailbox limit and deleted-item retention management when all users in the same database share the same configuration

When you do not define a mailbox database, Exchange 2013 creates the mailbox by selecting an appropriate database for creation automatically. This feature is calledAutomatic Mailbox Provisioning and is available since Exchange 2010. All newly created mailboxes are load-balanced across all available mailbox databases and a mailbox cannot be created if a suitable mailbox database is not available There are four parameters for every mailbox database:

  • IsExcludedFromProvisioning
  • IsExcludedFromInitialProvisioning
  • IsSuspendedFromProvisioning
  • IsExcludedFromProvisioningBySpaceMonitoring

Today the size of the mailboxes is 5 GB to 25 GB, in some cases even greater. It is difficult to convince an organization’s vice president that she must delete her email messages and attachments to remain under a mailbox limit, and she would be annoyed to receive an email alert every day telling her to do so. Creating a separate database for executives allows for a different policy set to apply. Each organization is different, and some will need only a few databases. Other organizations will require more. Carefully plan how these mailbox databases will be divided across the Database Availability Group (DAG) to meet your storage, backup, or performance requirements for your Exchange organization.

Managing mailbox permissions

In some instances, such as when an executive assistant needs permissions to access the executive’s calendar items, you might need to grant permissions to a mailbox. The administrative assistant can do this by assigning a delegate within Outlook using the Delegates feature. Delegate access also gives the delegate the ability to send email messages on behalf of the mailbox holder.

Administrators can set permissions for a mailbox by using the Add-MailboxFolderPermission cmdlet. This is helpful for users who might not have access to Outlook or who might rely on assistance from the Exchange administrator. Figure 1 shows the configuration for a delegate to access specified folders in Outlook.

An administrator also can modify permissions by granting Send On Behalf, Send As, or full mailbox permissions to an entire mailbox. Table 1 provides a description what the permission purpose is. This is not “delegate access”, but provides a similar functionality at the end.

 

Send On Behalf:

Allows a delegate to send email on behalf of a mailbox. Send on Behalf displays the original sender the message was sent from.

 

Send As:

Allows a delegate to send email appearing that it was sent from this mailbox. The message will appear to have been sent by the mailbox owner.

 

Full Access:

Allows a delegate to open this mailbox and behave as the mailbox owner. Delegates cannot send email from this mailbox unless they also have Send As or Send On Behalf permission.

 

Note: You need Full Access and Send As access rights to add a mailbox in Outlook as an additional account. If you have fewer rights than this, you can add it as an additional mailbox only within an existing account.

 

These permissions allow users other than the mailbox owner to send or receive messages as if they were sent by the mailbox owner. Setting these permissions might be necessary to support a third-party application that sends email messages to and receives messages from users. If the mailbox is either hidden or not as determined by the HiddenFromAddressListsEnabled switch, the user will not be able to select the hidden mailbox to send from within the GAL. You can also assign full access permissions, which allow a user to open and modify mailbox contents as well as send email on behalf of the mailbox. Full access rights are applied to the mailbox and not to a database; therefore, you use the Add-MailboxPermission cmdlet or the EAC Manage Full Access Permission delegation tap. To manage the full access permission with the EMS, you can run the Add-MailboxPermission cmdlet. For example, to give Joe Full Access permissions to Ed’s mailbox, you run the following:

 

Add-MailboxPermission –Identity “Ed” -User “Joe” -Accessrights “FullAccess”

 

Adding Full Access permissions to a mailbox will force Autodiscover to auto-map the mailbox in Outlook. In this case, the mailbox from Ed will be shown in the Outlook profile from Joe. If you don´t want to auto-map the mailbox from Ed in Joe’s Outlook profile, use the AutoMapping parameter:

 

 Add-MailboxPermission –Identity “Ed” -User “Joe” -Accessrights “FullAccess” -AutoMapping $false

 

Keep in mind that it can take up to 120 minutes for permission changes to be loaded into the Mailbox Cache Idle Limit that Exchange uses to control mailbox permissions by default. You can improve this by restarting the Microsoft Exchange Information Store, but then you take all active databases on the appropriate Exchange server offline.

 

Note: You can´t manage Send As permissions via the Add-MailboxPermissioncmdlet. Instead you have to use the Add-ADPermission cmdlet to provide broader permissions.

 

To give the executive assistant rights to send messages as the executive, you run the following:

 

Add-ADPermission –Identity “Secretary” –User “boss” ExtendedRights “Send As”

 

Be sure to keep in mind that the EAC does not provide an option to manage Receive As rights or to assign permissions to an entire database. In these cases, you need to use the EMS. The Receive As permission allows a user to read all email items in the mailboxes that the permission is assigned to.

 

Deleting mailboxes

At some point, a user will leave the company and his mailbox will be disconnected or deleted. Plan ahead of time for how you will handle disconnected mailboxes so that they are neither deleted too soon nor remain too long. Getting rid of these mailboxes too soon can lead to the accidental destruction of needed information; keeping mailboxes too long can eat up disk space unnecessarily.

 

Deleting or removing a mailbox differs from disabling a mailbox in that deleting it disconnects the mailbox from its associated user account and removes the user from Active Directory. Exchange has a default retention period of 30 days for deleted mailboxes, which allows the user to be reconnected to the mailbox during this period. This is useful if the user decides not to leave or the company decides to retain him. If you determine that the mailbox is no longer needed but you want to retain the user’s Active Directory account, the mailbox should be disabled. Disabling a mailbox might be necessary if an employee goes to a different position in the company where company email is not required but the employee still needs to log on to the network each day to fill out reports or perform other organization-related tasks. To use the EMS to disable mail for a mail-enabled user, run the following cmdlet:

 

Disable-MailUser Alex@contoso.com

 

It is recommended that you leave in place the default 30-day retention period. A mailbox that is deleted is only marked for deletion during the retention period; it is not actually deleted during this period. This is similar to the Windows Recycle Bin, in which the items are not actually deleted until the Recycle Bin is emptied. A deleted Exchange mailbox is removed by the Managed Folder Assistant (MFA) the next time that the mailbox is processed after the retention period expires. If you want to permanently remove the mailbox immediately, you can do so using the EMS by running the following cmdlet:

 

Remove-Mailbox Kelly -Permanent $true

 

Note: During the retention period, the deleted mailbox is stored in the same database where the active mailbox was located. This is important to know, because you need to remember where the mailbox is located; otherwise, you cannot “see” it.

 

Disconnected mailbox management

After deleting a mailbox, you might determine that the mailbox or data within it is still needed. During the deleted-mailbox retention period, the mailbox can be reconnected to an Active Directory user account that does not already have a mailbox associated with it. Both the EMS and the EMA can be used to reconnect a disconnected mailbox. Under the Recipient Configuration node in the EAC, choose Connect A Mailbox to reconnect the mailbox.

 

You can also use the EMS to reconnect a disconnected mailbox. To retrieve a list of disconnected mailboxes on Denver-EX01,for example, run the following cmdlet:

 

Get-MailboxStatistics -Server Denver-EX01 | where { $_.DisconnectDate -ne $null } | select DisplayName,DisconnectDate

 

You can then reconnect the mailbox using the mailbox GUID by running the following:

 

Connect-Mailbox -Identity DeletedMailboxGuid -Database MailboxDatabase1 -User NewUserName

 

If the mailbox retention period has passed or you used Remove-Mailbox with thePermanent switch, you will not be able to reconnect the mailbox. In this case, you might have to restore the mailbox from a backup before you can access the deleted mailbox data.

 

Note: You can use the Remove-StoreMailbox cmdlet for mailboxes in a SoftDeleted or Disabled state. Important: you purge the mailbox and won’t be able to recover it anymore.

 

Managing contacts

Mail contacts are mail-enabled Active Directory contacts that contain information about recipients who exist outside your Exchange Server organization. Mail contacts can be added as members to distribution groups. Each contact has an internal alias and an external email address. All email messages to a contact are automatically forwarded to the external email address.

 

If multiple people within your organization regularly send email to an external person, you can create a mail contact with the person’s email address. This way, the contact will show up in the GAL and people to send the person email without first having to look up contact information. Mail contacts are often used when contract employees frequently communicate with full-time employees but the contract employee has a separate email system. The contact will allow the company’s users to send email to the contract employee using the GAL, and the contractor will continue to receive email messages in his primary mailbox. Also users can have the contacts locally to their Outlook folder and they can be added to distribution lists.

 

Mail users are similar to mail contacts because both have external email addresses and can contain information about people outside your Exchange Server organization. You can also display them in the GAL and other address lists. However, unlike a mail contact, mail users have Active Directory logon credentials and can be assigned access to resources. If a contract employee or other external person requires access to network resources and will continue to use her primary email system, you should create a mail user instead of a mail contact.

 

Another situation in which mail users and mail contacts can be valuable is during migrations or long-term coexistence between Exchange organizations or between mail systems. By using mail users and mail contacts, you can provide a consolidated GAL by creating contacts in both Exchange organizations that forward email to users in the other organization. For example, Litware, Inc., acquired Proseware, Inc., a smaller niche publishing company. Both companies will be working closely together, but there are no plans to establish network connectivity between the companies and migrate all users and mailboxes into the same Active Directory forest until the end of the next fiscal year. In the interim, the companies createdmail users for employees who will require access to the other company’s information through a client VPN connection. They created mail contacts for all other users, which allows them to use the GAL to look up contact information as well as send email to people in the other company.

 

Creating a new mail contact is straightforward using both the EAC and the EMS. One example of how to create a contact using the EMS is by running the following cmdlet:

 

New-MailContact -Name “Kamil Amireh” -ExternalEmailAddress Kamil@proseware.com

 

To mail-enable an existing contact using the EMS, you could use a cmdlet like this:

 

Enable-MailContact -Identity “Terry Adams” -ExternalEmailAddress Terry@contoso.com

 

After the contact is no longer necessary, you need to remove that mail contact from Active Directory. This can be done through the EMS by running the cmdlet:

 

Remove-MailContact -Identity “Terry Adams

 

Managing groups

Mail-enabled groups are used to send mail to multiple recipients and to assign permissions to multiple users for Exchange objects. These Exchange objects include mailboxes and public folders. In Exchange 2013, mail-enabled groups belong to one of the following two group types:

  • Security groups: Security groups are groups that has a Security ID (SID), thus can be used to assign permissions to the group members. Also you can add security groups for example to public folders to gain permissions to the whole group instead of single mailbox users.
  • Distribution groups: Distribution groups do not have a SID, thus can only be used to distribute emails to all of the group members.

 

Both group types can have the following email group related properties set:

  • Public: allows end users to manage the distribution groups that they own through the EAC. The end users can add or remove group members, moderate the group, or even request access to other public groups.
  • Moderated: allows the distribution group manager to moderate messages sent to the group. This includes approving and rejecting all messages sent to the group or from specific users. Moderated groups can be used to restrict the conversation that occur between group members. These restrictions should be used for large groups or groups that deal with sensitive information that needs to be controlled.

 

When creating distribution groups, you need to consider what naming convention to use. Implementing a well-thought-out naming convention enables users to more easily identify distribution groups with their email client. Some organizations like to prepend text or information about who owns the distribution group to the name of the distribution group. For example, the Contoso IT department decided that all distribution groups should be prepended with the ^ character. This helps arrange all distribution lists so that they are at the top of the GAL, allowing users to quickly find the groups. Fabrikam chose to prepend all groups with the name of the department—for example, Sales Engineers and Marketing Events.

 

Exchange provides the ability to require groups to follow a specified naming convention. The naming convention can require that a specific suffix or prefix be added to the group name. The required text could be a specific text string, such as the ^ character that Contoso uses. This required text could also include information found in the following attributes of the group:

  • Department
  • Company
  • Office
  • City
  • State or Province
  • Country or Region
  • Country Code
  • Title
  • CustomAttribute1 through CustomAttribute15

 

The policy can also include a combination of these rules. This policy can be set using the Set-OrganizationConfig cmdlet or by using the EAC, as shown in Figure 2. This feature can also block specific words from being used in group names as well as set the default OU that all distribution groups should be created in.

 

 

Note: Exchange 2013 does not automatically convert distribution groups to security groups like in previous versions, for example if you want to set permissions for a group to public folders. You have do this manually via EMS with the following cmdlet:

 

Set-ADGroup MyDistributionGroup -GroupCategory Security

 

Moderated groups

Moderated groups basically include the functionality to approve or disapprove messages sent to the group. A moderator of the group is determined and then given rights to approve or deny a message within OWA or Outlook. This feature helps to detain or remove any messages that might be inappropriate for the group. While a user trying to send an email to a moderated group, MailTips come into play and warns the user that the group is moderated. The message flow for moderated recipients is as follows:

  1. A user sends a message to a moderated group.
  2. The categorizer in the Transport service on a Mailbox server initiates the approval process and reroutes it to the appropriate arbitration mailbox.
  3. The Mailbox Transport service delivers the message to the arbitration mailbox and sends an approval request to the moderator.
  4. The moderator can now accept or reject the message.
  5. The Mailbox Transport service marks the moderator’s decision on the original message stored in the arbitration mailbox.
  6. The Information Assistant in the Mailbox Transport service reads the approval status on the message stored in the arbitration mailbox and processes the message depending on the moderator’s decision:
    1. Approved: the Information Assistant resubmits the message to the Transport service and the message is delivered to the recipient.
    2. Rejected: the Information Assistant deletes the message from the arbitration mailbox and notifies the sender that the message was rejected.

You can see the message moderation properties of a moderated group in Figure 3. These properties provide you with the ability to assign multiple administrators, and exempt users from moderation. If the moderator doesn`t respond to the message within five days, the Information Assistant will delete the message from the arbitration mailbox.

 

 

Public groups

Public groups allow users to join and leave groups as needed without having to call the help desk. You can configure a group to allow open membership from within the EAC and EMS. A normal Exchange user cannot perform this as he or she does not have access to Active Directory because they do not have permissions to any of the Exchange-specific settings. You should always use the Exchange management tools to manage public groups.

 

A public group by definition is a distribution group configured to allow users to join the group by using the EAC. To set a mail-enabled group to be a public group using the EMS, you can run the following cmdlet:

 

Set-DistributionGroup GroupName –MemberJoinRestriction Open –MemberDepartRestriction Open

 

You can configure the public group to require owner approval to join the group. If the group is set to be Open, users can join this distribution group without the approval of the distribution group owners. If the group is configured as Closed, only distribution group owners can add members to the group and any requests to join the distribution group will be rejected automatically. If the groups are set for owner approval, users can request membership in this distribution group and the distribution group owner must approve or reject the request. Table 2 details the various settings you can choose to apply for member join and member restrictions for departing from a group.

 

Open:

All mailboxes can join/leave the group.

Closed:

No mailboxes can join/leave the group.

ApprovalRequired:

Mailboxes need an approval from the group moderator to join/leave the group.

 

A public group can also be configured to require that a member obtain approval to be able to leave the group. If the MemberDepartRestriction property of the group is set to Open, users can leave the distribution group without the approval of the distribution group owners. If the group is set to Closed, only distribution group owners can remove members from this distribution group and any requests to leave this distribution group will be rejected automatically.

Mail-enabled users can view the list of the groups they are currently members of, as well as look for other groups to join within EAC, as shown in Figure 4. The Public Groups management section in the EAC is also where a user who is the administrator for a group can modify membership, hide the group from the GAL, modify the MailTip, and make other changes.

 

 

Dynamic groups

One of the first decisions you need to make when it comes to distribution groups is deciding whether they will be static or dynamic distribution groups. Static groups are just that, static; you must manually remove or add members. Dynamic groups can be automatically maintained based on user attributes of Active Directory. If you have a high level of confidence in Active Directory, it is best practice to use dynamic distribution groups because of the reduced administrative effort required to maintain the group membership over time. If you want absolute certainty about group membership (as in the case of the groups used for secure distribution of information), then static groups are much better. Using static groups can lead to distribution groups with no defined purpose and can result in members being in a group that they no longer qualify for or users being left out of essential distribution groups.

 

Dynamic distribution groups were introduced in Exchange 2003 and provide an easy way to automatically create groups without manually adding users. To create a dynamic distribution group for a list of all users in the Sales OU, run the following command:

 

New-DynamicDistributionGroup -Name “SalesGroup” -IncludedRecipients MailboxUsers -OrganizationalUnit Sales

 

Dynamic groups have also drawbacks. Membership in a dynamic distribution group can be controlled by the user if you base the criteria on a user attribute that the user can modify using the EAC, such as city or state. A user might be able gain membership to a group by changing a user attribute. The filter that controls a dynamic group should be based on user attributes that are secured if sensitive information is being sent to that distribution group. Auditing these groups on a regular basis is recommended to ensure the integrity of the Exchange organization distribution groups. You need to determine ahead of time whether you need a dynamic group or a static group—you can’t convert a static group to a dynamic group or vice versa. You can, however, re-create the group and manually configure it as needed.

 

Moving mailboxes

It is common to move mailboxes on a regular basis. Some of the reasons for moving mailboxes are:

  • Migration: When you migrate from an existing Exchange Server 2007 or Exchange Server 2010 organization to Exchange Server 2013, you need to move mailboxes from the existing Exchange servers to an Exchange Server 2013 Mailbox server.
  • Physical location changes You can move mailboxes to a server that is in a different Active Directory site. For example, if a user moves to a different physical location, you can move that user’s mailbox to a server that is in a site closer to the new location.
  • Hybrid deployments: A company might want to use a Hybrid deployment and move mailboxes to a cloud provider and back again (or not).
  • Load balancing Because users change positions or seasonal workers are hired for a short period of time, leaving mailbox databases with uneven numbers of active mailboxes. You can move mailboxes to even out the number of mailboxes in each database.
  • Outsourcing email administration: A company might want to outsource the administration of email and retain the administration of Windows user accounts. To do this, you can move mailboxes from a single forest into a resource forest scenario, in which the Microsoft Exchange mailboxes reside in one forest and their associated Windows user accounts reside in a separate forest.
  • Policy adjustments: In cases where the mailbox databases are used to set the deleted item retention and mailbox limits, you can move mailboxes between databases to move a mailbox to a database with different settings.
  • Reducing database size: In cases where data has been removed from a database and a lot of white space remains, rather than performing an offline defragmentation on the database, you can move the contained mailboxes online to a new database and delete the original database.
  • Troubleshooting an issue: If you need to investigate an issue with a mailbox, you can move that mailbox to a different server or different mailbox database. In some cases, moving a mailbox that is having issues will help to determine whether the problem is with the server, mailbox, or mailbox database.

 

There are two ways to move a mailbox: local and remote. A local move is where a mailbox is moved from one database to another database within the same Exchange organization. At times, you might need to move a mailbox to investigate an issue with that mailbox. If you encounter corrupted mailboxes, you can move those mailboxes to another server, because the corrupted messages will not be moved. In addition, you might want to perform a local mailbox move for load-balancing and physical server location changes. A local mailbox move is asynchronous in Exchange 2013, meaning that users are still able to access their mailboxes while they are being moved.

A remote move of a mailbox might be necessary if you are migrating between Exchange organizations, such as Exchange Online or an Exchange organization run by another company or another forest within the same organization.  Figure 5 shows the Move Mailbox Wizard in the EAC.

 

 

Note: You can use a .csv file in the EAC to move multiple mailboxes. For example, a disadvantage of the EAC is that you cannot choose multiple mailbox databases for your mailbox moves.

 

A remote mailbox move in Exchange 2013 requires you to log out of Outlook to finish. Local mailbox moves in Exchange 2013 features the following capabilities:

  • Mailboxes are kept online during the moves. The larger mailboxes become, the longer it takes to move them around.
  • The mailbox’s Recoverable Items moves with the mailbox when you move it between Exchange Server 2010 and Exchange Server 2013 Mailbox servers, and when moved between Exchange 2013 Mailbox servers.
  • As soon as the mailbox begins to move, content indexing starts to scan the mailbox so that fast searching is available upon the move’s completion.
  • Each MRS instance, each mailbox database, or each mailbox server can be throttled automatically based on current system load and throughput.
  • Mailbox moves work over the Internet, and you can manage them from EAC or EMS. They only work over the Internet if the necessary configuration is in place to allow moves to occur to Office 365, for instance, or another hosted provider, or a different organization.
  • A mailbox’s move history is preserved. You can modifyMaxMoveHistoryLength on every Client Access server in theMSExchangeMailboxReplication.exe.config file. The move history is stored in the hidden mailbox folder of every user, and you can check this with the following cmdlet in the EMS:

 

Get-MailboxStatistics –Identity “John Smith” –IncludeMoveHistory | Format-List MoveHistory

 

In versions of Exchange before Exchange 2013, you had to use the New-MoveRequest cmdlet to start a mailbox move from one mailbox database to the other. This had several disadvantages because if you wanted to move multiple mailboxes at once, you had to import a .csv file or pipe the results along to theNew-MoveRequest cmdlet. This cmdlet is also available in Exchange 2013 and you should only use it when referring to move a single mailbox at a time because there is a new feature for mailbox moves in Exchange 2013 called New-MigrationBatchcmdlet. You can use this new feature from the EAC, which was shown in figure 5, and the EMS.

 

With the New-MigrationBatch cmdlet, you can move mailboxes within an Exchange on-premises organization, move mailboxes from on-premises to Exchange Online, or vice versa. Additionally, you can migrate mailbox data from Exchange on-premises on an IMAP server to Exchange Online mailboxes. There are several benefits of using the New-MigrationBatch cmdlet:

  • It has the ability to move multiple mailboxes in large batches.
  • Primary and personal archives can be moved together.
  • It generates email notifications with reports during the move request.
  • It performs a periodic incremental sync to update migration changes.
  • It has automatic retry and prioritization features.
  • It has an option for manual move request finalization.

 

The migration service creates a batch composed of individual moves, each of which is written as a mailbox move item to the arbitration mailbox. The migration service then instantiates a separate mailbox move request for each move item. After this happens, the Mailbox Replication Service (MRS) starts to process the moves. All during the move process, the migration service monitors the move items and updates status as necessary. Eventually the migration batch completes, with or without errors, and the migration service reports the outcome to the admin (optional email).

 

To move a local mailbox from one Exchange 2013 mailbox database to another you should use the EMS because there are more parameters to set whether in the EAC.

 

We will give you a best practices example how to move a single mailbox from one mailbox database to another mailbox database using the EMS in the Fabrikam scenario. The user “Carol Troup”, which is currently in site Denver on mailbox database “Denver-DB01”, will be moved to the mailbox database “Denver-DB02” at the same site. First, create a .csv file with the EmailAddress header and with the email address of the user. You should only choose unique header values for the .csv file. Figure 6 shows the created .csv file on the local disk of any Exchange server.

 

 

Note: Also if you move only a single mailbox you have to create a .csv file. Alternatively you can use the EAC if you only move a single mailbox and don’t need any specific parameters, such as LargeItemLimit, which specified the number of large items in each mailbox.

 

Next you have to create the local migration batch with the following cmdlet:

 

New-MigrationBatch –Name “Denver local move” –CSVData ([System.IO.File]::ReadAllBytes(“C:\new_migrationbatch.csv”)) –Local –TargetDatabase “Denver-DB02” –AutoStart –AutoComplete –NotificationEmailsAdministrator@fabrikam.com –AutoRetryCount 3

 

Now your migration batch “Denver local move” was created, will automatically start, automatically complete, email notifications about the mailbox move are enabled, and retrying 3 times if the mailbox move failed, for whatever reasons. You can additionally check some move statistics with the following cmdlet:

 

Get-MigrationUser | Get-MigrationUserStatistics

 

Figure 7 shows the move statistics in the EMS.

 

Importing and exporting mailboxes

Moving mailbox content to and from Personal Storage Files (PSTs) has long been a normal function of an Exchange administrator’s job. Since Exchange Server 2007, there has been a built-in feature for importing mailbox content into and exporting it from PSTs. This feature was improved in Exchange 2010 and also available in Exchange 2013. Importing or exporting a mailbox can be done using the EMS with the New-MailboxExportRequest and New-MailboxImportRequest cmdlets.

 

By default, no roles have rights to use any of the import or export cmdlets. You have to add the rights to a role or user before these cmdlets are available. For example, to assign these rights to Alex, run the following:

 

New-ManagementRoleAssignment –Role “Mailbox Import Export” –User Alex

To assign the roles to an entire group named Import Export Group, run the following:

New-ManagementRoleAssignment –Role “Mailbox Import Export” –Group “Import Export Group”

 

After you assign the proper rights, a few additional prerequisites must be met before you can use New-MailboxImportRequest or New-MailboxExportRequest:

  • A network share must be accessible by your Exchange servers. You have to assign the Exchange Trusted Subsystem group read/write permissions for the network share.
  • When exporting data to a PST file, only one mailbox at a time can be exported.
  • The maximum PST file size supported by Outlook 2010 or Outlook 2013 is 50 GBs.
  • Importing or exporting data must be performed on a computer with the Exchange Server 2013 role installed. It is recommended that this be a server dedicated to importing and exporting mailbox data, such as a management server.
  • Data can’t be imported or exported to ancient or modern public folders

 

When you use the New-MailboxImportRequest cmdlet, the mailboxes do not have to match. For example, you can import data from a mailbox named kelly@contoso.com to a mailbox named alex@contoso.com. All messages from the Recoverable Items structure are imported unless the ExcludeDumpster switch is specified, and even hidden data, if it exists in the .pst, will be imported. When data is merged into the existing mailbox, it will not import duplicated messages. TheNew-MailboxImportRequest cmdlet with the parameter TargetRootFolder imports the data into a subfolder, called RecoveredFiles, of the target mailbox. When using this cmdlet, you have the option of including or excluding special folders, such as the following:

  • Inbox
  • Deleted Items
  • Drafts
  • Junk Email
  • Outbox
  • Sent Items
  • Fax
  • Conflicts
  • Calendar

 

Note: Additionally, you can export and import archive files by using the –IsArchiveparameter. There are several other parameters you can use, such as for exporting and importing Outlook rules, which are configured by the end user.

 

You export mailbox data by using the New-MailboxExportRequest cmdlet in the EMS. Although the cmdlet has a limitation of being able to export only a single mailbox at a time, it does have nice features you can use to delete associated messages or filter out messages based on recipients and senders. To filter on senders, use the SenderKeywords parameter. To filter on recipients, use theRecipientKeywords parameter. You can remove one or even multiple messages using the New-MailboxExportRequest cmdlet. You might want to do this when a message is accidently sent to the wrong mailbox or when you need to process a mailbox for legal reasons.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s