M365/Exchange Hybrid OAuth Testing command, OAuth-Cert out-of-sync 4001, IIS VDIR OAuth wrong

by butsch 21. June 2023 19:00


Resolve and find OAuth problem in Exchange Hybrid Setup Enviroments


Short Understanding OAuth:

OAuth (Open Authorization) is an industry-standard protocol that enables secure authorization for third-party applications without the need to disclose user credentials. It allows users to grant limited access to their resources on one site to another site, without sharing their credentials. In the context of Exchange and Hybrid setups, OAuth provides a streamlined and secure way for users to access their emails, calendars, and other resources.



Since end 2022 every M365 TENANT has by default cloud side OAuth enabled. There is DAUTH (Older MS own made) and there is

an OPEN Source Authentication method called OAuth.



You may land here if:

a) You just want to test if OAuth works on both sides between Exchange<>M365

b) Or your IIS Virtualdirectory do not accept OAuth beside NTLM etc.

c) If you have done a Self Signed OAuth Cert renew (The one with 2H+ UTC/CET Local time offset delay bug)

We explain how to fix and how to check if both sides have the latest certificate UTC time corrected.

So this KB is on how to TEST OAuth Exchange onpremise<>m365 but also why you came here because maybe it does not work and reports FAILURE not SUCCESS.


First let us check if your Microsoft 365 side has OAUTH enabled?

M365 side: Get-OrganizationConfig | FL oau*


Is Oauth working incoming and outgoing?


Following are detailed steps on how to test OAuth from from both sides in your Exchange <> M365 Hybrid Setup.

We have following users:

User on-premise 

User M365 




Short without any help or explanation:

Test-OAuthConnectivity -Service EWS -TargetUri https://outlook.office365.com/ews/exchange.asmx -Mailbox test.onpremise@schweiz.ch -Verbose | fl

Test-OAuthConnectivity -Service AutoD -TargetUri https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc -Mailbox test.onpremise@schweiz.ch -Verbose | fl

Test-OAuthConnectivity -Service EWS -TargetUri https://outlook.schweiz.ch/ews/metadata/json/1 -Mailbox test.m365@schweiz.ch -Verbose | fl

Test-OAuthConnectivity -Service AutoD -TargetUri https://autodiscover.schweiz.ch/autodiscover/autodiscover.svc -Mailbox test.m365@schweiz.ch -Verbose | fl


Reference for command Test-OAuthConnectivity:


Default value for all TEST outgoing to M365: https://outlook.office365.com/ews/exchange.asmx

Default value for all TEST outgoing to M365: https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc


Test on On-premise > M365 Exchange outgoing direction:

Test-OAuthConnectivity -Service EWS -TargetUri https://outlook.office365.com/ews/exchange.asmx -Mailbox test.onpremise@schweiz.ch -Verbose | fl

Test-OAuthConnectivity -Service AutoD -TargetUri https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc -Mailbox test.onpremise@schweiz.ch -Verbose | fl


If succesfull:


Test M365 > on-premise incoming direction:

Yellow change to what you have in Exchange Virtual Directory:

Retrieve those from your on-premise:

On-premise: Get-WebServicesVirtualDirectory | fl Extern*

Example: https://outlook.schweiz.ch

On-premise: Get-ClientAccessServer | fl autodis*

Example: https://autodiscover.schweiz.ch


Test https://autodiscover.schweiz.ch from external:

Open UP in a web browser from EXTERNAL (Mobily other network) and make sure you can LOGON to the Autodiscover URL with the on-premise account.



Test on M365 side:

Test-OAuthConnectivity -Service EWS -TargetUri https://outlook.schweiz.ch/ews/metadata/json/1 -Mailbox test.m365@schweiz.ch -Verbose | fl

Test-OAuthConnectivity -Service AutoD -TargetUri https://autodiscover.schweiz.ch/autodiscover/autodiscover.svc -Mailbox test.m365@schweiz.ch -Verbose | fl


If succesfull:

Interpreting the Test Results:

After executing the Test-OAuthConnectivity command for both local and Microsoft 365 users, you will receive the test results. Here are a few possible outcomes:



If the test is successful, it means that the OAuth connectivity for the specified user is functioning correctly, and they can access Exchange resources seamlessly.


If the test fails, it indicates an issue with the OAuth connectivity. Check for any misconfigurations in the OAuth configuration, network connectivity problems, or any other relevant errors. Troubleshooting these issues will be crucial to ensure uninterrupted access for the user.


Failure may be because of......


OAuth not Set on VirtualDirectory EWS and AUTODISCOVER on Exchange on-premise


OAuth Set, but experiencing a PULL/REDO issue > FLIP-FLOP effect on IIS VirtualDirectory Settings for EWS and AUTODISCOVER on Exchange on-premise (That what MS says is possible....)


You have renewed the OAuth Certificate on the Exchange on-premise but

Failure due to OAuth Certificate Renewal without completing the final step in the KB



CHECK1: OAuth not Set on VirtualDirectory EWS and AUTODISCOVER on Exchange on-premise


When troubleshooting OAuth-related issues, the first step is to ensure that OAuth is correctly set on the VirtualDirectory configurations for EWS (Exchange Web Services) and Autodiscover in the on-premises Exchange environment. In some cases, OAuth might not be properly configured or enabled on these VirtualDirectories, resulting in authentication failures and connectivity issues.

To address this, it is essential to verify and configure OAuth settings correctly on the EWS and Autodiscover VirtualDirectories, ensuring that the necessary authentication methods are enabled and OAuth is correctly configured.


Check VirtualDirectory on-premise:

Save and run "vdir.sp1" relevant for Exchange<>M365 OAuth

$VirtualDirectories = @()

 $VirtualDirectories += Get-WebServicesVirtualDirectory | Select-Object Name, InternalAuthenticationMethods, ExternalAuthenticationMethods

$VirtualDirectories += Get-AutodiscoverVirtualDirectory | Select-Object Name, InternalAuthenticationMethods, ExternalAuthenticationMethods


foreach ($VirtualDirectory in $VirtualDirectories) {

Write-Host "Virtual Directory Name: $($VirtualDirectory.Name)"

Write-Host "Internal Authentication Methods: $($VirtualDirectory.InternalAuthenticationMethods)"

Write-Host "External Authentication Methods: $($VirtualDirectory.ExternalAuthenticationMethods)"


# Check if OAuth is present in internal authentication methods

if ($VirtualDirectory.InternalAuthenticationMethods -like "*OAuth*") {

$highlightedAuthMethods = $VirtualDirectory.InternalAuthenticationMethods -replace "OAuth", "`e[92mOAuth`e[0m"

Write-Host "OAuth authentication is enabled." -BackgroundColor Green



Does it show OAuth right side?

Or yourself:

Get-AutodiscoverVirtualDirectory | fl *auth*

Get-WebServicesVirtualDirectory | fl *auth*



CHECK2: OAuth Set, but does not PULL > FLIP-FLOP effect IIS VirtualDirectory Settings for EWS and AUTODISCOVER on Exchange on-premise


IF FAILURE: FLIP-FLOP the IIS Virtualdirectory Authentication Settings to be fireproof.

Even if ALL seems fine sometimes their is a FLIP FLOP effect which evn MS can't explain. So turn it OFF and TURN it ON.

Commands to move out the the FLIP/FLOP effect

ONLY READS VALUES | Does not change anything

Get-AutodiscoverVirtualDirectory -Server MYSERVERNAME |Set-AutodiscoverVirtualDirectory -OAuthAuthentication $false

 Get-AutodiscoverVirtualDirectory -Server MYSERVERNAME |Set-AutodiscoverVirtualDirectory -OAuthAuthentication $true

 Get-WebServicesVirtualDirectory -Server MYSERVERNAME |Set-WebServicesVirtualDirectory -OAuthAuthentication $false

 Get-WebServicesVirtualDirectory -Server MYSERVERNAME |Set-WebServicesVirtualDirectory -OAuthAuthentication $true

Cmd.exe elevated


and if you like you can Recycle in IIS the APP Pools with:

Restart-WebAppPool MSExchangeAutodiscoverAppPool
Restart-WebAppPool MSExchangeServicesAppPool


IF you use DAUTH the OLD authentication then the parameter would be:


Question: Can i see OAuth in IIS GUI?

 In the IIS Manager GUI, you cannot directly see the specific OAuth configuration settings for Exchange virtual directories. The GUI does not provide a dedicated section or flag to indicate whether OAuth is enabled for a virtual directory.

 OAuth configuration settings are managed at a higher level in Exchange Server, typically through PowerShell cmdlets or other management tools specific to Exchange. These settings control the OAuth functionality and its integration with Microsoft 365.

 While you can view general authentication settings in the IIS Manager GUI, it does not provide granular visibility into OAuth settings. To get detailed information about OAuth configuration in Exchange Server 2013, it is recommended to use PowerShell cmdlets or consult the Exchange management documentation for accurate and up-to-date information.



CHECK3: You have renewed the OAuth Certificate on the Exchange on-premise but

FAILURE: You did not do the last step in the KB on how to renew OAuth cert, Event 4001 Exchange on-premise

If you have recently renewed the OAuth certificate on your Exchange on-premises server but encounter authentication failures or other issues afterward, it is crucial to ensure that you have completed the final step mentioned in the corresponding knowledge base (KB) article.

Renewing the OAuth certificate involves multiple steps, and failure to follow the complete process can result in incomplete certificate installation or incorrect configuration. By carefully reviewing the KB article and verifying that all required steps, including post-renewal configuration, have been executed, you can avoid common pitfalls and ensure a successful OAuth certificate renewal.



Find out / ICO if you are affected

Event 4001 on Exchange on-premise

The request failed with HTTP status 401: Unauthorized in Event

Missing signing certificate if you do the Test-OAuthConnectivity 





 Autodiscover failed for email address <alani.berseddi@schweiz.mail.onmicrosoft.com>

SMTP:alani.berseddi@schweiz.mail.onmicrosoft.com with error 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.EndInvoke(IAsyncResult asyncResult) at Microsoft.Exchange.SoapWebClient.AutoDiscover.DefaultBinding_Autodiscover.EndGetUserSettings(IAsyncResult asyncResult) at Microsoft.Exchange.InfoWorker.Common.Availability.SoapAutoDiscoverRequest.<>c__DisplayClass4.<EndInvoke>b__3() at Microsoft.Exchange.InfoWorker.Common.Availability.SoapAutoDiscoverRequest.ExecuteAndHandleException(ExecuteAndHandleExceptionDelegate operation). ---> 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.EndInvoke(IAsyncResult asyncResult) at Microsoft.Exchange.SoapWebClient.AutoDiscover.DefaultBinding_Autodiscover.EndGetUserSettings(IAsyncResult asyncResult) at Microsoft.Exchange.InfoWorker.Common.Availability.SoapAutoDiscoverRequest.<>c__DisplayClass4.<EndInvoke>b__3() at Microsoft.Exchange.InfoWorker.Common.Availability.SoapAutoDiscoverRequest.ExecuteAndHandleException(ExecuteAndHandleExceptionDelegate operation) --- End of inner exception stack trace --- . Name of the server where exception originated: exchange2013R17


Cloud to On-premise OAuth certificate missing:

1) Check certificate in AuthConfig in On-Premises Exchange Management Shell:


Test-OAuthConnectivity -Service AutoD -TargetUri <OnPremises Autodiscover.svc
endpoint -https://mail.domain.com/autodiscover/autodiscover.svc> -Mailbox
<Exchange Online Mailbox> -Verbose | fl

it will give you this exception:

Microsoft.Exchange.Security.OAuth.OAuthTokenRequestFailedException: Missing signing certificate. 




Reason OAuth is not working anymore from on-premise > M365 side because OAuth Cert renew done on on-premise

DONE: You have renewed the OAuth Certificate on the Exchange on-premise but the CLOUD side still has the OLD version (You did not do the last step in the KB on how to renew OAuth cert)



Thumbprint Ending: ***62



(Get-AuthConfig).CurrentCertificateThumbprint | Get-ExchangeCertificate | Format-List


 All seems fine, you also waited the 2H+ because of the UTC/CET bug and /owa did not work for that time.

 You done all steps but did not do the purple box? Azure needs to KNOW the new cert now that's the part missing. Not the Exchange Online M365 the Azure Cloud.



When you deploy a new OAuth certificate in a hybrid Exchange environment, it is essential to rerun the Hybrid Configuration Wizard (HCW) to ensure that the cloud side of the environment is aware of the new certificate. The HCW is a tool provided by Microsoft to simplify the configuration of a hybrid deployment between on-premises Exchange and Exchange Online.

 By rerunning the HCW, you allow the wizard to update the necessary settings and configurations, including the OAuth certificate, on both the on-premises Exchange servers and the Exchange Online environment. This ensures seamless communication and authentication between the two environments, enabling features such as cross-premises free/busy lookup and mailbox moves.

 It is important to note that when deploying a new OAuth certificate, running the HCW is a crucial step to ensure proper functionality and synchronization between the on-premises and cloud components of the hybrid Exchange environment.

Solution 1:

 RE-RUN The HCW (Hybrid Configuration Wizard) wizard on Exchange with existing settings as quick fix.


Solution 2: (Very technical)

 This is the step you did read but it's only for 2007/2010 and mix with newer Exchange and M365 so you did not read.



So normal you ONLY need to do this IF you have 2007/2010 in MIXED mode with 2013/2016 and M365 or if you have DONE the OAuth Cert renew on a 2013/2016/2019 on-premise.

 Follow the manual steps as you when your create an Organisation Trust between two companys Exchange related.


For the OAuth Cert renew Steps 3 and 4 are relevant. This will upload the inhouse OAuth Certificate to Azure. As per 21.06.2023 those are:

 Step 3: Export the on-premises authorization certificate

 Step 4: Upload the on-premises authorization certificate to Azure Active Directory Access Control Service (ACS) 



Check IF Azure HAS your RE-done(latest) OAuth Exchange Certificate active


Azure side:

Connect to Azure from the machine where have acccess to Azure or the Exchange with the HCW Wizard.

Connect-MsolService (Logon with your Tenant or Admin account)

Get-MsolServicePrincipalCredential -AppPrincipalId 00000002-0000-0ff1-ce00-000000000000 -ReturnKeyValues $true


Note the StartDate and Enddate from the latest you made.


Get-ExchangeCertificate (Get-AuthConfig).CurrentCertificateThumbprint |fl Not*

Or CHECK below Script to get the time in UTC direct on-premise

 Attention Local Time Zone and Azure Time Zone are different. Remember when you did renew the OAuth cert

It took 2 or 4 hours to get active (OWA and PS was not wokting if so...)

On-premise Local Time Swiss

M365 side

NotAfter : 12.06.2028 13:39:54

NotBefore : 12.06.2023 13:39:54

StartDate : 12.06.2023 11:39:54

EndDate : 12.06.2028 11:39:54

On-premise Convertes to UTC USA Azure 

NotAfter : 12.06.2028 11:39:54

NotBefore : 12.06.2023 11:39:54


Now hopefully, when doing the renew of the OAuth cert onpremise, you did not start 10 times.


YOU = Local Time Zone +/- 2-4hrs or whatever

Use below script to get the time as it looks with azure


Get the TIMES from local OPAUTH Cert in all time zones relevant

ONLY READS VALUE | Does not change anything

# V1.0, 18.06.2023, www.butsch.ch

# Get the TIMES from local OPAUTH Cert in all time zones relevant


$certThumbprint = (Get-AuthConfig).CurrentCertificateThumbprint

$cert = Get-ExchangeCertificate -Thumbprint $certThumbprint


$localTimeZone = [System.TimeZoneInfo]::Local

$utcTimeZone = [System.TimeZoneInfo]::Utc


$cert | Select-Object -Property NotBefore, NotAfter, `

@{Name="LocalNotBefore"; Expression={$_.NotBefore.ToLocalTime().ToString()}}, `

@{Name="LocalNotAfter"; Expression={$_.NotAfter.ToLocalTime().ToString()}}, `

@{Name="UTCNotBefore"; Expression={$_.NotBefore.ToUniversalTime().ToString()}}, `

@{Name="UTCNotAfter"; Expression={$_.NotAfter.ToUniversalTime().ToString()}}, `

@{Name="LocalTimeZone"; Expression={$localTimeZone.DisplayName}}, `

@{Name="UTCTimeZone"; Expression={$utcTimeZone.DisplayName}} 


Re-check all as explained in:




FAILURE, 401 Access Denied: You don't not have all internal URL from your Exchange listed with AZURE as SPN

(He will accept only those address which the Cloud has SPN listed to easy explain)



On-premise: Check the OnPremisesDiscoveryEndPoint and OnPremisesWebServiceEndPoint from:

Get-IntraOrganizationConfiguration | Fl

On-premise: Should be the same as per:

Get-WebServicesVirtualDirectory | FL ExternalUrl


Check Azure side:

Connect to Azure from the machine where have acccess to Azure or the Exchange with the HCW Wizard.

Connect-MsolService (Logon with your Tenant or Admin account)

(Get-MsolServicePrincipal -ServicePrincipalName "00000002-0000-0ff1-ce00-000000000000").ServicePrincipalNames

Check that ALL URL which you have on-premise are listed also there.






And any further DOMAINS you may have on your on-premise Exchange Domains .EU .DE .COM don't forget those.


External Links mentioned:




Microsoft Azure Active Directory OAuth 2.0 Fundamentals:



Deprecation of Basic Authentication in Exchange Online:



Test-OAuthConnectivity PowerShell cmdlet:



Troubleshooting OAuth Expiration in Exchange:



Configuring OAuth Authentication in Exchange 2013:




M365/AZURE | Microsoft Exchange | Exchange 2013 | Exchange 2016 | Exchange 2019

Active Directory accounts with ADMINSholder/adminCount flag | No syncback from Azure, ms-ds-consistencyGuid

by butsch 14. June 2023 22:00

Management summary, english

The synchronization process of the Synchronization Service Manager (Microsoft Azure AD Connect Synchronization Services) does not transfer the attribute WP;ms-ds-consistencyGuid from Azure back to the Local Active Directory. This issue arises when a regular user in the local domain environment has the ADMINSholder/adminCount flags set to 1/true, which is intentionally implemented to protect sensitive Windows accounts from being inadvertently modified. It is essential to remove this flag when it is no longer necessary or remove the user from the corresponding groups to ensure proper functionality with ActiveSync, GPO, and Azure/M365. To gain a better understanding of the ADMINSholder/adminCount attribute, we recommend referring to the provided blog posts, which shed light on the impact of this flag, particularly regarding ActiveSync and GPO.


Management summary, deutsch

Der Synchronisationsprozess des Synchronisation Service Managers (Microsoft Azure AD Connect Synchronization Services) überträgt das Attribut WP;ms-ds-consistencyGuid nicht von Azure zurück zum lokalen Active Directory. Dieses Problem tritt auf, wenn ein normaler Benutzer in der lokalen Domänenumgebung die ADMINSholder/adminCount-Flags auf 1/true gesetzt hat, was absichtlich erfolgt, um zu verhindern, dass sensible Windows-Konten versehentlich geändert werden. Es ist wichtig, dieses Flag zu entfernen, wenn es nicht mehr benötigt wird, oder den Benutzer aus den entsprechenden Gruppen zu entfernen, um eine ordnungsgemäße Funktionalität mit ActiveSync, GPO und Azure/M365 zu gewährleisten. Um ein besseres Verständnis für das ADMINSholder/adminCount-Attribut zu erlangen, empfehlen wir die Lektüre der bereitgestellten Blog-Beiträge, die Informationen über die Auswirkungen dieses Flags, insbesondere in Bezug auf ActiveSync und GPO, liefern.


What is this about keywords: M365, ADMINSholder/adminCount, Synchronization by Azure AD Connect, ImmutableId, WP;ms-ds-consistencyGuid

Event: ADSYNC, 6100

Error in Synchronisation Service Manager: Insufficient access rights to perform the operation, 8344, permission-issue


Synchronisation Service Manager (Microsoft Azure AD Connect Synchronization Services) does not sync the attribute WP;ms-ds-consistencyGuid Back from Azure to Local Active Directory.

This is because a local normal employee user has the ADMINSholder/adminCount flags set to 1/true. (Which is not good in Domain Enviroments)

This is by purpose to protect sensitive Windows account of been written wrong by error.

When a user has been temporarily part of the "Local Admin group" or a member of specific ADS groups like Print Operator or Backup Operators, they receive a special FLAG (ADMINSholder/adminCount=1). The objective is to remove this flag if it is no longer necessary or remove the user from those groups altogether. If not done these accounts may encounter limitations when it comes to functionality with ActiveSync, GPO, and Azure/M365.

If you would like to gain a better understanding of what ADMINSholder/adminCount entails, we recommend reading our informative blog posts. They provide insights into the impact of this flag, especially concerning ActiveSync and GPO. Here are the steps to remove the flag:




Please be aware that ADMINSholder Attribute is here to PROTECT sensitive accounts like ADMINISTRATOR, Service, IIS-accounts and resets or overwrites them every 15 minutes to prevent catastrophic impact of wrong GPO/Policies or Powershell commands who manipulate such accounts.


Microsoft describes it like this related to Azure sync

"Users with administrative roles in Azure AD will bypass matching.


"To prevent unaccounted for account takeover of roles with privilege assignment, any user object that has an admin role assigned in AAD will be bypassed for matching.

Speaking of administrative roles and synchronization in general, highly privileged user accounts should be separated out from regular user accounts"


Here is Powershell sample to find the users under your ROOT ADS with excluding certain OU Llike deactivated or service:

Get-ADUser -Filter {admincount -gt 0} -Properties adminCount -ResultSetSize $null -SearchBase "DC=yourdomain,DC=local" | Where-Object { $_.DistinguishedName -notlike "*OU=Benutzer_deaktiviert*" -and $_.DistinguishedName -notlike "*OU=SERVICE_users_IT*" -and $_.DistinguishedName -notlike "*CN=Users,DC=yourdomain,DC=local" } | Format-List DistinguishedName, Enabled, SamAccountName

Change the yellow field to your enviroment or what your OU-folders contain.

This will provide you with a list of on-premises users who have the ADMINSholder FLAG set and will not synchronize back from Azure/M365 to your local Active Directory.

This is because Microsoft wants to protect those special accounts. (AdminSholder refers to a special account.)

Synchronisation Service Manager, Microsoft Azure AD Connect Synchronization Services

Event, ADSYNC, 6100,

The error (Or not because it helps you to find error on-premise and protects you from mistakes) as you see it


There is a user named CLAUDIO whose ms-ds-consistencyGuid value does not sync back from Azure to the Local Active Directory.

This synchronization failure is due to the Sync tool recognizing that the local user has the ADMINSHolder/Admincount FLAG set to 1 (true). As a result, the synchronization process does not update the value in the Local Active Directory.






Primary goal would be to FIX those accounts who are regular users and have the ADMINSolder/admount=1 flag set. You can do this manual:



Or you use a scripted solution. Be carefull you don't touch any service accounts my mistake.

C7Solutions has an excellent write up of the issue and also scripts with which you can modify the permission.


Also Microsoft has some good Blogs posts:



 DEUTSCH / Translation

Worum geht es bei den Schlüsselwörtern: M365, ADMINSholder/adminCount, Synchronisation durch Azure AD Connect, ImmutableId, WP;ms-ds-consistencyGuid?


Ereignis: ADSYNC, 6100

Fehler im Synchronisations-Service-Manager: Unzureichende Zugriffsrechte, um die Operation auszuführen, 8344, Berechtigungsproblem.



Der Synchronisations-Service-Manager (Microsoft Azure AD Connect Synchronization Services) synchronisiert das Attribut WP;ms-ds-consistencyGuid nicht von Azure zurück zum lokalen Active Directory.


Dies liegt daran, dass ein lokaler normaler Mitarbeiterbenutzer die ADMINSholder/adminCount-Flags auf 1/true gesetzt hat. (Was in Domänenumgebungen nicht gut ist)

Dies dient dazu, sensible Windows-Konten davor zu schützen, durch Fehler falsch geschrieben zu werden.


Wenn ein Benutzer vorübergehend Teil der "Lokalen Administratorengruppe" oder Mitglied bestimmter ADS-Gruppen wie "Druckoperator" oder "Backup-Betreiber" war, erhält er ein spezielles FLAG (ADMINSholder/adminCount=1). Das Ziel besteht darin, dieses Flag zu entfernen, wenn es nicht mehr benötigt wird, oder den Benutzer vollständig aus diesen Gruppen zu entfernen. Wenn dies nicht erfolgt, können diese Konten Einschränkungen bei der Funktionalität von ActiveSync, GPO und Azure/M365 erfahren.

Wenn Sie ein besseres Verständnis dafür erhalten möchten, was ADMINSholder/adminCount bedeutet, empfehlen wir Ihnen, unsere informativen Blog-Beiträge zu lesen. Sie bieten Einblicke in die Auswirkungen dieses Flags, insbesondere in Bezug auf ActiveSync und GPO. Hier sind die Schritte, um das Flag zu entfernen:




 Bitte beachten Sie, dass das ADMINSholder-Attribut dazu dient, sensible Konten wie ADMINISTRATOR, Service und IIS-Konten zu SCHÜTZEN und sie alle 15 Minuten zurückzusetzen oder zu überschreiben, um katastrophale Auswirkungen falscher GPOs, Richtlinien oder Powershell-Befehle zu verhindern, die solche Konten manipulieren.

 Microsoft beschreibt es im Zusammenhang mit der Azure-Synchronisation wie folgt:

 "Benutzer mit administrativen Rollen in Azure AD werden bei der Abgleichung übersprungen.


"Um unkontrollierten Account-Takeover bei Rollen mit Privilegienzuweisung zu verhindern, wird jeder Benutzerobjekt, dem in AAD eine Administratorrolle zugewiesen ist, bei der Abgleichung übersprungen. In Bezug auf administrative Rollen und die Synchronisation sollten hochprivilegierte Benutzerkonten von normalen Benutzerkonten getrennt werden."


Hier ist ein PowerShell-Beispiel, um Benutzer unter Ihrem ROOT ADS zu finden und bestimmte Organisationseinheiten wie deaktivierte oder Dienst-OU auszuschließen (Siehe oben englischer Text)


Ändern Sie das gelbe Feld entsprechend Ihrer Umgebung oder dem Inhalt Ihrer OU-Ordner. Dies liefert Ihnen eine Liste der lokalen Benutzer, bei denen das ADMINSholder-FLAG gesetzt ist und die nicht von Azure/M365 zurück zum lokalen Active Directory synchronisiert werden. Dies geschieht, um diese speziellen Konten zu schützen. (AdminSholder bezieht sich auf ein spezielles Konto.)


Synchronisations-Service-Manager, Microsoft Azure AD Connect Synchronization Services

 Ereignis, ADSYNC, 6100

Der Fehler (oder nicht, da er Ihnen hilft, Fehler lokal zu finden und vor Fehlern zu schützen), wie Sie ihn sehen.

 Es gibt einen Benutzer namens CLAUDIO, bei dem der Wert ms-ds-consistencyGuid nicht von Azure zum lokalen Active Directory zurück synchronisiert wird. Dieser Synchronisationsfehler tritt auf, da das Sync-Tool erkennt, dass der lokale Benutzer das ADMINSHolder/Admincount-FLAG auf 1 (true) gesetzt hat. Infolgedessen wird der Wert im lokalen Active Directory nicht aktualisiert.


Microsoft Server OS | Microsoft Exchange | Exchange 2013 | Exchange 2016 | Exchange 2019 | M365/AZURE

M365, Exchange Online Remote Powershell blocked by T1056 Mitre Trellix

by butsch 4. April 2023 03:00

Trellix ENS 10.X, T1056 - Key capture using Powershell detected, Host intrusion buffer overflow

ExP:Illegal API Use Blocked an attempt to exploit




If you want to manage M365, Exchange Online there are several ways. You can use the PS button within the Admin Portal but then you need an Azure licence for a seperate account you made for IT.

We also tried the Remote shell to M365 on Several Server and working clients and found some important fact.

Most Antivirus Solution who do more than other and who reflect MITRE rules capture the Connection as phising attack for credentials as defined in MITRE T1056, Keylogger. Yo you will have to exclude the machines where IT people use Remote shell and ASK for credentials with the POPUP GUI (Not passing the password in the cli command)



Install-Module -Name ExchangeOnlineManagement –Force



You can find and also exclude the API function call in Trellix EPO like this. I would like to state that you should only exclude the T1056 on machines where the Exchange Admin will work.

Select the EXPLOIT, checkbox, then bottom page left side, ADD Exclusion


Choose the POLICY you have for your Clients you want to change the single false

Again best would be NOT to exclude that MITRE for all enduser just for the IT machines.

Since Mcafee/Trellix ENS you can do POLICIES for all (Great range) and than add. to that more

fine granular policies for some machines or targets (Like we know from Windows gpo with WMI filter)


Threat Target Process Name:    POWERSHELL.EXE


Event Category:    Host intrusion buffer overflow

Event ID:    18054

Threat Severity:    Critical

Threat Name:    ExP:Illegal API Use

Threat Type:    Exploit Prevention

Action Taken:    Blocked

Threat Handled:    True

Analyzer Detection Method:    Exploit Prevention


Module Name:    Threat Prevention

Analyzer Technology Version:    

Analyzer Content Creation Date:    3/6/23 10:06:04 PM CET

Analyzer Content Version:

AMCore Content Version:    

Analyzer Rule ID:    6183

Analyzer Rule Name:    T1056 - Key capture using Powershell detected


If you want to disable the 6183 Analyzer rule complete you could do here in your POLICY.

To see you have to choose "OTHERS". By default maybe this rule is not ON in your mcafee/Trellix enviroment. (Out of the box)


After the change the Connection should work:



Exchange 2013 | Exchange 2016 | Exchange 2019 | M365/AZURE | SECURITY | Mcafee ENS, EPO, DLP, TIE, ATD, VSE, MSME

CVE-2023-23397, Outlook.exe Exploit, PidLIDReminder custom Sound ab SMB für Termin Reminder

by butsch 15. March 2023 03:00

CVE-2023-23397 Was ausgenutz wird:

Anstatt Standard Microsoft Outlook Sound kann man für ein meeting reminder einen Custom Sound angeben. Dieser kann auf einem Share liegen. Da liegt der Hund begraben.



CVE-2023-23397 ist ein Outlook-Bug. Wenn Sie eine eingehende E-Mail für einen Termin mit einer benutzerdefinierten Erinnerung (Ton, Attribut PidLIDReminder) senden, wird Outlook.exe (2012/2016) versuchen, die Sounddatei über SMB abzurufen, sogar von einem externen Share (ohne Berücksichtigung von Sites-Zonen in IE/EDGE/System). Wenn Port 445 zu diesem Ziel geöffnet ist, sendet das System einen NTLM-Hash außerhalb Ihres Netzwerks. Wie wir verstanden haben, können die meisten vorhandenen AV-Lösungen für On-Premise-Exchange derzeit dieses Attribut PidLIDReminder nicht scannen (Trend, Trellix Security für Exchange). Deshalb hat das MS Exchange-Team das Skript bereitgestellt.

Hier kann man für einen TERMIN einen Custom Sound angeben.

Z.B. Alarm "\\\attacker_ldap_scanner_hash\M365_Ausfall_Nichts_geht_mehr_alle_user_Ferien.wav"



besteht darin, das Outlook.exe-Patch zu installieren und die Clients neu zu starten, und auch sicherzustellen, dass Kunden kein SMB für externe Verbindungen öffnen. Dies ist in der Regel ab Client VLAN > WAN geschlossen. Heikel sind Home office, Remote worker welche je nach SPLIT VPN halt 445/SMB offen hätten.


Patches for Outlook 2013/2016:


2016 Direct download

https://www.catalog.update.microsoft.com/Search.aspx?q=outlook%202016 (All Outlook 2016 Patches, pick the ones from 14.03.2023)

https://catalog.s.download.windowsupdate.com/c/msdownload/update/software/secu/2023/02/outlook-x-none_a3461e8b8424793e267728be32cd83c294ebb897.cab (32BIT)

https://catalog.s.download.windowsupdate.com/c/msdownload/update/software/secu/2023/02/outlook-x-none_8d949e375d119c72a375435cd77a4797fb2e0b2b.cab (64BIT)

2013 Direct download

https://www.catalog.update.microsoft.com/Search.aspx?q=outlook%202013 (All Outlook 2013 Patches, pick the ones from 14.03.2023)

https://catalog.s.download.windowsupdate.com/c/msdownload/update/software/secu/2023/02/outlook-x-none_2cb1193a28972b39546f59d104ae5be489c01d8d.cab (64BIT)

https://catalog.s.download.windowsupdate.com/c/msdownload/update/software/secu/2023/02/outlook-x-none_2e7b2f55dcab1fd7d3b00aa1dbd2545fb90e435c.cab (32BIT)


Manuelle Installation. Auspacken der CAB files und DANN Doppelclick auf .MSP Patch file


Deployment ausserhalb WSUS, für die .CAB Files so kann man diese comnmandline installieren:

DISM.EXE für die Office CAB Files scheint nicht zu gehen.

Man kann aber das File aufmachen und dann einfach das MSP File installieren. Windows Installer sucht und findet den Rest. Z.B. die Quelle des Office Files.

msiexec /p c:\edv\ C:\edv\outlook-x-none_a3461e8b8424793e267728be32cd83c294ebb897\outlook-x-none.msp /qb

msiexec /p c:\edv\ C:\edv\outlook-x-none_a3461e8b8424793e267728be32cd83c294ebb897\outlook-x-none.msp /qn




DISM.EXE für die Office CAB Files scheint nicht zu gehen.


dism /Online /Add-Package /PackagePath:"c:\edv\outlook-x-none_a3461e8b8424793e267728be32cd83c294ebb897.cab"

Je nach System gibt dies ein Fehler weil er das darunter notwendige CBS Paket nicht hat:

Failed to get the underlying CBS package. - CDISMPackageManager::OpenPackageByPath(hr:0x80070002)

In der Regel bei anderen CAB Packages sind diese dann mit dabei im CAB/Archiv hier nicht z.B. bei Outlook 2016 auf W11 22H2

Beispiel file dabei von 202X. Da musste man zuerst das SSU installieren und dann den Patch mit DISM.

Bei den jetzigen Outlook Patch aber nur ein MSP mit dabei


023-03-16 10:46:42, Info DISM DISM Package Manager: PID=18624 TID=15128 Processing the top level command token(add-package). - CPackageManagerCLIHandler::Private_ValidateCmdLine

2023-03-16 10:46:42, Info DISM DISM Package Manager: PID=18624 TID=15128 Attempting to route to appropriate command handler. - CPackageManagerCLIHandler::ExecuteCmdLine

2023-03-16 10:46:42, Info DISM DISM Package Manager: PID=18624 TID=15128 Routing the command... - CPackageManagerCLIHandler::ExecuteCmdLine

2023-03-16 10:46:42, Info DISM DISM Package Manager: PID=18624 TID=15128 Encountered the option "packagepath" with value "c:\edv\outlook-x-none_a3461e8b8424793e267728be32cd83c294ebb897.cab" - CPackageManagerCLIHandler::Private_GetPackagesFromCommandLine

2023-03-16 10:46:42, Error DISM DISM Package Manager: PID=18624 TID=15128 Failed opening package. - CDISMPackageManager::Internal_CreatePackageByPath(hr:0x80070002)

2023-03-16 10:46:42, Error DISM DISM Package Manager: PID=18624 TID=15128 Failed to get the underlying CBS package. - CDISMPackageManager::OpenPackageByPath(hr:0x80070002)

2023-03-16 10:46:42, Error DISM DISM Package Manager: PID=18624 TID=15128 Failed to open the package at location: "c:\edv\outlook-x-none_a3461e8b8424793e267728be32cd83c294ebb897.cab" - CPackageManagerCLIHandler::ProcessPackagePath(hr:0x80070002)

2023-03-16 10:46:42, Error DISM DISM Package Manager: PID=18624 TID=15128 Failed to get the count of packages from the command line. - CPackageManagerCLIHandler::ProcessCmdLine_AddPackage(hr:0x80070002)

2023-03-16 10:46:42, Error DISM DISM Package Manager: PID=18624 TID=15128 Failed while processing command add-package. - CPackageManagerCLIHandler::ExecuteCmdLine(hr:0x80070002)

2023-03-16 10:46:42, Info DISM DISM Package Manager: PID=18624 TID=15128 Further logs for online package and feature related operations can be found at %WINDIR%\logs\CBS\cbs.log - CPackageManagerCLIHandler::ExecuteCmdLine

2023-03-16 10:46:42, Error DISM DISM.EXE: DISM Package Manager processed the command line but failed. HRESULT=80070002


The Patch info from WSUS.



Ist FORENSIC, um herauszufinden, ob Sie solche E-Mails erhalten haben und hoffentlich verhindern, dass sie an Outlook.exe geliefert werden. Sie können auch diejenigen reparieren, die bereits angekommen sind. Wenn Sie On-Premise sind, überprüfen Sie, ob Ihre Exchange-AV-Lösung nach dem Attribut suchen kann (An sich ahte die AV Loesung fuer Exchange alle Rechte welche man extra für das laufen lassen des Scripts vergeben muss die Frage ist nur OB Sie mit der aktuellen version das Attribut finden)


Wichitg für PRIO 2 SKRIPT: Wir empfehlen dies nur für Personen, die Erfahrung mit solchen Befehlen haben, z. B. durch Integration einer Archivlösung oder einer mobilen Geräteverwaltungslösung (MDM). Möglicherweise müssen Sie auch mit Ihrem hausinternen Rechts- / Compliance-Team Rücksprache halten, da Sie jemandem vollen Zugriff auf die E-Mails Ihres CEO und Vorstands gewähren, soweit ich verstanden habe (ich habe das Skript nicht im Detail überprüft).



Das Skirpt macht folgendens:

  • Generieren Sie eine unbegrenzte (vollständige) Throttle-Richtlinie für eine Gruppe oder einen Benutzer (wie ein MDM-Masterkonto oder ein Konto, das eine rechtliche Archivlösung speist).
  • Generieren Sie eine Regel, damit ein Benutzer vollen Zugriff auf jede E-Mail, jeden Kalendereintrag usw. hat, die in der Exchange-Umgebung gespeichert sind (Application Impersonation / https://learn.microsoft.com/en-us/exchange/client-developer/exchange-web-services/impersonation-and-...).
  • Scannen Sie alle E-Mails oder zumindest einige Tage rückwärts, da die Ukraine im 03/2022 angegriffen wurde, also für ein Jahr? Oder war diese Information falsch? Microsoft sagt hier das man besonders attratkive Targets scannen sollte (Wer sollen diese sein? Der CEO/VR oder nur der User?)


Handlungsbedarf 16.03.2023

Patch installieren und sicher stellen, dass alle den Reboot gemacht haben

Sicher stellen dass Port 445/SMB nach LAN>WAN geschlossen ist (Eventuell anpassen Remote Worker Firewall GPO/Policy oder dann via FW-Module z.B. vom Virenschutz, z.B. Mcafee ENS Firewall)

Die derzeit kursierenden PowerShell-Skripte sind ausschließlich für forensische Zwecke und die Suche nach Indicators of Compromise gedacht. Diese Skripte erfordern jedoch vorsichtiges Handling, da der Skript-User mit vollem Zugriff auf alle Ressourcen ausgestattet werden muss, einschließlich der Möglichkeit, die Geschwindigkeit des Skripts zu regulieren. Bitte führen Sie das Skript daher nicht aus, bis wir sicherstellen können, dass es nicht zu Problemen aufgrund von Sprachbarrieren kommt.

Es ist wichtig zu beachten, dass das PowerShell-Skript nicht notwendig ist, um die Outlook.exe-Sicherheitslücke zu schließen. Es dient ausschließlich der forensischen Untersuchung und dem Ersatz von 1-2% der Kalendereinträge, die aufgrund von Offline-Verbindungen noch nicht aktualisiert wurden. Es ist jedoch unwahrscheinlich, dass diese Skripte erforderlich sind, da die erste Welle des Angriffs durch eine E-Mail mit einem blockierten Anhang (.MSI) erfolgte.

Schließlich ist es wichtig zu betonen, dass der Exchange Patch vom März 2023 keine Auswirkungen auf die Outlook.exe-Sicherheitslücke hat.


Bild: Quelle ACEResponder/Twitter

Bild: Quelle MS, Learn

Guter Blog:

https://practical365.com/cve-2023-23397-ntlm-vulnerability/ (Nicht die Quelle der Info)



Hotfixes / Updates | Exchange 2010 | Exchange 2013 | Exchange 2016 | Exchange 2019 | M365/AZURE | SECURITY | SPAM Fortimail

M365/Hybrid Exchange Setup: Steps to verify on-premise, Prepare for Directory Synchronization (IDFIX, UPN, Proxyaddress)

by butsch 3. February 2023 02:00

TIP: Cleanup everything LOCAL before you even think of moving anything to M365 or Azure or even starting the Connector

PRO TIP: Full manual list of Objects/attribute to check on your local ADS in this blog.


This blog entry is mainly about those two steps of the MS Technet: https://learn.microsoft.com/en-us/microsoft-365/enterprise/prepare-for-directory-synchronization?view=o365-worldwide

  1. Directory Clean-up Tasks
  2. Directory object and attribute preparation

which are often just skipped because people think all is fine because they logon to their client an IT runs. Normally the things we talk about here are checked and cleaned with any serious IT-Service company who migrated something in direction of LDAP/Windows Domain Controller/Active Directory or Exchange inhouse.

But time may have passed since then so it's time to check again like the OnPremise migrations and one of the reasons why it's was a little more expensive inhouse. However, daily business shows that it's the same related to cloud. The difference is just that people who never really done such complex things inhouse now think all the problems are gone.


This is a collection of things we noticed during some test and inspection of logs and dumps from existing migrations.


As with Exchange 2 Exchange Onpremise or with Active Directory Domain Controller Migrations. It is recommended to clean-up the source that means your existing environment as clean as possible.

You do not want to run into errors during the sync or setup. Prevent it, think ahead, and do not be too naive. Problems want go away just because you move everything to the cloud that were there before.

All the things that are wrong come up with a migration even if things worked before and you lived with it.



MS describes it in a clear warning on most of their pages somewhere. In addition, as always on Technet if something is mentioned with a "!" in that form read it.

Like if, you remove last Hybrid in Onpremise and you remove the Exchange ORG. You do not ready no E-Mail next day for the cleaners who wanted to make all proper and nothing in the server room!


But maybe someone who migrated you last on-premise to on-premise fixed those for you already? Mainly most of these did happen in an environment, which have grown over the years from NT/2000/2003/2008/2016 etc.

So if someone cleaned already you may have an easy ride and even do not understand what those Exchange Experts done all the time because it was so easy now for you as cloud Manager. Forums are full with those it happens in Azure/M365 too ;-)


 Some things we did see: and to check:

  • Things like special Chars somewhere where they not should be like "\ < > ( ) ; , [ ] [ \ " | , / : < > + = ; ? * '] > IN: sAMAccountName or userPrincipalName
  • Too many groups in other groups or user in too many groups (Everything is possible in Enterprise with Academic naming convention and strategy)


  • User get's it done to get a special Category Color in Public Folders events? Yes possible and failure did happen.



Then there are points which may have been changed after the last person did a serious Exchange<>Exchange inhouse migration otherwise they would not be there.


PROXYADDRESSES > those get built by Exchange itself and are not relevant inhouse except for routing in ENT until mig or now

For their DFB-11 DE, EMEA Region ;-)

Stop using ö, ä, ü in IT identifiers we tell you since 30 years. Let them Mary and change the name it's cheaper! Or just don't use them.

Every 5 years there is a technology, which does not swallow UMLAUT it and that fails because of it.

Your Smartcard to enter the last ship, which will fly to Mars, will fail because you have müller on it instead of mueller



All other steps please reference the MS KB. We just wanted to highlight something, which should NOT be there. If you find ANY

Of those mentioned above, we recommend checking all other points VERY carefully. Find as much info as you can about the pre checks.


No Easy Solution?

  • There are many scripts around from ADS/DC and Exchange Migrations to check these things
  • CLOUD MANAGER: Also below see the IDFIX which may help with some errors.
  • PRO: Check the list below we made "Manual Reference Butsch what to check on on-premise enviroment before you start any Hybrid M365/Azure project, collected from different sources 02.02.2023"


Be careful with script that also Change things in same step. Best is a script which checks and reports and then has an option to change and also logs.

Also do not be Junior System Powershell-just-back-from-education and just run it first thing you find on google without a backup before?

  1. Check the regular Backup before you touch (Really do it open the console view the job or let the Backup Admin show you): Acronis, NetB, BEXEC, veeeam, and for Windows Domain just a regaultr Windows Backup so Tier3 MS will support it!
  2. Make an LDAP Export of ADS just as second backup (Example: ldifde -f C:\edv\export.ldf -d "CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=ch" -p subtree)


Believe us:



MS Links in general to that:


AD DS Preparation

To help ensure a seamless transition to Microsoft 365 by using synchronization, you must prepare your AD DS forest before you begin your Microsoft 365 directory synchronization deployment.

Your directory preparation should focus on the following tasks:


  • Remove duplicate proxyAddress and userPrincipalName attributes
  • Update blank and invalid userPrincipalName attributes with valid userPrincipalName attributes

Remove invalid and questionable characters in the givenName, surname ( sn ), sAMAccountName, displayName, mail, proxyAddresses, mailNickname, and userPrincipalName attributes. For details about preparing attributes, see List of attributes that are synced by the Azure Active Directory Sync Tool.


 PITFALLS: The TOP or First Level Domain of the FQDN of your Active Directory has to Routable in Internet


If you Windows Active Directory Domain is like it was learned correct in 1999 then i will end as .local as best practice.

What is what if you did not work for an ISP and have other things to do in life...

Secondleveldomain    firstleveldomain (top domain)

mycompany        local


mycompany.local < This is a non routable DNS Domain

ads.meinfirma.local < This is a non routable DNS Domain

ads.meinefirma.ch < This is a routable DNS Domain


If your internal Windows Domain is something green above > Good

If you have something that is like red above > Not good but can fix here is how:


You may have to adapt a second Domain name as you maybe already own from your Internet Web Site or if you have an SMTP MX from your E-Mail system. (Check you Internet Provider/Domains/DNS/MX). You will have to prove to Azure that you own the Domain with a special DNS entry.

Maybe you noticed the time where you could not get a Security Certificate for your .local domain. Maybe you already have a second UPN per user?

Microsoft explains it here maybe you understand maybe not. Clear up with Exchange People and security before you do this on Active Directory. It may have a lot if impact if you have a third party software, which enumerates these, fields wrong [Yes seen....] (Breaking things on other side).



When you synchronize your on-premises directory with Microsoft 365, you have to have a verified domain in Azure Active Directory (Azure AD). Only the User Principal Names (UPNs) that are associated with the on-premises Active Directory Domain Services (AD DS) domain are synchronized. However, any UPN that contains a non-routable domain, such as ".local" (example: billa@contoso.local), will be synchronized to an .onmicrosoft.com domain (example: billa@contoso.onmicrosoft.com).


If you currently use a ".local" domain for your user accounts in AD DS, it's recommended that you change them to use a verified domain, such as billa@contoso.com, in order to properly synchronize with your Microsoft 365 domain.


You can do this DOMAIN Wide is MS Explains this will be for further users.

As with Exchange Domains this is not adapted at once to existing users in some enviroments.

Ir you can do this just for one user maybe for testing or the ones who you will have Hybrid etc.


For sure you can do this with Powershell but as always TEST on a VM DC lab and limit the change to an OU if possible so you don't HIT service accounts, IT accounts etc.

$LocalUsers = Get-ADUser -Filter "UserPrincipalName -like '*contoso.local'" -Properties userPrincipalName -ResultSetSize $null

$LocalUsers | foreach {$newUpn = $_.UserPrincipalName.Replace("@contoso.local","@contoso.com"); $_ | Set-ADUser -UserPrincipalName $newUpn}

External Links to blogs: 




PITFALL 3: Fixing UPN on-premise by Markus Vilcinskas (Scripts moved to EXE solution called IDFIX)

As example, somehow, people get it done that on both sides on-premise and in Azure you have objects with the same UPN name.

There where once some Powershell script sets posted under the links below. However, you are unable to download those mentioned.

MS replaced and consolidated on a .NET EXE tool so the Cloud Managers can also run it. The Script seemed to have a too large impact when running

Wrong by people who suddenly run and unerstood PS and never used ADSIedit or DCDIAG.exe before ;-)



Here is the tool which will report all errors on your ADS on-premise:


idFix is used to perform discovery and remediation of identity objects and their attributes in an on-premises Active Directory environment in preparation for migration to Azure Active Directory. IdFix is intended for the Active Directory administrators responsible for directory synchronization with Azure Active Directory.

The purpose of IdFix is to reduce the time involved in remediating the Active Directory errors reported by Azure AD Connect. Our focus is on enabling the customer to accomplish the task in a simple expedient fashion without relying upon subject matter experts.

The Microsoft Office 365 IdFix tool provides the customer with the ability to identify and remediate object errors in their Active Directory in preparation for deployment to Azure Active Directory or Office 365. They will then be able to successfully synchronize users, contacts, and groups from the on-premises Active Directory into Azure Active Directory.





Microsoft is working to reduce the time required to remediate identity issues when onboarding to Microsoft 365. A portion of this effort is intended to address the time involved in remediating the Windows Server Active Directory (Windows Server AD) errors reported by the directory synchronization tools such as Azure AD Connect and Azure AD Connect cloud sync. The focus of IdFix is to enable you to accomplish this task in a simple, expedient fashion.

The IdFix tool provides you the ability to query, identify, and remediate the majority of object synchronization errors in your Window's Server AD forests in preparation for deployment to Microsoft 365. The utility does not fix all errors, but it does find and fix the majority. This remediation will then allow you to successfully synchronize users, contacts, and groups from on-premises Active Directory into Microsoft 365. Note: IdFix might identify errors beyond those that emerge during synchronization. The most common example is compliance with rfc 2822 for smtp addresses. Although invalid attribute values can be synchronized to the cloud, the product group recommends that these errors be corrected.

This was sourced from those scripts before:

OLD LINK: https://social.technet.microsoft.com/wiki/contents/articles/16692.how-to-use-powershell-to-fix-duplicate-user-principal-name-for-on-premises-active-directory-users.aspx



FIXID Proxyaddress Error:

For the PROXY Error we assume this will be changed by the latest version of the Hybris Wizard because MS describes that RUS on-premise will be changed. 

We assumed AS long as the Primary (FAT) SMTP: address is the correct this would work. But we also see that MS changes it on-premise with the wizard (new or since ever)



Primary SMTP proxy address is replaced by targetAddress value in a hybrid environment

You find following code which is run through the wizard on-premise:

Set-EmailAddressPolicy -Identity "Default Policy" -ForceUpgrade "True" -EnabledEmailAddressTemplates ("SMTP: @domain.com", "smtp:%m@domain.mail.onmicrosoft.com", + "SMTP: @domain.com" + "smtp:%m@domain.mail.onmicrosoft.com")

Update-EmailAddressPolicy -Identity "Default Policy" -UpdateSecondaryAddressesOnly "True" -DomainController "GlobalCatalog.domain.com"


If you want to make a script which changes that PLEASE note:

The field "email" (Under Street/address) should be in sync with PROXYaddress but often it's not.

The field E-Mail main focus is for CRM/ERP reference or for vcards.

The PROXYaddress primary SMTP is for routing that's the one you should select to fetch the E-Mail address for the Hybrid Wizard selection.

That's also what ID FIX checks. 

As per MS Reference the field email is Synced FROM Proxyaddress but depending on the WAY you handle the ADS user not anytime. (See posts below link)




If you've already set up directory synchronization, the user's UPN for Microsoft 365 may not match the user's AD DS UPN that's defined in your AD DS. This can occur when a user was assigned a license before the domain was verified. To fix this, use PowerShell to fix duplicate UPN to update the user's UPN to ensure that the Microsoft 365 UPN matches the corporate user name and domain. If you're updating the UPN in the AD DS and would like it to synchronize with the Azure Active Directory identity, you need to remove the user's license in Microsoft 365 prior to making the changes in AD DS.

n Microsoft Office 365, an administrator receives the following email message warning when directory synchronization finishes:




Directory Synchronization Error Report

 The error report in the email message may contain one or more of the following error messages:

  • A synchronized object with the same proxy address already exists in your Microsoft Online Services directory.
  • Unable to update this object because the user ID is not found.
  • Unable to update this object in Microsoft Online Services because the following attributes associated with this object have values that may already be associated with another object in your local directory.

This issue may occur if mail-enabled objects in the on-premises Active Directory Domain Services (AD DS) have duplicate or invalid values, and these user objects are not synchronized from the AD DS to Office 365 correctly during directory synchronization.



Manual Reference Butsch what to check on on-premise enviroment before you start any Hybrid M365/Azure project, collected from different sources 02.02.2023

Group objects:


 * List of attributes that are synchronized to Office 365 and attributes that are written back to the on-premises Active Directory Domain Services

* NOTE: these are list as group filters in the article, but they appear to be an inaccurate mix of filters and errors.



 * isCriticalSystemObject = TRUE

* mail is present AND DisplayName is not present

* Group has more than 15,000 immediate members

* Cannot start with Group_



 * DisplayName is empty

* ProxyAddress does not have a primary SMTP address) AND (mail attribute is not present/invalid - i.e. indexof ('@') <= 0)

* Group has more than 15,000 immediate members



 * DisplayName is empty

* ProxyAddress does not have a primary SMTP address) AND (mail attribute is not present/invalid - i.e. indexof ('@') <= 0)

* Group has more than 15,000 immediate members

* Value is non-blank if present

* Max Length = 255.

* The attribute being present check is done in mtChecks, however, the errorBlank check is done only if the attribute is missing, so that has been updated to check for blanks if attribute present. new ComposedRule(StringLiterals.DisplayName,


ProxyAddresses have additional requirements:

 * Cannot contain space < > () ; , [ ]

* There should be no ":" in the suffix part of ProxyAddresses.

* SMTP addresses should conform to valid email formats



 * Cannot start with period (.)

* Max Length = 64, document doesn't restrict, schema says 64

You could find out what to correct also in the AZURE Connector, Synchronization Rules Editor. There are some FILTERS in which they select objects to Sync from Local Active Directory to Azure AD.

As example for the Exchange Users:


 Active Directory Synchronization in Office 365