The Future of Exchange Server

Microsoft published an important new article today detailing some of the requirements and recommendations for upgrading Exchange Server to the latest version, Exchange Server SE (Subscription Edition). Upgrading your organization from current versions to Exchange Server SE - Microsoft Community Hub

This article applies to all customers running Exchange Server on-premises, including hybrid customers using Exchange Server for hybrid management.

The blog post is dense with a lot of information, but the key important points are:

• Exchange Server SE is the next version of Exchange Server and will be released the second half of 2025.
• Exchange 2019 CU15 will be released Q4 this year. This will be the last cumulative update for Exchange 2019. There will be no future updates for Exchange 2016.
• Exchange 2019 CU15 will allow for an in-place upgrade to Exchange Server SE. This is a first for Microsoft. Previous upgrades required new servers.
• Exchange Server SE will only allow coexistence with Exchange 2016 CU23 and Exchange 2019 CU14/15.
• Exchange 2013 will become totally unsupported with the release of Exchange 2019 CU15. You must upgrade or remove Exchange 2013 from your organization ASAP.
• Customers should upgrade their Exchange 2016 servers to Exchange 2019 CU14/15 ASAP to prepare for Exchange Server SE.
• After Exchange Server SE is released in 2025, Exchange 2016 and 2019 will be subject to throttling by Microsoft. See Throttling and Blocking Email from Persistently Vulnerable Exchange Servers to Exchange Online - Microsoft Community Hub
• The following table from the blog post illustrates the milestones and actions to take:

• Licensing for Exchange Server SE will be similar to Exchange 2019 – You either must have an existing Microsoft 365 license for all users or you can buy server licenses and CALs with Software Assurance (SA).

Please reach out to EXPTA Consulting if you need help implementing these requirements. We also can meet with you to discuss options for removing the last Exchange Server from hybrid environments.

Read more ...

Deploy Extended Protection for Exchange server NOW

Exchange 2019 CU14 is expected to enable Windows Extended Protection in Exchange Server by default. This feature enhances the existing authentication in Windows Server and mitigates authentication relay or man-in-the-middle (MitM) attacks..

Extended Protection requires several very important prerequisites, which the link above describes.

Prerequisites for enabling Extended Protection on Exchange Server:

• SSL offloading must be disabled on all Exchange servers (it's enabled by default).

• Clients should use NTLMv2 instead of NTLMv1, which is the default setting in Windows. I recommend configuring this via Group Policy. If NTLMv1 is used by clients when Extended Protection is enabled, the configuration leads to password prompts on the client side without a way to authenticate successfully against the Exchange server.

• TLS configurations must be consistent across all Exchange servers within the organization. Any variation in TLS version use across servers can cause client connections to fail. I recommend that all Exchange servers be configured to use only TLS 1.2 for client and server operations, as well as .NET.

• Third-Party software running on your Exchange server must be compatible with Extended Protection. Ensure to test all third-party products that are running in your Exchange Server environment to ensure that they work properly when Extended Protection is enabled.

• Extended Protection doesn't work with hybrid servers using a Modern Hybrid configuration.

• Extended Protection can't be enabled on Exchange Server 2013 servers with Public Folders in a coexistence environment.

• Extended Protection can't be enabled on Exchange Server 2016 CU22 or Exchange Server 2019 CU11 or older that hosts a Public Folder hierarchy.

It's unlikely that the Exchange 2019 CU14 installer will perform "deep" inspection for these prerequisites, so this may cause problems in your environment if the prerequisites are not met and CU14 enables Extended Protection. The most likely issue will be that clients will be unable to connect or authenticate to Exchange server after Extended Protection is enabled.

I strongly recommend that all customers with Exchange server (including hybrid) check that they meet the requirements above and run the Exchange Extended Protection Management script before they install Exchange 2019 CU14. This script will check that the major requirements are met before enabling Extended Protection across all Exchange servers (not just Exchange 2019) in the organization.

The best course of action is to check and mitigate the Extended Protection prerequisites first. Always read the CU installation notes, especially if you use Windows Update to deploy this security update.

Please reach out to EXPTA Consulting if you would like assistance.

Read more ...

Lessons Learned and Best Practices for Autodiscover in a Hybrid Environment

Outlook uses the Autodiscover service to get real-time connection information for your mailbox and any other mailbox you connect to. Without Autodiscover you may be able to get Outlook to connect, but it won't connect correctly. For example, Exchange Web Services (EWS) connectivity in Outlook can only be made using Autodiscover.

Outlook normally performs Autodiscover requests when you setup a mail profile for the first time and from then on, periodically in the background. This is how automapped shared mailboxes get automatically added to Outlook. Outlook also runs an Autodiscover request when your mailbox moves between servers or databases, as when a failover event occurs. Autodiscover is also used whenever you check free/busy availability of another user's calendar.

Domain-joined computers in an Exchange Server or hybrid environment normally use a Service Connection Point (SCP) published in Active Directory to get the URI Outlook should use for Autodiscover requests. This is set using the Set-ClientAccessService -AutoDiscoverServiceInternalUri <value> cmdlet in the Exchange Management Shell (EMS).

There's a lot of documentation in the web that says you should set the AutoDiscoverServiceInternalUri value to $null after a hybrid migration is complete. But is that the right thing to do?

It's a long answer, so strap in. 😉  Tl;dr at the end.

First, know that Autodiscover behavior changes depending on the Outlook client and build version, as well as possible non-standard registry settings.

Microsoft 365 Apps for Enterprise always tries https://outlook.office365.com/autodiscover/autodiscover.xml first (Autodiscover-V2) regardless of your DNS settings. Microsoft's assumption is that if you’re running that version, your account is probably in the cloud. If your mailbox is indeed in EXO, that process looks like this and only takes 1-2 seconds:

Autodiscover-V2 will fail if your account is missing in EXO or not migrated yet and Outlook will then start the regular Autodiscover-V1 process. Note that the Autodiscover-V2 process can also be skipped with the following reg key. I see this often in older enterprise environments.

HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover]
"ExcludeExplicitO365Endpoint"=dword:00000001

Office 2016/2019 clients normally only do the regular Autodiscover-V1 process, which is well known:

1. Check for Local Data preference (configured via GPO to use an autodiscover.xml file stored locally on the computer)
2. Check for Last Known Good (LKG) cached data
3. Some later builds use heuristics to determine if the user account comes from Azure AD and will check against https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml 
4. SCP (see *notes below)
5. DNS
• Root domain (https://contoso.com/autodiscover/autodiscover.xml, which nearly always fails)
• Autodiscover URI (https://autodiscover.contoso.com/autodiscover/autodiscover.xml)
6. HTTP redirect
• http://autodiscover.contoso.com/autodiscover/autodiscover.xml
7. SRV
• Value from _autodiscover._tcp.contoso.com 443 0 0 in DNS

*Note that the SCP process won't work in several scenarios:

• The computer is not domain-joined
• SCP is $null
• SCP is not available via LDAP because the domain-joined machine is disconnected from the DC
• Registry keys can, and most often will, override the default Autodiscover behavior

Here’s what the process looks like for an M365 mailbox user in a hybrid environment from a domain-joined computer on the LAN. The SCP is set to https://autodiscover.contoso.com/autodiscover.autodiscover.xml (the on-prem Exchange Server). This process took 52 seconds to complete. Remember, this is the same process that Outlook goes through when creating a new mail profile, too.

When the SCP is set to $null it skips the first five lines, but execution time is nearly the same. It gets there, but it's not efficient and takes a really long time.

If we set the SCP to https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml, the process only takes about 1 second.

As you can see, setting the SCP to https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml is much more efficient than setting it to $null when the migration is complete.

Tl;dr:

The Service Connection Point (SCP) is set using the Set-ClientAccessService -AutoDiscoverServiceInternalUri <value> cmdlet.

• If you're a hybrid customer and you still have mailboxes on-premises that use Outlook:
• Set your SCP to https://autodiscover.contoso.com/autodiscover/autodiscover.xml.
• Create an A record for autodiscover.contoso.com in internal and external DNS resolving to on-prem Exchange for computers that can't reach AD.

• If you're a hybrid or cloud customer and all mailboxes that use Outlook or in EXO:
• Use Microsoft 365 Apps for Enterprise, which always checks EXO first. It also provides the best experience, features, and performance for cloud mailboxes.
• If you're hybrid, set your SCP to https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml.
• Create a CNAME record for autodiscover.contoso.com in external DNS resolving to autodiscover.outlook.com. This way, older clients that don't use Autodiscover-V2 will use the HTTP redirect method to get to EXO.

Read more ...

Exchange Online will Throttle and Block Email from Persistently Vulnerable Exchange Servers

Microsoft announced that they will begin Throttling and Blocking Email from Persistently Vulnerable Exchange Servers to Exchange Online.

They will begin slowly by blocking OnPremises (hybrid) connections from Exchange 2007 servers to Exchange Online, but plan to include all persistently vulnerable servers soon. A “persistently vulnerable server” is any Exchange server that has reached end of life (e.g., Exchange 2007, Exchange 2010, and very soon, Exchange 2013), or remains unpatched for known vulnerabilities.

If you have any Exchange 2007, 2010, or 2013 servers in your organization that are used for hybrid or SMTP relay, you must make plans to replace or remove them ASAP. You must also keep any Exchange 2016 and 2019 servers up to date with the latest Cumulative and Security Updates, as they are released.

I support this initiative. Organizations using Exchange Servers with known and unpatched vulnerabilities put themselves and their partners at risk. I look forward to seeing it include additional unsupported Exchange Server versions, and I understand their approach of rolling this out slowly and carefully at first.

There are millions of mailboxes in Exchange Online and they have a duty to protect those mailboxes. They know there are 16-year old Exchange 2007 servers currently connecting to their service that haven’t been patched in years and have dozens of known vulnerabilities. 

Microsoft is not forcing anyone to move to Exchange Online. They’re just not going to allow Exchange servers with known vulnerabilities to send hybrid (trusted) emails into their service.

It’s only 2007 for now, but eventually it will be any Exchange Server that is not running the latest or second to latest updates. It’s too risky for everyone.

The table below details the stages of progressive enforcement over time of a persistently vulnerable server:

Read more ...

Turning off Basic Authentication for Autodiscover in Exchange Online

Much has been said and written about disabling Basic Authentication in Exchange Online, and for good reason. Basic Auth is insecure and makes it easy for bad guys to hack your accounts and access your organization's data.

Microsoft disabled Basic Auth for most Exchange Online protocols in October of this year. Those protocols include Outlook, EWS, RPS, POP, IMAP, and EAS. SMTP Auth was also be disabled in your tenant if it is not being used. Modern Authentication is the secure way to authenticate for these protocols. Congratulations to Microsoft for pulling off such a monumental achievement to help keep customers' data safe!

Read Deprecation of Basic authentication in Exchange Online | Microsoft Learn for more information.

Next up, Microsoft is going to disable Basic Auth for the Autodiscover protocol. I would argue this is one of the most significant changes to deprecating Basic Auth, since it is continuously used by Outlook and whenever you configure a mail profile on a mobile device that uses ActiveSync. Because of this, it's easy to ignore this traffic when monitoring for Basic Auth usage. It's also a fairly easy protocol for the bad guys to use for password guessing or dictionary attacks.

As with all the other impacted protocols, Microsoft is not turning off the protocol itself, only the ability to authenticate to the protocol using nothing more than a username and password.

Read more ...

Azure AD Connect version 2.1.20.0 released with a new ability you probably can't use yet

UPDATE: Hot on the heels of the last update, Microsoft released Azure AD Connect version 2.1.20 (6 days later) which apparently fixes a bug in the new sync feature described below. If you implemented the custom sync rule described earlier, you'll need to undo it and do it again. <facepalm>

Microsoft updated Azure AD Connect to version 2.1.19.0 today. 

According to the release notes, "We added a new attribute 'employeeLeaveDateTime' for syncing to Azure AD. To learn more about how to use this attribute to manage your users' life cycles, please refer to this article".

Let's break this down.

First, the support article the release notes refer to is for Azure AD Connect cloud sync, not Azure AD Connect. At this time, syncing the employeeLeaveDateTime is still not supported in Azure AD Connect.

Since AAD cloud sync doesn't support Exchange hybrid at this time, AAD cloud sync is of no value for hybrid customers. However, the AD Connect team is working on adding Exchange hybrid support in the future. 

The support table shows that syncing the employeeHireDate attribute is already supported in Azure AD Connect, so I expect that suspect the configuration is the same. I could not find a similar support article for Azure AD Connect.

Second, the employeeHireDate and EmployeeLeaveDateTime attributes only exist in Azure AD. The on-premises Active Directory schema is not extended to add these two attributes, so the recommendation is to use one of the existing extensionAttribute* attributes an AD to hold these values.

At this time, Microsoft recommends using the extensionAttribute1 attribute for employeeHireDate, but the documentation makes no mention of how to handle the EmployeeLeaveDateTime attribute. See How to synchronize attributes for Lifecycle workflows - Microsoft Entra | Microsoft Learn. I hope this documentation will be updated soon with the missing info and how to handle it if this attribute is already in use in your organization.

Last, if you want to update the employeeLeaveDateTime attribute directly in Azure AD using the Graph API, please see Set employeeLeaveDateTime - Microsoft Graph | Microsoft Learn.

Read more ...

How to Setup Exchange Management Tools in Environments without Exchange Server

Some Exchange Online customers have an Active Directory on-premises, but never had Exchange Server on-prem. For example, customers who migrated their email from an Exchange hosted environment or from a different email system, such as Notes.

In some environments, these customers are having to manage user accounts and groups in both AD and Azure AD. This leads to confusion since accounts and passwords are not synced, so usernames and passwords can be different. Those customers may be looking for a way to master accounts, groups, and mailboxes from AD on-prem so they have a single source of authority, similar to the way that hybrid customers do.

In other environments, customers are using Azure AD Connect to sync users from AD on-premises to the cloud. Here, user accounts and groups are managed on-premises, but mailboxes are managed in Exchange Online. These customers may be looking for a way to manage mailboxes and groups from AD, so they also have a single source of authority.

The following steps will let you install the Exchange 2019 Exchange Management Tools (EMT) in an AD environment without having to install Exchange Server. 

Keep in mind that this solution is not supported by Microsoft, since manual configurations must be made in AD using ADSI Edit. The Microsoft supported way to do this is to install an Exchange Server in the org. The solution below does not require this.

Prerequisites

• Active Directory is installed and the Forest Functional Level is Windows Server 2012 R2 or higher.
• The Exchange Management Tools (EMT) must be installed on a domain-joined computer. Azure AD-joined by itself is not enough, since we need to be able to update Active Directory.
• EMT can be installed on Windows 10, Windows 11, or any Windows Server 2016+ server.
• You will need the Exchange Server 2019 CU12 or later media.
• The AD schema will be updated during EMT installation. These procedures assume the installation is being performed by a Domain Admin.

Steps for Installing the Exchange Management Tools

• Logon to the domain-joined computer or server where you want to install the EMT as a Domain Admin. For ease of installation, it is recommended that this computer be in the same AD site as the AD Schema Master.
• Install the .NET Framework 4.8.
• Install the Visual C++ 2012 Runtime.
• Install Windows Remote Server Administration Tools (RSAT) for Windows 10 or Windows 11. On Windows Server add the AD DS Tools from Server Manager.
• Install the IIS 6 Metabase Compatibility component using the following command:
• dism /online /Enable-Feature /FeatureName:IIS-IIS6ManagementCompatibility /all
• Restart the management computer twice to ensure all files and installations are up-to-date.
• Run Setup from the Exchange 2019 CU12+ media
• Select only Management Tools in the Server Role Selection
• You will be prompted to add the Exchange Organization Name (i.e., Contoso)
• Restart the computer after EMT installation
• Run the C:\Program Files\Microsoft\Exchange Server\V15\Scripts\Add-PermissionForEMT.ps1 script from an elevated PowerShell prompt to create the Recipient Management EMT security group in the Users container.
• Add admin accounts to the new Recipient Management EMT group. Domain Admins already have rights to run the EMT and do not need to be added.
• Create a shortcut on the Desktop to the EMT:
• C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noexit -command "Add-PSSnapin *RecipientManagement"
• Configure the shortcut to run as Administrator

Note:

All mailbox management will be done using the EMT PowerShell cmdlets. The Exchange Management Shell (EMS) will also be installed, but you will never use it because you have no Exchange Server to connect to.

There is no built-in GUI for EMT recipient management, but fellow Office Apps & Services MVP Steve Goodman wrote one on GitHub. You may want to check it out. 

Also, be aware that the EMT does not support roles based access controls (RBAC) and there is no auditing available. For complete Microsoft EMT documentation see Install the Exchange management tools | Microsoft Learn.

Microsoft Exchange System Objects (MESO) Configuration

In order for admins to create remote mailboxes, you need to add a remote domain to the Exchange configuration partition in Active Directory. This is done using ADSI Edit. The usual disclaimer applies - Don't use this tool unless you know what you're doing. I accept no responsibility. Yada yada yada.

• Begin by getting your Microsoft 365 tenant's remote routing domain.
• Open Exchange Admin Center
• Navigate to Mail Flow > Accepted Domains
• Record the accepted domain of the domain that looks like domain.mail.onmicrosoft.com

• Open ADSIEdit.msc from the management computer. This was installed when you installed the Windows Remote Server Administration Tools (RSAT).
• Connect to the Configuration Naming Context.
• Navigate to CN=Configuration > CN=Services > CN=Microsoft Exchange > CN=domain > CN=Global Settings > CN=Internet Message Formats
• Right-click CN=Internet Message Formats and select New > Object...
• Select the class msExchDomainContentConfig and click Next
• Enter Hybrid Domain - domain.mail.onmicrosoft.com for the value, using the value recorded above. Click Next and Finish.
• Edit the Hybrid Domain you just created and set the following values:
• contentType: 0
• domainName: domain.mail.onmicrosoft.com, using the value recorded above
• msExchContentByteEncoderTypeFor7BitCharsets: 15
• msExchContentPreferredInternetCodePageForShiftJis: 0
• msExchDomainContentConfigFlags: 1
• msExchMinAdminVersion: -2147453113
• msExchResolveP2: 2147483647
• msExchRoutingAcceptMessageType: 351
• msExchRoutingDisplaySenderEnabled: True
• msExchVersion: 4535486012416
• sendTNEF: True
• Close ADSI Edit.

Add the remote routing domain as an accepted domain.

• Run the following from an elevated EMT prompt, using the value you recorded above:
• New-AcceptedDomain domain.mail.onmicrosoft.com -DomainName domain.mail.onmicrosoft.com

Update the email address policy that was created when the EMT was installed.

• Run the following from an elevated EMT prompt:
• Get-EmailAddressPolicy | Set-EmailAddressPolicy -EnabledEmailAddressTemplates "SMTP:@domain.com","smtp:@domain.mail.onmicrosoft.com"
• Replace the domains with the correct values.
• SMTP:@domain.com (SMTP in all caps) is the primary SMTP address for your organization.
• smtp:@domain.mail.onmicrosoft.com is the remote routing domain that you recorded above.

Now you can run all the EMT cmdlets to update your on-prem user accounts, mailboxes, and groups.

Configure AD Synchronization with Azure AD

Now that you have a way to update Exchange attributes in AD, the final step is to configure Azure AD Connect to sync the AD objects with Azure AD. 

If your environment already has AAD Connect installed and configured, you only need to update the AAD Connect configuration to use Exchange Hybrid Deployment in Optional Features.

If your environment doesn't already have Azure AD Connect installed and configured, you will need to do so and perform a soft match of the AD accounts to Azure AD. That's beyond the scope of this article. 

If you need help please reach out to me at EXPTA Consulting.

Read more ...

Big Exchange News!

Lots of exciting announcements are being made today about Exchange Server on the EHLO Blog.

• Free Exchange 2019 hybrid keys are being made available. This, along with the public availability of Exchange Server 2019 bits, means that customers can deploy Exchange 2019 hybrid management servers for free!

• A new Exchange Management Tools update is being announced. This will allow customers who have completed their migration to Microsoft 365 Exchange Online an option to turn off (not remove!) their last Exchange Server. There are several large caveats to this -- The solution is PowerShell only, it does not support RBAC, and there is no auditing available. I'm working on a blog article that does a walkthrough and explains all the details.

• The Hybrid Configuration Wizard is making several improvements, including MFA support.

• Microsoft is changing the updates delivery model for Exchange Server to bi-annually, rather than (roughly) every quarter. This will allow customers more time for testing and deployment between releases.

• Exchange Server 2019 is adding Windows Server 2022 support. Exchange 2019 CU12 and above can be installed on Windows Server 2019 or Windows Server 2022.

• With the latest CUs, Exchange Server 2013/2016/2019 now supports Windows Server 2022 Active Directory environments. Exchange customers no longer need to put off upgrading their Domain Controllers.

• New Microsoft Bounty Program for Exchange Server. A security vulnerability bounty program for Microsoft Exchange Server is being launched to help keep Exchange Server secure for all customers.

Read all about these exciting changes here: Released: 2022 H1 Cumulative Updates for Exchange Server

Read more ...

Yes, Virginia, You Can Buy Exchange 2019!

In the Beginning

When Exchange 2019 was announced at Microsoft Ignite 2019, it was also announced that Exchange Server 2019 and its Cumulative Updates would be available only through the Volume Licensing Service Center (VLSC). It was explained that large enterprise customers were asking for security, reliability, and dependability. They want all the things that mean Exchange runs as a mission critical application.

Welcome to Exchange Server 2019! - BRK2176

As Greg Taylor, then Director of Product Marketing for Exchange Server/Online, said at the time, "For those customers who still want to stay on premises, that's the reason we built Exchange 2019. And that's also the reason why we are only going to distribute Exchange 2019 to those customers through Volume Licensing."

As anticipated, Exchange Server 2019 RTM and CUs 1-8 were only available through the VLSC and to developers for testing and application development through MSDN. And for the first time ever, the current version of Exchange Server was no longer available on the Office Servers Evaluation Center.

To access Exchange Server 2019 through the VLSC, customers must have an active agreement in one of the following Microsoft Volume Licensing programs:

• Microsoft Enterprise Agreement (500+ seats)
• Microsoft Products and Services Agreement (250+ seats)
• Microsoft Open Value Agreement (5-499 seats)

See the Compare Microsoft Volume Licensing Programs resource document for full details.

I've found that most small-midsize customers mistakenly think that access to the VLSC requires an Enterprise Agreement or large minimum spend requirement. Plus, most of these customers buy licenses through a third-party license provider, like a Cloud Solution Provider or licensing distribution partners. Few of the customers I speak with have actually entered into a licensing agreement directly with Microsoft.

The VLSC requirement imposed a barrier that prevented these customers from accessing Exchange Server 2019. And if non-VLSC customers cannot get Exchange 2019, it means that Exchange 2016 is the latest version they could use for hybrid management after they have completed their migration to the cloud.

As we know, an Exchange server is still required for Exchange recipient management even after all mailboxes have been moved to Microsoft 365 since Active Directory is still the Source of Authority for hybrid customers.

Then HAFNIUM happened...

In March 2021 a state-sponsored hacking group called HAFNIUM targeted Exchange Servers around the world by exploiting zero-day vulnerabilities. Threat actors gained access to email servers and installed malware to facilitate long-term access to victim environments and to perform data exfiltration.

Microsoft quickly responded to HAFNIUM by releasing Security Updates (SUs) that patched the Exchange Server vulnerabilities and a short time later included these fixes in the March 2021 Quarterly Exchange Updates. In an effort to ensure that all customers could get and stay up-to-date, it was decided to publish Exchange Server 2019 CU9 and future CUs to the Microsoft Download Center in addition to the VLSC.

What This Means to Hybrid Customers

Exchange hybrid customers who have completed their migration to the cloud can now use Exchange Server 2019 as their hybrid management server. All customers can now run the latest version of Exchange server with the most recent CUs and SUs by downloading them from the Download Center, even with a Volume Licensing agreement.

CU's are build-to-build upgrades and contain a full server installation, so the latest CU can be used for a fresh installation. Always check the Exchange Team Blog for details on the latest CU. All customers, including hybrid customers, should keep their Exchange servers up to date using the N-1 support statement (the current and previous CUs and SUs are supported).

Keep in mind that currently there is no free Exchange hybrid license available for Exchange 2019 like there is for Exchange 2013/2016, so customers will need to license their Exchange Server 2019. See Big Exchange Announcements!

Customers with Exchange Server 2010 must keep in mind that Exchange Server 2019 will not install if Exchange 2010 is in the environment. Those customers must transition to Exchange Server 2016 and decommission Exchange 2010 before installing Exchange 2019.

Read more ...

AAD Connect 2.0.88.0 breaks Shared Mailboxes for Exchange hybrid customers

Microsoft released Azure AD Connect version 2.0.88.0 as a download-only version on 12/16/2021. This update includes several bug fixes and introduces support for syncing AD objects from a single forest to multiple tenants.

However, this version contains a new potentially devastating bug that removes disabled user accounts in AD from Azure AD. 

Because shared mailboxes use disabled user accounts this means those mail users are also deleted from Exchange Online. Cloud users will no longer see on-prem shared mailboxes in the GAL or be able to access them. Inbound mail flow will also be affected for these mailboxes since they no longer exist from an Exchange Online Protection perspective.

Luckily, version 2.0.88.0 is not being pushed as an auto upgrade version, so only customers who download and install it are affected.

AAD Connect version 2.0.89.0 has been released. If you are affected by this bug, you should update to the latest version. See my other updates below.

The workaround is to remove AAD Connect 2.0.88.0 and reinstall the previous AAD Connect version 2.0.28.0. Since Microsoft removes all but the most current version, I've made AAD Connect 2.0.28.0 available on my blog here.

I recommend exporting your current AAD Connect configuration first, then importing it when installing version 2.0.28.0. Be sure to uncheck the "Enable staging mode" when completing the installation. 

During the first sync you will see that the disabled accounts in AD are being synced again to Azure AD.

Update #1 - Dec 22, 2021

The Azure AD Connect Version History website was updated yesterday after my blog post to say that version 2.0.89.0 has been released which addresses this issue. However, at this time only 2.0.88.0 is still available from the AAD Connect download website.

Update #2 - Dec 22, 2021

AAD Connect version 2.0.89.0 is now available for download. Strangely, this new version is no longer listed in the version history. :-/ 

I  have confirmed that the bug has been squashed.

Read more ...

Azure AD Connect V1.X versions no longer support the V2 endpoint

Microsoft introduced the Azure AD Connect sync V2 endpoint with version 1.6.4.0 in March 2021. Among the improvements, the V2 endpoint includes performance improvements and allows for synchronization of groups with up to 250K members. Enterprise customers with groups of 50K or more were encouraged to move to the new V2 endpoint.

AAD Connect version 2.0.3.0 was released in July 2021 and was a major upgrade. It supports the V2 endpoint by default, but requires Windows Server 2016 or 2019 due to it's dependency on SQL Server Express 2019 for localDB. There are still many customers running AADC V1.x for this reason.

Today, Microsoft updated the AADC version history to say that the V2 endpoint is no longer available for V1.x versions. 

UPDATE - 11/10/2021: Microsoft just added the following information to the AAD Connect version history:

Known Issues

There is an issue where customers who have the V2 endpoint running with an older version and try to upgrade to a newer V1.6 release will see that the 50K limitation on group membership is reinstated. We will not fix this issue in V1.6 and require customers to upgrade to AADConnect V2.0 if this is an issue for them.

Azure AD Connect V1.x customers are strongly encouraged to update to V2.x, keeping in mind that this may require installing AADC V2.x on a new Windows 2016 or Windows 2019 server. I wrote a step-by-step article on upgrading here.

In the meantime, if you are still using Azure AD Connect 1.x you should make sure you're using the V1 endpoint using the following steps.

First, check to see which sync endpoint you're using with these cmdlets, run from the server where Azure AD Connect 1.x is running:

• Import-Module 'C:\Program Files\Microsoft Azure AD Sync\Extensions\AADConnector.psm1'
• Get-ADSyncAADConnectorExportApiVersion
• Get-ADSyncAADConnectorImportApiVersion

If both Get-* cmdlets return the value "1", you're using the V1 endpoint. Nothing more to do here, except plan to upgrade to AAD Connect V2.x as soon as reasonable.

If the values returned are "2", you're using the V2 endpoint and need to change it back to V1.

• Import-Module 'C:\Program Files\Microsoft Azure AD Sync\Extensions\AADConnector.psm1'
• Set-ADSyncScheduler -SyncCycleEnabled $false
• Set-ADSyncAADConnectorExportApiVersion 1
• Set-ADSyncAADConnectorImportApiVersion 1
• Set-ADSyncScheduler -SyncCycleEnabled $true

Be aware that the V1 endpoint cannot sync groups with 50K+ members. You should plan to upgrade to AAD Connect V2.x as soon as possible.

Read more ...

IMPORTANT: AAD Connect versions 1.x will retire August 31, 2022

Microsoft released AAD Connect version 2.0.8.0 on August 10, 2021 which included many important changes. Not the least of which is that the localDB database used by AADC was changed to SQL Server 2019. This means that AAD Connect version 2.x can only run on Windows Server 2016 or later, since that's a requirement for SQL Server 2019.

Today, Microsoft posted in the Azure Active Directory Connect version history that all 1.x versions of AAD Connect will be retired August 31, 2022, roughly one year after version 2.x was released.

Important

On 31 August 2022, all 1.x versions of Azure Active Directory (Azure AD) Connect will be retired because they include SQL Server 2012 components that will no longer be supported. Either upgrade to the most recent version of Azure AD Connect (2.x version) by that date, or evaluate and switch to Azure AD cloud sync.

You need to make sure you are running a recent version of Azure AD Connect to receive an optimal support experience.

If you run a retired version of Azure AD Connect it may unexpectedly stop working and you may not have the latest security fixes, performance improvements, troubleshooting and diagnostic tools and service enhancements. Moreover, if you require support we may not be able to provide you with the level of service your organization needs.

Go to this article to learn more about Azure Active Directory Connect V2.0, what has changed in V2.0 and how this change impacts you.

Please refer to this article to learn more about how to upgrade Azure AD Connect to the latest version.

For version history information on retired versions, see Azure AD Connect version release history archive

A few notes on this announcement:

1. "Retired" doesn't necessarily mean it won't work anymore, but I suspect Microsoft will eventually block it in the future. You should ALWAYS keep AAD Connect up-to-date for the best features, performance, and security.
2. Although the announcement mentions evaluating and switching to Azure AD cloud sync, be aware that AAD cloud sync is not compatible with Exchange. See my article, How to Decide Between Azure AD Connect and Azure AD Connect Cloud Sync on the Practical365 blog. I also recorded a video podcast about AAD cloud sync with Steve Goodman from Practical365 here.
3. Refer to my article, How to migrate AAD Connect to a new server for step-by-step instructions how to move AAD Connect to a new Windows 2016 Server using the latest version of AADC. There's really no better time to do it than now.

Read more ...

Important updates to AAD Connect

AAD Connect is used to synchronize Active Directory with Azure Active directory and is a critical component in a Exchange hybrid configuration. It's very important for admins to keep AAD Connect up-to-date with the latest build for security and feature enhancements.

Microsoft just released AAD Connect version 2.0.3.0, which includes a number of significant changes and new features. At top of the list is that AADC is no longer supported on Windows Server 2012 R2 or earlier. This is because the built-in database, LocalDB, is now using components from SQL Server 2019 which requires Windows Server 2016 or later.

If you're currently running AADC on Windows Server 2012 or Windows Server 2012 R2, auto upgrade will not happen, for obvious reasons.

Customers running AADC on earlier OS's will need to install a new copy of AADC on new Windows Server 2016 computer or later. I wrote a step-by-step walkthrough of that process here.

Other significant changes in this version include:

• TLS 1.2 is enforced in this build. If TLS 1.2 is disabled in the OS, will you will see an error message when attempting to install AADConnect and the installation will not continue until you have enabled TLS 1.2.
• Added two new cmdlets to the ADSyncTools module to enable or retrieve TLS 1.2 settings from the Windows Server:
• Get-ADSyncToolsTls12
• Set-ADSyncToolsTls12
• You no longer need to be a Global Admin to install or manage AADC. The "Hybrid Identity Administrator" user role can now be used.
• AAD now honors the "User must change password at next logon" flag when set in AD.

For a full list of the all the new features and big fixes visit Azure AD Connect: Version release history.

Read more ...

Script to Set Exchange Server Antivirus Exclusions for Windows Defender

Microsoft released the June 2021 Quarterly Exchange Updates which now includes Exchange Server AMSI integration. 

The Antimalware Scan Interface (AMSI) allows antivirus software, such as Windows Defender which is installed by default on Windows Server 2016 and Windows Server 2019, to dynamically scan for malware such as the web shells created by the HAFNIUM attack earlier this year. Here's the Microsoft announcement which includes links to Exchange Server 2019 CU 10 and Exchange Server 2016 CU 21:

Exchange Server AMSI Integration

As mentioned in our recent blog post, the June 2021 CUs include new Exchange Server integration with AMSI (Antimalware Scan Interface). AMSI exists in Windows Server 2016 and Windows Server 2019, and the new integration is available in Exchange 2016 and Exchange 2019 when running on either of those operating systems. For Exchange 2016, AMSI integration is available only when running on Windows Server 2016. It is not available for Exchange 2016 running on Windows Server 2012 or Windows Server 2012 R2.

AMSI integration in Exchange Server provides the ability for an AMSI-capable antivirus/antimalware solution to scan content in HTTP requests sent to Exchange Server and block a malicious request before it is handled by Exchange Server. The scan is performed in real-time by any AMSI-capable antivirus/antimalware solution that runs on the Exchange server as the server begins to process the request. This provides automatic mitigation and protection that compliments the existing antimalware protection in Exchange Server to help make your Exchange servers more secure.

Because we know that some of our customers modify the web.config file on their Exchange Server, we wanted to let you know that installation of the June 2021 CUs will add a new section in the web.config of every HTTP service under <Modules>. The entry will be called "HttpRequestFilteringModule" and it must be present for AMSI integration to work.

AMSI helps keep your Exchange servers protected from malware, but it's still imperative to set the antivirus exclusions for Exchange Server as per the article, Running Windows antivirus software on Exchange servers on Microsoft Docs. This is required to prevent anti-virus/anti-malware solutions from potentially corrupting the Exchange Server installation, worker processes, and databases. Trust me. I've seen this happen many times and it usually ends up with a complete server rebuild.

If you've ever looked at this document, it lists many folder, process, and file name extension exclusions. To ease this configuration for Windows Defender I created the following Set-ExchangeAntivirusExclusionsForDefender.ps1 PowerShell script. 

Please note this script only works for Windows Defender running on Windows Server 2016 or 2019. If you're running another antivirus or antimalware solution, you'll still need to configure these exclusions some other way.

Simply copy the text below to a Set-ExchangeAntivirusExclusionsForDefender.ps1 file on your Exchange server and run it from EMS.

#Sets Exchange 2016/2019 antivirus exclusions for Windows Defender

#Author: Jeff Guillet | MCSM | MVP, jguillet@expta.com

#Ref: https://docs.microsoft.com/en-us/Exchange/antispam-and-antimalware/windows-antivirus-software?view=exchserver-2019

$m = Get-Module -ListAvailable Defender

if ($m -eq $null) {

Write-Host "Windows Defender is not installed on" (Get-WmiObject -class Win32_OperatingSystem).Caption

Exit

}

$ExchangeInstallPath = $Env:ExchangeInstallPath -replace ".$"

$excludedPaths = @( "$Env:SystemDrive\ExchangeSetupLogs", `

"$ExchangeInstallPath", `

"$Env:WinDir\SoftwareDistribution", `

"$Env:SystemRoot\Cluster", `

"$Env:SystemRoot\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files", `

"$Env:SystemRoot\System32\Inetsrv" ), `

"$Env:SystemDrive\inetpub\temp\IIS Temporary Compressed Files"

$excludedExtensions = @( "config", "chk", "edb", "jfm", "jrs", "log", "que", "dsc", "txt", "cfg", "grxml", "lzx" )

$excludedProcesses = @( "$ExchangeInstallPath\Bin\Search\Ceres\Runtime\1.0\noderunner.exe", `

"$ExchangeInstallPath\Bin\EdgeTransport.exe", `

"$ExchangeInstallPath\Bin\Microsoft.Exchange.AntispamUpdateSvc.exe", `

"$ExchangeInstallPath\Bin\Microsoft.Exchange.Diagnostics.Service.exe", `

"$ExchangeInstallPath\Bin\Microsoft.Exchange.Directory.TopologyService.exe", `

"$ExchangeInstallPath\Bin\Microsoft.Exchange.AntispamUpdateSvc.exe", `

"$ExchangeInstallPath\Bin\Microsoft.Exchange.EdgeCredentialSvc.exe", `

"$ExchangeInstallPath\Bin\Microsoft.Exchange.EdgeSyncSvc.exe", `

"$ExchangeInstallPath\Bin\Microsoft.Exchange.Notifications.Broker.exe", `

"$ExchangeInstallPath\Bin\Microsoft.Exchange.ProtectedServiceHost.exe", `

"$ExchangeInstallPath\Bin\Microsoft.Exchange.RPCClientAccess.Service.exe", `

"$ExchangeInstallPath\Bin\Microsoft.Exchange.Search.Service.exe", `

"$ExchangeInstallPath\Bin\Microsoft.Exchange.Servicehost.exe", `

"$ExchangeInstallPath\Bin\Microsoft.Exchange.Store.Service.exe", `

"$ExchangeInstallPath\Bin\Microsoft.Exchange.Store.Worker.exe", `

"$ExchangeInstallPath\Bin\MSExchangeCompliance.exe", `

"$ExchangeInstallPath\Bin\MSExchangeDagMgmt.exe", `

"$ExchangeInstallPath\Bin\MSExchangeDelivery.exe", `

"$ExchangeInstallPath\Bin\MSExchangeFrontendTransport.exe", `

"$ExchangeInstallPath\Bin\MSExchangeHMHost.exe", `

"$ExchangeInstallPath\Bin\MSExchangeHMWorker.exe", `

"$ExchangeInstallPath\Bin\MSExchangeMailboxAssistants.exe", `

"$ExchangeInstallPath\Bin\MSExchangeMailboxReplication.exe", `

"$ExchangeInstallPath\Bin\MSExchangeRepl.exe", `

"$ExchangeInstallPath\Bin\MSExchangeSubmission.exe", `

"$ExchangeInstallPath\Bin\MSExchangeTransport.exe", `

"$ExchangeInstallPath\Bin\MSExchangeTransportLogSearch.exe", `

"$ExchangeInstallPath\Bin\MSExchangeThrottling.exe", `

"$ExchangeInstallPath\Bin\OleConverter.exe", `

"$ExchangeInstallPath\Bin\UmService.exe", `

"$ExchangeInstallPath\Bin\UmWorkerProcess.exe", `

"$ExchangeInstallPath\Bin\wsbexchange.exe", `

"$ExchangeInstallPath\FIP-FS\Bin\fms.exe", `

"$ExchangeInstallPath\Bin\Search\Ceres\HostController\hostcontrollerservice.exe", `

"$ExchangeInstallPath\TransportRoles\agents\Hygiene\Microsoft.Exchange.ContentFilter.Wrapper.exe", `

"$ExchangeInstallPath\FrontEnd\PopImap\Microsoft.Exchange.Imap4.exe", `

"$ExchangeInstallPath\ClientAccess\PopImap\Microsoft.Exchange.Imap4service.exe", `

"$ExchangeInstallPath\FrontEnd\PopImap\Microsoft.Exchange.Pop3.exe", `

"$ExchangeInstallPath\ClientAccess\PopImap\Microsoft.Exchange.Pop3service.exe", `

"$ExchangeInstallPath\FrontEnd\CallRouter\Microsoft.Exchange.UM.CallRouter.exe", `

"$ExchangeInstallPath\Bin\Search\Ceres\ParserServer\ParserServer.exe", `

"$ExchangeInstallPath\FIP-FS\Bin\ScanEngineTest.exe", `

"$ExchangeInstallPath\FIP-FS\Bin\ScanningProcess.exe", `

"$ExchangeInstallPath\FIP-FS\Bin\UpdateService.exe", `

"$Env:SystemRoot\System32\Dsamain.exe", `

"$Env:SystemRoot\System32\inetsrv\inetinfo.exe", `

"$Env:Systemroot\System32\WindowsPowerShell\v1.0\Powershell.exe", `

"$Env:SystemRoot\System32\inetsrv\W3wp.exe" )

$excludedPaths | ForEach {if (!(Test-Path -Path $_ )) {New-Item -ItemType Directory -Path $_ }; Add-MpPreference -ExclusionPath $_ }

$excludedExtensions | ForEach {Add-MpPreference -ExclusionExtension $_ }

$excludedProcesses | ForEach {Add-MpPreference -ExclusionProcess $_ }

Be sure to run this from all your Exchange servers including those used for hybrid and Edge Transport after installation. You do not need to run it again after CU installations, but it won't hurt anything if you do.

Read more ...

Send as SMTP alias is now available in Exchange Online

One of the longest running user requests is finally a reality. Users can finally send emails as one of their alias SMTP addresses. At least they can in Exchange Online in Microsoft 365. We'll need to wait and see if this comes to on-premises Exchange Servers. I can't imagine why it wouldn't, but it will probably only come to Exchange 2019 in a future CU or Exchange Server vNext.

UserVoice may no longer exist, but ancient stone tablets have been unearthed that show this has been requested by users for a long, long time.

Exchange Admins can assign alternate email addresses, or aliases, to user mailboxes. Users can receive emails for any of their aliases, but up till now, emails and replies can only be sent using their primary SMTP email address.

With the new behavior, emails sent using one of their aliases show the From address and the Reply-To address as the alias SMTP address that's being used. And there was much rejoicing.

You enable Send From Alias using Exchange Online PowerShell. Simply run the following cmdlet:

Set-OrganizationConfig -SendFromAliasEnabled $true

Once set, users can send emails using one of their configured alias addresses in Outlook or OWA.

To do this in Outlook, the user must first show the From field for new emails using the Options menu. Then they can pick an alias address they've previously used or click Other Email Address and type in the one they want to use.

To do this from Outlook on the web, create a new message, click the (...) ellipses, and click Show From. Then type the email alias you want to use for the new email.

Emails will be delivered to recipients showing the user's full name and the From email address:

If we examine the SMTP headers we see that the From address and the Return-Path values are using the specified alias.

It's important to have valid SPF, DKIM, and/or DMARC records set for the alternate alias' domain to ensure delivery can be made. This is an important consideration with customers in merger and acquisition scenarios.

In my testing I found that when the user receives emails or replies to the alias, Outlook always replies from the primary email address. The user will need to manually change the From address if they want to "continue the lie". Hopefully, this will be fixed in the future.

Read more ...

Install AAD Connect 1.6.4.0 if you installed version 1.6.2.4

Microsoft released AAD Connect 1.6.2.4 as a download-only version. Although it includes significant changes, including updating the software to use the new AAD V2 endpoint, it was not offered as an automatic update. Turns out that was a wise decision since it breaks the Azure AD Connect Health feature.

1.6.4.0

Release status

3/31/2021: Released for download only, not available for auto upgrade

Bug fixes

• This release fixes a bug in version 1.6.2.4 where, after upgrade to that release, the Azure AD Connect Health feature was not registered correctly and did not work. Customers who have deployed build 1.6.2.4 are requested to update their Azure AD Connect server with this build, which will correctly register the Health feature.

If you installed build 1.6.2.4 (either first-time install or as a manual update) please update ASAP to the newest build 1.6.4.0. Get it here: Download Microsoft Azure Active Directory Connect from Official Microsoft Download Center

Read more ...