Released: August 2022 Exchange Server Security Updates

[The_Exchange_Team]

Microsoft has released security updates (SUs) for vulnerabilities found in:

• Exchange Server 2013
• Exchange Server 2016
• Exchange Server 2019

IMPORTANT: Updates are released in a self-extracting auto-elevating .exe package. Please see this post for more information. Older version of update packages can be downloaded from Microsoft Update Catalog.

These SUs are available for the following specific builds of Exchange Server:

• Exchange Server 2013 CU23
• Exchange Server 2016 CU22 and CU23
• Exchange Server 2019 CU11 and CU12

The SUs address vulnerabilities responsibly reported to Microsoft by security partners and found through Microsoft’s internal processes. Although we are not aware of any active exploits in the wild, our recommendation is to immediately install these updates to protect your environment.

These vulnerabilities affect Exchange Server. Exchange Online customers are already protected from the vulnerabilities addressed in these SUs and do not need to take any action other than updating any Exchange servers in their environment.

More details about specific CVEs can be found in the Security Update Guide (filter on Exchange Server under Product Family).

Manual enablement of Windows Extended Protection

Addressing some of CVEs released this month requires admins to enable Windows Extended protection on your Exchange servers. To help you enable this feature, we have developed a script for this process. Please carefully evaluate your environment and review all known issues mentioned in the script documentation before enabling Windows Extended protection on your Exchange servers.

Please note that enabling Extended Protection (EP) is only supported on specific versions of Exchange (please see documentation for full list of prerequisites).

The current version of this script can be found at https://aka.ms/ExchangeEPScript and the documentation is at https://aka.ms/ExchangeEPDoc. The script provided to enable Extended Protection will automatically update itself and ask you to relaunch it as long as the computer on which it is executed on has an internet connection (direct or via proxy). However, if you don’t have internet access, make sure to download the latest version of the script as we are continuously improving it.

It is important that you fully understand Windows Extended Protection prerequisites and all known issues before running the script in your environment. Enabling Extended Protection affects communication between your Exchange servers and between clients and servers.

Update installation

Update paths available:

Inventory your Exchange Servers / determine which updates are needed

Use the Exchange Server Health Checker script (use the latest release) to inventory your servers. Running this script will tell you if any of your Exchange Servers are behind on updates (CUs and SUs).

Update to the latest Cumulative Update

Go to https://aka.ms/ExchangeUpdateWizard and choose your currently running CU and your target CU to get directions for your environment.

If you encounter errors during or after installation of Exchange Server updates

If you encounter errors during installation, see the SetupAssist script. If something does not work properly after updates, see Repair failed installations of Exchange Cumulative and Security updates.

Known issues with this release

We are not aware of any known issues with this release.

FAQs

My organization is in Hybrid mode with Exchange Online. Do I need to do anything?
While Exchange Online customers are already protected, the August 2022 SUs do need to be installed on your on-premises Exchange servers, even if they are used only for management purposes. You do not need to re-run the Hybrid Configuration Wizard (HCW) after installing updates.

Do I need to install the updates on ‘Exchange Management Tools only’ workstations?
Servers or workstations running only the Management Tools role (no Exchange services) do not need these updates.

We skipped installation of May 2022 SU. Do we need to run /preparealldomains after we install the August SU?
When May 2022 SU was released, the /preparealldomains switch needed to be run manually to address a particular CVE. If you skipped the May 2022 SU and are going straight to August 2022 SU, you will still need to run /preparealldomains to address that particular CVE. Please see the May 2022 SU release post for more details. When in doubt, run HealthChecker which will tell you what you need to do!

Updates to this post:

• 8/11: Updated the "update paths" graphics to indicate the preferred path for server running supported CUs older than 2022 H1 CUs. This is the "Preferred path" due to less restrictive Extended Protection requirements (see EP documentation)
• 8/10: Clarified the wording for script auto-update capability
• 8/10: Added a FAQ about /preparealldomains for customers who skipped May 2022 SU
• 8/9: We temporarily removed and now re-added a link to Exchange 2019 CU12 update package because of the issue with original download. The date of publication on the correct package is 8/9/2022

The Exchange Server Team

[Lukas Sassl]

@Marc K thanks for your feedback. So, you initially experienced the issue with KB5008631. You migrated then to Exchange 2019 and the issue did not occur again, correct?

@PeterC2 have you installed the August 2022 SU for Exchange 2013 and tested if the eDiscovery search issue still exists? It should not as it is marked as resolved for the August 2022 SU. Please confirm.

See:  https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-... 

[madeyem]

@The_Exchange_Team 

Exchange 2013 CU23

Windows Server 2012 R2

I installed the August 2022 update and enabled Extended Protection. Script went through without problems.

My problem now is, that some (not all users) get constant password prompts in Outlook 2016. Their Outlook can't login, putting in the password doesn't do anything, same prompt again. However, they can login to Outlook Web Access. Others have no problem at all. Everyone here has same Windows, same Outlook.

Can anyone help, any advice?

Update 08/22/2022:

I finally found the problem. On the clients, that get constant PW prompts when opening Outlook, check registry:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa

The key "LmCompatibilityLevel" had value 1. On my PC (no problems with Outlook) the Key doesn't exist. So you can either delete the key or set its value to at least 3, restart the PC and Outlook should be working properly again.

Check the documentation here (see Method 1):

https://docs.microsoft.com/en-gb/troubleshoot/windows-server/remote/0xc000035b-when-you-use-lmcompat...

If you have the same problem, you should find error 0xC000035B in your Exchange event viewer ("An account failed to log on").

[PeterC2]

@Lukas Sassl - similar to above, installed the August Security Update (KB5015321) on all four (2013CU23) Exchange Servers.  After installing it on the third and taking the fourth down for maintenance we get the error when trying to view the on-prem ediscovery cases page:

"Deserialization of type Microsoft.Exchange.Data.PropertyBag+ValuePair blocked due to NotInAllow at location MailboxDataStore"

No cases are shown in the window.

Removing the August Exchange SU from all four servers has resolved the issue, the on-prem ediscovery page now shows all the cases again. 

One side note, we also rolled back the April Exchange SU - do we need to apply both April and August SU to resolve the issue?

Tracking reference number 2208120050001102

[ceantuco]

Hi @Lukas Sassl @Nino Bilic 

We installed the Exchange 2019 CU12 SU update without issues this morning; however, I have a few questions:

1) healthchecker.ps1 flagged 4 Microsoft Exchange certificates that are expiring soon. If I try editing any of those certificates, the pen icon is greyed out. All 4 show 'Assigned to Services = NONE' Should I delete those 4 certificates before running EP script? I recall a few months ago, a SU will cause the host service not to start if there was any expired certificates. The Microsoft Exchange certificate that expires in 2025 has IIS and SMTP assigned. Also, our certificate (blank under name for security reasons) has IMAP, POP, IIS and SMPT services assigned to it.

2) healthchecker.ps1 produced the following results:

TLSVersion ServerEnabled ServerDbD ClientEnabled ClientDbD Configuration
---------- ------------- --------- ------------- --------- -------------
1.0 False True False True Disabled
1.1 False True False True Disabled
1.2 True False True False Enabled

FrameworkVersion SystemDefaultTlsVersionsWow6432NodeSystemDefaultTlsVersionsSchUseStrongCrypto Wow6432NodeSchUseStrongCrypto
---------------- ----------------------------------------------------------------------------- -----------------------------
NETv4 True True False False
NETv2 False False False False

v4.0.30319 SchUseStrongCryptoValue: NULL --- Error: Value should be defined in registry for consistent results.
v4.0.30319 WowSchUseStrongCryptoValue: NULL --- Error: Value should be defined in registry for consistent results.
SecurityProtocol: Tls12

is that mean I have to modify the registry by creating the file below as explained on https://docs.microsoft.com/en-us/Exchange/exchange-tls-configuration?view=exchserver-2019 ?

NET4X-UseSchannelDefaults.reg

is there anything else from that article that I must do before enabling EP?

Your help and guidance is greatly appreciated!

[Lukas Sassl]

@SulzerIT thanks for reporting. We will investigate this.

@VidyaSagarSidda the archiving issue occurs in the following scenario:

Customers using a Retention Policy containing Retention Tags which perform Move to Archive actions should not configure Extended Protection, as enabling Extended Protection will cause automated archiving to stop working. We are actively working to resolve this issue.

See: https://microsoft.github.io/CSS-Exchange/Security/Extended-Protection/#known-issues-and-workarounds 

Do you use Retention Tags with "Move to Archive" actions defined (to automatically move elements to an Exchange archive mailbox)?

[VidyaSagarSidda]

@Lukas Sassl thanks for your clarification. We use retention tag to move items to archive mailbox automatically but we have dedicated mailbox server to host archive enabled users' mailboxes. So if we don't enable EP on that server only and enable in all other servers would help? Is this scenario supported.

[sjhudson]

@Lukas Sassl , @The_Exchange_Team 

Hi Exchange team,

You give the SU the same file name regardless of the CU it relates to.

For example: -

August SU for 2019 CU11 is Exchange2019-KB5015322-x64-en.exe

August SU for 2019 CU12 is Exchange2019-KB5015322-x64-en.exe

So, I always check the file hash of the SU before I install it.

Here is the confusion; the Exchange2019 SU file hashes listed in the KB5015322 don't match the actual file hashes?

I’ve checked the file hash of the files downloaded from the Blog URLs, and the KB5015322 URLs, they don’t match the hash table in KB5015322 (see below)

Am I missing something? I'm using 'Get-FileHash .\Exchange2019-KB5015322-x64-en.exe'

Table from KB5015322 document...

Regards Stephen

[HerrLebkuchen]

We activated Windows Extended Protection on our Exchange 2016 DAG and have now some problems with owa and apple devices. We can login to owa from our PC, Laptops and also from Android Devices. But when we try to open the owa link from an apple device like iPhone, iPad or a Mac, it’s not possible to login. No matter which brower app (safari, firefox, chrome). This problem started right after running the Extended Protection script.
Anyone else with this kind of problem?

[Lukas Sassl]

@sjhudson thanks for reporting this. Indeed, the file hash for August 2022 SU for Exchange 2019 CU12 is wrong. There was an issue with the original update package, and it looks like the hash was not updated correctly. I will take care of it.

Update://

We've updated the hash table. It should show the correct hashes now.

[steveMUTB]

I enabled Extended protection using the script after running the health check script and meeting all of the pre-requisites.

We are running Exchange server 2016 CU23 in a 3 server DAG configuration.

We are now getting connectivity errors in the eventlog for:

MSExchange Availability EventID 4002

Process 18420: ProxyWebRequest CrossSite from S-1-5-21-2056657990-1692598545-328166375-19544 to https://exc01.XXXX.com:444/EWS/Exchange.asmx failed. Caller SIDs: NetworkCredentials. The exception returned is Microsoft.Exchange.InfoWorker.Common.Availability.ProxyWebRequestProcessingException: Proxy web request failed. ---> System.Net.WebException: The remote server returned an error: (401) Unauthorized.
at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
at Microsoft.Exchange.InfoWorker.Common.Availability.Proxy.RestService.EndGetUserPhoto(IAsyncResult asyncResult)
at Microsoft.Exchange.InfoWorker.Common.UserPhotos.UserPhotoApplication.EndProxyWebRequest(ProxyWebRequest proxyWebRequest, QueryList queryList, IService service, IAsyncResult asyncResult)
at Microsoft.Exchange.InfoWorker.Common.Availability.ProxyWebRequest.EndInvoke(IAsyncResult asyncResult)
at Microsoft.Exchange.InfoWorker.Common.Availability.AsyncWebRequest.EndInvokeWithErrorHandling()
--- End of inner exception stack trace ---
. Name of the server where exception originated: EXC02. LID: 43532. Make sure that the Active Directory site/forest that contain the user's mailbox has at least one local Exchange 2010 server running the Availability service. Turn up logging for the Availability service and test basic network connectivity.

This is appearing in the event log of all servers, but I can see availability of rooms and users via Outlook.

We are also getting:

MSExchange CalendarRepairAssistant EventID 24001

The description for Event ID 24001 from source MSExchange CalendarRepairAssistant cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

If the event originated on another computer, the display information had to be saved with the event.

The following information was included with the event:

email address removed for privacy reasons
System.Net.WebException: The request failed with HTTP status 401: Unauthorized.
at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
at Microsoft.Exchange.SoapWebClient.HttpAuthenticator.NetworkServiceHttpAuthenticator.AuthenticateAndExecute[T](CustomSoapHttpClientProtocol client, AuthenticateAndExecuteHandler`1 handler)
at Microsoft.Exchange.SoapWebClient.EWS.ExchangeServiceBinding.FindItem(FindItemType FindItem1)
at Microsoft.Exchange.Infoworker.MeetingValidator.CalendarRemoteParticipant.GetRemoteCalendarItems(List`1 searchItems)
at Microsoft.Exchange.Infoworker.MeetingValidator.CalendarRemoteParticipant.ValidateMeetings(Dictionary`2& organizerRumsSent, Action`1 onItemRepaired)

the message resource is present but the message is not found in the string/message table

Is anyone else experiencing the same?

[Lukas Sassl]

@madeyem we need a few more details about your current setup. I will drop you a PM.

[turigor]

Hello @Nino Bilic  and @Lukas Sassl 

I have question about Windows Authentication state on virtual directories. 

Per table with virtual directories listed in https://microsoft.github.io/CSS-Exchange/Security/Extended-Protection/, some virtual directories should have WEP set to Allow or Required. But some of them does not have Windows Authentication enabled by default (for instance OWA in Default Web Site) while WEP is enhancement of Windows Authentication feature (per https://docs.microsoft.com/en-us/iis/configuration/system.webserver/security/authentication/windowsa...

How Extended protection is supposed to work in this case if Windows Authentication is disabled for such virtual directory? If it is not supposed to work, why documentation lists it as Required/Allow for vdirs without Windows Authentication and why does script enable it?

Thank you! 

[spring8080]

hello , i installed May 2022 security update for my exchange server 2016 without using /PrepareAllDomains command

and now i install August 2022 security update and run /PrepareAllDomains command and it successfully done , but healthchecker still mention that i need to run /PrepareAllDomains :

CVE-2022-21978 Install the May 2022 SU and run /PrepareDomain or /PrepareAllDomains

and also i receive this critical issue in healthchecker report :

pla - Status: Stopped - StartType: Disabled

i found that Performance logs & alerts service is disable so i enable it and i mark the startup type as manual , but also the healthchecker report still mention that pla status is disabled .

Note : i didn't restart the exchange server yet after using /PrepareAllDomains and after enabling the pla service

[spring8080]

along with that , i have this critical issue in my healthchecker report :

v4.0.30319 SchUseStrongCryptoValue           NULL --- Error: Value should be defined in registry for consistent results.

v4.0.30319 WowSchUseStrongCryptoValue   NULL --- Error: Value should be defined in registry for consistent results.

[ceantuco]

Hi@Lukas Sassl @Nino Bilic 

Will you be able to respond my question above posted on Aug 18 2022 at 08:21 AM?

Thank you!

[Tonibert]

@ceantuco & @spring8080 

Take a look at blog page number 3 - the post from @Arngrimur Magnusson and @Lukas Sassl .

There you will find the explanation.

[spring8080]

Hello @Tonibert , thank for you i found the answer for SchUseStrongCryptoValue issue in @Arngrimur Magnusson post .

but what about the pla service disabled and /PrepareAllDomains issues ? 

[JS2022]

I also have the Outlook password prompt problem with both 2016 & 2019 Office (WIndows) versions.

I had to disable EP in some of the virtual directories as Jörg Maletzky did though not as many as he did:

Has anyone found a fix or a workaround for this issue so EP can be configured as recommended? So far I haven't seen this problem even acknowledged by MS Techs here.

TIA

[Lukas Sassl]

@JS2022 can you check if (and if so, which) setting is specified under: HKLM\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel ?

If you force the client to use NTLMv1 instead of NTLMv2 this will lead to password prompts. We will update our documentation to provide more context on this.

[ceantuco]

Hi @Tonibert ,

Thanks for response. How about question #1 about the certificates below?

Please advise
Thank you!

[Jörg Maletzky]

@Lukas Sassl 

Our Exchange servers are configured with HKLM\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel = 4

So all clients are required to use NTLMv2.

Could that be a problem?

Greetings

Jörg Maletzky

[Lukas Sassl]

@Jörg Maletzky can you validate if the value is configured on an affected client as well? If it's not set, we treat it as if it is set to 3 (on Windows Server 2008 R2 OS or later). If it's not set on the client side, please try to set it to at least to 3 (5 is recommended).

[Jörg Maletzky]

@Lukas Sassl 

Not adhoc, but in the long run.

By the way, what is the recommended setting on the client side and on the server side for HKLM\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel? 

[Lukas Sassl]

@Jörg Maletzky the recommended value is 5 which is: 

Send NTLMv2 response only. Refuse LM & NTLM

Client devices use NTLMv2 authentication, and they use NTLMv2 session security if the server supports it. Domain controllers refuse to accept LM and NTLM authentication, and they'll accept only NTLMv2 authentication.

NTLMv1 should be considered as insecure (for example, the cryptography used by it is obsolete) and so no longer used.

More information:

https://support.microsoft.com/topic/security-guidance-for-ntlmv1-and-lm-network-authentication-da216... 

[MS-NLMP]: NTLM v1 Authentication | Microsoft Docs

[MS-NLMP]: NTLM v2 Authentication | Microsoft Docs

To enforce NTLMv2 usage it's required to configure the LmCompatibilityLevel on all clients, servers, and Domain Controllers. However, you should verify that no applications require NTLMv1 anymore before turning it off.

See: Network security LAN Manager authentication level (Windows 10) - Windows security | Microsoft Docs

[Jörg Maletzky]

@Lukas Sassl 

In other words: If we enable Extended Protection (CBT) no Outlook client can use NTLMv1 anymore. Correct?

[Lukas Sassl]

@Jörg Maletzky correct, if the client explicitly does NTLMv1 in the challenge/response to authenticate against Exchange and Extended Protection is enabled, it will fail and the user will see a password prompt. We will add this scenario to the documentation and will update it soon. 

[Jörg Maletzky]

@Lukas Sassl 

Good to know. Thanks for the information!

Greetings

Jörg Maletzky

[JS2022]

@Lukas Sassl 

We have LmCompatibilityLevel = 5 in all domain computers through GPO (Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Network security: LAN Manager authentication level --> "Send NTLMv2 response only. Refuse LM & NTLM")

[Forgemaztah021]

@Lukas Sassl

We are using a single public folder to share contacts/calendars.

At the bottom of the github documentation it says "If you have an environment containing only Exchange 2013 servers with Public Folders,
you can manually remove the SSL flag from the Backend RPC virtual directory to make Public Folders accessible."

question 1: Does this mean that I can leave that Public Folder in place and run the script to enable Extended Protection without it failing?
And then I can just go into IIS and uncheck require SSL for the backend rpc virtual directory? everything will be fine? in terms of public folder issue with exchange 2013

anyone tried? please advise. Thank you.

[Sreejith]

Dear @The_Exchange_Team @Nino Bilic @Lukas Sassl ,

I needed a clarity here do we need to apply Windows Extented Protection script on Hybrid removed Exchange 2019 Server...? For example if we have removed the Hybrid but we are only using the Exchange 2019 server for relaying on prem application emails to EXOL and for managing Exchange resources etc. Also keeping in mind that if we might need to enable Hybrid between EXOL in future it should be possible without any issues.

Awaiting your valuable feedback.

Best Regards,

Sreejith S

[GregecSLO]

Dont know where else to post it, here ppl are listening :)

Happening again:

EVENT LOG CONTENT: MS Filtering Engine Update process was unsuccessful to download the engine update for Microsoft from Primary Update Path.
Update Path:http://amupdatedl.microsoft.com/server/amupdate
UpdateVersion:0
Reason:"There was a catastrophic error while attempting to update the engine. Error: DownloadEngine failed and there are no further update paths available.Engine Id: 1 Engine Name: Microsoft" - (WindowsAppLog)

Please forward to team responsible, thanks!

[DGomez300]

Hello, very basic question here; After the SU is installed, do the servers need to be rebooted, then the extended protection enabled or can the SU be installed and extended protection enabled right after, then reboot the server?

[spring8080]

hello , i restart the exchange server but still the healthreport show 

CVE-2022-21978 Install the May 2022 SU and run /PrepareDomain or /PrepareAllDomains

pla - Status: Stopped - StartType: Disabled

Although the pla service is running and /PrepareAllDomains already done 

Anyone can help me with this

[spring8080]

and also i make already the change in the registry to add the 2  REG_DWORD

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319

SchUseStrongCrypto = 1

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319

SchUseStrongCrypto = 1

and i reboot again the server but again the healthcheker give me these critical errors :

v4.0.30319 SchUseStrongCryptoValue           NULL --- Error: Value should be defined in registry for consistent results.

v4.0.30319 WowSchUseStrongCryptoValue   NULL --- Error: Value should be defined in registry for consistent results.

[Ken_Harrell1145]

Related to enabling Extended Protection. We have some Exchange 2013 serveres with TLS 1.0 enalbed. I know, not great. We also have some Outlook 2010 that was supposed to have TLS 1.0 turned off. How do we make sure there are no TLS 1.0 connections to the Exchange server? SMTP is easy to look for but what about other connections like Outlook (MAPI).  

[Lukas Sassl]

@spring8080 I can't confirm that. I assume there is something wrong with your configuration. Please double check the registry entries. You can copy them from here:

https://docs.microsoft.com/en-us/Exchange/exchange-tls-configuration?view=exchserver-2019#enable-tls... 

@Ken_Harrell1145 it's possible to enable some custom fields in IIS which are related to encryption protocol version and ciphers. This should help you to track the versions in use.

See: New IIS functionality to help identify weak TLS usage - Microsoft Security Blog

[spring8080]

hello , i fix my problem by deleting the xml fil related to healthreport and generate the report again .

but now there is new error :

'UMCallRouter' is in Local Maintenance Mode only

i didn't enable yet the extended protection 

[madeyem]

@Forgemaztah021 

In our Environment (single on-prem Exchange 2013), enabling EP had no consequences on the public folders. No one is actually using them, but we have an old contact list in public folders, and it is still accessible despite having EP turned on. You could just try enabling EP and if public folders no longer work, try the fix shown at the end of the documentation or if nothing helps, just rollback EP (the script itself offers rolling back and creates a backup file before changing anything).

@DGomez300 

In my case (Exchange 2013) no reboot was required after August 2022 SU installation. However, I still rebooted just in case. Regarding Extendended Protection script, no reboots are required.

@spring8080 

Have you done everything like described here?

https://docs.microsoft.com/en-us/Exchange/exchange-tls-configuration?view=exchserver-2019

Maybe also add: "SystemDefaultTlsVersions"=dword:00000001

[spring8080]

Dear @madeyem , about TLS problem all settle now after i generate the healthreport again by deleting the xml file .

my problem is now that this component UMCallRouter not active :

'UMCallRouter' is in Local Maintenance Mode only

Thanks in advance

[Lukas Sassl]

@spring8080 you can set it back to active as described here: Server component state remains Inactive - Exchange | Microsoft Docs

[Lukas Sassl]

@turigor sorry for the delay. Even if Windows Authentication is not enabled, setting Extended Protection to prescribed value is highly recommended. Although when Windows authentication is disabled, Extended Protection will not be used (setting will be ignored). Configuring the Extended Protection setting in the vDir as described in the table ensures Extended Protection will be used just in case Windows Authentication is ever enabled in future.
Another important point to note is that, even for the vDirs where Windows Authentication is disabled by default, enabling Extended Protection is critical as there may be some sub vDirs that have Windows Authentication enabled which should requisite Extended Protection setting. OWA for example makes use of Basic Authentication for its default vDir and most of its sub vDirs. However, there is one OWA sub vDir called "Integrated" which has Windows Authentication enabled by default. Therefore, not enabling Extended Protection can make OWA vDir susceptible to MitM attacks.

[Kuemmerer]

@Lukas Sassl &  @turigor 

will the ExchangeExtendedProtectionManagement script even if for example OWA or ECP VDir WindowsAuthentication is disabled (Default) set the Advanced Settings... to Required or do we have to manually enable Windows Authentication, set Required and then deactivate Windows Authentication again - and how would it look like during the HealthChecker script (TRUE-green)

?

[Lukas Sassl]

@Kuemmerer the script to enable Extended Protection will not change the authentication method. It will only set Extended Protection to the supported configuration (None, Allow or Require --> see table in the documentation) and will configure the SSL flags. It's not required to manually enable Windows Authentication. If Windows Authentication is not enabled, Extended Protection will not be used (setting will be ignored).

[Hap]

After enabling Extended Protection on all our 2016 CU22 servers we found a couple of issues.

1. The statement in the docs @ https://microsoft.github.io/CSS-Exchange/Security/Extended-Protection/#tls-configuration-must-be-con... about SchUseStrongCrypto did not appear to be true. We had SchUseStrongCrypto configured to 0, but this was not considered to be a valid configuration for the script. We had to set this to 1 on all servers before the script would continue.

2. After successfully configuring all servers and verifying operations, we found SCOM throwing multiple errors on probes that were executed. Also Exchange Healthmonitoring was reporting authentication problems to healthmailboxes. Probes unable to authenticate seem to be these 3: OutlookMapiHttpCtpProbe, ComplianceOutlookLogonToArchiveMapiHttpCtpProbe, OutlookRpcCtpProbe

@The_Exchange_Team @Lukas Sassl

[ceantuco]

Hello, 

Will making the required registry changes and not enabling Extended Protection cause issues? 

I would like to make the registry changes and leave the server running for a few days before enabling EP.

Please advise

Thank you

v4.0.30319 SchUseStrongCryptoValue: NULL --- Error: Value should be defined in registry for consistent results.
v4.0.30319 WowSchUseStrongCryptoValue: NULL --- Error: Value should be defined in registry for consistent results.
SecurityProtocol: Tls12

[spring8080]

Dear @Lukas Sassl , thanks it is working now

[Lukas Sassl]

@Hap thanks for reporting this. Indeed, it's strongly recommended to have SchUseStrongCrypto set to 1 (to enforce the usage of strong cryptography) but it should also work if this is set explicitly to 0 (which means weak cryptography like SSL 3 can be used). We will look into this. The monitoring thing is already under investigation.

@ceantuco these settings are TLS best practices and can be made independently of Extended Protection. See: https://docs.microsoft.com/en-us/Exchange/exchange-tls-configuration?view=exchserver-2019 

[ceantuco]

@Lukas Sassl thank you! 

[Sreejith]

Hi @Lukas Sassl ,

I needed a clarity here do we need to apply Windows Extented Protection script on Hybrid removed Exchange 2019 Server...? For example if we have removed the Hybrid but we are only using the Exchange 2019 server for relaying on prem application emails to EXOL and for managing Exchange resources etc. Also keeping in mind that if we might need to enable Hybrid between EXOL in future it should be possible without any issues.

Awaiting your valuable feedback.

Best Regards,

Sree

[Lukas Sassl]

@Sreejith what do you mean by "Hybrid removed Exchange 2019 Server"? Does it mean that you have removed your organization-wide hybrid configuration, and this is the LES (Last Exchange Server) which is still running and relays emails to Exchange Online?