Chapter 20. Microsoft Exchange Server 2013

Introduction

Microsoft Exchange Server is Microsoft’s flagship messaging and collaboration server application. Exchange manages email messages through a proprietary MAPI protocol for rich use with Microsoft Outlook clients as well as the Internet standard protocols POP3, IMAP4, and SMTP. It is a scalable enterprise solution from gateway to mailbox with expected functionality including backup and recovery, message hygiene, and mailbox management. Several features that have evolved over the years are still present in the latest version, including Outlook Web App (OWA), Public Folders, cached Exchange mode, and mobile device synchronization with ActiveSync (the primary mechanism for Windows RT devices to communicate with Exchange. Other features have been added or improved significantly for 2013, such as a single unified management console, Data Loss Prevention (DLP), and OWA optimization for smartphones and tablets.

Exchange has a set of APIs that can be used to integrate custom applications or access specific Exchange data. Exchange can be an important component of a business collaboration system. We are not going to cover every single PowerShell cmdlet or all possible recipes for configuring Exchange, but we will introduce a good cross section of common tasks that Exchange implementers or administrators may need to perform their duties.

Exchange Server and Active Directory

Even with the major changes in Exchange, one of the mainstays over the past few versions is the use of Windows Active Directory as the Directory Services provider. Exchange 2000 Server was one of the first AD-aware applications. Indeed, AD is partly based on the Exchange directory used in Exchange 5.5 and earlier. Installing Exchange requires first extending the AD schema with Exchange-specific attributes. A successful implementation of Microsoft Exchange Server is dependent therefore on a successful implementation of Active Directory. In addition, Exchange routing is now dependent on AD Site topology instead of its own routing engine, as was present in 2003.

This deep integration also means that AD topology design should also consider Exchange messaging requirements. The AD and Exchange relationship also makes an Exchange chapter a suitable addition to this book.

Exchange Server 2013 Architecture

Microsoft has made significant changes to Exchange Server with Exchange 2013. Some of the architecture for the latest version is different from Exchange 2010 and other earlier versions, and as a result, so are the mechanisms for deploying and administering Exchange. Exchange 2013 requires Windows Server 2008 R2 or Windows Server 2012. Exchange 2013 has reverted some of the modularity found in Exchange 2010 by separating functionality into just two different server roles.

There are two Exchange roles to choose from at installation:

  • Client Access Server

  • Mailbox Server

Only the selected role(s) are installed. Other installation options include Clustered Mailbox Roles and the Management Tools. The roles can share residence on a single server or be placed on separate servers as part of a deployment strategy.

Exchange Server Tools

Exchange administration is shared between the Exchange Management Shell (EMS) and the Exchange Administration Center (EAC); however, the EAC is built upon the EMS. Every configuration performed in the console has an equivalent command-line entry using the shell.

Exchange Management Shell

As we have seen in the previous chapters, PowerShell revolutionizes the command-line experience in Windows. With Exchange 2013, there are more than 900 cmdlets to assist with Exchange management.

PowerShell uses an XML file as a console definition file to identify snap-ins to be loaded with PowerShell. For the EMS, this file is named exshell.psc1 and is called with the parameter -PSConsoleFile. The Exchange Management Shell is an extension of PowerShell. The shortcut for the EMS actually uses the following command:

C:WINDOWSsystem32windowspowershellv1.0powershell.exe -PSConsoleFile "C:Program FilesMicrosoftExchange Serverinexshell.psc1" -noexit -command ".'C:Program FilesMicrosoftExchange ServerinExchange.ps1'"

Exchange Administration Center

The EAC is a web-based management center that allows you to easily manage multiple Exchange servers. It is a graphical representation of underlying shell commands in the EMS. The EAC replaces the Exchange Management Console that existed in Exchange 2007 and Exchange 2010. The EAC allows you to manage the Exchange Server environment, regardless of whether it is a local on-premises installation, in the cloud, or in a hybrid Exchange deployment scenario.

The EAC can be accessed from a web browser by navigating to https://<CASServerName>/ecp.

Exchange Scripts Folder

Not to be overlooked in terms of Exchange administration is the scripts folder. Installed with Exchange Server, the folder includes several PowerShell scripts that can be used to easily make specific changes or that can be amended to customize components:

C:Program FilesMicrosoftExchange ServerV15Scripts

For example, in the scripts folder, there are PowerShell scripts to enable anti-malware scanning on a Mailbox server and to export Message Classifications for distribution to Outlook clients. Administrators can also add their own custom Exchange scripts to this folder as it is added to the Windows Path environment variable when Exchange is installed. It is not necessary, therefore, to remember the entire path to the scripts folder when executing scripts from the command line.

Third-Party Tools

Sometimes third parties create innovative utilities that can accomplish a task with greater ease than the native tools. There are numerous products, both free and commercially available, that can assist with Exchange management. joe Richards maintains several Active Directory and Exchange utilities through his website. A few tools that we use in this chapter, including ExchMbx, AdFind, and AdMod, are available as freeware.

Finding Exchange Server Cmdlets

Problem

You want to generate a reference list of all the Exchange Server cmdlets available in the Exchange Management Shell.

Solution

Using PowerShell

PowerShell has a cmdlet that can list all the available cmdlets in PowerShell or the EMS, called Get-Command. A subset of this cmdlet, called Get-ExCommand, returns only the cmdlets added to PowerShell with the installation of the EMS. To get a list of all the EMS cmdlets, execute the following cmdlet:

Get-ExCommand | FL Name,Definition >> c:ExCommandList.txt

This will generate a formatted list of all of the EMS cmdlets and their definitions in a text file on the C: drive.

Discussion

The purpose of the Get cmdlets is really to serve as a search and query tool. When specific cmdlet properties are designated, Get-Command will return only the cmdlets representing the filter properties requested. Get-ExCommand is actually Get-Command with a built-in filter for cmdlets, called Microsoft.Exchange.Management.PowerShell.Admin, that are part of the PSSnapin, which we know as the Exchange Management Shell. For example, we can show all EMS cmdlets with the word mailbox as part of the object, as follows:

Get-ExCommand *mailbox*

Preparing Active Directory for Exchange

Problem

You want to prepare your Active Directory forest and domains for the installation of your first Exchange server.

Solution

Using a graphical user interface

Exchange Server requires that the Active Directory forest schema be extended before installation. Exchange extends AD with new attributes. This step is done automatically through the GUI setup process. Running setup from the GUI therefore requires Schema Admin rights (in addition to Enterprise Admin and Domain Admin rights, which are discussed in more detail in Discussion).

There is no separate mechanism to apply schema extensions or prepare the domain independent of installing the Exchange Server binaries when using the GUI. This makes the GUI a reasonable option for smaller shops; however, larger businesses with division of administrative duties will certainly want to use the command-line option instead.

Using a command-line interface

Exchange Server uses Setup.exe at the root of the installation media to control aspects of preparation, installation, and even recovery. Setup.exe can be run from the command line with the appropriate parameters applied. The command line allows for easier separation of administrative duties based on permission level. The Exchange administrator may not have schema admin rights in AD. For AD preparation, there are several parameters to be applied in order.

/PrepareSchema

This switch updates the Active Directory schema by importing a set of .ldf files for Exchange.

/PrepareAD

This switch creates the Exchange configuration container in AD, creates the Exchange-related universal security groups (USGs), and applies the appropriate permissions. The /PrepareAD switch will also run the /PrepareSchema switch if it has not been run.

/PrepareDomain

This switch configures the necessary permissions and configuration of the domain in preparation for installation of Exchange Server.

/PrepareAllDomains

This switch prepares all the domains in the forest at once.

/IAcceptExchangeServerLicenseTerms

This switch is required for all command-line operations, and is required each time a command is issued.

/OrganizationName

This switch accepts input to specify the name of the Exchange organization. This switch has a 64-character limit, including letters, numbers, spaces, hyphens, and dashes.

/DomainController

This switch allows you to specify the domain controller that setup.exe will use to read from and write to Active Directory.

/ActiveDirectorySplitPermissions

This switch allows you to enable Active Directory split permissions mode when preparing the Active Directory topology.

This series of setup steps is sequential. The schema needs to be extended before AD is configured, and that must complete prior to the domains being prepared. Especially in a wide area topology, you should leave sufficient time in between steps to allow for AD replication between domain controllers.

Discussion

Microsoft Exchange will not run in an Active Directory forest unless the forest and the domain have been properly prepared. Microsoft did not make the assumption that everyone or every AD forest would use Exchange and therefore did not include all of the Exchange attributes and classes in the base Active Directory schema. The ability to dynamically extend the schema for Active Directory makes it possible to require only those people running Exchange to install the Exchange infrastructure and only in the AD forests where they need Exchange.

In addition to schema changes, you have to make security changes to Active Directory and the domain policy, as well as create some basic Exchange infrastructure objects. All of this is completed in the AD and Domain preparation processes for Exchange. Do not confuse these with the Active Directory ForestPrep and DomainPrep processes (using the adprep command); the concept is the same but the specific changes are different.

You need to run the PrepareSchema and PrepareAD processes once per forest to make the schema changes, create the Exchange organization structure in the Configuration container, and set up Exchange-specific permissions. We recommend that you create a security group in your root domain for this delegation. You could use a domain local group in a single domain forest in which you will never create another domain. In a multidomain forest, you must use a global group or a universal group. The group is used to assign rights to objects in the Configuration container. Whether you use a global or universal group is up to you—either will do the job.

You need to run the PrepareDomain processes in the root domain of the forest and for every domain that will contain mail-enabled objects. Normally, PrepareDomain is run on every domain in an Active Directory forest. The process creates Exchange security principals, modifies the domain security policy, creates some Exchange-specific infrastructure objects, and assigns permissions for Exchange-specific objects. The PrepareDomain processes require the person running the process to be a member of the Domain Admins group of the domain being prepared. Thankfully, Exchange Server has a /PrepareAllDomains switch allowing this step to be run once and have it apply to all accessible domains. However, when running the /PrepareAllDomains step, the person running the process must be a member of the Enterprise Admins group of the forest being prepared.

Due to the depth of changes made to the overall structure of Active Directory, the PrepareAD processes require Schema Admin and Enterprise Admin rights, and PrepareDomain requires Domain Admin rights. This usually prevents anyone but the centralized administration group responsible for the overall Active Directory forest from preparing the forest and domain(s) for Exchange.

For a more in-depth discussion of the Exchange deployment requirements, considerations, and specifics of what the preparation processes do, please see “Planning and Deployment”.

See Also

Chapters 7 and 11 for more on groups and the AD schema

Installing the First Exchange Server 2013 Server in an Organization

Problem

You want to install the first Exchange server for a new Exchange organization.

Solution

Using a graphical user interface

  1. Log on to a server that is a member of an Exchange-prepared domain with an account that is a member of the delegated group in Preparing Active Directory for Exchange.

  2. From the Exchange 2013 media, launch setup.exe.

  3. Choose whether to check and download updates or continue without checking, and then click Next.

  4. Click Next on the Introduction screen.

  5. On the License Agreement screen, read through the agreement, and if you agree, click “I accept the terms in the license agreement” and click Next.

  6. On the error reporting screen, select the desired error reporting setting and then click Next.

  7. Select the Exchange Server roles for this installation by placing a checkmark next to the roles you wish to install, and then click Next.

  8. If necessary, specify a different path for the Exchange Server installation. Or, accept the default and then click Next.

  9. As the first Exchange server in a new organization, enter the new organization name. This value cannot be changed later. Place a checkmark in the Apply Active Directory split permissions security model to the Exchange organization if needed, and then click Next.

  10. The next screen asks whether you would like to enable malware scanning. Malware scanning is enabled by default; if you would like to disable it, click Yes, and then click Next.

  11. Setup works through a set of Readiness Checks. Click Install if there are no issues to correct.

  12. Installation progress is shown in the GUI; when it is done, the Completion screen will be presented. Click Finish to close the window.

Using a command-line interface

You can also install Exchange Server from the command line. Setup.exe, found in the root of the Exchange Server installation media, has several switches to break down installation into its components. We already covered the preparatory switches in Preparing Active Directory for Exchange. The other command-line switches for setup.exe are shown in the following list. Note that setup.com, used with previous versions of Exchange, is now part of setup.exe.

/Mode

The mode for setup.exe identifies whether you are performing an install, uninstall, or recovery. The default mode is Install.

/Roles

These are the main roles that you can select for a custom installation in the GUI. The roles are Mailbox, Client Access, and Management Tools.

/OrganizationName

This value is required for the first Exchange server in a new organization.

/IAcceptExchangeServerLicenseTerms

This switch is required for all command-line operations, and is required each time a command is issued.

/TargetDir

This is the destination directory for binary installation. By default, this is found in %ProgramFiles%MicrosoftExchange Server.

/DomainController

This switch allows you to specify the domain controller that setup.exe will use to read from and write to Active Directory.

/AnswerFile

Setup is directed to a text file with preset properties to apply during installation.

/DoNotStartTransport

This switch prevents Exchange Server from automatically routing email when it first starts. This is usually used in case there is additional software to install or configure before Exchange is enabled.

/CustomerFeedbackEnabled

As we saw in the GUI, Microsoft is interested in making the product better by automating error reports submitted to the company. This is optional, and the default is set to True.

/DisableAMFiltering

This option disables the Exchange server anti-malware feature.

/InstallWindowsComponents

This option installs all required Windows Server roles and features.

/OrganizationName

This switch accepts input to specify the name of the Exchange organization. This switch has a 64-character limit, including letters, numbers, spaces, hyphens, and dashes.

/UpdatesDir

This switch specifies the directory in which Exchange Server updates are located and will be installed during installation.

/ActiveDirectorySplitPermissions

This switch allows you to enable Active Directory split permissions mode when preparing the Active Directory topology.

/DbFilePath

This switch allows you to specify the full directory path for the mailbox database if the Mailbox server role is installed.

/LogFolderPathUse

This switch allows you to specify the full directory path for the mailbox database logfiles if the Mailbox server role is installed.

/MdbName

This switch allows you to specify the Mailbox server role database name.

/TenantOrganizationConfig

This switch allows you to specify the file that contains the configuration for an Office 365 tenant.

For example, to install the Mailbox and Client Access roles on a new server run:

setup.exe /Mode:Install /Roles:Mailbox,ClientAccess /IAcceptExchangeServerLicenseTerms /InstallWindowsComponents

Using PowerShell

For small installations, PowerShell does not offer great benefits for running the setup. Setup.exe can be run from a classic command prompt or a PowerShell prompt. For larger organizations, especially with multiple simultaneous Exchange Server installations, PowerShell affords some opportunities to simplify the process, such as identifying Exchange servers on the network based on specific hostname policies or confirming target directory availability.

Discussion

If this is the first Exchange server in a new organization, additional parameters are needed at installation. For example, the administrator must specify a name for the new Exchange organization.

The Exchange installation has a few prerequisites before installing on Windows Server 2012, which are presented in the UI as follows:

  • Microsoft Unified Communications Managed API 4.0, Core Runtime 64-bit

  • Microsoft Office 2010 Filter Pack 64 bit, with SP 1

A Custom installation provides us with the opportunity to select individual roles or a combination. The Management Tools are listed as a separate option, but they are automatically installed with any of the other roles. They are listed separately for installation on an administration client computer or on a server.

Exchange performs readiness checks based on the roles selected. Should a readiness check fail, the offending situation must be resolved and, if you’re using the GUI, the setup must be restarted.

See Also

The deployment section of the Exchange Server technical library

Creating Unattended Installation Files for Exchange Server

Problem

You want to create an unattended installation file to minimize the administrative effort of installing several Exchange servers while also ensuring a consistent deployment across servers.

Solution

Using a command-line interface

Exchange 2013 can be installed in unattended mode simply using the command-line setup options. Some of the setup.exe switches can be listed within a text file that in turn is called by the /AnswerFile parameter. The setup.exe switches that can reside in an unattended installation answer file are TargetDir, SourceDir, UpdatesDir, DomainController, MdbName, LogFolderPath, and more. See the full list of switches mentioned previously in the chapter. These switches are listed in a text file without the backslash and are saved as a text file such as UnattendParams.txt.

Setup.exe references the answer file as follows:

Setup.exe /Mode:Install /Roles:ClientAccess,Mailbox↵
 /AnswerFile:C:UnattendParams.txt

Discussion

Using unattended installation is a great way to install Exchange on many servers, deploy the Exchange tools to many admin workstations, update service packs for Exchange on many servers, or maintain consistency in installation configurations.

To see a complete list of options, run the setup or update executable with the /? option. In Exchange 2010, the parameter is /AnswerFile and is formed using parameters available with Setup.com. After you create an unattended installation answer file, you can use it to install additional Exchange servers.

See Also

Installing Exchange Management Tools for more on installing the Exchange Management Tools; “Install Exchange 2013 Using Unattended Mode”

Installing Exchange Management Tools

Problem

You want to install Exchange Management Tools onto a client computer or onto a server that isn’t running Exchange.

Solution

Using a graphical user interface

  1. Follow the standard installation steps outlined in Installing the First Exchange Server 2013 Server in an Organization, except bypass the step that creates a new organization.

  2. Select the defaults for the remainder of the installation and complete the wizard.

Using a command-line interface

Setup.exe provides a switch to select the roles to install. The ManagementTools or MT role is one of the options. After the prerequisites are applied, the Exchange Management Tools can be installed as follows:

setup.exe /Mode:Install /Role:ManagementTools /IAcceptExchangeServerLicenseTerms

Discussion

Installing the Exchange Management Tools on a client computer or on a server that is not running Exchange Server is an alternative to using Remote Desktop administration of Exchange. The tools install the following components:

  • Exchange Administration Center

  • Exchange Management Shell

  • Exchange Help files

Exchange Management Tools are supported on Windows 7 64-bit, Windows 8 64-bit, Windows Server 2012, and Windows Server 2008 R2. Windows 7 installations require the IIS 6 Management Console, as well as .NET Framework 4.5, Windows Management Framework 3.0, and Windows Identify Foundation. The Windows 7 prerequisites must be installed in that order.

See Also

Creating Unattended Installation Files for Exchange Server for more on unattended installation

Stopping and Starting Exchange Server

Problem

You want to stop or start Exchange Server.

Solution

Using a graphical user interface

  1. Launch the Services management console (services.msc).

  2. Locate the services that begin with “Microsoft Exchange.”

  3. Right-click the service and select the appropriate action.

Using a command-line interface

To start a service using the command line, issue the following command:

net start "<ServiceName>"

To stop a service using the command line, issue the following command:

net stop "<ServiceName>"

Using PowerShell

Stopping and starting Exchange Server services is a little easier because almost every service has the term Exchange in its name. For a list of all of the services on the server with Exchange in their display name, issue the following command:

Get-Service *Exchange* | FT Name, Status

Note

PowerShell will return the services in alphabetical order. The results can be further piped to the Sort-Objects cmdlet to control how the list is presented.

To start an Exchange service using PowerShell, use the following command:

Start-Service "<ServiceName>"

To stop services that are running and have Exchange in the display name, use the following command:

Get-Service *Exchange* | Where {$_.Status -eq "Running"} | Stop-Service

Discussion

Several services are involved with Exchange Server, and stopping different services will accomplish different things. Typically, it is not necessary to stop services manually. The services are interdependent, so when you stop or start various services, you may see a message about having to stop dependent services. If you do stop dependent services, don’t forget to restart them again when you restart the service that you began with.

Note

Different servers could be running a combination of different services based on the complexity of the environment and the specific function of the server. Not all Exchange servers will run all Exchange services.

For the long list of Exchange Server services, see Table 20-1.

Table 20-1. Exchange services

Exchange service

Description

Microsoft Exchange POP3 (MSExchangePOP3)

Supplies POP3 protocol message server functionality. This is available only on a Client Access Server.

POP3Backend (MSExchangePOP3BE)

Runs on Exchange servers with the Mailbox role installed and is required when POP3 is being used to access Exchange.

Microsoft Exchange IMAP4 (MSExchangeIMAP4)

Supplies IMAP4 protocol message server functionality. This is available only on a Client Access Server.

IMAP 4 Backend (MSExchangeIMAP4BE)

Runs on Exchange servers with the Mailbox role installed and is required when IMAP is being used to access Exchange.

Microsoft Exchange Information Store (MSExchangeIS)

Is used to access the Exchange mail and public folder stores. If this service is not running, users will not be able to use the Exchange server.

Microsoft Exchange Active Directory Topology (MSExchangeADTopology)

Queries Active Directory and returns configuration information and other data.

Anti-spam Update service (MSExchangeAntiSpamUpdate)

Automatically downloads anti-spam filter updates from Microsoft.

Mailbox Assistants (MsExchangeMailboxAssistants)

Manages the calendar, resource booking, Out-of-Office, and managed folder assistants.

Monitoring (MSExchangeMonitoring)

Allows diagnostics using an RPC server.

Replication (MSExchangeRepl)

Performs replication services for highly available environments.

Transport (MSExchangeTransport)

Manages SMTP.

Transport Log Search (MSExchange-TransportLogSearch)

Powers the Message Tracking functionality in Exchange.

Unified Messaging (MSExchangeUM)

Manages the Unified Messaging engine for Outlook Voice Access.

Mailbox Transport Delivery (MSExchangeDelivery)

Relays messages from the Transport service to the respective mailbox by using a remote procedure call (RPC).

Diagnostics (MSExchangeDiagnostics)

Monitors the Exchange server health.

Search (MSExchangeFastSearch)

Handles indexing and search queries for the Exchange server.

Frontend Transport (MSExchangeFrontEndTransport)

Relays SMTP connecting to and from hub servers.

Health Manager (MSExchangeHM)

Manages the Exchange server health.

Mailbox Replication (MSExchangeMailBoxReplication)

Manages and processes mailbox move requests.

RPC Client Access (MSExchangeRPC)

Manages client RPC connections for Exchange Server.

ServiceHost (MSExchangeServiceHost)

Manages services for applications.

Mailbox Transport Submission (MSExchangeSubmission)

Runs on Mailbox servers and processes messages by converting from MAPI to MIME, and then relays them to the hub transport server.

Throttling (MSExchangeThrottling)

Limits the rate of user operations that could affect Exchange performance.

Unified Messaging Call Router (MSExchangeUMCR)

Enables the Unified Messaging Call Router features.

Tracing Service for Search (SearchExchangeTracing)

Enables trace logs for searching in Exchange Server.

Extension for Windows Server Backup (wsbexchange)

Allows Windows Server Backup to perform backup and recovery operations for Exchange Server.

Mail-Enabling a User

Problem

You want to mail-enable an existing user.

Solution

Using a graphical user interface

  1. Sign in to the Exchange Administration Center (EAC). To launch the EAC, open a web browser and navigate to https://<CASServerName>/ecp.

  2. From the Recipients screen, click Contacts on the top menu.

  3. Click the arrow on the plus sign (+) and then click “Mail user.”

  4. Ensure that the existing user is selected. Click Browse and select the user account to create the mailbox for, and then click OK.

  5. Enter a unique alias for the mailbox and an external email address, and then click Save.

This entry now represents a mail-enabled user. This user does not have a mailbox. The external SMTP address we entered can be seen in the E-mail Addresses tab in the user properties looking from the EAC. The mail-enabled user can be found in the Recipients Configuration container in the Mail Contacts folder, and this entry represents the primary SMTP address in the multivalued attribute called proxyAddresses.

Using PowerShell

This is one of those tasks that is simple on the surface but makes significant changes beneath. PowerShell and Exchange Server reduce mail-enabling an existing user to a simple one-line cmdlet:

Enable-MailUser -Identity "<user_ID_parameter>" -Alias "<Alias_Name>"↵
-ExternalEmailAddress "<SMTP:proxy_SMTP_Address>"

An example of the cmdlet might look like this:

Enable-MailUser -Identity 'adatum.com/Users/Elias Mereb' -Alias 'Elias'↵
-ExternalEmailAddress 'SMTP: [email protected]'

Discussion

With Exchange Server, these controls are available in the Exchange Administration Center (EAC) and the Exchange Management Shell (EMS). The Enable-MailUser cmdlet mail-enables an existing user; however, the EAC can also be used to configure new users. Note that while a mail-enabled user is similar to a mail-enabled contact, the key difference is that a mail-enabled user can log on to Active Directory and access resources, whereas a mail-enabled contact cannot log on to Active Directory.

Mail-Disabling a User

Problem

You want to mail-disable a user.

Solution

Using a graphical user interface

  1. Sign in to the EAC

  2. From the Recipients screen, click Contacts from the top menu.

  3. Select the user to mail-disable.

  4. Click the arrow next to the trashcan icon and then click Disable.

  5. Select Yes to confirm.

The mail-disabled user then disappears from the Recipient Contact container view; however, it still resides as a regular user in AD, stripped of the Exchange properties.

Using PowerShell

The cmdlet to mail-disable a user is as follows:

Disable-MailUser -Identity "<user_ID_parameter>"

An example of the cmdlet might look like this:

Disable-MailUser -Identity "Elias Mereb"

or:

Disable-MailUser "[email protected]"

The -Identity parameter can use the Distinguished Name, the User Principal Name, the DomainAccount name, the GUID, or other identifying information (see TechNet for a complete list). This cmdlet also only removes the Exchange properties for the user; it does not remove the user from AD. Because it is a significant change, there is a confirmation step after entering the preceding code. The administrator will be prompted to complete the action, requiring a Yes, Yes to all, No, No to all, Suspend, or Help. This prompt can be suppressed or selected by assigning one of those values in the original cmdlet by using the -Confirm parameter.

Discussion

This recipe removes the Active Directory Exchange attributes for a previously mail-enabled user. This is a simple process from EAC or PowerShell, but behind the scenes, several attributes are being updated.

Mail-disabling a user requires Exchange View-Only Administrator or higher permissions, as well as Read and Write permissions to a number of object attributes. See the Microsoft Exchange Tech Center on the Microsoft website for a list of all necessary attributes.

See Also

Installing Exchange Management Tools; Mail-Enabling a User for more on mail-enabling a user

Mailbox-Enabling a User

Problem

You want to create a mailbox for a user. This is also known as mailbox-enabling a user.

Solution

Using a graphical user interface

  1. Sign in to the EAC by navigating to https://<CASServer>/ecp.

  2. From the Mailboxes screen, click the plus sign (+).

  3. Enter a unique alias for the mailbox.

  4. Select whether this is a new user or whether to add a mailbox for an existing Active Directory user.

  5. If enabling a mailbox for an existing user, click Browse and select the user. Click OK and then Save.

  6. If creating a new user, click the “new user” radio button.

  7. Complete the new user information form and then click Save.

Using PowerShell

In the EMS, we use the Enable-Mailbox cmdlet to apply the appropriate Exchange attributes to an existing user. A mailbox has to have an associated storage location, which is the message store where it will reside:

Enable-Mailbox -Identity "<User_ID_Parameter>" -Alias "<Name>" -Database "<DatabaseName>"

An example of this cmdlet might read as follows:

Enable-Mailbox -Identity "Alberto Contador" -Alias "Alberto" -Database "DB01"

To mailbox-enable a group of users, this command can be piped from a Get-User filter parameter as well:

Get-User -RecipientType User | Enable-Mailbox -Database "Mailbox Database"

This command retrieves all users with the Recipient Type of User and mail-enables them. After Enable-Mailbox is successfully applied to an object, the Recipient Type will show as UserMailbox.

If you have a set of users within an OU that need to be mailbox-enabled, it is just a matter of applying a different filter parameter to the Get-User cmdlet:

Get-User -OrganizationalUnit "Sales" | Where-Object{$_.RecipientType -eq "User"} | Enable-Mailbox -Database "DB01"

Discussion

A mailbox-enabled user is a user object that has a mailbox defined in the Exchange organization that the user object exists in. This is one of the most common objects in an Exchange organization.

Note

Mailbox-enabling a user requires Exchange View-Only Administrator or higher permissions, as well as Read and Write permissions to a number of object attributes. See the Microsoft Exchange Tech Center on the Microsoft website for a list of all necessary attributes.

When you create a mailbox for a user, in the background, the specific changes occur on the user object in Active Directory and include changes to the following attributes:

  • mDBUseDefaults

  • msExchUserAccountControl

  • homeMTA

  • msExchHomeServerName

  • homeMDB

  • mailNickname

  • msExchMailboxGuid

  • msExchMailboxSecurityDescriptor

  • legacyExchangeDN

  • mail

  • msExchPoliciesIncluded

  • msExchRecipientDisplayType

  • msExchRecipientTypeDetails

  • msExchVersion

  • proxyAddresses

  • showInAddressBook

You can view the attributes before and after the Enable-Mailbox cmdlet is run to see the different attributes of the object to which values have been added. Right-click on the user in the Active Directory Administrative Center and select properties and then scroll down to the Attribute Editor. Click on the Filter button and enable “Show only attributes that have values” to display the attributes in use for that user object. Doing this before and after engaging the Enable-Mailbox cmdlet will allow you to visualize the changes.

Deleting a User’s Mailbox

Problem

You want to delete a user’s mailbox. This is also known as mailbox-disabling a user.

Solution

Using a graphical user interface

  1. Sign in to the EAC by navigating to https://<CASServer>/ecp.

  2. From the Recipient screen, select the user to mailbox-disable.

  3. Click the arrow next to the trashcan icon and click Disable.

  4. Select Yes to confirm.

This process disconnects the mailbox from the user object by removing the Exchange-specific attributes. In the EAC drop-down, there is the option to Disable and also Delete. The latter will disconnect the mailbox and also delete the user from AD.

Using PowerShell

Disable-Mailbox -Identity <User_ID_Parameter>

A basic example might be:

Disable-Mailbox [email protected]

As with the some other cmdlets, the -Identity parameter is assumed and does not need to be typed out in the command as long as it is the first parameter after the cmdlet. The mailbox for will be disconnected from the user.

To delete mailboxes from a set of users, just pipe the output of a Get-Mailbox filter to the Disable-Mailbox cmdlet, similar to the examples in Mailbox-Enabling a User.

Discussion

Although the recipe title is “Deleting a User’s Mailbox,” these solutions don’t really delete the mailbox. They actually just clear the Exchange attributes from the user object, and that disassociates the mailbox from the user; the mailbox itself will still exist in the Exchange store. The length of time it will exist depends on the mailbox retention period, which is 30 days by default. While the mailbox exists in that state, it can be reconnected to the same or a different user object.

Note

Deleting a user requires Exchange View-Only Administrator or higher permissions, as well as Read and Write permissions to a number of object attributes. See the Microsoft Exchange Tech Center on the Microsoft website for a list of all necessary attributes.

Moving a Mailbox

Problem

You want to move a mailbox to a new database or server.

Solution

Using a graphical user interface

  1. Sign in to the EAC by navigating to https://<CASServer>/ecp.

  2. From the Recipients screen, select the mailbox that you want to configure.

  3. From the right panel, scroll to the bottom, and under Move Mailbox, click “to another database.”

  4. Name the migration job and then select whether to move the primary mailbox, archive mailbox, or both.

  5. For the target database, click Browse and select the database that you want to move the mailbox to. Repeat the process for the archive database, if necessary, and then click Next.

  6. If necessary, change the batch report recipient by clicking Browse and then selecting a user.

  7. Choose whether to automatically or manually start the batch, and whether to automatically complete the migration, and then click New.

  8. To view the migration job, click Migration from the top menu.

  9. Double-click the job name from the list to view the progress or results.

Using PowerShell

There is a simple PowerShell command to accomplish the same feat. The command to move a mailbox is as follows:

New-MoveRequest "<Mailbox>" -TargetDatabase "<MailboxDB>"

An example of such a move might be:

New-MoveRequest "User5" -TargetDatabase "DB02"

Again, the -Identity parameter is assumed, so typing the actual parameter is optional. There are many times where you will have to move groups of mailboxes to new storage or a new database. There are several ways of accomplishing this. The easiest is probably to pipe the output from a Get-Mailbox cmdlet with the appropriate filters to the New-MoveRequest cmdlet. For example:

Get-Mailbox | Where {$._<Property> -eq "<Value>"} | New-MoveRequest -TargetDatabase "<Database>"

You can also assemble the mailboxes in an array that PowerShell can loop through using a foreach command. This works well if the array is loaded at the beginning of the script. If not, the mailboxes are then moved in serial—the next mailbox isn’t moved until the previous one is completed. That is not the most efficient method. The array itself can be piped to the New-MoveRequest cmdlet to work through the items in a multithreaded fashion:

$array = "UserA","UserB","UserC","UserD","UserE"
$array | New-MoveRequest -TargetDatabase <Database> -Confirm:$false

The source can also be a CSV file with a list of usernames and the intended destination store for their mailbox. These are the two required values for the New-MoveRequest cmdlet. If all the mailboxes are to be moved to the same destination database, then the target database is best specified as part of the cmdlet and not pulled from the CSV for each mailbox. The Import-CSV cmdlet calls the .csv file by name and pipes the output to the New-MoveRequest command.

Assuming we have a .csv file with a column heading of Username and the users with mailboxes to be moved are listed in the column, then we can import those values and move their mailboxes as follows:

Import-CSV <file_name>.csv | foreach {New-MoveRequest -Identity $_.Username -TargetDatabase <Database> -Confirm:$false}

Discussion

Mailbox moves are commonly performed in many Exchange organizations due to servers getting upgraded, server hardware issues, users changing locations, or if the administrators want to readjust the mailbox location for load distribution.

Moving a mailbox in Exchange requires Read and Write permissions to the following attributes:

  • msexchhomeservername

  • homemdb

  • homeMTA

  • msExchOmaAdminWirelessEnable

  • msExchOmaAdminExtendedSettings

  • targetAddress

Warning

A mailbox move is an odd operation in terms of permissions. Logically, moving a mailbox is basically a combination of create and delete operations, which is something a typical Exchange administrator has permissions to do. See MS KB 842033 for details of the permissions needed.

Using a graphical user interface

The new Local Mailbox Move Wizard allows you to perform the move(s) immediately or at some point later (by manually starting the move[s] later). This is obviously a handy feature for mailbox moves because it isn’t something you tend to want to do in the middle of the day. This allows Exchange administrators who like to sleep at night to schedule the work to be done and then go home with everyone else.

Using PowerShell

After a move, you may notice that the source mailbox is in a disconnected state. This is helpful in the case of an unsuccessful move or a problem with the new destination mailbox. The disconnected mailbox can be removed by using the Remove-StoreMailbox cmdlet, or it will automatically be removed based on the retention period. There are several ways to perform this task using PowerShell, depending on the number of mailboxes to move. Looping through an array, importing a CSV file, and applying a cmdlet filter and piping the result to the New-MoveRequest command are all good options.

Like the other solutions, PowerShell does not have a mechanism to migrate the recoverable items folder. This is a consideration for companies that require access to the recoverable items folder for compliance reasons. You may need to keep the last backup available prior to the mailbox move.

Viewing Mailbox Sizes and Message Counts

Problem

You want to view the sizes and message counts of all mailboxes on a server.

Solution

Using PowerShell

Again, this is another scenario where the EMS simplifies Exchange management. An important reporting cmdlet for mailbox reporting is Get-MailboxStatistics. It quantifies mailbox size, item count, last logon time, and more. (See this recipe’s for the list.) To get summary statistics for a specific server, run the following:

Get-MailboxStatistics -Server <Server_name>

This lists the mailboxes and their size and message counts on the server specified. Data is easily sorted in ascending or descending order by any value in the Get-MailboxStatistics output. For example, to sort the list by mailbox size and easily identify the largest mailboxes, we can use:

Get-MailboxStatistics -Server <Server_name> | Sort-Object StorageLimitStatus-Descending | FT

Administrators often need to act on this information and need it in a timely manner. It is easy to write this information to a file and attach it to a scheduled email using a PowerShell script.

This script assigns parts of the email message to variables, collects the data with Get-MailboxStatistics values, writes the report to a .txt file, and attaches it to an email to the administrator. It specifies only a Recipient Type of UserMailbox, which is a mailbox-enabled user. This also requires that the sending SMTP server can relay for the host sending the request:

$FromAddress = "[email protected]"
$ToAddress = "[email protected]"
$MessageSubject = "Daily Mailbox Size Report"
$MessageBody = "The Daily Mailbox Size Report is attached."
$SendingServer = "EX01"

Get-MailboxStatistics -Server "EX01"| Sort-Object StorageLimitStatus -Descending | FT DisplayName, ItemCount | Out-File "C:	empmbxreport.txt"

Send-MailMessage -To $ToAddress -From $FromAddress -Subject $MessageSubject -SmtpServer $SendingServer -Body $MessageBody -Attachments "C:	empmbxreport.txt"

Save the script as a PowerShell file such as MbxReportSend.ps1 and schedule it to run every morning so that it is sitting in your inbox when you get to the office.

Discussion

Mailbox sizes and message counts are items on Exchange systems that administrators routinely want to know about for the purposes of reporting and metrics. Administrators want to know whether their mail system is balanced and whether users are spread across the mailbox stores evenly. Knowing the number of users and the size of their mailboxes in each mailbox store, the administrator can make better decisions about where new user mailboxes should be placed or if some leveling of mailboxes is required.

Using PowerShell

The Get-MailboxStatistics cmdlet is a powerful reporting resource. It can be used as a standalone command to review a snapshot of mailbox properties, or it can be used as a filter for other queries. The output can be saved on a regular basis to compare values over time and identify trends of how users leverage their mailboxes.

By running the cmdlet with the Format List option at the end, the full set of variables captured by Get-MailboxStatistics is displayed:

Get-MailboxStatistics "user5" | FL

RunspaceId                       : 2d75e969-834f-4eee-9897-73cdd0f4abb8
AssociatedItemCount              : 12
DeletedItemCount                 : 0
DisconnectDate                   :
DisconnectReason                 :
DisplayName                      : User5
ItemCount                        : 3
LastLoggedOnUserAccount          :
LastLogoffTime                   :
LastLogonTime                    : 12/26/2012 1:41:24 AM
LegacyDN                         : /o=AdatumExchange/ou=Exchange Administrative                                   Group
                                   (FYDIBOHF23SPDLT)/cn=Recipients/cn=60f0b069318                                   a4edca0b06bfe11b9170d-User5
MailboxGuid                      : 4ea903e2-fd9d-49ec-9ae8-b51dd0015a05
MailboxType                      : Private
ObjectClass                      : Unknown
StorageLimitStatus               :
TotalDeletedItemSize             : 0 B (0 bytes)
TotalItemSize                    : 829.94 MB (870,255,165 bytes)
MailboxTableIdentifier           :
Database                         : MailboxDB2
ServerName                       : EX01
DatabaseName                     : MailboxDB2
MoveHistory                      :
IsQuarantined                    : False
PersistableTenantPartitionHint   : 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-                                   00
IsArchiveMailbox                 : False
IsMoveDestination                : False
DatabaseIssueWarningQuota        : 1.899 GB (2,039,480,320 bytes)
DatabaseProhibitSendQuota        : 2 GB (2,147,483,648 bytes)
DatabaseProhibitSendReceiveQuota : 2.3 GB (2,469,396,480 bytes)
Identity                         : 4ea903e2-fd9d-49ec-9ae8-b51dd0015a05
MapiIdentity                     : 4ea903e2-fd9d-49ec-9ae8-b51dd0015a05
OriginatingServer                : ex01.adatum.com
IsValid                          : True
ObjectState                      : Unchanged

Any of these output values can be used to filter another cmdlet or be saved to file or database for reporting over time. The LastLogonTime is valuable in identifying stale mailboxes that have not been archived and deleted. Be wary of the LastLogonTime if you have third-party software (such as archiving software) that logs on to mailboxes, as the date and time may not be accurate.

Configuring Mailbox Limits

Problem

You want to enable storage limits for user mailboxes on an Exchange server.

Solution

Using a graphical user interface

To configure storage quota settings on a database, follow these steps:

  1. Sign in to the EAC by navigating to https://<CASServer>/ecp.

  2. Navigate to Servers→Databases.

  3. Double-click the database that needs to have quota limits changed.

  4. Click on the Limits link.

  5. Set the values for the storage quota.

To configure storage quota settings on a mailbox, follow these steps:

  1. Open the EAC by navigating to https://<CASServer>/ecp.

  2. Double-click the mailbox that needs to have quota limits changed.

  3. Click on the “Mailbox usage” link.

  4. Click “More options,” and then select “Customize the settings for this mailbox.”

  5. Set the storage quota values as required for the user.

Using PowerShell

To set the different quota levels on a database, use the following command:

Set-MailboxDatabase "<Database>" -IssueWarningQuota "<Value>" -ProhibitSendQuota "<Value>" -ProhibitSendReceiveQuota "<Value>"

An example of this command is as follows:

Set-MailboxDatabase "DB01" -IssueWarningQuota "3GB" -ProhibitSendQuota "4GB" -ProhibitSendReceiveQuota "5GB"

To set the different quota levels on a mailbox, use the following command:

Set-Mailbox "<MailboxAlias>" -UseDatabaseQuotaDefaults <$true|$False>-IssueWarningQuota  "<Value>" -ProhibitSendQuota "<Value>" -ProhibitSendReceiveQuota "<Value>"

Discussion

It’s not uncommon for administrators to want to set reasonable size limits on individual users’ mailboxes. You can configure this globally at the mailbox store level. Since you can have multiple stores on a single server, this allows you to create multiple stores with multiple storage limits for departments or groups that have greater storage needs. You can also override the mailbox store defaults for individual user accounts by programmatically modifying the same three attributes and then setting the mdBUseDefaults attribute to FALSE. In Exchange Server, this is an EMS parameter on the Set-Mailbox cmdlet called -UseDatabaseQuotaDefaults. The following explains each quota setting and its default values:

“Issue warning at”

Warns users that they have exceeded the storage limit, but their mailbox will continue to function. The default value is 1.9 GB.

“Prohibit send at”

Warns users that they have exceeded the storage limit and then prevents them from sending new messages until their mailboxes are brought back underneath the configured storage limit. Users can still receive messages. The default value is 2 GB.

“Prohibit send and receive at”

Warns users that they have exceeded the storage limit and then prevents them from both sending and receiving messages until they have corrected the situation. The default value is 2.3 GB.

You can set the quota values using PowerShell to KB, MB, GB, or even TB. The quota levels are relative to each other. The IssueWarningQuota value should not be greater than the ProhibitSendQuota value, which in turn should not be greater than the ProhibitSendReceiveQuota value.

Creating an Address List

Problem

You want to create an address list.

Solution

Using a graphical user interface

  1. Sign in to the EAC by navigating to https://<CASServer>/ecp.

  2. Navigate to Organization→Address lists.

  3. Click the plus sign (+) to create a new address list.

  4. Enter a name for the new list.

  5. Select the container for the address list.

  6. If necessary, identify the recipient types to include in this address list.

  7. To further define the recipient list, click “add a rule” and then select the attribute from the drop-down list.

  8. Click Save to create the new address list.

Using PowerShell

There is a simple cmdlet for creating address lists in Exchange Server, as follows:

New-AddressList -Name "<AddressList_Name>" -Container "<AddressListIDParameter>"-IncludedRecipients

Here is an example of this cmdlet creating a new address list container named Regions:

New-AddressList -Name "Regions" -Container "" -IncludedRecipients "None"

In addition, there is an Update-AddressList to generate members independent of list creation or to apply any changes in list membership:

Update-AddressList -Identity "<AddressListIDParameter>"

A custom address list placed in the new Regions container based on a state, in this case Nevada, might read as follows:

New-AddressList -Name "Nevada" -IncludedRecipients "MailboxUsers, MailContacts, MailGroups, MailUsers" -ConditionalStateOrProvince "NV" -Container "Regions"

After the list is created, it needs to be applied. This is done with a separate command as follows:

Update-AddressList -Identity "RegionsNevada"

Discussion

Address lists are special groupings of email accounts that allow users to quickly find specific email users that are part of some logical grouping in the GAL. In essence, they are a subset of the GAL. Exchange Server provides some precanned address lists and allows for more complete Opath filter creation with the Recipient Filter option.

Address lists should employ friendly and descriptive names, as they are options for users to query in finding other users through Outlook. In addition, address lists should be added after consideration. Too many address lists can confuse users as to which one they should be using.

Using a graphical user interface

Using the GUI for this process is straightforward and is the most likely way you’ll want to create address lists unless you need to create a lot of them on the fly or you are importing them from a test lab.

Using PowerShell

There is a set of cmdlets to manage address lists in Exchange Server. First the New-AddressList cmdlet is used to create the list. Subsequently, Update-AddressList is used to populate the address list or specifically apply the filters and build the list, and even schedule when it should be updated. For larger enterprises with tens of thousands or hundreds of thousands of Active Directory recipients, address list generation is not trivial.

Creating a Database Availability Group

Problem

You want to create a new Database Availability Group (DAG) for automatic database-level recovery.

Solution

Using a graphical user interface

  1. Sign in to the EAC by navigating to https://<CASServer>/ecp.

  2. Navigate to Servers→Database Availability Groups.

  3. Click the plus sign (+) to open the new DAG window.

  4. Enter a name for the DAG.

  5. If you would like a specific server to be the witness server, specify it in the Witness Server field; otherwise, leave it blank.

  6. If you need to designate a specific directory for the witness server, specify it in the Witness Directory field; otherwise, leave it blank.

  7. Enter one or more IP addresses to be used for the DAG. Leave this field blank to use DHCP.

  8. Click Save to create the DAG.

Using PowerShell

New-DatabaseAvailabilityGroup -Name "<DAGName>" -WitnessServer "<ServerName>"

An example of this command might be as follows:

New-DatabaseAvailabilityGroup -Name "DAG01" -WitnessServer "EX01"

Discussion

Database Availability Groups (DAGs) are used to automatically recover at the database level, regardless of whether the failure is database-, server-, or network-related. In addition, DAGs are useful for supporting server maintenance because they allow administrators to perform maintenance without causing downtime for users. Mailbox servers are added to a DAG to provide automatic recovery. A common deployment for a DAG provides high availability at the primary data center and disaster recovery capability at a remote site (often a DR site). You can add up to 16 Exchange mailbox servers to a DAG. If you plan to create a DAG in an environment where there are still Windows Server 2008 R2 domain controllers, you must pre-stage the object in Active Directory. For more information, see the TechNet article “Pre-Stage the Cluster Network Object for a Database Availability Group”.

The witness server parameter for both the GUI and the PowerShell solutions is optional. By default, the witness server is applied only on an Exchange server with the Client Access Server role installed, but not the Mailbox Server role. This can be overridden by specifying the witness server manually.

Creating a Mailbox Database

Problem

You want to create a mailbox database.

Solution

Using a graphical user interface

  1. Sign in to the EAC by navigating to https://<CASServer>/ecp.

  2. Navigate to Servers→Databases.

  3. Click the plus sign (+) to add a new database.

  4. Assign the mailbox database a relevant name.

  5. Click Browse and select the server to create the database on.

  6. The default database file path is generated. Choose whether to mount the new database.

  7. Click Save to create the database.

Using PowerShell

Here is the command for creating a new mailbox database:

New-MailboxDatabase -Name <Name_ID_Parameter> -Server <ServerName>

An example of this command is as follows:

New-MailboxDatabase -Name "DB07" -Server "EX01"

A final step for the PowerShell-generated database is to mount it if needed:

Mount-Database "DB07"

Discussion

Mailbox databases are where mailboxes are located. There are quite a few configuration settings for mailbox databases that are beyond the scope of this chapter, but going through the EAC when manually creating a mailbox store should give you an idea of what can be configured.

In Exchange Server, depending on the version (Standard or Enterprise) of Exchange, you can have up to five mailbox databases mounted. EAC and EMS enforce these limits, but it is possible to directly modify Active Directory to exceed these limits. If you create more databases or storage groups than are allowed, the additional databases will not mount. Exchange Server allows for up to 50 databases with the Enterprise edition (this was reduced from a maximum of 100 databases in Exchange 2010).

Mailbox databases are represented in Active Directory by the msExchPrivateMDB class. This class is not as simple as some of the other classes used by Exchange. In addition, several of the attributes hold binary data, so working with these Active Directory objects directly can be difficult. One of the more notable attributes of the mailbox store objects is a backlink attribute called homeMDBBL. This is a multivalued attribute linking back to all of the user objects that have mailboxes in this mailbox store.

Enabling or Disabling Anti-Malware Scanning

Problem

You want to enable Exchange Server anti-malware scanning.

Solution

Using PowerShell

Within the scripts folder on any Exchange server, there is a precanned PowerShell script to enable anti-malware scanning. This is found in the scripts folder located by default at C:Program FilesMicrosoftExchange ServerV15scripts. You can enable anti-malware scanning by running the script as follows:

& $env:ExchangeInstallPathScriptsEnable-Antimalwarescanning.ps1

Note

Changing the anti-malware scanning settings requires the transport service to be restarted before the settings will take place. Running the built-in PowerShell scripts will automatically restart this service without prompting.

Discussion

To confirm the installation, run the Get-MalwareFilteringServer cmdlet, which will also show the anti-malware settings. To disable anti-malware filtering, run the following command:

& $env:ExchangeInstallPathScriptsDisable-Antimalwarescanning.ps1

Enabling Message Tracking

Problem

You want to enable message tracking on Exchange Server.

Solution

Using a graphical user interface

Message tracking in Exchange can be set on servers running with the Mailbox role installed. To enable message tracking on an Exchange server, follow these steps:

  1. Sign in to the EAC by navigating to https://<CASServer>/ecp.

  2. Navigate to Servers→Servers.

  3. Double-click the server that you want to configure and then click the “Transport logs” link.

  4. Select or deselect the checkbox next to “Message Tracking logging” to enable or disable the feature.

  5. Accept the default message tracking log path or specify an alternate path.

  6. Click Save to close the window and save the settings.

Using PowerShell

To enable the message tracking log for an Exchange server, use the following syntax:

Set-MailboxServer <Server_Name> -MessageTrackingLogEnabled $True

There are a few other parameters that are easily configured with the cmdlet. These include:

MessageTrackingLogPath

This parameter is used to set a nondefault local path for the message tracking logs. The default location is C:Program FilesMicrosoftExchange ServerTransportRolesLogsMessageTracking.

MessageTrackingLogSubjectEnabled

By default, message subjects are logged in message tracking; however, a privacy or compliance policy may require subjects be omitted from logging content.

MessageTrackingLogMaxDirectorySize

Controlling the directory size where message tracking logs are stored can prevent unexpected drive space usage.

MessageTrackingLogMaxFileSize

The default file size for message tracking logs is 10 MB. To control the frequency of new logfiles and the total number of files, it may be beneficial to increase or decrease the individual file size.

MessageTrackingLogMaxAge

For policy, compliance, or storage reasons, it may benefit a company to have logs expire.

A full example of this configuration is:

Set-MailboxServer EX01 -MessageTrackingLogEnabled:$True -MessageTrackingLogPath "e:Logs" -MessageTrackingLogMaxDirectorySize 1GB

Discussion

Message tracking logs are an invaluable aid when troubleshooting message delivery in any Exchange environment. A message can be tracked from submission to the Information Store all the way through to its departure out of the Exchange environment. As long as the administrator doing the tracking has the rights to and can resolve the NetBIOS name of each server along the message path, the administrator will be able to see how a particular message traveled through the network and how long it took to go through each server.

Message tracking is enabled by default on all Exchange servers running the Mailbox role. The EMS allows for full configuration of message tracking.

When changing the location of the message tracking logs, the existing logs are not automatically transferred to the new location.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.221.188.161