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.

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.

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.

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.

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.

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

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

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.

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

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

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>"

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

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

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.

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]'

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.

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.

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"

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.

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 [email protected] 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.

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}

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.

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.

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.

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.

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

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

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>"

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"

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.

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.

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

An example of this command might be as follows:

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

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"

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

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:

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:

A full example of this configuration is:

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