Exchange

In this article, we explore applying the Exchange product key. We will illustrate this process through both the Exchange Admin Center (EAC) and PowerShell. We will also look at how to license multiple servers at once and how to locate all unlicensed servers in your environment. This process is the same for both Exchange 2013 and 2016.

Apply the product key with Exchange Admin Center

To apply the product key through the Exchange Admin Center follow these steps.

Log into the Exchange Admin Center (EAC). Navigate to the Servers tab and then the Servers sub-tab at the top.

Select the server you wish to apply the key and click the Edit () button.

From the General tab enter your 25-character product key into the 5 boxes under Enter a valid product key section.

UPDATED: 1/19/2023

Before you install a new version of Exchange, you will need to perform a number of tasks in Active Directory. This is true for both migrating an older version of Exchange, or, installing into a greenfield that has had no prior iteration of Exchange. This will involve the following tasks.

1. Extend the schema
2. Prepare the organization
3. Prepare the domains

Setup will perform these steps during its main installation if it determines they have not been run. So, you may wonder why you would ever perform these steps manually.

One possibility is that a company operates in a split-permissions model. In large organizations, two separate teams may manage Active Directory and Exchange. If least privilege is in place, it is likely that the Exchange team cannot perform elevated Active Directory tasks such as schema extensions. Similarly, the Active Directory team may not have permission to manage Exchange. In this case, the Active Directory team will need to run the commands manually before the main setup.

Another possibility is that a company may have a large geographically dispersed network with multiple Active Directory sites. It could have its schema master in one site and its Exchange servers in a totally different site. The links between these sites could have any number of restrictions upon them, such as a long interval between replication cycles. In that case, the company will need to run the command manually in the site hosting the schema master and allow time for replication.

This article illustrates how to perform these tasks from a command line.

Tip: These same instructions work for Exchange 2010, 2013, 2016, and 2019 installations. In addition, these tasks often have to be repeated when performing cumulative updates. For more information on whether your cumulative update requires these commands, be sure to check official Microsoft documentation.

Extending the Schema

To do this, we must first open an elevated command prompt. We need to do this from a machine running a 64-bit version of Windows. The minimum version of Windows required is dictated by the Exchange Supportability Matrix. This machine must also be in the same site and domain as the schema master. The computer we execute this from does not have to be a domain controller. For smaller companies with a single-domain/single-site environment, we can simply run these commands from the intended Exchange server.

Tip: To perform this update, you must be a member of both the Enterprise and Schema admin groups.

Change to the directory containing your Exchange setup files and issue the following command. Be sure to include the license agreement switch.

Tip: Starting with Exchange 2016 CU22 and Exchange 2019 CU11, Microsoft replaced the /IAcceptExchangeServerLicenseTerms parameter with the option to send diagnostic data to Microsoft. To send the optional data, use the /IAcceptExchangeServerLicenseTerms_DiagnosticDataON parameter. If you do not wish to send any data, use /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF. Note that this can be changed post-installation using the Set-ExchangeServer cmdlet.

C:\Ex2016Setup> Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms_DiagnosticDataON

After several minutes the command will complete. You should see an output similar to the following.

In most situations adding a second email domain, is simply just a matter of configuring the necessary mail flow. However, in situations such as an acquisition or merger, you may need users to configure Outlook with an email domain that is different from the one configured in your autodiscover URI. This is especially true for companies that offer hosted Exchange in a multi-tenancy business model. 

In this article, we take a look at a couple of case studies where an SRV record might be preferred over adding additional names to a certificate. We then explore how to configure an SRV record in a popular DNS management system. Finally, we look at two different ways to test that SRV record.

Tip: Not all ActiveSync devices support SRV records (some don’t support Autodiscover at all). In these cases you may need to manually configure each device with the server name, or, look into a different autodiscover method.

Case Study 1: Acquisitions and Divestiture

One solution is to simply add each domain to your UC / SAN certificate (also called a multi-domain certificate). This may seem like a quick and easy solution but it all depends on volume. Re-keying your certificate for a one-time acquisition or merger may seem like a minute task. But consider a company that frequently acquires or divests other companies. You may find yourself re-keying that certificate every couple of months. This may still seem trivial but consider the size of your environment. If you have a large Exchange deployment with dozens of servers and multiple load balancers then each will need the new certificate every time it is re-keyed. This pales in comparison to the single SRV record that can be easily added to the new domain. It not only saves you time but also money. Adding each domain may incur additional charges. Some certificate providers even charge a fee for re-keying a certificate.

Case Study 2: Multi-tenant hosted Exchange providers

With a hosted Exchange provider the acquisition and departure of clients are likely to be even more volatile. That said, you don’t want to be re-keying your certificate every time you onboard or off-board a client. Adding each domain to your certificate will eventually become cost-prohibitive affecting your bottom line. Like any business your bottom line is important. So choosing the SRV redirect method over a cost-prohibitive multi-domain certificate is more attractive (and also simpler to configure).

Scenario

For the purposes of this article ExchangeServerGeek has recently acquired SuperTekBoy. STB users have an email address of SuperTekBoy.com. Whereas ESG users have an email address of ExchangeServerGeek.com. Mail data from STB has already been migrated to the ESG. The company requires STB users to keep using their SuperTekBoy.com email addresses to configure their Outlook profiles. The company does not want to make any changes to its current SSL certificate as this will incur additional fees. The Exchange administrator determines the best solution is to configure an SRV record.