An update to the Exchange Server Extended Protection script is now available

When you run the script, do you need to perform an IIS Reset on each Exchange server?

Nino_Bilic 

Many thanks for your answers. Regarding the third question what I seemed to mise that part on the link https://microsoft.github.io/CSS-Exchange/Security/Extended-Protection/ it’s a loot off text and I was probably being to fast when I read through it 😊

Keep up the great work you guys and girls are doing.

Craig_PFE 

Yes, there is information about it on the link, thanks.

I know that using group policy is the best. Our problem is that we are running a hosting company. That means that our clients are not logging in to our active directory with their computers. So, we have a lot of small company with a couple of users that we need to contact and inform off changes that they need to make if there are any issues after the update.

Thanks for the PowerShell command 😊

PeterJoh200 

3. You can find additional documentation here regarding the registry values:

https://aka.ms/ExchangeEPDoc (as Nino_Bilic mentioned)

"If you experience password prompts on your clients once Extended Protection is enabled, you should check the following registry key and value on client and Exchange server side"

One could use this PowerShell command to see if the DWORD is set/exists on computers/servers with 2019 in their name. (red result = does not exist)

You can also use this to look at clients by adjusting the filter.
(Get-ADComputer -Filter 'Name -like "*2019*"').name | %{$_;Invoke-Command -ComputerName $_ {Get-ItemProperty -Path "HKLM:System\CurrentControlSet\Control\Lsa" -Name "LmCompatibilityLevel" | FL }}

Your question of a registry template for the keys: It is recommended to use Group Policy (see link in my comment). But, if one would want to look into updating using the registry it would look like this (Example sets value to 3. Remove -WhatIf after testing). Keep in mind that Group Policy, if set, will change it back to the Group Policy value.
(Get-ADComputer -Filter 'Name -like "*2019*"').name | %{$_;Invoke-Command -ComputerName $_ {Set-ItemProperty -Path "HKLM:System\CurrentControlSet\Control\Lsa" -Name "LmCompatibilityLevel" -Value "3" -Type "DWORD" -WhatIf}}

PeterJoh200 

1. If you install August SUs, the installation part is done. But you must enable Extended Protection manually to be protected against vulnerabilities described in CVEs that were released in August. So no, installation alone is not enough to be protected from all vulnerabilities. When in doubt, run Health Checker script and it will tell you. https://aka.ms/ExchangeHealthChecker 

2. LMCompatibilityLevel needs to be 3 or above, but not after SU installation. This is required for Extended Protection. In other words - you can install August SUs and you will have no issues. However, if LMCompatibilityLevel is less than 3, then clients will have issues connecting to servers where Extended Protection is enabled.

3. Unclear what you mean by this, sorry can you clarify? The LMCompatibilityLevel requirement as far as Extended Protection goes is documented at https://aka.ms/ExchangeEPDoc 

Regarding : August 2022 Exchange Server Security Updates

Dear @The_Exchange_Team @Nino Bilic @Lukas Sassl 

We are a litle confuced here. 

1. Will our Exchange servers not be protected if we install the update and we do not enable Windows Extended Protection?
2. We have clients spread across a couple off contries and when looking at there defult value off  LMCompatibilityLevel its ❤️ (les then 3). Dose the value have to be 3 or greater then 3 for the clents to be able to log on to the exchange server after patching pur Exchange servers?
3. If the value LMCompatibilityLevel needs to be 3 or greater then 2 it would be greatly apriciated if that would be outlined in a KB with templates REG keys.

Updated version is now live.

jhlmb a fix for this is already checked in and will go live with an updated version of the script very soon. Stay tuned

There is an error in the script. It fails with "This script requires to be run inside of Exchange Management Shell. Please run on an Exchange Management Server or an Exchange Server with Exchange Management Shell.". Despite running in an EMS.

[09/16/2022 10:57:33] : Starting Logger Instance 09/16/2022 10:57:33
[09/16/2022 10:57:33] : Calling: Confirm-ExchangeShell
[09/16/2022 10:57:33] : Passed: LoadExchangeShell: True | Identity: XXX
[09/16/2022 10:57:33] : Exchange PowerShell Module already loaded.
[09/16/2022 10:57:33] : WARNING: This script requires to be run inside of Exchange Management Shell. Please run on an Exchange Management Server or an Exchange Server with Exchange Management Shell.

Reason is the check on line 4023, where the object $exchangeShell is checked but not set beforehand.