How to Install, Configure, and Manage the Mailbox Role in Microsoft Exchange Server 2013

Objective 1.2: Configure and manage the mailbox role

Exchange 2013 setup is now greatly simplified, and it also accounts for installing operating system component prerequisites as a part of the setup, if selected. But this simplification doesn’t prevent the need to carefully plan the deployment of the mailbox server roles, taking into account the unique qualities of the environment where Exchange 2013 is being deployed. In this section, you learn the details of how to configure and manage mailbox role and related components.

Deploying mailbox server roles

The first step to successfully deploy a mailbox server is to ensure that all of the prerequisites are met. Starting with authentication provider, you must be certain that at least one writeable domain controller exists in each Active Directory site where you plan to deploy an Exchange 2013 server. The supported operating system running on the Active Directory controller is Windows Server 2003 or later. Referencing mail-enabled objects is critical for Exchange server roles. For Exchange server to function properly, you must deploy at least one global catalog server in each Active Directory site where you plan to deploy an Exchange 2013 server.

The network infrastructure using the IPv6 protocol is supported only when IPv4 is also installed and enabled.

In small environments, it’s tempting to collocate Exchange 2013 server on a server that’s also a domain controller to reduce the number of servers required. While it is a supported to install Exchange 2013 on a domain controller, for security and performance reasons, the recommendation is to install Exchange 2013 server on a member server in a domain. If you choose to collocate an Exchange server with a domain controller, the server can’t later be demoted to a member server or promoted to a domain controller from a member server after Exchange server is installed.

Since the Resilient File System (ReFS) was introduced in Windows Server 2012, it hasn’t shared much of the limelight, despite the new features that offer a better integrity of data. Exchange 2013 supports storing database files, transaction log files, and content index files on partitions formatted with ReFS. But partitions storing Exchange binary files and diagnostics logging data generated by Exchange server must be formatted using the NTFS file system.

Windows Server Core installations reduce the management overhead and increase the security profile of the server by reducing the attack surface. Core installations, however, aren’t supported for Exchange 2013 server installations. If you have Windows Server 2012 or Windows Server 2012 R2, it’s possible to convert from a Core installation to a Full installation of the server. But if you have a Windows 2008 R2 Core installation, you must reinstall the operating system using the Full installation option. Windows Server 2012 R2 is only supported with Exchange 2013 Service Pack 1 or later.

Preparing the organization is one of the first steps that needs to be run before installing any Exchange 2013 server roles. In an environment where role separation is required, the Exchange administrator might not have the ability to modify the Active Directory schema. In such cases, the Active Directory administrator with Schema Admins and Enterprise Admins privileges needs to run the preparation steps before the Exchange administrator can install Exchange 2013 servers. In Active Directory forests with multiple domains, it’s also important to run Active Directory preparation steps from a computer in the same domain and site as the domain controller that is a Schema Master.

Because this first step requires access to Active Directory, tools that enable you to administer Active Directory are required on the server where the setup is being run. Remote Tools Administration Pack (RSAT) includes all of the required tools and must be installed if the computer is not a domain controller; it can be installed via server manager interface or by using PowerShell. If the server is running Windows Server 2008 R2, you can use the command line Add-WindowsFeature RSAT-ADDS. On Windows Server 2012 or later, run Install-WindowsFeature RSAT-ADDS instead. While the difference is subtle, note the cmdlet, which is different between the two versions, while the component being installed is the same.

When using setup.exe in unattended mode, which can also be used for unattended setup, you must also use the /IAcceptExchangeServerLicenseTerms switch for setup to succeed. No abbreviated aliases exist for the switch.

When preparing a schema, you must allow for the replication to complete from a schema master to all of the domain controllers in all of the domains of the forest. You need to do this before you can proceed to the next steps of preparing Active Directory and preparing domains where Exchange servers and Exchange server users are to be located. In an Active Directory forest with multiple domains, you must prepare every domain where Exchange server users reside, even if an Exchange server won’t be installed in that domain.

When extending the Active Directory schema, Exchange server setup adds and updates classes, attributes, and other items. In simple terms, this is how Active Directory is made aware of what Exchange objects are going to be made up of.

When preparing Active Directory, in new environments, an Exchange Organization is created using the name provided by the administrator. In existing environments, an existing Exchange organization is updated to include Exchange containers, objects, and attributes. When an Exchange server is installed, you’ll find that the corresponding Exchange server object is created within the Exchange organization container in Active Directory.

The last step in preparation of Active Directory is the preparation of domains. During this step, Exchange-related containers and security groups are created. Setup also assigns permissions to the containers, so the Exchange server can access them.

If the Exchange administrator also has required Active Directory permissions, the Exchange Setup Wizard can run all three Active Directory preparation steps automatically.

After the successful installation of Exchange servers, Exchange administrators with permissions to create objects can create new security principals, such as a user in Active Directory, before creating an Exchange mailbox if needed. This model of security might not be preferred in organizations with strict role separation requirements. In such environments, Active Directory administrators are unable to manage Exchange objects, such as mailbox creation, distribution group creation, and so on. Likewise, an Exchange administrator isn’t permitted to create a new user in Active Directory. To achieve such role separation, Exchange setup provides the capability to create Active Directory split permissions. This can be achieved during the setup or after Exchange servers are set up, by running setup.exe with the /ActiveDirectorySplitPermissions switch set to True.

When using the Setup Wizard, the Apply Active Directory split permission security model to the Exchange organization option is only available if you are setting up the first Exchange server in a new organization. In an existing organization, you must use setup.exe in unattended mode with the previously mentioned switch to change the existing permission model.

When permissions are involved, larger environments tend to have separation of roles and duties that extend beyond just separation between Exchange and Active Directory administrators. For example, you can have an Exchange architect who is responsible for setting objectives for the Exchange server design and deployment. They might also serve as a subject matter expert and a point of escalation when needed. Daily management tasks might be further delegated to other Exchange administrators. Similarly, an organization might hire temporary staff to assist with time-bound, short-term needs where hiring a new person might not be warranted or possible.

Exchange setup accounts for such requirements where the person setting up an Exchange server might not be responsible for managing an entire Exchange organization and might only need limited permissions that enable them to successfully install new Exchange server roles.

For delegated setup to work, you must have at least one Exchange server installed in the organization. Next, the organization administrator must provision a new Exchange server in Active Directory. This can be achieved by running setup.exe from the command line and using the /NewProvisionedServer switch. If you’re provisioning a new server using a different computer to run the setup, you must also include the computer name of the server being provisioned with the /NewProvisionedServer switch. After provisioning a new server, the user who is performing an installation of Exchange server needs to be added to the Delegated Setup role group.

Creating and configuring Offline Address Book

Address books are part of the functionality Exchange server offers to enable users to find other users easily. Address books are created and maintained by mailbox servers. The Offline Address Book (OAB) enables users to use Address Book functionality when they aren’t connected to Exchange server.

Address lists are a building block of OAB. Address lists represent a collection of recipients and other mail-enabled objects, such as contacts, groups, and room/equipment resources. When Exchange 2013 is installed, it automatically creates multiple default address lists that contain contacts, distribution lists, rooms, users, and public folders. The default Global Address List (GAL), which contains all mailbox-enabled or mail-enabled objects from the Active Directory forest where Exchange is installed, is also created.

You can also create custom address lists to contain mail-enabled objects from certain departments, geography, or any other organizational entity that can help users identify which address list is most likely to contain a user they want to find. Custom address lists tend to be a subset of objects contained in a global address list. New address lists can be created using the New-AddressList cmdlet or by using the Exchange Admin Center (EAC).

When creating a new address list, you can restrict which recipients should be included in the new address list by using built-in filter parameters, such as the ConditionalDepartment. This only selects users with a department attribute that matches a defined value of the parameter. Here’s an example of creating a new address list named Finance that includes all users with a department attribute set to Finance.

Create new address list

New-AddressList –Name Finance –IncludedRecipients AllRecipients –ConditionalDepartment
Finance

The same can be achieved using the Exchange Admin Center, as you can see in Figure 1-2.

When built-in filter parameters might not be sufficient to create a custom address list, you can create recipient filters using the OPATH filtering syntax. To create a custom address list using the recipientfilter parameter, you can’t use the Exchange Admin Center (EAC) and you must use the Shell. In the following example, let’s create a custom address list to include all users with a mailbox from finance or the sales department, based on their department attribute value.

Create new address list using recipient filter

New-AddressList –Name ""Finance-Sales"" –RecipientFilter {((RecipientType -eq
'UserMailbox') -and ((Department -eq 'Finance') -or (Department -eq 'Sales')))}

For the list of filterable properties that can be used with a recipient filter, see the article Filterable properties for the RecipientFilter parameter at http://technet.microsoft.com/en-us/library/bb738157(v=exchg.150).aspx.

While default GAL contains all objects, when an organization is required to provide separation between different departments to achieve compliance or other business reasons, a single default GAL doesn’t serve the purpose. To address the requirement, you need to create additional global address lists and provide separation using Address Book policies. The process is also referred to as Global Address List (GAL) segmentation.

Each Address Book policy consists of four components:

• Address Lists
• Room Address List
• Global Address List
• Offline Address Book

When you create address lists, you use recipient address filters to create a logical separation between entities. For example, you can create two separate address lists, each containing employees and contacts from the Finance department and the Sales department, respectively. You also create separate room address lists to contain rooms and resources that should only be available to one department. A new GAL is then created to include custom address and room lists, as well as corresponding OAB objects containing their corresponding GAL objects. When this procedure is complete, you will have two Address Book policies separating two department Address Books.

The logical separation still isn’t achieved since user mailboxes need to be configured to start using their corresponding GALs and OABs. You can configure user mailboxes to use new GALs and OABs by using the Set-Mailbox cmdlet.

Let’s walk through this process.

GAL segmentation walk-through

#Create address lists for each department
New-AddressList –Name "Finance AL" –IncludedRecipients AllRecipients
–ConditionalDepartment Finance
New-AddressList –Name "Sales AL" –IncludedRecipients AllRecipients
–ConditionalDepartment Sales

#Create room address lists for each department
New-AddressList -Name "Finance Room AL" -RecipientFilter {(RecipientDisplayType
-eq 'ConferenceRoomMailbox')}
New-AddressList -Name "Sales Room AL" -RecipientFilter {(RecipientDisplayType
-eq 'ConferenceRoomMailbox')}

#Create Global Address Lists for each department
New-GlobalAddressList -Name "Finance Global Address List" -IncludedRecipients
MailboxUsers -ConditionalDepartment Finance
New-GlobalAddressList -Name "Sales Global Address List" -IncludedRecipients MailboxUsers
-ConditionalDepartment Sales

#Create Offline Address book objects for each department
New-OfflineAddressBook -Name "Finance OAB" -AddressLists "\Finance Global Address List"
-VirtualDirectories "SERVER01\OAB (Default Web Site)"
New-OfflineAddressBook -Name "Sales OAB" -AddressLists "\Sales Global Address List"
-VirtualDirectories "SERVER01\OAB (Default Web Site)"

#Create Address Book Policies (ABPs) for each department
New-AddressBookPolicy -Name "Finance ABP" -AddressLists "Finance AL" -OfflineAddressBook
"\Finance OAB" -GlobalAddressList "\Finance Global Address List" –RoomList "\Finance
Room AL"
New-AddressBookPolicy -Name "Sales ABP" -AddressLists "Sales AL" -OfflineAddressBook "Sales OAB" -GlobalAddressList "\Sales Global Address List" -RoomList "\Sales Room AL"

#Assign the ABPs for each mailbox
Set-Mailbox "FinUser1" –AddressBookPolicy "Finance ABP"
Set-Mailbox "SalesUser1" –AddressBookPolicy "Sales ABP"

So far, we’ve followed all of the logical steps to provide a separation between two departments. Notice how we only changed one mailbox for each department in the previous example. Obviously, in the real world, you have to change all of the mailboxes of each department to apply the correct ABPs to each.

Here’s one more item not covered yet: name resolution. When a user from Outlook types a name in the address bar, Outlook provides the capability to resolve the name from GAL. Despite the separation created using ABPs, name resolution continues to work across logical boundaries created by ABPs. This is because name resolution is an organizational function and, despite logical separation, the objects from both departments continue to exist in a single Exchange organization. To address this problem, two departments, when using ABPs, must be considered external to each other. The Address Book Policy routing agent provides this function.

The ABP routing agent must be manually installed and enabled to provide name resolution separation. Take a look at the process.

Install and enable ABP routing agent

#Install ABP routing agent
Install-TransportAgent -Name "ABP Routing Agent" -TransportAgentFactory
"Microsoft.Exchange.Transport.Agent.AddressBookPolicyRoutingAgent.
AddressBookPolicyRoutingAgentFactory" -AssemblyPath $env:ExchangeInstallPathTransportRoles\agents\AddressBookPolicyRoutingAgent\Microsoft.Exchange.Transport.Agent.
AddressBookPolicyRoutingAgent.dll

#Enable transport agent
Enable-TransportAgent "ABP Routing Agent"

#Restart transport service
Restart-Service MSExchangeTransport

#Enable ABP routing agent
Set-TransportConfig -AddressBookPolicyRoutingEnabled $true

After following these steps, name resolution across departments shouldn’t work and, along with configured Address Book policies, it provides the desired separation between two departments.

Figure 1–3 provides an example of a Sales user trying to resolve the display name of a Finance user (finuser1) while ABP separation is in place and the ABP routing agent is configured.

Now let’s look at more details of Offline Address Books. Because OABs are offline copies of address lists associated with an OAB, the files corresponding to the OABs need to be generated on Exchange servers. On Exchange 2013 servers, this is the function of the Microsoft Exchange OABGen service. The Microsoft Exchange OABGen service isn’t a schedule-based function. Instead, based on server resource availability, it’s throttled or paused as needed.

Exchange 2013 supports and produces OAB v4 files only. OAB v4 was introduced with the release of Exchange 2003 Service Pack 2 and is supported by Outlook 2007 and later. OAB v4 Unicode format allows client computers to receive differential updates, instead of full OAB downloads, as well as a reduction in file size.

Exchange 2013 uses web-based distribution, which Outlook clients use to download OAB files. In contrast to public folder-based distribution in previous versions, web-based distribution provides distinct advantages, such as the ability to support more concurrent clients for OAB distribution, a reduction in bandwidth usage, and more control over the distribution end point. Clients use Autodiscover to locate the OAB distribution point they should connect to, which, in turn, can be load-balanced end points providing better resiliency.

Another change in Exchange 2013 regarding OAB is generation. OAB generation is no longer associated with a particular mailbox server like in previous versions. When we created an example OAB in the previous ABP exercise, you may have noticed we didn’t specify a generation server. The OAB generation functionality is now associated with a specialized mailbox called the arbitration mailbox. When Exchange server is installed, multiple arbitration mailboxes are automatically created and are associated with different persisted capabilities, which define the purpose and function of an arbitration mailbox. An arbitration mailbox with persisted capability OrganizationCapabilityOABGen is responsible for OAB generation. The new functionality can now benefit from higher availability provided by a DAG when a mailbox is located on a database protected by DAG.

Because no generation server exists, changing the OAB generation server simply means moving the arbitration mailbox to a different database on a different server if the database isn’t protected by DAG. If a mailbox is located on a database copy protected by DAG, you can simply activate a different copy of the database on a different server to move the arbitration mailbox to a different server.

To provide close proximity to an OAB generation mailbox in a distributed environment, you can create additional arbitration mailboxes as needed. When creating an arbitration mailbox, specify the Arbitration parameter to the New-Mailbox cmdlet. After creating an arbitration mailbox in the desired location, enable OAB generation by using the –OABGen $True parameter with the Set-Mailbox cmdlet.

When an OAB download request is received by a client access server, it proxies the request to the mailbox server hosting an active arbitration mailbox in the same Active Directory site. If more than one mailbox server contains an active arbitration mailbox with an OAB generation capability, the client access server sends the requests using round-robin distribution. This could result in the frequent full download of OABs by the client and isn’t recommended.

The OAB generation schedule configuration has also been changed in Exchange 2013. Schedule property on the OAB object is no longer affected when the OAB is generated. The OAB generation is now controlled based on the configuration of the OABGeneratorWorkCycle and the OABGeneratorWorkCycleCheckpoint properties of a mailbox server. The default values of these attributes are set to one day, resulting in the OAB generation taking place once every day. Values of these parameters can be changed using the Set-MailboxServer cmdlet.

If you need to manually force the generation of a particular OAB, you can use the Update-OfflineAddressBook cmdlet. You can also restart the mailbox assistant service, but it’s more impactful on the server resources and it isn’t the best or most preferred option when a better option exists.

Designing and creating hierarchical address lists

While GAL provides the ability to easily find recipients from an organization, it doesn’t reflect management or seniority relationships within recipients of the organization. The hierarchical address book (HAB) enables end users to look for recipients using an organizational hierarchy, thus providing an efficient method for locating internal recipients.

The HAB is enabled at the organization level by using the Set-OrganizationConfig cmdlet. When enabling HAB, you need to provide a distribution group to use as the root of HAB. You can create a separate organizational unit (OU) to store all HAB-related distribution groups or use an existing OU in Active Directory.

You also need to create more distribution groups, each corresponding to the hierarchy of the company. For example, HQ, designating company headquarters, locations, and departments.

The hierarchy is created by using a distribution group nesting. You need to add subordinate distribution groups to their parents as a member. For example, distribution group HQ is added to the root distribution group, and department distribution groups HR and Accounting are added to the distribution group HQ to represent a hierarchy.

Individual recipients show up in the HAB based on their distribution group membership. For example, the CEO of the company might be a member of distribution group HQ, whereas the Director of Human Resources might be added to the HR distribution group, and so on.

Once the distribution group for the HAB root is created and the HAB is enabled at the organization level, set the value of the IsHierarchicalGroup property on the distribution group to $true. You also need to repeat this step for all of the distribution groups that are members of the HAB.

When you have multiple members for a given location, such as HQ, in the HAB display, they are organized alphabetically in ascending order. It might be more desirable to show the members based on their seniority. HAB enables you to achieve that by setting the value of the SeniorityIndex attribute on the recipient or the distribution group. In HAB, objects are organized based on seniority index values from higher to lower.

Let’s take a look at the process of creating the HAB root distribution group and enabling HAB for Contoso, Ltd.

Enable Hierarchical Address Book

#Add OU for Hierarchical Address Book
dsadd ou "OU=HAB,DC=Contoso,DC=com"

#Create root Distribution group
New-DistributionGroup -Name "Contoso,Ltd" -DisplayName "Contoso,Ltd" -Alias
"ContosoRoot" -OrganizationalUnit "Contoso.com/HAB" -SamAccountName "ContosoRoot" -Type
"Distribution"

#Enable HAB using Contoso Distribution Group created for HAB root
Set-OrganizationConfig -HierarchicalAddressBookRoot "Contoso,Ltd"

#Designate distribution group as member of HAB
Set-Group -Identity "Contoso,Ltd" -IsHierarchicalGroup $true

At this point, you have an empty HAB, which would look similar to Figure 1–4 when using the Outlook client.

Now let’s create subordinate distribution groups HQ, New York, and London, and then add them to their relevant parent distribution groups. HQ also has HR and Accounting sub groups. We also set the seniority index of a few recipients and add them to the appropriate distribution groups in the hierarchy.

Create subordinate groups and configure hierarchy

#Create subordinate distribution groups
New-DistributionGroup -Name "HQ" -DisplayName "HQ" -Alias "HQ" -OrganizationalUnit
"Contoso.com/HAB" -SamAccountName "HQ" -Type "Distribution"
New-DistributionGroup -Name "HR" -DisplayName "HR" -Alias "HR" -OrganizationalUnit
"Contoso.com/HAB" -SamAccountName "HR" -Type "Distribution"
New-DistributionGroup -Name "Accounting" -DisplayName "Accounting" -Alias "Accounting"
-OrganizationalUnit "Contoso.com/HAB" -SamAccountName "Accounting" -Type "Distribution"
New-DistributionGroup -Name "New York" -DisplayName "New York" -Alias "New York"
-OrganizationalUnit "Contoso.com/HAB" -SamAccountName "NY" -Type "Distribution"
New-DistributionGroup -Name "London" -DisplayName "London" -Alias "London"
-OrganizationalUnit "Contoso.com/HAB" -SamAccountName "London" -Type "Distribution"

#Designate distribution groups as member of HAB
Set-Group -Identity "HQ" -IsHierarchicalGroup $true
Set-Group -Identity "HR" -IsHierarchicalGroup $true
Set-Group -Identity "Accounting" -IsHierarchicalGroup $true
Set-Group -Identity "New York" -IsHierarchicalGroup $true
Set-Group -Identity "London" -IsHierarchicalGroup $true

#Add distribution groups to appropriate parent
Add-DistributionGroupMember -Identity "ContosoRoot" -Member "HQ"
Add-DistributionGroupMember -Identity "ContosoRoot" -Member "New York"
Add-DistributionGroupMember -Identity "ContosoRoot" -Member "London"
Add-DistributionGroupMember -Identity "HQ" -Member "HR"
Add-DistributionGroupMember -Identity "HQ" -Member "Accounting"

#Add members to appropriate distribution groups
Add-DistributionGroupMember -Identity "HQ" -Member "Ray"
Add-DistributionGroupMember -Identity "HQ" -Member "Peter"
Add-DistributionGroupMember -Identity "HR" -Member "Mary"

#Assign appropriate seniority index to members
Set-Group -Identity "HR" -SeniorityIndex 100
Set-User -Identity "Ray" -SeniorityIndex 100
Set-User -Identity "Peter" -SeniorityIndex 99

After the completion of the previous steps, we now have an example HAB, complete with subordinate groups and their members. Because we also assigned seniority to Ray, he is displayed before Peter in the list, overriding the default alphabetical ordering. The same also applies to the HR department, which displays before Accounting in the hierarchy. Figure 1–5 represents the example HAB.

Notice how London is listed after HQ and before New York. Because we chose not to assign any seniority index to the locations, they’re displayed using default alphabetical display order. However, Ray is displayed before Peter and HQ is displayed before Accounting as defined by the seniority index.

The Name List tab still provides you with a nonhierarchical reference to all recipient objects, as shown in Figure 1–6.

It’s important for you to understand that the effort involved in a large environment to enable HAB goes beyond the simple steps demonstrated here. In such an organization, you might need to create many distribution groups representing each leaf of hierarchy and then add DLs as needed. You also need to define each individual member’s seniority index where necessary, which in large environments can be daunting. It’s best to have a defined business process that mandates appropriate steps, either performed manually by the administrative staff or by scripting triggered on appropriate intervals to keep HAB updated according to changes occurring in the environment.

Creating and configuring public folders

Creating public folders in Exchange 2013 is a different process compared to previous versions. This is because public folders are now stored in public folder mailboxes. In a new installation where no public folders exist, the first step is to create a public folder mailbox. Because this is the first public folder mailbox in the organization, it contains public folder hierarchy information and becomes the primary hierarchy mailbox. The public folder mailbox can also contain public folder content.

The primary hierarchy mailbox is the only writeable copy of the hierarchy in the organization. All other public folder mailboxes created contain a read-only copy of the public folder hierarchy.

You can create a public folder mailbox using EAC or the Shell. Similar to any other mailbox, the cmdlet you use to create the public folder mailbox is New-Mailbox. To designate a mailbox as a public folder mailbox, use the PublicFolder parameter. There is no difference in the syntax for creating the first public folder mailbox containing the primary public folder hierarchy and secondary public folder mailboxes. Exchange server automatically creates the public folder with an appropriate copy of the hierarchy. To verify which mailbox contains the primary writeable copy of the public folder hierarchy, you can issue Get-OrganizationConfig | Format-List RootPublicFolderMailbox at the Shell.

After creating a public folder mailbox, you can now create a public folder that users see in the hierarchy and can store content in. To create a public folder, you can use New-PublicFolder cmdlet or EAC. You can specify a name for the folder being created, the path in the hierarchy where the folder is created and, optionally, the public folder mailbox where the content for the folder is stored. You don’t need to define the path if you’re creating a public folder in the root of the hierarchy.

When you create a public folder, it inherits the settings of its parent folder, which includes the permissions assigned to the parent public folder. To assign permissions to a public folder, you can use EAC or use the Add-PublicFolderClientPermission cmdlet. You can either choose to assign permissions such as ability to read, create or delete items, or assign a role, such as owner, editor, or author. Each role represents a combination of permissions on the public folder. For example, the Reviewer role enables the assignee permissions to see the public folder and its contents, but it has no ability to edit or delete them.

Public folders also allow the ability to submit content via email. To do so, you must mail-enable a public folder. Similar to other public folder-related procedures, you can use EAC to mail-enable a public folder, or you can use the Enable-MailPublicFolder cmdlet. When mail-enabling a public folder, you don’t need to provide an email address for the folder. You can, however, change the primary email address or assign additional email addresses to a mail-enabled public folder, if needed. If you use the Shell, you can use the Set-MailPublicFolder cmdlet to update an email address and other mailbox properties, such as the mailbox quota.

Another important consideration for when you mail-enable a public folder mailbox, is to ensure that only authorized users can submit content via email. You can choose to accept emails from individual recipients or members of a distribution group. Use the Set-MailPublicFolder cmdlet with the AcceptMessagesOnlyFrom, AcceptMessagesOnlyFromDLMembers, or AcceptMessagesOnlyFromSendersOrMembers parameters to assign appropriate sender restrictions.

Now that only one writeable copy of the public folder hierarchy exists, it’s critical that the public folder mailbox containing a writeable copy of the hierarchy is highly available. Ensure that the public folder mailbox is located on a database copy protected by DAG and has multiple database copies located in appropriate locations to provide protection against local and site failures. The same protection should also be applied to all public folder mailboxes that store critical public folder content.

If public folders are accessed by users located across multiple locations and regions connected via WAN or slower network links, you can improve the user experience when accessing a public folder hierarchy. You can also provide uninterrupted access in case of network failures between a client location and other sites. You do this by creating a public folder mailbox in close proximity to the client location where network connectivity between client and Exchange server is robust. After creating a public folder mailbox in such a location, you need to change all user mailboxes for a given office or regions to use the new public folder mailbox as their default access location for the public folder hierarchy. You can do so by using the Set-Mailbox cmdlet with the DefaultPublicFolderMailbox parameter.

While this provides users with uninterrupted access to the public folder hierarchy, uninterrupted access to the content can only be guaranteed if the public folder content is also stored on public folder mailboxes that are locally accessible. That is why locating public folder content requires careful planning and an understanding of the usage of public folders and the factors affecting it, such as a public folder containing regional data or a public folder containing company data that might be applicable to all public folder users.

Moving a public folder mailbox may be necessary due to organizational or infrastructure changes. If you need to move a public folder mailbox, you can do so by issuing a mailbox move request, similar to moving a regular mailbox. This enables you to move the public folder mailbox, including all of its content, including the primary or read-only copy of a public folder hierarchy, to a different database located on the same or a different server, which may or may not be a part of DAG. When you need to provide high availability to a public folder mailbox, you should move it to a database configured with multiple copies protected by DAG. If you’re using the Shell, you can use the New-MoveRequest cmdlet to move a public folder server.

When the organization grows, you might need to change where the public folders are stored. You might need to move a public folder to a different public folder mailbox to provide close proximity access to its primary user base. Or, you might need to move a public folder that exceeds the assigned mailbox storage quota. Moving a single public folder is as simple as issuing the New-PublicFolderMoveRequest cmdlet.

If you need to move a public folder, including all of the public folders within its branch, you can’t use the New-PublicFolderMoveRequest cmdlet. While the cmdlet enables you to move multiple individual public folders to a different mailbox, it doesn’t move an entire branch of a selected public folder. To move the entire branch of a public folder, you must use the Move-PublicFolderBranch.ps1 script, which is included with an Exchange server installation.

The process of creating public folders in a new environment might seem relatively simple. Migrating public folders from a previous version of Exchange servers requires careful planning. This is because when the public folder data is migrated to Exchange 2013 servers, it doesn’t synchronize with a previous version of public folders.

Migrating from a previous version of public folders is a multi-step process. The supported version of Exchange servers for such a migration is Exchange Server 2007 SP3 RU10 and Exchange Server 2010 SP3 or later.

The first step in the migration process is to use public-folder migration scripts to create the public folder name to size mapping and the public folder to the proposed new public-folder mailbox mapping. The collection of statistics enables you to understand the impact on new Exchange 2013 servers. It also enables you to create the required public folder mailboxes according to the appropriate folder size mapping created by the scripts.

Before you proceed with migration, ensure that no public folder mailboxes exist on Exchange 2013 and that no public folder migration requests exist. You can verify any existing public-folder migration requests by running the Get-PublicFolderMigrationRequest cmdlet. If a migration request exists, you need to make sure no migration is in progress or you risk losing data when you remove the migration request to start the new migration.

After ensuring that starting a new public folder migration is appropriate, start the process by creating public folder mailboxes. When you create the first public folder mailbox, set the property of the HoldForMigration parameter to $true. Use the csv file created by the migration script PublicFoldertoMAilboxMapGenerator.ps1 to create additional public folder mailboxes.

After the successful creation of all required public folder mailboxes, you can start the migration request by using the New-PublicFolderMigrationRequest cmdlet. The time it takes to migrate the public folder data depends on the amount of data being migrated, the load on the source and destination servers, and other environmental factors, such as the network infrastructure.

When the migration is started, Exchange servers synchronize public folder data from a previous version of Exchange servers to the new public folder mailboxes created earlier. However, during the initial data synchronization process, users can continue using legacy public folders and make changes.

When the migration process reaches the status of autosuspended, you can lock the public folders on a legacy exchange server for final migration. To verify the status of the migration process, run the Get-PublicFolderMigrationRequest cmdlet. To lock down the legacy public folders for final migration, run Set-OrganizationConfig -PublicFoldersLockedForMigration:$true. After performing this step, users won’t be able to access public folders or make any changes. If public folder databases are distributed across multiple locations, it might take several hours for the change to converge. You can verify the status of public folder databases by verifying the PublicFoldersLockedForMigration flag.

Once all of the legacy public folders are locked for migration, you can set the PreventCompletion property on the public folder migration request to $false. This action allows the final synchronization of public folder data to take place. You also need to resume the public folder migration request by issuing the Resume-PublicFolderMigrationRequest cmdlet. The amount of time required for the final synchronization depends on the amount of changes made by users to the public folder data after the migration process reaches the autosuspended status, and before the legacy public folders are locked for migration.

Before you can enable public folders on Exchange 2013, you need to ensure that the migration is complete, which you can verify by running the Get-PublicFolderMigrationRequest cmdlet and ensuring that the status is Completed. Once complete, you can allow user access to migrated public folders on Exchange 2013 servers by setting the IsExcludedFromServingHierarchy property on the public folder mailboxes to $false. You also need to set the organization configuration property PublicFolderMigrationComplete to $true on legacy Exchange servers, and then set the PublicFoldersEnabled property of the organization configuration on Exchange 2013 servers to Local.

Users can access data from migrated public folders on Exchange 2013 after the successful completion of the previously shown process. But there might be times when a migration doesn’t complete successfully and you need to roll back the migration, so users can continue to access public folders from legacy exchange servers. To roll back the migration, you need to set the organization property PublicFoldersLockedForMigration on legacy Exchange servers to $false, remove all of the public folder mailboxes created on Exchange 2013 servers, and set the PublicFolderMigrationComplete flag on the organization property to $false from legacy Exchange servers.

Once the new public folders are deployed on the Exchange 2013 mailbox, you might need to address such issues as accidental deletions of a public folder or the deletion of a public folder mailbox. This can happen because of a user action, a failed public folder, or a public folder mailbox move. Because the public folder mailboxes are now similar to user mailboxes, restoring a deleted public folder mailbox is similar to restoring a deleted mailbox. Use the New-MailboxRestoreRequest cmdlet and provide the appropriate values for SourceStoreMailbox, SourceDatabase and TargetMailbox. If the public folder mailbox is intact, but a public folder is deleted instead, you can restore the public folder by using a similar process to the one previously mentioned. You also need to include the IncludeFolders parameter with the public folder path of the folder that needs restoring.

The process gets more involved when a deleted public folder or the public folder mailbox is past its retention period as defined on the mailbox and mailbox database properties.

The process to restore a public folder mailbox and public folders past their retention period requires recovering data using a recovery database. For more information on this topic, see Develop backup and recovery solutions for the mailbox role and public folders in Objective 1.5 later in this chapter, which covers this topic in detail. The process applies to both regular and public folder mailboxes. At a high level, the process involves creating a recovery database, restoring data from backups, mounting restored databases, and extracting the data from the recovery database. Extracted data can then be exported to a folder or merged into an existing mailbox.

Objective summary

• Schema updates are required anytime you install an Exchange 2013 server, including when you apply updates. Plan for schema update dependencies, including OS components required, such as the Remote Tools Administration Toolkit to make schema updates.
• If you’re using the Setup Wizard and have appropriate permissions to make schema and domain changes, you don’t need to perform schema updates separately before running setup.
• When using the command line setup, if you run Prepare Domain before applying schema updates and before preparing Active Directory, setup tries to perform those steps automatically and it will succeed if the account running setup has required permissions.
• Address book segmentation allows logical separation between business units or different companies hosted on the same Exchange organization.
• HABs provides an organizational hierarchy view, making navigation and search of recipient easier compared to flat address-book structure provided by the default address-book view.
• Public folder migration requires that careful planning and downtime is required. Rollback is possible, but it might involve data loss because no backward synchronization exists from Exchange 2013 public folders to legacy public folders.

Objective review

Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.

1. Contoso, Ltd. has deployed an Exchange 2013 environment in the child domain ny.contoso.com. The empty forest root domain is called consoto.com. Contoso, Ltd. later introduces a new domain, London.contoso.com. What should you do before enabling recipient objects in the domain London.contoso.com?

   1. Run setup.exe /prepareschema.
   2. Run setup.exe /preparead.
   3. Run setup.exe /preparedomain.

2. When an Exchange server crashed, users complained their Address Books didn’t include recent new hires. You need to move the OAB generation to a different server. What should you do?

   1. Run Move-OfflineAddressBook cmdlet.
   2. Run Set-OfflineAddressBook cmdlet.
   3. Run Move-Mailbox cmdlet.
   4. Run Update-OfflineAddressBook cmdlet

3. Contoso, Ltd. has implemented a hierarchical address book (HAB). You need to ensure the company’s CEO is listed before other employees, regardless of the alphabetical order of names. What should you do?

   1. Run Set-Mailbox cmdlet to change CEO’s mailbox.
   2. Run Set-DistributionGroup to change the seniority index.
   3. Run Set-OrganizationConfig –OrganizationSummary $true.
   4. Run Set-AddressList cmdlet.