Configure Exchange Multi-Tenant Environment

Exchange Multi-Tenant
4043 E Salinas Ct customer@qualtechsoftware.com Page |1

Phoenix, AZ 85044 602.490.0911/855.477.7463
Table of Contents
First time installation...................................................................................................................................................... 7
Create an Exchange admin account......................................................................................................................... 7
Active Directory preparation....................................................................................................................................... 8
What do you need to know before you begin? .............................................................................................. 9
1. Extend the Active Directory schema ............................................................................................................ 10
2. Prepare Active Directory .................................................................................................................................. 12
3. Prepare Active Directory domains ................................................................................................................ 15
Prepare all of the domains in my Active Directory forest.................................................................... 15
Let me choose which Active Directory domains I want to prepare ................................................. 17
How do you know this worked? ........................................................................................................................ 18
Exchange 2016 Active Directory versions .................................................................................................. 19
Windows Server 2012 and Windows Server 2012 R2 prerequisites ..................................................... 21
Mailbox server role ............................................................................................................................................. 21
Edge Transport server role .............................................................................................................................. 21
Create and configure mailbox databases ........................................................................................................... 23
Set virtual-directory external path ......................................................................................................................... 28
Configure certificates.................................................................................................................................................. 29
Add QualTechMail certificate .............................................................................................................................. 29
Configure services with wildcard certificate .................................................................................................. 30
Create send connectors ............................................................................................................................................. 31
Outbound SMTP connector ............................................................................................................................ 31
Configure POP3 and IMAP4 ..................................................................................................................................... 36
Configure POP3........................................................................................................................................................ 36
Step 1: Start the POP3 services, and configure the services to start automatically ................... 36
Step 2: Use the Exchange Management Shell to configure the POP3 settings for external
clients....................................................................................................................................................................... 38

Phoenix, AZ 85044 602.490.0911/855.477.7463
Step 3: Restart the POP3 services ................................................................................................................. 39
How do you know this task worked? ............................................................................................................... 40
Next steps................................................................................................................................................................... 42
Configure IMAP ........................................................................................................................................................ 42
What do you need to know before you begin? ...................................................................................... 43
How do you do this? ........................................................................................................................................ 44
Step 1: Start the IMAP4 services, and configure the services to start automatically ................ 44
Step 2: Use the Exchange Management Shell to configure the IMAP4 settings for external
clients....................................................................................................................................................................... 45
How you do know this step worked? .......................................................................................................... 46
Step 3: Restart the IMAP4 services ............................................................................................................ 47
Step 4: Configure the authenticated SMTP settings for IMAP4 clients .......................................... 47
How do you know this task worked? ........................................................................................................ 47
Configure authenticated SMTP settings for POP3 and IMAP4 clients in Exchange 2016 ................ 49
What do you need to know before you begin? ........................................................................................... 50
How do you do this? .............................................................................................................................................. 51
Step 1: Configure the FQDN on the "Client Frontend <Server name>" Receive connector .. 51
How do you know this step worked? ........................................................................................................ 54
Step 2: Use the Exchange Management Shell to specify the certificate that's used to encrypt
authenticated SMTP client connections ..................................................................................................... 54
Step 3: Use the Exchange Management Shell to configure Outlook on the web to display
the SMTP settings for authenticated SMTP clients ................................................................................ 55
How do you know this task worked? ............................................................................................................... 56
Setting up an email client ......................................................................................................................................... 57
DMZ port configuration ............................................................................................................................................ 57
Port 443 ....................................................................................................................................................................... 57

Phoenix, AZ 85044 602.490.0911/855.477.7463
Port 587 ....................................................................................................................................................................... 57
Port 143 and 993 ..................................................................................................................................................... 59
Port 110 and 995 ..................................................................................................................................................... 59
Multitenancy .................................................................................................................................................................. 60
Adding users ............................................................................................................................................................. 60
Tasks ........................................................................................................................................................................ 60
Create AD Structure and UPN Sufix ............................................................................................................. 60
Setting up Exchange server for new Tenant.................................................................................................. 61
Add a new domain for the new tenant....................................................................................................... 61
Global Address List (GAL) for Tenant00001 .............................................................................................. 61
All Rooms Address List ..................................................................................................................................... 63
All Users Address List ........................................................................................................................................ 63
All Contacts Address List .................................................................................................................................. 64
All Groups Address List ..................................................................................................................................... 64
Offline Address Book ......................................................................................................................................... 64
Email Address Policy .......................................................................................................................................... 64
Address Book Policy........................................................................................................................................... 65
Resource management by creating a Room Mailbox. .......................................................................... 65
Creating a new user for our Tenant0001 ................................................................................................... 66
Create mailbox for and existing AD user ................................................................................................... 66
Deploy and Configure a DAG server..................................................................................................................... 69
Use the EAC to create a database availability group ................................................................................. 70
Use the Exchange Management Shell to create a database availability group .......................... 71
Manage database availability group membership .......................................................................................... 74
What do you need to know before you begin? ........................................................................................... 75
What do you want to do?..................................................................................................................................... 75

Phoenix, AZ 85044 602.490.0911/855.477.7463
Use the EAC to manage database availability group membership.................................................. 76
Use the Shell to manage database availability group membership ................................................ 76
DAG membership .................................................................................................................................................... 77
Pre-staging the cluster name object for a DAG ...................................................................................... 82
Removing servers from a DAG ........................................................................................................................... 83
Configuring DAG properties ............................................................................................................................... 84
DAG network encryption.................................................................................................................................. 84
DAG network communication encryption settings ............................................................................. 85
DAG network compression ............................................................................................................................. 85
DAG network communication compression settings......................................................................... 86
Appendix ......................................................................................................................................................................... 91
Network ports required for clients and services .......................................................................................... 91
Network ports required for mail flow .............................................................................................................. 94
Network ports required for mail flow (no Edge Transport servers) ................................................. 95
Network ports required for mail flow with Edge Transport servers ................................................ 97
Name resolution .................................................................................................................................................... 104
Network ports required for hybrid deployments ...................................................................................... 104
Network ports required for Unified Messaging ......................................................................................... 104
Database availability groups (DAGs)................................................................................................................... 105
Database availability group lifecycle .............................................................................................................. 106
Exchange 2016 architecture ................................................................................................................................... 112
Server communication architecture ............................................................................................................. 114
Server role architecture ..................................................................................................................................... 115
Mailbox servers ................................................................................................................................................. 115
Edge Transport servers .................................................................................................................................. 116
High availability architecture .......................................................................................................................... 116

Phoenix, AZ 85044 602.490.0911/855.477.7463
Mailbox high availability............................................................................................................................... 116
Transport high availability ........................................................................................................................... 116
Client access protocol architecture............................................................................................................... 116
Exchange 2016 architecture changes ........................................................................................................... 118

Phoenix, AZ 85044 602.490.0911/855.477.7463
Install IIS and install QualTechCloud’s certificate.
First time installation

For first time installation of Exchange the AD has to be prepared first.
Create an Exchange admin account

Create an account named exchangeadminacc. This account must be member of the Enterprise
Admins and Schema Admin roles.
You will use this account to log on to the exchange servers and run the entire Exchange
deployment.
This user must be part of the roles:
• Enterprise Admins
• Organization Management
• Schema Admins

Phoenix, AZ 85044 602.490.0911/855.477.7463
Figure 1: Exchange admin account.
Active Directory preparation

The computer you want to use to prepare Active Directory for Exchange 2016 has specific
prerequisites that must be met.
First, install .NET Framework 4.6.2 on the computer that will be used to prepare Active Directory.

Phoenix, AZ 85044 602.490.0911/855.477.7463
Before you install Microsoft Exchange Server 2016, you need to prepare your Active Directory
forest and its domains. Exchange needs to prepare Active Directory so that it can store
information about your users' mailboxes and the configuration of Exchange servers in the
organization. If you aren't familiar with Active Directory forests or domains, check out Active
Directory Domain Services Overview.
There are a couple of ways you can prepare Active Directory for Exchange. The first is to let the
Exchange 2016 Setup wizard do it for you. If you don't have a large Active Directory deployment,
and you don't have a separate team that manages Active Directory, we recommend using the
wizard. The account you use will need to be a member of both the Schema Admins and
Enterprise Admins security groups. For more information about how to use the Setup wizard,
check out Install the Exchange 2016 Mailbox role using the Setup wizard.
If you have a large Active Directory deployment, or if a separate team manages Active Directory,
this topic is for you. Following the steps in this topic gives you much more control over each
stage of preparation, and who can do each step. For example, Exchange administrators might
not have the permissions needed to extend the Active Directory schema.
1. What do you need to know before you begin?

2. Extend the Active Directory schema
3. Prepare Active Directory
4. Prepare Active Directory domains
How do you know this worked?
Curious about what's happening when Active Directory is being prepared for Exchange? Check
out What changes in Active Directory when Exchange 2016 is installed?
What do you need to know before you begin?

• Estimated time to complete: 10-15 minutes or more (not including Active Directory
replication), depending on organization size and the number of child domains.
• The computer you use to run these steps needs to meet the Exchange 2016 system
requirements. Also, your Active Directory forest needs to meet the requirements in the
"Network and directory servers" section in Exchange 2016 system requirements.
• If your organization has multiple Active Directory domains, we recommend the following:
o Do the steps below from an Active Directory site that has an Active Directory
server from every domain.

Phoenix, AZ 85044 602.490.0911/855.477.7463
o Install the first Exchange server in an Active Directory site with a writeable global
catalog server from every domain.
Tip:
Having problems? Ask for help in the Exchange forums. Visit the forums at: Exchange
Server, Exchange Online, or Exchange Online Protection.
1. Extend the Active Directory schema

The first step in getting your organization ready for Exchange 2016 is to extend the Active
Directory schema. Exchange stores a lot of information in Active Directory but before it can do
that, it needs to add and update classes, attributes, and other items. If you're curious about
what's changed when your schema is extended, check out Exchange 2016 Active Directory schema
changes.
Before you extend your schema, there are a few things to keep in mind:
• The account you're logged in as needs to be a member of the Schema Admins and
Enterprise Admins security groups.
• The computer where you'll run the command to extend the schema needs to be in the
same Active Directory domain and site as the schema master.
• If you use the DomainController parameter, make sure to use the name of the domain
controller that's the schema master.
• The only way to extend the schema for Exchange is to use the steps in this topic or use
Exchange 2016 Setup. Other ways of extending the schema aren't supported.
Tip:
If you don't have a separate team that manages your Active Directory schema, you can skip
this step and go directly to Step 2. Prepare Active Directory. If the schema isn't extended in
4043 E Salinas Ct customer@qualtechsoftware.com P a g e | 10

Phoenix, AZ 85044 602.490.0911/855.477.7463
step 1, the commands in step 2 will extend the schema for you. If you decide to skip step 1,
the information you need to keep in mind above still applies.
When you're ready, do the following to extend your Active Directory schema. If you have
multiple Active Directory forests, make sure you're logged into the right one.
1. Make sure the computer is ready to run Exchange 2016 Setup. To see what you need to
run Setup, check out the Active Directory preparation section in Exchange 2016 prerequisites.
2. Open a Windows Command Prompt window and go to where you downloaded the
Exchange installation files.
3. Run the following command to extend the schema.
4. <drive>:\Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms
After Setup finishes extending the schema, you'll need to wait while Active Directory replicates
the changes to all of your domain controllers. If you want to check on how replication is going,
you can use the repadmin tool. Repadmin is included as part of the Active Directory Domain
Services Tools feature in Windows Server 2012 R2 and Windows Server 2012. For more
information about how to use it, see Repadmin.
Figure 2: The AD schema preparation completed successfully.

Phoenix, AZ 85044 602.490.0911/855.477.7463
2. Prepare Active Directory
Now that the Active Directory schema has been extended, you can prepare other parts of Active
Directory for Exchange 2016. During this step, Exchange will create containers, objects, and
other items in Active Directory that it'll use to store information. The collection of all of the
Exchange containers, objects, attributes, and so on, is called the Exchange organization.
Before you prepare Active Directory for Exchange, there are a few things to keep in mind:
• The account you're logged in as needs to be a member of the Enterprise Admins security
group. If you skipped step 1 because you want the PrepareAD command to extend the
schema, the account you use also needs to be a member of the Schema Admins security
group.
• The computer where you'll run the command needs to be in the same Active Directory
domain and site as the schema master. It'll also need to contact all of the domains in the
forest on TCP port 389.
• Wait until Active Directory has replicated the changes made in step 1 to all of your
domain controllers before you do this step.
When you run the command below to prepare Active Directory for Exchange, you'll need to
name the Exchange organization. This name is used internally by Exchange and isn't normally
seen by users. The name of the company where Exchange is being installed is often used for the
organization name. The name you use won't affect the functionality of Exchange or determine
what you can use for email addresses. You can name it anything you want, as long as you keep
the following in mind:
• You can use any uppercase or lowercase letters from A to Z.

• You can use numbers 0 to 9.
• The name can contain spaces as long as they're not at the beginning or end of the name.
• You can use a hyphen or dash in the name.
• The name can be up to 64 characters but can't be blank.
• The name can't be changed after it's set.
When you're ready, do the following to prepare Active Directory for Exchange. If the
organization name you want to use has spaces, enclose the name in quotation marks (").
2. Run the following command:

Phoenix, AZ 85044 602.490.0911/855.477.7463
3. Setup.exe /PrepareAD /OrganizationName:"<organization name>"
/IAcceptExchangeServerLicenseTerms
Figure 3: Prepare organization for Exchange.
After Setup finishes preparing Active Directory for Exchange, you'll need to wait while Active
Directory replicates the changes to all of your domain controllers. If you want to check on how
replication is going, you can use the repadmin tool. repadmin is included as part of the Active
Directory Domain Services Tools feature in Windows Server 2012 R2 and Windows Server 2012.
For more information about how to use the tool, see Repadmin.
Notes

Phoenix, AZ 85044 602.490.0911/855.477.7463
To view the Exchange objects in the AD in Active Directory and Computers select
View>Advanced Features.
Figure 4: AD Exchange objects.
In a command prompt type ADSIEdit

Phoenix, AZ 85044 602.490.0911/855.477.7463
k
Figure 5: Exchange objects in the ADSIEdit.
3. Prepare Active Directory domains

The final step to get Active Directory ready for Exchange is to prepare each of the Active
Directory domains where Exchange will be installed or where mail-enabled users will be located.
This step creates additional containers and security groups, and sets permissions so that
Exchange can access them.
If you have multiple domains in your Active Directory forest, you have a couple of choices in
how you prepare them. Select the option that matches what you want to do. If you only have
one domain, you can skip this step because the PrepareAD command in step 2 already prepared
the domain for you.
Prepare all of the domains in my Active Directory forest

Phoenix, AZ 85044 602.490.0911/855.477.7463
To prepare all of your Active Directory domains, you can use the PrepareAllDomains parameter
when you run Setup. Setup will prepare every domain for Exchange in your Active Directory
forest for you.
Before you prepare all of the domains in your Active Directory forest, keep the following in
mind:
• The account you use needs to be a member of the Enterprise Admins security group.
domain controllers. If you don't, you might get an error when you try to prepare the
domain.
When you're ready, do the following to prepare all of the domains in your Active Directory
forest for Exchange.
2. Run the following command:
3. Setup.exe /PrepareAllDomains /IAcceptExchangeServerLicenseTerms

Phoenix, AZ 85044 602.490.0911/855.477.7463
Figure 6: Exchange preparation of all domains.
Let me choose which Active Directory domains I want to prepare
If you want to choose which Active Directory domains you want to prepare, you can use
the PrepareDomain parameter when you run Setup. When you use the PrepareDomain parameter,
you need to include the fully qualified domain name (FQDN) of the domain you want to
prepare.
Before you prepare the domains in your Active Directory forest, keep the following in mind:
• The account you use needs permissions depending on when the domain was created.

Phoenix, AZ 85044 602.490.0911/855.477.7463
o Domain created before PrepareAD was run If the domain was created before you
ran the PrepareAD command in step 2 above, then the account you use needs to
be a member of the Domain Admins group in the domain you want to prepare.
o Domain created after PrepareAD was run If the domain was created after you ran
the PrepareAD command in step 2 above, then the account you use needs to 1) be
a member of the Organization Management role group and 2) be a member of
the Domain Admins group in the domain you want to prepare.
domain controllers. If you don't, you might get an error when you try to prepare the
domain.
• You need to prepare every domain where an Exchange server will be installed. You'll also
need to prepare any domain that'll contain mail-enabled users, even if those domains
won't contain any Exchange servers.
• You don't need to run the PrepareDomain command in the domain where
the PrepareAD command was run. The PrepareAD command prepares that domain
automatically.
When you're ready, do the following to prepare an individual domain in your Active Directory
forest for Exchange.
2. Run the following command. Include the FQDN of the domain you want to prepare. If
you want to prepare the domain you're running the command in, you don't have to
include the FQDN.
3. Setup.exe /PrepareDomain:<FQDN of the domain you want to prepare>
/IAcceptExchangeServerLicenseTerms
4. Repeat the steps for each Active Directory domain where you'll install an Exchange server
or where mail-enabled users will be located.

Once you've done all the steps above, you can check to make sure everything's gone smoothly.
To do so, you'll use a tool called Active Directory Service Interfaces Editor (ADSI Edit). ADSI Edit
is included as part of the Active Directory Domain Services Tools feature in Windows Server
2012 R2 and Windows Server 2012. If you want to know more about it, check out ADSI Edit
(adsiedit.msc).

Phoenix, AZ 85044 602.490.0911/855.477.7463
Warning:
Never change values in ADSI Edit unless you're told to do so by Microsoft support. Changing
values in ADSI Edit can cause irreparable harm to your Exchange organization and Active
Directory.
After Exchange extends your Active Directory schema and prepares Active Directory for
Exchange, several properties are updated to show that preparation is complete. Use the
information in the following list to make sure these properties have the right values. Each
property needs to match the value in the table below for the release of Exchange 2016 that
you're installing.
• In the Schema naming context, verify that the rangeUpper property on ms-Exch-Schema-
Version-Pt is set to the value shown for your version of Exchange 2016 in the Exchange
2016 Active Directory versions table.
• In the Configuration naming context, verify that the objectVersion property in the
CN=<your organization>,CN=Microsoft
Exchange,CN=Services,CN=Configuration,DC=<domain> container is set to the value
shown for your version of Exchange 2016 in the Exchange 2016 Active Directory
versions table.
• In the Default naming context, verify that the objectVersion property in the Microsoft
Exchange System Objects container under DC=<root domain is set to the value shown for
your version of Exchange 2016 in the Exchange 2016 Active Directory versions table.
You can also check the Exchange setup log to verify that Active Directory preparation has
completed successfully. For more information, see Verify an Exchange 2016 installation. You won't
be able to use the Get-ExchangeServer cmdlet mentioned in the Verify an Exchange 2016
installation topic until you've completed the installation of at least one Mailbox server role in an
Active Directory site.
Exchange 2016 Active Directory versions
The following table shows you the Exchange 2016 objects in Active Directory that get updated
each time you install a new version of Exchange 2016. You can compare the object versions you

Phoenix, AZ 85044 602.490.0911/855.477.7463
see with the values in the table below to verify that the version of Exchange 2016 you installed
successfully updated Active Directory during installation.
Exchange
rangeUpper objectVersion objectVersion
version
Naming Schema Default Configuration

context
Container ms-Exch- Microsoft CN=<your organization>,

Schema- Exchange CN=Microsoft Exchange,
Version-Pt System Objects CN=Services,
CN=Configuration,
DC=<domain>
Exchange 15326 13236 16213

2016 CU5
Exchange 15326 13236 16213

2016 CU4
Exchange 15326 13236 16212

2016 CU3
Exchange 15325 13236 16212

2016 CU2
Exchange 15323 13236 16211

2016 CU1
Exchange 15317 13236 16210

2016 RTM
Exchange 15317 13236 16041

2016
Preview

Phoenix, AZ 85044 602.490.0911/855.477.7463
Windows Server 2012 and Windows Server 2012 R2
prerequisites
The prerequisites that are needed to install Exchange 2016 on computers running Windows
Server 2012 or Windows Server 2012 R2 depends on which Exchange role you want to install.
Read the section below that matches the role you want to install.
Mailbox server role
Follow the instructions in this section to install the prerequisites on computers running Windows
Server 2012 or Windows Server 2012 R2 where you want to install the Mailbox server role.
Do the following to install the required Windows roles and features:
1. Open Windows PowerShell.

2. Run the following command to install the required Windows components.
3. Install-WindowsFeature AS-HTTP-Activation, Server-Media-Foundation, NET-Framework-
45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface,
RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, Web-Mgmt-Console, WAS-
Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth,
Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-
Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-
Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45,
Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-
Windows-Auth, Web-WMI, Windows-Identity-Foundation, RSAT-ADDS
After you've installed the operating system roles and features, install the following software in
the order shown:
1. .NET Framework 4.6.2

2. Install the Unified Communications Managed API 4.0 Runtime from here.
Edge Transport server role
Follow the instructions in this section to install the prerequisites on computers running Windows
Server 2012 or Windows Server 2012 R2 where you want to install the Edge Transport server
role.

Phoenix, AZ 85044 602.490.0911/855.477.7463
Do the following to install the required Windows roles and features:
3. Open Windows PowerShell.

4. Run the following command to install the required Windows components.
Install-WindowsFeature ADLDS
After you've installed the operating system roles and features, install .NET Framework 4.6.2
Attach the Exchange CD to the AD server and run setup.exe /PrepareAD

/IAcceptExchangeServerLicenseTerms /OrganizationName “QualTech Ex1”.
Notes
To view the new AD properties created by Exchange use ADSIEdit.msc. Connect to the
Configuration and the Exchange properties are under Services.
Figure 7: Complete AD preparation.
Run Exchange installation wizard. The installation will also prepare the AD for exchange if
needed.

Phoenix, AZ 85044 602.490.0911/855.477.7463
Add a second disk to the server to contain Exchange’s mailbox databases. Do not create the
databases in the C drive.
We don’t use Auto Reseed. Storage for databases has to be calculated and 50GB per mailbox.
The setup log file is in <system drive>:\ExchangeSetupLogs\ExchangeSetup.log.
After the installation, you can check if the server is running by starting the Exchange
Management Shell and typing Get-ExchangeServer.
Figure 8: Get-ExchangeServer
Create and configure mailbox databases

Mailbox databases are created by logging in to the Exchange admin center and navigating to
servers and then databases. Click the New button to create a new mailbox database.
Add an A record in the DNS server to point to the Exchange server under qualtechmail.com.
To access the Exchange Admin run the Exchange Administrative Center

Phoenix, AZ 85044 602.490.0911/855.477.7463
We will need a new ip address to setup Exchange in the qualtechs1.
Notes
Get-ECPVirtualDirectory|fl
Get-OWAVirtualDirectory|fl
See Exchange book page 17.
When you install a Mailbox server it by default creates the mailbox database in the C drive
C:\Program Files\Microsoft\Exchange Server\V15\Mailbox\Mailbox Database
1716673664\Mailbox Database 1716673664.edb
We are not going to use the C drive for the mailboxes. We’ll add a disk or disks as necessary and
will create the databases under:
<new drive1>:\ExchangeDatabases\DB01

Phoenix, AZ 85044 602.490.0911/855.477.7463
The first task is to create a new database and move the mailbox of the exchange admin to the
new database.
In the Exchange Admin Server go to server>databases and add new databases.
Figure 9: New DB with standard path.

Phoenix, AZ 85044 602.490.0911/855.477.7463
Adding new databases requires the re-start of the Microsoft Exchange Information Store service.
Don’t forget confirm that the new databases have been mounted or you won’t be able to move
the default database or do anything with it.
Figure 10: After creating a new database the Microsoft Exchange Information service must be re-started
The next setup after a new deployment of the Exchange server is to move the default mailboxes
to one of the new databases we have just added.
In recipients>mailboxes on the right hand tab under Move Mailbox select To another database.
Fill up the migration form and create the batch migration job.
Once the move is complete we dismount the default database so it can’t be used.

Phoenix, AZ 85044 602.490.0911/855.477.7463
Figure 11: Mailboxes.
View the status or start the migration job by selecting the migration form.

Phoenix, AZ 85044 602.490.0911/855.477.7463
Figure 12: Migration form
Set virtual-directory external path

When we setup the Exchange server all the virtual directories are setup with the internal path to
the different applications.
We need to update the external path before we can access Exchange applications from the
outside.
In the Exchange admin center select servers>virtual directories.
Double click the service you want to update the path to and in the External URL text box type
the external path.
If you change the path to the ECP service (central admin) will get a message to also change the
OWA.

Phoenix, AZ 85044 602.490.0911/855.477.7463
Figure 13: Update to the ECP service requires the update to the OWA service.
Configure certificates
Add certificate
Select servers>certificates. Add the certificate and assign it to the services.

Phoenix, AZ 85044 602.490.0911/855.477.7463
Figure 14: Assign the certificate to services.
Because we use wildcard certificates we can only set the SMTP and IIS services. To set our
certificate to the other services we’ll have to use powershell commands.
Configure services with wildcard certificate

To configure the POP3 and IMAP services with a wild card you’ll have to use a FQDN
(mail1.qualtechmail.com) and the following commands:
set-POPSettings -X509CertificateName mail.domain.com

set-IMAPSettings -X509CertificateName mail.domain.com
You can see what services are associated with the Get-ExchangeCertificate command:
Get-ExchangeCertificate -Thumbprint <certificatethumbprint> | fl
You can see the thumbprint by using Get-ExchangeCertificate only.

Phoenix, AZ 85044 602.490.0911/855.477.7463
Figure 15: Services associated with a certificate.
Create send connectors

Outbound SMTP connector
The installation doesn’t create a send connector for the outbound email. We have to create the
connector for that and we route the outbound email through our external email server
mail.qualtechsoftware.com.
Select mail flow and click the plus sign in the send connectors to create a new connector.
Type a name for the connector. Check Custom (For example, to send mail to other non-
Exchange servers)

Phoenix, AZ 85044 602.490.0911/855.477.7463
Figure 16: New send connector form1.
Click Next. In the form 2 check Route mail through smart hosts. Click the plus sign to add the
fully qualified smart host. Click Save and then Next.

Phoenix, AZ 85044 602.490.0911/855.477.7463
your external email server
Figure 17: Send connector form 2.
Next we need to set the authentication to connect to the smart host. We don’t have
authentication in the internal server it only accepts connections from specific servers. That is
setup in the internal SMTP server.
In the form 3 we will inform the domains Exchange hosts which will use this connector to route
outbound email.

Phoenix, AZ 85044 602.490.0911/855.477.7463
Figure 18: Authoritative domains using this connector.
In form 4 we associate the connector with the servers.

Phoenix, AZ 85044 602.490.0911/855.477.7463
Figure 19: Associate connector.
Notes
This is VERY IMPORTANT. Because we relay our outbound email through our external smtp
servers when you define the accepted domain make sure you set the Domain Type as External
Relay otherwise Exchange will try to find the recipient in that server and because it won’t find
it there it will return a '550 5.1.10 RESOLVER.ADR.RecipientNotFound; Recipient not found by
SMTP address lookup'

Phoenix, AZ 85044 602.490.0911/855.477.7463
Figure 20: Define the accepted domain as External Relay.
Configure POP3 and IMAP4

The POP3 and IMAP4 services are disabled by default. We need to configure these services.
Configure POP3
Step 1: Start the POP3 services, and configure the services to start
automatically
You can perform this step by using the Windows Services console, or the Exchange
Management Shell.
Use the Windows Services console to start the POP3 services, and configure the
services to start automatically

Phoenix, AZ 85044 602.490.0911/855.477.7463
1. On the Exchange server, open the Windows Services console. For example:
o Run the command services.msc from the Run dialog, a Command Prompt window, or
the Exchange Management Shell.
o Open Server Manager, and then click Tools > Services.
2. In the list of services, select Microsoft Exchange POP3, and then click Action > Properties.
3. The Microsoft Exchange POP3 Properties window opens. On the General tab, configure the
following settings:
o Startup type Select Automatic.
o Service status Click Start.
When you are finished, click OK.
4. In the list of services, select Microsoft Exchange POP3 Backend, and then
click Action > Properties.
5. The Microsoft Exchange POP3 Backend Properties window opens. On the General tab,
configure the following settings:
Use the Exchange Management Shell to start the POP3 services, and configure the
services to start automatically
1. Run the following command to start the POP3 services:

2. Start-Service MSExchangePOP3; Start-Service MSExchangePOP3BE
3. Run the following command to configure the POP3 services to start automatically:
4. Set-Service MSExchangePOP3 -StartupType Automatic; Set-Service MSExchangePOP3BE
-StartupType Automatic
For more information about these cmdlets, see Start-Service and Set-Service.
How do you know this step worked?
To verify that you've successfully started the POP3 services, use either of the following
procedures:
• On the Exchange server, open Windows Task Manager. On the Services tab, verify that
the Status value for the MSExchangePOP3 and MSExchangePOP3BE services is Running.
• In the Exchange Management Shell, run the following command to verify that the POP3
services are running:
• Get-Service MSExchangePOP3; Get-Service MSExchangePOP3BE

Phoenix, AZ 85044 602.490.0911/855.477.7463
Notes
To enable the POP protocol log do
Set-PopSettings –Server <Exchange server name> –ProtocolLogEnabled $True
Step 2: Use the Exchange Management Shell to configure the POP3

settings for external clients
To configure the POP3 settings for external clients, use the following syntax:
Set-PopSettings -ExternalConnectionSettings "<FQDN1>:<TCPPort1>:<SSL | TLS | blank>",

"<FQDN2>:<TCPPort2>:<SSL | TLS | blank>"... -X509CertificateName <FQDN> [-SSLBindings
"<IPv4Orv6Address1>:<TCPPort1>","<IPv4Orv6Address2>:<TCPPort2>"...] [-
UnencryptedOrTLSBindings
"<IPv4Orv6Address1>:<TCPPort1>","<IPv4Orv6Address2>:<TCPPort2>"...]
This example configures the following settings for external POP3 connections:
• POP3 server FQDN mail.contoso.com

• TCP port 995 for always TLS encrypted connections, and 110 for unencrypted
connections or opportunistic TLS (STARTTLS) encrypted connections.
• Internal Exchange server IP address and TCP port for always TLS encrypted connections All
available IPv4 and IPv6 addresses on the server on port 995 (we aren't using
the SSLBindings parameter, and the default value is [::]:995,0.0.0.0:995).
• Internal Exchange server IP address and TCP port for unencrypted or opportunistic TLS
(STARTTLS) encrypted connections All available IPv4 and IPv6 addresses on the server on
port 110 (we aren't using the UnencryptedOrTLSBindings parameter, and the default value
is [::]:110,0.0.0.0:110).
• FQDN used for encryption mail.contoso.com. This value identifies the certificate that
matches or contains the POP3 server FQDN.
Set-PopSettings -ExternalConnectionSettings
"mail.contoso.com:995:SSL","mail.contoso.com:110:TLS" -X509CertificateName mail.contoso.com

Phoenix, AZ 85044 602.490.0911/855.477.7463
Notes:
• For detailed syntax and parameter information, see Set-PopSettings.
• The external POP3 server FQDN that you configure needs to have a corresponding
record in your public DNS, and the TCP port (110 or 995) needs to be allowed through
your firewall to the Exchange server.
• The combination of encryption methods and TCP ports that you use for
the ExternalConnectionSettings parameter need to match the corresponding TCP ports and
encryption methods that you use for
the SSLBindings or UnencryptedOrTLSBindings parameters.
• Although you can use a separate certificate for POP3, we recommend that you use the
same certificate as the other Exchange IIS (HTTP) services, which is likely a wildcard
certificate or a subject alternative name (SAN) certificate from a commercial certification
authority that's automatically trusted by all clients. For more information, see Certificate
requirements for Exchange services.
• If you use a single subject certificate, or a SAN certificate, you also need to assign the
certificate to the Exchange POP service. You don't need to assign a wildcard certificate to
the Exchange POP service. For more information, see Assign certificates to Exchange 2016
services.
How you do know this step worked?
To verify that you've successfully configured the POP3 settings for external clients, run the
following command in the Exchange Management Shell and verify the settings:
Get-PopSettings | Format-List *ConnectionSettings,*Bindings,X509CertificateName
For more information, see Get-POPSettings.
Step 3: Restart the POP3 services
After you enable and configure POP3, you need to restart the POP3 services on the server by
using the Windows Services console, or the Exchange Management Shell.
Use the Windows Services console to restart the POP3 services
1. On the Exchange server, open the Windows Services console.

2. In the list of services, select Microsoft Exchange POP3, and then click Action > Restart.

Phoenix, AZ 85044 602.490.0911/855.477.7463
3. In the list of services, select Microsoft Exchange POP3 Backend, and then
click Action > Restart.
Use the Exchange Management Shell to restart the POP3 services
Run the following command to restart the POP3 services.
Restart-Service MSExchangePOP3; Restart-Service MSExchangePOP3BE
For more information about this cmdlet, see Restart-Service.
To verify that you've successfully restarted the POP3 services, run the following command:
Get-Service MSExchangePOP3; Get-Service MSExchangePOP3BE
How do you know this task worked?

To verify that you have enabled and configured POP3 on the Exchange server, perform the
following procedures:
1. Open a mailbox in Outlook on the web, and then click Settings > Options.
2. Click Mail > Accounts > POP and IMAP and verify the correct POP3 settings are displayed.

Phoenix, AZ 85044 602.490.0911/855.477.7463
Note: If you configured 995/SSL and 110/TLS values for the ExternalConnectionSettings parameter
on the Set-PopSettings cmdlet, only the 995/SSL value is displayed in Outlook on the web. Also,
if the external POP3 settings that you configured don't appear as expected in Outlook on the
web after you restart the POP3 services, run the command iisreset.exe /noforce to restart
Internet Information Services (IIS).
1. You can test POP3 client connectivity to the Exchange server by using the following
methods:
• Internal clients Use the Test-PopConnectivity cmdlet. For example, Test-
PopConnectivity -ClientAccessServer<ServerName> -Lightmode -
MailboxCredential (Get-Credential). For more information, see Test-
PopConnectivity.
Test-popconnectivity -clientaccessserver ex1-dev15.qtdev.qualtechcloud.com -lightmode -

mailboxcredential (get-credential)
• Note: The Lightmode switch tells the command test POP3 logons to the server. To test
sending (SMTP) and receiving a (POP3) message, you need to configure the
authenticated SMTP settings as described in Configure authenticated SMTP settings in
Exchange 2016 for POP3 and IMAP4 clients.
• External clients Use the Exchange Server > POP Email test in the Microsoft Remote
Connectivity Analyzer at http://go.microsoft.com/fwlink/p/?LinkID=313839.

Phoenix, AZ 85044 602.490.0911/855.477.7463
Note: You can't use POP3 to connect to the Administrator mailbox. This limitation was
intentionally included in Exchange 2016 to enhance the security of the Administrator mailbox.
Next steps
To enabled or disable POP3 access to individual mailboxes, see Enable or disable POP3 or IMAP4
access to mailboxes.
Configure IMAP
By default, IMAP4 client connectivity isn't enabled in Exchange. To enable IMAP4 client
connectivity, you need to perform the following steps:
1. Start the IMAP4 services, and configure the services to start automatically:
• Microsoft Exchange IMAP4 This is the Client Access (frontend) service that IMAP4 clients
connect to.
• Microsoft Exchange IMAP4 Backend IMAP4 client connections from the Client Access
service are proxied to the backend service on the server that hold the active copy of the
user's mailbox. For more information, see Client access protocol architecture.
2. Configure the IMAP4 settings for external clients.
By default, Exchange uses the following settings for internal IMAP4 connections:
• IMAP4 server FQDN <ServerFQDN>. For example, mailbox01.contoso.com.
• TCP port and encryption method 993 for always TLS encrypted connections, and 143 for
unencrypted connections, or for opportunistic TLS (STARTTLS) that results in an
encrypted connection after the initial plain text protocol handshake.
To allow external IMAP4 clients to connect to mailboxes, you need to configure the IMAP4
server FQDN, TCP port, and encryption method for external connections. This step causes the
external IMAP4 settings to be displayed in Outlook on the web (formerly known as Outlook Web
App) at Settings > Options > Mail > Accounts > POP and IMAP.

Phoenix, AZ 85044 602.490.0911/855.477.7463
3. Restart the IMAP4 services to save the changes.
4. Configure the authenticated SMTP settings for internal and external clients. For more
information, see Configure authenticated SMTP settings in Exchange 2016 for POP3 and IMAP4
clients.
For more information about IMAP4, see POP3 and IMAP4 in Exchange 2016.
• Estimated time to complete each procedure: 5 minutes.

• Secure Sockets Layer (SSL) is being replaced by Transport Layer Security (TLS) as the
protocol that's used to encrypt data sent between computer systems. They’re so closely
related that the terms "SSL" and "TLS" (without versions) are often used interchangeably.
Because of this similarity, references to "SSL" in Exchange topics, the Exchange admin
center, and the Exchange Management Shell have often been used to encompass both
the SSL and TLS protocols. Typically, "SSL" refers to the actual SSL protocol only when a
version is also provided (for example, SSL 3.0). To find out why you should disable the
SSL protocol and switch to TLS, check out Protecting you against the SSL 3.0 vulnerability.
• To learn how to open the Exchange Management Shell in your on-premises Exchange
organization, see Open the Exchange Management Shell.

Phoenix, AZ 85044 602.490.0911/855.477.7463
• You need to be assigned permissions before you can perform this procedure or
procedures. To see what permissions you need, see the "POP3 and IMAP4 Permissions"
section in the Clients and mobile devices permissions topic.
• For information about keyboard shortcuts that may apply to the procedures in this topic,
see Keyboard shortcuts in the Exchange admin center.
Tip:
Server, Exchange Online, or Exchange Online Protection..
How do you do this?

Step 1: Start the IMAP4 services, and configure the services to start
automatically
You can perform this step by using the Windows Services console, or the Exchange
Management Shell.
Use the Windows Services console to start the IMAP4 services, and configure the services to
start automatically
1. On the Exchange server, open the Windows Services console. For example:
o Run the command services.msc from the Run dialog, a Command Prompt window, or
o Open Server Manager, and then click Tools > Services.
2. In the list of services, select Microsoft Exchange IMAP4, and then click Action > Properties.
3. The Microsoft Exchange IMAP4 Properties window opens. On the General tab, configure the
following settings:
4. In the list of services, select Microsoft Exchange IMAP4 Backend, and then
click Action > Properties.

Phoenix, AZ 85044 602.490.0911/855.477.7463
5. The Microsoft Exchange IMAP4 Backend Properties window opens. On the General tab,
configure the following settings:
Use the Exchange Management Shell to start the IMAP4 services, and configure
the services to start automatically
1. Run the following command to start the IMAP4 services:

2. Start-Service MSExchangeIMAP4; Start-Service MSExchangeIMAP4BE
3. Run the following command to configure the IMAP4 services to start automatically:
4. Set-Service MSExchangeIMAP4 -StartupType Automatic; Set-Service
MSExchangeIMAP4BE -StartupType Automatic
For more information about these cmdlets, see Start-Service and Set-Service.
To verify that you've successfully started the IMAP4 services, use either of the following procedures:
• On the Exchange server, open Windows Task Manager. On the Services tab, verify that
the Status value for the MSExchangeIMAP4 and MSExchangeIMAP4BE services is Running.
• In the Exchange Management Shell, run the following command to verify that the IMAP4 services
are running:
• Get-Service MSExchangeIMAP4; Get-Service MSExchangeIMAP4BE
Step 2: Use the Exchange Management Shell to configure the IMAP4

settings for external clients
To configure the IMAP4 settings for external clients, use the following syntax:
Set-ImapSettings -ExternalConnectionSettings "<FQDN1>:<TCPPort1>:<SSL | TLS | blank>",

"<FQDN2>:<TCPPort2>:<SSL | TLS | blank>"... -X509CertificateName <FQDN> [-SSLBindings
"<IPv4Orv6Address1>:<TCPPort1>","<IPv4Orv6Address2>:<TCPPort2>"...] [-
UnencryptedOrTLSBindings
"<IPv4Orv6Address1>:<TCPPort1>","<IPv4Orv6Address2>:<TCPPort2>"...]
This example allows configures the following settings for external IMAP4 connections:
• IMAP4 server FQDN mail.contoso.com

• TCP port 993 for always TLS encrypted connections, and 143 for unencrypted connections or
opportunistic TLS (STARTTLS) encrypted connections.

Phoenix, AZ 85044 602.490.0911/855.477.7463
• Internal Exchange server IP address and TCP port for always TLS encrypted connections All
available IPv4 and IPv6 addresses on the server on port 993 (we aren't using
the SSLBindings parameter, and the default value is [::]:993,0.0.0.0:993).
• Internal Exchange server IP address and TCP port for unencrypted or opportunistic TLS
(STARTTLS) encrypted connections All available IPv4 and IPv6 addresses on the server on port
143 (we aren't using the UnencryptedOrTLSBindings parameter, and the default value
is [::]:143,0.0.0.0:143).
• FQDN used for encryption mail.contoso.com. This value identifies the certificate that matches
or contains the IMAP4 server FQDN.
Set-ImapSettings -ExternalConnectionSettings
"mail.contoso.com:993:SSL","mail.contoso.com:143:TLS" -X509CertificateName
mail.contoso.com
Notes:
• For detailed syntax and parameter information, see Set-ImapSettings.
• The external IMAP4 server FQDN that you configure needs to have a corresponding
record in your public DNS, and the TCP port (143 or 993) needs to be allowed through
your firewall to the Exchange server.
• The combination of encryption methods and TCP ports that you use for
the ExternalConnectionSettings parameter need to match the corresponding TCP ports and
encryption methods that you use for
the SSLBindings or UnencryptedOrTLSBindings parameters.
• Although you can use a separate certificate for IMAP4, we recommend that you use the
same certificate as the other Exchange IIS (HTTP) services, which is likely a wildcard
certificate or a subject alternative name (SAN) certificate from a commercial certification
authority that's automatically trusted by all clients. For more information, see Certificate
requirements for Exchange services.
• If you use a single subject certificate, or a SAN certificate, you also need to assign the
certificate to the Exchange IMAP service. You don't need to assign a wildcard certificate
to the Exchange IMAP service. For more information, see Assign certificates to Exchange
2016 services.
How you do know this step worked?
To verify that you've successfully configured the IMAP4 settings for external clients, run the
following command in the Exchange Management Shell and verify the settings:
Get-ImapSettings | Format-List *ConnectionSettings,*Bindings,X509CertificateName

Phoenix, AZ 85044 602.490.0911/855.477.7463
For more information, see Get-IMAPSettings.
Step 3: Restart the IMAP4 services
After you enable and configure IMAP4, you need to restart the IMAP4 services on the server by
using the Windows Services console, or the Exchange Management Shell.
Use the Windows Services console to restart the IMAP4 services
1. On the Exchange server, open the Windows Services console.

2. In the list of services, select Microsoft Exchange IMAP4, and then click Action > Restart.
3. In the list of services, select Microsoft Exchange IMAP4 Backend, and then
click Action > Restart.
Use the Exchange Management Shell to restart the IMAP4 services
Run the following command to restart the IMAP4 services.
Restart-Service MSExchangeIMAP4; Restart-Service MSExchangeIMAP4BE
For more information about this cmdlet, see Restart-Service.
To verify that you've successfully restarted the IMAP4 services, run the following command:
Get-Service MSExchangeIMAP4; Get-Service MSExchangeIMAP4BE
Step 4: Configure the authenticated SMTP settings for IMAP4 clients
Because IMAP4 isn't used to send email messages, you need to configure the authenticated
SMTP settings that are used by internal and external IMAP4 clients. For more information,
see Configure authenticated SMTP settings in Exchange 2016 for POP3 and IMAP4 clients.

To verify that you have enabled and configured IMAP4 on the Exchange server, perform the
following procedures:

Phoenix, AZ 85044 602.490.0911/855.477.7463
2. Click Mail > Accounts > POP and IMAP and verify the correct IMAP4 settings are
displayed.
Note: If you configured 993/SSL and 143/TLS values for the ExternalConnectionSettings parameter
on the Set-ImapSettings cmdlet, only the 993/SSL value is displayed in Outlook on the web. Also,
if the external IMAP4 settings that you configured don't appear as expected in Outlook on the
web after you restart the IMAP4 services, run the command iisreset.exe /noforce to restart
Internet Information Services (IIS).

Phoenix, AZ 85044 602.490.0911/855.477.7463
3. You can test IMAP4 client connectivity to the Exchange server by using the following
methods:
• Internal clients Use the Test-ImapConnectivity cmdlet. For example, Test-
ImapConnectivity -ClientAccessServer<ServerName> -Lightmode -
MailboxCredential (Get-Credential). For more information, see Test-
ImapConnectivity.
• Note: The Lightmode switch tells the command test IMAP4 logons to the server. To test
sending (SMTP) and receiving (IMAP4) a message, you need to configure the
authenticated SMTP settings as described in Configure authenticated SMTP settings in
Exchange 2016 for POP3 and IMAP4 clients.
• External clients Use the Exchange Server > Imap Email test in the Microsoft Remote
Connectivity Analyzer at http://go.microsoft.com/fwlink/p/?LinkID=313840.
Note: You can't use IMAP4 to connect to the Administrator mailbox. This limitation was
intentionally included in Exchange 2016 to enhance the security of the Administrator mailbox.
Configure authenticated SMTP settings for POP3 and

IMAP4 clients in Exchange 2016
Learn how to configure the authenticated SMTP settings on an Exchange 2016 server that are
required by POP3 or IMAP4 clients to send email messages.
After you enable and configure POP3 or IMAP4 on an Exchange 2016 server as described
in Enable and configure POP3 on an Exchange 2016 server and Enable and configure IMAP4 on an
Exchange 2016 server, you need to configure the authenticated SMTP settings for POP3 and
IMAP4 clients so they can send email messages.
The default Receive connector named "Client Frontend <Server name>" in the Client Access
services on the Mailbox server listens for authenticated SMTP client submissions on port 587. By
default, this connector uses the following settings for internal and external client (authenticated)
SMTP connections:
• SMTP server <ServerFQDN>. For example, mailbox01.contoso.com.

• TCP port 587
• Encryption method TLS. Note that this is opportunistic TLS (STARTTLS) that results in an
encrypted connection after the initial plain text protocol handshake.

Phoenix, AZ 85044 602.490.0911/855.477.7463
For more information, see Default Receive connectors created during setup and Client access protocol
architecture.
To configure the authenticated SMTP settings that are used by POP3 and IMAP4 clients, perform
the following steps:
1. Configure the FQDN on the "Client Frontend <Server name>" Receive connector.
2. Specify the certificate that's used to encrypt authenticated SMTP client connections.
3. Configure Outlook on the web (formerly known as Outlook Web App) to display the
SMTP settings for authenticated SMTP clients
at Settings > Options > Mail > Accounts > POP and IMAP.
For more information about POP3 and IMAP4, see POP3 and IMAP4 in Exchange 2016.

• Estimated time to complete: 5 minutes.
• Secure Sockets Layer (SSL) is being replaced by Transport Layer Security (TLS) as the
protocol that's used to encrypt data sent between computer systems. They’re so closely
related that the terms "SSL" and "TLS" (without versions) are often used interchangeably.
Because of this similarity, references to "SSL" in Exchange topics, the Exchange admin

Phoenix, AZ 85044 602.490.0911/855.477.7463
center, and the Exchange Management Shell have often been used to encompass both
the SSL and TLS protocols. Typically, "SSL" refers to the actual SSL protocol only when a
version is also provided (for example, SSL 3.0). To find out why you should disable the
SSL protocol and switch to TLS, check out Protecting you against the SSL 3.0 vulnerability.
• If you have POP3 or IMAP4 clients that can only send SMTP email on port 25, you can
configure port 25 on the "Client Frontend <Server name>" Receive connector to allow
clients to send authenticated SMTP email. However, because port 25 is also configured
on the "Client Frontend <Server name>" Receive connector for email from external SMTP
servers, you'll need to modify the local IP addresses that are used to listen on port 25 on
one or both of the connectors. For more information, see Receive connector local address
bindings.
procedures. To see what permissions you need, see the "Receive connectors" entry in
the Mail flow permissions topic.
Tip:
How do you do this?
Step 1: Configure the FQDN on the "Client Frontend <Server name>"

Receive connector
You can skip this step if you want to keep the default server FQDN value (for example,
mailbox01.contoso.com). Or, you can specify an FQDN value that's more compatible with your
Internet naming convention or a TLS certificate that you want to use.

Phoenix, AZ 85044 602.490.0911/855.477.7463
If you change the FQDN value, and you want internal POP3 or IMAP4 clients to use this
connector to send email, the new FQDN needs to have a corresponding record in your internal
DNS.
Regardless of the FQDN value, if you want external POP3 or IMAP4 clients to use this connector
to send email, the FQDN needs to have a corresponding record in your public DNS, and the TCP
port (587) needs to be allowed through your firewall to the Exchange server.
Use the EAC to configure the FQDN for authenticated SMTP clients
1. In the EAC, go to Mail flow > Receive connectors.

2. In the list of Receive connectors, select Client Frontend <Server name>, and then
click Edit ( ).
3. In the Exchange Receive Connector page that opens, click Scoping.
4. In the FQDN field, enter the SMTP server FQDN that you want to use for authenticated
SMTP client connections (for example, mail.contoso.com) and then click Save.

Phoenix, AZ 85044 602.490.0911/855.477.7463
Use the Exchange Management Shell to configure the FQDN for authenticated SMTP clients
To configure the FQDN for authenticated SMTP clients, use the following syntax:
Get-ReceiveConnector -Identity "Client Frontend*" | Set-ReceiveConnector -Fqdn <FQDN>

Phoenix, AZ 85044 602.490.0911/855.477.7463
This example configures the FQDN value mail.contoso.com.
Get-ReceiveConnector -Identity "Client Frontend*" | Set-ReceiveConnector -Fqdn

mail.contoso.com
To verify that you've successfully the FQDN on the "Client Frontend <Server name>" Receive
connector, use either of the following procedures:
• the EAC, go to Mail flow > Receive connectors > select Client Frontend <Server name>,
click Edit ( ) > Scoping, and verify the value in the FQDN field.
• In the Exchange Management Shell, run the following command:
• Get-ReceiveConnector -Identity "Client Frontend*" | Format-List Name,Fqdn
Step 2: Use the Exchange Management Shell to specify the certificate

that's used to encrypt authenticated SMTP client connections
The certificate needs to match or contain the FQDN value that you specified in the previous
step, and the POP3 and SMTP clients need to trust the certificate, which likely means a certificate
from a commercial certification authority. For more information, see Certificate requirements for
Exchange services.
Also, you need to assign the certificate to the Exchange SMTP service. For more information,
see Assign certificates to Exchange 2016 services.
To specify the certificate that's used for authenticated SMTP client connections, use the
following syntax:
$TLSCert = Get-ExchangeCertificate -Thumbprint <ThumbprintValue>
$TLSCertName = "<I>$($TLSCert.Issuer)<S>$($TLSCert.Subject)"
Get-ReceiveConnector -Identity "Client Frontend*" | Set-ReceiveConnector -TlsCertificateName

$TLSCertName
To verify that you've specified the certificate that's used to encrypt authenticated SMTP client
connections, perform the following steps:

Phoenix, AZ 85044 602.490.0911/855.477.7463
1. Run the following command in the Exchange Management Shell:
2. Get-ReceiveConnector -Identity "Client Frontend*" | Format-List
Name,Fqdn,TlsCertificateName
3. Run the following command in the Exchange Management Shell:
4. Get-ExchangeCertificate | Format-List
Thumbprint,Issuer,Subject,CertificateDomains,Services
5. Verify the Subject or CertificateDomains field of the certificate that you specified on the
Receive connector contains the Fqdn value of the Receive connector (exact match or
wildcard match).
Step 3: Use the Exchange Management Shell to configure Outlook on the

web to display the SMTP settings for authenticated SMTP clients
To configure Outlook on the web to display the SMTP settings server for authenticated SMTP
clients, run the following command:
Get-ReceiveConnector -Identity "Client Frontend*" | Set-ReceiveConnector -

AdvertiseClientSettings $true
Note: To prevent the SMTP settings from being displayed in Outlook on the web, change the
value from $true to $false.
To verify that you've configured Outlook on the web to display the SMTP settings for
authenticated SMTP clients, perform the following steps:

Phoenix, AZ 85044 602.490.0911/855.477.7463
2. Click Mail > Accounts > POP and IMAP and verify the correct SMTP settings are displayed.
Note: If the SMTP settings that you configured don't appear as expected in Outlook on the web,
run the command iisreset.exe /noforce to restart Internet Information Services (IIS).

To verify that you've configured the authenticated SMTP settings on the Exchange server,
perform one or more following procedures:

Phoenix, AZ 85044 602.490.0911/855.477.7463
• Use the Test-PopConnectivity or Test-ImapConnectivity cmdlets, which use authenticated
SMTP to send test messages. For more information, see Test-PopConnectivity and Test-
ImapConnectivity.
• Enable protocol logging on the "Client Frontend <Server name>" Receive connector,
configure a POP3 or IMAP4 client to connect to a mailbox, send a test message from an
internal network connection and/or an external Internet connection, and view the results
in the protocol log. For more information, see Protocol logging.
• Note: You can't use POP3 or IMAP4 to connect to the Administrator mailbox. This
limitation was intentionally included in Exchange 2016 to enhance the security of the
Administrator mailbox.
Setting up an email client
DMZ port configuration
Port 443
Exchange admin center
https://qualtechdevex1.qualtechcloud.com/ecb
Outlook online
https://qualtechdevex1.qualtechcloud.com/owa
Port 587
This is the secure inbound SMTP receive connector configured in the Client Frontend connector.

Phoenix, AZ 85044 602.490.0911/855.477.7463
Figure 21: Client Frontend receive connector.
In the properties of the Client Frontend connector the FQDN property to the external FQDN as
in qualtechdevex1.qualtechcloud.com.

Phoenix, AZ 85044 602.490.0911/855.477.7463
Figure 22: Client Frontend HELO FQDN
Port 143 and 993

These are the unsecure and secure IMAP4 respectively.
Port 110 and 995

These are the unsecure and secure POP3 respectively.

Phoenix, AZ 85044 602.490.0911/855.477.7463
Multitenancy
Adding users
Tasks
We already structure customers in the AD the way it’s required. We have a top OU called
Customers and inside this OU we create a new OU for each customer. This is a good structure to
manage customers and it’s required for SP and Exchange.
1. Create AD STructure and UPN Suffix

2. Setting up Exchange server for new Tenant
3. Add a new domain for the new Tenant
4. Global Address List (GAL) for Tenant0001
5. All Rooms Address List
6. All Users Address List
7. All Contacts Address List
8. All Groups Address List
9. Offline Address Book
10. Email Address Policy
11. Address Book Policy
12. Resourcea management by creating a Room Mailbox
13. Creating a new user for our Tenant0001
Create AD Structure and UPN Sufix
We already use the proper AD structure. We have a top OU called Customers and inside this OU
we have 1 OU for each customer. Nothing to do here.
If the user is just a single user we will use our domain which will be mail1.qualtechmail.com.
If it is a business with multiple users and they would like to use their own domain name we’ll
have to add a new USPN to the AD:
Ex:
Set-ADForest -Identity qtdev.qualtechcloud.com -UPNSuffixes @{add=”qualtehcybersec.com”}

Phoenix, AZ 85044 602.490.0911/855.477.7463
Setting up Exchange server for new Tenant
Add a new domain for the new tenant
New-AcceptedDomain -Name "Tenant00001" -DomainName domain.new -

DomainType:Authoritative
Ex:
New-AcceptedDomain -Name “QualTechCyberSec” -DomainName qualtechcybersec.com -

DomainType:Authoritative
Figure 23: Accepted domains.
Global Address List (GAL) for Tenant00001
New-GlobalAddressList -Name "Tenant00001 – GAL" -

ConditionalCustomAttribute1 "Tenant00001" -IncludedRecipients MailboxUsers
-RecipientContainer "domain.dmz/Customers/Tenant00001"
Ex:
New-GlobalAddressList -Name “QualTechCyberSec – GAL” -ConditionalCustomAttribute1

“QualTechCyberSec” -IncludedRecipients MailboxUsers -RecipientContainer
“qtdev.qualtechcloud.com/Customers/QualTechCyberSec”

Phoenix, AZ 85044 602.490.0911/855.477.7463
Figure 24: Address lists

Phoenix, AZ 85044 602.490.0911/855.477.7463
Figure 25: The global address list custom attribute.
All Rooms Address List
New-AddressList -Name "Tenant00001 – All Rooms" -RecipientFilter

"(CustomAttribute1 -eq 'Tenant00001') -and (RecipientDisplayType -eq
'ConferenceRoomMailbox')" -RecipientContainer
"domain.dmz/Customers/Tenant00001"
All Users Address List

Phoenix, AZ 85044 602.490.0911/855.477.7463
New-AddressList -Name "Tenant00001 – All Users" -RecipientFilter
"(CustomAttribute1 -eq 'Tenant00001') -and (ObjectClass -eq 'User')" -
RecipientContainer "domain.dmz/Customers/Tenant00001"
All Contacts Address List
New-AddressList -Name "Tenant00001 – All Contacts" -RecipientFilter

"(CustomAttribute1 -eq 'Tenant00001') -and (ObjectClass -eq 'Contact')" -
All Groups Address List
New-AddressList -Name "Tenant00001 – All Groups" -RecipientFilter

"(CustomAttribute1 -eq 'Tenant00001') -and (ObjectClass -eq 'Group')" -
Offline Address Book
New-OfflineAddressBook -Name "Tenant00001" -AddressLists "Tenant00001 –

GAL"
Email Address Policy
You’ll also need to create an Email Address Policy. This example also includes first.last@domain
email aliasing, or you can set the primary email address to first.last@domain by using the -
EnabledPrimarySMTPAddressTemplate “SMTP:%g.%s@domain.new” attribute and data.
Note: strictly speaking, you don’t need to create an email address policy.
New-EmailAddressPolicy -Name "Tenant00001 – EAP" -RecipientContainer

"domain.dmz/Customers/Tenant00001" -IncludedRecipients "AllRecipients" -
ConditionalCustomAttribute1 "Tenant00001" -EnabledEmailAddressTemplates
"SMTP:%g.%s@domain.new","smtp:%m@domain.new"

Phoenix, AZ 85044 602.490.0911/855.477.7463
Address Book Policy
The Address Book Policy is what ties everything together. Here we create a policy containing all
the different Address Lists and Books we created in Step 2. This Address Book Policy can then be
assigned to individual users.
New-AddressBookPolicy -Name "Tenant00001" -AddressLists "Tenant00001 – All

Users", "Tenant00001 – All Contacts", "Tenant00001 – All Groups" -
GlobalAddressList "Tenant00001 – GAL" -OfflineAddressBook "Tenant00001" -
RoomList "Tenant00001 – All Rooms"
Resource management by creating a Room Mailbox.
This step is not needed, but you might need it for your setup.
Here we create a new Room Mailbox for ressources. Note how the Adress Book Policy is assigned
to the new mailbox using the -AddressBookPolicy parameter.
New-Mailbox -Name 'Tenant00001 Conference Room 1' -Alias

'Tenant00001_conf1' -OrganizationalUnit 'domain.new/Customers/Tenant00001'
-UserPrincipalName 'confroom1@domain.new' -SamAccountName
'Tenant00001_conf1' -FirstName 'Conference' -LastName 'Room 1' -
AddressBookPolicy 'Tenant00001' -Room
It is vital that we set a Custom Attribute for the mailbox, or it will not be included by the Address
Book Policy we just created.
Set-Mailbox Tenant00001_conf1 -CustomAttribute1 'Tenant00001'
Here we set up how requests for our resources are processed.
Set-CalendarProcessing -Identity Tenant00001_conf1 -AutomateProcessing

AutoAccept -DeleteComments $true -AddOrganizerToSubject $true -
AllowConflicts $false

Phoenix, AZ 85044 602.490.0911/855.477.7463
Notes
We only create a room mailbox if a customer requests it.
Creating a new user for our Tenant0001
Notes
This is here just as an example. We add the users to the customer OU in the AD so instead of
creating a new mailbox in Exchange which will create the user in the AD we create a mailbox
for an existing AD user.
In creating the new User with a mailbox, we specify location in AD and assign the Address Book
Policy we created.
The password is entered using the popup that shows using the first line $c = Get-Credential
For the ‘username’ field you can type anything you want as it is the password attribute we want for
the mailbox being created.
$c = Get-Credential
New-Mailbox -Name 'Morten Nielsen' -Alias 'tenant00001_morten' -

OrganizationalUnit 'domain.dmz/Customers/Tenant00001' -UserPrincipalName
'morten@domain.new' -SamAccountName 'tenant00001_morten' -FirstName
'Morten' -LastName 'Nielsen' -Password $c.password -
ResetPasswordOnNextLogon $false -AddressBookPolicy 'Tenant00001'
As with a room mailbox we need to also set a custom attribute to the tenant. This step cannot
be performed in the same step as when you create the mailbox.
Set-Mailbox morten@domain.new -CustomAttribute1 "Tenant00001"
Create mailbox for and existing AD user

Phoenix, AZ 85044 602.490.0911/855.477.7463
In the Exchange Admin Center select recipients. Click the plus sign to create a new user mailbox.
Figure 26: Create a new user mailbox.
Type the alias for the user as first.last.
Browse for an existing user and select the user you want to create the mailbox for and save.

Phoenix, AZ 85044 602.490.0911/855.477.7463
Figure 27: Select existing AD user
Double click the newly created mailbox or select it and click the edit button from the toolbar to
edit the mailbox.
In the Edit User Mailbox form select mailbox features and from the Address book policy
dropdown select the address book policy we created above (QualTechCyberSec) and save.

Phoenix, AZ 85044 602.490.0911/855.477.7463
Figure 28: Add the addressbook policy to the mailbox.
Select the email address and change the domain in the email address to match the customers
domain (tony.amaral@qualtechcybersec.com).
Deploy and Configure a DAG server

There are three requirements we need to meet:
• The Exchange Trusted Subsystem group in Active Directory must be added to the local
Administrators group on the server that will be the file share witness.
• The File Server feature (FS-FileServer) must be installed on the file share witness

Phoenix, AZ 85044 602.490.0911/855.477.7463
• File and Print Sharing must be allowed through the Windows Firewall if the firewall is
enabled
• Windows failover clustering.
Use the EAC to create a database availability group

5. In the EAC, go to Servers > Database Availability Groups.
6. Click to create a DAG.
7. On the new database availability group page, provide the following information for the
DAG:
• Database availability group name Use this field to type a valid and unique name for the
DAG of up to 15 characters. The name is equivalent to a computer name, and a
corresponding CNO will be created in Active Directory with that name. This name will be
both the name of the DAG and the name of the underlying cluster.
• Witness server Use this field to specify a witness server for the DAG. If you leave this
field blank, the system will attempt to automatically select an Exchange server with Client
Access services that is in the local Active Directory site.
Note:
If you specify a witness server, you must use either a host name or a fully
qualified domain name (FQDN). Using an IP address or a wildcard name isn't
supported. In addition, the witness server can't be a member of the DAG.
• Witness directory Use this field to type the path to a directory on the witness server that
will be used to store witness data. If the directory doesn't exist, the system will create it
for you on the witness server. If you leave this field blank, the default directory
(%SystemDrive%\DAGFileShareWitnesses\<DAG FQDN>) will be created on the witness
server.
• Database availability group IP addresses Use this field to assign one or more static IPv4
addresses to the DAG. Enter an IPv4 address and click to add it. Leave this field blank if
you want the DAG to use Dynamic Host Configuration Protocol (DHCP) to obtain the
necessary IPv4 addresses. Optionally, enter 255.255.255.255 to create a DAG without an

Phoenix, AZ 85044 602.490.0911/855.477.7463
IP address or cluster administrative access point, which applies only to DAGs that will
contain Mailbox servers running Windows Server 2012 R2.
1. Click Save to create the DAG.
Figure 29: New DAG.
Use the Exchange Management Shell to create a database availability group
The following example creates a DAG named DAG1, which is configured to use the witness
server FILESRV1 and the local directory C:\DAG1. DAG1 is also configured to use DHCP for the
DAG's IP addresses.
New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer FILESRV1 -WitnessDirectory

C:\DAG1
The next example creates a DAG named DAG2. For the DAG's witness server, the system
automatically selects an Exchange 2016 server with Client Access services that is in the local
Active Directory site. DAG2 is assigned a single static IP address because in this example all DAG
members have the MAPI network on the same subnet.
New-DatabaseAvailabilityGroup -Name DAG2 -DatabaseAvailabilityGroupIPAddresses 10.0.0.8

Phoenix, AZ 85044 602.490.0911/855.477.7463
This example creates the DAG DAG3. DAG3 is configured to use the witness server MBX2 and
the local directory C:\DAG3. DAG3 is assigned multiple static IP addresses because its DAG
members are on different subnets on the MAPI network.
New-DatabaseAvailabilityGroup -Name DAG3 -WitnessServer MBX2 -WitnessDirectory C:\DAG3

-DatabaseAvailabilityGroupIPAddresses 10.0.0.8,192.168.0.8
This example creates the DAG DAG4 that's configured to use DHCP. In addition, the witness
server will be automatically selected by the system, and the default witness directory will be
created.
New-DatabaseAvailabilityGroup -Name DAG4
This example creates the DAG DAG5 that will not have an administrative access point (valid for
Windows Server 2012 R2 DAGs only). In addition, MBX4 will be used as the witness server for the
DAG, and the default witness directory will be created.
New-DatabaseAvailabilityGroup -Name DAG5 -DatabaseAvailabilityGroupIPAddresses

([System.Net.IPAddress]::None) -WitnessServer MBX4
Notes
After the DAG is created we need to do a few checks.
First off make sure you added an IP address to the DAG.
Open the Active Directory Users and Computers, select View>Advanced features.
1. In the Computers OU locate the DAG by the name you named it during creation.

Phoenix, AZ 85044 602.490.0911/855.477.7463
Figure 30: DAG AD object.
2. Select the DAG, right click and select properties.

3. In the General tab if the DNS name is empty, go to the Attribute Editor tab and edit
the attribute dNSHostName and the FQDN of the DAG
(dag1.qtdev.qualtechcloud.com).
4. Click OK and wait for AD replication (or execute gpupdate). Then try to the re-add the
servers to the DAG.
5. Add an A record to the DNS server.
If you come across the error “A computer account name <dag name> already exists and is
enable” do the following:
1. Go to Active Directory Users and Computers

Phoenix, AZ 85044 602.490.0911/855.477.7463
2. In ADUC be sure to turn on View > Advanced Features
3. Search for a computer object that represents your DAG. ie So if you name your DAG
“Exchange2013DAG” you will have a computer object with the same name.
4. Right Click > Disable
5. Wait for AD replication and retry to add new server to the DAG
Windows Failover Clustering must be installed on servers being added to the DAG.
If you get the error:
Access was denied. Check that the current user (NT AUTHORITY\SYSTEM) has permissions to
create computer accounts in the domain or to claim the computer account.
Check the fix on this link

To verify that you've successfully created a DAG, do one of the following:
• In the EAC, navigate to Servers > Database Availability Groups. The newly created DAG is
displayed.
• In the Exchange Management Shell, run the following command to verify the DAG was
created and to display DAG property information.
• Get-DatabaseAvailabilityGroup <DAGName> | Format-List
Manage database availability group membership
When you add a server to a DAG, the server works with the other DAG members to provide
automatic database-level recovery from database, server, or network failures. When you remove
a server from a DAG, the server is no longer automatically protected from failures.

Phoenix, AZ 85044 602.490.0911/855.477.7463
• Estimated time to complete: 5 minutes per server
procedures. To see what permissions you need, see the "Database availability groups"
entry in the High availability and site resilience permissions topic.
• DAGs use Windows Failover Clustering (WFC) technologies. Each Mailbox server that's a
member of a DAG is also a node in the underlying cluster used by the DAG. As a result,
at any specific time, a Mailbox server can be a member of only one DAG. Because DAGs
use WFC technology, all servers added to a DAG must be running the same operating
system: either Windows Server 2008 R2 Enterprise or Datacenter Edition, or the Standard
or Datacenter Edition of Windows Server 2012 or Windows Server 2012 R2.
• If you're adding Mailbox servers running Windows Server 2012, you must pre-stage the
cluster name object (CNO) for the DAG. If you’re adding Mailbox servers running
Windows Server 2012 R2, and your DAG does not have an administrative access point,
then you do not need to pre-stage a CNO, as DAGs without administrative access points
do not have a CNO. For detailed steps, see Pre-stage the cluster name object for a database
availability group.
• Before you can add members to a DAG, you must first create a DAG. For detailed steps,
see Create a database availability group.
• You must remove all replicated database copies from the server before you can remove
it from a DAG.
Tip:
What do you want to do?

Phoenix, AZ 85044 602.490.0911/855.477.7463
Use the EAC to manage database availability group membership
1. In the EAC, go to Servers > Database Availability Groups.

2. Select the DAG you want to configure, and then click .
• To add one or more Mailbox servers to the DAG, click , select the servers from the list,
click Add, and then click OK.
• To remove one or more Mailbox servers from the DAG, select the servers, and then click
the minus (-) icon.
3. Click Save to save the changes.
4. When the task has completed successfully, click Close.
Use the Shell to manage database availability group membership
This example adds the Mailbox server MBX1 to the DAG DAG1.
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX1
This example removes the Mailbox server MBX1 from the DAG DAG1. Before running this
command, make sure that no replicated databases exist on the Mailbox server.
Remove-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX1
This example removes the configuration settings for the Mailbox server MBX4 from the DAG
DAG2. MBX4 is expected to be offline for an extended period, so its configuration is being
removed from the DAG while it's offline to establish quorum with the remaining online DAG
members.
Remove-DatabaseAvailabilityGroupServer -Identity DAG2 -MailboxServer MBX4 -

ConfigurationOnly

To verify that you've successfully managed DAG membership, do one of the following:
• In the EAC, navigate to Servers > Database Availability Groups. The current DAG
membership is displayed in the Member Servers column.
• In the Shell, run the following command to display DAG membership information.
• Get-DatabaseAvailabilityGroup <DAGName> | Format-List Servers

Phoenix, AZ 85044 602.490.0911/855.477.7463
DAG membership
After a DAG has been created, you can add servers to or remove servers from the DAG using the
Manage Database Availability Group wizard in the EAC, or using the Add-
DatabaseAvailabilityGroupServer or Remove-DatabaseAvailabilityGroupServer cmdlets in
the Exchange Management Shell. For detailed steps about how to manage DAG membership,
see Manage database availability group membership.
Note:
Each Mailbox server that's a member of a DAG is also a node in the underlying cluster used
by the DAG. As a result, at any one time, a Mailbox server can be a member of only one DAG.
If the Mailbox server being added to a DAG doesn't have the failover clustering component
installed, the method used to add the server (for example, the Add-
DatabaseAvailabilityGroupServer cmdlet or the Manage Database Availability Group wizard)
installs the failover clustering feature.
When the first Mailbox server is added to a DAG, the following occurs:
• The Windows failover clustering component is installed, if it isn't already installed.

• A failover cluster is created using the name of the DAG. This failover cluster is used
exclusively by the DAG, and the cluster must be dedicated to the DAG. Use of the cluster
for any other purpose isn't supported.
• A CNO is created in the default computers container.
• The name and IP address of the DAG is registered as a Host (A) record in Domain Name
System (DNS).
• The server is added to the DAG object in Active Directory.
• The cluster database is updated with information on the databases mounted on the
added server.
Notes
1. If you get errors adding the servers to the DAG follow the steps below.

Phoenix, AZ 85044 602.490.0911/855.477.7463
The server to be used as witness has to be added to the Exchange Trusted System or you’ll
get the error
A server-side database availability group administrative operation failed. Error The
operation failed. CreateCluster errors may result from incorrectly configured static
addresses. Error: Windows Failover Clustering isn't installed on 'EXCH2K16.test.com'..
[Server: EXCH2K16.test.com]
error
Add the name of the DAG to the DNS server or you’ll get the error
DumpClusterTopology: Failed opening with

Microsoft.Exchange.Cluster.Shared.AmGetFqdnFailedNotFoundException: The fully qualified
domain name for node 'DAG1' could not be found.

Phoenix, AZ 85044 602.490.0911/855.477.7463
at
Microsoft.Exchange.Cluster.Shared.AmServerNameCache.<>c__DisplayClass1.<ResolveFqdn>
b__0(Object param0, EventArgs param1)
at Microsoft.Exchange.Cluster.Shared.SharedHelper.RunADOperationEx(EventHandler ev)
at Microsoft.Exchange.Cluster.Shared.AmServerNameCache.ResolveFqdn(String
shortNodeName, Boolean throwException)
at Microsoft.Exchange.Cluster.Shared.AmServerNameCache.GetFqdn(String
shortNodeName, Boolean throwException)
at Microsoft.Exchange.Cluster.Shared.AmServerName..ctor(String serverName, Boolean
throwOnFqdnError)
at
Microsoft.Exchange.Management.SystemConfigurationTasks.DumpClusterTopology..ctor(Strin
g nameCluster, ITaskOutputHelper output)
If it continues to fail look in the log file and see the message that says to restart the computer
[2017-04-08T00:46:12] Working
[2017-04-08T00:46:12] Running PS> Import-Module -Name ServerManager
[2017-04-08T00:46:13] Running PS> Add-WindowsFeature -Name RSAT-Clustering -
IncludeAllSubFeature
[2017-04-08T00:46:14] Produced result: Success: True, ExitCode: NoChangeNeeded,
RestartNeeded: Yes
[2017-04-08T00:46:14] Warning: Please restart this computer before adding or removing roles
or features.
[2017-04-08T00:46:14] Running PS> Import-Module -Name ServerManager
[2017-04-08T00:46:14] Running PS> Add-WindowsFeature -Name Failover-Clustering -
IncludeAllSubFeature
[2017-04-08T00:46:14] Produced result: Success: True, ExitCode: NoChangeNeeded,
RestartNeeded: Yes
[2017-04-08T00:46:14] Warning: Please restart this computer before adding or removing roles
or features.
[2017-04-08T00:46:14] Updated Progress 'The task has installed the Windows Failover
Clustering component.' 4%.
[2017-04-08T00:46:14] Working
Error:
WriteError! Exception = Microsoft.Exchange.Cluster.Replay.DagTaskOperationFailedException:

A server-side database availability group administrative operation failed. Error The operation

Phoenix, AZ 85044 602.490.0911/855.477.7463
failed. CreateCluster errors may result from incorrectly configured static addresses. Error: An
error occurred while attempting a cluster operation. Error: Cluster API failed: "CreateCluster()
failed with 0x5. Error: Access is denied". --->
Microsoft.Exchange.Cluster.Shared.ClusterApiException: An error occurred while attempting a
cluster operation. Error: Cluster API failed: "CreateCluster() failed with 0x5. Error: Access is
denied" ---> System.ComponentModel.Win32Exception: Access is denied
Give full control to the Exchange Trusted Subsystem in the DAG in the AD.
Disable the DAG account before re adding the server

Phoenix, AZ 85044 602.490.0911/855.477.7463
Error:
In the Failover Cluster Manager;
Cluster network name resource 'Cluster Name' failed registration of one or more
associated DNS name(s) for the following reason:
DNS operation refused.
Solution:
Delete the existing A record for the cluster name and re-create it and make sure select the
box says “Allow any authenticated user to update DNS record with the same owner name
“Don’t worry about breaking anything , this has “ZERO” impact to cluster simply delete the A
record and re-create as it is suggested here
http://mxlookup.online-domain-tools.com/
In a large or multiple site environment, especially those in which the DAG is extended to
multiple Active Directory sites, you must wait for Active Directory replication of the DAG object
containing the first DAG member to complete. If this Active Directory object isn't replicated
throughout your environment, adding the second server may cause a new cluster (and new
CNO) to be created for the DAG. This is because the DAG object appears empty from the
perspective of the second member being added, thereby causing the Add-
DatabaseAvailabilityGroupServer cmdlet to create a cluster and CNO for the DAG, even
though these objects already exist. To verify that the DAG object containing the first DAG server
has been replicated, use the Get-DatabaseAvailabilityGroup cmdlet on the second server
being added to verify that the first server you added is listed as a member of the DAG.
When the second and subsequent servers are added to the DAG, the following occurs:
• The server is joined to the Windows failover cluster for the DAG.
• The quorum model is automatically adjusted:
o A Node Majority quorum model is used for DAGs with an odd number of
members.
o A Node and File Share Majority quorum model is used for DAGs with an even
number of members.
• The witness directory and share are automatically created by Exchange when needed.
• The server is added to the DAG object in Active Directory.
• The cluster database is updated with information about mounted databases.

Phoenix, AZ 85044 602.490.0911/855.477.7463
Note:
The quorum model change should happen automatically. However, if the quorum model
doesn't automatically change to the proper model, you can run the Set-
DatabaseAvailabilityGroup cmdlet with only the Identity parameter to correct the quorum
settings for the DAG.
Pre-staging the cluster name object for a DAG
The CNO is a computer account created in Active Directory and associated with the cluster's
Name resource. The cluster's Name resource is tied to the CNO, which is a Kerberos-enabled
object that acts as the cluster's identity and provides the cluster's security context. The
formation of the DAG's underlying cluster and the CNO for that cluster is performed when the
first member is added to the DAG. When the first server is added to the DAG, remote PowerShell
contacts the Microsoft Exchange Replication service on the Mailbox server being added. The
Microsoft Exchange Replication service installs the failover clustering feature (if it isn't already
installed) and begins the cluster creation process. The Microsoft Exchange Replication service
runs under the LOCAL SYSTEM security context, and it's under this context in which cluster
creation is performed.
Warning:
If your DAG members are running Windows Server 2012, you must pre-stage the CNO prior
to adding the first server to the DAG. If your DAG members are running Windows Server
2012 R2, and you create a DAG without a cluster administrative access point, then a CNO will
not be created, and you do not need to create a CNO for the DAG.

Phoenix, AZ 85044 602.490.0911/855.477.7463
In environments where computer account creation is restricted, or where computer accounts are
created in a container other than the default computers container, you can pre-stage and
provision the CNO. You create and disable a computer account for the CNO, and then either:
• Assign full control of the computer account to the computer account of the first Mailbox
server you're adding to the DAG.
• Assign full control of the computer account to the Exchange Trusted Subsystem USG.
Assigning full control of the computer account to the computer account of the first Mailbox
server you're adding to the DAG ensures that the LOCAL SYSTEM security context will be able to
manage the pre-staged computer account. Assigning full control of the computer account to
the Exchange Trusted Subsystem USG can be used instead because the Exchange Trusted
Subsystem USG contains the machine accounts of all Exchange servers in the domain.
For detailed steps about how to pre-stage and provision the CNO for a DAG, see Pre-stage the
cluster name object for a database availability group.
Removing servers from a DAG

Mailbox servers can be removed from a DAG by using the Manage Database Availability Group
wizard in the EAC or the Remove-DatabaseAvailabilityGroupServer cmdlet in the Exchange
Management Shell. Before a Mailbox server can be removed from a DAG, all replicated mailbox
databases must first be removed from the server. If you attempt to remove a Mailbox server
with replicated mailbox databases from a DAG, the task fails.
There are scenarios in which you must remove a Mailbox server from a DAG before performing
certain operations. These scenarios include:
• Performing a server recovery operation If a Mailbox server that's a member of a DAG

is lost, or otherwise fails and is unrecoverable and needs replacement, you can perform a
server recovery operation using the Setup /m:RecoverServer switch. However, before
you can perform the recovery operation, you must first remove the server from the DAG
using the Remove-DatabaseAvailabilityGroupServer cmdlet with
the ConfigurationOnly parameter.
• Removing the database availability group There may be situations in which you need
to remove a DAG (for example, when disabling third-party replication mode). If you need
to remove a DAG, you must first remove all servers from the DAG. If you attempt to
remove a DAG that contains any members, the task fails.

Phoenix, AZ 85044 602.490.0911/855.477.7463
Return to top
Configuring DAG properties

After servers have been added to the DAG, you can use the EAC or the Exchange Management
Shell to configure the properties of a DAG, including the witness server and witness directory
used by the DAG, and the IP addresses assigned to the DAG.
Configurable properties include:
• Witness server The name of the server that you want to host the file share for the file
share witness. We recommend that you specify a server running Client Access services as
the witness server. This enables the system to automatically configure, secure, and use
the share, as needed, and enables the messaging administrator to be aware of the
availability of the witness server.
• Witness directory The name of a directory that will be used to store file share witness
data. This directory will automatically be created by the system on the specified witness
server.
• Database availability group IP addresses One or more IP addresses must be assigned
to the DAG, unless the DAG members are running Windows Server 2012 R2 and you are
creating a DAG without an IP address. Otherwise, the DAG’s IP addresses can be
configured using manually assigned static IP addresses, or they can be automatically
assigned to the DAG using a DHCP server in your organization.
The Exchange Management Shell enables you to configure DAG properties that aren't available
in the EAC, such as DAG IP addresses, network encryption and compression settings, network
discovery, the TCP port used for replication, and alternate witness server and witness directory
settings, and to enable Datacenter Activation Coordination mode.
For detailed steps about how to configure DAG properties, see Configure database availability
group properties.
DAG network encryption
DAGs support the use of encryption by leveraging the encryption capabilities of the Windows
Server operating system. DAGs use Kerberos authentication between Exchange servers.
Microsoft Kerberos security support provider (SSP) EncryptMessage and DecryptMessage APIs
handle encryption of DAG network traffic. Microsoft Kerberos SSP supports multiple encryption

Phoenix, AZ 85044 602.490.0911/855.477.7463
algorithms. (For the complete list, see section 3.1.5.2, "Encryption Types" of Kerberos Protocol
Extensions). The Kerberos authentication handshake selects the strongest encryption protocol
supported in the list: typically Advanced Encryption Standard (AES) 256-bit, potentially with a
SHA Hash-based Message Authentication Code (HMAC) to maintain integrity of the data. For
details, see HMAC.
Network encryption is a property of the DAG and not a DAG network. You can configure DAG
network encryption using the Set-DatabaseAvailabilityGroup cmdlet in the Exchange
Management Shell. The possible encryption settings for DAG network communications are
shown in the following table.
DAG network communication encryption settings
Setting Description
Disabled Network encryption isn't used.
Enabled Network encryption is used on all DAG networks for replication and
seeding.
InterSubnetOnly Network encryption is used on DAG networks when replicating across

different subnets. This is the default setting.
SeedOnly Network encryption is used on all DAG networks for seeding only.
DAG network compression
DAGs support built-in compression. When compression is enabled, DAG network

communication uses XPRESS, which is the Microsoft implementation of the LZ77 algorithm. For
details, see An Explanation of the Deflate Algorithm and section 3.1.4.11.1.2.1 "LZ77 Compression
Algorithm" of Wire Format Protocol Specification. This is the same type of compression used in
many Microsoft protocols, in particular, MAPI RPC compression between Microsoft Outlook and
Exchange.
As with network encryption, network compression is also a property of the DAG and not a DAG
network. You configure DAG network compression by using the Set-

Phoenix, AZ 85044 602.490.0911/855.477.7463
DatabaseAvailabilityGroup cmdlet in the Exchange Management Shell. The possible compression
settings for DAG network communications are shown in the following table.
DAG network communication compression settings
Setting Description
Disabled Network compression isn't used.
Enabled Network compression is used on all DAG networks for replication and
seeding.
InterSubnetOnly Network compression is used on DAG networks when replicating across

different subnets. This is the default setting.
SeedOnly Network compression is used on all DAG networks for seeding only.
Add database copies
Once you have a second server in the DAG to as a backup of a front end server you should
create the copy of the front end server to the second server for fail over.
Go to servers>databases, select the database to copy click the 3 doted button and fill out the
form.

Phoenix, AZ 85044 602.490.0911/855.477.7463
Phoenix, AZ 85044 602.490.0911/855.477.7463
Email Client configuration

Phoenix, AZ 85044 602.490.0911/855.477.7463
Phoenix, AZ 85044 602.490.0911/855.477.7463
Phoenix, AZ 85044 602.490.0911/855.477.7463
Appendix
Network ports required for clients and services

The network ports that are required for email clients to access mailboxes and other services in
the Exchange organization are described in the following diagram and table.
Notes:
• The destination for these clients and services is the Client Access services on a Mailbox
server. In Exchange 2016, Client Access (frontend) and backend services are installed
together on the same Mailbox server. For more information, see Client access protocol
architecture.
• Although the diagram shows clients and services from the Internet, the concepts are the
same for internal clients (for example, clients in an accounts forest accessing Exchange
servers in a resource forest). Similarly, the table doesn't have a source column because
the source could be any location that's external to the Exchange organization (for
example, the Internet or an accounts forest).
• Edge Transport servers have no involvement in the network traffic that's associated with
these clients and services.

Phoenix, AZ 85044 602.490.0911/855.477.7463
Purpose Ports Comments

Phoenix, AZ 85044 602.490.0911/855.477.7463
Encrypted web 443/TCP (HTTPS) For more information about these clients and
connections are used services, see the following topics:
by the following
Autodiscover service
clients and services:
Exchange ActiveSync
Autodiscover service
EWS reference for Exchange
Exchange ActiveSync
Offline address books
Exchange Web
Services (EWS) Outlook Anywhere
Offline address book MAPI over HTTP in Exchange 2016

(OAB) distribution
Outlook Anywhere
(RPC over HTTP)
Outlook MAPI over

HTTP
Outlook on the web
Unencrypted web 80/TCP (HTTP) Whenever possible, we recommend using

connections are used encrypted web connections on 443/TCP to
by the following help protect data and credentials. However,
clients and services: you may find that some services must be
configured to use unencrypted web
Internet calendar
connections on 80/TCP to the Client Access
publishing
services on Mailbox servers.
Outlook on the web
For more information about these clients and
(redirect to 443/TCP)
services, see the following topics:
Autodiscover (fallback
Enable Internet calendar publishing
when 443/TCP isn't
available) Autodiscover service

Phoenix, AZ 85044 602.490.0911/855.477.7463
IMAP4 clients 143/TCP (IMAP), IMAP4 is disabled by default. For more
993/TCP (secure information, see POP3 and IMAP4.
IMAP)
The IMAP4 service in the Client Access services
on the Mailbox server proxies connections to
the IMAP4 Backend service on a Mailbox
server.
POP3 clients 110/TCP (POP3), POP3 is disabled by default. For more

995/TCP (secure information, see POP3 and IMAP4.
POP3)
The POP3 service in the Client Access services
on the Mailbox server proxies connections to
the POP3 Backend service on a Mailbox server.
SMTP clients 587/TCP The default Received connector named "Client

(authenticated) (authenticated Frontend <Server name>" in the Front End
SMTP) Transport service listens for authenticated
SMTP client submissions on port 587.
Note:
If you have mail clients that can submit

authenticated SMTP mail only on port 25, you
can modify the network adapter bindings value
of this Receive connector to also listen for
authenticated SMTP mail submissions on port
25.
Network ports required for mail flow

How mail is delivered to and from your Exchange organization depends on your Exchange
topology. The most important factor is whether you have a subscribed Edge Transport server
deployed in your perimeter network.

Phoenix, AZ 85044 602.490.0911/855.477.7463
Network ports required for mail flow (no Edge Transport servers)
The network ports that are required for mail flow in an Exchange organization that has only
Mailbox servers are described in the following diagram and table.

Phoenix, AZ 85044 602.490.0911/855.477.7463
Purpose Ports Source Destination Comments
Inbound 25/TCP (SMTP) Internet Mailbox The default Receive connector

mail (any) server named "Default
Frontend <Mailbox server name>"
in the Front End Transport service
listens for anonymous inbound
SMTP mail on port 25.
Mail is relayed from the Front End

Transport service to the Transport
service on a Mailbox server using
the implicit and invisible intra-
organization Send connector that
automatically routes mail between
Exchange servers in the same
organization. For more
information, see Implicit Send
connectors.
Outbound 25/TCP (SMTP) Mailbox Internet By default, Exchange doesn't

mail server (any) create any Send connectors that
allow you to send mail to the
Internet. You have to create Send
connectors manually. For more
information, see Create a Send
connector to send mail to the
Internet.
Outbound 25/TCP (SMTP) Mailbox Internet Outbound mail is proxied through

mail (if server (any) the Front End Transport service
proxied only when a Send connector is

Phoenix, AZ 85044 602.490.0911/855.477.7463
through the configured with Proxy through
Front End Client Access server in the
transport Exchange admin center or -
service) FrontEndProxyEnabled $true in
In this case, the default Receive

connector named "Outbound
Proxy Frontend <Mailbox server
name>" in the Front End Transport
service listens for outbound mail
from the Transport service on a
Mailbox server. For more
information, see Configure Send
connectors to proxy outbound
mail.
DNS for 53/UDP,53/TCP Mailbox DNS server See the Name resolution section.
name (DNS) server
resolution
of the next
mail hop
(not
pictured)
Network ports required for mail flow with Edge Transport servers
A subscribed Edge Transport server that's installed in your perimeter network affects mail flow in
the following ways:
• Outbound mail from the Exchange organization never flows through the Front End
Transport service on Mailbox servers. Mail always flows from the Transport service on a
Mailbox server in the subscribed Active Directory site to the Edge Transport server
(regardless of the version of Exchange on the Edge Transport server).

Phoenix, AZ 85044 602.490.0911/855.477.7463
• Inbound mail flows from the Edge Transport server to a Mailbox server in the subscribed
Active Directory site. Specifically:
o Mail from an Exchange 2016 or Exchange 2013 Edge Transport server first arrives
at the Front End Transport service before it flows to the Transport service on an
Exchange 2016 Mailbox server.
o Mail from an Exchange 2010 Edge Transport server always delivers mail directly
to the Transport service on an Exchange 2016 Mailbox server.
For more information, see Mail flow and the transport pipeline.
The network ports that are required for mail flow in Exchange organizations that have Edge
Transport servers are described in the following diagram and table.

Phoenix, AZ 85044 602.490.0911/855.477.7463
Purpose Ports Source Destination Comments
Inbound mail - 25/TCP (SMTP) Internet (any) Edge The default Receive
Internet to Transport connector named
Edge Transport server "Default internal
server Receive
connector <Edge
Transport server
name>" on the Edge
Transport server listens
for anonymous SMTP
mail on port 25.
Inbound mail - 25/TCP (SMTP) Edge Transport Mailbox The default Send
Edge Transport server servers in connector named
server to the "EdgeSync - Inbound
internal subscribed to <Active Directory
Exchange Active site name>" relays
organization Directory inbound mail on port
site 25 to any Mailbox
server in the
subscribed Active
Directory site. For
more information,
see Send connectors
created automatically
by the Edge
Subscription.
The default Receive

connector named
"Default
Frontend <Mailbox

Phoenix, AZ 85044 602.490.0911/855.477.7463
server name>" in the
Front End Transport
service on the Mailbox
server listens for all
inbound mail
(including mail from
Exchange 2016 and
Exchange 2013 Edge
Transport servers) on
port 25.
Outbound mail 25/TCP (SMTP) Mailbox servers Edge Outbound mail always
- Internal in the Transport bypasses the Front End
Exchange subscribed servers Transport service on
organization to Active Directory Mailbox servers.
Edge Transport site
Mail is relayed from
server
the Transport service
on any Mailbox server
in the subscribed
Active Directory site to
an Edge Transport
server using the
implicit and invisible
intra-organization
Send connector that
automatically routes
mail between
Exchange servers in
the same organization.
The default Receive

connector named
"Default internal
Receive

Phoenix, AZ 85044 602.490.0911/855.477.7463
connector <Edge
Transport server
name>" on the Edge
Transport server listens
for SMTP mail on port
25 from the Transport
service on any Mailbox
server in the
subscribed Active
Directory site.
Outbound mail 25/TCP (SMTP) Edge Transport Internet The default Send
- Edge server (any) connector named
Transport "EdgeSync - <Active
server to Directory site
Internet name> to Internet"
relays outbound mail
on port 25 from the
Edge Transport server
to the Internet.
EdgeSync 50636/TCP Mailbox servers Edge When the Edge

synchronization (secure LDAP) in the Transport Transport server is
subscribed servers subscribed to the
Active Directory Active Directory site,
site that all Mailbox servers that
participate in exist in the site at the
EdgeSync time participate in
synchronization EdgeSync
synchronization.
However, any Mailbox
servers that you add
later don't
automatically

Phoenix, AZ 85044 602.490.0911/855.477.7463
participate in
EdgeSync
synchronization.
DNS for name 53/UDP,53/TCP Edge Transport DNS server See the Name
resolution of (DNS) server resolution section.
the next mail
hop (not
pictured)
Open proxy see comments Edge Transport Internet By default, sender

server detection server reputation (the
in sender Protocol Analysis
reputation (not agent) uses open
pictured) proxy server detection
as one of the criteria to
calculate the sender
reputation level (SRL)
of the source
messaging server. For
more information,
see Sender reputation
and the Protocol
Analysis agent.
Open proxy server

detection uses the
following protocols
and TCP ports to test
source messaging
servers for open proxy:

Phoenix, AZ 85044 602.490.0911/855.477.7463
Protocols Ports
SOCKS4, 1081,
SOCKS5 1080
Wingate, 23
Telnet,
Cisco
HTTP 6588,
CONNECT, 3128,
HTTP POST 80
Also, if your
organization uses a
proxy server to control
outbound Internet
traffic, you need to
define the proxy server
name, type, and TCP
port that sender
reputation requires to
access the Internet for
open proxy server
detection.
Alternatively, you can

disable open proxy
server detection in
sender reputation.

Phoenix, AZ 85044 602.490.0911/855.477.7463
For more information,
see Manage sender
reputation.
Name resolution
DNS resolution of the next mail hop is a fundamental part of mail flow in any Exchange
organization. Exchange servers that are responsible for receiving inbound mail or delivering
outbound mail must be able to resolve both internal and external host names for proper mail
routing. And all internal Exchange servers must be able to resolve internal host names for proper
mail routing. There are many different ways to design a DNS infrastructure, but the important
result is to ensure name resolution for the next hop is working properly for all of your Exchange
servers.
Network ports required for hybrid deployments

The network ports that are required for an organization that uses both on-premises Exchange
and Microsoft Office 365 are covered in the "Hybrid deployment protocols, port and endpoints"
section in Hybrid deployment prerequisites.
Network ports required for Unified Messaging

The network ports that are required for Unified Messaging are covered in the topic UM protocols,
ports, and services.

Phoenix, AZ 85044 602.490.0911/855.477.7463
Database availability groups (DAGs)
Exchange 2016
A database availability group (DAG) is the base component of the Mailbox server high
availability and site resilience framework built into Microsoft Exchange Server 2016. A DAG is a
group of up to 16 Mailbox servers that hosts a set of databases and provides automatic
database-level recovery from failures that affect individual servers or databases.
Important:
All servers within a DAG must be running the same version of Exchange. You can't mix
Exchange 2013 servers and Exchange 2016 servers in the same DAG.
A DAG is a boundary for mailbox database replication, database and server switchovers and
failovers, and an internal component called Active Manager. Active Manager, which runs on every
Mailbox server, manages switchovers and failovers within DAGs. For more information about
Active Manager, see Active Manager.
Any server in a DAG can host a copy of a mailbox database from any other server in the DAG.
When a server is added to a DAG, it works with the other servers in the DAG to provide
automatic recovery from failures that affect mailbox databases, such as a disk, server, or network
failure.
Contents
Database availability group lifecycle
Using a database availability group for high availability
Using a database availability group for site resilience
Note:

Phoenix, AZ 85044 602.490.0911/855.477.7463
For more information about creating DAGs, managing DAG membership, configuring DAG
properties, creating and monitoring mailbox database copies, and performing switchovers,
see Managing high availability and site resilience.
Database availability group lifecycle

DAGs leverage the concept of incremental deployment, which is the ability to deploy service and
data availability for all Mailbox servers and databases after Exchange is installed. After you
deploy Exchange 2016 Mailbox servers, you can create a DAG, add Mailbox servers to the DAG,
and then replicate mailbox databases between the DAG members.
Note:
It's supported to create a DAG that contains a combination of physical Mailbox servers and
virtualized Mailbox servers, provided that the servers and solution comply with the Exchange
2016 system requirements and the requirements set forth in Exchange 2016 virtualization. As
with all Exchange high availability configurations, you must ensure that all Mailbox servers in
the DAG are sized appropriately to handle the necessary workload during scheduled and
unscheduled outages.
A DAG is created by using the New-DatabaseAvailabilityGroup cmdlet. A DAG is initially created as

an empty object in Active Directory. This directory object is used to store relevant information
about the DAG, such as server membership information and some DAG configuration settings.
When you add the first server to a DAG, a failover cluster is automatically created for the DAG.
This failover cluster is used exclusively by the DAG, and the cluster must be dedicated to the
DAG. Use of the cluster for any other purpose isn't supported.
In addition to a failover cluster being created, the infrastructure that monitors the servers for
network or server failures is initiated. The failover cluster heartbeat mechanism and cluster
database are then used to track and manage information about the DAG that can change
quickly, such as database mount status, replication status, and last mounted location.

Phoenix, AZ 85044 602.490.0911/855.477.7463
During creation, the DAG is given a unique name, and either assigned one or more static IP
addresses or configured to use Dynamic Host Configuration Protocol (DHCP), or created without
a cluster administrative access point. DAGs without an administrative access point can be
created only on servers running Exchange 2016 or Exchange 2013 Service Pack 1 or later, with
Windows Server 2012 R2 Standard or Datacenter edition. DAGs without cluster administrative
access points have the following characteristics:
• There is no IP address assigned to the cluster/DAG, and therefore no IP Address

Resource in the cluster core resource group.
• There is no network name assigned to the cluster, and therefore no Network Name
Resource in the cluster core resource group
• The name of the cluster/DAG is not registered in DNS, and it is not resolvable on the
network.
• A cluster name object (CNO) is not created in Active Directory.
• The cluster cannot be managed using the Failover Cluster Management tool. It must be
managed using Windows PowerShell, and the PowerShell cmdlets must be run against
individual cluster members.
This example shows you how to use the Exchange Management Shell to create a DAG with a
cluster administrative access point that will have three servers. Two servers (EX1 and EX2) are on
the same subnet (10.0.0.0), and the third server (EX3) is on a different subnet (192.168.0.0).
New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer EX4 -

DatabaseAvailabilityGroupIPAddresses 10.0.0.5,192.168.0.5
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX1
The commands to create a DAG without a cluster administrative access point are very similar:
New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer EX4 -

DatabaseAvailabilityGroupIPAddresses ([System.Net.IPAddress])::None

Phoenix, AZ 85044 602.490.0911/855.477.7463
The cluster for DAG1 is created when EX1 is added to the DAG. During cluster creation, the Add-
DatabaseAvailabilityGroupServer cmdlet retrieves the IP addresses configured for the DAG and
ignores the ones that don't match any of the subnets found on EX1. In the first example above,
the cluster for DAG1 is created with an IP address of 10.0.0.5, and 192.168.0.5 is ignored. In the
second example above, the value of the DatabaseAvailabilityGroupIPAddresses parameter instructs
the task to create a failover cluster for the DAG that does not have an administrative access
point. Thus, the cluster is created with an IP address or network name resource in the core
cluster resource group.
Then, EX2 is added, and the Add-DatabaseAvailabilityGroupServer cmdlet again retrieves the IP
addresses configured for the DAG. There are no changes to the cluster's IP addresses because in
EX2 is on the same subnet as EX1.
Then, EX3 is added, and the Add-DatabaseAvailabilityGroupServer cmdlet again retrieves the IP
addresses configured for the DAG. Because a subnet matching 192.168.0.5 is present on EX3, the
192.168.0.5 address is added as an IP address resource in the cluster group. In addition,
an OR dependency for the Network Name resource for each IP address resource is automatically
configured. The 192.168.0.5 address will be used by the cluster when the cluster core resource
group moves to EX3.
For DAGs with cluster administrative access points, Windows failover clustering registers the IP
addresses for the cluster in the Domain Name System (DNS) when the Network Name resource
is brought online. In addition, when EX1 is added to the cluster, a cluster name object (CNO) is
created in Active Directory. The network name, IP address(es), and CNO for the cluster are not
used for DAG functions. Administrators and end users don't need to interface with or connect to
the cluster/DAG name or IP address for any reason. Some third party applications connect to the
cluster administrative access point to perform management tasks, such as backup or monitoring.
If you do not use any third party applications that require a cluster administrative access point,
and your DAG is running Exchange 2016 on Windows Server 2012 R2, then we recommend
creating a DAG without an administrative access point. This simplifies DAG configuration,
eliminates the need for one or more IP addresses, and reduces the attack surface of a DAG.
DAGs are also configured to use a witness server and a witness directory. The witness server and
witness directory are either automatically configured by the system, or they can be manually
configured by the administrator. In the examples above, EX4 (a server that is not and will not be
a member of the DAG) is being manually configured as the DAG’s witness server.

Phoenix, AZ 85044 602.490.0911/855.477.7463
By default, a DAG is designed to use the built-in continuous replication feature to replicate
mailbox databases among servers in the DAG. If you're using third-party data replication that
supports the Third Party Replication API in Exchange 2016, you must create the DAG in third-
party replication mode by using the New-DatabaseAvailabilityGroup cmdlet with
the ThirdPartyReplication parameter. After this mode is enabled, it can't be disabled.
After the DAG is created, Mailbox servers can be added to the DAG. When the first server is
added to the DAG, a cluster is formed for use by the DAG. DAGs make use of Windows failover
clustering technology, such as the cluster heartbeat, cluster networks, and the cluster database
(for storing data that changes, such as database state changes from active to passive or vice
versa, or from mounted to dismounted and vice versa). As each subsequent server is added to
the DAG, it's joined to the underlying cluster, the cluster's quorum model is automatically
adjusted by Exchange, and the server is added to the DAG object in Active Directory.
After Mailbox servers are added to a DAG, you can configure a variety of DAG properties, such
as whether to use network encryption or network compression for database replication within
the DAG. You can also configure DAG networks and create additional DAG networks.
After you add members to a DAG and configure the DAG, the active mailbox databases on each
server can be replicated to the other DAG members. After you create mailbox database copies,
you can monitor the health and status of the copies using a variety of built-in monitoring tools.
In addition, you can perform database and server switchovers.
Database availability group quorum models

Underneath every DAG is a Windows failover cluster. Failover clusters use the concept of
quorum, which uses a consensus of voters to ensure that only one subset of the cluster
members (which could mean all members or a majority of members) is functioning at one time.
Quorum isn't a new concept for Exchange 2016. Highly available Mailbox servers in previous
versions of Exchange also use failover clustering and its concept of quorum. Quorum represents
a shared view of members and resources, and the term quorum is also used to describe the
physical data that represents the configuration within the cluster that's shared between all
cluster members. As a result, all DAGs require their underlying failover cluster to have quorum. If
the cluster loses quorum, all DAG operations terminate and all mounted databases hosted in the
DAG dismount. In this event, administrator intervention is required to correct the quorum
problem and restore DAG operations.
Quorum is important to ensure consistency, to act as a tie-breaker to avoid partitioning, and to

ensure cluster responsiveness:

Phoenix, AZ 85044 602.490.0911/855.477.7463
• Ensuring consistency A primary requirement for a Windows failover cluster is that each
of the members always has a view of the cluster that's consistent with the other
members. The cluster hive acts as the definitive repository for all configuration
information relating to the cluster. If the cluster hive can't be loaded locally on a DAG
member, the Cluster service doesn't start, because it isn't able to guarantee that the
member meets the requirement of having a view of the cluster that's consistent with the
other members.
• Acting as a tie-breaker A quorum witness resource is used in DAGs with an even number
of members to avoid split brain syndrome scenarios and to make sure that only one
collection of the members in the DAG is considered official. When the witness server is
needed for quorum, any member of the DAG that can communicate with the witness
server can place a Server Message Block (SMB) lock on the witness server's witness.log
file. The DAG member that locks the witness server (referred to as the locking node)
retains an additional vote for quorum purposes. The DAG members in contact with the
locking node are in the majority and maintain quorum. Any DAG members that can't
contact the locking node are in the minority and therefore lose quorum.
• Ensuring responsiveness To ensure responsiveness, the quorum model makes sure that,
whenever the cluster is running, enough members of the distributed system are
operational and communicative, and at least one replica of the cluster's current state can
be guaranteed. No additional time is required to bring members into communication or
to determine whether a specific replica is guaranteed.
DAGs with an even number of members use the failover cluster's Node and File Share Majority
quorum mode, which employs an external witness server that acts as a tie-breaker. In this
quorum mode, each DAG member gets a vote. In addition, the witness server is used to provide
one DAG member with a weighted vote (for example, it gets two votes instead of one). The
cluster quorum data is stored by default on the system disk of each member of the DAG, and is
kept consistent across those disks. However, a copy of the quorum data isn't stored on the
witness server. A file on the witness server is used to keep track of which member has the most
updated copy of the data, but the witness server doesn't have a copy of the cluster quorum
data. In this mode, a majority of the voters (the DAG members plus the witness server) must be
operational and able to communicate with each other to maintain quorum. If a majority of the
voters can't communicate with each other, the DAG's underlying cluster loses quorum, and the
DAG will require administrator intervention to become operational again.
DAGs with an odd number of members use the failover cluster's Node Majority quorum mode.
In this mode, each member gets a vote, and each member's local system disk is used to store

Phoenix, AZ 85044 602.490.0911/855.477.7463
the cluster quorum data. If the configuration of the DAG changes, that change is reflected across
the different disks. The change is only considered to have been committed and made persistent
if that change is made to the disks on half the members (rounding down) plus one. For example,
in a five-member DAG, the change must be made on two plus one members, or three members
total.
Quorum requires a majority of voters to be able to communicate with each other. Consider a
DAG that has four members. Because this DAG has an even number of members, an external
witness server is used to provide one of the cluster members with a fifth, tie-breaking vote. To
maintain a majority of voters (and therefore quorum), at least three voters must be able to
communicate with each other. At any time, a maximum of two voters can be offline without
disrupting service and data access. If three or more voters are offline, the DAG loses quorum,
and service and data access will be disrupted until you resolve the problem.

Phoenix, AZ 85044 602.490.0911/855.477.7463
Exchange 2016 architecture
Learn about the architecture of Exchange 2016
Exchange Server 2016 uses a single building block architecture that provides email services for
deployments at all sizes, from small organizations to the largest multi-national corporations.
This architecture is describe in the following diagram.

Phoenix, AZ 85044 602.490.0911/855.477.7463
Phoenix, AZ 85044 602.490.0911/855.477.7463
Individual components are described in the following sections.
Contents
Server communication architecture
Server role architecture
High availability architecture
Client access protocol architecture
Exchange 2016 architecture changes
Server communication architecture

Communication between Exchange 2016 servers and past and future versions of Exchange occurs at the
protocol layer. Cross-layer communication isn't allowed. This communication architecture is summarized
as "every server is an island". This architecture has the following benefits:
• Reduced inter-server communications.
• Version-aware communications.
• Isolated failures.
• Integrated design inside each server.
Protocol layer communication between Exchange 2016 servers is shown in the following diagram.

Phoenix, AZ 85044 602.490.0911/855.477.7463
Return to top
Server role architecture

Exchange 2016 uses Mailbox servers and Edge Transport servers. These server roles are described in the
following sections.
Mailbox servers
• Mailbox servers contain the transport services that are used to route mail. For more information,
see Mail flow and the transport pipeline
• Mailbox servers contain mailbox databases that process, render, and store data.
• Mailbox servers contain the client access services that accept client connections for all protocols.
These frontend services are responsible for routing or proxying connections to the corresponding

Phoenix, AZ 85044 602.490.0911/855.477.7463
backend services on a Mailbox server. Clients don't connect directly to the backend services. For
more information, see the Client access protocol architecture section later in this topic.
• Mailbox servers contain the Unified Messaging (UM) services that provide voice mail and other
telephony features to mailboxes.
• You manage Mailbox servers by using the Exchange admin center (EAC) and the Exchange
Management Shell. For more information, seeExchange admin center in Exchange 2016 and Using
PowerShell with Exchange 2016 (Exchange Management Shell).
Edge Transport servers
• Edge Transport servers handle all external mail flow for the Exchange organization.
• Edge Transport servers are typically installed in the perimeter network, and are subscribed to the
internal Exchange organization. The EdgeSync synchronization process makes recipient and other
configuration information available to the Edge Transport server as mail enters and leaves the
Exchange organization.
• Edge Transport servers provide antispam and mail flow rules as mail enters and leaves your
Exchange organization. For more information, see Antispam protection in Exchange 2016
• You manage Edge Transport servers by using the Exchange Management Shell. For more
information, see Using PowerShell with Exchange 2016 (Exchange Management Shell).
For more information about Edge Transport servers, see Edge Transport servers.
Return to top
High availability architecture

The high availability features in Exchange 2016 are described in the following sections.
Mailbox high availability
A database availability group (DAG) is the fundamental element of the high availability and site resilience
framework that's built into Exchange 2016. A DAG is a group of Mailbox servers that host a set of
databases and provides automatic, database-level recovery from database, network, and server failures.
And DAGs in Exchange 2016 have been improved compared to Exchange 2013.
Transport high availability
• The Transport service makes redundant copies of all messages in transit. This feature is known
as shadow redundancy.
• The transport service makes redundant copies of all delivered messages. This feature is known
as Safety Net.
• In Exchange 2016, a DAG represents a transport high availability boundary. You can achieve site
resilience by spanning a DAG across multiple Active Directory sites.
• In Exchange 2016, transport high availability is more than a best effort for message redundancy,
because redundancy doesn't depend on supported features of the sending mail server. Therefore,
you can say that Exchange 2016 attempts to guarantee message redundancy by keeping multiple
copies of messages during and after delivery.
Return to top
Client access protocol architecture

Phoenix, AZ 85044 602.490.0911/855.477.7463
The client access services on Exchange 2016 Mailbox servers are responsible for accepting all forms of
client connections. The client access (frontend) services proxy these connections to the backend services
on the destination Mailbox server (the local server or a remote Mailbox server that holds the active copy
of the user's mailbox). Clients don't directly connect to the backend services. This communication is
shown in the following diagram.

Phoenix, AZ 85044 602.490.0911/855.477.7463
The protocol that's used by a client determines the protocol that's used to proxy the request to the
backend services on the destination Mailbox server. For example, if the client connected using HTTP, the
Mailbox server uses HTTP to proxy the request to the destination Mailbox server (secured via SSL using a
self-signed certificate). If the client used IMAP or POP, then the protocol that's used is IMAP or POP.
Telephony requests are different than other client connections. Instead of proxying the request, the
Mailbox server redirects the request to the Mailbox server that holds the active copy of the user’s mailbox.
Telephony devices are required to establish their SIP and RTP sessions directly with the Unified Messaging
services on the destination Mailbox server.
Exchange 2016 architecture changes

• Server role consolidation In previous versions of Exchange, you could install the Client Access
server role and the Mailbox server role on separate computers. In Exchange 2016, the Client
Access server role is automatically installed as part of the Mailbox server role, and the Client
Access server role isn't available as a separate installation option. This change reflects the
philosophy of Exchange server role co-location that's been a recommended best practice since
Exchange 2010. A multi-role Exchange server architecture gives you the following tangible
benefits:
o All Exchange servers in your environment (with the likely exception of any Edge Transport
servers) can be exactly the same—the same hardware, the same configuration, etc. This
uniformity simplifies hardware purchasing, and also maintenance and management of the
Exchange servers.
o You'll likely need fewer physical Exchange servers. This results in lower ongoing
maintenance costs, fewer Exchange server licenses, and reduced rack, floor space, and
power requirements.
o Scalability is improved, because you’re distributing the workload across a greater number
of physical machines. During a failure, the load on the remaining Exchange multi-role
servers increases only incrementally, which ensures the other functions on the Exchange
servers aren’t adversely affected.
o Resiliency is improved, because a multi-role Exchange server can survive a greater
number of Client Access role (or service) failures and still provide service.
• Search improvements The local search instance is now able to read data from the local mailbox
database copy. As a result, passive search instances no longer need to coordinate with their active
counterparts to perform index updates, and bandwidth requirements between the active copy
and a passive copy have been reduced by 40% compared to previous versions of Exchange. Also,
search is now able to perform multiple asynchronous disk reads prior to a user completing a
search term. This populates the cache with relevant information, and provides sub-second search
query latency for online clients like Outlook on the web.
• Office Online Server Preview for Outlook on the web document preview In previous
versions of Exchange, Outlook Web App included WebReady Document Viewing for the built-in
preview of Office and PDF documents. In Exchange 2016, Outlook on the web uses Office Online
Server Preview to provide rich preview and editing capabilities for documents. While this provides
a consistent document experience with other products like SharePoint and Skype for Business, it

Phoenix, AZ 85044 602.490.0911/855.477.7463
does require you to deploy Office Online Server Preview in your on-premises environment if you
don't already have it. For more information, see Install Office Online Server in an Exchange 2016
organization.
• MAPI over HTTP is the default for Outlook connections MAPI over HTTP was introduced in
Exchange 2013 Service Pack 1, and offers improvements over the traditional Outlook Anywhere
(RPC over HTTP) connection method. In Exchange 2016, MAPI over HTTP is enabled by default,
and offers additional controls, such as the ability to enable or disable MAPI over HTTP per user,
and whether to advertise it to external clients.

Phoenix, AZ 85044 602.490.0911/855.477.7463
Load Balancing in Exchange 2016
Like Exchange 2013, Exchange 2016 does not require session affinity at the load
balancing layer.
To understand this statement better, and see how this impacts your designs, we need to
look at how MBX2016 functions. From a protocol perspective, the following will happen:
1. A client resolves the namespace to a load balanced virtual IP address.

2. The load balancer assigns the session to a MBX server in the load balanced pool.
3. The Client Access services located on the MBX server authenticates the request and
performs a service discovery by accessing Active Directory to retrieve the following
information:
1. Mailbox version (for this discussion, we will assume an Exchange 2016 mailbox)
2. Mailbox location information (e.g., database information, ExternalURL values, etc.)
4. The Client Access services located on the MBX server makes a decision on whether
to proxy the request or redirect the request to another MBX infrastructure (within the
same forest).
5. The Client Access services located on the MBX server queries an Active Manager instance
that is responsible for the database to determine which Mailbox server is hosting the
active copy.
6. The Client Access services located on the MBX server proxies the request to the Mailbox
server hosting the active copy.
Step 5 is the fundamental change that enables the removal of session affinity at the load
balancer. For a given protocol session, the Client Access services located on the Mailbox
server now maintains a 1:1 relationship with the Mailbox server hosting the user’s
data. In the event that the active database copy is moved to a different Mailbox server,
MBX closes the sessions to the previous server and establishes sessions to the new
server. This means that all sessions, regardless of their origination point (i.e., MBX
servers in the load balanced array), end up at the same place, the Mailbox server hosting
the active database copy.This is vastly different in releases prior to Exchange 2013 – for
example, in Exchange 2010, if all requests from a specific client did not go to the same
endpoint, the user experience was negatively affected.
The protocol used in step 6 depends on the protocol used to connect to MBX. If the
client leverages the HTTP protocol, then the protocol used between Mailbox servers is
HTTP (secured via SSL using a self-signed certificate). If the protocol leveraged by the

Phoenix, AZ 85044 602.490.0911/855.477.7463
client is IMAP or POP, then the protocol used between the Mailbox servers is IMAP or
POP.
Telephony requests are unique, however. Instead of proxying the request at step 6, MBX
will redirect the request to the Mailbox server hosting the active copy of the user’s
database, as the telephony devices support redirection and need to establish their SIP
and RTP sessions directly with the Unified Messaging components on the Mailbox
server.
Figure 1: Exchange 2016 Client Access Protocol Architecture
However, there is a concern with this architectural change. Since session affinity is not
used by the load balancer, this means that the load balancer has no knowledge of the
target URL or request content.All the load balancer uses is layer 4 information, the IP
address and the protocol/port (TCP 443):

Phoenix, AZ 85044 602.490.0911/855.477.7463
Figure 2: Layer 4 Load Balancing
The load balancer can use a variety of means to select the target server from the load
balanced pool, such as, round-robin (each inbound connection goes to the next target
server in the circular list) or least-connection (load balancer sends each new connection
to the server that has the fewest established connections at that time).
Health Probe Checking

Unfortunately, this lack of knowledge around target URL (or the content of the request),
introduces complexities around health probes.
Exchange 2016 includes a built-in monitoring solution, known as Managed Availability.
Managed Availability includes an offline responder. When the offline responder is
invoked, the affected protocol (or server) is removed from service. To ensure that load
balancers do not route traffic to a Mailbox server that Managed Availability has marked
as offline, load balancer health probes must be configured to
check <virtualdirectory>/healthcheck.htm (e.g.,
https://mail.contoso.com/owa/healthcheck.htm). Note that healthcheck.htmdoes not
actually exist within the virtual directories; it is generated in-memory based on the
component state of the protocol in question.
If the load balancer health probe receives a 200 status response, then the protocol is up;
if the load balancer receives a different status code, then Managed Availability has

Phoenix, AZ 85044 602.490.0911/855.477.7463
marked that protocol instance down on the Mailbox server. As a result, the load
balancer should also consider that end point down and remove the Mailbox server from
the applicable load balancing pool.
Administrators can also manually take a protocol offline for maintenance, thereby
removing it from the applicable load balancing pool. For example, to take the OWA
proxy protocol on a Mailbox server out of rotation, you would execute the following
command:
Set-ServerComponentState <Mailbox Server> -Component OwaProxy –Requestor
Maintenance –State Inactive
For more information on server component states, see the article Server Component
States in Exchange 2013.
What if the load balancer health probe did not monitor

healthcheck.htm?
If the load balancer did not utilize the healthcheck.htm in its health probe, then the load
balancer would have no knowledge of Managed Availability’s removal of (or adding
back) a server from the applicable load balancing pool. The end result is that the load
balancer would have one view of the world, while Managed Availability would have
another view of the world. In this situation, the load balancer could direct requests to a
Mailbox server that Managed Availability has marked down, which would result in a
negative (or broken) user experience. This is why the recommendation exists to
utilize healthcheck.htm in the load balancing health probes.
Namespace and Affinity Scenarios

Now that we understand how health checks are performed, let’s look at four scenarios:
1. Single Namespace / Layer 4 (No Session Affinity)

2. Single Namespace / Layer 7 (No Session Affinity)
3. Single Namespace / Session Affinity
4. Multiple Namespaces / No Session Affinity
Single Namespace / Layer 4 (No Session Affinity)

Phoenix, AZ 85044 602.490.0911/855.477.7463
In this scenario, a single namespace is deployed for all the HTTP protocol clients
(mail.contoso.com). The load balancer is operating at layer 4 and is not maintaining
session affinity. The load balancer is also configured to check the health of the target
Mailbox servers in the load balancing pool; however, because this is a layer 4 solution,
the load balancer is configured to check the health of only a single virtual directory (as it
cannot distinguish OWA requests from RPC requests). Administrators will have to
choose which virtual directory they want to target for the health probe; you will want to
choose a virtual directory that is heavily used.For example, if the majority of your users
utilize OWA, then targeting the OWA virtual directory in the health probe is appropriate.
Figure 3: Single Namespace with No Session Affinity
As long as the OWA health probe response is healthy, the load balancer will keep the
target MBX in the load balancing pool. However, if the OWA health probe fails for any
reason, then the load balancer will remove the target MBX from the load balancing pool
for all requests associated with that particular namespace. In other words, in this
example, health from the perspective of the load balancer, is per-server, not per-
protocol, for the given namespace.This means that if the health probe fails, all client

Phoenix, AZ 85044 602.490.0911/855.477.7463
requests for that namespace will have to be directed to another server, regardless of
protocol.
Figure 4: Single Namespace with No Session Affinity – Health Probe Failure
Single Namespace / Layer 7 (No Session Affinity)

In this scenario, a single namespace is deployed for all the HTTP protocol clients
(mail.contoso.com). The load balancer is configured to utilize layer 7, meaning SSL
termination occurs and the load balancer knows the target URL. The load balancer is
also configured to check the health of the target Mailbox servers in the load balancing
pool; in this MBXe, a health probe is configured on each virtual directory.
target MBX in the OWA load balancing pool. However, if the OWA health probe fails for
any reason, then the load balancer will remove the target MBX from the load balancing
pool for OWA requests. In other words, in this example, health is per-protocol; this
means that if the health probe fails, only the affected client protocol will have to be
directed to another server.

Phoenix, AZ 85044 602.490.0911/855.477.7463
Figure 5: Single Namespace with Layer 7 (No Session Affinity) – Health Probe Failure
A single namespace utilizing layer 7 without session affinity is the recommended

namespace and load balancer configuration for Exchange 2016.
Single Namespace / Layer 7 with Session Affinity

this scenario, a single namespace is deployed for all the HTTP protocol clients
(mail.contoso.com). The load balancer is configured to maintain session affinity (layer 7),
meaning SSL termination occurs and the load balancer knows the target URL. The load
balancer is also configured to check the health of the target Mailbox servers in the load
balancing pool; in this MBXe, the health probe is configured on each virtual directory.

Phoenix, AZ 85044 602.490.0911/855.477.7463
Figure 6: Single Namespace with Layer 7 with Session Affinity – Health Probe Failure
Note: By having session affinity enabled, the load balancer’s capacity and utilization are
decreased because processing is used to maintain more involved affinity options, such
as cookie-based load balancing or Secure Sockets Layer (SSL) session-ID. Check with
your vendor on the impacts session affinity will have in your load balancing scalability.
Multiple Namespaces / No Session Affinity

This scenario combines the best of both worlds – provides per-protocol health checking,
while not requiring complex load balancing logic.
In this scenario, a unique namespace is deployed for each HTTP protocol client; for
example:

Phoenix, AZ 85044 602.490.0911/855.477.7463
Figure 7: Multiple Namespaces with No Session Affinity
Note: As seen in the picture depicted above, ECP is provided its own namespace. ECP
and OWA are intimately tied together, and thus, ECP does not necessarily require its
own namespace. However, ECP does have its own application pool, is the endpoint for
the Exchange Administration Center, and used by Outlook clients for certain
configuration items. Therefore, you may want to provide a unique namespace for ECP.
The load balancer is configured to not maintain session affinity (layer 4). The load
balancer is also configured to check the health of the target Mailbox servers in the load
balancing pool; in this case, the health probes are effectively configured to target the
health of each virtual directory, as each virtual directory is defined with a unique
namespace, and while the load balancer still has no idea what the URL is being accessed,
the result is as if it does know.

Phoenix, AZ 85044 602.490.0911/855.477.7463
Figure 8: Multiple Namespaces with No Session Affinity – Health Probe Failure
The downside to this approach is that it introduces additional namespaces, additional

VIPs (one per namespace), and increases the number of names added as subject
alternative names on the certificate, which can be costly depending on your certificate
provider. But, this does not introduce extra complexity to the end user – the only URL
the user needs to know is the OWA URL. ActiveSync, Outlook, and Exchange Web
Services clients will utilize Autodiscover to determine the correct URL.
Exchange Scenario Summary

The following table identifies the benefits and concerns with each approach:
Benefits Concerns
Single Namespace / Layer 4 (No ▪ Single namespace ▪ Per-server health

Session Affinity) ▪ Reduced load
balancer complexity

Phoenix, AZ 85044 602.490.0911/855.477.7463
▪ Session affinity
maintained at MBX
Recommended: Single Namespace ▪/ Single namespace ▪ SSL offloading which may

Layer 7 (No Session Affinity) ▪ Per-protocol health impact load balancer scalability
Single Namespace / Layer 7 (Session

▪ Single namespace ▪ Session affinity maintained at
Affinity) ▪ Per-protocol health load balancer
▪ Increased load balancer
complexity
▪ Reduced load balancer
scalability
Multiple Namespaces / No Session ▪ Per-protocol health ▪ Multiple namespaces

Affinity ▪ Session affinity ▪ Additional names on certificate
maintained at MBX ▪ Increased rule set on load
▪ Users only have to balancer
know OWA URL ▪ Multiple VIPs
Office Online Server Load Balancing

Exchange Server 2016 leverages Office Online Server to provide the rich document
preview and editing capabilities for OWA. While this was a necessary change to ensure a
homogenous experience across the Office Server suite, this does introduce additional
complexity for environments that don’t have Office Online Server.
As discussed in the architecture and namespace planning articles, the Office Online
Server infrastructure requires unique namespaces. The load balancer is configured to
maintain layer 7 with session affinity (using cookie-based persistence) for each Office
Online Server namespace, meaning SSL termination occurs and the load balancer knows
the target URL.This ensures the client is always directed to the same Office Online Server
while the user is utilizing the document collaboration capabilities within OWA.
Conclusion

Phoenix, AZ 85044 602.490.0911/855.477.7463
Exchange 2016 introduces significant flexibility in your namespace and load balancing
architecture. With load balancing, the decision ultimately comes down to balancing
functionality vs. simplicity. The simplest solution lacks session affinity management and
per-protocol health checking, but provides the capability to deploy a single namespace.
At the other end of the spectrum, you can utilize session affinity management, per-
protocol health checking with a single namespace, but at the cost of increased
complexity. Or you could balance the functionality and simplicity spectrums, and deploy
a load balancing solution that doesn’t leverage session affinity, but provides per-
protocol health checking at the expense of requiring a unique namespace per protocol.

Phoenix, AZ 85044 602.490.0911/855.477.7463

Configure Exchange Multi-Tenant Environment

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Configure Exchange Multi-Tenant Environment

Enviado por

Direitos autorais:

Formatos disponíveis

Exchange Multi-Tenant

4043 E Salinas Ct customer@qualtechsoftware.com Page |1

4043 E Salinas Ct customer@qualtechsoftware.com Page |2

4043 E Salinas Ct customer@qualtechsoftware.com Page |3

4043 E Salinas Ct customer@qualtechsoftware.com Page |4

4043 E Salinas Ct customer@qualtechsoftware.com Page |5

4043 E Salinas Ct customer@qualtechsoftware.com Page |6

First time installation

Create an Exchange admin account

This user must be part of the roles:

4043 E Salinas Ct customer@qualtechsoftware.com Page |7

Active Directory preparation

4043 E Salinas Ct customer@qualtechsoftware.com Page |8

1. What do you need to know before you begin?

How do you know this worked?

What do you need to know before you begin?

4043 E Salinas Ct customer@qualtechsoftware.com Page |9

1. Extend the Active Directory schema

4043 E Salinas Ct customer@qualtechsoftware.com P a g e | 10

Figure 2: The AD schema preparation completed successfully.

4043 E Salinas Ct customer@qualtechsoftware.com P a g e | 11

• You can use any uppercase or lowercase letters from A to Z.

4043 E Salinas Ct customer@qualtechsoftware.com P a g e | 12

Figure 3: Prepare organization for Exchange.

4043 E Salinas Ct customer@qualtechsoftware.com P a g e | 13

Figure 4: AD Exchange objects.

In a command prompt type ADSIEdit

4043 E Salinas Ct customer@qualtechsoftware.com P a g e | 14

Figure 5: Exchange objects in the ADSIEdit.

3. Prepare Active Directory domains

Prepare all of the domains in my Active Directory forest

4043 E Salinas Ct customer@qualtechsoftware.com P a g e | 15

4043 E Salinas Ct customer@qualtechsoftware.com P a g e | 16

Let me choose which Active Directory domains I want to prepare

4043 E Salinas Ct customer@qualtechsoftware.com P a g e | 17

How do you know this worked?

4043 E Salinas Ct customer@qualtechsoftware.com P a g e | 18

Exchange 2016 Active Directory versions

4043 E Salinas Ct customer@qualtechsoftware.com P a g e | 19

Naming Schema Default Configuration

Container ms-Exch- Microsoft CN=<your organization>,

Exchange 15326 13236 16213

Exchange 15326 13236 16213

Exchange 15326 13236 16212

Exchange 15325 13236 16212

Exchange 15323 13236 16211

Exchange 15317 13236 16210

Exchange 15317 13236 16041

4043 E Salinas Ct customer@qualtechsoftware.com P a g e | 20

Mailbox server role

Do the following to install the required Windows roles and features:

1. Open Windows PowerShell.

1. .NET Framework 4.6.2

Edge Transport server role

4043 E Salinas Ct customer@qualtechsoftware.com P a g e | 21

3. Open Windows PowerShell.

Attach the Exchange CD to the AD server and run setup.exe /PrepareAD

Figure 7: Complete AD preparation.

4043 E Salinas Ct customer@qualtechsoftware.com P a g e | 22

The setup log file is in <system drive>:\ExchangeSetupLogs\ExchangeSetup.log.

Create and configure mailbox databases

To access the Exchange Admin run the Exchange Administrative Center

Get-PopSettings | Format-List ConnectionSettings,Bindings,X509CertificateName

Get-ImapSettings | Format-List ConnectionSettings,Bindings,X509CertificateName