Customer Guidance for Reported Zero-day Vulnerabilities in Microsoft Exchange Server

UPDATE: Microsoft (in a later post) advises against blindly disabling all accounts since this will include all of your administrator accounts.  I was able to re-enable my own and other admin accounts with the previous instructions, all in the same Exchange Management Shell (PowerShell with Exchange Add-Ins) locally on the Exchange Server; but this is not guaranteed.  Worst case, by disabling Remote PowerShell for yourself, you may remove the ability to re-enable it for yourself.  Again, it worked for me, but it is NOT recommended.

Instead, I propose changing your command to exclude yourself from the list of users to disable by filtering with

-and samaccountname -ne "{your admin username}"

Therefore, the first EMS PowerShell command below and the sentence immediately prior have been revised:

Nino_Bilic, I've just completed disabling Remote PowerShell for ALL users, except for my (your) user, with this:

Get-User -ResultSize Unlimited -Filter 'RemotePowerShellEnabled -eq $true -and samaccountname -ne "{your admin username}"' | Set-User -RemotePowerShellEnabled $false

Then I re-enabled Remote PowerShell for individuals who actually need it with this:

Get-User -filter 'samaccountname -eq "{username of user to re-enable}"' | Set-User -RemotePowerShellEnabled $true

For a single user, I receive an access denied error when trying to disable Remote PowerShell, and that user is "MSOL_{randomstring}." 

This user was "created by Microsoft Azure Active Directory Connect with installation identifier {randomstring} running on computer {...} configured to synchronize to tenant {domain}. This account must have directory replication permissions in the local Active Directory and write permission on certain attributes to enable Hybrid Deployment," as indicated in the user's Description.

Do I need to be concerned about this user, necessary for Azure AD Connect?  OR may I disregard?  Please note, this user doesn't have a mailbox, and in fact, doesn't even have a logon name (but, does have a "pre-Windows 2000" logon name).  Also, it's likely this user was created with a strong password during creation/installation of Azure AD Connect.

Therefore, my assumption is that I don't need to be concerned about this user, but again, I'd like to hear it from Microsoft.

Thank you.