close

Exchange 2016

Exchange 2016

Exchange Multi-Forest Hybrid Tips and Tricks

download

Setting up Exchange hybrid between Office 365 and on-premises is a common and well-understood configuration. Chances are, you have this setup today.

But what if you have more than one Exchange forest?

Multiple forests, each with their own hybrid connection into a single Office 365 tenant, is supported from Exchange 2010 to 2019, although it does come with a unique set of challenges. This article assumes you have one Exchange organisation in hybrid and multiple Active Directory Domains synchronizing using Azure AD Connect already and are looking to add more Exchange Forests.

Office 365 tenant with two hybrid email forests

Key Considerations with Multi-Forest Exchange Hybrid

The basics still need to be in place for additional Exchange hybrid deployments. Azure Active Directory (AD) needs to successfully sync all users to the cloud (one per tenant, regardless of how many AD forests), Sender Policy Framework (SPF) and Domain-based Message Authentication. Reporting & Conformance (DMARC) also needs to be configured correctly, and the Simple Mail Transfer Protocol (SMTP), Embedded Web Server (EWS), and Autodiscover on-premises endpoints need to be exposed properly. See here for more guidance.

You should also take care to ensure that all Autodiscover endpoints work for all – internal name resolution allows connections through internal firewalls and if Service (SRV) records are in use then Outlook Autodiscover prompts are suppressed.

One thing to note is that when all your organisations are in hybrid, the on-prem user’s global address list doesn’t change to include all other Exchange organizations. There are no immediate benefits such as mailbox sharing to users sourced from foreign Exchange environments.  To get the maximum collaboration, all users need to have their mailbox in Office 365.

Existing policies in Office 365 – Data Loss Prevention (DLP), archiving, transport rules. These all require assessment, especially when integrating different geographies or companies and departments with differing cultures and languages.

Hybrid Configuration Wizard – Special Considerations

Setting subsequent Exchange organisations into Federation can be achieved by the normal Hybrid Configuration Wizard (HCW), but some specialised configuration is required – this is discussed below. Should you ever need to re-run the HCW, then the guidance below still applies, and the steps will need repeating.

Centralised Mail Routing

Centralised mail routing is Microsoft’s term for sending outgoing emails via your on-prem environment. If this is present, or you wish your newly joined Exchange forest to perform centralised mail routing, then it’s necessary to take care to avoid unexpected mail routing.

When running the Hybrid Configuration wizard against subsequent Exchange forests never select the checkbox to enable centralised mail configuration. This is because the wizard ‘helpfully’ inserts a default mail route to your new hybrid Exchange environment for all Office 365 email, which would probably be a surprise when all external email routes via it.

The simplest answer is to not have any centralised mail routing and deliver email straight from Office 365 via the implicit deliver-via-MX-resolution route. Due to compliance and existing message hygiene products in use however, this is not always possible.

Don't enable centralised mail

If you wish to achieve something like centralised mail transport for your new Exchange forest, or you already have centralised mail transport that you don’t wish the new Forest to be part of, after Hybrid Wizard has successfully completed perform the following:

  • Setup a connector to your on-premises environment (from Exchange 365 to Partner) that only fires when triggered by a transport rule
Setup a connector to on-prem
  • Setup a transport rule to ship external emails for senders from that company to the connector, unless the email is internal. If you cannot match on senders domain, consider using a group (and populating that group appropriately)

There are some exceptions. System generated email addresses will not follow the transport rule. For example, messages generated by Office Message Encryption (OME) that appear to come from the sender will not trigger that rule and still be sent via the default route, so that default route must have the ability to send email for that domain (SPF records and relay rights).

Organization Configuration Transfer

In the Hybrid Configuration wizard, there is an option to perform an ‘Organization Configuration Transfer’ which copies certain configurations like retention policies tags. Unless you have a comprehensive test environment to thoroughly test and assess the impact of meshing existing on-premises policies with existing tenant policies, it is probably safest to not select the ‘Organization Configuration Transfer checkbox and manually re-create once hybrid is complete.

Consider carefully before enabling organisation configuration transfer

Routing address

As part of the Hybrid Configuration wizard, your Exchange Address Policy generation default rule will be updated to include an Office365 routing address:

Where %m = mailbox alias

This is done by modifying the default recipient policy. The challenge with approach (mailboxalias@tennantname.mail.onmicrosoft.com), is there is no check for uniqueness outside that Exchange forest.

If you’re lucky, your mailbox aliases across different Exchange environments will not and never will clash, so there’s nothing to worry about. If there’s a chance of a clash, then action is required.

Modifying the default address generation rule with a forest-specific prefix may resolve the issue.

If you just let the Hybrid Configuration wizard run, it will likely end up with all your user accounts stamped with the default routing address, risking a clash. An approach to tackle this is to stop accounts from being updated by address book policy, run the Hybrid Configuration wizard, modify the address generation rules, then regress the address policy update.

To achieve this:

  1. Disable Accounts from being updated by recipient Policy

Get a list of all accounts that Do Have ‘Automatically update email addresses based on e-mail address policy’.

Assess the output and validate it is correct

2. Run the Hybrid Configuration wizard as normal

3. Modify the default address book policy to remove the HCW created routing address rule %m@tennantnname.mail.onmicrosoft.com and apply a new forest-specific policy, e.g. CompanyA-%m@tennnantname.mail.onmicrosoft.com

a) Take note of the current Email Address Templates:

get email address default policy

b) Update the address to include your new routing address scheme, and any other address

c) Check the new rule is in place

Check the new rule is in place example

d) Regress the setting to return mailboxes to automatically updating email addresses using the CSV generated in the previous step

Use Email address from Company A in Company B

Once Exchange organisations are hybrid-enabled into the same tenant, it is possible for a user to have an email address based from another forest in the environment. For this to operate successfully the mailbox needs to be in Office 365, and in the ‘owning’ Exchange on-premises forest, the email domain needs to be set to internal relay. In other words, when the on-prem environment cannot find the mailbox, it must send it onwards rather than non-deliver the email.

Simply add the desired email address to the ProxyAddresses field of the on-premise mailbox.

Issues to be aware of

A key issue to be aware of is if you set User Principal Name (UPN) to be their email address, this will not work, as the UPN can only be owned by one forest in a typical corporate environment with trusts. Users who chose to have their reply address as a domain owned by another forest will need to know when to enter their UPN and when to enter their email address.

There are a few other issues. Firstly, the user and email address will never appear in the on-premises environment that owns that email domain which may be confusing if you have on-prem mailboxes.

Secondly, if you have a separate message hygiene product that looks up the directory to validate email addresses, it may reject the message, as the
Simple Mail Transfer Protocol (SMTP) address will not be in the directory it is looking at.

No checking for duplicate SMTP addresses will be done either, so it will be possible now to create a duplicate SMTP address. Whilst this will not sync into Office 365, it will be confusing so a process to ensure no duplicates needs to be implemented. Using MIM or similar to create contact objects in Company B from user accounts in Company A and vice-versa may resolve these three issues.

read more
Exchange 2016Exchange Server

How to use Mail Contact object to enable outgoing SMTP relay

download (1)

Consider the following scenario – you have a need to deliver email to and from an application server that receives email via SMTP. You want to use Exchange Online Protection, the SMTP domain of the application server can send email via SMTP, however it isn’t routable or contactable via the internet, and therefore can’t receive replies to messages sent. Your organization’s email is setup in a Hybrid configuration with on-premises Exchange Server, which is configured to allow your application servers to relay email outbound via Office 365.

One way to allow your application server to receive email from the internetvia Exchange Online is by using a Mail Contact object. This will accept email to Exchange Online, and then relay the mail back to on-premises for delivery to your application server. In this post, we’ll show you how to achieve this, and how to resolve common issues you might encounter.

Example configuration of SMTP relay

In our example scenario, we’ve got an application server sending messages as Application.Mailbox. It has two different email addresses – the internal address used within the application server, and the address defined within Office 365.

In this example, our Office 365 email address is: Application.Mailbox@wordfish.co.uk

The internal application server email address is: Application.Mailbox@resdomain.local

Contact Object
Contact Object

So that the Office 365 email address can be used to relay mail back to the on-premises application server, the non-routable email domain needs a specific connector configured to route messages to the application server’s specific on-premises domain.

It’s important to note that you could instead add the domain to the hybrid connector, but we don’t recommend this. This is because if you re-run the Hybrid Configuration Wizard, which you may need to do periodically, the domain will be removed from the connector created and managed by the hybrid wizard.

The other key component of allowing email to route from Office 365 back to on-premises is ensuring that the on-premises environment is able to send the email to the application server, as shown below:

Routing Email Externally

In a configuration like this, we’ll also expect that because the application server needs to send SMTP messages, the on-premises Exchange environment can be used for relay via the Hybrid configuration, as shown below:

Routing Email Externally

After implementing this configuration, email can be sent and received from the application server. And all may appear well, initially…

Some emails are reported as spam or not delivered

After time, one common issue that may be reported is that there are mail delivery issues with some mail servers on the internet.

Generally, you will check that records, like your SPF records are set up correctly. You check and find that SPF is setup correctly and you are not on any bad reputation lists. Email delivery in general is fine.

However, sending a test email via the Application server and analysing the headers shows some interesting results.

Send Test Email

After sending a test message to replicate the issue, open the message headers in a client like Outlook. You can then copy and paste the headers into the Microsoft Message Header Analyser.

This is a useful tool, as it helps you easily examine the properties contained in the message headers and quickly identify the offending issue. In the example below, we’ve highlighted what appears to be the underlying issue:

Return Path

You’ll see above that we can see in the Return-Path, the envelope ‘from’ address, is set to the internal resdomain.local domain.

While this is valid on the internet, many receiving mail servers will consider an invalid Return-Path domain enough of a reason to mark the message as spam, or completely reject the message.

As this example is a lab environment, it is possible to easily reconfigure the network and Office 365 so that messages can be relayed directly from the application server. We’ll change the configuration for testing purposes to the configuration shown below:

Direct Test

Upon making the configuration changes, we’ll re-perform the SMTP relay test, as shown below:

Direct Test

After the message is received, we’ll follow the same investigation process as before and examine the message headers once the email has been successfully received. Routing directly, rather than via Exchange Hybrid shows that this time the Return-Path is as expected:

Proper Return Path

So, what’s going on?

Conclusion

Look at the unusual capitalisation of the Return-path in the first example and note that it’s exactly the same as the emboldened address in the Mail Contact object (the reply address):

SMTP Bad Default Reply to Address

Exchange on-premises is receiving the email then using the Mail Contact object as the envelope-from address when relaying it through to Office 365. It is not changing the reply address seen by the user, so at first glance everything behaves as expected.

Although Office 365 has the same Mail Contact object, the behaviour is not the same. Exchange Online is not changing the envelope address.

You could consider relaying all your application servers through Office 365 and Exchange Online directly. However this configuration isn’t suitable for many organizations, because it requires extensive firewall changes including allowing application servers to directly communicate over the internet.

Instead, we’ll choose to correct this by updating our application servers’ contact object within the Exchange on-premises environment. You’ll find the most straight-forward fix here is to set the correct address as the reply-to address in the Mail Contact, as shown in the example below:

SMTP fixed reply to address
read more
Exchange 2016

Unleash the “Hidden Magic” in the Exchange Server Role Requirements Calculator

image1

Every Exchange project should use the Exchange Server Role Requirements Calculator. The calculator helps us estimate the hardware requirements for new Exchange Server environments. All it needs is some input about your design requirements, along with the user messaging profiles.

Microsoft updates the Exchange Server Role Requirements Calculator regularly. Before you start designing a new environment, make sure to download the newest version available. You can see the changes in each version on the release notes page. At the time of this writing, the latest version is 9.1.

As you can see in the screenshot above, the calculator is an Excel spreadsheet with several tabs. You fill out the Input tab and the calculator does the rest for us.

The purpose of the calculator is to give us an accurate view of the hardware requirements of the Exchange Server design. But what many people don’t realize is that also provides us with deployment scripts. This is what I refer to as the secret magic of the calculator.

The Deployment Scripts

The deployment scripts generated by the Exchange Server Role Requirements Calculator provide us with several benefits:

  • Speeds up the deployment of the Exchange servers and DAG
  • Provides documentation of the steps taken during the DAG implementation
  • Makes sure you don’t miss some of the vital configuration steps during DAG setup
  • Makes for a reusable process if you work as a consultant in different environments

This is a great tool for you to take advantage of. The days of logging on to each server and manually making configuration changes are over. Instead, we should be scripting deployments so that we achieve predictable outcomes.

So, where do we find these deployment scripts? Well, they’re hiding out on the tab in the calculator named Distribution.

As you can see we have five buttons:

  • Export DB Mount List – creates the Servers.csv file.
  • Export DAG List – creates the DAGInfo.csv file.
  • Export Primary DB List – Creates the MailboxDatabases.csv file.
  • Export Copy DB List – Creates the MailboxDatabaseCopies.csv file.
  • Export Role Calculator Scripts – Generates the PowerShell scripts for deploying the Exchange servers and DAG.

The first four buttons on the Distribution tab generate custom CSV formatted input files. We use these files together with the bundled deployment scripts. The custom CSV files are based the data you entered in the Input tab of the calculator. They also display a pop-up dialog for some extra information.

The last button, Export Role Calculator Script, creates the following script files:

  • DiskPart.ps1 – uses the Servers.csv file for input. This script brings the data disks of the Exchange Server online, formats them, and mounts the volumes. The script will align with the recommendations of the Exchange Preferred Architecture for the volume mount points.
  • CreateDAG.ps1 – uses the DAGinfo.csv file for input. This script creates the Database Availability Group and configures relevant settings such as the File Share Witness, and the number of database copies per volume.
  • CreateMBDatabases.ps1 – uses the MailboxDatabases.csv file for input. This script creates the active databases, specifies the folder paths, and configures settings such as default mailbox quotas.
  • CreateMBDatabaseCopies.ps1 – uses the MailboxDatabaseCopies.csv file for input. This script creates the mailbox database copies, and also configures any lagged database copies.

Providing Naming Information

Before generating the script input files, you should review and edit the Role Requirements Input Factors – Database Availability Group Configuration, found on the Input tab of the calculator. Here we define the server names, DAG name and mailbox database naming prefix.

In the example below, I’m using server names of JN-MBX-1 and JN-MBX-2. Don’t worry about changing all the server names in the list. The CSV file will only use of the same number of names as you set in the Number of Mailbox Servers Hosting Active Mailboxes / DAG field of the Input tab.

Additionally, I want my DAG to be named JN-DAG-1 and the prefix for my Databases set to JN-MDB.

Generating the Script Input Files

Now we can proceed with creating the CSV files to use as input for the deployment scripts. Start by clicking the Export DB Mount List button on the Distribution tab. The following dialog box will appear, prompting for information about where to save the CSV file. It will also ask you if you want to use a different volume/database root and file system format than the recommended values.

It’s very important to specify the correct First DAG Drive. This is the drive from where the scripts start to initiate actions such as formatting disks. You can retrieve the correct disk number by running Diskpart.exe from a command prompt on the server, and then the List Disk command.

Next, click the Export DAG List button. This dialog box is a bit more detailed and requires information about your global catalogs and file share witness server. You’ll notice there are also a series of configuration choices for the DAG itself. Ideally you have already made those design decisions before you get to this stage of your project. If not, you can use the defaults provided, but I do recommend you research each of them so that you understand what they mean.

Next, we can generate the CSV file for the mailbox databases by clicking on the Export Primary Database List button. Again, the input that you provide in this dialog will depend on your design decisions for the environment you’re deploying. The default values align with Microsoft’s recommendations in the Preferred Architecture. As with the DAG configuration, you should research those options to make sure you understand the implications of each of them.

Finally, click on the Export Copy DB List button to create the input file for the mailbox database copies script. For that script, there is only the need to specify the export path for the input file MailboxDatabaseCopies.csv. The script that configures the database copies also uses information in the MailboxDatabases.csv file.

Using the Exchange Deployment Scripts

The deployment scripts themselves are generated by clicking the last button, Export Role Calculator Scripts. You can open each script in the PowerShell ISE or your favorite PowerShell code editor to see help information and instructions for running the scripts.

Before using the scripts generated by the Exchange Server Role Requirements Calculator, we need to have Exchange Server installed onto the servers, and the storage disks present and ready for formatting and mounting.

The deployment scripts are run in the following order:

  • DiskPart.ps1 to configure the storage volumes.
  • CreateDAG.ps1 to create the database availability group and add your Exchange servers as DAG members.
  • CreateMBDatabases.ps1 to create and configure the mailbox databases.
  • CreateMBDatabaseCopies.ps1 – to add copies of the mailbox databases on other DAG members, and configure any lagged copies.

Although this may all seem like more work than just manually installing and configuring your DAG, by investing the time up front you will avoid human errors during the configuration. Also, you now have a repeatable process for sizing and deploying Exchange servers. And if you save the calculator, CSV files, and scripts, you will also have a basis for the documentation of the newly deployed Exchange servers and DAG.

read more
Exchange 2016

June 2018 Updates Released for Exchange Server

image1

Microsoft has released the latest quarterly updated for Exchange Server 2016 and 2013, as well as an update rollup for Exchange 2010.

Some notes to be aware of:

  • Exchange 2016 CU10 and Exchange 2013 CU21 require .NET Framework 4.7.1 be installed on the server before you install the CU. This requirement was called out as far back as September 2017. If you have a scenario where you can’t see a path to upgrade .NET and Exchange while staying within supported combinations of the two, refer to this article for guidance.
  • The VC++ 2013 runtime is also a pre-requisite for the updates released this month to “provide current and future security updates for a third party component shipped with Exchange Server. The component provides WebReady Document Viewing in Exchange Server 2010 and 2013 and Data Loss Prevention in Exchange Server 2013 and 2016.”
  • Also included in these updates is a critical security patch for the Oracle Outside In libraries, which provide “WebReady Document Viewing in Exchange Server 2010 and 2013 and Data Loss Prevention in Exchange Server 2013 and 2016.” The update is described in MSRC advisory ADV180010. Microsoft has not allocated a severity rating to their advisory (currently it says “None”), but Oracle refers to it as a critical update in their advisory in April. It’s unclear whether that is due to previous critical vulnerabilities patched in the code, or new ones disclosed in April.

Microsoft’s normal practice is to release security updates separately to cumulative updates. In other words, a security update for a supported version of Exchange should always be available as a standalone update, and not require you to install an entire CU to receive the security update. This quarter they have not done that. The security update included in these quarterly updates is not available separately. Microsoft’s statement on this matter is:

The Exchange team has previously stated they will not ship security fixes in a cumulative update not previously released separate from a cumulative update. That goal and official plan of record are unchanged. Shipping the updated third party components in a cumulative update was necessary to integrate a new version of the components and a new product dependency not previously required by Exchange in a manner customers are accustomed to with minimal disruption to the Windows Update process.

New Exchange 2016 and 2013 Cmdlets for Creating and Modifying Remote Shared Mailboxes

A long standing issue with managing shared mailboxes in hybrid environments has been the inability to manage shared mailboxes in Exchange Online by running on-premises Exchange cmdlets. For user mailboxes, the New-RemoteMailbox, Enable-RemoteMailbox, and Set-RemoteMailbox cmdlets can be used. But for shared mailboxes it was necessary to create the shared mailbox on-premises first, then migrate it to Exchange Online. Or alternatively, create the remote mailbox as a user mailbox in Exchange Online, and then convert it to a shared mailbox.

Quietly mentioned in the release notes for the cumulative updates released this quarter are updates to the *-RemoteMailbox cmdlets to add a -Shared parameter, enabling the management of remote shared mailboxes from the on-premises Exchange management shell.

To receive this update you must ensure that you prepare your Active Directory using the setup.exe file in Exchange 2016 CU10 or Exchange 2013 CU21.

If you do not manually prepare AD then setup might not do the preparation automatically for you. This depends on which previous version of Exchange you’re updating from. The safest approach is to manually prepare AD yourself to ensure that it is done.

Exchange Server 2013 Extended Support

Microsoft has included a note in this release that Exchange Server 2013 is now in the extended support phase of its lifecycle. Cumulative Update 21 is the last planned CU for Exchange Server 2013, so you must update to CU21 to continue to receive security updates, and for support in hybrid environments. Microsoft may at their discretion release future CUs if required for security or hybrid compatibility reasons.

Exchange Server 2010 Updates

Exchange 2010 SP3 UR22 adds support for Windows Server 2016 domain controllers. Prior to this update it was necessary to include pre-2016 domain controllers in AD sites where Exchange 2010 is running.

There are no restrictions to adding Windows Server 2016 domain controllers in forests where Exchange Server 2010 is deployed. Support for Active Directory Forest Functional Levels through Windows Server 2016 is included. Domain Controllers must be running Windows Server 2016 updates released through June 2018 to be supported. Customers are encouraged to remain current by applying monthly operating system quality updates.

UR22 also fixes an Exchange Web Services (EWS) impersonation issue for 2010/2016 co-existence environments.

Additional Information

read more
Exchange 2016

New Pluralsight Course – Designing & Deploying Exchange 2016 (70-345) Hybrid and Migration

download

The final course in my series with Pluralsight for the Exchange 2016 certification exam (70-345) is now available. This course covers the “Implement and manage coexistence, hybrid scenarios, migration, and federation” portion of the exam.

In this course you’ll learn about configuring federation, organization relationships, and sharing policies for various free/busy and calendar sharing scenarios between separate organizations. You’ll also learn about creating a hybrid configuration with Office 365, and how to migrate from legacy versions of Exchange.

The course runs for about 2.5 hours, and includes:

  • Module 1 – Course introduction
  • Module 2 – Exchange Federation
  • Module 3 – Coexistence with Office 365
  • Module 4 – Troubleshooting Coexistence with Office 365
  • Module 5 – Migrating from Earlier Versions of Exchange Server
  • Module 6 – Troubleshooting Migrations and Coexistence

If you’re an existing Pluralsight subscriber you can access the course now.

If you’re not already a Pluralsight subscriber, sign up for a free trial to watch this course and others. It’s a great investment for professional training that will help you in your career.

read more
Exchange 2016

Changing the OWA Reply All Default Setting to Reply

reply-all-default-01

One of Microsoft’s interesting design decisions with Outlook on the web (OWA) for Exchange is the default setting of “Reply all” for replying to email messages.

As any seasoned email admin will tell you, careless use of “Reply all” has the potential to take down entire Exchange servers. And even though there are methods we can use to prevent such an incident, it would be preferable to take all possible steps to reduce the change of an accidental reply all storm breaking out. When I questioned this decision some time ago, I was told by some Microsoft employees that the default is probably a reflection of the email-heavy culture within Microsoft where there is a lot of “Reply all” usage during discussions. These days we have alternatives to email, like Microsoft Teams, Skype for Business group IM, or even Slack if you prefer, where those types of group discussions can take place instead of email. But old habits die hard.

For admins who want to do something about the “Reply all” default, there are solutions. End users can configure the setting themselves in their OWA options, but that depends on the end user actually doing it, which tends to be an unreliable way to implement any large scale change.

For Exchange 2016 and Exchange Online there is a PowerShell solution we can use instead. The Set-MailboxMessageConfiguration cmdlet has an option to configure IsReplyAllTheDefaultResponse to either True or False.

The change will take effect for the next time they refresh their OWA session, or the next time they login.

If you prefer that the IsReplyAllTheDefaultResponse option be set to False for all mailbox users, that’s something you can add to your provisioning scripts so that new mailboxes also receive the configuration change.

read more
Exchange 2016

Unleash the “Hidden Magic” in the Exchange Server Role Requirements Calculator

calculator_intro

Every Exchange project should use the Exchange Server Role Requirements Calculator. The calculator helps us estimate the hardware requirements for new Exchange Server environments. All it needs is some input about your design requirements, along with the user messaging profiles.

Microsoft updates the Exchange Server Role Requirements Calculator regularly. Before you start designing a new environment, make sure to download the newest version available. You can see the changes in each version on the release notes page. At the time of this writing, the latest version is 9.1.

As you can see in the screenshot above, the calculator is an Excel spreadsheet with several tabs. You fill out the Input tab and the calculator does the rest for us.

The purpose of the calculator is to give us an accurate view of the hardware requirements of the Exchange Server design. But what many people don’t realize is that also provides us with deployment scripts. This is what I refer to as the secret magic of the calculator.

The Deployment Scripts

The deployment scripts generated by the Exchange Server Role Requirements Calculator provide us with several benefits:

  • Speeds up the deployment of the Exchange servers and DAG
  • Provides documentation of the steps taken during the DAG implementation
  • Makes sure you don’t miss some of the vital configuration steps during DAG setup
  • Makes for a reusable process if you work as a consultant in different environments

This is a great tool for you to take advantage of. The days of logging on to each server and manually making configuration changes are over. Instead, we should be scripting deployments so that we achieve predictable outcomes.

So, where do we find these deployment scripts? Well, they’re hiding out on the tab in the calculator named Distribution.

As you can see we have five buttons:

  • Export DB Mount List – creates the Servers.csv file.
  • Export DAG List – creates the DAGInfo.csv file.
  • Export Primary DB List – Creates the MailboxDatabases.csv file.
  • Export Copy DB List – Creates the MailboxDatabaseCopies.csv file.
  • Export Role Calculator Scripts – Generates the PowerShell scripts for deploying the Exchange servers and DAG.

The first four buttons on the Distribution tab generate custom CSV formatted input files. We use these files together with the bundled deployment scripts. The custom CSV files are based the data you entered in the Input tab of the calculator. They also display a pop-up dialog for some extra information.

The last button, Export Role Calculator Script, creates the following script files:

  • DiskPart.ps1 – uses the Servers.csv file for input. This script brings the data disks of the Exchange Server online, formats them, and mounts the volumes. The script will align with the recommendations of the Exchange Preferred Architecture for the volume mount points.
  • CreateDAG.ps1 – uses the DAGinfo.csv file for input. This script creates the Database Availability Group and configures relevant settings such as the File Share Witness, and the number of database copies per volume.
  • CreateMBDatabases.ps1 – uses the MailboxDatabases.csv file for input. This script creates the active databases, specifies the folder paths, and configures settings such as default mailbox quotas.
  • CreateMBDatabaseCopies.ps1 – uses the MailboxDatabaseCopies.csv file for input. This script creates the mailbox database copies, and also configures any lagged database copies.

Providing Naming Information

Before generating the script input files, you should review and edit the Role Requirements Input Factors – Database Availability Group Configuration, found on the Input tab of the calculator. Here we define the server names, DAG name and mailbox database naming prefix.

In the example below, I’m using server names of JN-MBX-1 and JN-MBX-2. Don’t worry about changing all the server names in the list. The CSV file will only use of the same number of names as you set in the Number of Mailbox Servers Hosting Active Mailboxes / DAG field of the Input tab.

Additionally, I want my DAG to be named JN-DAG-1 and the prefix for my Databases set to JN-MDB.

Generating the Script Input Files

Now we can proceed with creating the CSV files to use as input for the deployment scripts. Start by clicking the Export DB Mount List button on the Distribution tab. The following dialog box will appear, prompting for information about where to save the CSV file. It will also ask you if you want to use a different volume/database root and file system format than the recommended values.

It’s very important to specify the correct First DAG Drive. This is the drive from where the scripts start to initiate actions such as formatting disks. You can retrieve the correct disk number by running Diskpart.exe from a command prompt on the server, and then the List Disk command.

Next, click the Export DAG List button. This dialog box is a bit more detailed and requires information about your global catalogs and file share witness server. You’ll notice there are also a series of configuration choices for the DAG itself. Ideally you have already made those design decisions before you get to this stage of your project. If not, you can use the defaults provided, but I do recommend you research each of them so that you understand what they mean.

Next, we can generate the CSV file for the mailbox databases by clicking on the Export Primary Database List button. Again, the input that you provide in this dialog will depend on your design decisions for the environment you’re deploying. The default values align with Microsoft’s recommendations in the Preferred Architecture. As with the DAG configuration, you should research those options to make sure you understand the implications of each of them.

Finally, click on the Export Copy DB List button to create the input file for the mailbox database copies script. For that script, there is only the need to specify the export path for the input file MailboxDatabaseCopies.csv. The script that configures the database copies also uses information in the MailboxDatabases.csv file.

Using the Exchange Deployment Scripts

The deployment scripts themselves are generated by clicking the last button, Export Role Calculator Scripts. You can open each script in the PowerShell ISE or your favorite PowerShell code editor to see help information and instructions for running the scripts.

Before using the scripts generated by the Exchange Server Role Requirements Calculator, we need to have Exchange Server installed onto the servers, and the storage disks present and ready for formatting and mounting.

The deployment scripts are run in the following order:

  • DiskPart.ps1 to configure the storage volumes.
  • CreateDAG.ps1 to create the database availability group and add your Exchange servers as DAG members.
  • CreateMBDatabases.ps1 to create and configure the mailbox databases.
  • CreateMBDatabaseCopies.ps1 – to add copies of the mailbox databases on other DAG members, and configure any lagged copies.

Although this may all seem like more work than just manually installing and configuring your DAG, by investing the time up front you will avoid human errors during the configuration. Also, you now have a repeatable process for sizing and deploying Exchange servers. And if you save the calculator, CSV files, and scripts, you will also have a basis for the documentation of the newly deployed Exchange servers and DAG.

read more
Exchange 2016

March 2018 Updates Released for Exchange Server

Exchange-2016-CU10-Setup

Microsoft has released the latest quarterly updated for Exchange Server 2016 and 2013, as well as an update rollup for Exchange 2010.

The Exchange 2016 and 2013 cumulative updates include the following changes and improvements:

  • Full support for TLS 1.2 on supported Exchange versions (i.e. not older CU’s that are already out of support). Refer to the further guidance here.

Microsoft also reminds customers to upgrade to .NET Framework 4.7.1 before the June 2018 quarterly release:

Reminder that customers should be in the process of moving to .NET Framework 4.7.1. .NET Framework 4.7.1 will be required on Exchange Server 2013 and 2016 installations starting with our June 2018 quarterly releases. Customers should plan to upgrade to .NET Framework 4.7.1 after applying March 2018 quarterly release to avoid blocking installation of the June 2018 quarterly releases for Exchange Server 2013 and 2016.

Additional Information

read more
1 2 3
Page 1 of 3