close

Exchange 2016

Exchange 2016Exchange Server

Why can’t you remove the last Exchange Server?

GENERIC-Exchange-Online-An-admin-managing-it-LOW-300×162

So, you’ve completed your migration to Exchange Online. Email flows smoothly into and out of the cloud, and all your mailboxes are now online. What’s next for your Exchange Servers, now that you’ve made the transition?

After completion you will have several tasks to perform to remove Exchange Servers from your environment, but there is one important caveat you need to know about; if you run Azure AD Connect then you can’t remove every Exchange Server from your environment. You will need to keep at least one around for management purposes. In this article, I’ll walk through what you can do to minimize what you keep and need to maintain, and what you can consider planning for in the future. You can also join me at TEC this week, on September 2nd.

If you run Azure AD Connect, you need Exchange for recipient management

At the time of writing (August 2021), Microsoft still haven’t removed the need to keep at least one Exchange Server around after migrating to Exchange Online – if you plan to still run Hybrid Identity.

This is because when you run Hybrid Identity, your on-premises Active Directory Forest and Domains remain the source of truth for objects that are synchronized to Azure Active Directory (Azure AD). Azure AD is the directory that Microsoft 365, including Exchange Online uses, and almost all attributes that are synced from your local AD are read-only in Azure AD and must be set and edited locally.

That means that when you create a new user account, you must create the user account in your local Active Directory. After creating the new user account, Azure AD Connect will run a synchronization job and see a new user account, and then create a new synced account in Azure AD. The new Azure AD account will be linked back to that account and if it’s missing vital attributes, you won’t be able to use the online tools, like the Exchange Admin Center, to fill in missing values or update values.

Your local Active Directory management tools aren’t designed to manage Exchange attributes, and whilst you can technically set Exchange-specific attributes using Active Directory Users and Computers (via the attribute editor), ADSIEdit.msc or by using PowerShell scripting, Microsoft do not support manually editing the attributes. Microsoft clearly state that you must use an Exchange Server, if you want the option of phoning up Microsoft for support:

The question of whether a third-party management tool or ADSIEDIT can be used is often asked. The answer is you can use them, but they are not supported. The Exchange Management Console, the Exchange admin center (EAC), and the Exchange Management Shell are the only supported tools that are available to manage Exchange recipients and objects. If you decide to use third-party management tools, it would be at your own risk. Third-party management tools often work fine, but Microsoft does not validate these tools.
From https://docs.microsoft.com/en-us/exchange/decommission-on-premises-exchange

There are good reasons why Microsoft have made this statement. Firstly, Microsoft have committed to providing a solution for removing the last Exchange Server from your environment, but as it’s a reasonably complex problem that needs to account for the needs of small, medium and large organizations, then providing a one-size fits all solution will be difficult. Solutions like cutting off the sync of Exchange attributes have been suggested in the community, but would result in stale and out of date data in AD; complex solutions for write-back or co-ordinated changes aren’t practical in many enterprise environments that are regulated, nor are suitable for smaller customers. And simply providing a set of PowerShell scripts to replace Exchange Management tools could work for some organizations, but would be too complex for smaller organizations to manage.

If you do choose to go it alone and remove the last Exchange Server there is another risk; that when Microsoft do provide a solution, whatever you’ve done yourself will break. This is because Microsoft have suggested the solution might require an update before removal can take place:

When we have a solution available to allow any management-only servers to be removed, it may require an update to Exchange Server 2016, and in that case we may release a future CU or patch. Currently there is no plan to release future updates for Exchange 2016, but we want to assure our customers that if we need to do this to support the removal of these ‘management only’ servers, we will.
From https://techcommunity.microsoft.com/t5/exchange-team-blog/exchange-server-2016-and-the-end-of-mainstream-support/ba-p/1574110

Finally, it’s reasonably rare to find either a third-party tool or scripts that a consultant or IT administrator have provided that sufficiently cover the same functionality as the Exchange Admin Center or Exchange Management Shell. Remember that the configuration stored and used within the local Active Directory includes several areas directly related to ongoing recipient management in Exchange Online:

  • Remote Mailbox management for users, shared mailboxes and archives (i.e. management of the AD attributes linked to your mailboxes in Exchange Online)
  • Mail User management
  • Mail Contact management
  • Mail-Enabled Security Group management
  • Distribution Group management
  • Accepted Domain and Remote Domain management
  • Email Address Policy management and updates
  • Autodiscover Service Connection Point management

Even when I’ve seen reasonably comprehensive scripts aimed at managing this, these don’t always provide the same validation functionality that the Exchange tooling does; for example – ensuring address uniqueness and RFC compliance when altering proxy addresses and the primary email address, or following the same logic when applying changes to Email Address Policies. Because scripts or tools are acting directly against Active Directory (which has little knowledge of Exchange) you can create scripts that make changes that would not be valid if performed through the Exchange tooling.

As Microsoft state – it is possible to examine everything Exchange does with regards to recipient management, but it is at your own risk. However as time goes on, and the risk of running Exchange on-premises appears to increase – there may be a time when the Microsoft 365 community of IT pros (and Microsoft MVPs like myself) weigh up the risks collectively and provide a solution. Right now though it’s not yet the time.

If you relay SMTP email on behalf of legacy application servers

The best thing you can do is upgrade line-of-business applications to their respective vendors’ SaaS equivalents or at the very least, upgrade to versions that have native support for Microsoft 365 and Exchange Online. There should be no vendor worthy of respect that appears to be confused by a request to configure their software so that it can send email directly using Exchange Online.

Such applications should not need to use an on-premises mail server to relay outbound mail to or through Exchange Online in 2021; Exchange Online has been around for ten years. And those vendors should not be shocked or confused that simply using authenticated SMTP with Exchange Online won’t be enough either; Microsoft announced in September 2019 (almost three years ago) that legacy authentications will no longer be supported in due time, and announced support for OAuth 2.0 with SMTP around 18 months ago. A vendor that has asked it’s development team to spend an hour looking into what they should do will have fast arrived at the conclusion that they should use Microsoft Graph to submit email messages, and build their integration in a way that doesn’t require a username and password to be stored and works seamlessly in environments that leverage Conditional Access policies and Multi-Factor Authentication. If your vendor claims they haven’t been asked if their application can work properly with Microsoft 365, then you should be suspicious, unless you are their only customer.

Unfortunately, getting on a call and grandstanding with the vendor won’t solve the fact they’ve done little except collect recurring revenue from you to support their solution. And if, like many organizations, you run tens of applications like this or have in-house bespoke applications relied upon that were created by developers who’ve long since left the business, you might find yourself in a difficult position.

That position is often one where you need to be able to accept unauthenticated, insecure SMTP messages and relay them either outbound through Exchange Online to your customers or to employee mailboxes. In that case, then the simplest option often is to continue to run several Exchange Servers, utilizing a copy of your existing relay receive connectors. As you’ve read above, you need the servers for ongoing management – so it often makes sense.

Recommendations for the “last Exchange Server”

Assuming you aren’t moving to cloud-only identities and removing Active Directory today (which some organizations are) then you are keeping Exchange running on premises. What this needs to be depends somewhat on your organization, but should be guided by several principles:

  • The server(s) required to run Exchange Hybrid functionality for management and SMTP relay purposes is unlikely to be the same specification you needed to host Mailboxes on, and can be a lower specification.
  • The server(s) are typically is suited to run as a Virtual Machine on-premises or in a cloud provider, so long as core requirements for access to Active Directory are met with no firewall rules in-between.
  • You only need to run Exchange Server 2016 on these servers. There is no benefit today in running Exchange Server 2019, except for the ability to run on Server Core and support in-place operating system upgrades, and the free Hybrid license is only available for Exchange 2016 and below.
  • The specifications for the last Exchange Server can be lower than normal Exchange Servers. The minimum requirements for Exchange Server are not typically sufficient, but 2 to 4 virtual CPUs and 12GB RAM, with a minimum of 100GB of disk space often work well as a starting specification. If you expect significant SMTP relay traffic, then you should size the servers appropriately to ensure mail queue database size and logs are meet your requirements, and ensure you have sufficient disk space to keep extended logs for security investigation purposes.
  • You should not need to expose HTTPS services to the internet, now you’ve migrated all mailboxes (and public folders) to Exchange Online. You will first move your Autodiscover records to point directly at Exchange Online, and set your Service Connection Point to $null; no clients should be accessing these servers.
  • If you are relaying SMTP mail outbound only and not receiving mail back to on-premises or running centralized transport, then you should not need firewall rules to allow SMTP mail to be received inbound to these servers.
  • You may choose to restrict HTTPS and other connectivity on your internal network to the Exchange Servers, now that no internal clients require access to Exchange On-Premises. If you need more than one Exchange Server to provide HA for SMTP relay, Load Balancing functionality will only be relevant for SMTP relay and not for HTTPS, as HTTPS access will only be used for IT administrator access from secured clients.
  • Don’t run the Exchange Mailbox role on a server running other related services, such as on an Active Directory Domain Controller or Azure AD Connect server.
  • You must keep the Exchange Servers up-to-date. This needs to be the latest update, or immediately previous update (i.e. you remain supported for the small duration of time, such as a week, that it takes to agree the change to perform the updates); furthermore you absolutely must apply security updates as soon as you can after they are released. Do this whether or not the servers are published to the internet; it is common for a low-privilege account to be compromised and this account used to explore your network to find opportunities to gain escalated privileges.
  • Ensure logging capabilities on the servers are set so that you keep enough security and access logs so that you can investigate a security incident, should Exchange be subject to a zero-day threat again. If you have the capability, ensure logs are consumed by your SOC or SOC service and analyzed in real-time for threats.
  • Ensure you are installing EPP and EDR software. Exchange admins have questioned in the past the validity of running Anti-Virus software on Exchange Servers because AV software can attempt to scan database files and cause issues. This only happens if you don’t specify the correct exclusions. EDR (Endpoint Detection and Response) software, like Defender for Endpoint has specific capabilities and recommendations for Exchange too, so if you have purchased these products, use them.

A future without Exchange Servers on-premises

However, as Microsoft do say they will have a solution coming for removing the last Exchange Server – and that, given Exchange has become a cybersecurity target – you might actually want to restrict access to Exchange Servers or potentially even switch them off when they aren’t being used for management. So if you need SMTP relay for legacy applications, multi-function copiers and don’t want to poke a bunch of outbound SMTP holes in your firewall for direct delivery to Exchange Online – what can you do?

Whilst we’d hope that Microsoft will provide some guidance when they do finally release a way to remove the last Exchange Server, there are several options you can consider; after all – we are only considering standards-compliant SMTP relay with a known configuration on the Exchange Online side that can accept TLS-secured messages from known IP addresses and certificates.

The first option is to consider using Exchange Servers running the Edge Transport role. This role can be installed without connecting to any local Active Directory domain on standalone servers within a perimeter network area like a DMZ. The Edge Transport role doesn’t install any HTTPS services, and has lower minimum hardware requirements. Edge Servers are supported in a Hybrid Deployment, but the model for a sans-Exchange future would mean this model was not applicable, as no Exchange 2016 Mailbox servers would exist to provide an EdgeSync relationship, and you would instead create Send and Receive connectors directly on each Edge Server. Microsoft’s licensing FAQ indicates that a hybrid mail flow scenario would cover Edge Transport servers, as particular roles are not specified, but it’s important to check with your Microsoft account manager that this applies to you. Otherwise, the Edge Transport role provides the same ability to maintain relay Receive Connectors and a Send Connector onward to Exchange Online using the same skills you have today, and fulfils the need to remove Exchange from the corporate network and Active Directory.

Other options include firstly, using Windows Server’s IIS SMTP functionality. This is a configuration that some organizations have used with success, but remember – this is very similar to the SMTP functionality long-term Exchange admins will remember from Exchange Server 2000 and 2003. If you are considering IIS SMTP for mail relay, then it’s likely that you are desperate for an option to use, and perhaps a non-Microsoft solution might be more appropriate that has ongoing development and support. Open Source mail servers, like Exim, Postfix and Sendmail are well documented and capable of sustaining extremely high mail flow loads. They often form the underpinnings of cloud-based mail filtering solutions – but they require skills to setup and do require checks and maintenance – a Unix, Linux or BSD-based server running a Mail Transport Agent still needs to be patched, and can still be compromised.

If you’ve read this far and are thinking “No thanks – I don’t want to manage SMTP mail relay on-premises” – then consider whether beginning those efforts to press your legacy application vendors into making their software relay mail properly with Exchange Online is energy better spent and will result in a solution you don’t have to maintain.

Join me at TEC this week

For more on removing the last Exchange Server, join me this week for TEC. I’m presenting “Removing the last Exchange On-Premises Server where I talk through the above – and much more. I’d love to see you there.

Source Practical365

read more
Exchange 2016

Exchange 2016 messages stuck in Drafts

no thumb

Question.

Hello all, I have set up an Active Directory domain at home, with virtual machines running on a Hyper-V Server. I have two domain controlers running Windows Server 2016, and another Windows Server 2016 Server running Exchange 2016. I have two mailbox accounts (Bruno and Test), that I used for testing after setting up the Exhange Server. After the setup, I used the OWA to send and receive messages between these two accounts, and it was working, although it took about 5 minutes to receive a message. I noticed the RAM usage was very high, and turned the machine off, to give it 4GB extra. When I turned it back on I tried seding a message from the OWA, and when I do this, the message gets stuck in the Drafts folder with a message saying “Your message will be sent, but we’re not quite ready”. This message then becomes “Something went wrong and we haven’t been able to send your message yet.”. Why exactly is this happening? I tried rebooting the Exchange Server again, but the issue still persists.

 

Also, a different question: The Exchange Server is using the local domain in the email addresses (@ecorp.local). How would I make it so it uses a domain name I own, on Google Domains, for example?

Answer:

There are lots of possible causes, you can try the following steps to troubleshoot:
1.Make sure Microsoft Exchange Mailbox Transport Submission and Microsoft Exchange Mailbox Assistants services are running. Restart the services and do IIS restart.
2.Use the following commands to check the state and mail flow:

Get-ServerComponentState Identity <ServerID>
Test-Mailflow -Identity <ServerIdParameter> -MonitoringContext $true

3. Go to EAC-Server-DNSlookups to check if DNS is pointing to right place.
4.Try to add IP and HOSTNAME of the AD to the HOST file of the Exchange server like this: 

Host file is located in:c:\WINDOWS\system32\drivers\etc

 

For the second question, I’m not quite sure about your requirement. This thread may be talking about similar questions as yours:https://social.technet.microsoft.com/Forums/en-US/5f2f740f-c9d7-40d8-8870-8e1c03a85832/change-domain-name-in-exchange-2013?forum=exchangesvr3rdpartyapps

In addition, I have to mention that we focus on a single issue per post, which makes each thread clear for other’s reference. So I suggest you to open a new thread to post the second question if you need further help. Thanks for your understanding.

Source Social tech net

read more
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
1 2 3
Page 1 of 3