How to migrate AAD Connect to a new server

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 https://www.microsoft.com/en-us/download/details.aspx?id=47594 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

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

You cannot migrate mailbox off of Office365 while the mailbox has a connected account enabled

Exchange hybrid is the only Microsoft migration method that allows you to move mailboxes in both directions between Exchange and Office 365.

I'm working with a customer who is offboarding their mailboxes from Exchange Online back to Exchange Server 2016. Several mailboxes cannot be migrated back to on-premises due to the following error:

You cannot migrate mailbox '2f15ec3c-b024-4a25-2fdf-bfda9fd806ba' off of Office365 while the mailbox has a connected account enabled. To successfully remove the connected accounts, run the following command: 'Get-Subscription -Mailbox MailboxID -Aggregati

Note the truncated command, which isn't very useful. 

The Get-Subscription cmdlet let's you view the properties of an existing subscription configured in a user's cloud-based mailbox. This cmdlet is used by Outlook on the web Options to display the list of email subscriptions that the end user has, such as POP, IMAP, Facebook, and LinkedIn.

The exact issue with the mailbox can be determined by running the following in Exchange Online PowerShell:

Get-Subscription -Mailbox user -AggregationType all | select DisplayName, Name, AggregationType, UserId, LastModifiedTime, LastSuccessfulSync, CreationType, Status, StatusDescription, DetailedStatus

We can see that the user has configured a subscription to LinkedIn so that Outlook can do a PeopleConnection lookup. This service was closed down by Microsoft over 3 years ago, but the subscription on the mailbox remains.

Run the following cmdlet in EXOPS to remove the subscription from the mailbox:

Get-Subscription -Mailbox UserId -AggregationType All | Remove-Subscription

Now you can resume the mailbox migration to complete the offboard.

Read more ...

Please join me for "HAFNIUM Exchange Server Hack: Why Patching Isn't Enough & Where to Start Hunting" webinar

Please join me, Michael Van Horenbeeck, and Paul Robichaux for a spirited discussion of the HAFNIUM Exchange Server Hack: Why Patching Isn't Enough & Where to Start Hunting. This free live webinar will held Friday, March 12, 2021 at 11:00AM EST.

We'll be discussing:

• How and where to spot key indicators of compromise
• Practical guidance on next steps to take if you’ve been compromised
• Ways to proactively start protecting yourself against future attacks

I hope you can join us!

Read more ...