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

Friday, August 27, 2021

Microsoft released AAD Connect version 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.


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 ...

Where do those "# Questionable URLs detected in message" emails come from?

Monday, August 23, 2021

Exchange Online admins may receive emails from time-to-time with the line, "# Questionable URLs detected in message:". The email includes the SMTP headers, a text-only version of the original message, and the original message included as an attachment.

Where are these emails coming from and why are you getting them?

The answer lies within the User Submissions configuration in the Microsoft Defender portal ( Go to User submissions - Microsoft 365 security and check the Send the reported messages to: configuration.

The default and recommended setting is to send reported messages only to Microsoft, but you can reconfigure it to send to Microsoft and another email address in your organization.

This will send diagnostic info to both Microsoft and the internal email address you specified.

What isn't obvious is that Safe Links in Microsoft Defender for Office 365 (formerly ATP) uses the same configuration. When Safe Links detects questionable URLs in an email, that diagnostic information is sent the same way as User Submissions. So if you've configured User Submissions to send reported messages to an internal email address, you will get Safe Link reports to that address, too.

Read more ...

How to migrate AAD Connect to a new server

Wednesday, July 21, 2021

As I posted earlier, Microsoft has released Azure Active Directory Connect version 2.0.3, which now requires Windows Server 2016 or later. Customers running AAD Connect on Windows Server 2012 or Windows Server 2012 R2 will need to install a new copy of AADC on new Windows Server 2016 computer or later.

In this walk-through I will show you how to do this and migrate all your current settings to the new Windows 2016 server. These same steps can be used whenever you wish to move AADC to a new server.

The high-level steps are:

  • Export the existing AAD Connect configuration from the current server.
  • Install the latest version of AADC on a new or existing Windows Server 2016 computer.
  • Import the AADC configuration, put it into staging mode, and sync.
  • Uninstall AADC from the old server.
  • Remove the new server from staging mode.

Begin by exporting the AADC configuration on the current server. Open Azure AD Connect and select View or export current configuration.

Select View or export current configuration and click Next

Click the Export Settings button

The settings will be exported as a single JSON file in C:\ProgramData\AADConnect by default.
Copy this file to the new AAD Connect server.

Now login to the Windows Server 2016 or later computer where you want to install AADC. This can be either a new or existing domain-joined server.

Download the latest version of AAD Connect from and install it.

Start the AADC installer.

Select Customize since we're going to import the existing config.

Check Import synchronization settings and browse to the JSON file you copied from the old server.
Click Install to begin the installation.

The installer will walk you through setup using the existing config, similar to a manual upgrade.

Make sure Enable staging mode is checked, then click Install.

Installation will take a few minutes to complete and should look like this. Click Exit.

Open Computer Management on the new server and add the domain's Enterprise Admins group to the local ADSyncAdmins group so they can manage AAD Connect. Log off and back on to get the new management permissions.

You will notice that the two Azure AD Connect Health Sync services and the Microsoft Azure AD Sync service are now installed and running on the new server.

Open the Synchronization Service Manager client located at "C:\Program Files\Microsoft Azure AD Sync\UIShell\miisclient.exe". You will see that the initial full sync occured on the new server.

Now you're ready to complete the AAD Connect migration by uninstalling AADC from the old server and disabling staging mode on the new server.

Login to the old AADC server, open Programs and Features, and uninstall Microsoft Azure AD Connect.

Make sure to check "Also uninstall supporting components" and click Remove.

AADC is successfully uninstalled from the old server.

Now login to the new AADC server again and run Azure AD Connect to disable staging mode.

Select Configure Staging Mode and click Next.

Enter the tenant credentials for an admin who has Hybrid Identity Administrator or Global Admin rights.

Clear the checkbox to Enable staging mode and click Next.

Click Configure to disable staging mode and start the sync process.

Click Exit. The migration to the new AAD Connect server is now complete!

The final step is to delete the old MSOL_<guid> user account from Active Directory. You will find one MSOL_<guid> user account for each AADC installation. Uninstalling AADC does not remove the old account from AD.

Using Active Directory Users and Computers, find the MSOL accounts. They will be normally in the Users container by default. Examine the Description which will tell you which computer created each account.

Delete the MSOL_<guid> account that was created by the old AADC server.

Read more ...

Important updates to AAD Connect

Wednesday, July 21, 2021

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, 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

Wednesday, June 30, 2021

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,

$m = Get-Module -ListAvailable Defender
if ($m -eq $null) {
Write-Host "Windows Defender is not installed on" (Get-WmiObject -class Win32_OperatingSystem).Caption

$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

Wednesday, April 21, 2021

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 if you installed version

Thursday, April 1, 2021

Microsoft released AAD Connect 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.

Release status

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

Bug fixes

  • This release fixes a bug in version 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 are requested to update their Azure AD Connect server with this build, which will correctly register the Health feature.

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

Read more ...