When we released the very popular Office 365 for Exchange Professionals eBook, some people told us that there’s just too much information in 800 pages. They wanted some very specific information about one particular scenario – how to create and manage a Hybrid Exchange deployment.

Enough people were asking about it that we decided to take three chapters and an appendix from Office 365 for Exchange Professionals to create a standalone eBook that is focused on all aspects of Hybrid Exchange connectivity and deployment.

The Complete Guide to Managing Hybrid Exchange Deployments is 160+ pages of pure Hybrid Exchange. Written by Michael Van Hybrid (or Van Horenbeeck, if you insist) with a little help from his friends, the guide is as complete and up to date as it can be.

If you want to just learn about Hybrid Exchange without all the other Office 365 information, then this is the eBook for you. And for a limited time we’re offering this new eBook at 15% off the regular price.

Click here to find out more

PS – Just to be clear, if you already own a copy of Office 365 for Exchange Professionals, then you’ve already got the information contained in this Hybrid eBook (plus a whole lot more).

This article The Complete Guide to Managing Hybrid Exchange Deployments is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

There are two methods you can use for generating a certificate request for Exchange Server 2016:

• The Exchange Admin Center (you can think of this as the GUI method)
• The Exchange Management Shell (or PowerShell, you can think of this as the command line method)

Generating the certificate request (or CSR) using the Exchange Admin Center is generally easier of the two options, and this tutorial will demonstrate how to do it.

To begin, open your web browser and connect to the URL for the Exchange Admin Center on one of your Exchange 2016 servers. After logging in, navigate to servers and then certificates.

If you have more than one Exchange server in your organization select the correct server from the drop down list, then click the “+” icon to start a new CSR.

Choose to create a request for a certificate from a certification authority.

Enter a friendly name for the certificate. You’ll see this name in the list of certificates installed on the server, so make it something that you will easily recognise. For example, there’s already a self-signed certificate named “Microsoft Exchange”, so call your new certificate something different such as “Exchange 2016 SAN Certificate”.

Although wildcard certificates are generally supported for Exchange Server 2016 I am not going to be installing a wildcard certificate in this example.

Choose a server to store the certificate request on. The same server is later used to complete the certificate request, and will be the first server that has the certificate installed. You can later export the certificate from this server and import it into other Exchange servers that have the same namespaces configured.

Next we select the domain names to include on the SSL certificate. You’ll notice that the wizard has pre-populated the list based on the namespaces configured on the various Exchange services. However you may also notice if you scroll down that the server’s real name is included in that list due to the default configuration of the POP and IMAP services, even if those services are not enabled. You can edit the entries at this step, but I find it easier to proceed to the next step and modify the list there instead.

At the next step you can select and remove any unwanted names, edit existing names, or add more names to the certificate request. In this example I’ve modified the list to include only the planned namespaces:

• mail.exchange2016demo.com (for HTTPS services)
• autodiscover.exchange2016demo.com (the Autodiscover CNAME that may be used by non-domain joined devices such as mobile phones)
• exchange2016demo.com (the root domain, which is optional and depends on your specific scenario, but it’s harmless to include it if you’re not sure)

Enter your organization information for the certificate request. This information will form part of the validation process by the certificate authority that is issuing your certificate, so using correct and valid details is important. If any of the details are incorrect the certificate authority may contact you for additional proof of ownership before they’ll issue you a certificate, slowing down the whole process.

Enter a UNC path to save the certificate request to. The UNC path you provide must be accessible by the Exchange server’s computer account, or by the Exchange Trusted Subsystem group. Simply choosing a UNC path that points to the Exchange server itself should be fine. You’ll also need to be able to access the location yourself to be able to submit the request to the certificate authority.

Click Finish, and the certificate request will be generated in the UNC path you chose.

You can now submit the CSR to a certificate authority such as Digicert. When you’ve received your certificate, return to the Exchange Admin Center and complete the pending certificate request.

This article How to Generate an SSL Certificate Request in Exchange Server 2016 is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

After installing Exchange Server 2016 into your organization you may receive reports from your end users of a security alert containing certificate warning messages appearing in Outlook.

The two most common problems reported by the Outlook certificate warning message are:

• The name on the security certificate is invalid or does not match the name of the site
• The security certificate was issued by a company you have not chosen to trust

Why Does Outlook Display a Security Warning for a Certificate Problem?

When you install Exchange Server 2016 into your Active Directory environment the setup process registers a Service Connection Point (SCP) for the Autodiscover service. Autodiscover is used by client applications to discover information about Exchange mailboxes and services. For example, Outlook uses Autodiscover during the setup of a new Outlook profile to discover the server settings for the user, so that the profile can be automatically configured (instead of the old days of manually entering server names and other details into Outlook).

By default the Autodiscover SCP is registered using a URL that includes the Exchange server’s fully-qualified domain name. You can see the Autodiscover URL for an Exchange 2016 server by running the Get-ClientAccessService cmdlet in the Exchange Management Shell. For example:

[PS] C:\>Get-ClientAccessService -Identity EXSERVER | Select AutodiscoverServiceInternalUri
AutoDiscoverServiceInternalUri
------------------------------
https://exserver.exchange2016demo.com/Autodiscover/Autodiscover.xml

Note: Previous versions of Exchange used the Get-ClientAccessServer cmdlet. With the changes in Exchange 2016 server roles architecture the new cmdlets for these management tasks are *-ClientAccessService. The old cmdlets are still available in Exchange 2016, but if you use them you will see a warning message that they are deprecated.

Autodiscover is accessible via an HTTPS (SSL) connection from clients. The Exchange server also has a number of other web services that are accessible using HTTPS connections from clients, such as Exchange Web Services (EWS), Outlook on the web (also known as OWA), ActiveSync (for mobile devices), and Outlook Anywhere (used by Outlook clients).

As the connection is over HTTPS the SSL certificate configured on the server must meet three criteria to be considered valid by the client:

• The certificate was issued by a trusted certificate authority (CA)
• The certificate has not expired
• The name on the certificate matches the server name (or URL) that the client is connecting to

How to Fix Outlook Security Warnings After Installing Exchange 2016

There are two parts to the solution:

1. Configure the Autodiscover URL for the service
2. Install a valid SSL certificate

Configuring the Autodiscover URL for Exchange 2016

It is not recommended to leave the Autodiscover URL configured with the server’s fully-qualified domain name. Instead, you should configure it to use a different DNS name or alias. This is part of your overall Client Access namespace planning for Exchange 2016.

In this example I will change the Autodiscover URL to use the DNS name of mail.exchange2016demo.com.

[PS] C:\>Set-ClientAccessService -Identity EXSERVER -AutoDiscoverServiceInternalUri https://mail.exchange2016demo.com/Autodiscover/Autodiscover.xml

However, as this is also a new server installation all of the other HTTPS services also need their URLs reconfigured. You can read more about that here, and also download my PowerShell script ConfigureExchangeURLs.ps1 to make the process easier.

In some cases an IIS restart on the server is also necessary after configuring the namespaces.

You also need to add a DNS record for the namespace if one does not already exist. In this example I add an A record of “mail” to my internal DNS zone, and point it to the IP address of the Exchange 2016 server (because it is the only server in the organization). If you have multiple Exchange servers then either DNS round robin or a load balancer could be used instead.

Install a Valid SSL Certificate

With the namespaces correctly configured, and DNS records in place, you will then need to provision an SSL certificate for the Exchange 2016 server. If this is a new concept for you then I recommend some additional reading:

• SSL Certificates for Exchange Server 2016

To provision an SSL certificate for your Exchange 2016 server the process is:

1. Create a certificate signing request (CSR)
2. Submit the CSR to a certificate authority such as Digicert
3. Complete the pending certificate request on the Exchange server
4. Enable the SSL certificate for Exchange services

Summary

The common causes of Outlook security alerts containing certificate warnings are misconfigured Exchange server namespaces, and invalid SSL certificates. Using the steps demonstrated above you can reconfigure your namespaces and/or install a valid SSL certificate. When your Exchange server’s configuration has been corrected the Outlook security alerts should stop appearing for your end users.

This article Certificate Warnings in Outlook After Installing Exchange Server 2016 is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

To install an Exchange 2016 SSL certificate the process is:

1. Generate a certificate signing request (CSR)
2. Submit the CSR to a certificate authority, such as Digicert, and download the issued certificate
3. Complete the pending SSL certificate request in Exchange
4. Assign the certificate to Exchange services

In this tutorial we’ll look at step 3, completing the pending SSL certificate request.

The certificate has already been downloaded and placed in a location that is accessible by the Exchange server’s computer account, or by the Exchange Trusted Subsystem group. You will need to provide the UNC path to the file when completing the pending certificate request. I’ve placed my certificate in the C:\Admin folder of my Exchange server.

In the Exchange Admin Center navigate to servers, then certificates. Choose the Exchange server you need to complete the pending certificate request for, and selecting the pending request. Click the Complete link on the right side of the page.

Enter the UNC path to the certificate file and click OK.

If the import is successful the certificate should now appear with a status of “Valid”.

The next step is to assign or enable the certificate for Exchange services.

This article Completing a Pending SSL Certificate Request for Exchange Server 2016 is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

When an SSL certificate has been installed for Exchange Server 2016 you need to assign it to Exchange services before it will be used. This task can be performed in the Exchange Admin Center.

Navigate to servers, then certificates, and select the server that has the SSL certificate you wish to enable for Exchange services.

Select the SSL certificate and click the edit icon.

Select services, then tick the boxes for each service you wish to enable.

• IIS is used for all HTTPS services (such as OWA, ActiveSync, Outlook Anywhere). Only one certificate can be assigned to IIS, so it’s important that the certificate contains all of the correct names configured as URLs for your HTTPS services.
• SMTP is used for TLS-encrypted mail flow. More than one certificate can be assigned to SMTP.
• POP and IMAP are disabled by default in Exchange Server 2016, but if you are planning to enable them you should assign a certificate, whether that is the same certificate used for HTTPS or a different one.
• UM is optional as well. If you are planning to use the UM features of Exchange Server 2016 enable a certificate for UM as well, again that can be the same certificate as used for HTTPS services or a different one.

Click Save when you’ve select the services you need to use the SSL certificate for. If you are assigning an SMTP certificate you may be prompted to overwrite the default SMTP certificate. SMTP can have multiple certificates assigned, and for a simple deployment where the single SSL certificate you acquired contains the SMTP namespace you plan to use on connectors it is generally fine to say Yes to this prompt.

After you’ve completed those steps the SSL certificate will be used by Exchange for those services you selected.

This article Assign an SSL Certificate to Exchange Server 2016 Services is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

When Exchange Server 2016 is installed it creates a mailbox database for you on the server . If you installed Exchange to the default path then the mailbox will be stored in C:\Program Files\Microsoft\Exchange Server\V15\Mailbox\.

Here’s an example from my test server:

[PS] C:\>Get-MailboxDatabase | fl Name,EdbFilePath,LogFolderPath
Name          : Mailbox Database 2116642217
EdbFilePath   : C:\Program Files\Microsoft\Exchange Server\V15\Mailbox\Mailbox Database 2116642217\Mailbox Database 2116642217.edb
LogFolderPath : C:\Program Files\Microsoft\Exchange Server\V15\Mailbox\Mailbox Database 2116642217

The default location is probably not suitable for your environment, so you would likely want to move this database to the volumes that you’ve provisioned for your Exchange database and log files. Another common scenario is that the database is growing and the current volume is low on free disk space, so you want to move it to new, larger volume.

A mailbox database can be moved, but before you proceed consider that the move requires the database to be dismounted and taken offline, so it will not be accessible by your mailbox users during the move. This is fine if the server has just been set up and there are no mailboxes on it, but if you’re moving a database with active mailbox users a better option would be to create a new database on the new volume and perform mailbox moves (which are non-disruptive to end users).

I will also point out that the procedure below is not suitable for mailbox databases that are being replicated to multiple DAG members.

Before I move the database I am first going to rename it. The uniquely generated name of “Mailbox Database 2116642217” is not desirable so I will rename it to “DB01” instead.

[PS] C:\>Set-MailboxDatabase "Mailbox Database 2116642217" -Name "DB01"

To move the database and transaction log files to their new locations we use the Move-DatabasePath cmdlet.

[PS] C:\>Move-DatabasePath DB01 -EdbFilePath D:\DB01\DB01.edb -LogFolderPath E:\DB01

The database is temporarily dismounted, the files are copied to the new locations, and then the database is mounted again. The time operation takes will depend on how much data there is to be moved, as well as the speed of the source and destination disks. Generally speaking, the more data you have the longer it will take, potentially becoming a very long outage for your users, hence why I recommend considering moving mailboxes to a new database instead.

This article Moving an Exchange Server 2016 Mailbox Database is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

When you first install Exchange Server 2016 there is no outbound mail flow configured by setup. If you happen to be installing into an existing Exchange organization then the existing outbound routes for the organization will apply, and mail sent by mailboxes on your new Exchange server to external recipients will likely work. However if you’re installing into a new organization, or want to change your existing outbound mail flow, then you’ll need to create a send connector.

Send connectors control outgoing mail flow from your Exchange server. Every organization that needs to send email message to external recipients will need at least one send connector. In this tutorial we’ll look at creating and testing a new send connector for outbound email from an Exchange Server 2016 server.

Creating a Send Connector for Exchange Server 2016

Log on to your Exchange Admin Center and navigate to mail flow and then send connectors.

Give the new send connector a meaningful name and set the Type to Internet.

Next you’ll need to decide how the outbound emails will be delivered. There are two choices – by MX record, or via smart host. MX record delivery involves your Exchange server looking up the MX records of the recipient’s domain in DNS, and then connecting directly to their email server via SMTP to deliver the email message. Smart host delivery involves your Exchange server sending the messages to a specified IP address or host name for another system (typically an email security appliance or cloud service) that is then responsible for the further delivery of that email message.

For this example I’m going to use MX records to deliver the message. My server already has outbound firewall access on TCP port 25, and can resolve MX records on the internet using DNS, so at a basic level this should work fine. There are other considerations such as SPF and IP reputation in the real world that may impact the delivery of email messages from your server.

Set the address space for the send connector. An address space of “*” means “any domain” and is suitable if you have one send connector that is used for all outbound mail flow. You can use this address space option if you later need to configure specific send connectors for different domains.

Finally, set the source server for the send connector. If you have multiple servers that you want to be responsible for outbound mail flow you can add more than one server to this list.

Click Finish to complete the wizard.

Testing the Send Connector

A simple test to verify that the send connector is working is to send an email from a mailbox on the server to an external address. If the email message is received by the external mailbox you can then check the message headers by copying them from the message and pasting them into the Message Analyzer at ExRCA.com. This will verify for you that the email message took the intended route (via your new server) instead of some other existing outbound route in your organization.

If the email message was not received check the transport queue on the Exchange 2016 server.

[PS] C:\>Get-Queue
Identity                   DeliveryType Status MessageCount Velocity RiskLevel OutboundIPPool NextHopDomain
--------                   ------------ ------ ------------ -------- --------- -------------- -------------
EXSERVER\3                 DnsConnec... Ready  0            0        Normal    0              gmail.com
EXSERVER\Submission        Undefined    Ready  0            0        Normal    0              Submission

If you see message stuck in the queue for the next hop domain that you’re trying to send to you can see more details about them by piping the command to Get-Message.

[PS] C:\>Get-Queue | Get-Message | fl

In particular look for the LastError attribute of the queued messages, which will often contain a status code that will tell you why the messages are not being delivered.

Since outbound mail flow depends on DNS and firewall access you can also check those items. For example, to verify that MX records can be resolved in DNS by the Exchange server use the Resolve-DnsName cmdlet.

[PS] C:\>Resolve-DnsName gmail.com -Type MX

You can also test SMTP connectivity from the server using Telnet. Because the Telnet client is not installed by default on Windows Server you may need to install it first.

[PS] C:\>Install-WindowsFeature Telnet-Client
Success Restart Needed Exit Code      Feature Result
------- -------------- ---------      --------------
True    No             Success        {Telnet Client}

From a CMD prompt try to telnet to one of the MX records you resolved earlier.

C:\>telnet gmail-smtp-in.l.google.com 25
220 mx.google.com ESMTP bv3si49894863pbd.105 - gsmtp

If you do not see the 220 response and banner you may have an outbound SMTP connectivity issue that you need to look into further on your firewall.

Finally, if SMTP connectivity looks fine but the emails are still not being delivered you can enable protocol logging on your send connector and then use the log data to assist your troubleshooting.

[PS] C:\>Set-SendConnector "Internet Email" -ProtocolLoggingLevel Verbose

The protocol logs are stored by default in C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Hub\ProtocolLog\SmtpSend and can be opened and read in a text editor such as Notepad. The protocol log will show the SMTP conversation between your server and the external recipient’s server, so any SMTP errors should appear in the log.

Summary

Outbound mail flow from your Exchange 2016 server requires a send connector to be configured. In the article above I demonstrated how to configure a new send connector for a simple scenario, as well as some troubleshooting steps to help you test and validate that the send connector is working.

This article Outbound Mail Flow for Exchange Server 2016 is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

Configuring inbound mail flow for an Exchange Server 2016 environment is reasonably simple, however there are several different parts involved. For your server to receive email from the internet and deliver it to internal recipients there needs to be:

• An Accepted Domain configured for the organization
• An email address assigned to the recipient
• MX records in your public DNS zone
• SMTP connectivity from external senders to your Exchange server, or a mail route that leads to your Exchange server

The Exchange server will accept SMTP connections using a receive connector. A receive connector that is suitable for incoming email from the internet is pre-configured for you by Exchange setup, so there’s no need for you to configure one yourself. The receive connector is named Default Frontend SERVERNAME.

If you look at the properties of that connector you might notice that “Anonymous Users” is enabled as a permission group. Yes this is the correct configuration for the connector, and no that does not mean it can be abused as an open relay.

Configuring Accepted Domains

Accepted domains define which domain names your Exchange servers will accept email for. When you install a new Exchange 2016 server the DNS name of the Active Directory forest is automatically added as an accepted domain for the Exchange organization. If your Active Directory forest DNS name happens to match the SMTP domain you plan to use for email, then there’s no additional work required here. Similarly, if you’re installing Exchange 2016 into an existing Exchange organization, the accepted domains are likely already configured.

You can view your accepted domains in the Exchange Admin Center. Navigate to mail flow and then choose accepted domains. In my test environment the accepted domain of exchange2016demo.com is already present.

If you need to add a new accepted domain click the “+” icon, which launches a wizard for the task. Enter a name for the accepted domain, then the domain name itself (I always just configure those two values to be the same).

Notice the three options for the type of domain. The explanations are very clear, but to summarise:

• Authoritative – a domain for which your servers host the only recipients. For most scenarios this will be the correct choice.
• Internal relay – a domain for which your servers host some, but not all of the recipients. A typical use case for this type of accepted domain is a shared SMTP namespace, which is often required when two companies are merging or separating.
• External relay – a domain for which your server receives email, but hosts none of the recipients.

Add any domain names that you need for your organization, then move on to the email address policies.

Configuring Email Address Policies

The next step is to add email addresses to recipients in your organization. You can do this on a per-recipient basis, by simply opening the properties of the recipient (such as a mailbox), selecting email address, and adding the desired SMTP address.

Of course this is not a very efficient way to manage multiple recipients, and even though PowerShell is available for automating this step, the more effective method is to use email address policies. An email address policy is configured by default when you install a new Exchange 2016 server, or it will simply use the existing policy if you’re installing into an existing organization. Email address policies are found in the mail flow section of the Exchange Admin Center.

In my test environment the default email address policy configured by Exchange setup already contains the default accepted domain that was also configured by setup. The default address format is alias@domain, and we can either change that or add more address formats or addresses for different domain names to the policy if required.

Earlier you may have noticed the check box on the mailbox user that says:

Automatically update email addresses based on the email address policy applied to this recipient.

In effect this means that the email address policy shown above will stamp the SMTP addresses on that recipient (and all the other recipients with that check box enabled), without me having to add them manually.

Review or modify your email address policies and confirm that recipients have the desired SMTP addresses, then move on to DNS records.

Configuring MX Records in DNS

With the accepted domains and email addresses configured the next thing to look at is the MX records in the public DNS zone. At least one MX record is required for other email systems to be able to locate yours in DNS. The steps to add the MX record to your DNS zone will vary depending on the DNS control panel your provider gives you access to. Basically you will need to configure:

• An MX record that resolves to an A record, for example mail.exchange2013demo.com
• The A record that resolves to an IP address

You can test your MX record using PowerShell and the Resolve-DnsName cmdlet.

PS C:\> Resolve-DnsName -Type MX exchange2016demo.com
Name                                     Type   TTL   Section    NameExchange                              Preference
----                                     ----   ---   -------    ------------                              ----------
exchange2016demo.com                     MX     3600  Answer     mail.exchange2016demo.com                 40

Or you can use tools such as MXToolbox.com to test your MX records.

Configure and test your DNS records, then move on to SMTP connectivity.

Configuring SMTP Connectivity to the Exchange Server

The final piece of the solution is to establish SMTP connectivity to the Exchange server. There’s generally two approaches used for this:

• The firewall is configured to NAT and allow SMTP connections directly to the Exchange server (either the Mailbox server or an Edge Transport server)
• SMTP connections first go to an inbound smart host, such as an email security appliance or cloud service, which then routes the messages on to your Exchange server

Of course, there are many other variations of how inbound SMTP connectivity is established depending on the size and complexity of the organization, but those are two typical examples.

The configuration steps for your firewall will depend on the type of firewall you’re running. After configuring your firewall you can look at performing tests of your end to end solution.

Testing Inbound Mail Flow to Exchange

Considering all of the parts involved in this solution it’s important to test the configuration in a way that will help to pin-point any issues that may be present. I cover inbound SMTP connectivity troubleshooting in the following article:

• Troubleshooting SMTP Connectivity from External Senders

Summary

As you can see establishing inbound mail flow for an Exchange 2016 server involves the configuration of several different items. Fortunately some of them are configured automatically for you and require little adjustment for most environments.

This article Inbound Mail Flow for Exchange Server 2016 is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

My guest for this episode is Michael Van Horenbeeck.

Michael is a Microsoft Certified Solutions Master, and an Exchange Server MVP from Belgium. He works for Enow, a company that provides systems management software for Microsoft technologies, specializing in Exchange, Office 365, Active Directory and Skype for Business.

This episode of the Exchange Server Pro Podcast is brought to you by Office 365 for Exchange Professionals, the most comprehensive and up to date guide to Microsoft’s Office 365 cloud services. Find out more at Office365forExchangePros.com.

In this episode Michael and I discuss Hybrid Exchange deployments with Office 365, and what’s new in Hybrid for Exchange Server 2016.

Subscribe on iTunes, Stitcher, or RSS.

Links:

• Follow @mvanhorenbeeck on Twitter
• Michael’s blog

This article Podcast Episode 5: Hybrid Exchange with Michael Van Horenbeeck is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

In most organizations there are several devices or applications that need to use an SMTP service to send email messages. An Exchange 2016 server can provide that service for you, however the configuration required on the server depends on the SMTP relay requirements of your scenario.

There are generally two types of SMTP relay scenarios that Exchange Server 2016 is used for:

• Internal relay – devices and applications that need to send email messages only to internal recipients in the Exchange organization.
• External relay – devices and applications that need to send email messages to external recipients.

Let’s take a look at each of those scenarios, and then some additional considerations when you are deploying this in your own production environments.

Internal SMTP Relay with Exchange Server 2016

When Exchange Server 2016 is first installed the setup routine automatically creates a receive connector that is pre-configured to be used for receiving email messages from anonymous senders to internal recipients. This allows inbound internet email to be received by the server, and is also suitable for internal relay scenarios.

The receive connector is named “SERVERNAME\Default Frontend SERVERNAME”, for example, “EXSERVER\Default Frontend EXSERVER” in my test environment.

[PS] C:\>Get-ReceiveConnector
Identity                                Bindings                                Enabled
--------                                --------                                -------
EXSERVER\Default EXSERVER               {0.0.0.0:2525, [::]:2525}               True
EXSERVER\Client Proxy EXSERVER          {[::]:465, 0.0.0.0:465}                 True
EXSERVER\Default Frontend EXSERVER      {[::]:25, 0.0.0.0:25}                   True
EXSERVER\Outbound Proxy Frontend EXS... {[::]:717, 0.0.0.0:717}                 True
EXSERVER\Client Frontend EXSERVER       {[::]:587, 0.0.0.0:587}                 True

You can test this connector by making an SMTP connection using Telnet and issuing SMTP commands. For example:

C:\>telnet exserver 25
220 EXSERVER.exchange2016demo.com Microsoft ESMTP MAIL Service ready at Thu, 22
Oct 2015 11:39:23 +1000
helo
250 EXSERVER.exchange2016demo.com Hello [192.168.0.30]
mail from: test@test.com
250 2.1.0 Sender OK
rcpt to: adam.wally@exchange2016demo.com
250 2.1.5 Recipient OK
Data
354 Start mail input; end with .
Subject: Test email
Testing
.
250 2.6.0 <f7c2f921-ff7e-4ce4-b2eb-a70dc52f225f@EXSERVER.exchange2016demo.com> [
InternalId=854698491929, Hostname=EXSERVER.exchange2016demo.com] Queued mail for
 delivery

So there’s no specific configuration required on the server or the connectors to allow this scenario, however it is recommended that you use a DNS alias instead of the real server name. This will allow you to configure all of your devices and applications with the DNS alias, and you can later move that DNS alias to point to a different Exchange server during a migration.

External SMTP Relay with Exchange Server 2016

Continuing from the previous demonstration, let’s see what happens if I try to use Telnet to send an email message from a valid internal address to an external recipient.

220 EXSERVER.exchange2016demo.com Microsoft ESMTP MAIL Service ready at Thu, 22
Oct 2015 12:04:45 +1000
helo
250 EXSERVER.exchange2016demo.com Hello [192.168.0.30]
mail from: adam.wally@exchange2016demo.com
250 2.1.0 Sender OK
rcpt to: exchangeserverpro@gmail.com
550 5.7.54 SMTP; Unable to relay recipient in non-accepted domain

An SMTP error code “550 5.7.54, Unable to relay recipient in non-accepted domain” is received instead. The receive connector will not allow an anonymous, unauthenticated sender to relay to external domain names, which prevents your server from being exploited as an open relay.

There are two ways you can resolve this and allow your devices and applications to send to external recipients:

• Using authentication for SMTP connections
• Configuring an anonymous SMTP relay connector

External SMTP Relay with Exchange Server 2016 Using Authentication

The first method is to use authenticated SMTP connections. Exchange Server 2016 has a receive connector designed to be used by clients that need to send via SMTP called “SERVERNAME\Client Frontend SERVERNAME”, for example “EXSERVER\Client Frontend EXSERVER” in my test environment.

[PS] C:\>Get-ReceiveConnector
Identity                                Bindings                                Enabled
--------                                --------                                -------
EXSERVER\Default EXSERVER               {0.0.0.0:2525, [::]:2525}               True
EXSERVER\Client Proxy EXSERVER          {[::]:465, 0.0.0.0:465}                 True
EXSERVER\Default Frontend EXSERVER      {[::]:25, 0.0.0.0:25}                   True
EXSERVER\Outbound Proxy Frontend EXS... {[::]:717, 0.0.0.0:717}                 True
EXSERVER\Client Frontend EXSERVER       {[::]:587, 0.0.0.0:587}                 True

Minimal configuration is required to get this working. Assuming you’ve already configured an SSL certificate for Exchange Server 2016, and added a DNS alias for your SMTP devices and applications to use (I’m using a DNS alias of mail.exchange2016demo.com in this example), you should then also set the TlsCertificateName for the receive connector.

Use Get-ExchangeCertificate to identify the thumbprint of the SSL certificate you’ll be using.

[PS] C:\>Get-ExchangeCertificate
Thumbprint                                Services   Subject
----------                                --------   -------
FC5259C0528657EF22BB818CA9B23FD220A9DE83  ...WS..    CN=mail.exchange2016demo.com, OU=IT, O=LockLAN Systems Pty Ltd,...
FE6528BE1548D81C794AE9A00D144FF3D16E0CD2  ....S..    CN=Microsoft Exchange Server Auth Certificate
DAB089E53CA660DEF7B8EE303212C31C0E3D3499  IP.WS..    CN=EXSERVER
17839AF62AA3A1CBBD5F7EC81E92A609976D8AD9  .......    CN=WMSvc-EXSERVER

The syntax of the TlsCertificateName string is made up of two different attributes of the certificate, so I use the following commands to apply the configuration to my receive connector.

[PS] C:\>$cert = Get-ExchangeCertificate -Thumbprint FC5259C0528657EF22BB818CA9B23FD220A9DE83
[PS] C:\>$tlscertificatename = "<i>$($cert.Issuer)<s>$($cert.Subject)"
[PS] C:\>Set-ReceiveConnector "EXSERVER\Client Frontend EXSERVER" -Fqdn mail.exchange2016demo.com -TlsCertificateName $tlscertificatename

To test using the Client Frontend connector to send an email message I’m going to use PowerShell’s Send-MailMessage cmdlet instead of Telnet. First, capture some valid credentials to use for authentication.

PS C:\>$credential = Get-Credential

Next, use the Send-MailMessage cmdlet with parameters specifying the server, to and from addresses, subject line, and the port number.

PS C:\>Send-MailMessage -SmtpServer mail.exchange2016demo.com -Credential $credential -From 'adam.wally@exchange2016demo.com' -To 'exchangeserverpro@gmail.com' -Subject 'Test email' -Port 587 -UseSsl

In the above example the email is successfully received by the external recipient. So any device or application on the network that can use authenticated SMTP can be set up to use that connector listening on port 587 on your Exchange 2016 server.

External SMTP Relay with Exchange Server 2016 Using Anonymous Connections

When authenticated SMTP is not an option you can create a new receive connector on the Exchange 2016 server that will allow anonymous SMTP relay from a specific list of IP addresses or IP ranges.

In the Exchange Admin Center navigate to mail flow and then receive connectors. Select the server that you want to create the new receive connector on, and click the “+” button to start the wizard.

Give the new connector a name. I like to keep the name consistent with the other default connectors. Set the Role to “Frontend Transport”, and the Type to “Custom”.

The default Network adapter bindings are fine. This represents the IP and port that the server will be listening on for connections. Multiple receive connectors on the Frontend Transport service can listen on the same port of TCP 25.

Remove the default IP range from the Remote network settings, and then add in the specific IP addresses or IP ranges that you want to allow anonymous SMTP relay from. I do not recommend adding entire IP subnets that contain other Exchange servers as this can cause issues with server to server communications.

Click Finish to complete the wizard, then there is some additional configuration still required.

In the Exchange Management Shell run the following two commands.

[PS] C:\>Set-ReceiveConnector "EXSERVER\Anon Relay EXSERVER" -PermissionGroups AnonymousUsers
[PS] C:\>Get-ReceiveConnector "EXSERVER\Anon Relay EXSERVER" | Add-ADPermission -User 'NT AUTHORITY\Anonymous Logon' -ExtendedRights MS-Exch-SMTP-Accept-Any-Recipient

We can now test the connector using Telnet from the IP address that was added to the remote network settings of the receive connector. In my test environment that IP address will now be allowed to send email from any email address (whether it is a valid internal address or not) to any external address.

220 EXSERVER.exchange2016demo.com Microsoft ESMTP MAIL Service ready at Thu, 22
Oct 2015 12:59:39 +1000
helo
250 EXSERVER.exchange2016demo.com Hello [192.168.0.30]
mail from: test@test.com
250 2.1.0 Sender OK
rcpt to: exchangeserverpro@gmail.com
250 2.1.5 Recipient OK
Data
354 Start mail input; end with .
Subject: test
.
250 2.6.0 <e1739c5f-db11-4fdd-aa27-a9702bc15b15@EXSERVER.exchange2016demo.com> [
InternalId=863288426497, Hostname=EXSERVER.exchange2016demo.com] Queued mail for
 delivery

Additional Considerations

Here’s some additional items that you should consider when you’re providing SMTP relay services with Exchange Server 2016 for your environment.

High Availability and Load Balancing

If you want to provide a highly available SMTP service then a load balancer is the natural solution. If you plan to load balance you’ll need to ensure that the same receive connectors exist on all of the servers in the load balanced pool. This means creating the same relay connector on multiple servers and managing the same list of permitted IP addresses on those connectors.

However, as you’ll see by reading my article on issues with load balancing SMTP traffic, when a load balancer is source NATing the connections the only IP address that will appear to the Exchange server is that of the load balancer itself, not the source device or application. While this simplifies the receive connector configuration (only the load balancer IP needs to be added as an allowed IP) it opens up a number of concerns:

• Access control (which IP’s are allowed to send) needs to be applied at the load balancer, or you risk having a wide open anonymous SMTP relay service on your network
• Depending on the load balancer, health probes to the Exchange servers may not detect all health conditions, resulting in traffic being sent to unhealthy servers (and failing)
• Connections made via the load balancer are anonymous and in some cases untraceable to the source IP (depending on what logging your load balancer is capable of)

You can read more about these issues here.

If a load balancer is not an option for you and you still want some high availability for SMTP services, then you can consider DNS round robin. However, many devices and applications do not handle DNS round robin as well as Outlook or a web browser would. Some devices, when they attempt a connection to one of several IP addresses available in DNS round robin and that IP address is not responding, will not try other IP addresses that are available and will simply consider the connection attempt failed. So it really depends on how well your devices and applications deal with that situation as to whether DNS round robin will be suitable for your environment.

Security vs Convenience

A lot of organizations simply go with the anonymous relay option and set up a connector that allows wide ranges of IP addresses to relay email anywhere. This is the simplest approach, but clearly not the best in terms of security and auditing. Anonymous relay relies on trusted, identifiable IP addresses. If the IP addresses are in a DHCP pool, are associated with a load balancer (see above), are multi-user (such as terminal servers), or the IP/host itself is compromised in some way, then your ability to trace emails back to the real source is difficult if not impossible.

Although authentication adds some complexity, it may be worth it from security perspective. However it does mean managing credentials for all of your devices and applications. Sharing SMTP credentials across multiple systems might seem like a way to avoid complexity, but it re-introduces the problems associated with anonymous SMTP.

Encryption

In the tutorial above I demonstrated configuring a TLS certificate name for a receive connector and also used TLS/SSL for my testing with Send-MailMessage. If you are going to use authentication for SMTP in your environment, or the SMTP traffic is in any way sensitive, then you should protect it with TLS/SSL encryption.

Multiple Receive Connectors

You may be wondering how the Exchange server is able to differentiate between traffic destined for one receive connector vs another receive connector, when both of them are listening on the same IP address and port number, for example “EXSERVER\Default Frontend EXSERVER” and “EXSERVER\Anon Relay EXSERVER”.

The answer is in the Remote network settings of the receive connectors. Exchange will use the receive connector that is the most specific match for the source IP address of the SMTP connection.

In my examples above this means that the default connector with its remote network settings of 0.0.0.0-255.255.255.255 (which is basically “anywhere”) is less specific than the relay connector with its remote network settings of 192.168.0.30. So when an SMTP connection comes from IP 192.168.0.30 to port 25 on the server it will be handled by the relay connector, while everything else connecting to port 25 will be handled by the default connector.

Troubleshooting

One of the most common issues when troubleshooting receive connector behaviour on an Exchange server is determine which connector is actually handling a given connection. There are two ways to approach this type of troubleshooting.

The first is to set different SMTP banners on each connector. Exchange MVP Jeff Guillet has a PowerShell example that you can run to configure each connector’s SMTP banner with the name of the connector itself, so that when you connect with Telnet you can immediately see which receive connector you’ve connected to.

[PS] C:\>$rc = Get-ReceiveConnector -Server EXSERVER
[PS] C:\>$rc | % {Set-ReceiveConnector $_.Identity -ProtocolLoggingLevel Verbose  -Banner "220 $_"}

Now when you use Telnet to connect you will see the connector name in the banner.

C:\>telnet exserver 25
220 EXSERVER\Anon Relay EXSERVER

The other troubleshooting method is to use protocol logging. In the PowerShell example above the protocol log level for each connector was also set to “Verbose”. You can set this on individual connectors if you need to by running Set-ReceiveConnector.

[PS] C:\>Set-ReceiveConnector "EXSERVER\Anon Relay EXSERVER" -ProtocolLoggingLevel Verbose

You can then review the protocol logs to determine what is happening to SMTP connections. I generally recommend you leave protocol logging enabled for receive connectors at all times.

Summary

This article demonstrates how Exchange Server 2016 can be used to provide SMTP relay services to devices and applications on your network. As you can see there are multiple approaches that you can take to achieve this, each being suitable for different scenarios, and each having some pros and cons associated with it.

Internal relay needs are already met with the default configuration of an Exchange 2016, and authenticated SMTP for external relay is also available with minimal setup. When anonymous relay is required an additional receive connector can be easily configured.

I do recommend that you consider your actual requirements and implement the most appropriate solution to meet them, instead of simply configuring an anonymous relay connector for all devices and applications on your network.

This article How to Configure Exchange Server 2016 for SMTP Application Relay is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

Although the trend in recent years is towards larger and larger mailboxes there are still many organizations that set mailbox quotas for their Exchange users. I do actually recommend setting mailbox quotas in just about every organization anyway, because “unlimited” can be dangerous from a capacity management perspective if left unmonitored. A very large quota that is effectively “unlimited” is better, in my opinion.

In some operational roles where I’ve worked and where quotas were in use there was a fairly regular requirement to bump up a specific mailbox user’s quota. Often the request was worded as “Can you add 10% to Adam Wally’s mailbox quotas.”

There’s two administrative challenges with that request, although they are relatively minor:

• You need to calculate what the new quotas should be ($currentquota + 10%) for each of the IssueWarningQuota, ProhibitSendQuota, and ProhibitSendReceiveQuota settings.
• You need to navigate through the Exchange Admin Center or run a long-ish PowerShell command to set the new values.
• If the request is for more than one user, the above tasks are very repetitive and time-consuming.

Set-MailboxQuota.ps1 is a PowerShell script written to solve those problems. This script can be run against a single mailbox, or multiple mailboxes. There are three options when running the script:

• Set the mailbox to use the default quota thresholds configured on the mailbox database
• Increase each of the mailbox quotas by a specified percentage
• Decrease each of the mailbox quotas by a specific percentage

Examples:

This command will set Alannah Shaw’s mailbox to use the default quotas that are configured on the database hosting their mailbox.

[PS] C:\Scripts>.\Set-MailboxQuota.ps1 -Mailbox Alannah.Shaw -UseDatabaseDefaults
----------------------------------------
Mailbox: Alannah Shaw
----------------------------------------
Uses Database Defaults: False
Warning Quota: 1.88 GB (2,019,086,336 bytes)
Prohibit Send Quota: 1.98 GB (2,126,010,368 bytes)
Prohibit Send/Receive Quota: 2.277 GB (2,444,702,720 bytes)
Alannah Shaw has been configured to use database quota defaults.
----------------------------------------

This command will increase Alannah Shaw’s mailbox quota values by 10%.

[PS] C:\Scripts>.\Set-MailboxQuota.ps1 -Mailbox Alannah.Shaw -IncreaseByPercentage 10
----------------------------------------
Mailbox: Alannah Shaw
----------------------------------------
Uses Database Defaults: True
Warning Quota: 1.899 GB (2,039,480,320 bytes)
Prohibit Send Quota: 2 GB (2,147,483,648 bytes)
Prohibit Send/Receive Quota: 2.3 GB (2,469,396,480 bytes)
Calculating new quotas
Current warning quota: 1991680 KB
New warning quota: 2190848 KB
Current send quota: 2097152 KB
New send quota: 2306867.2 KB
Current send/rec quota: 2411520 KB
New send/rec quota: 2652672 KB
Setting new quotas
Quotas increased by 10 percent
----------------------------------------

This command will set all mailboxes on database DB01 to use the default quota values configured on the database.

[PS] C:\Scripts>Get-Mailbox -Database DB01 | .\Set-MailboxQuota.ps1 -UseDatabaseDefaults

if any of the current quota levels for the mailbox user or the database they’re hosted on are set to “Unlimited” the script will not make any changes to the mailbox.

Set-MailboxQuota.ps1 is available for download from the TechNet Script Gallery and Github. Comments are welcome below.

This article Set-MailboxQuota.ps1 – A PowerShell Script for Configuring Exchange Server Mailbox Quotas is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

Exchange Server 2016 can be installed into an existing Exchange organization as long as it meets the system requirements. This includes:

• No Exchange Server 2007 or earlier versions of Exchange in the organization
• Any Exchange Server 2010 servers must be running at least Service Pack 3 with Update Rollup 11
• Any Exchange Server 2013 servers must be running at least Cumulative Update 10

You can have a combination of Exchange 2010 and 2013 servers in the organization as long as they each meet those minimum versions.

If you have Edge Transport servers or legacy server objects that were not properly removed from Active Directory you may encounter a setup error when you first try to install Exchange Server 2016. You can find more details about this, and the solutions, at the following article:

• All Exchange 2013 Servers in the Organization Must Have Exchange 2013 Cumulative Update 10 or Later Installed

In your Active Directory environment the following requirements exist:

• All domain controllers must be running at least Windows Server 2008
• The forest functional level must be at least Windows Server 2008 (steps here)

The system requirements for Exchange Server 2016 may change over time so always be sure to check TechNet for the latest information.

When you have your environment ready you can:

• Install the Exchange Server 2016 pre-requisites on the server that will be running Exchange
• Install Exchange Server 2016

When you’re running Exchange setup note that:

• You do not need to provide an organization name when you’re installing into an existing organization
• There is Active Directory preparation performed automatically by setup when you install the first Exchange 2016 server. If you’d prefer to handle those steps separately you can do so (the steps are broken out separately in this article)

After Exchange Server 2016 has been installed you should, at minimum, configure the Autodiscover namespace to avoid certificate warnings appearing for Outlook clients in your environment. You can then proceed with the rest of your Exchange Server 2016 configuration, such as:

• Namespace configuration
• SSL certificate installation

This article Installing Exchange Server 2016 into an Existing Organization is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

When you are installing Exchange Server 2016 into an existing organization you may encounter a setup error:

All Exchange 2013 servers in the organization must have Exchange 2013 Cumulative Update 10 or later installed.

Cumulative Update 10 for Exchange Server 2013 is the minimum requirement for co-existence with Exchange Server 2016. However, even if you have upgraded all of your Exchange 2013 servers to CU10 you may still see the error message due to other circumstances such as:

• You have one or more Edge Transport servers in the environment
• An improperly removed Exchange server object still exists in Active Directory

Updating Edge Transport Server Build Details

The Edge Transport issue is the simplest to correct. The cause of this issue is that Active Directory does not update the build version of the Edge Transport when the server itself is upgraded to a newer cumulative update, because the EdgeSync process is one way only.

In my environment this is the version that the Edge Transport server is actually at:

[PS] C:\>Get-ExchangeServer EX2013EDGE | fl *version*
AdminDisplayVersion : Version 15.0 (Build 1130.7)
ExchangeVersion     : 0.1 (8.0.535.0)

In Active Directory it is still displayed as the earlier version that it was running when the Edge Subscription was created.

[PS] C:\>Get-ExchangeServer EX2013EDGE | fl *version*
AdminDisplayVersion : Version 15.0 (Build 1104.5)
ExchangeVersion     : 0.1 (8.0.535.0)

To resolve the issue simply remove and recreate the Edge Subscription. On the Edge Transport server:

[PS] C:\>Get-EdgeSubscription | Remove-EdgeSubscription
Confirm
Are you sure you want to perform this action?
Removing Edge Subscription "EX2013EDGE".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y
Confirm
Do you want to remove recipients? You don't need to remove the recipients that have already synchronized to this Edge
server if you will re-subscribe it to the same organization. This would improve the performance of Edge synchronization
 when you re-subscribe.
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): n

On an internal Exchange 2013 server:

[PS] C:\>Get-EdgeSubscription EX2013EDGE | Remove-EdgeSubscription
Confirm
Are you sure you want to perform this action?
Removing Edge Subscription "EX2013EDGE".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is "Y"): y

Then follow these steps to recreate the Edge Subscription.

Resolving Improperly Removed Exchange Servers in Active Directory

If your Active Directory contains Exchange server objects for servers that no longer exist then it is likely that at some stage in the past someone decommissioned a server in your environment without properly uninstalling it. This can be resolved by removing the object from Active Directory.

The supported method for removing an old Exchange server object from Active Directory is to install a new Windows server of the same name and then perform a recovery install of Exchange onto that server. After Exchange has been installed you can then cleanly uninstall the server.

The unsupported method is to use ADSIEdit to remove the server object from the Configuration partition.

My recommendation to you is to use the supported method.

This article All Exchange 2013 Servers in the Organization Must Have Exchange 2013 Cumulative Update 10 or Later Installed is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

Exchange Server setup may fail with an error message:

“Microsoft.Exchange.Configuration.Tasks.ServiceDidNotReachStatusException:
Service ‘WMSVC’ failed to reach status ‘Running’ on this server.

In the Exchange setup log file you may see the following lines:

Current service status query time is '10/26/2015 3:11:17 PM'.
Will wait '25000' milliseconds for the service 'WMSVC' to reach status 'Running'.
Service 'WMSVC' failed to reach status 'Running' on this server after waiting for '25000' milliseconds.
[2] [WARNING] Service checkpoint has not progressed. Previous checkpoint='0'- Current checkpoint='0'.

In the Application event log of the server Event ID 1007 may appear:

Log Name:      Application
Source:        Microsoft-Windows-IIS-IISManager
Date:          10/26/2015 3:00:54 PM
Event ID:      1007
Description:
The following information was included with the event:
IISWMSVC_STARTUP_UNABLE_TO_READ_CERTIFICATE
Unable to read the certificate with thumbprint '7557c2f111b0448b6c90f491cb92e9e7e401089a'.
Please make sure the SSL certificate exists and that is correctly configured in the Management Service page.
Process:WMSvc
User=NT AUTHORITY\LOCAL SERVICE

A common cause of this problem is that the WMSVC certificate has been deleted from the certificate store on the server. The certificate can be recreated to resolve the issue.

Open IIS Manager on the server. Select the server name and then open Server Certificates.

In the actions pane click Create Self-Signed Certificate.

Name the certificate “WMSVC” and complete the creation of the self-signed certificate.

Next, open Management Service.

Select the self-signed certificate that you just created, and apply the change.

You should now be able to start the management service.

Restart Exchange setup and it should proceed past this step and complete successfully.

This article Service ‘WMSVC’ Failed to Reach Status ‘Running’ On This Server is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

My guest for this episode is Jeff Guillet.

Jeff is an Exchange Server MVP as well as a Microsoft Certified Solutions Master for Exchange, and works as a Principal Systems Architect for ExtraTeam in the San Francisco Bay Area.

This episode of the Exchange Server Pro Podcast is brought to you by Office 365 for Exchange Professionals, the most comprehensive and up to date guide to Microsoft’s Office 365 cloud services. Find out more at Office365forExchangePros.com.

In this episode Jeff and I discuss Exchange Server and Office 365 migrations, as well as Jeff’s home lab server builds.

Subscribe on iTunes, Stitcher, or RSS.

Links:

• Jeff’s blog expta.com
• Jeff’s GEN6 Home Lab Server Builds
• Follow @expta on Twitter

This article Podcast Episode 6: Exchange Migrations with Jeff Guillet is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

There’s plenty of excitement to be had when it comes to backup and recovery of Exchange servers. The excitement isn’t so much in the setting up and day to day operations of the backups, it’s more in the hoping that you’ll be able to get back the data you need when you find yourself in a recovery situation.

Over the years I have witnessed many unfortunate data loss incidents that were ultimately the fault of incorrectly configured, or non-operational backups. The simple fact is that failures happen. One day your server or storage will fail, and you’ll need to recover the data that it was hosting. You should expect that to happen. If you don’t have reliable backups then you might find yourself suddenly needing to update your resume and get your best suit dry cleaned.

This is the first part of a series on backup and recovery for Exchange Server 2016, and will provide an introduction to backup and recovery concepts for Exchange 2016. Throughout this series of articles I’ll also cover:

• How to backup Exchange Server 2016 with Windows Server Backup
• How to restore an Exchange Server 2016 database from backup
• How to restore individual Exchange Server 2016 mailboxes and mailbox items
• How to recover a failed Exchange Server 2016 standalone server
• How to recovery a failed Exchange Server 2016 database availability group member

Let’s get started by covering some of the general concepts around Exchange Server 2016 backup and recovery.

Backup and Recovery Terminology

As you deal with different Exchange Server backup and recovery scenarios you’ll encounter a lot of the same terminology, so let’s start with that.

Types of Backup

There are four backup types that you’ll generally see referred to in backup products and documentation.

• Full – a complete copy of the data on a server, volume, application or file system. For Exchange 2016 database backups a “full” backup is sometimes also referred to as a “VSS Full” or an “application aware” backup. A full backup will include all of the data regardless of whether the data has changed since the last backup or not. A full backup is a complete set of data that can be used for a restore.
• Incremental – a partial copy of the data on a server, volume, application or file system. An incremental backup will only include data that has changed since the last full or incremental backup. In a restore scenario the last full backup, plus all subsequent incremental backups up to the point in time you’re restoring to, will be required for the recovery to be successful.
• Differential – similar to an incremental backup, however a differential backup does not mark the data as having been backed up. This means that differential backup sets tend to get larger and larger as you get further away from the last full backup. However in a restore scenario differentials can be simpler than incrementals because you only need the last full backup plus the latest differential backup to perform the recovery.
• Copy – similar to a full, however the data is not marked as having been backed up. Copy backups are typically used to make a copy of data to another system for testing purposes. Copy backups are not suitable for recovery scenarios involving Exchange databases.

Each backup type has pros and cons. Full backups are the simplest to operate and recover from, but take the longest to run. Using a mixture of full backups plus incremental or differential backups can shorten some of your backup job times, but at the cost of extra time and complexity when you need to perform a recovery.

In addition to the backup types listed above you’ll encounter other terminology in various backup products such as “synthetic full” backups. Those terms can mean many different things depending on the backup vendor, so you should refer to the specific documentation for those products to find out more.

Backup Storage

Different backup products support writing and storing backup sets on a wide variety of storage types.

• Tape – magnetic tape backup media that is available in many different formats and capacities. Tape is still commonly used today but not always as a primary backup media. Instead it is often used to replicate backup sets from disk storage so that a copy of the backed up data can be taken offsite.
• Disk – very large capacity disk storage is very cheap these days, faster than tape for many backup and recovery scenarios, and often has attractive features such as hardware-based de-duplication, compression, and replication.
• Cloud – there are many cloud-based storage providers to choose from these days, such as Amazon Web Services and Microsoft Azure. These providers sell storage by the gigabyte, usually at very low cost. Cloud-based backup storage often includes built-in replication of your data to protect it from failures in the cloud provider’s infrastructure. Cloud-based backup storage is also very practical in that you do not need to purchase large amounts of it up front as you do with on-site backup storage.

Cloud-based backup is becoming very popular these days, however backing up large amounts of data to the cloud does require good network bandwidth between you and your provider. It can also be slower to restore from. Some organizations use cloud-based storage as an off-site replica of their on-premises disk-based backup storage. Some even combine all three, backing up primarily to on-site disk, then replicating that to the cloud while also making copies of specific data to tape (usually multiple tapes) to be stored off-site for specific retention requirements.

When you are considering backup storage for your Exchange 2016 servers remember to follow the 3-2-1 Rule:

• At least 3 copies of the data
• Stored on at least 2 different media
• At least 1 copy kept off-site

Other General Terminology

Here’s some additional terms you may need to be familiar with.

• RPO – stands for Recovery Point Objective. The RPO is the point in time that you are attempting to recover data from. For example, attempting to recover a mailbox from 5pm last Monday. The RPO may also define how much data loss a business is willing to accept in the event of a disaster, and your backup solution should be designed to meet that RPO. For example, if the business tells you that they are willing to accept up to 24 hours of data loss, then running only a weekly backup is obviously not acceptable.
• RTO – stands for Recovery Time Objective. The RTO defines the amount of time that is acceptable to perform a recovery after a disaster. Your backup solution should be designed to meet the RTO as well. For example, if the business requires an RTO of 8 hours but it would take you 20 hours to retrieve tapes from off-site storage and recover from them, then you would not be able to meet the RTO. However you should also be aware that the RTO can be impacted by infrastructure other than the Exchange server itself. If you virtualize your Exchange servers the the virtualization hosts are lost in a disaster, then obviously you can’t start to recover the Exchange VM until some other host is available.
• VSS – stands for Volume Shadow-copy Service. VSS is part of the Windows Server operating system and is used to make application-aware backups of Exchange 2016 databases.
• Recovery Database – a special type of Exchange server database that is used as the target for a database restore operation. Data within the mailboxes of a recovery database can’t be accessed by clients but can be extracted by the administrator and restored into a user’s mailbox.
• Database Portability – this refers to Exchange Server 2016’s capability to mount databases that have been copied or restored from other Exchange 2016 servers within the same Exchange organization. This is useful when the original server that hosted the database is no longer available for the recovery operation.
• Dial Tone Recovery – this refers to Exchange Server 2016’s capability to mount a temporary database with empty mailboxes for end users to connect to so that they can continue to send and receive emails. A dial tone recovery is often used to restore service for end users while the much longer process of recovery the mailbox data from backup is performed.
• Log Truncation – all changes (transactions) to an Exchange 2016 database are stored in a memory buffer and also written to transaction log files. Periodically the memory buffer is flushed by committing changes to the database file itself. As there is generally some gap between what is written to the transaction log files and what has been committed to the database the log files become very important in a recovery scenario. Transaction logs accumulate on the server (and consume disk space) until the next database backup. When a full backup of the database is taken the server will remove the transaction log files that are no longer needed for recovery now that a backup of the database up to that specific point in time has been successfully taken.
• Circular Logging – when circular logging is enabled the transaction logs are automatically truncated as the changes are committed to the database file. This reduces the disk space consumption by the transaction logs, but removes the ability to recover the database beyond the point of the most recent backup.

As an additional note you may encounter snapshot-based backup systems in the real world, especially when you’re running virtualized Exchange servers. While a snapshot-based backup solution may still be supported for backups, providing it takes an application-aware backup that properly truncates the transaction logs, snapshots are not supported for recovery purposes. Many snapshot-based backup products provide different processes or tools to use for recovering data from their backup sets that do not involve “rolling back” the VM to the last snapshot, which is fine. I mention this because a common mistake by administrators is to take a snapshot of an Exchange VM before any routine maintenance (such as monthly security patching) with the expectation that they can “roll back” the VM using that snapshot if something goes wrong with the patching. Unfortunately this type of snapshot recovery can be catastrophic for an Exchange server.

What to Backup for Exchange Server 2016

Exchange Server 2016 has two server roles; Mailbox and Edge Transport. The backup requirements for each server role are different.

• Edge Transport – a full server backup is generally advisable, however it is not necessarily a requirement. If your ability to rebuild and reinstall the Edge Transport server (for example with an automated operating system deployment and pre-scripted Exchange installation and configuration) allows you to restore operation within an acceptable timeframe then you would not necessarily need to also use traditional backups for the server.
• Mailbox – similar to the Edge Transport server you may consider not backing up the server operating system itself if you have fast enough rebuild processes. However, Mailbox servers also host the databases containing mailbox and public folder data, as well as the transport databases that may contain email messages still in transit. Therefore it is recommended to back up at least the databases, if not the entire server.

Aside from the considerations above you should also think about the various log files that are stored on the Exchange servers, such as event logs or message tracking logs. Those are important for historical purposes.

If you’re in any doubt as to what you should be backing up on your Exchange servers I recommend you err on the side of caution and backup everything.

Summary

In this article I’ve provided an overview of backup and recovery concepts that may apply to Exchange Server 2016. In the next part of this series we’ll look at backing up Exchange Server 2016 with Windows Server Backup.

This article Introduction to Exchange Server 2016 Backup and Recovery is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

In this article in the series on Exchange Server 2016 backup and recovery we’ll look at backing up Exchange Server 2016 using Windows Server Backup.

For this scenario I’m using a single Exchange 2016 Mailbox server that is not a member of a database availability group. The server hosts a single mailbox database, with the database file on D:\ drive and the transaction logs on E:\ drive. An additional volume has been created for the server to host the backup files.

[PS] C:\>Get-ExchangeServer
Name                Site                 ServerRole  Edition     AdminDisplayVersion
----                ----                 ----------  -------     -------------------
EXSERVER            exchange2016demo.... Mailbox,... Standard... Version 15.1 (Bu...
[PS] C:\>Get-MailboxDatabase | Select Name,EdbFilePath,LogFolderPath
Name          : DB01
EdbFilePath   : D:\DB01\DB01.edb
LogFolderPath : E:\DB01

The Windows Server Backup feature is not installed by default so the first step we need to perform is to install it on the server.

PS C:\> Install-WindowsFeature Windows-Server-Backup
Success Restart Needed Exit Code      Feature Result
------- -------------- ---------      --------------
True    No             Success        {Windows Server Backup}

Now we can launch Windows Server Backup and configure the scheduled backup job.

After launching Windows Server Backup select Local Backup from the left side and then click Backup Schedule in the Actions pane on the right side.

When the Backup Schedule Wizard launches you have the choice to create a full server backup, or a custom backup.

Creating a Full Server Backup of Exchange Server 2016

Select Full server from the backup configuration choice and then click Next. Choose the backup time and frequency you need for your environment.

Choose your backup destination. I’m backing up to a hard disk that is dedicated for Windows Server Backup to use.

Click Show All Available Disks and add the volume you’re using for backups, then select it before you continue to the next step.

At the confirmation screen verify that all your selections are correct. Note that VSS Full Backup is automatically chosen as the backup type, which is correct for this scenario.

Click Finish to create the backup job. It will run at the next scheduled time.

Creating a Custom Backup of Exchange Server 2016

In some situations you may want to create a custom backup selection for Windows Server Backup to use when backing up Exchange Server 2016. I recommend that you only do this if you understand what you’re excluding from the backup.

At the beginning of the Backup Schedule Wizard choose Custom instead of Full server. Add the items you want to back up. If you’re backing up Exchange databases you must select the entire volume, not just the folders containing the database and transaction log files.

After adding your selections click the Advanced Settings button.

On the VSS Settings tab select VSS full backup. If you do not make this change the backup will not truncate the transaction logs for the databases.

Set the scheduled time and frequency for your backup job to run.

Set the destination to store the backups. I’m using a dedicated hard disk for this demonstration.

Click Show Available Disks and add the volume that you will be backing up to, and then select it for this backup job.

Confirm your selections and that you have chosen VSS Full Backup, then click Finish to create the scheduled backup job.

Monitoring Backup Results for Exchange Server 2016

When you’re backing up Exchange Server 2016 there’s two places to look when checking the results of your backup jobs:

• The backup software’s logs or reports
• The Exchange server’s database backup timestamps

Since I’ve used Windows Server Backup in this example I can check the status of the last backup job in the console and confirm that it ran successfully.

However I don’t recommend that you rely solely on the backup software to confirm that your backups are running successfully. You should also check it on the Exchange databases themselves.

To check the Exchange server’s database backup timestamps use the Get-MailboxDatabase cmdlet.

[PS] C:\>Get-MailboxDatabase -Status | Select Name,*backup*
Name                           : DB01
BackupInProgress               : False
SnapshotLastFullBackup         : True
SnapshotLastIncrementalBackup  :
SnapshotLastDifferentialBackup :
SnapshotLastCopyBackup         :
LastFullBackup                 : 28/10/2015 4:24:34 PM
LastIncrementalBackup          :
LastDifferentialBackup         :
LastCopyBackup                 :
RetainDeletedItemsUntilBackup  : False

For an automated, daily check of your Exchange Server 2016 backups I recommend using my Get-DailyBackupAlerts.ps1 script.

This article Backing up Exchange Server 2016 Using Windows Server Backup is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

Q: Can I re-use the existing SSL certificate on my Exchange 2010 or 2013 servers for my new Exchange 2016 servers?

A: Yes.

There are three basic requirements of your Exchange 2016 SSL certificate:

1. The certificate must contain the names (i.e. the URLs or namespaces) that clients will be connecting to over HTTPS, for example https://mail.exchangeserverpro.net/owa for Outlook on the web
2. The SSL certificate must still be within its validity period (start and end dates)
3. The SSL certificate must be from a certificate authority that the connecting clients (Outlook, web browsers, mobile devices, etc) trust

As long as your existing SSL certificate meets those requirements then yes, you can use it.

It is also recommended to use the same SSL certificate when you are in an Exchange Server 2013 and 2016 co-existence scenario and you are load balancing client traffic across the Exchange 2013 and 2016 servers. Both Exchange Server 2013 and 2016 are capable of up-level and down-level proxying of client connections, so this is a perfectly fine configuration. And as is always recommended, all servers in a load-balanced pool should use the same SSL certificate.

To re-use your existing SSL certificate export it from Exchange 2010 or Exchange 2013 and import it to the new Exchange 2016 servers.

This article Exchange Server 2016 FAQ: Can I Re-Use My Existing SSL Certificate? is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

When an Exchange Server 2016 database has failed you may need to restore it from backup. As an example of this let’s look at a scenario where the volume on the server that hosts the database file has been lost due to a hardware failure. The server has been running backups using Windows Server Backup, so we’ll restore the lost database from the last successful backup.

In this situation we need to consider what will happen to any new or changed items in mailboxes that has been created or changed since the last backup ran. Obviously the backup itself will not contain those recent changes, however the transaction logs for the database that are stored on a separate volume are still intact. So in this case the logs can be used to roll forward the restored database up to the point in time at which the failure occurred, which should mean no data loss. However if the transaction logs were not available, for example if they were on the same volume as the database when it was lost, or because circular logging was enabled, then we would only be able to recover to the point in time at which the backup ran. That would mean accepting some data loss.

My Exchange 2016 backups have been running thanks to a scheduled job in Windows Server Backup. The last backup was successful, so that will be the one used for this recovery.

Because I don’t trust backup software to tell me the truth I also check the backup time stamp on the database itself.

[PS] C:\>Get-MailboxDatabase -Server EX2016SRV1 -Status | fl Name,LastFullBackup
Name           : DB05
LastFullBackup : 11/2/2015 2:59:37 PM

And just to reinforce the point, we can see that the mailbox for Alannah Shaw (which is hosted on the database that will be restored) had 2963 unread items and at least one new item that arrived after the backup completed. So if the restore process that includes the roll forward of transaction log files is successful, the mailbox should look the same after the restore as it did before the failure occurred.

Restoring an Exchange Server 2016 Database Using Windows Server Backup

So we’ve seen above that the backups have been running, and that new items had arrived in user mailboxes since the last backup was taken. The storage failure on the server has occurred, and we can see that the database is in a dismounted state because the database file is missing.

[PS] C:\>Get-MailboxDatabase DB05 -Status | select mounted
Mounted : False

The failed storage volume has been replaced, formatted and mounted in the same path as it was before. We can now begin the restore.

In Windows Server Backup select Recover from the Actions pane.

Select the source of the backup that will be used for recovery. In this example the backup is stored on a volume attached to the server.

Select the backup that you want to restore from.

Choose Applications as the recovery type.

Select the Exchange application. Note also that there is an option for controlling the roll-forward behaviour. In this example scenario we do want to roll forward the transaction logs and bring the database completely up to date, but if your recovery scenario involves recovering to a specific point in time, or if you have further restores to perform (such as incremental or differential backup sets) then you can check this box to prevent the roll-forward from occurring.

Because we are recovering a completely failed database we want to simply restore to the original location.

The final step is to confirm the previous selections before beginning the recovery operation.

Click Recover to begin the restore. Monitor the restore operation until it completes. If the restore is successful the database should be mounted automatically for you.

[PS] C:\>Get-MailboxDatabase DB05 -Status | select mounted
Mounted : True

The mailbox for Alannah Shaw also shows the correct number of unread items, as well as the newer item that was received after the backup had occurred, thanks to the roll-forward operation that the recovery process included.

Summary

As you can see a database restore for Exchange Server 2016 is a simple operation when Windows Server Backup is used for backups. Windows Server Backup is supported for production use, and is ideal for test labs where you just want to practice various recovery scenarios. If you use a different backup product to protect your Exchange server then the process will vary, and you should consult the documentation provided by your backup vendor.

This article Restoring Exchange Server 2016 Mailbox Databases is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

My guest for this episode is Justin Harris.

Over the past 18 years, Justin has worked with a global customer base to deliver enterprise-level messaging, unified communications, and cloud-enabled virtualization solutions. Justin is one of a handful of professionals globally who holds the Microsoft Certified Master, Microsoft Certified Solutions Master, and MVP designations with Microsoft for Exchange.

This episode of the Exchange Server Pro Podcast is brought to you by Office 365 for Exchange Professionals, the most comprehensive and up to date guide to Microsoft’s Office 365 cloud services. Find out more at Office365forExchangePros.com.

In this episode Justin and I discuss modern productivity and collaboration with Office 365 Groups.

Subscribe on iTunes, Stitcher, or RSS.

Links:

• Follow @ntexcellence on Twitter
• Justin’s blog
• Justin’s LinkedIn

This article Podcast Episode 7: Office 365 Groups with Justin Harris is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com