Tell us about your PDF experience.

Azure Active Directory troubleshooting

documentation
Welcome to Azure Active Directory troubleshooting. These articles explain how to
determine, diagnose, and fix issues that you might encounter when you use Azure
Active Directory. In the navigation pane on the left, browse through the article list or use
the search box to find issues and solutions.

Sign-in and Multi-factor authentication

ｃ HOW-TO GUIDE

Authorization_RequestDenied error when changing password

Can't authenticate using ADAL

Code 403 Forbidden error when using SSO

Azure AD Hybrid Sync Agent Installation Issues

ｃ HOW-TO GUIDE

No privileges to install MSI

Cannot start service AADConnectProvisioningAgent

The gMSA is set to log on as Service

There is no such object on the server

Unable to create gMSA because KDS may not be running on domain controller

Password writeback issues

ｃ HOW-TO GUIDE

General troubleshooting steps

Access rights and permissions

Error code 8023062C - insecure password reset or change

Error code SSPR_009 - synced Azure AD admin can't do cloud reset

Error code SSPR_0029 - on-premises configuration not set up

Admin password reset on Microsoft 365 admin center

Initial sign-in delays after forced password change

On-premises policy disallows password reset

Sign-in to SAML-based SSO apps

ｃ HOW-TO GUIDE

Error AADSTS50003 - certificate or key not configured

Error AADSTS50011 - reply URL mismatch

Error AADSTS50020 - guest sign-in to resource tenant fails

Error AADSTS50105 - user not assigned a role

Error AADSTS650056 - misconfigured app

Error AADSTS70001 - app not found in directory

Error AADSTS75011 - authentication method mismatch

Error AADSTS75005 - not a valid saml request

Error AADSTS750054 - SAML request or response not present

Error when you try to reset your
password in Azure, Office 365, or
Intune: We could not verify your
account
Article • 04/20/2022 • 2 minutes to read

This article describes a problem in which you receive an error message "We could not
verify your account" when you try to reset your password in Microsoft Azure, Office 365,
or Microsoft Intune. To resolve this problem, work with your administrator to update
your telephone number.

Original product version:   Azure Active Directory, Microsoft Intune, Cloud Services (Web
roles/Worker roles)

Original KB number:   2951246

Symptoms
When you use Microsoft Azure, Microsoft Office 365, or Microsoft Intune, you may
receive the following error message when you try to reset your password:

We could not verify your account.

Cause
This problem may occur because there are no telephone numbers on file for you.

Resolution
To resolve this problem, work with your administrator to update your telephone
number(s).

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Error (The maximum number of devices
that can be joined to the workplace by
the user has been reached) during a
Workplace Join
Article • • 2 minutes to read

This article describes a problem in which a "The maximum number of devices that can
be joined to the workplace by the user has been reached" error occurs when you try to
perform a Workplace Join operation.

Original product version:   Windows Server 2012 R2 Datacenter, Windows Server 2012 R2
Standard, Windows 8.1 Enterprise, Azure Active Directory

Original KB number:   3045379

Symptoms
When a user tries to perform a Workplace Join operation on a WIndows device, they
receive the following message:

Confirm you are using the current sign-in info, and that your workplace uses this
feature. Also, the connection to your workplace might not be working right now.
Please wait and try again.

Additionally, an administrator may see the following Event details in Event Viewer.

Event ID:200

Log Name: Microsoft-Windows-Workplace Join/Admin

Source: Microsoft-Windows-
Workplace Join
Level: Error
Description: The maximum number of devices that can
be joined to the workplace by the user has been reached.

Registration Service URI:

https://enterpriseregistration.windows.net/EnrollmentServer/DeviceEnrollmentWeb

Service.svc

Cause
This problem occurs because the user has joined the maximum number of devices and
has fulfilled the designated quota.
Resolution
To resolve this problem, check the quota configuration. Then, check the number of
devices that the user has previously registered. If the quota is reached, follow these
steps, depending on the applicable scenario.

If the user is trying to perform Workplace Join to Azure Active Directory

1. Delete devices for the user.

a. Sign in to Azure portal or start the Azure AD console from the Microsoft
365 admin center as Company Administrator.
b. Move to the directory that the user is trying the join.
c. Locate Users, and then locate the user who cannot perform the Workplace
Join operation.
d. Locate Devices.
e. Review the list to determine which devices can be deleted. Then, click
Delete Device.
2. Increase the Registered Device Quota.
a. Sign in to the Azure portal or start the Azure AD console from the
Microsoft 365 admin center as Company Administrator.
b. Move to the directory that the user is trying the join.
c. Locate Devices, and then locate Device Settings.
d. Change the Maximum Number of devices per user setting to a larger
value.

If the user is trying to perform Workplace Join to your local Active Directory site

1. Delete devices for the user.

Use Windows PowerShell scripts to identify devices and to delete devices
that are associated with a user.
2. Increase the Registered Device Quota value.

a. Sign in to your AD FS server.

b. Run Windows PowerShell as an elevated administrator.

c. Run the following command to increase the quota:

Set-ADFSDeviceRegistration -DevicesPerUser [0 - 1000]

 For example, run the following command to set the number of devices for
the user to 10:

Set-ADFSDeviceRegistration -DevicesPerUser 10

You can also verify that the user has reached the device capacity by reviewing the DRS
Event logs.

1. Open Event Viewer on the DRS server.

2. Browse to the location: Applications and Services Logs\Device Registration

Service\DRS\Admin

3. Look for Event ID 125. It should resemble the following:

User 'user@domain.com : GUID' is not eligible to enroll a device of type

'device_type' Reason 'DeviceCapReached'.
Troubleshoot data freshness alerts in
Azure AD Connect Health
Article • 04/20/2022 • 9 minutes to read

This article offers common diagnostic fixes for the data freshness alert "Health service
data is not up to date", which is generated when the Azure Active Directory (Azure AD)
Connect Health Service hasn't received data in the last two hours. The alert occurs in the
Health Service for the following services:

Azure AD Sync service

Azure AD Domain Services (Azure AD DS)
Active Directory Federation Services (AD FS)

Prerequisites
Azure AD Connect .
The Azure AD Connect Health agent for AD DS .
The Azure AD Connect Health agent for Azure AD FS .
The PsExec tool.

Symptoms
To view the data freshness alert, take the following steps:

1. In the Azure portal , search for and select Azure AD Connect Health.

2. In the Azure Active Directory Connect Health | Quick start menu pane, select AD
DS Services.

3. Select your domain name, and then select Alerts.

4. In the Active Directory Domain Services Alerts pane, select Health service data is
not up to date.

5. In the Health service data is not up to date pane, select the Server Name. The lists
of properties for Alert Details and Data Type Details appear.

Common diagnostic steps

Before you continue, see Health service data is not up to date alert.
HTTP proxy troubleshooting steps
If you use an HTTP proxy, follow these steps:

1. If Secure Sockets Layer (SSL) inspection is turned on, make sure that you've added
the policy key service endpoint ( policykeyservice.dc.ad.msft.net ) to the allow list.

2. Use a PowerShell cmdlet to find connectivity issues. You can run the Test-
AzureADConnectHealthConnectivity cmdlet successfully as a regular user.
However, if all data types are missing, the proxy setting might be correct for the
user but not for Local System (the context that the service runs under). In that
case, run the appropriate Test-AzureADConnectHealthConnectivityAsSystem cmdlet
instead:

Sync

PowerShell

Test-AzureADConnectHealthConnectivityAsSystem -Role Sync

3. To check whether the proxy settings are correct for Local System:

a. Enter the following PsExec command to view the Windows settings remotely:

Console

PsExec.exe -i -s "start ms-settings:"

b. Select Network & internet > Proxy, and then select Edit under the Manual
proxy setup heading.

c. In the Edit proxy server dialog box, update the proxy server settings to match
the current setup.

d. Restart the services.

Performance counter troubleshooting steps

Run the following PowerShell commands to check for the existence of certain
performance counter categories.

Sync
 PowerShell

[System.Diagnostics.PerformanceCounterCategory]::Exists("Processor")

[System.Diagnostics.PerformanceCounterCategory]::Exists("TCPv4")

[System.Diagnostics.PerformanceCounterCategory]::Exists("Memory")

[System.Diagnostics.PerformanceCounterCategory]::Exists("Process")

If any of these commands return False, run the following script to get more information
about the performance counters:

Sync

PowerShell

$perfCounters = @(

"\Processor(_Total)\% Processor Time",

"\Memory\Available MBytes",

"\TCPv4\Connections Established",

"\Process(Microsoft.Identity.AadConnect.Health.AadSync.Host)\Private
Bytes",

"\Process(Microsoft.Identity.Health.AadSync.MonitoringAgent.Startup)\Pri
vate Bytes"

foreach($counter in $perfCounters)

try

$counterResult = Get-Counter -Counter $counter -MaxSamples 1 -

ErrorAction SilentlyContinue

if($counterResult -eq $null)

Write-Host $counter " -> does not exist" -ForegroundColor

Red

if($counter -eq
"\Process(Microsoft.Identity.AadConnect.Health.AadSync.Host)\Private
Bytes")

Write-Host " Please make sure Azure AD Connect

Health Sync Insights Service is running." -ForegroundColor Magenta
}

elseif($counter -eq
"\Process(Microsoft.Identity.Health.AadSync.MonitoringAgent.Startup)\Pri
vate Bytes")

Write-Host " Please make sure Azure AD Connect

Health Sync Monitoring Service is running." -ForegroundColor Magenta

else

Write-Host $counter " -> exists " -ForegroundColor Green

catch {}

Data type troubleshooting steps

This section includes troubleshooting steps for fixing data type issues.

Sync

Data type Troubleshooting steps

PerfCounter Make sure that the performance counters

exist.
Make sure that the Azure AD Connect Health
Sync Monitoring Service is running.

AadSyncService‑Connectors
Make sure that the Azure AD Connect Health Sync
AadSyncService‑GlobalConfigurations
Insights Service is running.
AadSyncService‑RunProfileResults

AadSyncService‑ServiceConfigurations

AadSyncService‑ServiceStatus

AadSyncService‑SynchronizationRules

Collect logs for the Monitoring Agent and

Insights Agent
If the dashboard isn't helping, collect the agent logs. The relevant service can be run in
the console to get more information.

Begin by entering the following PsExec command to run the command prompt
remotely:

Console

PsExec.exe -i -s cmd

Then, collect the agent logs for the Monitoring and Insights services of Sync, AD DS, or
AD FS, as described in the next section.

７ Note

AD FS also has a Diagnostics service. Instructions for collecting the corresponding

Diagnostic Agent logs are shown after the log collection sections for Monitoring
and Insights.

Collect Monitoring Agent logs

To collect Monitoring Agent logs, follow these steps:

1. At the remote command prompt, enter services.msc to open the Services snap-in.

2. Stop the Monitoring Service for the appropriate service type.

For example, for AD FS, select Azure AD Connect Health AD FS Monitoring

Service from the list of services, then select the Stop Service icon.

3. Change the current directory to the appropriate directory according to the service
type. Then, open the configuration file of the Monitoring Agent service executable
in a text editor (such as Notepad) for editing. The path name and executable file
name for each service type is shown in the following table. The configuration file
name simply appends the .config file name extension to the end of the
executable file name.

Service Path Executable

type

Sync C:\Program Microsoft.Identity.Health.AadSync.MonitoringAgent.Startup.exe

Files\Microsoft
Azure AD Connect
Health Sync
Agent\Monitor

AD DS C:\Program Microsoft.Identity.Health.Adds.MonitoringAgent.Startup.exe
Files\Azure Ad
Connect Health
Adds
Agent\Monitor
 Service Path Executable
type

AD FS C:\Program Microsoft.Identity.Health.Adfs.MonitoringAgent.Startup.exe
Files\Azure Ad
Connect Health
Adfs
Agent\Monitor

For example, for AD FS, enter the following commands:

Console

cd "C:\Program Files\Azure Ad Connect Health Adfs Agent\Monitor"

notepad
"Microsoft.Identity.Health.Adfs.MonitoringAgent.Startup.exe.config"

4. In the text editor, insert the following line to set the ConsoleDebug key to true :

XML

<add key="ConsoleDebug" value="true" />

5. Save and close the configuration file.

6. Run the Monitoring Agent service, and direct its output to a log file (monitor.log).

For example, for AD FS, enter the following command:

Console

Microsoft.Identity.Health.Adfs.MonitoringAgent.Startup.exe >
monitor.log

7. Let the Monitoring Agent service run for 15 minutes. Then, press Ctrl+C to stop the
service, and inspect the monitor.log file.

Collect Insights Agent logs

To collect Insights Agent logs, follow these steps:

1. At the remote command prompt, enter services.msc to open the Services snap-in.

2. Stop the Insights service for the appropriate service type.

 For example, for AD FS, select Azure AD Connect Health AD FS Insights Service
from the list of services, then select the Stop Service icon.

3. Change the current directory to the appropriate directory according to the service
type. Then, run the Insights Agent service executable by using the /console
parameter and direct its output to a log file (insights.log). The path name and
executable file name for each service type is shown in the following table.

Service Path Executable

type

Sync C:\Program Microsoft.Identity.AadConnect.Health.AadSync.Host.exe

Files\Microsoft Azure AD
Connect Health Sync
Agent\Insights

AD DS C:\Program Files\Azure Microsoft.Identity.Health.Adds.InsightsService.exe

Ad Connect Health Adds
Agent\Insights

AD FS C:\Program Files\Azure Microsoft.Identity.Health.Adfs.InsightsService.exe

Ad Connect Health Adfs
Agent\Insights

For example, for AD FS, enter the following commands:

Console

cd "C:\Program Files\Azure Ad Connect Health Adfs Agent\Insights"

Microsoft.Identity.Health.Adfs.InsightsService.exe /console >

insights.log

4. Let the Insights Agent service run for 15 minutes. Then press Ctrl+C to stop the
service, and inspect the insights.log file.

Collect logs for the Diagnostics Agent (for AD

FS only)
To collect Diagnostics Agent logs for AD FS, follow these steps:

1. In the remote command prompt, enter services.msc to open the Services snap-in.

2. Stop the Diagnostics service for the appropriate service type.

 For example, for AD FS, select Azure AD Connect Health AD FS Diagnostics
Service from the list of services, then select the Stop Service icon.

3. Change the current directory to the diagnostics directory for AD FS. Then, run the
Diagnostics Agent service executable by using the -Debug parameter, and direct its
output to a log file (diagnostics.log).

Console

cd "C:\Program Files\Azure Ad Connect Health Adfs Agent\Diagnostics"

Microsoft.Identity.Health.Adfs.DiagnosticsAgent.exe -Debug >

diagnostics.log

4. Press Enter.

5. Let the Diagnostics Agent service run for 15 minutes. Then, press Ctrl+C to stop
the service, and copy the console output into diagnostics.log.

6. Search for Error in the logs, and check whether any error entry indicates a specific
problem (such as connectivity or proxy configuration).

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Error when you try to register a device:
Can't connect to the service
Article • 04/20/2022 • 2 minutes to read

Original product version:   Windows 8.1 Enterprise, Windows Server 2012 R2 Standard,
Windows Server 2012 R2 Datacenter, Azure Active Directory

Original KB number:   3045378

Symptoms
When you try to perform a Workplace Join operation and register your device to your
local Active Directory domain from a Windows 8.1 device, you receive the following
error message:

Can't connect to the service

We can't connect to the service you need right now. Check your network connection
or try this again later.

Cause
This problem may occur for one of the following reasons:

Although the Active Directory Federation Services (AD FS) proxy server can resolve
the name of the federation server, the name resolves to an incorrect host.
The AD FS service is not running on the AD FS proxy server.
The WAP role is not installed.
The WAP role is installed but is not configured.

Resolution
To resolve this problem, follow these steps:

1. Sign in to your AD FS proxy server:

a. Run the Services Management Console (services.msc).
b. Locate the AD FS service.
c. Verify that the service is in a Started state.

2. Verify name resolution of the Internal AD FS instance:

a. From the AD FS proxy server, open a command prompt.
 b. Type PING adfsserver.contoso.com , and then press Enter.

７ Note

The adfsserver.contoso.com placeholder represents the address of your AD

FS server, such as sts.contoso.com .

3. Don't worry about whether the PING is successful or unsuccessful. Instead, notice
whether the target address resolves to the IP address of the server.

4. If the address is incorrect, correct the resolution conflicts:

Check the Hosts file on the AD FS proxy server to see whether the correct
entry is included and whether it targets your AD FS instance.
If you do not use a Hosts file, check internal DNS by using the Nslookup
command to verify DNS records.

More information
For more troubleshooting information, see the following article:

Diagnostic logging for troubleshooting Workplace Join issues

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Understand AD FS sign-in events in
Azure AD with Connect Health
Article • 04/20/2022 • 2 minutes to read

With Azure AD Connect Health, you can integrate Active Directory Federation Services
(AD FS) sign-in events into the Azure Active Directory (Azure AD) sign-ins report. The
Azure AD sign-ins report includes information about when the following types of
entities sign in to Azure AD and access resources:

Users
Applications
Managed resources

This article shows how to use the Connect Health for AD FS agent, Azure Monitor, and
Log Analytics to correlate and analyze AD FS sign-in data.

Prerequisites
Azure AD Connect Health for AD FS installed and upgraded to latest version
(3.1.95.0 or greater).
The Global Administrator or Reports Reader role to view the Azure AD sign-ins.
At least one Azure AD Premium (P1 or P2) license for the first Connect Health
agent.
25 extra Azure AD Premium (P1 or P2) licenses for each extra registered agent.
An equal agent count to the total number of agents that are registered across all
monitored roles (AD FS, Azure AD Connect, and Active Directory Domain Services).
The requisite number of valid Azure AD Connect Health licenses. (You aren't
required to assign the license to specific users.)

Sign-in data reporting

The Connect Health for AD FS agent correlates many event IDs from AD FS to offer
information about the sign-in request and error details if a request fails. The request
information is correlated to the Azure AD sign-ins report schema. The information can
be displayed in the Azure AD sign-in report user interface. Along with the report, a new
Azure Monitor workbook template and a new Azure Log Analytics stream are available
with the AD FS data. You can use and modify the workbook template for an in-depth
analysis for scenarios, such as:
 AD FS account lockouts.
Bad password attempts.
Spikes of unexpected sign-in attempts.

The available data mirrors the same data that's available for Azure AD sign-ins. Five tabs
with information are available, based on the sign-in type:

Azure AD
AD FS

Connect Health correlates events from AD FS, dependent on the server version. It then
matches the events with the AD FS schema. For more information, see What data is
displayed in the report?

Configuration
Basic configuration is automatic. Data is fed into the report after the feature goes live
and prerequisites are met.

You can enable Log Analytics for AD FS sign-ins and use it with any other Log Analytics-
integrated components, such as Microsoft Sentinel. For more information, see Enabling
Log Analytics and Azure Monitor.

Basic troubleshooting
For current known issues and limitations, see Frequently asked questions.

Kusto logging
To collect the sign-in events from AD FS sign-ins, run the following Kusto query in Log
Analytics.

Kusto

unioncluster('Idsharedweu').database('ADFSConnectHealth').SignInEvent,

cluster('Idsharedwus').database('ADFSConnectHealth').SignInEvent

| where env_time > ago(2d)

| where tenantId == "00000000-0000-0000-0000-000000000000"

| take 15

Next steps
Read more about AD FS sign-ins in Azure AD with Connect Health.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Understand Azure AD Connect 1.4.xx.x
and device disappearance
Article • 04/20/2022 • 6 minutes to read

With the implementation of version 1.4.xx.x of Azure Active Directory Connect (Azure AD
Connect), customers may see some or all of their Windows devices disappear from
Azure AD. This isn't a cause for concern, as these device identities aren't used by Azure
Active Directory (Azure AD) during Conditional Access authorization. This change won't
delete any Windows devices that were correctly registered with Azure AD for Hybrid
Azure AD Join.

If you see the deletion of device objects in Azure AD exceeding the Export Deletion
Threshold, allow the deletions to go through. How To: allow deletes to flow when they
exceed the deletion threshold

Background
Windows devices registered as Hybrid Azure AD Joined are represented in Azure AD as
device objects, and they can be used for Conditional Access. Windows 10 devices are
synchronized to the cloud via Azure AD Connect, while down level Windows devices are
registered directly using either Active Directory Federation Services (AD FS) or seamless
single sign-on.

Windows 10 devices
Only Windows 10 devices with a specific userCertificate attribute value that's configured
by Hybrid Azure AD Join should be synchronized to the cloud by Azure AD Connect. In
previous versions of Azure AD Connect, this requirement was not rigorously enforced,
and unnecessary device objects were added to Azure AD. Such devices in Azure AD
always stayed in the "pending" state, as these devices were not intended to be
registered with Azure AD.

This version of Azure AD Connect will only synchronize Windows 10 devices that are
correctly configured to be Hybrid Azure AD Joined. Windows 10 device objects without
the Azure AD join specific userCertificate will be removed from Azure AD.

Down-Level Windows devices

Azure AD Connect should never synchronize down-level Windows devices. Any devices
in Azure AD previously synchronized incorrectly will be deleted from Azure AD. If Azure
AD Connect attempts to delete down-level Windows devices, then the device isn't the
one that was created by the Microsoft Workplace Join for non-Windows 10 computers
MSI , and it can't be consumed by any other Azure AD feature.

Some customers might need to revisit How To: Plan your hybrid Azure Active Directory
join implementation to register their Windows devices correctly and ensure that those
devices can participate in device-based Conditional Access.

How can I verify which devices are deleted with

this update?
To verify which devices are deleted, use the PowerShell script in PowerShell certificate
report script.

This script generates a report about certificates stored in Active Directory Computer
objects, and specifically certificates issued by the Hybrid Azure AD join feature.

The script also checks the certificates present in the UserCertificate property of a
Computer object in AD. For each non-expired certificate present, the script validates
whether or not the certificate was issued for the Hybrid Azure AD join feature; for
example, Subject Name matches CN={ObjectGUID} .

Before this update, Azure AD Connect would synchronize to Azure AD any Computer
that contained at least one valid certificate. Beginning with Azure AD Connect version
1.4, the synchronization engine identifies Hybrid Azure AD join certificates, and will use
the cloudfilter filter to prevent the computer object from synchronizing to Azure AD
unless there's a valid Hybrid Azure AD join certificate.

Azure AD devices that were previously synchronized to AD, but don't have a valid
Hybrid Azure AD join certificate, will be deleted by the synchronization engine using the
filter CloudFiltered=TRUE .

PowerShell certificate report script

PowerShell

<#

Filename: Export-ADSyncToolsHybridAzureADjoinCertificateReport.ps1.

DISCLAIMER:

Copyright (c) Microsoft Corporation. All rights reserved. This script is

made available to you without any express, implied or statutory warranty,
not even the implied warranty of merchantability or fitness for a
particular purpose, or the warranty of title or non-infringement. The entire
risk of the use or the results from the use of this script remains with you.

.Synopsis

This script generates a report about certificates stored in Active Directory

Computer objects, specifically,

certificates issued by the Hybrid Azure AD join feature.

.DESCRIPTION

It checks the certificates present in the UserCertificate property of a

Computer object in AD and, for each

non-expired certificate present, validates if the certificate was issued for

the Hybrid Azure AD join feature
(i.e. Subject Name matches CN={ObjectGUID}).

Before, Azure AD Connect would synchronize to Azure AD any Computer that

contained at least one valid

certificate but starting on Azure AD Connect version 1.4, the sync engine
can identify Hybrid

Azure AD join certificates and will 'cloudfilter' the computer object from
synchronizing to Azure AD unless
there's a valid Hybrid Azure AD join certificate.

Azure AD Device objects that were already synchronized to AD but do not have
a valid Hybrid Azure AD join

certificate will be deleted (CloudFiltered=TRUE) by the sync engine.

.EXAMPLE

.\Export-ADSyncToolsHybridAzureADjoinCertificateReport.ps1 -DN
'CN=Computer1,OU=SYNC,DC=Fabrikam,DC=com'

.EXAMPLE

.\Export-ADSyncToolsHybridAzureADjoinCertificateReport.ps1 -OU
'OU=SYNC,DC=Fabrikam,DC=com' -Filename "MyHybridAzureADjoinReport.csv" -
Verbose

#>

[CmdletBinding()]

Param

# Computer DistinguishedName

[Parameter(ParameterSetName='SingleObject',

Mandatory=$true,

ValueFromPipelineByPropertyName=$true,

Position=0)]

[String]

$DN,

# AD OrganizationalUnit

[Parameter(ParameterSetName='MultipleObjects',

Mandatory=$true,

ValueFromPipelineByPropertyName=$true,

Position=0)]

[String]

$OU,

# Output CSV filename (optional)

 [Parameter(Mandatory=$false,

ValueFromPipelineByPropertyName=$false,

Position=1)]

[String]

$Filename

# Generate Output filename if not provided

If ($Filename -eq "")

$Filename = [string] "$([string] $(Get-Date -Format

yyyyMMddHHmmss))_ADSyncAADHybridJoinCertificateReport.csv"

Write-Verbose "Output filename: '$Filename'"

# Read AD object(s)

If ($PSCmdlet.ParameterSetName -eq 'SingleObject')

$directoryObjs = @(Get-ADObject $DN -Properties UserCertificate)

Write-Verbose "Starting report for a single object '$DN'"

Else

$directoryObjs = Get-ADObject -Filter { ObjectClass -like 'computer'

} -SearchBase $OU -Properties UserCertificate

Write-Verbose "Starting report for $($directoryObjs.Count) computer

objects in OU '$OU'"

Write-Host "Processing $($directoryObjs.Count) directory object(s).

Please wait..."

# Check Certificates on each AD Object

$results = @()

ForEach ($obj in $directoryObjs)

# Read UserCertificate multi-value property

$objDN = [string] $obj.DistinguishedName

$objectGuid = [string] ($obj.ObjectGUID).Guid

$userCertificateList = @($obj.UserCertificate)

$validEntries = @()

$totalEntriesCount = $userCertificateList.Count

Write-verbose "'$objDN' ObjectGUID: $objectGuid"

Write-verbose "'$objDN' has $totalEntriesCount entries in

UserCertificate property."

If ($totalEntriesCount -eq 0)

Write-verbose "'$objDN' has no Certificates - Skipped."

Continue

# Check each UserCertificate entry and build array of valid certs

ForEach($entry in $userCertificateList)
{

Try

$cert =
[System.Security.Cryptography.X509Certificates.X509Certificate2] $entry

Catch

Write-verbose "'$objDN' has an invalid Certificate!"

Continue

Write-verbose "'$objDN' has a Certificate with Subject:

$($cert.Subject); Thumbprint:$($cert.Thumbprint)."

$validEntries += $cert

$validEntriesCount = $validEntries.Count

Write-verbose "'$objDN' has a total of $validEntriesCount

certificates (shown above)."

# Get non-expired Certs (Valid Certificates)

$validCerts = @($validEntries | Where-Object {$_.NotAfter -ge (Get-

Date)})

$validCertsCount = $validCerts.Count

Write-verbose "'$objDN' has $validCertsCount valid certificates (not-

expired)."

# Check for AAD Hybrid Join Certificates

$hybridJoinCerts = @()

$hybridJoinCertsThumbprints = [string] "|"

ForEach ($cert in $validCerts)

$certSubjectName = $cert.Subject

If ($certSubjectName.StartsWith($("CN=$objectGuid")) -or
$certSubjectName.StartsWith($("CN={$objectGuid}")))

$hybridJoinCerts += $cert

$hybridJoinCertsThumbprints += [string] $($cert.Thumbprint) +

'|'

$hybridJoinCertsCount = $hybridJoinCerts.Count

if ($hybridJoinCertsCount -gt 0)

$cloudFiltered = 'FALSE'

Write-verbose "'$objDN' has $hybridJoinCertsCount AAD Hybrid Join

Certificates with Thumbprints: $hybridJoinCertsThumbprints
(cloudFiltered=FALSE)"

Else

$cloudFiltered = 'TRUE'

Write-verbose "'$objDN' has no AAD Hybrid Join Certificates

(cloudFiltered=TRUE)."

# Save results

$r = "" | Select ObjectDN, ObjectGUID, TotalEntriesCount, CertsCount,

ValidCertsCount, HybridJoinCertsCount, CloudFiltered

$r.ObjectDN = $objDN

$r.ObjectGUID = $objectGuid

$r.TotalEntriesCount = $totalEntriesCount

$r.CertsCount = $validEntriesCount

$r.ValidCertsCount = $validCertsCount

$r.HybridJoinCertsCount = $hybridJoinCertsCount

$r.CloudFiltered = $cloudFiltered

$results += $r

# Export results to CSV

Try

$results | Export-Csv $Filename -NoTypeInformation -Delimiter ';'

Write-Host "Exported Hybrid Azure AD Domain Join Certificate Report

to '$Filename'.`n"

Catch

Throw "There was an error saving the file '$Filename':

$($_.Exception.Message)"

Next Steps
Azure AD Connect Version history

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Authentication fails with an error stating
"The requested federation realm object
'< Object ID >' does not exist"
Article • 04/20/2022 • 2 minutes to read

Authentication fails with the error "The requested federation realm object '< Object ID
>' does not exist" for users who are part of domain that is federated with a third party
identity provider in either Azure Active Directory (Azure AD) or Microsoft 365 .

This failure happens when the third Party identity provider returns the wrong IssuerURI
within the Issuer field in the Security Assertion Markup Language (SAML) response.

Resolution 1
Contact the support team for the third party identity provider and have them correct the
IssuerURI, returned as Issuer, in the SAML the response returned to either Azure AD or
Microsoft 365, through the client.

Resolution 2
Use the command Set-MsolDomainFederationSettings to modify the IssuerURI of the
federated domain to match the realm object listed in the error.

1. Connect to Azure AD using the MSONLINE module. To check that the module is
installed, open PowerShell and execute the get-module MSONLINE -ListAvailable
command.

2. Follow the steps outlined in Install the Azure AD Module to install the module.

3. Run the following commands to verify the preferred authentication protocol of the
federated domain.

PowerShell

$federationSettings=Get-MsolDomainFederationSettings -DomainName
domain.com

$federationSettings.PreferredAuthenticationProtocol

4. If the PreferredAuthenticationProtocol value listed in step 3 is shown as WSFED,

run the following command to update the IssuerURI.

PowerShell

Set-MsolDomainFederationSettings -DomainName domain.com -IssuerUri

"value of federated realm object listed in the authentication failure
message"

The necessary IssuerURI value is listed by Azure AD in the authentication failure

message.

5. If the PreferredAuthenticationProtocol value listed in step 3 is SAMLP (SAML

Protocol), run the following command to update the IssuerURI.

PowerShell

Set-MsolDomainFederationSettings -DomainName domain.com -IssuerUri

"value of federated realm object listed in the authentication failure
message" -PreferredAuthenticationProtocol samlp

 The necessary IssuerURI value is listed by Azure AD in the authentication failure

message.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Azure AD Hybrid Sync Agent Installation
Issues
Article • 04/20/2022 • 2 minutes to read

Overview
The scenarios in this set of articles describe frequent issues when installing Azure AD
Hybrid Sync Agent, and how to correct them.

This troubleshooting doc applies to configuring the agent for Azure AD Connect Cloud
Sync or Workday automatic user provisioning.

No privileges to install MSI

Cannot start service AADConnectProvisioningAgent
The gMSA is set to log on as Service
There is no such object on the server
Unable to create gMSA because KDS may not be running on domain controller

Prerequisites
To install Cloud Provisioning Agent, the following prerequisites are required:
Prerequisites for Azure AD Connect cloud sync.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Azure AD Hybrid Sync Agent Installation
Issues - No privileges to install MSI
Article • 04/20/2022 • 2 minutes to read

This troubleshooting guide focuses on when you don't have privileges to install MSI.
Without these privileges, you may be unable to successfully install the Azure AD
Connect Provisioning Agent.

Prerequisites
To install Cloud Provisioning Agent, the following prerequisites are required:
Prerequisites for Azure AD Connect cloud sync.

No privileges to install MSI

While installing Cloud Provisioning Agent, you may get the following error:

Service 'Microsoft Azure AD Connect Provisioning Agent'

(AADConnectProvisioningAgent) failed to start. Verify that you have sufficient
privileges to start system services.
To verify that you have sufficient privileges:

1. Make sure the user context credentials are set to either Domain Administrator or
Enterprise Administrator.

2. Open the Local Security Policy snap-in (secpol.msc). In the Security Settings pane,
select Local policies > User Rights Assignment. Then select the Log on as a
service policy.

3. Select Action > Properties. Then in Local Security Setting, make sure the NT
SERVICE\ALL SERVICES group appears.
During package installation, the service AADConnectProvisioningAgent is created, and
logon credentials are temporarily set to NT Service\AADConnectProvisioningAgent.

If Log on as a service doesn't have ALL SERVICES listed, the installation fails to start, and
it shows the previously listed error message.

To resolve this issue, provide ALL SERVICES user rights to Log on as a service.

The wizard now completes successfully.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Azure AD Hybrid Sync Agent Installation
Issues - Cannot start service
AADConnectProvisioningAgent
Article • 04/20/2022 • 2 minutes to read

This troubleshooting guide focuses on when you can't start the

AADConnectProvisioningAgent service. This problem may block you from installing the
Azure AD Connect Provisioning Agent successfully.

Prerequisites
To install Cloud Provisioning Agent, the following prerequisites are required:
Prerequisites for Azure AD Connect cloud sync.

Cannot start service

AADConnectProvisioningAgent
While installing Cloud Provisioning Agent, you may get the following error:

Service 'Microsoft Azure AD Connect Provisioning Agent'

(AADConnectProvisioningAgent) failed to start. Verify that you have sufficient
privileges to start system services.
Assign domain administrator credentials to the AADConnectProvisioningAgent service,
as shown in How to troubleshoot agent failed to start.
After assigning credentials to the service, you may still be unable to complete the
installation wizard, and receive the following error message:

Failed changing Windows service credentials to gMSA. Please check the logs for
more detailed information. If that doesn't help resolve this issue, please contact
support.

If you select the confirm button again, following message will be displayed:

Unable to create gMSA because KDS may not be running on domain controller.
Please create/run KDS manually.
To resolve this issue, check the System event logs for eventID 7041. The event details
describe how to assign a Log on as a service user right at the Local Security Policy snap-
in (secpol.msc).

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Azure AD Hybrid Sync Agent Installation
Issues - The gMSA is set to log on as
Service
Article • 04/20/2022 • 2 minutes to read

This troubleshooting guide focuses on when the gMSA is set to log on as a service. This
situation may block you from successfully installing the Azure AD Connect Provisioning
Agent.

Prerequisites
To install Cloud Provisioning Agent, the following prerequisites are required:
Prerequisites for Azure AD Connect cloud sync.

The gMSA is set to log on as Service

While installing Cloud Provisioning Agent, you may get the following error:

Failed changing Windows service credentials to gMSA.

To resolve this issue, check the System event logs for EventID 7038. The following error
appears:

The user name or password is incorrect.

Open the Microsoft Azure AD Connect Provisioning Agent properties and select the
Log On tab. You'll find the settings aren’t grayed out, as is expected for a managed
account service.
To verify whether the account is managed, open a command prompt and type the
following command:

Console

Sc.exe qmanagedaccount aadconnectprovisioningagent

The account-managed status is shown as False.

To set the status to True and resolve this issue, type the following command:

Console
 Sc.exe managedaccount aadconnectprovisioningagent true

The wizard now completes successfully.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Azure AD Hybrid Sync Agent Installation
Issues - There is no such object on the
server
Article • 04/20/2022 • 3 minutes to read

This troubleshooting guide focuses on when an object reference isn't set to an object
instance. This situation may block you from installing the Azure AD Connect
Provisioning Agent.

Prerequisites
To install Cloud Provisioning Agent, the following prerequisites are required:
Prerequisites for Azure AD Connect cloud sync.

Scenario 1
When installing Cloud Provisioning Agent, you may get this error during installation
process.

Error while creating group managed service account (gMSA). Error: There is no such
object on the server.
 

The installation wizard's trace file isn't clear about what's missing:

Output

[15:16:14.583] [ 16] [ERROR] Exception creating gmsa. Exception:

System.DirectoryServices.DirectoryServicesCOMException (0x80072030): There
is no such object on the server.

at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)

at System.DirectoryServices.DirectoryEntry.Bind()

at System.DirectoryServices.DirectoryEntry.get_NativeObject()

at System.DirectoryServices.DirectoryEntry.InvokeGet(String propertyName)

at
Microsoft.Online.Deployment.Framework.Providers.GroupManagedServiceAccountPr
ovider.CreateGroupManagedAccount(String serviceAccountName, String
serviceDnsName, String username, String password)

[15:16:14.585] [ 16] [ERROR] Exception caught while creating gmsa.

Exception: System.DirectoryServices.DirectoryServicesCOMException
(0x80072030): There is no such object on the server.

To resolve the issue in this scenario, use the Active Directory Users and Computers snap-
in (dsa.msc). This snap-in verifies within the domain controller whether the Managed
Service Account container is present.
If the container is missing, contact the Windows Directory Services Team to restore or
create the container with the ADPrep /Domainprep command.

The following items are Active Directory Domain Service requirements:

The Active Directory schema in the gMSA domain's forest needs to be updated to
Windows Server 2012 to create a gMSA.

You can update the schema by installing a domain controller that runs Windows
Server 2012 or by running the version of adprep.exe from a computer running
Windows Server 2012. The object-version attribute value for the object
CN=Schema,CN=Configuration,DC=< name of DC >,DC=Com must be 52.

Scenario 2
In a similar scenario as above, you may get the following error:

Error when creating group managed service account (gMSA). Error: There is no such
object on the server.
 

The wizard trace shows the following information:

Output

[01:12:13.924] [ 9] [INFO ] IsServiceAccountGMSA:: Checking if service

account is gmsa

[01:12:13.924] [ 9] [INFO ] Get current service credentials.

[01:12:13.938] [ 9] [INFO ] IsServiceAccountGMSA:: Service account: NT

SERVICE\AADConnectProvisioningAgent is not gmsa.

[01:12:15.414] [ 9] [INFO ] IsServiceAccountGMSA:: Checking if service

account is gmsa

[01:12:15.414] [ 9] [INFO ] Get current service credentials.

[01:12:15.418] [ 9] [INFO ] IsServiceAccountGMSA:: Service account: NT

SERVICE\AADConnectProvisioningAgent is not gmsa.

[01:12:15.468] [ 9] [ERROR] Exception creating gmsa. Exception:

System.DirectoryServices.DirectoryServicesCOMException (0x80072030): There
is no such object on the server.

at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)

at System.DirectoryServices.DirectoryEntry.Bind()

at System.DirectoryServices.DirectoryEntry.get_NativeObject()

at System.DirectoryServices.DirectoryEntry.InvokeGet(String propertyName)

at
Microsoft.Online.Deployment.Framework.Providers.GroupManagedServiceAccountPr
ovider.CreateGroupManagedAccount(String serviceAccountName, String
serviceDnsName, String username, String password)

[01:12:15.472] [ 9] [ERROR] Exception caught while creating gmsa.

Exception: System.DirectoryServices.DirectoryServicesCOMException
(0x80072030): There is no such object on the server.

Once you verify and confirm that Managed Service account container is present at the
domain, a client Lightweight Directory Access Protocol (LDAP) trace shows the following
information:

Output

9638 [2]0144.1380::04/14/21-14:17:20.2063638
[Microsoft_Windows_LDAP_Client/Debug16 ] Message=ldap_search called for
connection 0x4392e0d8: DN is
<WKGUID=1eb93889e40c45df9f0c64d23bbb6237,DC=*****,DC=com>. SearchScope is
0x0. AttributesOnly is 0x0.

9679 [1]0144.1380::04/14/21-14:17:20.2075574
[Microsoft_Windows_LDAP_Client/Debug16 ] Message=4e 61 6d 65 45 72 72 3a 20
44 53 49 44 2d 30 33 NameErr:.DSID-03

9680 [1]0144.1380::04/14/21-14:17:20.2076087
[Microsoft_Windows_LDAP_Client/Debug16 ] Message=31 30 30 32 33 38 2c 20 70
72 6f 62 6c 65 6d 20 100238,.problem.

9681 [1]0144.1380::04/14/21-14:17:20.2076151
[Microsoft_Windows_LDAP_Client/Debug16 ] Message=32 30 30 31 20 28 4e 4f 5f
4f 42 4a 45 43 54 29 2001.(NO_OBJECT)

The agent couldn't find the WellKnown globally unique identifier (GUID) for the
Managed Service Accounts (MSA) container.

This error can be verified with the following PowerShell command:

PowerShell

$ListOWKO = Get-ADObject (Get-ADRootDSE).DefaultNamingContext -Properties

otherwellKnownObjects

$ListOWKO.otherwellKnownObjects

The output of the previous command displays the following results:

Output

B:32:1EB93889E40C45DF9F0C64D23BBB6237:CN=Managed Service
Accounts\0ADEL:8b637607-65e8-4a80-b194-f738b26b9414,CN=Deleted Objects,DC=<
name of DC >,DC=com


This orphan metadata value indicates one of these scenarios:

The MSA container was previously deleted and wasn't properly restored.
The value is missing.

The default value for the OtherWellKnownObjects attribute is:

B:32:1EB93889E40C45DF9F0C64D23BBB6237:CN=Managed Service Accounts,DC=<

name of DC >,DC=com

To resolve this issue, open a ticket with Windows Directory Services Team.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Azure AD Hybrid Sync Agent Installation
Issues - Unable to create gMSA because
KDS may not be running on domain
controller
Article • 04/20/2022 • 2 minutes to read

This troubleshooting guide focuses on when you can't install the service account after
many retries. This situation blocks you from installing the Azure AD Connect
Provisioning Agent.

Prerequisites
To install Cloud Provisioning Agent, the following prerequisites are required:
Prerequisites for Azure AD Connect cloud sync.

Unable to create gMSA because KDS may not

be running on domain controller
While installing Cloud Provisioning Agent, you may get the following error:

Unable to create gMSA because KDS may not be running on domain controller.
Please create/run KDS manually.
 

To locate the 9001 and 9002 EventIDs, go to Applications and Services Logs >
Microsoft > Windows > Security - Netlogon.

Use the following command to retrieve the server settings for the supported encryption
types:

Console

C:\windows\system32>reg query
"HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Syste
m\Kerberos\Parameters"

 HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System
\Kerberos\Parameters

SupportedEncryptionTypes REG_DWORD 0x7ffffff8

Within the command, the DWORD 0x7ffffff8 represents AES128_HMAC_SHA1

AES256_HMAC_SHA1.

In the Active Directory Users and Computers snap-in (dsa.msc), open the
provAgentgMSA properties of the domain controller:

1. Select the Attribute Editor tab.

2. Choose the msDS-SupportedEncryptionTypes attribute, and select Edit.

Verify that there's a mismatch between the encryption types that the server offers and
that the accounts accept.

To resolve the issue, remove the RC4 from the provAgentgMSA account by running the
following command in a domain controller:

Console

Set-ADServiceAccount -Identity provAgentgMSA -KerberosEncryptionType

AES128,AES256

Next, reboot the Provisioning agent server and reinstall the agent.

For more information on this issue, see Cannot install service account. The provided
context did not match the target.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Troubleshoot common problems adding
or removing an application to Azure
Active Directory
Article • 01/28/2023 • 4 minutes to read

This article helps you understand the common problems people face when adding or
removing an app in Azure Active Directory.

I clicked the “add” button and my application

took a long time to appear
Under some circumstances, it can take 1-2 minutes (and sometimes longer) for an
application to appear after adding it to your directory. While this is not the normal
expected performance, you can see the application addition is in progress by clicking on
the Notifications icon (the bell) in the upper right of the Azure portal and looking for
an In Progress or Completed notification labeled Adding application.

If your application is never added, or you encounter an error when clicking the Add
button, you’ll see a Notification in an Error state. If you want more details about the
error to learn more to or share with a support engineer, you can see more information
about the error by following the steps in the How to see the details of a portal
notification section.

I clicked the “add” button and my application

didn’t appear
Sometimes, due to transient issues, networking problems, or a bug, adding an
application fails. You can tell this happens when you click the Notifications icon (the
bell) in the upper right of the Azure portal and you see a red (!) icon next to your
Adding application notification. This indicates there was an error when creating the
application.

If you encounter an error when clicking the Add button, you’ll see a Notification in an
Error state. If you want more details about the error to learn more to or share with a
support engineer, you can see more information about the error by following the steps
in the How to see the details of a portal notification section.
I don’t know how to set up my application
once I’ve added it
If you need help with learning about applications, the List of Tutorials on How to
Integrate SaaS Apps with Azure Active Directory article is a good place to start.

In addition to this, the Azure AD Applications Document Library helps you to learn more
about single sign-on with Azure AD and how it works.

I want to delete an application but the Delete

button is disabled
The delete button will be disabled in the following scenarios:

For applications under Enterprise application, if you don't have one of the
following roles: Global Administrator, Cloud Application Administrator, Application
Administrator, or owner of the service principal.

For Microsoft application, you won't be able to delete them from the UI regardless
of your role.

For service principals that correspond to a managed identity. Managed identities

service principals can't be deleted in the Enterprise apps blade. You need to go to
the Azure resource to manage it. Learn more about Managed Identity

How to see the details of a portal notification

You can see the details of any portal notification by following the steps below:

1. Select the Notifications icon (the bell) in the upper right of the Azure portal
2. Select any notification in an Error state (those with a red (!) next to them).

７ Note

You cannot click notifications in a Successful or In Progress state.

3. Use the information under Notification Details to understand more details about
the problem.
4. If you still need help, you can also share this information with a support engineer
or the product group to get help with your problem.
 5. Select the copy icon to the right of the Copy error textbox to copy all the
notification details to share with a support or product group engineer.

How to get help by sending notification details

to a support engineer
It is important that you share all the details listed below with a support engineer if you
need help, so that they can help you quickly. Take a screenshot or select the Copy error
icon, found to the right of the Copy error textbox.

Notification Details Explained

See the following descriptions for more details about the notifications.

Essential Notification Items

Title – the descriptive title of the notification
Example – Application proxy settings
Description – the description of what occurred as a result of the operation
Example – Internal url entered is already being used by another application
Notification ID – the unique ID of the notification
Example – clientNotification-2adbfc06-2073-4678-a69f-7eb78d96b068
Client Request ID – the specific request ID made by your browser
Example – 302fd775-3329-4670-a9f3-bea37004f0bc
Time Stamp UTC – the timestamp during which the notification occurred, in UTC
Example – 2017-03-23T19:50:43.7583681Z
Internal Transaction ID – the internal ID we can use to look up the error in our
systems
Example – 71a2f329-ca29-402f-aa72-bc00a7aca603
UPN – the user who performed the operation
Example – tperkins@f128.info
Tenant ID – the unique ID of the tenant that the user who performed the operation
was a member of
Example – 7918d4b5-0442-4a97-be2d-36f9f9962ece
User object ID – the unique ID of the user who performed the operation
Example – 17f84be4-51f8-483a-b533-383791227a99

Detailed Notification Items

 Display Name – (can be empty) a more detailed display name for the error
Example – Application proxy settings
Status – the specific status of the notification
Example – Failed
Object ID – (can be empty) the object ID against which the operation was
performed
Example – 8e08161d-f2fd-40ad-a34a-a9632d6bb599
Details – the detailed description of what occurred as a result of the operation
Example – Internal url https://bing.com/ is invalid since it is already in use
Copy error – Select the copy icon to the right of the Copy error textbox to copy all
the notification details to share with a support or product group
engineer
Example
{"errorCode":"InternalUrl\_Duplicate","localizedErrorDetails":
{"errorDetail":"Internal url 'https://google.com/' is invalid since it is
already in use"},"operationResults":\

[{"objectId":null,"displayName":null,"status":0,"details":"Internal url

'https://bing.com/' is invalid since it is already in

use"}\],"timeStampUtc":"2017-03-

23T19:50:26.465743Z","clientRequestId":"302fd775-3329-4670-a9f3-
bea37004f0bb","internalTransactionId":"ea5b5475-03b9-4f08-8e95-

bbb11289ab65","upn":"tperkins@f128.info","tenantId":"7918d4b5-0442-4a97-
be2d-36f9f9962ece","userObjectId":"17f84be4-51f8-483a-b533-383791227a99"}

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support. You can also submit product feedback to Azure community support.
Error AADSTS50003 - No signing key
configured
Article • 10/12/2022 • 2 minutes to read

This article describes a problem in which you receive the error message "Error
AADSTS50003 - No signing key configured." when trying to sign into a SAML-based
single sign-on (SSO) configured app that has been integrated with Azure Active
Directory (Azure AD).

Symptoms
You receive error AADSTS50003 when trying to sign into an application that has been
setup to use Azure AD for identity management using SAML-based SSO.

Cause
The application object is corrupted and Azure AD doesn’t recognize the certificate
configured for the application.

Resolution
To delete and create a new certificate, follow the steps below:

1. On the SAML-based SSO configuration screen, select Create new certificate under
the SAML signing Certificate section.
2. Select Expiration date and then click Save.
3. Check Make new certificate active to override the active certificate. Then, click
Save at the top of the pane and accept to activate the rollover certificate.
4. Under the SAML Signing Certificate section, click remove to remove the Unused
certificate.

More Information
For a full list of Active Directory Authentication and authorization error codes see Azure
AD Authentication and authorization error codes

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Error AADSTS50011 - The reply URL
specified in the request does not match
Article • 06/15/2022 • 2 minutes to read

This article provides a resolution to the AADSTS50011 error that occurs during federated
authentication with Azure Active Directory (Azure AD).

Symptoms
You receive error AADSTS50011 when trying to sign into an application that has been set
up to use Azure AD for identity management using SAML-based SSO.

Error AADSTS50011 - The reply URL does not match the reply URLs configured for
the application <GUID>. Make sure the reply URL sent in the request matches one
added to your application in the Azure portal. Navigate to
https://aka.ms/urlMismatchError to learn more about how to fix this." when trying
to sign into a SAML-based Single Sign-On (SSO) configured app that has been
integrated with Azure Active Directory (Azure AD).

Cause
The AssertionConsumerServiceURL value in the SAML request doesn't match the Reply
URL value or pattern configured in Azure AD. The AssertionConsumerServiceURL value in
the SAML request is the URL you see in the error.

Resolution
To fix the issue, follow these steps:

1. Ensure that the AssertionConsumerServiceURL value in the SAML request matches

the Reply URL value configured in Azure AD.
2. Verify or update the value in the Reply URL textbox to match the
AssertionConsumerServiceURL value in the SAML request.

As an example, refer to the following article for detailed steps about how to configure
the values in Azure AD:

Tutorial: Azure AD SSO integration with Salesforce

 ７ Note

The reply URL is also known as Redirect URI. These values depend on what
application is being used. You should get the values from the application vendor.

After you update the Reply URL value in Azure AD and it matches the value that sent by
the application in the SAML request, you should be able to sign in to the application.

More Information
For a full list of Active Directory Authentication and authorization error codes, see Azure
AD Authentication and authorization error codes.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Error AADSTS50011: The redirect URI
specified in the request does not match
Article • 12/08/2022 • 2 minutes to read

This article describes a problem in which an AADSTS50011 error message is returned

when you try to sign in to an application that uses OpenID Connect (OIDC)-based single
sign-on (SSO) with Azure Active Directory (Azure AD).

Symptoms
You receive the following error message when you try to sign in to an application that
uses OIDC or OAuth2 authentication protocols with Azure AD:

Error AADSTS50011 - The redirect URI <Redirect URI> specified in the request does
not match the redirect URIs configured for the application <GUID>. Make sure the
redirect URI sent in the request matches one added to your application in the Azure
portal. Navigate to https://aka.ms/redirectUriMismatchError to learn more about
how to fix this.

Cause
This error occurs if the redirect URI that the application sent doesn't match any of the
redirect URIs that are registered on the application itself.

When the user tries to sign in to the application by using OIDC or OAuth2 SSO, the login
server (Azure AD) has to know where to send the authorization code or access token
that proves that the user has been successfully authenticated. The application notifies
Azure AD by sending the redirect URI together with the login request. However, the
protocol specifications require that the redirect URI that the application sends must
also be registered on the application itself.

Resolution
To fix the issue, follow these steps:

1. Copy the <GUID> value from the error message. This is your application (client) ID.

2. Go to the Authentication blade of your application in the Azure portal. You can
open the page directly by inserting your application ID as the GUID value in one of
 the following links:

If this app is owned by an organization (Azure AD tenant), use

https://portal.azure.com/#blade/Microsoft_AAD_RegisteredApps/Application

MenuBlade/Authentication/appId/<GUID> . Make sure that you sign in to the

portal by using an administrator account for that organization, or an account
that owns the application.
If this app is owned by your personal Microsoft (MSA) account, use
https://portal.azure.com/#blade/Microsoft_AAD_RegisteredApps/Application

MenuBlade/Authentication/appId/<GUID>/isMSAApp/true . Make sure that you

sign in to the portal by using your personal Microsoft account.

3. Copy the <redirect URI> value from the error message.

4. Add the redirect URI to the appropriate platform configuration. This might be the
web, single page app, or some public/native client platform. Make sure to save the
input after the redirect URI is added.

5. Wait three to five minutes for the changes to take effect, and then send the log-in
request again. You should now be able to sign in to the application.

７ Note

The redirect URI is also known as the reply URL. These values depend on which
protocol is used. OIDC and OAuth2 protocols refer to this value as a redirect URI.

The following video shows how to fix the redirect URI mismatch error in Azure AD:

[!VIDEO https://www.youtube.com/embed/a_abaB7494s ]

More information
For a full list of Active Directory authentication and authorization error codes, see Azure
AD Authentication and authorization error codes.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Error AADSTS50020 - User account from
identity provider does not exist in
tenant
Article • 04/20/2022 • 7 minutes to read

This article helps you troubleshoot error code AADSTS50020 that's returned if a guest
user from an identity provider (IdP) can't sign in to a resource tenant in Azure Active
Directory (Azure AD).

Symptoms
When a guest user tries to access an application or resource in the resource tenant, the
sign-in fails, and the following error message is displayed:

AADSTS50020: User account 'user@domain.com' from identity provider

{IdentityProviderURL} does not exist in tenant {ResourceTenantName}.

When an administrator reviews the sign-in logs on the home tenant, a "90072" error
code entry indicates a sign-in failure. The error message states:

User account {email} from identity provider {idp} does not exist in tenant {tenant}
and cannot access the application {appId}({appName}) in that tenant. The account
needs to be added as an external user in the tenant first. Sign out and sign in again
with a different Azure Active Directory user account.

Cause 1: Used unsupported account type

(multitenant and personal accounts)
If your app registration is set to a single-tenant account type, users from other
directories or identity providers can't sign in to that application.

Solution: Change the sign-in audience setting in the app

registration manifest
To make sure that your app registration isn't a single-tenant account type, perform the
following steps:
 1. In the Azure portal , search for and select App registrations.

2. Select the name of your app registration.

3. In the sidebar, select Manifest.

4. In the JSON code, find the signInAudience setting.

5. Check whether the setting contains one of the following values:

AzureADandPersonalMicrosoftAccount
AzureADMultipleOrgs
PersonalMicrosoftAccount

If the signInAudience setting doesn't contain one of these values, re-create the
app registration by having the correct account type selected. You currently can't
change signInAudience in the manifest.

For more information about how to register applications, see Quickstart: Register an
application with the Microsoft identity platform.

Cause 2: Used the wrong endpoint (personal

and organization accounts)
Your authentication call must target a URL that matches your selection if your app
registration's supported account type was set to one of the following values:

Accounts in any organizational directory (Any Azure AD directory - Multitenant)

Accounts in any organizational directory (Any Azure AD directory - Multitenant)

and personal Microsoft accounts (e.g. Skype, Xbox)

Personal Microsoft accounts only

If you use https://login.microsoftonline.com/<YourTenantNameOrID> , users from other

organizations can't access the application. You have to add these users as guests in the
tenant that's specified in the request. In that case, the authentication is expected to be
run on your tenant only. This scenario causes the sign-in error if you expect users to sign
in by using federation with another tenant or identity provider.

Solution: Use the correct sign-in URL

Use the corresponding sign-in URL for the specific application type, as listed in the
following table:
 Application type Sign-in URL

Multitenant applications https://login.microsoftonline.com/organizations

Multitenant and personal accounts https://login.microsoftonline.com/common

Personal accounts only https://login.microsoftonline.com/consumers

In your application code, apply this URL value in the Authority setting. For more
information about Authority , see Microsoft identity platform application configuration
options.

Cause 3: Signed in to the wrong tenant

When users try to access your application, either they're sent a direct link to the
application, or they try to gain access through https://myapps.microsoft.com . In either
situation, users are redirected to sign in to the application. In some cases, the user might
already have an active session that uses a different personal account than the one that's
intended to be used. Or they have a session that uses their organization account
although they intended to use a personal guest account (or vice versa).

To make sure that this scenario is the issue, look for the User account and Identity
provider values in the error message. Do those values match the expected combination

or not? For example, did a user sign in by using their organization account to your
tenant instead of their home tenant? Or did a user sign in to the live.com identity
provider by using a different personal account than the one that was already invited?

Solution: Sign out, then sign in again from a different

browser or a private browser session
Instruct the user to open a new in-private browser session or have the user try to access
from a different browser. In this case, users must sign out from their active session, and
then try to sign in again.

Cause 4: Guest user wasn't invited

The guest user who tried to sign in was not invited to the tenant.

Solution: Invite the guest user

Make sure that you follow the steps in Quickstart: Add guest users to your directory in
the Azure portal to invite the guest user.

Cause 5: App requires user assignment

If your application is an enterprise application that requires user assignment, error
AADSTS50020 occurs if the user isn't on the list of allowed users who are assigned access

to the application. To check whether your enterprise application requires user

assignment:

1. In the Azure portal , search for and select Enterprise applications.

2. Select your enterprise application.

3. In the sidebar, select Properties.

4. Check whether the Assignment required option is set to Yes.

Solution: Assign access to users individually or as part of

a group
Use one of the following options to assign access to users:

To individually assign the user access to the application, see Assign a user account
to an enterprise application.

To assign users if they're a member of an assigned group or a dynamic group, see

Manage access to an application.

Cause 6: Tried to use a resource owner

password credentials flow for personal
accounts
If a user tries to use the resource owner password credentials (ROPC) flow for personal
accounts, error AADSTS50020 occurs. The Microsoft identity platform supports ROPC only
within Azure AD tenants, not personal accounts.

Solution: Use an endpoint that's specific to the tenant or

organization
Use a tenant-specific endpoint ( https://login.microsoftonline.com/<TenantIDOrName> )
or the organization's endpoint. Personal accounts that are invited to an Azure AD tenant
can't use ROPC. For more information, see Microsoft identity platform and OAuth 2.0
Resource Owner Password Credentials.

Cause 7: A previously deleted user name was

re-created by the home tenant administrator
Error AADSTS50020 might occur if the name of a guest user who was deleted in a
resource tenant is re-created by the administrator of the home tenant. To verify that the
guest user account in the resource tenant isn't associated with a user account in the
home tenant, use one of the following options:

Verification option 1: Check whether the resource tenant's

guest user is older than the home tenant's user account
The first verification option involves comparing the age of the resource tenant's guest
user against the home tenant's user account. You can make this verification by using
Microsoft Graph or MSOnline PowerShell.

Microsoft Graph

Issue a request to the MS Graph API to review the user creation date, as follows:

HTTP

GET https://graph.microsoft.com/v1.0/users/{id |
userPrincipalName}/createdDateTime

Then, check the creation date of the guest user in the resource tenant against the
creation date of the user account in the home tenant. The scenario is confirmed if the
guest user was created before the home tenant's user account was created.

MSOnline PowerShell

７ Note

The MSOnline PowerShell module is set to be deprecated.

Because it's also
incompatible with PowerShell Core, make sure that you're using a compatible
PowerShell version so that you can run the following commands.
Run the Get-MsolUser PowerShell cmdlet to review the user creation date, as follows:

Azure PowerShell

Get-MsolUser -SearchString user@contoso.com | Format-List whenCreated

Then, check the creation date of the guest user in the resource tenant against the
creation date of the user account in the home tenant. The scenario is confirmed if the
guest user was created before the home tenant's user account was created.

Verification option 2: Check whether the resource tenant's

guest alternative security ID differs from the home
tenant's user net ID

７ Note

The MSOnline PowerShell module is set to be deprecated.

Because it's also
incompatible with PowerShell Core, make sure that you're using a compatible
PowerShell version so that you can run the following commands.

When a guest user accepts an invitation, the user's LiveID attribute (the unique sign-in
ID of the user) is stored within AlternativeSecurityIds in the key attribute. Because the
user account was deleted and created in the home tenant, the NetID value for the
account will have changed for the user in the home tenant. Compare the NetID value of
the user account in the home tenant against the key value that's stored within
AlternativeSecurityIds of the guest account in the resource tenant, as follows:

1. In the home tenant, retrieve the value of the LiveID attribute using the Get-
MsolUser PowerShell cmdlet:

Azure PowerShell

Get-MsolUser -SearchString tuser1 | Select-Object -ExpandProperty

LiveID

2. In the resource tenant, convert the value of the key attribute within
AlternativeSecurityIds to a base64-encoded string:

Azure PowerShell
 [convert]::ToBase64String((Get-MsolUser -ObjectId 01234567-89ab-cdef-
0123-456789abcdef

).AlternativeSecurityIds.key)

3. Convert the base64-encoded string to a hexadecimal value by using an online

converter (such as base64.guru ).

4. Compare the values from step 1 and step 3 to verify that they're different. The
NetID of the user account in the home tenant changed when the account was
deleted and re-created.

Solution: Reset the redemption status of the guest user

account
Reset the redemption status of the guest user account in the resource tenant. Then, you
can keep the guest user object without having to delete and then re-create the guest
account. You can reset the redemption status by using the Azure portal, Azure
PowerShell, or the Microsoft Graph API. For instructions, see Reset redemption status for
a guest user.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Error AADSTS50105 - The signed in user
is not assigned to a role for the
application
Article • 06/15/2022 • 2 minutes to read

This article provides a resolution to the AADSTS50105 error that occurs during federated
authentication with Azure Active Directory (Azure AD).

Symptoms
You receive the following error when trying to sign into an application that has been set
up to use Azure AD for identity management using SAML-based Single Sign-On (SSO):

Error AADSTS50105 - The signed in user is not assigned to a role for the application.

Cause
The user hasn't been granted access to the application in Azure AD. The user must
belong to a group that is assigned to the application, or be assigned directly.

７ Note

Nested groups are not supported, and the group must be directly assigned to the
application.

Resolution
To assign one or more users to an application directly, see Quickstart: Assign users to an
app.

More Information
For a full list of Active Directory authentication and authorization error codes, see Azure
AD Authentication and authorization error codes.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Error AADSTS650056 - Misconfigured
application
Article • 09/07/2022 • 2 minutes to read

This article describes a problem in which you receive the following error message when
trying to sign into a SAML-based single sign-on (SSO) configured app that has been
integrated with Azure Active Directory (Azure AD):

Error AADSTS650056 - Misconfigured application. This could be due to one of the

following: the client has not listed any permissions for '{name}' in the requested
permissions in the client's application registration. Or, the admin has not consented
in the tenant. Or, check the application identifier in the request to ensure it matches
the configured client application identifier. Or, check the certificate in the request to
ensure it's valid. Please contact your admin to fix the configuration or consent on
behalf of the tenant. Client app ID: {id}. Please contact your admin to fix the
configuration or consent on behalf of the tenant.

Symptoms
You receive error AADSTS650056 when trying to sign into an application that has been
setup to use Azure AD for identity management using SAML-based SSO.

Cause
The Issuer attribute sent from the application to Azure AD in the SAML request doesn’t
match the Identifier value configured for the application in Azure AD.

Resolution
Ensure that the Issuer attribute in the SAML request matches the Identifier value
configured in Azure AD.

Verify that the value in the Identifier textbox matches the value for the identifier value
displayed in the error.

For more information about the Issuer attribute, see Single Sign-On SAML protocol.

More Information
For a full list of Active Directory authentication and authorization error codes see Azure
AD Authentication and authorization error codes.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Error AADSTS70001 - Application with
Identifier was not found in the directory
Article • 10/12/2022 • 2 minutes to read

This article describes a problem in which you receive the error message "Error
AADSTS70001 - Application with Identifier was not found in the directory." when trying
to sign into a SAML-based single sign-on (SSO) configured app that has been integrated
with Azure Active Directory (Azure AD).

Symptoms
You receive error AADSTS70001 when trying to sign into an application that has been set
up to use Azure AD for identity management using SAML-based SSO.

Cause
The Issuer attribute sent from the application to Azure AD in the SAML request doesn’t
match the Identifier value that's configured for the application in Azure AD.

Resolution
Ensure that the Issuer attribute in the SAML request matches the Identifier value
configured in Azure AD.

On the SAML-based SSO configuration page, in the Basic SAML configuration section,
verify that the value in the Identifier textbox matches the value for the identifier value
displayed in the error. If there's a trailing slash at the end of the url, it should be also
included.

Using the Test SSO Function in the Azure AD Portal

The Azure AD Portal can help you troubleshoot SAML configuration errors.
 1. In the Azure AD portal, go to Enterprise Applications and click on the application
needing troubleshooting.
2. Navigate to the Single sign-on page using the left-hand navigation menu
3. Click on Test this application to use the Test SSO functionality.
4. Copy and paste the error received into the Resolving Errors section and click Get
resolution guidance
5. View the difference between the Issuer and Identifier found.
6. Correct either the Issuer or Identifier.

More Information
For a full list of Active Directory Authentication and authorization error codes, see Azure
AD Authentication and authorization error codes

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Error - AADSTS75011 Authentication
method by which the user authenticated
with the service doesn't match
requested authentication method
AuthnContextClassRef
Article • 09/07/2022 • 2 minutes to read

This article describes a problem in which you receive the error message "Error -
AADSTS75011 Authentication method by which the user authenticated with the service
doesn't match requested authentication method AuthnContextClassRef." when trying to
sign into a SAML-based single sign-on (SSO) configured app that has been integrated
with Azure Active Directory (Azure AD).

Symptoms
You receive error AADSTS75011 when trying to sign into an application that has been
setup to use Azure AD for identity management using SAML-based SSO.

Cause
The RequestedAuthnContext is in the SAML request. This means the app is expecting the
AuthnContext specified by the AuthnContextClassRef . However, the user has already
authenticated prior to access the application and the AuthnContext (authentication
method) used for that previous authentication is different from the one being
requested. For example, a federated user access to MyApps and WIA occurred. The
AuthnContextClassRef will be urn:federation:authentication:windows . AAD won’t

perform a fresh authentication request, it will use the authentication context that was
passed-through it by the IdP (ADFS or any other federation service in this case).
Therefore, there will be a mismatch if the app requests other than
urn:federation:authentication:windows . Another scenario is when MultiFactor was used:
'X509, MultiFactor .

Resolution
RequestedAuthnContext is an optional value. Then, if possible, ask the application if it

could be removed.

Another option is to make sure the RequestedAuthnContext will be honored. This will be
done by requesting a fresh authentication. By doing this, when the SAML request is
processed, a fresh authentication will be done and the AuthnContext will be honored. To
request a Fresh Authentication the SAML request must contain the value
forceAuthn="true" .

More Information
For a full list of Active Directory Authentication and authorization error codes see Azure
AD Authentication and authorization error codes

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Error AADSTS75005 - The request is not
a valid Saml2 protocol message
Article • 09/07/2022 • 2 minutes to read

This article describes a problem in which you receive the error message "Error
AADSTS75005 - The request is not a valid Saml2 protocol message." when you try to
sign into an apapplication that has been integrated with Azure Active Directory (Azure
AD).

Symptoms
You receive error AADSTS75005 when trying to sign into an application that has been set
up to use Azure AD for identity management using SAML-based SSO.

Cause
Azure AD doesn't support the SAML request sent by the application for single sign-on.
Some common issues are:

Missing required fields in the SAML request.

SAML request encoded method.

Resolution
1. Capture the SAML request. Follow the tutorial How to debug SAML-based single
sign-on to applications in Azure AD to learn how to capture the SAML request.
2. Contact the application vendor and share the following info:

SAML request
Azure AD Single Sign-on SAML protocol requirements

The application vendor should validate that they support the Azure AD SAML
implementation for single sign-on.

More Information
For a full list of Active Directory Authentication and authorization error codes, see Azure
AD Authentication and authorization error codes
Contact us for help
If you have questions or need help, create a support request , or ask Azure community
support.
Error AADSTS750054 - SAMLRequest or
SAMLResponse must be present as
query string parameters in HTTP
request for SAML Redirect binding
Article • 10/12/2022 • 2 minutes to read

This article describes a problem in which you receive the error message "Error
AADSTS750054 - SAMLRequest or SAMLResponse must be present as query string
parameters in HTTP request for SAML Redirect binding." when trying to sign into a
SAML-based single sign-on (SSO) configured app that has been integrated with Azure
Active Directory (Azure AD).

Symptoms
You receive error AADSTS750054 when trying to sign into an application that has been
setup to use Azure AD for identity management using SAML-based SSO.

Cause
Azure AD wasn’t able to identify the SAML request within the URL parameters in the
HTTP request. This can happen if the application is not using HTTP redirect binding
when sending the SAML request to Azure AD.

Resolution
The application needs to send the SAML request encoded into the location header using
HTTP redirect binding. For more information about how to implement it, read the
section HTTP Redirect Binding in the SAML protocol specification document .

Most often, the error is due to one of the following issues:

1. Ensure that single-sign on is enabled on the application side.

2. The application must support service provider-initiated single sign-on (sometimes
known as SP-initiated SSO). When entering a sign-in URL for an application that
only supports identity provider-initiated single sign-on can lead to a bounce back
from the application without a SAML response.
3. Verify that the sign-on URL is correctly configured.
Using the Test SSO Function in the Azure AD Portal
The Azure AD Portal can help you troubleshoot SAML configuration errors.

1. In the Azure AD portal, go to Enterprise Applications and click on the application

needing troubleshooting.
2. Navigate to the Single sign-on page using the left-hand navigation menu
3. Click on Test this application to use the Test SSO functionality.
4. Copy and paste the error received into the Resolving Errors section and click Get
resolution guidance
5. Follow the steps to troubleshoot error AADSTS750054

More Information
For a full list of Active Directory Authentication and authorization error codes see Azure
AD Authentication and authorization error codes

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Problems signing in to SAML-based
Single Sign-On configured apps
Article • 06/15/2022 • 2 minutes to read

To troubleshoot the sign-in issues below, we recommend the following to better

diagnosis and automate the resolution steps:

Install the My Apps Secure Browser Extension to help Azure Active Directory (Azure
AD) to provide better diagnosis and resolutions when using the testing experience
in the Azure portal.
Reproduce the error using the testing experience in the app configuration page in
the Azure portal. Learn more on Debug SAML-based Single Sign-On applications

If you use the testing experience in the Azure portal with the My Apps Secure Browser
Extension, you don't need to manually follow the steps below to open the SAML-based
Single Sign-On configuration page.

To open the SAML-based Single Sign-On configuration page:

1. Open the Azure portal and sign in as a Global Administrator or Coadmin.

2. Open the Azure Active Directory Extension by selecting All services at the top of
the main left-hand navigation menu.

3. Type “Azure Active Directory" in the filter search box and select the Azure Active
Directory item.

4. Select Enterprise Applications from the Azure Active Directory left-hand

navigation menu.

5. Select All Applications to view a list of all your applications.

If you do not see the application you want show up here, use the Filter control at
the top of the All Applications List and set the Show option to All Applications.

6. Select the application you want to configure for Single Sign-On.

7. Once the application loads, select Single Sign-On from the application’s left-hand
navigation menu.

8. Select SAML-based SSO.

General troubleshooting
Problem when customizing the SAML claims sent to an
application
To learn how to customize the SAML attribute claims sent to your application, see
Claims mapping in Azure Active Directory.

Errors related to misconfigured apps

Verify both the configurations in the portal match what you have in your app.
Specifically, compare Client/Application ID, Reply URLs, Client Secrets/Keys, and App ID
URI.

Compare the resource you’re requesting access to in code with the configured
permissions in the Required Resources tab to make sure you only request resources
you’ve configured.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Azure Active Directory is sending the
token to an incorrect reply URL
endpoint or localhost
Article • 09/07/2022 • 2 minutes to read

This article describes a problem in which Azure Active Directory is sending the token to
an incorrect reply URL endpoint or localhost.

Symptoms
During single sign-on, if the sign-in request does not contain an explicit reply URL
(Assertion Consumer Service URL) then Azure AD will select any of the configured reply
URLs for that application. Even if the application has an explicit reply URL configured,
the user may be to redirected https://127.0.0.1:444 .

When the application was added as a non-gallery app, Azure Active Directory created
this reply URL as a default value. This behavior has changed and Azure Active Directory
no longer adds this URL by default.

Cause
The user has not been granted access to the application in Azure AD.

Resolution
Delete the unused reply URLs configured for the application.

On the SAML-based SSO configuration page, in the Reply URL (Assertion Consumer
Service URL) section, delete unused or default Reply URLs created by the system. For
example, https://127.0.0.1:444/applications/default.aspx .

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
An exception occurs when you sign in to
an app that's set up for Azure B2C
Article • 04/20/2022 • 2 minutes to read

Original product version:   Azure Active Directory

Original KB number:   3092592

Symptoms
When you try to sign up for, or sign in to, an app that's set up for Microsoft Azure B2C,
you receive the following error message:

Server Error in '/' Application"

Response status code does not indicate success: 404 (Not Found)

Description : An unhandled exception occurred during the execution of the current

web request. Please review the stack trace for more information about the error and
where it originated in the code.

Exception Details : System.Net.WebException: The remote server returned an error.

404 (Not Found)

Source Error :

Line 106: {

Line 107: ...

Line 108: OpenIdConnectConfiguration config = await mgr.GetConfigurationAsync();

Line 109: ...

Line 110: }

Cause
This problem occurs if the Policy Name setting for sign-in, password reset, or the user
profile is missing or incorrect in the web.config file for your app.

Resolution
To resolve this issue, follow these steps:

1. Open the web.config file for your app.

 2. In this file, verify the following:

The ida:SignInPolicyId app key exists, and you've replaced the value with the
name of the Sign-in policy that you provided in the Azure B2C Admin Portal.
The ida:PasswordResetPolicyId app key exists, and you've replaced the value
with the name of the Sign-in policy that you provided in the Azure B2C
Admin Portal.
The ida:UserProfilePolicyId app key exists, and you've replaced the value with
the name of the Sign-in policy that you provided in the Azure B2C Admin
Portal.

The web.config file should resemble the following:

Console

<appSettings>

...

<add key="ida:SignInPolicyId" value="B2C_Signin_Policy">

<add key="ida:PasswordResetPolicyId" value="B2C_PasswordReset_Policy">

<add key="ida:UserProfilePolicyId" value="B2C_UserProfile_Policy">

...

</appSettings>

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Error when you try to delete a B2C
directory in Azure AD: Cannot delete
'<contoso>'
Article • 04/20/2022 • 2 minutes to read

This article describes an issue in which an error occurs when you try to delete a B2C
directory in Azure Active Directory.

Original product version:   Azure Active Directory

Original KB number:   3112170

Symptoms
In a Microsoft Azure Active Directory environment, you set up a B2C directory, and then
you try to delete it. However, you receive the following error message:

Cannot delete '<contoso>'

The following issue(s) prevent deletion of the directory:

Directory contains one or more applications that were added by a user or

administrator

Cause
This problem occurs if existing B2C application service principals (for example, CPIM,
Ibiza Portal, and SSPR) are blocking the deletion.

Resolution
To fix this issue, use the Azure portal.

Step 1: Delete all apps that are listed on the Azure AD B2C
Dashboard
To do this, follow these steps:

1. Sign in Azure portal as an administrator who has access to the Azure AD B2C
directory.
2. Select your display name in the upper-right corner, and then select the directory
that's your B2C directory.

７ Note

If you have only one directory, your Azure AD B2C directory will already be
selected.

3. To find the Azure AD B2C blade, select the More Services (>) button in the lower-
left corner, and then search on "B2C".

4. Select Azure AD B2C.

5. Select All Settings, and then select Applications.

6. Delete all applications. To do this, select the application, select Properties, and
then select the Delete button.
Step 2: Delete the Azure AD B2C tenant
To do this, follow these steps:

1. In the Azure AD B2C directory, locate and select the Azure Active Directory blade
in the Azure portal.

2. On the Overview menu, select Delete Directory.

3. Follow the instructions in the portal.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Error occurs when you try to sign in to
an app that's set up for Azure AD B2C
Article • 04/20/2022 • 2 minutes to read

This article describes an error that occurs when you try to sign in to an app that's set up
for Azure AD B2C.

Original product version:   Azure Active Directory

Original KB number:   3092587

Symptoms
When you try to sign in to an app that is set up for Microsoft Azure Active Directory
(AD) business to consumer (B2C), you receive the following error message:

Sorry, but we're having trouble signing you in

We track these errors automatically, but if the problem persists feel free to contact
us. In the meantime, please try again.

Your administrator hasn't provided any contact details

Correlation ID:xxxxxxxx-xxxx-
xxxx-xxxx-xxxxxxxxxxxx

Timestamp:yyyy-mm-dd hh:mm:ssZ

AADB2C: An exception has occurred

Cause
The client ID may be missing or incorrect in the Web.config file for the app.

Resolution
To fix this issue, follow these steps:

1. Open the Web.config file for the app.

2. In the Web.config file, find the app key ida:ClientId.

3. Replace the value of the app key with the client ID that is provided for your app in
the Azure AD B2C admin portal.

The changed part of the file resembles the following:

 Console

<appSettings>

<add key="ida:ClientId" value="**xxxxxxxx-xxxx-xxxx-xxxx-

xxxxxxxxxxxx**">

</appSettings>

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Error when you try to sign in to an app
that is set up for Azure AD B2C: Server
Error in '/' Application
Article • 04/20/2022 • 2 minutes to read

This article describes an error that occurs when trying to sign in to an app that is set up
for Azure AD B2C.

Original product version:   Azure Active Directory

Original KB number:   3092588

Symptoms
When you try to sign in to an app that is set up for Microsoft Azure Active Directory
(AD) business to consumer (B2C), you receive the following error message:

Server Error in '/' Application

Response status code does not indicate success: 404 (Not Found)

Description : An unhandled exception occurred during the execution of the current

web request. Please review the stack trace for more information about the error and
where it originated in the code.

Exception Details : System.Net.Http.HttpRequestException: Response status code

does not indicate success: 404 (Not Found)

Source Error : An unhandled exception occurred during the execution of the current
web request. Information regarding the origin and locations of the exception can be
identified using the exception stack trace below.

Stack Trace :

...

[IOException: Unable to get document from:

https://login.microsoftonline.com/contoso.onmicrosoft.com/.well-known/openid-
configuration?p=Policyname ]

Cause
The sign-up policy name may be missing or incorrect in the Web.config file for the app.

Resolution
To fix this issue, follow these steps:

1. Open the Web.config file for the app.

2. In the Web.config file, verify that the app key ida:SignUpPolicyId exists.

3. Replace the value of the app key with the name of the sign-up policy that you
provided in the Azure AD B2C admin portal.

The changed part of the file resembles the following:

Console

<appSettings>

<add key="ida:SignUpPolicyId" value="B2C_Signup_Policy_Name">

</appSettings>

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Can't delete a directory through the
Azure Management Portal
Article • 04/20/2022 • 3 minutes to read

This article can help you fix an issue in which you can't delete a directory from the Azure
Active Directory extension in Azure portal.

Original product version:   Azure Active Directory

Original KB number:   2967860

Symptoms
You can't delete a directory from the Microsoft Azure Active Directory extension through
the Azure Management Portal. Additionally, you receive one of the following messages:

You are signed in as a user for whom <Your Company Name> is the home directory.

Delete all users except yourself.

Directory has one or more subscriptions to Microsoft Online Services.

Directory has one or more Azure subscriptions.

Directory has one or more applications.

Directory has one or more Multi-Factor Authentication providers.

Directory is a "Partner" directory.

Directory contains one or more applications that were added by a user or

administrator.

You are signed in as a user for whom <Your

Company Name> is the home directory
Make sure that your directory has no home users, and then delete the directory. The
user who deletes this directory must be a guest user, must be homed in another
directory, and must be a global admin of the directory that is being deleted.

For example, your directory has the domains contoso.onmicrosoft.com and contoso.com .
There must be no users who have these domains in your directory. The guest user may
be a Microsoft account or may be homed from another directory such as
fabrikam.onmicrosoft.com .

To learn more about how to add a guest user, see Create or edit users. When you create
this user in your directory, select one of the following:

A user who has an existing Microsoft account

A user in another Azure AD directory

This user must also be an admin of your Azure subscription.

Delete all users except yourself

Do what the message tells you to do. That is, delete all users except yourself.

Directory has one or more subscriptions to

Microsoft Online Services
Do you have one of the following subscriptions?

Office 365
Intune
Dynamics
Microsoft Azure Information Protection (previously known as Microsoft Azure
Rights Management)
Azure Active Directory Premium

If you have one of these subscriptions, contact billing and subscriptions support .

Do you have one of the following subscriptions?

Microsoft Enterprise Mobility + Security

Azure Active Directory Basic

If you have one of these subscriptions, contact your Volume Licensing partner to cancel
the subscription.

Directory has one or more Azure subscriptions

If you have an Azure subscription, make sure that your Azure subscription is not linked
to another directory. To do this, follow these steps:

1. In the navigation pane, select Settings, and select Subscriptions.

2. Notice the following information:

Subscription
Account administrator
Directory

3. If the directory that you are trying to delete is listed under any of the subscriptions,
the account administrator has to sign in and change the directory that is
associated with the subscription. To do this, the account administrator should
follow these steps:
a. On this screen, select Edit Directory.
b. In the Edit Directory window, select the Directory list, and then change the
directory.

７ Note

If no other directory is available as an option, the account administrator must be a

global admin of another directory or must create a new directory. You will see the
Edit Directory option if the account is a Microsoft account. Organizational accounts
can't change the directory. Therefore, the directory can't be deleted.

Directory has one or more applications

To learn how to remove applications from your directory, read Adding, updating, and
removing an application

You may also have to remove additional service principals. Use Azure Active Directory
Module for Windows PowerShell to remove all service principals. To do this, follow these
steps:

1. Open Azure Active Directory Module for Windows PowerShell.

2. Connect to the Microsoft Online Service.

3. Run the following command:

PowerShell
 Get-MsolServicePrincipal | Remove-MsolServicePrincipal

７ Note

You may receive an error when you remove some service principals. These
principals can't be removed. However, this does not prevent you from
deleting your directory. The error that you receive may resemble the
following:

Remove-MsolServicePrincipal : Invalid value for parameter. Parameter Name:

appPrincipalId.

Directory has one or more Multi-Factor

Authentication providers
Remove Azure multi-factor authentication providers for your directory. For information
about how do this, see Plan an Azure Multi-Factor Authentication deployment.

Directory is a 'Partner' directory

Contact Microsoft Partner Support at Microsoft Partner Site .

Directory contains one or more applications

that were added by a user or administrator
To fix this issue, follow the steps in "Cannot delete" error when you try to delete a B2C
directory in Azure AD .

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
You can't open the Azure Active
Directory Module for Windows
PowerShell
Article • 04/20/2022 • 2 minutes to read

Original product version:   Cloud Services (Web roles/Worker roles), Azure Active
Directory, Microsoft Intune, Azure Backup, Office 365 User and Domain Management,
Office 365 Identity Management

Original KB number:   2461873

Symptoms
When you try to open the Microsoft Azure Active Directory Module for Windows
PowerShell, the Windows PowerShell console window opens with many text errors
indicating that module packages couldn't be loaded.

Cause
This issue occurs if you don't have the Microsoft .NET Framework 3.51 enabled on your
computer.

Resolution
To resolve this issue, manually enable the .NET Framework 3.51. To do this, follow these
steps, as appropriate for the operating system that you're running:

In Windows 2008 R2:

1. Open Server Manager.

2. Select Features, select Add Features, select .NET Framework 3.51 Features, and
then select .NET Framework 3.51.

In Windows 7:

1. Open Programs and Features.

2. Select Turn Windows features on or off.
3. Select to select the Microsoft NET Framework 3.51 check box, and then select OK.
Contact us for help
If you have questions or need help, create a support request , or ask Azure community
support.
Error when you try to reset your
password in Azure, Office 365, or
Intune: We could not verify your
account
Article • 04/20/2022 • 2 minutes to read

This article describes a problem in which you receive an error message "We could not
verify your account" when you try to reset your password in Microsoft Azure, Office 365,
or Microsoft Intune. To resolve this problem, work with your administrator to update
your telephone number.

Original product version:   Azure Active Directory, Microsoft Intune, Cloud Services (Web
roles/Worker roles)

Original KB number:   2951246

Symptoms
When you use Microsoft Azure, Microsoft Office 365, or Microsoft Intune, you may
receive the following error message when you try to reset your password:

We could not verify your account.

Cause
This problem may occur because there are no telephone numbers on file for you.

Resolution
To resolve this problem, work with your administrator to update your telephone
number(s).

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Error when you run Azure PowerShell
cmdlets: Method invocation failed
Article • 04/20/2022 • 2 minutes to read

This article discusses an issue in which you receive an error message "Method invocation
failed because [System.Object[]] doesn't contain a method named 'RemoveAll'." when
you run Azure PowerShell cmdlets.

Original product version:   Azure Active Directory, Cloud Services (Web roles/Worker
roles)

Original KB number:   3072418

Symptoms
When you run Windows Azure PowerShell cmdlets, you receive an error message that
resembles the following message:

Method invocation failed because [System.Object[]] doesn't contain a method

named 'RemoveAll'.

Cause
This problem occurs for either of the following reasons:

You are using an outdated version of Azure PowerShell.

You are using a method name that does not exist.

Resolution
To resolve this problem, do either of the following:

Install the latest version of Azure PowerShell. To upgrade the program, see How to
install and configure Azure PowerShell.
Make sure that you are using the correct method name.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Changes to your password are not saved
in Azure, Office 365, or Intune
Article • 04/20/2022 • 2 minutes to read

Original product version:   Cloud Services (Web roles/Worker roles), Microsoft Intune

Original KB number:   2951280

Symptoms
When you change your password in Microsoft Azure, Microsoft Office 365, or Microsoft
Intune and then select Finish to save your changes, the changed password is not saved.

Cause
This problem occurs when you use special characters such as the less-than sign < or the
greater-than sign > as part of your password.

Resolution
To resolve this problem, do not use special characters as part of your password.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Pending devices in Azure Active
Directory
Article • 11/08/2022 • 2 minutes to read

Pending devices are devices that are synced to Azure Active Directory (Azure AD) from
your on-premises Active Directory, but haven't completed registration with the Azure
AD device registration service. When the registered state of a device is pending, the
device can't complete any authorization or authentication requests, such as requesting a
Primary Refresh token for single sign-on, or applying device-based Conditional Access
policies.

７ Note

The pending state exists only for hybrid Azure AD-joined devices.

Why a device might be in a pending state

When you configure a Hybrid Azure AD join task in the Azure AD Connect Sync for your
on-premises devices, the task will sync the device objects to Azure AD, and temporarily
set the registered state of the devices to "pending" before the device completes the
device registration. This is because the device must be added to the Azure AD directory
before it can be registered. For more information about the device registration process,
see How it works: Device registration.

For more information about how to troubleshoot pending devices, see the following
video:
https://www.youtube-nocookie.com/embed/QBR1c81kaxA

How a device gets stuck in a pending state

There are two scenarios in which a device can be stuck in a pending state.

Sync a new on-premises domain joined device to Azure

AD
A new on-premises device can get stuck in a pending state if it can't complete the
device registration process. This problem can be caused by several factors, such as that
the device can't connect to the registration service.
To troubleshoot a device registration problem, see:

Troubleshooting hybrid Azure Active Directory joined devices

Test Device Registration Connectivity

The state of a registered device is changed to pending

This problem can occur in the following scenario:

1. The device object is moved to another organizational unit (OU) that isn't in the
sync scope in Azure AD Connect Sync.
2. Azure AD Connect Sync recognizes this change as the device object being deleted
in the on-premises Active Directory. Therefore, it deletes the device in Azure AD.
3. The device object was moved back to the OU in the sync scope.
4. Azure AD Connect Sync creates a pending device object for this device in Azure
AD.
5. The device fails to complete the device registration process because it was
registered previously.

To fix the problem, unregister the device by running dsregcmd /leave at an elevated
command prompt, and restart the device. The device will reinitiate the device
registration process through the scheduled task. For Windows 10-based devices, the
scheduled task is under Task Scheduler Library > Microsoft > Windows > Workplace
Join > Automatic-Device-Join Task.

Get a list of pending devices

Count all pending devices

PowerShell

(Get-AzureADDevice -all $true | Where-Object{($_.DeviceTrustType -

eq"ServerAd") -and ($_.ProfileType -ne"RegisteredDevice") -and (-not
$_.AlternativeSecurityIds)}).count

Get all pending devices, and save the returned data in a CSV file

PowerShell

Get-AzureADDevice -all $true | Where-Object{($_.DeviceTrustType -

eq"ServerAd") -and ($_.ProfileType -ne"RegisteredDevice") -and (-not
$_.AlternativeSecurityIds)} | select-object -Property AccountEnabled,
ObjectId, DeviceId, DisplayName, DeviceOSType, DeviceOSVersion,
 DeviceTrustType | export-csv pendingdevicelist-summary.csv -
NoTypeInformation

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Can't perform a Workplace Join by
using Device Registration Services
Article • 04/20/2022 • 4 minutes to read

This article describes an issue in which a user can't join a device to a Workplace by using
Device Registration Services. It provides two resolutions.

Original product version:   Windows 8.1 Enterprise, Windows Server 2012 R2 Datacenter,
Windows Server 2012 R2 Standard, Azure Active Directory

Original KB number:   3045387

Symptoms
When a user tries to do a Workplace Join by using Device Registration Services, the user
receives one of the following messages:

The user receives the following message before providing the user's user name and
password:

Confirm you are using the current sign-in info, and that your workplace uses
this feature. Also, the connection to your workplace might not be working
right now. Please wait and try again.

The user receives the following message after the user provides the user's user
name and password:

Can't connect to the service.

Resolution
To resolve either of these problems, use the method that's appropriate for the situation.

Method 1
To fix the problem for message 1, review the Event logs on the client computer that's
trying to do a Workplace Join to determine the correct solution.

An administrator may see details in Event Viewer that resemble the following example:
Event ID: (See the following table for the Event ID.)

Log Name: Windows 7: Applications and Service Logs/Microsoft-Workplace-Join/Admin

Windows 8 or Windows 10: Applications and Service Logs/Microsoft-Windows-

Workplace-Join/Admin

Source: Microsoft-Windows-Workplace Join

Level: Error

Description: (See the following table for the Event ID description.)

Event Description Resolution

ID

103 Workplace Join discovery failed. Server returned http status 404. KB
3045386

103 Workplace Join discovery failed. Server returned http status 503. KB
3045388

102 Workplace Join discovery failed.

KB
3045385
Exit Code: 0x80072EE7.

The server name or address could not be resolved. Could not connect to
'https://EnterpriseRegistration.domainTEST.com:443/EnrollmentServer/contract?
api-version=1.0' .

102 Workplace Join discovery failed.

KB
3045384
Exit Code: 0x80072F19.

It was not possible to connect to the revocation server or a definitive response

could not be obtained. Could not connect to
'https://EnterpriseRegistration.domain.com:443/EnrollmentServer/contract?api-
version=1.0' .

102 Workplace Join discovery failed.

KB
3045383
Exit Code: 0x80072F8A.

The supplied certificate has been revoked. Could not connect to

'https://EnterpriseRegistration.domain.com:443/EnrollmentServer/contract?api-
version=1.0' .
 Event Description Resolution
ID

102 Workplace Join discovery failed.

KB
3045382
Exit Code: 0x80072F0D.

The certificate authority is invalid or incorrect. Could not connect to

'https://EnterpriseRegistration.domain.com:443/EnrollmentServer/contract?api-
version=1.0' .

102 Workplace Join discovery failed.

KB
3045381
Exit Code: 0x80072EFD.

A connection with the server could not be established. Could not connect to
'https://EnterpriseRegistration.domain.com:443/EnrollmentServer/contract?api-
version=1.0' .

102 Workplace Join discovery failed.

KB
3045380
Exit Code: 0x80004005.

An unknown error has occurred. Could not connect to

'https://EnterpriseRegistration.domain.com:443/EnrollmentServer/contract?api-
version=1.0' .

200 "The maximum number of devices that can be joined to the workplace by the user KB
has been reached." 3045379

Method 2
To fix the problem for message 2, see "Can't connect to the service" error when you try
to register a device .

More Information
To quickly troubleshoot these problems, try one or more of the following things.

Verify DNS
Verify the DNS configuration by using NSlookup , and verify that the answers are correct.
To do so, open a Command Prompt window, and then run the following command:

Console
 Nslookup enterpriseregistration.domain.com

If you use Azure Active Directory Join:

Should return CNAME result of EnterpriseRegistration.windows.net as the
target.
If you use Windows Server Workplace Join:
Internal host should return internal ADFS node.
External host should return external ADFS proxy address.  

Flush the DNS cache

Open a Command Prompt window as an administrator, and then run the following
command:

Console

ipconfig /FlushDNS

Verify that Device Registration is enabled

If you try to do Workplace Join to Azure Active Directory:

1. Sign in to the Azure portal, or start the Azure AD console from Microsoft 365
admin center as a Company Administrator.
2. Go to the directory where the user is trying to do the join.
3. Go to Configure.
4. Scroll down to the Device Registration section.
5. Make sure the setting labeled ENABLE WORKPLACE JOIN is toggled to Yes.
("Yes" will be blue.)

If you try to do Workplace Join to your local Active Directory domain, take the following
actions:

Open the Active Directory Federation Services (AD FS) management console.
Select Relying Party Trusts to determine whether the Device Registration
Service trust is enabled on each node of the AD FS farm.

Verify that the Active Directory Federation Services

service and the Device Registration Services service are
running
If you try to do a Workplace Join to your local Active Directory, you should log on to
each node of the AD FS farm and then follow these steps:

1. Go to Control Panel, Administrative Tools, and then Services (Services.msc).

2. Locate the Active Directory Federation Services service, and verify its status.
3. Locate the Device Registration Services service, and verify its status.
4. If either service isn't running, start the services.

Verify that the host name bindings are registered for each
node in the AD FS farm
If you try to do a Workplace Join to your local Active Directory, follow the steps at the
following Microsoft TechNet website:

Configure a Host Header for a Web Site (IIS 7)

Make sure that the host name (such as EnterpriseRegistration. domain_name.

domain_extension) is bound to port 443.

Update the root certificates

Run Microsoft Update , and make sure that the Updates for Root Certificates are all
installed

Verify that traffic is enabled if you're using a third-party

proxy or firewall server
If you try to do a Workplace Join to your local Active Directory, verify that there's a rule
to enable incoming TCP connections to EnterpriseRegistration. domain_name.
domain_extension. It should allow for traffic to pass through to the DRS server.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Error when you try to remove a user
from the recycle bin: Remove-MsolUser
User Not Found
Article • 04/20/2022 • 2 minutes to read

Original product version:   Office 365 Identity Management, Azure Active Directory,
Cloud Services (Web roles/Worker roles), Microsoft Intune, Azure Backup

Original KB number:   3019157

Symptoms
When you try to remove a user from the recycle bin (also sometimes known as the
Deleted Users container) in a Microsoft cloud service such as Microsoft Office 365,
Microsoft Intune, or Microsoft Azure, you receive the following error message:

Remove-MsolUser: User Not Found

For example, you experience these symptoms when you run the following cmdlet:

PowerShell

Remove-MsolUser -RemoveFromRecyleBin

Cause
This problem occurs if the user who is performing the action is not a global admin.

Resolution
Take one of the following actions:

Have someone assign the global admin role to you, and then remove the user
from the recycle bin.
Have a global admin remove the user from the recycle bin.
Wait 30 days. Deleted users will remain in the recycle bin for 30 days. After 30 days,
they are automatically removed from the recycle bin.
Contact us for help
If you have questions or need help, create a support request , or ask Azure community
support.
Set up your enterprise for
working remotely in Azure: FAQ
FAQ

This Azure Active Directory (Azure AD) and cloud services FAQ can help you manage
your IT Pro teams as they work remotely.

Original product version:   Azure Active Directory

Original KB number:   4559203

Frequently asked questions

I'm new to Microsoft Cloud. How can I

enable my employees to start working
remotely by using Microsoft Teams with
the free license that's offered by
Microsoft?
Microsoft offers a free E1 license for six months to enable your employees to increase
their productivity from home through Microsoft Teams. For information about licensing,
and to check your eligibility, go to: Manage the Office 365 E1 Trial.

What guidance is available to set up

Microsoft Teams from an Azure AD
perspective to work with my existing
on-premises deployment?
Your first step should be to consider your needs. For example, do you want to sync users
from on-premises to Azure AD, or do you want only to start a new cloud solution? You
can learn more about deployments here .
I work in education, and I have no
existing on-premises infrastructure.
How can I use Microsoft Teams for
educational purposes, such as online
teaching?
Microsoft offers a free A1 license for education. For information about licensing, go to
Get Office 365 free for your entire school .
The following documentation provides
useful information about how to enable remote learning at your school or university:

Get started with Microsoft Teams for remote learning

Create your Office 365 tenant account

My administrators also work from

home. How can I enable them to access
our internal servers remotely and in a
secure manner?
The answer depends on your current deployment. If you already have a VPN solution,
you can integrate it by using our multi-factor authentication (MFA) solution to add an
additional layer of security.

If you don't have a VPN solution yet, you can proceed with the deployment, and use a
Windows gateway to allow remote access by having MFA as an additional layer of
security.

Can you provide technical details to

help me enable MFA to allow remote
access to my internal servers if I'm using
a third-party VPN solution or a
Microsoft Windows gateway?
Yes, we provide technical guides.

If you have an Azure MFA server already in operation, and you have to use it, you can
create such a deployment by using an existing VPN solution or a Windows gateway.
(Notice that this kind of deployment has been deprecated, and only existing customers
can use it.)

Here are examples of MFA server integration with third-party VPNs:

Advanced scenarios with Azure MFA Server

Here's how to integrate Azure MFA server with gateway .

If you're using the MFA NPS extension, see the following articles for technical details:

Integrate your Remote Desktop Gateway infrastructure

Integrate your VPN infrastructure with Azure MFA

I want to enable Azure MFA. How can I

choose the type of MFA to use?
The following table provides multiple scenarios in which to deploy MFA.

Scenario Prerequisite

Cloud-only identity No additional prerequisite tasks

environment that uses
modern authentication

Hybrid identity scenarios Azure AD Connect is deployed, and user identities are
synchronized or federated with the on-premises Active
Directory Domain Services (AD DS) with Azure Active
Directory.

On-premises legacy Azure AD Application Proxy is deployed.

applications published
for cloud access

Using Azure MFA with A Network Policy Server (NPS) is deployed.

RADIUS Authentication
 Scenario Prerequisite

Users have Microsoft Upgrade to Microsoft Office 2013 or later and Apple Mail for
Office 2010 or earlier, or iOS 12 or later. Conditional access is not supported by legacy
Apple Mail for iOS 11 or authentication protocols.
earlier

For more information about how each MFA type works and when to use it, go to Plan an
Azure Multi-Factor Authentication deployment.

How can I enable users to be able to

reset their passwords directly from
Azure AD?
Azure AD provides several methods to achieve this based on your current scenario:

If the user has Azure Active Directory Premium and wants to enable SSPR-U (SSPR
for users), we recommend this option:

Enable Azure Active Directory self-service password reset

If the user doesn't have Azure Active Directory Premium, and uses an Active
Directory Federation Services (AD FS) for federation but doesn't have any SSPR, we
recommend this option:

If the user doesn't have Azure Active Directory premium but wants to use ADFS to
change the password endpoint, they must explicitly enable the endpoint (Update
password customization). They can do this also on a proxy endpoint. Doing this enables
the capability on AD FS.

Users can send a claim that is named "passwordchangeurl" for the URL as a claim to
Azure AD. Azure AD will honor this for Windows 10, Azure AD-joined workstations that
are running Windows 10, version 1703 or a later version. The user will be directed to the
URL that is shown in the claim when the user presses Ctrl+Alt+Del.

Here's are some sample references on claims in the context of AD FS:

Configure AD FS to Send Password Expiry Claims

I have a cloud-only deployment, and I
have to add Azure MFA as an additional
layer of security. Is there a free license
for this?
Yes. Azure AD Free or standalone Office 365 licenses use security defaults to require
MFA for users and administrators.

To learn how to manage your users' MFA settings, go to View the status for a user.

Is it worth connecting my user's devices

to Azure AD while they are working
remotely?
Azure AD enables single sign-on to devices, apps, and services from anywhere through
connected devices. IT professionals get the controls they must have to manage and
secure your organization's resources. For more information, go to Getting devices in
Azure AD.

What kinds of device types can connect

to Azure AD?
You can connect three kinds of devices to Azure AD: Azure AD Registered, Azure AD
Joined, or Hybrid Azure AD joined, depending on your infrastructure. For more
information, go to Getting devices in Azure AD.

Is an additional license required to

connect my device to Azure AD?
No. An additional license is not required. Because the Azure AD Free license is enabled
by default together with the Office 365 license, users can connect devices to Azure AD.
While working remotely, why can't I
access Office 365 services after I reset
my password from my Azure AD-joined
device?
After you reset your password, you have to log out and log back in by using the new
password.

While working remotely, why can't I

access Office 365 services after I reset
my password from my Hybrid Azure
AD-joined device.
When you reset your password on a Hybrid Azure AD-joined device, you must have a
line of sight to the domain controller. If you're outside the corporate network, make sure
that you're connected through a VPN. Then, log out and log back in by using the new
password.

Do I still have access to Office 365

resources from Hybrid Azure AD-joined
device when I work outside my
corporate network?
Yes. You still have access to Office 365 resources from Hybrid Azure AD-joined devices
from outside the corporate network unless you change your password.

Is there a way to keep access to Office

365 resources from Hybrid Azure AD
joined devices even if I changed my
password while outside the corporate
network?
If you're using Windows Hello for Business (WHfB) to sign in a Hybrid Azure AD joined
device, you will retain access to Office 365 resources even after changing your password.

How I can verify the health status of my

Azure AD device?
You can verify the health status for all join types (Hybrid Azure AD-joined, Azure AD-
Joined, and Azure AD Register) by using the Device Registration Troubleshooter Tool.

How can I verify that Single Sign-On

(SSO) is working as expected on my
device?
Run the dsregcmd /status  command from a Hybrid Azure AD-joined or Azure AD-
joined device, and check whether AzureAdPrt  is set as YES. For more information, go to
SSO state.

What are the Hybrid Azure AD device

registration steps?
The following are the device registration steps for Hybrid Azure AD-joined:

1. The device tries to retrieve the tenant ID and domain name from the following
registry subkey:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD .
2. If step 1 fails, the device communicates with the Local AD (configuration partition)
to get the tenant's information form the Service Connection Point (SCP). (You can
get SCP information by using Device Registration SCP Tool PowerShell.)
3. The device communicates with the Azure AD tenant.
4. The device authenticates against either Azure AD or a federation service (for
example, ADFS).
5. The device registration process finishes.
For more information, go to Hybrid Azure AD Device Registration .

What is the best method to

troubleshoot device registration issues?
The Device Registration Troubleshooter Tool runs more than 30 tests to identify and fix
the most common device registration issues for all join types (Hybrid Azure AD-joined,
Azure AD-joined, and Azure AD Register).

While working from home, I can't access

cloud resources. My device's conditional
access policy isn't registered, but the
device seems to be connected to Azure
AD. What might be wrong?
Double-check the device connection to Azure AD. Also check the Azure AD PRT value.
For more information, go to SSO state.

When users work from home, is there a

way to allow them to reset their
passwords?
Yes. You can allow users to change their password from home. Here's how to configure
the password writeback feature:

1. Enable the password writeback feature from Azure Active Directory Connect. For
more information, go to Enable password writeback in Azure AD Connect.

2. Set the required permission to the Azure Active Directory Connect account by
running the following PowerShell commands on the Azure Active Directory
Connect server:

PowerShell

Import-Module "C:\Program Files\Microsoft Azure Active Directory

Connect\AdSyncConfig\AdSyncConfig.psm1"

 PowerShell

Set-ADSyncPasswordWritebackPermissions -
ADConnectorAccountNameAADConnectAccount -ADConnectorAccountDomain
domain.local

To get ADConnectorAccountName  and ADConnectorAccountDomain values:

PowerShell

Get-ADSyncADConnectorAccount

3. To enable password writeback from Azure portal, go to Enable password writeback

for SSPR.

What is the required license for

password writeback and SSPR?
The required licenses are listed in the following article:

How does self-service password reset writeback work in Azure Active Directory?

What are the required ports and URLs

for password writeback and SSPR?
For an Azure Active Directory Connect server that is running behind a firewall or
through a proxy, open the ports and URLs that are listed in this article.

Third-party information disclaimer

The third-party products that this article discusses are manufactured by companies that
are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about
the performance or reliability of these products.
Error when you try to run Azure Active
Directory for Windows PowerShell
cmdlets: The term <cmdlet name> is
not recognized
Article • 04/20/2022 • 2 minutes to read

Original product version:   Cloud Services (Web roles/Worker roles), Azure Active
Directory, Microsoft Intune, Azure Backup, Office 365 Identity Management

Original KB number:   2669552

Symptoms
When you try to run Microsoft Azure Active Directory Module for Windows PowerShell
cmdlets, you receive the following error message:

The term <cmdlet name> is not recognized as the name of a cmdlet, function, script
file, or operable program. Check the spelling of the name, or if a path was included,
verify that the path is correct and try again.

For example, you might see the following similar message:

The term 'Connect-MsolService' is not recognized as the name of a cmdlet, function,

script file, or operable program. Check the spelling of the name, or if a path was
included, verify that the path is correct and try again.

At line:1 char:20

+ Connect-MsolService <<<<

+ CategoryInfo : ObjectNotFound: (Connect-MsolService:String) [],

CommandNotFoundException

+ FullyQualifiedErrorId : CommandNotFoundException

Cause
This issue can occur if the Azure Active Directory Module for Windows PowerShell isn't
loaded correctly.

Resolution
To resolve this issue, follow these steps.

1. Install the Azure Active Directory Module for Windows PowerShell on the
computer (if it isn't already installed). To install the Azure Active Directory Module
for Windows PowerShell, see Manage Azure AD using Windows PowerShell.

2. Select Start > All Programs, select Windows Azure Active Directory, and then
select Windows Azure Active Directory Module for Windows PowerShell.

3. At the Windows PowerShell command prompt, type Get-Module , and then press
Enter.

4. In the output, check that the MSOnline module is present. The output should look
similar to the following one:

Output

Module Type Name Exported Commands

-------------- -------- ----------------

Binary MSOnline {Add-MsolRoleMember, Remove-MsolContact...

If the MSOnline module isn't present, use Windows PowerShell to import the
MSOnline module. To do it, follow these steps:

a. Connect to Exchange Online by using remote PowerShell. For more info about
how to do it, see Connect to Exchange Online Using Remote PowerShell.

b. Type the following cmdlet, and then press Enter:

PowerShell

Import-Module MSOnline

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Troubleshoot dynamic groups
Article • 04/20/2022 • 11 minutes to read

This troubleshooting guide helps you diagnose and solve issues with dynamic groups in
Azure Active Directory.

Dynamic groups identification and

management
To verify whether your group is a dynamic group, see Evaluate whether a group is a
dynamic group.

Yes: proceed to the next section.

No: Create a basic group and add members using Azure Active Directory or other
applicable groups.

Dynamic group creation issues

References
Recommended articles for group creation:

Create a new group and add members in Azure portal

Create groups in Powershell MSOnline
Disable groups creation in Powershell
Azure AD administrative roles

Common issues in creating a dynamic group or rule:

You're unable to create a dynamic group in the Azure Portal, or you receive an
error when creating a dynamic group in PowerShell. See Cannot create a dynamic
group.

You can't find the attribute to create a rule. See Create a dynamic membership rule.

You receive a "max groups allowed" error when trying to create a Dynamic Group
in PowerShell: You have reached 5,000 groups, the maximum limit for Dynamic
groups in your tenant. To create new Dynamic groups, first delete existing Dynamic
groups. Note that there's no way to increase the maximum limit.
Dynamic membership update issues
You've created a dynamic group and configured a rule, but encountered these common
issues:

No members appear in the group, some users or devices don't appear in the group, or
the wrong users or devices appear in the group.

Visit Troubleshoot dynamic membership update issues.

Existing members of the rule are removed.

This behavior is expected. Existing members of the group are removed when a rule
is enabled or changed, or attributes are changed. The users returned from the
evaluation of the rule are added as members to the group.

You don't see membership changes instantly after adding or changing a rule.

Membership evaluation is performed periodically as a background process. The

duration of the process is determined by the number of users in your directory,
and the size of the group is created because of the rule. Typically, directories with
small numbers of users will see group membership changes within a few minutes.
Directories with a large number of users can take 30 minutes or longer to
populate.

Check the membership processing status to confirm whether the process is

complete. Check the last updated date on the group Overview page in Azure
portal to confirm that the page is updated.

To force the group to be processed, see Force the group to be processed now.

You receive a rule processing error.

See Fix a rule processing error.

Dynamic group deletion or restoration issues

You receive an error when deleting a group.

Before you attempt to delete a group in Azure Active Directory, ensure that you
have deleted all assigned licenses. For more information about group deletion in
general, see Delete a group.

You restored a deleted group but did not see any update.
 When a dynamic group is deleted and restored, it's seen as a new group and re-
populated according to the rule. This process might take up to 24 hours.

Evaluate whether a group is a dynamic group

To determine whether a group is dynamic group:

1. Sign into the Azure portal .

2. Select the group in the Overview of Group tab, then check whether the
membership type is set to Dynamic.

Validate dynamic group membership rules

Azure Active Directory (Azure AD) provides the means to validate dynamic group rules.
On the Validate rules tab, you can validate your dynamic rule against sample group
members to confirm that the rule is working as expected.

When creating or updating dynamic group rules, you can use this information to help
determine whether a user or device meets the rule criteria for becoming a member of a
group. This can also aid you in troubleshooting when membership isn't expected.

For more information, see Validate a dynamic group membership rule (preview) in Azure
Active Directory

Troubleshoot dynamic group creation issues

You've encountered issues when creating a dynamic group or rule.

Cannot create a dynamic group

You don't see option to create a dynamic group in the Azure portal, or there was an
error in creating a dynamic group in PowerShell.

1. Ensure that your tenant has the appropriate license.

Dynamic groups require the tenant to have an Azure Active Directory P1/P2
Premium license. For more information, check Azure Active Directory license
plans

2. Ensure that the user creating the group has the appropriate administrator
permissions:
 Ensure that you are authorized to create a new group. Global administrators
can disable group creation in the Azure portal or Access Panel. You may need
an administrator create the new group for you, or give you appropriate
permissions.

3. Check that group creation permissions are enabled for the type of group being
created.

Global administrators can manage group creation permissions for security or

Office 365 groups created in the Azure portal or Access Panel, by setting the
Users can create security groups in Azure portals or Users can create Office
365 groups in Azure portals settings in the Azure portal under All groups >
General (Settings). This setting applies to dynamic groups as well.

4. Check that the specific user is in the list of users that can create a group.

Global administrators can restrict group creation to select a group of users if

you have an Azure Active Directory P1 Premium license. You should verify
that you have the appropriate permissions.

You get a max groups allowed error when creating a

Dynamic group in Powershell
This error means you have reached the max limit for Dynamic groups in your tenant.
Check the number of groups in the tenant. The max number of Dynamic groups per
tenant is 5,000.

To create any new Dynamic groups, you'll first need to delete some existing Dynamic
groups. There's no way to increase the limit.

Troubleshoot dynamic group rule creation

issues

Cannot find the attribute to create a rule

1. Ensure that the user attributes are in the list of supported properties. If they're not
in the list, they're not currently supported.
2. Ensure that the device attributes are in the list of device attributes. If they're not in
the list, they're not currently supported. For more information, visit Dynamic
membership rules for groups in Azure Active Directory.
Cannot create a dynamic membership rule
1. Ensure that your tenant has the appropriate license. Dynamic groups require the
tenant to have an Azure Active Directory P1 Premium license.

The list of Azure Active Directory license plans can be accessed at Azure
Active Directory pricing .

Enterprise Mobility + Security licensing plans can be accessed at Enterprise

Mobility+Security pricing options .

2. If you cannot find the built-in User Attributes, ensure that the attribute is in the list
of supported properties. If it's not in the list, it's not currently supported.

3. If you're looking for built-in Device Attributes, ensure that the attribute is in the
list of device attributes. If it's not in the list, it's not currently supported.

4. If the attribute isn't found in the Simple Rule drop-down in the Azure portal, use
the Advanced Rule to construct a rule.

a. Ensure that the syntax is accurate and that both the property type and value
match.

b. Also ensure that you have added the appropriate object prefix to select the
property.

For example: user.country, device.deviceOSType.

c. Learn about the guidelines on how to create an Advanced Rule including the list
of supported operators and examples for common rules.

5. Also use Extension Attributes for dynamic user rules. These rules will be visible in
the drop-down list while creating a simple rule.

The custom attribute name can be found in the directory by querying a user's
attribute using PowerShell, and searching for the attribute name. These
attributes could also be used when constructing an Advanced Rule.

6. Ensure that the Role of the user creating the Dynamic group, is either a Company
Administrator or a User Administrator.

7. Allow time for the group to populate.

8. The Simple Rule builder supports up to five (5) expressions. To add more than five
expressions to the rule, the text box must be used.
Troubleshoot dynamic membership update
issues
You've created a dynamic group and configured a rule, but encountered one of these
issues:

There are no members listed in the group.

Some users or devices don't appear in the group.
Incorrect users or devices don't appear in the group.

Members are not added or removed as expected

1. Check the membership processing status to confirm if it's complete, and check the
last updated date on the group Overview page in Azure portal to confirm it's up-
to-date.

2. If membership processing status is processing error and update paused, ask the
administrator or PG team to resume the group from processing error.

3. Verify that the users or devices satisfy the membership rule or not, following the
steps in Evaluate dynamic membership of a user or device.

4. Verify that processing status is not impacted by the issue of guest user addition
disallowed by policy.

If the group is an Office365 group and the user is a guest user, the guest user
can't be added to a group if the directory setting does not allow a guest user
addition in the tenant.

A guest user addition error in one group will block the updates of the same
and other groups in the same tenant. You can choose to:
Allow a guest user addition by following the Manage guest user setting
for groups in a tenant.
Change the group rule to exclude a guest user by adding: (user.userType
-eq "member") .

5. If everything looks correct, allow some time for the group to populate. Depending
on the size of your tenant, the group may take up to 24 hours to populate the first
time, or after a rule change.

6. If problem still exists after 24 hours and the processing status shows as complete,
you can reset the processing for the group to resolve any transient system issue.
 If the processing status shows as in processing, continue to wait.

Evaluate dynamic membership of a user or device

To evaluate whether a user or device satisfies the rule to be part of a group, use Manual
validation.

Manual validation
Validate the values for user or device attributes (InAzure Portal, or using PowerShell in
the rule.

Ensure that there are users that satisfy the rule.

For devices, check the device properties to ensure that synchronized attributes
contain the expected values.

Manage guest user setting in office365 group

First, install the Azure AD PowerShell module

1. Connect to the directory. Visit How to connect to the directory using PowerShell
for more information.

2. Check the directory setting:

a. Read the directory setting of the tenant: Read settings at the directory level.
b. Check the guest user setting: As shown in the following image, if
AllowToAddGuests is true, check the setting in that particular group. If
AllowToAddGuests is false, no matter what group level setting is, guest users
can't be added.

3. Update the setting at the tenant level. To change the guest user setting at the
tenant level, visit: How to update setting at tenant level using PowerShell.
 4. Check the setting for the group. To change the guest user setting to your target
value if applicable, visit: How to check and update setting for a specific group
using PowerShell

Existing members of the rule are removed

This is expected behavior. Existing members of the group are removed when a rule is
enabled or changed, or attributes are changed. The users returned from evaluation of
the rule are added as members to the group.

You don't see membership changes instantly after

updating a rule
Membership evaluation is done periodically in a background process. How long the
process takes is determined by multiple factors.

Force the group to be processed now

Reset processing for a dynamic group. In the Azure portal, manually trigger the re-
processing by updating the membership rule to add a whitespace at the end.

Fix a rule processing error

Rule parser Error usage Corrected usage

error

Error: (user.invalidProperty - (user.department -eq "value")

Attribute not eq "Value") Make sure the attribute is on the supported properties
supported list.

Error: (user.accountEnabled - (user.accountEnabled -eq true)

Operator contains true) The operator used isn't supported for the property
isn't type (in this example, -contains cannot be used on
supported on type boolean). Use the correct operators for the
attribute property type.

Error: Query 1. (user.department -eq 1. Missing operator. Use -and or -or two join
compilation "Sales") predicates: (user.department -eq "Sales") -or
error (user.department -eq (user.department -eq "Marketing")

"Marketing")
2. Error in regular expression used with -match

2. (user.userPrincipalName -match " .*@domain.ext ")

(user.userPrincipalName or alternatively: (user.userPrincipalName -match

-match " *@domain.ext ") "@domain.ext$")
Troubleshoot dynamic groups deletion or
restoration
Before attempting to delete a group in Azure Active Directory, ensure you have deleted
all assigned licenses to avoid errors.

(For more information about group deletion in general, see Delete a group.

Delete a group
1. Groups can be deleted from the directory using the Remove-AzureADGroup
cmdlet in the Azure AD PowerShell module.
2. Before attempting to delete a group in Azure Active Directory, ensure you have
deleted all assigned licenses to avoid errors.

Restore a deleted group

If an Office 365 group is deleted, it can only be restored up to 30 days before
permanent deletion occurs. Once permanently deleted, the group can no longer
be restored. To learn more about restoring groups, see Restore a deleted Microsoft
365 group in Azure Active Directory.
This functionality isn't supported for security groups and distribution groups.
Verify that you're authorized to restore an Office 365 group. Only Global
administrators, User account administrators, Intune service administrators, , or the
owner of the group can restore a group.

You restored a deleted dynamic group, but didn't see any

update
When a dynamic group is deleted and restored, it's seen as a new group and re-
populated according to the rule. This process might take up to 24 hours.

Related articles
Creating Dynamic Membership Rules.
Troubleshooting groups.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Troubleshoot user creation and deletion
issues in Azure Active Directory
Article • 04/20/2022 • 5 minutes to read

This article outlines the methods in Azure Active Directory (Azure AD) you can use to:

Create a user.
Delete a user.
Create users in bulk.

Prerequisites
One of the following role assignments:
Global Administrator
User Administrator

Methods for user creation and deletion

Azure AD has many methods for creating and deleting users, such as:

Azure portal
Microsoft Graph REST API
Azure PowerShell
Azure CLI

These methods refer to users who are created directly in Azure AD. The article doesn't
cover users who are created elsewhere and then synced to Azure AD or business-to-
business scenarios.

Create a user
Select a method to create a user in Azure AD.

Azure portal

To add a new user in the Azure portal:

1. In the Azure portal , sign in as a Global Administrator or a User

Administrator.
 2. Search for and select Azure Active Directory.

3. Select Users, and then select New user.

4. On the User page, enter the user's Name, User name, Groups, Directory role,
and Job info.

5. Copy the autogenerated password provided in the Password box. You'll need
to give this password to the user to sign in for the first time.

6. Select Create.

For more information, see Add or delete users - Azure Active Directory.

Delete a user
Select a method to delete a user in Azure AD.

Azure portal

To delete a user in the Azure portal:

1. In the Azure portal , sign in as a Global Administrator or a User

Administrator.

2. Search for and select Azure Active Directory.

3. Select Users.

4. Search for and select the user you want to delete from your Azure AD tenant
(for example, Mary Parker).

5. Select Delete user.

The user is deleted and no longer appears on the Users - All users page. You can
view the user on the Deleted users page for the next 30 days. You may also restore
the deleted user during that time. For more information about restoring a user, see
Restore or remove a recently deleted user using Azure Active Directory.

After you delete a user, any licenses that the user consumes are made available for
other users.

Create users in bulk

For more information about creating or deleting users in bulk, see Bulk create users in
Azure Active Directory.

Permissions required to manage users with a

service principal
If you want to automate the creation and deletion of your Azure Active Directory users
on Microsoft Graph, your application needs the following permissions:

User.ReadWrite.All
Directory.ReadWrite.All

For more information about who can manage each aspect of user management, see
Least privileged roles by task in Azure Active Directory—Users.

Error messages and remediation actions

The following table contains a list of common error messages when you attempt to
create or delete a user in Azure Active Directory (Azure AD), and describes the proper
remediation actions for them. The error messages are as shown for the Microsoft Graph
REST API, Azure PowerShell, or Azure CLI. Similar, but briefer error messages are shown
in the Azure portal, and the remedial actions are identical.

Error message Action

Another object Make the user principal name (UPN) unique. This error occurs when the
with the same administrator attempts to create a user with an existing user name in Azure
value for property AD. For more information, see User name policies.
userPrincipalName
already exists.

Insufficient Find a Global Administrator or a User Administrator to add or delete the

privileges to user. This error occurs when the security principal tries to create or delete
complete the users, but doesn't have the needed permissions. A Global admin can create
operation. or delete any user, including other admins. A User admin can create users
and delete any non-admin users, Helpdesk administrators, and other User
admins.

Property See User name policies for a list of allowed and disallowed characters. This
userPrincipalName error occurs when you create a new user with unacceptable characters in the
is invalid. UPN. The user name and email address properties also can't contain accent
characters.
 Error message Action

The specified Avoid using a password that:

password does not Doesn't follow the Azure AD password policies.
comply with Is on the custom banned password list.
password Contains the user name of the user.
complexity
requirements.
Please provide a
different password.

The domain Make sure the domain you're using to create the user is on the list of
portion of the verified domains in the Azure AD portal. The status of the domain needs to
userPrincipalName be Verified. If you've verified the domain status, see whether the domain is
property is invalid. Federated (has a checkmark) or Managed (doesn't have a checkmark). You
You must use one can only create users in Azure AD for managed domains. For federated
of the verified domains, you must create the user on the identity provider (IdP), and then
domain names in sync to Azure AD. You can't assign a federated domain to a user.
your organization.

Directory quotas
For the Free edition of Azure AD, you can create a maximum of 50,000 Azure AD
resources in a single tenant by default. If you use at least one verified domain, the
default Azure AD service quota for your organization is extended to 300,000 Azure AD
resources. For organizations that are created by self-service sign-up, the Azure AD
service quota remains 50,000 Azure AD resources. This limit applies even if you made an
internal admin takeover and converted the organization to a managed tenant with one
or more verified domains. This service limit is unrelated to the pricing tier limit of
500,000 resources on the Azure AD pricing page. To go beyond the default quota, you
must contact Microsoft Support.

For more information, see Azure AD service limits and restrictions.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Unknown Actors in Audit Reports
Article • 02/11/2023 • 2 minutes to read

The following are common examples of Microsoft first party service principal actors that
may be found in Azure Active Directory audit logs including a description of actions
these actors may take on Azure Active Directory objects in your tenant.

Unknown actors
Actor Name Service(s) Description

Microsoft Substrate Management Exchange Used by Exchange Online

during dual write operations
to Azure Active Directory.
When an object in Exchange
Online is written to Azure
Active Directory, this principal
will show up as the actor in
Azure Active Directory audit
logs. For more information
about dual write operations,
see Exchange Online
Improvements to Accelerate
Replication of Changes to
Azure Active Directory

Windows Azure Service Management API Azure Used by Azure Resource

Resource Manager (ARM) service ". This
Manager service principal may be used
for any Azure Active Directory
operations needed to
maintain proper access for
Azure subscription and
resources such as ensuring the
subscription’s Service
Administrator has an Azure
Active Directory account in
your tenant.
Actor Name Service(s) Description

5MS-CE-CXG-MAC-AadShadowRoleWriter License Used by commerce platform

Manager to assign Microsoft 365
Service, commerce role permissions to
Purchase Azure Active Directory. An
Service, example of a role this service
Marketplace would add is Modern
Commerce Administrator

- Reference 1 - Azure AD
built-in roles

- Reference 2 - Who can buy

through self-service purchase?

Microsoft Exchange Online Protection Security and Used by Exchange Online

Compliance Protection to write changes to
Center Azure Active Directory. As an
example, MIP labels can only
be modified in Security and
Compliance Center (SCC). SCC
logs contain the user actor.
SCC then pushes these labels
to AAD offline, so there's no
user context.

Microsoft Azure AD Subscription Lifecycle License Used by the license manager

Process Manager service to remove licenses and
Service subscriptions from Azure
Active Directory when a
subscription has expired or
when the subscription state
changes.

fim_password_service@support.onmicrosoft.com Self-Service Used to perform the Self

Password Service Password Reset
Reset operation for end users.

Signup Commerce Used by commerce licensing

Licensing service during self-service
(LMS) subscription signup. For more
information on self-service
subscriptions, see Manage
self-service sign-up
subscriptions
 Actor Name Service(s) Description

Microsoft Approval Management Self-Service Used by self-service group

Group management service (SSGM)
Management for Azure Active Directory
Service dynamic groups, and Office
365 Group expiration policy
operations

spo_service@support.onmicrosoft.com SharePoint This account is used to create

Online Azure Access Control Service
(ACS) principles, which are
required for the installation of
the SharePoint app (add-in).

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support. You can also submit product feedback to Azure community support.
Verify first-party Microsoft applications
in sign-in reports
Article • 12/23/2022 • 3 minutes to read

When you're reviewing your sign-in reports, you might see an application in your sign-in
report that you don't own and want to identify the application. You also might wonder
how you signed into that app, if you don't remember accessing the app.

Here's an example sign-in report:

For example, when you access learn.microsoft.com , the application that's shown in the
sign-in log may say dev-rel-auth-prod , which isn't descriptive of learn.microsoft.com .

Although the apps that are listed in sign-in reports are owned by Microsoft and aren't
suspicious applications, you can determine whether Microsoft owns an Azure Active
Directory (Azure AD) service principal that's found in your Azure AD logs.

７ Note

First-party Microsoft applications don't always result in a service principal that's

created in your tenant. In this case, you'll likely continue to see the applications in
your sign-in reports. This article lists the application IDs of commonly used
Microsoft applications.
Verify a first-party Microsoft service principal in
your Azure AD tenant
1. Open the list of enterprise applications in Azure AD .

2. In the navigation pane, select All applications.

3. In the Application Type drop-down list, select Microsoft Applications, and then
select Apply. All applications that are listed here are owned by Microsoft.

4. In the search box below the drop-down lists, filter the Microsoft application list by
adding a specific Display Name or Application ID.

5. Select the desired app, and then select Properties in the navigation pane to view
the listed app's properties. Verify that you see the following error message:

Output

You can't delete this application because it's a Microsoft first party
application.

Verify a first-party Microsoft service principal

through PowerShell
1. Open the Azure Active Directory Module in PowerShell.

2. In the PowerShell module, enter the following cmdlet:

cmd

Get-AzureADServicePrincipal -Filter "DisplayName eq '<display-name>'" |

fl *

Replace <display name> with the app's actual display name.

3. Review the result's AppOwnerTenantId .

In the screenshot, f8cdef31-a31e-4b4a-93e4-5f571e91255a is the Microsoft Service's

Azure AD tenant ID.

Application IDs of commonly used Microsoft

applications
The following table lists some, but not all, first-party Microsoft applications. You may see
these applications in the Sign-ins report in Azure AD.

Application Name Application IDs

ACOM Azure Website 23523755-3a2b-41ca-9315-f81f3f566a95

AEM-DualAuth 69893ee3-dd10-4b1c-832d-
4870354be3d8

ASM Campaign Servicing 0cb7b9ec-5336-483b-bc31-b15b5788de71

Azure Advanced Threat Protection 7b7531ad-5926-4f2d-8a1d-38495ad33e17

Azure Data Lake e9f49c6b-5ce5-44c8-925d-015017e9f7ad

Azure Lab Services Portal 835b2a73-6e10-4aa5-a979-21dfda45231c

Azure Portal c44b4083-3bb0-49c1-b47d-974e53cbdf3c

AzureSupportCenter 37182072-3c9c-4f6a-a4b3-b3f91cacffce

Bing 9ea1ad79-fdb6-4f9a-8bc3-2b70f96e34c7

CPIM Service bb2a2e3a-c5e7-4f0a-88e0-8e01fd3fc1f4

CRM Power BI Integration e64aa8bc-8eb4-40e2-898b-cf261a25954f

Dataverse 00000007-0000-0000-c000-000000000000

Enterprise Roaming and Backup 60c8bde5-3167-4f92-8fdb-059f6176dc0f

IAM Supportability a57aca87-cbc0-4f3c-8b9e-dc095fdc8978

IrisSelectionFrontDoor 16aeb910-ce68-41d1-9ac3-9e1673ac9575

MCAPI Authorization Prod d73f4b35-55c9-48c7-8b10-651f6f2acb2e

Media Analysis and Transformation Service 944f0bd1-117b-4b1c-af26-804ed95e767e

0cd196ee-71bf-4fd6-a57c-b491ffd4fb1e

Microsoft 365 Support Service ee272b19-4411-433f-8f28-5c13cb6fd407

Microsoft App Access Panel 0000000c-0000-0000-c000-000000000000

Microsoft Approval Management 65d91a3d-ab74-42e6-8a2f-0add61688c74

38049638-cc2c-4cde-abe4-4479d721ed44

Microsoft Authentication Broker 29d9ed98-a469-4536-ade2-f981bc1d605e

Microsoft Azure CLI 04b07795-8ddb-461a-bbee-02f9e1bf7b46

Microsoft Azure PowerShell 1950a258-227b-4e31-a9cf-717495945fc2

Application Name Application IDs

Microsoft Bing Search cf36b471-5b44-428c-9ce7-313bf84528de

Microsoft Bing Search for Microsoft Edge 2d7f3606-b07d-41d1-b9d2-0d0c9296a6e8

Microsoft Bing Default Search Engine 1786c5ed-9644-47b2-8aa0-7201292175b6

Microsoft Defender for Cloud Apps 3090ab82-f1c1-4cdf-af2c-5d7a6f3e2cc7

Microsoft Docs 18fbca16-2224-45f6-85b0-f7bf2b39b3f3

Microsoft Dynamics ERP 00000015-0000-0000-c000-000000000000

Microsoft Edge Insider Addons Prod 6253bca8-faf2-4587-8f2f-b056d80998a7

Microsoft Exchange Online Protection 00000007-0000-0ff1-ce00-000000000000

Microsoft Forms c9a559d2-7aab-4f13-a6ed-e7e9c52aec87

Microsoft Graph 00000003-0000-0000-c000-000000000000

Microsoft Intune Web Company Portal 74bcdadc-2fdc-4bb3-8459-76d06952a0e9

Microsoft Intune Windows Agent fc0f3af4-6835-4174-b806-f7db311fd2f3

Microsoft Learn 18fbca16-2224-45f6-85b0-f7bf2b39b3f3

Microsoft Office d3590ed6-52b3-4102-aeff-aad2292ab01c

Microsoft Office 365 Portal 00000006-0000-0ff1-ce00-000000000000

Microsoft Office Web Apps Service 67e3df25-268a-4324-a550-0de1c7f97287

Microsoft Online Syndication Partner Portal d176f6e7-38e5-40c9-8a78-3998aab820e7

Microsoft password reset service 93625bc8-bfe2-437a-97e0-3d0060024faa

Microsoft Power BI 871c010f-5e61-4fb1-83ac-98610a7e9110

Microsoft Storefronts 28b567f6-162c-4f54-99a0-6887f387bbcc

Microsoft Stream Portal cf53fce8-def6-4aeb-8d30-b158e7b1cf83

Microsoft Substrate Management 98db8bd6-0cc0-4e67-9de5-f187f1cd1b41

Microsoft Support fdf9885b-dd37-42bf-82e5-c3129ef5a302

Microsoft Teams 1fec8e78-bce4-4aaf-ab1b-5451cc387264

Microsoft Teams Services cc15fd57-2c6c-4117-a88c-83b1d56b4bbe

Microsoft Teams Web Client 5e3ce6c0-2b1f-4285-8d4b-75ee78787346

Application Name Application IDs

Microsoft Whiteboard Services 95de633a-083e-42f5-b444-a4295d8e9314

O365 Suite UX 4345a7b9-9a63-4910-a426-35363201d503

Office 365 Exchange Online 00000002-0000-0ff1-ce00-000000000000

Office 365 Management 00b41c95-dab0-4487-9791-b9d2c32c80f2

Office 365 Search Service 66a88757-258c-4c72-893c-3e8bed4d6899

Office 365 SharePoint Online 00000003-0000-0ff1-ce00-000000000000

Office Delve 94c63fef-13a3-47bc-8074-75af8c65887a

Office Online Add-in SSO 93d53678-613d-4013-afc1-62e9e444a0a5

Office Online Client AAD- Augmentation Loop 2abdc806-e091-4495-9b10-b04d93c3f040

Office Online Client AAD- Loki b23dd4db-9142-4734-867f-3577f640ad0c

Office Online Client AAD- Maker 17d5e35f-655b-4fb0-8ae6-86356e9a49f5

Office Online Client MSA- Loki b6e69c34-5f1f-4c34-8cdf-7fea120b8670

Office Online Core SSO 243c63a3-247d-41c5-9d83-7788c43f1c43

Office Online Search a9b49b65-0a12-430b-9540-c80b3332c127

Office.com 4b233688-031c-404b-9a80-a4f3f2351f90

Office365 Shell WCSS-Client 89bee1f7-5e6e-4d8a-9f3d-ecd601259da7

OfficeClientService 0f698dd4-f011-4d23-a33e-b36416dcb1e6

OfficeHome 4765445b-32c6-49b0-83e6-1d93765276ca

OfficeShredderWacClient 4d5c2d63-cf83-4365-853c-925fd1a64357

OMSOctopiPROD 62256cef-54c0-4cb4-bcac-4c67989bdc40

OneDrive SyncEngine ab9b8c07-8f02-4f72-87fa-80105867a763

OneNote 2d4d3d8e-2be3-4bef-9f87-7875a61c29de

Outlook Mobile 27922004-5251-4030-b22d-91ecd9a37ea4

Partner Customer Delegated Admin Offline a3475900-ccec-4a69-98f5-a65cd5dc5306

Processor

Password Breach Authenticator bdd48c81-3a58-4ea9-849c-ebea7f6b6360

Power BI Service 00000009-0000-0000-c000-000000000000

 Application Name Application IDs

SharedWithMe ffcb16e8-f789-467c-8ce9-f826a080d987

SharePoint Online Web Client Extensibility 08e18876-6177-487e-b8b5-cf950c1e598c

Signup b4bddae8-ab25-483e-8670-df09b9f1d0ea

Skype for Business Online 00000004-0000-0ff1-ce00-000000000000

Sway 905fcf26-4eb7-48a0-9ff0-8dcc7194b5ba

Universal Store Native Client 268761a2-03f3-40df-8a8b-c3db24145b6b

Vortex [wsfed enabled] 5572c4c0-d078-44ce-b81c-6cbf8d3ed39e

Windows Azure Active Directory 00000002-0000-0000-c000-000000000000

Windows Azure Service Management API 797f4846-ba00-4fd7-ba43-dac1f8f63013

WindowsDefenderATP Portal a3b79187-70b2-4139-83f9-6016c58cd27b

Windows Search 26a7ee05-5602-4d76-a7ba-eae8b7b67941

Windows Spotlight 1b3c667f-cde3-4090-b60b-3d2abd0117f0

Windows Store for Business 45a330b1-b1ec-4cc1-9161-9f03992aa49f

Yammer 00000005-0000-0ff1-ce00-000000000000

Yammer Web c1c74fed-04c9-4704-80dc-9f79a2e515cb

Yammer Web Embed e1ef36fd-b883-4dbf-97f0-9ece4b576fc6

More information
For more information, see Sign-in activity reports in the Azure Active Directory portal.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support. You can also submit product feedback to Azure community support.
Error when you run the Azure Active
Directory Sync Tool Configuration
Wizard: An unknown error occurred
with the Microsoft Online Services Sign-
in Assistant
Article • 04/20/2022 • 2 minutes to read

Original product version:   Cloud Services (Web roles/Worker roles), Azure Active
Directory, Microsoft Intune, Azure Backup, Office 365 Identity Management

Original KB number:   2502710

Symptoms
When you run the Microsoft Azure Active Directory Sync Tool Configuration Wizard, you
receive the following error message:

An unknown error occurred with the Microsoft Online Services Sign-in Assistant.
Contact Support.

Resolution
To resolve this issue, follow these steps:

1. Select Start, type appwiz.cpl , and then press Enter to open the Programs and
Features item in Control Panel.

2. Uninstall the Microsoft Online Services Sign-In Assistant.

3. Uninstall the Azure Active Directory Sync tool.

4. Reinstall the Azure Active Directory Sync tool. For more information about how to
do this, go to Install or upgrade the Directory Sync tool .

5. Check whether the issue is resolved. If the error still occurs after you follow steps 1
through 4, make sure that the Microsoft Online Services Sign-In Assistant service is
started. To do this, follow these steps:
a. Select Start, type services.msc , and then press Enter.
 b. In the list of services, make sure that the entry in the Status column for
Microsoft Online Services Sign-In Assistant is Started.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Authorization_RequestDenied error
when you try to change a password
using Graph API
Article • 04/20/2022 • 2 minutes to read

This article provides information about troubleshooting a problem in which you receive
Authorization_RequestDenied error when trying to change a password using Graph API.

Original product version:   Azure Active Directory

Original KB number:   3004133

Symptoms
You try to change the password of a Microsoft Azure Active Directory (Azure AD) user. If
the Organizational Role setting for that user is set to any "Administrator" option, the
process fails. It generates the following error message:

{"odata.error":{"code":"Authorization_RequestDenied","message":
{"lang":"en","value":"Insufficient privileges to complete the operation." }} }

When you give the Read and write directory data permission to your application or
Application Service Principal, the application can change the password of a typical Azure
AD user by using Graph API. This setting is shown in the following screenshot.

You can delegate an Azure AD user as an administrator by changing the user's

Organizational Role setting, as shown in the following screenshot.
Cause
This problem occurs because the users who have any of the Administrator
organizational roles aren't members of Company Administrator or User Account
Administrator in the Office 365 administrative roles.

Resolution
To resolve this problem, add your application to Company Administrator in the Office
365 administrative roles. To do so, run all the following Azure AD Module for Windows
PowerShell (MSOL) cmdlets:

PowerShell

Connect-MsolService

It will prompt you for your tenant's credential. You should be able to use your Azure AD
administrative user name in the admin@tenant.onmicrosoft.com format.

PowerShell

$displayName = "Application Name"

$objectId = (Get-MsolServicePrincipal -SearchString $displayName).ObjectId

Replace the "Application Name" with the name of your "Application Service Principal".

PowerShell

$roleName = "Company Administrator"

Add-MsolRoleMember -RoleName $roleName -RoleMemberType ServicePrincipal -

RoleMemberObjectId $objectId

It will add your "Application Service Principal" to the Company Administrator role.

Also, you must add your application to User Account Administrator in the Office 365
administrative roles if the Azure AD user has any of the following Administrator
organizational roles:

Global Administrator
Billing Administrator
Service Administrator

To do so, run all the following MSOL cmdlets:

PowerShell

Connect-MsolService

$displayName = "Application Name"

$objectId = (Get-MsolServicePrincipal -SearchString $displayName).ObjectId

$roleName = "User Account Administrator"

Add-MsolRoleMember -RoleName $roleName -RoleMemberType ServicePrincipal -

RoleMemberObjectId $objectId

After you run both sets of cmdlets, your application will be enabled to change the
password of all Administrator organizational roles.

７ Note

It can take up to 30 minutes for the permissions to be applied to the Application

Service Principal after you add the permissions to the Office 365 administrative
roles.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Using ADAL to authenticate from
Android devices fails if additional
certificate downloads are required
Article • 04/20/2022 • 2 minutes to read

This article describes an issue in which Azure Active Directory Authentication Library
(ADAL) authentication from Android devices fails if additional certificate downloads are
required.

Original product version:   Azure Active Directory

Original KB number:   3203929

Symptoms
When you try to authenticate by using the ADAL for Android, Federation sign-in may
fail. Specifically, the application triggers an AuthenticationException error when it tries
to display the login page. In Google Chrome, the STS login page might be called out as
unsafe. This issue occurs only on Android devices, for any application that uses ADAL for
Android to connect to a Federation server.

To determine whether you are experiencing this issue, run the following test:

1. Obtain your Security Token Service (STS) server's fully qualified domain name
(FQDN). To do this, follow these steps:
a. Go to https://login.microsoftonline.com on a non-Android device.
b. Enter your work or school account.
c. When you're redirected to your federated STS login page, note the URL address
in the browser. It looks like https://sts.contoso.com . The FQDN is
sts.contoso.com .

2. Go to the following URL, replacing <STS_SERVER_FQDN_HERE> with your STS

FQDN:

https://www.ssllabs.com/ssltest/analyze.html?d=

<STS_SERVER_FQDN_HERE>&hideResults=on&latest

For example:

https://www.ssllabs.com/ssltest/analyze.html?

d=sts.contoso.com&hideResults=on&latest
 3. See whether any of the following messages are displayed:

Extra download
Sent by server
In trust store

If any of the SSL certificates displays the "Extra download" message, you are
experiencing the issue that's described earlier in this section, per the following
screenshot:

Here's a screenshot showing a certificate with the "Sent by server" message,

illustrating successful authentication on an Android device:

Cause
Android does not support downloading additional certificates from the
authorityInformationAccess field of the certificate. This is true across all Android
versions and devices, and for the Chrome browser. Any server authentication certificate
that's marked for extra download based on the authorityInformationAccess field will
trigger this error if the entire certificate chain is not passed from Active Directory
Federation Services (AD FS).
Resolution
To resolve this issue, configure your STS and Web Application Proxy (WAP) servers to
send the necessary intermediate certificates together with the SSL certificate. To do this,
follow these steps:

1. When you export the SSL certificate from a computer to the computer's personal
store of the AD FS and WAP server (or servers), make sure that you export the
Private key and that you select Personal Information Exchange - PKCS #12. Also
make sure that the Include all certificates in the certificate path if possible and
Export all extended properties check boxes are selected.
2. Run certlm.msc on the Windows servers, and then import the *.PFX file into the
computer's personal certificate store. When you do this, the server will pass the
entire certificate chain when a client application uses ADAL for authentication.

７ Note

The certificate store of Network Load Balancers should also be updated to include
the entire certificate chain.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Error when you perform a Workplace
Join: Confirm you are using the current
sign-in info
Article • 04/20/2022 • 2 minutes to read

This article describes a problem in which an error occurs when you perform a Workplace
Join operation.

Original product version:   Windows 8.1 Enterprise, Windows Server 2012 R2 Datacenter,
Windows Server 2012 R2 Standard, Azure Active Directory

Original KB number:   3045386

Symptoms
When you try to perform a Workplace Join operation, you receive this error message:

Confirm you are using the current sign-in info, and that your workplace uses this
feature. Also, the connection to your workplace might not be working right now.
Please wait and try again.

Additionally, an administrator may see the following event details in Event Viewer:

Event ID: 103

Log Name: Microsoft-Windows-Workplace Join/Admin

Source: Microsoft-Windows-Workplace Join

Level: Error

Description: Workplace Join discovery failed. Server returned http status 404.

https://EnterpriseRegistration.domain.com:443/EnrollmentServer/contract?api-
version=1.0

Cause
This problem occurs for one of the following reasons:

The client is being redirected to the internal Device Registration Service (DRS)
instance where the DRS endpoint is disabled or stopped.
The DNS records for the EnterpriseRegistration service are missing or
misconfigured.
 The domain suffix of the currently logged-on user is not accounted for in the SSL
certificate of DRS.
The network or firewall is blocking traffic, or transient network issues are causing
packet loss.

Resolution

Verify DNS
Verify the DNS configuration by using the NSlookup tool, and verify that the answers are
correct.

To do this, open a Command Prompt window, and then run the following command:

Console

Nslookup enterpriseregistration.domain.com

If you use Azure Active Directory Join

This should return the CNAME result of EnterpriseRegistration.windows.net as
the target.
If you use Windows Server Workplace Join
The internal host should return the internal AD FS node.
The external host should return the external AD FS proxy address.

Verify that Device Registration is enabled

If you try to perform Workplace Join to Azure Active Directory, follow these steps:

1. Sign in to Azure portal, or launch the Azure AD console from the M365 admin
center as a Company Administrator.
2. Locate the directory where the user is trying the join operation.
3. Go to Configure.
4. Scroll down to the Device Registration section.
5. Make sure that the setting that's labeled ENABLE WORKPLACE JOIN is toggled to
Yes (Yes will be blue).

If you try to perform a Workplace Join to your local Active Directory domain, follow
these steps:
 1. Start the AD FS Management console, and then select Relying Party Trusts to
determine whether the Device Registration Service trust is Enabled on each node
of the AD FS farm.
2. If Device Registration Service is Enabled, check the Services Console to make sure
that the Device Registration Service is started.

Check the SSLCertificate bindings

If you try to perform Workplace Join to your local Active Directory domain, follow these
steps:

1. Open a Command Prompt window as an administrator, type the following

commands, and press Enter after each command to display the bindings on the
ADFS Proxy or ADFS Server:

Console

Netsh

Console

Http Show SSLCert

2. Determine whether the IP Port Binding (not Name binding) is present.

3. If the IP Port binding is not present, review to determine whether the

EnterpriseRegistration Name binding is present.

More information
For more troubleshooting information, see the following article in the Microsoft
Knowledge Base:

Diagnostic logging for troubleshooting Workplace Join issues .

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Can't sync SystemMailbox or
DiscoveryMailboxSearch accounts using
Azure Active Directory Sync tool
Article • 04/20/2022 • 2 minutes to read

This article provides information about resolve a problem in which you receive errors
when trying to use the Azure Active Directory Sync tool to synchronize the
SystemMailbox and DiscoverySearchMailbox user accounts.

Original product version:   Cloud Services (Web roles/Worker roles), Azure Active
Directory, Microsoft Intune, Azure Backup, Office 365 Identity Management

Original KB number:   2804688

Symptoms
When you use the Microsoft Azure Active Directory Sync tool to sync the following user
accounts, you receive directory synchronization errors:

SystemMailbox{1f05a927-beed-480c-b962-
da8d1d7e16a8}@<DomainNameName>
SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}@<DomainName>
DiscoverySearchMailbox{D919BA05-46A6-415f-80AD-
7E09334BB852}@<DomainNameName>

Cause
This issue occurs if the three user accounts that were created during Microsoft Exchange
Server 2010 installation are missing the attribute data. In this case, the attribute data is
used by the Azure Active Directory Sync tool to filter out these user accounts and stop
them from being synced to the cloud.

Resolution
To resolve this issue, use one of the following methods, as appropriate for your
situation.

Method 1
On the domain controller or a computer on which the Active Directory Domain Services
Administration Tools are installed, follow these steps:

1. Open Active Directory Users and Computers.

2. On the View menu, select Advanced Features.

3. Select the Users container.

4. Double-click each SystemMailbox user account, and then follow these steps for
each account:
a. Select Attribute Editor.
b. Find the mailNickName attribute, and then populate the attribute by using the
value that's included in the mail attribute.
c. Select OK.

5. Double-click each DiscoverySearchMailbox user account, and then follow these

steps for each account:
a. Select Attribute Editor.
b. Find the mailNickName attribute, and then populate the attribute by using the
value that is included in the mail attribute.
c. Find the msExchRecipientTypeDetails attribute, and then set the value of the
attribute to 536870912.
d. Select OK.

Method 2

On the computer on which the Directory Sync tool is installed, follow these steps:

1. Open an elevated command prompt.

2. Open Windows PowerShell, type Import-Module DirSync , and then press Enter.

3. After the Windows PowerShell session starts, run the following cmdlet:

PowerShell

Start-OnlineCoexistenceSync

If the methods did not work, see Recreate missing arbitration mailboxes.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Error when you try to reset your
password in Azure, Office 365, or
Intune: We could not verify your
account
Article • 04/20/2022 • 2 minutes to read

This article describes a problem in which you receive an error message "We could not
verify your account" when you try to reset your password in Microsoft Azure, Office 365,
or Microsoft Intune. To resolve this problem, work with your administrator to update
your telephone number.

Original product version:   Azure Active Directory, Microsoft Intune, Cloud Services (Web
roles/Worker roles)

Original KB number:   2951246

Symptoms
When you use Microsoft Azure, Microsoft Office 365, or Microsoft Intune, you may
receive the following error message when you try to reset your password:

We could not verify your account.

Cause
This problem may occur because there are no telephone numbers on file for you.

Resolution
To resolve this problem, work with your administrator to update your telephone
number(s).

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Code 403 (Forbidden) when you use
Azure Seamless Single Sign-On on
Windows 10
Article • 04/20/2022 • 2 minutes to read

This article can help you resolve a problem in which you receive Code 403 (Forbidden)
when using Azure Seamless Single Sign-On on Windows 10.

Original product version:   Azure Active Directory, Windows 10

Original KB number:   4135083

Symptoms
The Azure Seamless Single Sign-On authentication does not work after you upgrade to
Windows 10. When this problem occurs, you may receive the following error message:

Integrated Windows Authentication failed with status code 403 (Forbidden).

Resolution
To resolve this problem, follow these steps:

1. Check the following Group Policy object, and make sure that it is set to not
defined:

Network security: Configure encryption types allowed for Kerberos

If you update the Group Policy setting, run gpupdate /force to push the changes
to the devices.

2. Start Registry Editor, and browse to the following subkey:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\k

erberos\parameters

3. Delete the supportedencryptiontypes DWORD entry if it exists.

4. Restart the device.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Can't connect to Office 365, Azure, or
Intune using the Azure Active Directory
Module for Windows PowerShell
Article • 04/20/2022 • 2 minutes to read

This article describes an issue in which you can't connect to a Microsoft cloud service
such as Office 365, Azure, or Microsoft Intune by using the Connect-MSOLService cmdlet.

Original product version:   Azure Active Directory, Microsoft Intune, Azure Backup, Office
365 User and Domain Management, Office 365 Identity Management

Original KB number:   2494043

Symptoms
When you try to use the Connect-MSOLService cmdlet in the Microsoft Azure Active
Directory Module for Windows PowerShell to connect to a Microsoft cloud service such
as Office 365, Microsoft Azure, or Microsoft Intune, your attempt is unsuccessful.
Instead, you receive one of the following error messages:

Connect-MsolService : Exception of type

'Microsoft.Online.Administration.Automation.MicrosoftOnlineException' was thrown.

Connect-MsolService : Access Denied. You do not have permissions to call this

cmdlet.

Connect-MsolService : The user name or password is incorrect. Verify your user

name, and then type your password again.`

Resolution
To resolve this issue, refer one of the following articles, as appropriate for your situation:

"Connect-MsolService: Exception of type was thrown" error

"Access Denied" error
"The user name or password is incorrect" error

More information
For more information about Azure Active Directory Module for Windows PowerShell, see
Manage Azure AD using Windows PowerShell.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
ESR settings don't sync with multi-factor
authentication enabled
Article • 04/27/2022 • 2 minutes to read

Original product version:   Windows 10 version 1709 all editions, Windows 10 version
1703 all editions, Windows 10 version 1511 all editions, Windows 10 version 1607 all
editions

Original KB number:   3193683

Symptoms
You have enabled Enterprise State Roaming (ESR) in the Azure Active Directory portal
and on some Windows 10 clients. Any supported settings for sync, such as the desktop
background or task bar position, don't sync between devices for the same user. The
following events 1098 and 1097 are logged in the Microsoft-Windows-AAD/Operational
event log:

Console

Log Name:      Microsoft-Windows-AAD/Operational

Source:        Microsoft-Windows-AAD

Event ID:      1098

Task Category: AadTokenBrokerPlugin Operation

Level:         Error

Keywords:      Error,

Error Computer:      Win10client.contoso.com

Description: Error: 0xCAA2000C The request requires user interaction. Code:

interaction_required Description: AADSTS50076: The user is required to use
multi-factor authentication to access this resource. Please retry with a new
authorize request for the resource 'https://syncservice.windows.net/*'.
Trace ID: <Trace ID GUID> Correlation ID: <Correlation ID GUID> Timestamp:
yyyy-mmmm-dddd 01:30:38Z

TokenEndpoint: https://login.microsoftonline.com/common/oauth2/token
Authority: https://login.microsoftonline.com/common

Client ID: <Client ID GUID>

Redirect URI: ms-appx-web://Microsoft.AAD.BrokerPlugin/<Client ID GUID>

Resource: https://syncservice.windows.net/*

Correlation ID (request): <Correlation ID GUID>

Log Name:      Microsoft-Windows-AAD/Operational

Source:        Microsoft-Windows-AAD

Event ID:      1097 Task Category: AadTokenBrokerPlugin

Operation Level:         Warning

Keywords:      Operational,

Operational Computer:      Win10client.contoso.com

Description: Error: 0xCAA90004 Getting token by refresh token failed.

Authority: https://login.microsoftonline.com/common

 Client ID: <Client ID GUID> Redirect URI: ms-appx-

web://Microsoft.AAD.BrokerPlugin/<Client ID GUID>

Resource: https://syncservice.windows.net/*

Correlation ID (request): <Correlation ID GUID>

Cause
Multi-factor authentication (MFA) is enabled, and that's why Enterprise State Roaming
won't prompt the user for additional authorization.

Resolution
If your device is configured to require multi-factor authentication on the Azure Active
Directory portal, you may fail to sync settings while you sign in to a Windows 10 device
using a password. This type of multi-factor authentication configuration is intended to
protect an Azure administrator account. Admin users may still be able to sync by signing
in to their Windows 10 devices with their Microsoft Passport for Work PIN or by
completing multi-factor authentication while accessing other Azure services, such as
Microsoft Office 365.

Sync can fail if the Azure AD Administrator configures the Active Directory Federation
Services multi-factor authentication conditional access policy, and the access token on
the device expires. Make sure that you sign in and sign out using the Microsoft Passport
for Work PIN, or complete multi-factor authentication when accessing other Azure
services like Office 365.

More Information
Microsoft is investigating how to improve the experience with Enterprise State Roaming
and MFA authorization enabled on the device.

For more information, see Settings and data roaming FAQ.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Enable support for TLS 1.2 in your environment
for Azure AD TLS 1.1 and 1.0 deprecation
Article • 10/06/2022 • 13 minutes to read

To improve the security posture of your tenant, and to remain in compliance with industry standards,
Microsoft Azure Active Directory (Azure AD) will soon stop supporting the following Transport Layer
Security (TLS) protocols and ciphers:

TLS 1.1
TLS 1.0
3DES cipher suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA)

How this change might affect your organization

Do your applications communicate with or authenticate against Azure Active Directory? Then those
applications might not work as expected if they can't use TLS 1.2 to communicate. This situation includes:

Azure AD Connect
Azure AD PowerShell
Azure AD Application Proxy connectors
PTA agents
Legacy browsers
Applications that are integrated with Azure AD

Why this change is being made

These protocols and ciphers are being deprecated for the following reasons:

To follow the latest compliance standards for the Federal Risk and Authorization Management
Program (FedRAMP) .
To improve security when users interact with our cloud services.

The services are being deprecated on the following dates:

TLS 1.0, 1.1 and 3DES Cipher suite in U.S. government instances starting on March 31, 2021.
TLS 1.0, 1.1 and 3DES Cipher suite in public instances starting January 31, 2022. (This date has been
postponed from June 30th, 2021 to January 31st, 2022, to give administrators more time to remove
the dependency on legacy TLS protocols and ciphers (TLS 1.0,1.1 and 3DES).)

Enable support for TLS 1.2 in your environment

How do you maintain a secure connection to Azure Active Directory (Azure AD) and Microsoft 365
services? You enable your client apps and client and server operating system (OS) for TLS 1.2 and modern
cipher suites.

Guidelines for enabling TLS 1.2 on clients

 Update Windows and the default TLS that you use for "WinHTTP".
Identify and reduce you dependency on the client apps and operating systems that don't support TLS
1.2.
Enable TLS 1.2 for applications and services that communicate with Azure AD.
Update and configure your .NET Framework installation to support TLS 1.2.
Make sure that applications and PowerShell (that use Microsoft Graph ) and Azure AD PowerShell
scripts are hosted and run on a platform that supports TLS 1.2.
Make sure that your web browser has the latest updates. We recommend that you use the new
Microsoft Edge browser (based on Chromium). For more information, see the Microsoft Edge release
notes for Stable Channel.
Make sure that your web proxy supports TLS 1.2. For more information about how to update a web
proxy, check with the vendor of your web proxy solution.

For more information, see the following articles:

How to enable TLS 1.2 on clients

Preparing for TLS 1.2 in Office 365 and Office 365 GCC - Microsoft 365 Compliance

Update the Windows OS and the default TLS that you use for
WinHTTP
These operating systems natively support TLS 1.2 for client-server communications over WinHTTP:

Windows 10
Windows 8.1
Windows Server 2016
Windows Server 2012 R2
Later versions of Windows and Windows Server

Verify that you haven't explicitly disabled TLS 1.2 on these platforms.

By default, earlier versions of Windows (such as Windows 8 and Windows Server 2012) don't enable TLS
1.2 or TLS 1.1 for secure communications by using WinHTTP. For these earlier versions of Windows:

1. Install Update 3140245 .

2. Enable the registry values from the Enable TLS 1.2 on client or server operating systems section.

You can configure those values to add TLS 1.2 and TLS 1.1 to the default secure protocols list for WinHTTP.

For more information, see How to enable TLS 1.2 on clients.

７ Note

By default, an OS that supports TLS 1.2 (for example, Windows 10) also supports legacy versions of
the TLS protocol. When a connection is made by using TLS 1.2 and it doesn’t get a timely response, or
when the connection is reset, the OS might try to connect to the target web service by using an older
TLS protocol (such as TLS 1.0 or 1.1). This usually occurs if the network is busy, or if a packet drops in
the network. After the temporary fallback to the legacy TLS, the OS will try again to make a TLS 1.2
connection.
 What will be the status of such fallback traffic after Microsoft stops supporting the legacy TLS? The OS
might still try to make a TLS connection by using the legacy TLS protocol. But if the Microsoft service
is no longer supporting the older TLS protocol, the legacy TLS-based connection won’t succeed. This
will force the OS to try the connection again by using TLS 1.2 instead.

Identify and reduce dependency on clients that don't support TLS 1.2
Update the following clients to provide uninterrupted access:

Android version 4.3 and earlier versions

Firefox version 5.0 and earlier versions
Internet Explorer versions 8-10 on Windows 7 and earlier versions
Internet Explorer 10 on Windows Phone 8.0
Safari 6.0.4 on OS X 10.8.4 and earlier versions

For more information, see Handshake Simulation for various clients connecting to www.microsoft.com,
courtesy SSLLabs.com.

Enable TLS 1.2 on common server roles that communicate with Azure
AD
Azure AD Connect (install the latest version)
Do you also want to enable TLS 1.2 between the sync engine server and a remote SQL Server?
Then make sure you have the required versions installed for TLS 1.2 support for Microsoft SQL
Server .

Azure AD Connect Authentication Agent (pass-through authentication) (version 1.5.643.0 and later
versions)

Azure Application Proxy (version 1.5.1526.0 and later versions enforce TLS 1.2)

Active Directory Federation Services (AD FS) for servers that are configured to use Azure Multi-Factor
Authentication (Azure MFA)

NPS servers that are configured to use the NPS extension for Azure AD MFA

MFA Server version 8.0.x or later versions

Azure AD Password Protection proxy service

Action required

1. We highly recommend that you run the latest version of the agent, service, or connector.

2. By default, TLS 1.2 is enabled on Windows Server 2012 R2 and later versions. In rare instances,
the default OS configuration might have been modified to disable TLS 1.

To make sure that TLS 1.2 is enabled, we recommend that you explicitly add the registry values
from the Enable TLS 1.2 on client or server operating systems section on servers that are
running Windows Server and that communicate with Azure AD.
 3. Most of the previously listed services are dependent on .NET Framework. Make sure it's
updated as described in the Update and configure .NET Framework to support TLS 1.2 section.

For more information, see the following articles:

TLS 1.2 enforcement - Enforce TLS 1.2 for the Azure AD Registration Service
Azure AD Connect: TLS 1.2 enforcement for Azure Active Directory Connect
Understand Azure AD Application Proxy connectors

Enable TLS 1.2 on client or server operating systems

Registry strings
To manually configure and enable TLS 1.2 at the operating system level, you can add the following
DWORD values.

For Windows 2012 R2, Windows 8.1, and later OS, TLS 1.2 is enabled by default. Thus, the following
registry values aren't required unless they were set with different values.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
1.2\Client
"DisabledByDefault": 00000000
"Enabled": 00000001
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
1.2\Server
"DisabledByDefault": 00000000
"Enabled": 00000001
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319
"SchUseStrongCrypto": 00000001

To enable TLS 1.2 by using a PowerShell script, see TLS 1.2 enforcement for Azure AD Connect.

Update and configure .NET Framework to support TLS 1.2

Managed Azure AD-integrated applications and Windows PowerShell scripts (using Azure AD PowerShell
V1 (Microsoft MSOnline), V2 (AzureAD), Microsoft Graph ) may use .NET Framework.

Install .NET updates to enable strong cryptography

Determine the .NET version

First, determine the installed .NET versions.

For more information, see Determine which versions and service pack levels of .NET Framework are
installed.

Install .NET updates

Install the .NET updates so that you can enable strong cryptography. Some versions of .NET Framework
might have to be updated to enable strong cryptography.

Use these guidelines:

.NET Framework 4.6.2 and later versions support TLS 1.2 and TLS 1.1. Check the registry settings. No
other changes are required.

Update .NET Framework 4.6 and earlier versions to support TLS 1.2 and TLS 1.1.

For more information, see .NET Framework versions and dependencies.

Do you use .NET Framework 4.5.2 or 4.5.1 on Windows 8.1 or Windows Server 2012? Then the
relevant updates and details are also available from Microsoft Update Catalog .
Also see Microsoft Security Advisory 2960358.

For any computer that communicates across the network and runs a TLS 1.2-enabled system, set the
following registry DWORD values.

For 32-bit applications that are running on a 32-bit OS and 64-bit applications that are running on a
64-bit OS, update the following subkey values:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727
"SystemDefaultTlsVersions": 00000001
"SchUseStrongCrypto": 00000001

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319
"SystemDefaultTlsVersions": 00000001
"SchUseStrongCrypto": 00000001

For 32-bit applications that are running on 64-bit OSs, update the following subkey values:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727
"SystemDefaultTlsVersions": dword:00000001
"SchUseStrongCrypto": dword:00000001
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319
"SystemDefaultTlsVersions": dword:00000001
"SchUseStrongCrypto": dword:00000001

For example, set these values on:

Configuration Manager clients

Remote site system roles that aren't installed on the site server
The site server itself

For more information, see the following articles:

TLS Cipher Suites supported by Azure AD

How to enable TLS 1.2 on clients
Transport Layer Security (TLS) best practices with the .NET Framework
Solving the TLS 1.0 Problem - Security documentation

Overview of new telemetry in the sign-in logs

To help you identify any clients or apps that still use legacy TLS in your environment, view the Azure AD
sign-in logs. For clients or apps that sign in over legacy TLS, Azure AD marks the Legacy TLS field in
Additional Details with True. The Legacy TLS field only appears if the sign-in occurred over legacy TLS. If
you don’t see any legacy TLS in your logs, you're ready to switch to TLS 1.2.

To find the sign-in attempts that used legacy TLS protocols, an administrator can review the logs by:

Exporting and querying the logs in Azure Monitor.

Downloading the last seven days of logs in JavaScript Object Notation (JSON) format.
Filtering and exporting sign-in logs using PowerShell.

These methods are described below.

Azure Monitor

You can query the sign-in logs using Azure Monitor. Azure Monitor is a powerful log analysis,
monitoring, and alerting tool. Use Azure Monitor for:

Azure AD logs
Azure resources logs
Logs from independent software tools

７ Note

You need an Azure AD Premium license to export reporting data to Azure Monitor.

To query for legacy TLS entries using Azure Monitor:

1. In Integrate Azure AD logs with Azure Monitor logs, follow the instructions for how to access the
Azure AD sign-in logs in Azure Monitor.

2. In the query definition area, paste the following Kusto Query Language query:

Kusto

// Interactive sign-ins only

SigninLogs

| where AuthenticationProcessingDetails has "Legacy TLS"

and AuthenticationProcessingDetails has "True"

| extend JsonAuthProcDetails = parse_json(AuthenticationProcessingDetails)

| mv-apply JsonAuthProcDetails on (

where JsonAuthProcDetails.key startswith "Legacy TLS"

| project HasLegacyTls=JsonAuthProcDetails.value

| where HasLegacyTls == true

// Non-interactive sign-ins

AADNonInteractiveUserSignInLogs

| where AuthenticationProcessingDetails has "Legacy TLS"

and AuthenticationProcessingDetails has "True"

| extend JsonAuthProcDetails = parse_json(AuthenticationProcessingDetails)

| mv-apply JsonAuthProcDetails on (

where JsonAuthProcDetails.key startswith "Legacy TLS"

| project HasLegacyTls=JsonAuthProcDetails.value

| where HasLegacyTls == true

 // Workload Identity (service principal) sign-ins

AADServicePrincipalSignInLogs

| where AuthenticationProcessingDetails has "Legacy TLS"

and AuthenticationProcessingDetails has "True"

| extend JsonAuthProcDetails = parse_json(AuthenticationProcessingDetails)

| mv-apply JsonAuthProcDetails on (

where JsonAuthProcDetails.key startswith "Legacy TLS"

| project HasLegacyTls=JsonAuthProcDetails.value

| where HasLegacyTls == true

3. Select Run to execute the query. The log entries that match the query appear in the Results tab
below the query definition.

4. To learn more about the source of the legacy TLS request, look for the following fields:

UserDisplayName
AppDisplayName
ResourceDisplayName
UserAgent

View details about log entries in the Azure AD portal

After you obtain the logs, you can get more details about legacy TLS-based sign-in log entries in the Azure
AD portal. Follow these steps:

1. In the Azure portal , search for and select Azure Active Directory.

2. In the Overview page menu, select Sign-in logs.

3. Select a sign-in log entry for a user.

4. Select the Additional details tab. (If you don't see this tab, first select the ellipsis (...) in the right
corner to view the full list of tabs.)

5. Check for a Legacy TLS (TLS 1.0, 1.1, or 3DES) value that's set to True. If you see that particular field
and value, the sign-in attempt was made using legacy TLS. If the sign-in attempt was made using TLS
1.2, that field doesn't appear.

For more information, see Sign-in logs in Azure Active Directory.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community support.
Federated users in Azure AD are forced
to sign in frequently
Article • 04/20/2022 • 4 minutes to read

This article discusses an issue in which federated users in Azure AD are forced to sign in
frequently.

Original product version:   Azure Active Directory

Original KB number:   4025960

Symptoms
After federated users sign in to Azure Active Directory (Azure AD), they are forced to
continually sign back in instead of being kept signed in.

Cause
Federated users who do not have the LastPasswordChangeTimestamp attribute synced
are issued session cookies and refresh tokens that have a Max Age  value of 12 hours.
This means that the program can silently retrieve new tokens to keep the user's session
alive only up to 12 hours. After that time, the users are returned to the original IdP to re-
authenticate.

This occurs because Azure AD cannot determine when to revoke tokens that are
related to an old credential (such as a password that has been changed). Therefore,
Azure AD must check more frequently to make sure that the user and associated tokens
are still in good standing.
For more information about token lifetimes and how they are
managed, see the following Microsoft Azure article:

Configurable token lifetimes in Azure Active Directory (Public Preview)

Resolution
To resolve this problem, tenant admins must make sure to sync the
LastPasswordChangeTimestamp  attribute. Syncing this attribute improves the
user experience and security status.

This setting can be made on the user object by using PowerShell or through Azure AD
Connect.
PowerShell
You can use the Azure AD PowerShell V1 (MSOnline) module to set the
StsRefreshTokensValidFrom attribute for a user. This will inform the Azure Active
Directory authentication flow to give the user a longer lasting Refresh Token or one
based on your Azure Active Directory policies. To do this, follow these steps:

1. Download the latest Azure AD PowerShell V1 release.

2. Run the Connect command to sign in to your Azure AD admin account every time
that you start a new session:

PowerShell

Connect-msolservice

3. Set the StsRefreshTokensValidFrom attribute by using the following commands:

PowerShell

$RefreshTokensValidFrom = Get-Date

Set-MsolUser -UserPrincipalName<UPN of user>-StsRefreshTokensValidFrom

$RefreshTokensValidFrom

For example:

PowerShell

$RefreshTokensValidFrom = Get-Date

Set-MsolUser -UserPrincipalName john@contoso.com -

StsRefreshTokensValidFrom $RefreshTokensValidFrom

７ Note

StsRefreshTokenValidFromwill appear to accept any date, but it will always set

to the current date and time.

4. For more help, contact Azure Support .

Azure AD Connect
Azure AD Connect syncs this attribute by default. However, Azure AD Connect can be
configured to sync or not sync this attribute either by using the attribute filtering feature
or by disabling the out-of-box synchronization rules.

Using the Azure AD app and attribute filtering feature

If you have previously disabled synchronization of the PwdLastSet attribute by using the
Azure AD app and attribute filtering feature, follow these steps to re-enable the process:

Disabling the out-of-box synchronization rules

1. Log in to the Azure AD Connect server, and then start the Azure AD Connect
wizard.

2. Click Customize synchronization options task.

3. Navigate to the Optional Features screen, and verify that the Azure AD app and
attribute filtering feature is enabled. If it isn't, this means that the feature hasn't
been used to disable synchronization of the PwdLastSet attribute.

4. Navigate to Azure AD Attributes screen, and enable the PwdLastSet attribute. If

it's already enabled, this means that the feature hasn't been used to disable
synchronization of the PwdLastSet attribute.

5. Complete the wizard, and then save the configuration.

6. Run a Full Synchronization cycle by running the following cmdlet in PowerShell:

PowerShell

Start-ADSyncSyncCycle -policyType initial

７ Note

If the Azure AD app and attribute filtering feature is disabled (see step 3) or
the PwdLastSet attribute is already enabled (see step 4), this means that the
feature hasn't been used to disable the PwdLastSet attribute. In this situation,
you can skip steps 5 and 6.

Azure AD Connect implements the synchronization of PwdLastSet attribute by using the

following out-of-box synchronization rules.

Out-of-box sync Details

rule
 Out-of-box sync Details
rule

In from AD User Common Imports on-premises AD PwdLastSet attribute to Metaverse

PwdLastSet attribute.

Out of Azure AD User Join Exports Metaverse PwdLastSet

attribute to Azure AD LastPasswordChangeTimestamp attribute.

In the following screen shot, you can see how the attribute flow is implemented in both
synchronization rules by using the Azure AD Connect Synchronization Rules Editor.

Customers may disable the synchronization of PwdLastSet attribute by disabling these

out-of-box sync rules and replacing them with custom sync rules. To enable
synchronization of the PwdLastSet attribute, consider re-enabling these out-of-box sync
rules or implementing the same attribute flow in existing custom sync rules.

For more information about how to implement and verify sync rule changes, see  to
article Azure AD Connect sync: How to make a change to the default configuration.

Password hash synchronization

If the Password Hash Synchronization feature is enabled on Azure AD Connect, the
Password Synchronization Manager synchronizes the on-premises Active Directory
PwdLastSet attribute with the Azure AD LastPasswordChangeTimestamp attribute. This
is true even if the PwdLastSet attribute has been filtered by using the two methods in
this section.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Federated user is prompted
unexpectedly to enter account
credentials
Article • 06/21/2022 • 5 minutes to read

This article describes a scenario in which a federated user is prompted unexpectedly to

enter their work or school account credentials when accessing Office 365, Azure, or
Microsoft Intune.

Original product version:   Azure Active Directory, Microsoft Intune, Azure Backup, Office
365 Identity Management

Original KB number:   2535227

Symptoms
When a federated user signs in Office 365, Microsoft Azure, or Microsoft Intune, the user
is prompted unexpectedly to enter the work or school account credentials. After the
user enters the credentials, the user is granted access to the cloud service.

７ Note

Not all federated user authentication experiences are without a credential prompt.
In certain scenarios, it's by design and expected that federated users are prompted
to enter their credentials. Make sure that the credential prompt is unexpected
before you continue.

Cause
This issue may occur for internal domain clients if one or more of the following
conditions are true:

An internal client resolves the Active Directory Federation Services (AD FS)
endpoint to the IP address of the AD FS proxy service instead of to the IP address
of the AD FS federation service.
The security settings in Internet Explorer are not configured for single sign-on to
AD FS.
The proxy server settings in Internet Explorer are not configured for single sign-on
to AD FS.
 The web browser does not support integrated Windows authentication.
The client computer cannot connect to the on-premises Active Directory domain.

Resolution 1: Make sure that the DNS server

has a host record for the AD FS endpoint
Make sure that the DNS server has a host record for the AD FS endpoint that is
appropriate to the client computer that is experiencing this issue. For internal clients,
this means that the internal DNS server should resolve the AD FS endpoint name to an
internal IP address. For Internet clients, this means that the endpoint name should
resolve to a public IP address. To test this on the client, follow these steps:

1. Select Start, select Run, type cmd, and then press Enter.

2. At the command prompt, type the following command, where the placeholder
sts.contoso.com represents the AD FS endpoint name:

Console

nslookup sts.contoso.com

3. If the output of the command shows an incorrect IP address, update the A record
on the internal or external DNS server. For more information about how to do this,
see Internet browser can't display the AD FS sign-in webpage for federated users
Internet browser can't display the AD FS webpage when a federated user tries to
sign in to Office 365, Azure, or Intune

Resolution 2: Check the local intranet zone and

proxy server settings in Internet Explorer
Use one of the following procedures, as appropriate for your situation.

Procedure A
Check the local intranet zone and proxy server settings in Internet Explorer. To do this,
follow these steps:

1. Start Internet Explorer.

2. On the Tools menu, select Internet Options.

 3. Select the Security tab, select the Local intranet zone, and then select Sites.

4. In the Local intranet dialog box, select Advanced. In the Websites list, make sure
that an entry (such as sts.contoso.com ) exists for the fully qualified DNS name of
the AD FS service endpoint.

5. Select Close, and then select OK.

７ Note

Use the following additional steps only if a network administrator configured

a web proxy server in the on-premises environment:

6. Select the Connections tab, and then select LAN Settings.

7. Under Automatic configuration, select to clear the Automatically detect settings

check box, and then select to clear the Use automatic configuration script check
box.

8. Under Proxy server, select to select the Use a proxy server for your LAN check
box, type the proxy server address and the port that it uses, and then select
Advanced.

9. Under Exceptions, add your AD FS endpoint (such as sts.contoso.com ).

10. Select OK three times.

Procedure B
Manually configure the security settings for the security zone in Internet Explorer. The
default security setting that causes the local intranet zone not to prompt for Windows
authentication can be configured manually for any security zone in Internet Explorer. To
customize the security zone of which the AD FS service name is already a part, follow
these steps:

２ Warning

We highly discourage this configuration because it could result in the unintended

submission of Integrated Windows Authentication traffic to websites.

1. Start Internet Explorer.

2. On the Tools menu, select Internet options.
 3. Select the Security tab, select the security zone in which the AD FS service name is
already contained, and then select Custom level.
4. In the Security Settings dialog box, scroll to the bottom to locate the User
Authentication entry.
5. Under Logon, select Automatic logon with current user name and password.
6. select OK two times.

Resolution 3: Use Internet Explorer or a third-

party web browser
Use Internet Explorer or a third-party web browser that supports integrated Windows
authentication.

Resolution 4: Verify connectivity to Active

Directory
Log off from the client computer and then log on as an Active Directory user. If logon is
successful, verify the connectivity to Active Directory by using the Nltest command-line
tool. Nltest.exe is included in the Remote Server Administration Tools for Windows 10 .

1. At a command prompt, type the following command, and then press Enter: Nltest
/dsgetdc:<FQDN Of Domain> . If the settings are correct, you receive output that

resembles the following:

DC: \DC.contoso.com Address:\ <IP Address> Dom Guid: <GUID>

Dom Name:
contoso.com Forest Name: contoso.com Dc Site Name: Default-First-Site-
Name
Our Site Name: Default-First-Site-Name Flags: PDC GC DS LDAP KDC
TIMESERV GTIMESERV WRITABLE
DNS_DC DNS_DOMAIN DNS_FOREST
CLOSE_SITE The command completed successfully

2. Check the computer's site membership. To do this, type the following command,
and then press Enter: nltest /dsgetsite . A successful result resembles the
following:

Default-First-Site-Name The command completed successfully

More information
Accessing Office 365 resources by using a non-federated account or a federated
account from a public Internet connection may not result in a single sign-on experience.

The experience for logging on to Microsoft Outlook connections is also not expected to
be a single sign-on experience.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Federated users in Azure Active
Directory may have to sign in two times
before being prompted for MFA
Article • 04/20/2022 • 2 minutes to read

This article discusses an issue in which federated users in Azure Active Directory must
sign in two times before they can run MFA.

Original product version:   Azure Active Directory

Original KB number:   4037806

Symptoms
Consider the following scenario:

You have an Azure Active Directory (Azure AD) tenant in which users are federated
through Active Directory Federated Services (AD FS).
In this tenant, Azure MFA Server or a third-party MFA provider is deployed in AD
FS.

In this scenario, users may be forced to sign in by providing their user name and
password two times before they are prompted for multi-factor authentication (MFA) and
can complete the logon.

Cause
If the MsolDomainFederationSettings -SupportsMFA value is set to $true and the -
PromptLoginBehavior value is set to TranslateToFreshPasswordAuth, Azure AD sends
the MFA request to the Identity Provider for step-up authentication. Azure AD also asks
for a fresh user login. This is accomplished by sending the following parameters to AD
FS:

wauth=http://schemas.microsoft.com/claims/multipleauthn

wfresh=0

When this occurs, user is prompted a second time for their user name and password
regardless of whether they just logged in. Users are prompted for MFA only after they
enter their credentials a second time.
Resolution
To resolve this issue, you must configure Azure AD to let AD FS natively handle this
request by changing the -PromptLoginBehavior setting to NativeSupport. To do this,
follow these steps:

） Important

Your AD FS deployment must be running on Windows Server 2016 or Windows

Server 2012 R2, and must have the July 2016 update KB 3172614 installed.

1. Run the following Connect command to sign in to your Azure AD administrator

account:

PowerShell

Connect-Msolservice

７ Note

Run this command every time that you start a new session.

2. Configure Azure AD to run federated user authentication by using the

prompt=login behavior. This prevents the user from having to begin a new
authentication. For example, run a command such as the following that includes
your tenant-specific information:

PowerShell

Set-MsolDomainFederationSettings -DomainNameyour_domain_name-
PreferredAuthenticationProtocol <current auth setting such as WsFed> -
SupportsMfa $True -PromptLoginBehavior NativeSupport

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Error when you try to set up another
federated domain in Office 365, Azure,
or Intune: Federation service identifier
specified in the AD FS 2.0 server is
already in use
Article • 04/20/2022 • 4 minutes to read

This article provides information about resolving an issue in which you receive an error
message when running the New-MSOLFederatedDomain command or the Convert-
MSOLDomainToFederated command using Azure Active Directory Module for Windows

PowerShell.

Original product version:   Cloud Services (Web roles/Worker roles), Azure Active
Directory, Microsoft Intune, Azure Backup, Office 365 Identity Management

Original KB number:   2618887

Symptoms
In a Microsoft cloud service such as Office 365, Microsoft Azure, or Microsoft Intune, you
can't set up a second federated domain on an Active Directory Federation Services (AD
FS) server. When you use the Azure Active Directory Module for Windows PowerShell to
run the New-MSOLFederatedDomain command or the Convert-MSOLDomainToFederated
command, you receive the following error message:

The federation service identifier specified in the Active Directory Federation Services
2.0 server is already in use. Please correct this value in the AD FS 2.0 Management
console and run the command again.

Cause
The Azure Active Directory (Azure AD) authentication system requires a unique
federation brand uniform resource identifier (URI) for each federated domain. By default,
AD FS uses a global value for all federated trusts. When you try to federate a second
domain in a scenario where a federated trust already exists, the request fails because the
URI is already being used.
Resolution
To resolve the issue, you must use the -supportmultipledomain switch to add or convert
every domain that's federated by the cloud service. This includes federated domains that
already exist.

Step 1: Install Update Rollup 1 for AD FS 2.0

On each node of the AD FS 2.0 Federation Service farm, download and install Update
Rollup 1 for AD FS 2.0. For more information about how to download and install Update
Rollup 1 for AD FS 2.0, see Description of Update Rollup 1 for Active Directory
Federation Services (AD FS) 2.0 .

７ Note

This update requires a restart of the computer. If you do not restart the computer,
you will experience the issue "Sorry, but we're having trouble signing you in" and
"8004789A" error when a federated user tries to sign in to Office 365, Azure, or
Intune .

Step 2: Check that the Update-MSOLFederatedDomain

command can be run successfully against the AD FS
environment
1. Select Start > All Programs > Windows Azure Active Directory, right-click
Windows Azure Active Directory Module for Windows PowerShell and select Run
As Administrator.

2. At the command prompt, run the following commands in the order in which they
are presented. Press Enter after each command.

PowerShell

Connect-MSOLService

７ Note

When you are prompted, enter your cloud service global administrator
credentials.
 PowerShell

Set-MSOLADFSContext -Computer <AD FS 2.0 server name>

７ Note

In this command, <AD FS 2.0 server name> is the computer name of a node
in the AD FS Federation Service farm.

PowerShell

Update-MSOLFederatedDomain -DomainName <Federated Domain Name>

７ Note

In this command, <Federated Domain Name> is the name of the domain

that's already federated with Azure AD for single sign-On (SSO).

3. If the Update-MSOLFederatedDomain command is successful and you do not receive

error messages, go to step 3 to remove the federated trust from the AD FS server.

Step 3: Update the federated trust on the AD FS server

２ Warning

The following steps should be planned carefully. Users for which SSO functionality
is enabled in the federated domain will be unable to authenticate between the
completion of steps C and D. If the Update-MSOLFederatedDomain command test in
step 2 was not completed successfully, step D of this procedure will not finish
correctly. Federated users will be unable to authenticate until the Update-
MSOLFederatedDomain command can be run successfully.

1. Log on to the console of the AD FS server, select Start > All Programs >
Administrative Tools, and then select AD FS (2.0) Management.

2. In the left navigation pane, select AD FS (2.0), select Trust Relationships, and then
select Relying Party Trusts.
 3. In the pane on the right side, delete the Microsoft Office 365 Identity Platform
entry.

4. Re-create the deleted trust object by using the -supportmultipledomain switch. In

the PowerShell window that's open from step 1C, run the following command, and
then press Enter:

PowerShell

Update-MSOLFederatedDomain -DomainName <Federated Domain Name> -

supportmultipledomain

７ Note

In this command, <Federated Domain Name> is the name of the domain that's
already federated with the cloud service for SSO.

Step 4: Use the -supportmultipledomain switch to add or

convert additional federated domains
After you update the existing trust in step 2, use the -supportmultipledomain switch to
add or convert additional federated domains. This switch informs the command to use a
unique URI namespace for each domain that's federated by the cloud service. To do this,
use one of the following command syntaxes:

PowerShell

New-MSOLFederatedDomain -domainname <domain name> -supportmultipledomain

PowerShell

Convert-MSOLDomainToFederated -domainname <domain name> -

supportmultipledomain

７ Note

In this command, <domain name> represents the name of the domain that you are
trying to federate.
Workaround
Implement an AD FS Federation Service farm to federate every cloud service domain for
which SSO features will be used. AD FS implementation guidance for Office 365 can be
found at the following article:

Step-by-step implementation guidance: Plan for and deploy Active Directory Federation
Services 2.0 for use with single sign-on

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Some users who are enabled for Azure
Multi-Factor Authentication aren't
prompted for a second verification
method
Article • 04/20/2022 • 2 minutes to read

This article describes a scenario in which users who are enabled for Azure Multi-Factor
Authentication aren't prompted for a second verification factor when they sign in.

Original product version:   Azure Active Directory, Cloud Services (Web roles/Worker
roles), Microsoft Intune

Original KB number:   3124671

Symptoms
When conditional access policies are set up so that Azure Multi-Factor Authentication is
expected to be enforced, some users aren't prompted to verify their identities through a
second verification method. This issue may occur in the following two scenarios.

Scenario 1: Multi-factor authentication is suspended on a remembered device:

In this scenario, an admin sets up trusted networks for multi-factor authentication and
enables the Allow users to suspend multi-factor authentication by causing a device to
be remembered option.

Scenario 2: The user is a member of the exception group:

In this scenario, the user is a member of an exception group for the app. When an
admin sets up multi-factor authentication access policies for an app, an admin can select
the Except box to set up groups as exceptions. Even though the settings in these
scenarios are configured, you expect users to be prompted for the second verification
method because of the conditional access policies that you applied.

Resolution
For Scenario 1:

1. Confirm that the Allow users to suspend multi-factor authentication option is

enabled.
 2. If the option is enabled, have the user try one or more of the following:

Delete browser cookies.

Use a different browser.
Use an InPrivate browsing session.

For Scenario 2:

Remove the user from the exception group.

Remove the group from the list of exception groups.

More information
For Scenario 1:

This option lets users who have successfully authenticated through multi-factor
authentication avoid future multi-factor authentication prompts for the next 1-60 days,
depending on the value that's configured in the Days before a device must re-
authenticate setting.

This is true even if the app is set to Require multi-factor authentication, Require multi-
factor authentication when not at work, or Block access when not at work, and the
user's device isn't on a trusted network.

For Scenario 2:

For users who are members of the exception group, the requirement for multi-factor
authentication on the user account is overridden.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Error when trying to reset password in
Azure, Office 365, or Intune: We did not
receive your response in time, or you
hung up the call
Article • 04/20/2022 • 2 minutes to read

This article describes a problem in which you receive an error message when you try to
reset your password in Microsoft Azure, Office 365, or Microsoft Intune.

Original product version:   Azure Active Directory, Microsoft Intune, Cloud Services (Web
roles/Worker roles)

Original KB number:   2951259

Symptoms
When you try to reset your password in Microsoft Azure, Microsoft Office 365, or
Microsoft Intune, you receive the following error message:

We did not receive your response in time, or you hung up the call.

Cause
This problem occurs because of any of the following:

You pressed the wrong button instead of the pound (#) button.
You hung up before hitting the pound (#) button.
You did not answer.
The telephone number that we have on file may be incorrect, and we were unable
to reach you.

You pressed the wrong button instead of the

pound (#) button
To resolve this problem, press the pound button after you answer the call.
You hung up before hitting the pound (#)
button
To resolve this problem, press the pound button after you answer the call.

You did not answer

Maybe you missed the call. To resolve this problem, you must answer the call.

The telephone that we have on file may be

incorrect, and we were not able to reach you
To resolve this problem, work with your administrator to update your telephone
number(s).

７ Note

If available, try to use another method such as using your mobile phone, office
telephone, or mobile app.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Error when you reset your password in
Azure, Office 365, or Intune: Your
request could not be processed
Article • 04/20/2022 • 2 minutes to read

This article describes a problem in which you receive a "Your request could not be
processed" message when you reset your password in Microsoft Azure, Office 365, or
Microsoft Intune. To resolve this problem, work with your administrator to update your
telephone number(s).

Original product version:   Azure Active Directory, Microsoft Intune, Cloud Services (Web
roles/Worker roles)

Original KB number:   2951268

Symptoms
When you try to reset your password in Microsoft Azure, Microsoft Office 365, or
Microsoft Intune, you receive the following error message:

There was an error processing your request. Please try resetting your password
again by clicking here.

If you are unable to reset your password after retrying, please contact Support for
assistance.

Cause
This problem occurs because the telephone number that we have on file may be
incorrect, and we were unable to reach you.

Resolution
To resolve this problem, work with your administrator to update your telephone
number(s).

７ Note

If available, try to use another method such as using your mobile phone, office
telephone, or mobile app.
Contact us for help
If you have questions or need help, create a support request , or ask Azure community
support.
Can't use Azure Multi-Factor
Authentication to sign in to cloud
services after you lose your phone or
the phone number changes
Article • 04/20/2022 • 2 minutes to read

Original product version:   Cloud Services (Web roles/Worker roles), Azure Active
Directory, Microsoft Intune, Azure Backup, Office 365 Identity Management

Original KB number:   2834954

Symptoms
Assume that you're a Microsoft cloud services admin who has Microsoft Azure Multi-
Factor Authentication enabled. If you lose your phone or your phone number has
changed, you can't sign in to your cloud services account (such as Office 365, Azure, or
Microsoft Intune) because you didn't receive the text message or voice call from the
Multi-Factor Authentication service.

Resolution
Ask another cloud services admin to reset your Multi-Factor Authentication settings. To
do this, the admin should follow these steps:

1. Sign in to the cloud service portal as an admin.

2. Go to
https://account.activedirectory.windowsazure.com/usermanagement/multifactorve
rification.aspx .
3. Select the check box for the admin account whose Multi-Factor Authentication
settings you want to reset.
4. Select Manage user settings.
5. Select the Require selected users to provide contact methods again check box,
and then select Save.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Error when Windows 10 devices settings
fail to sync: This user can't sign in
because this account is currently
disabled
Article • 04/27/2022 • 3 minutes to read

This article describes an issue in which error "Event ID 6065:80070533 This user can't
sign in because this account is currently disabled" is logged when Windows 10 settings
fail to sync.

Original product version:   Windows 10, version 1803, version 1709, version 1703, version
1511, version 1607, all editions

Original KB number:   3193791

Symptoms
You have enabled Enterprise State Roaming in the Azure Active Directory portal and on
some Windows 10 clients. Any supported settings for sync, such as the desktop
background or the task bar position, do not sync between devices for the same user.

Additionally, Event ID 6065 is logged in the Microsoft-Windows-SettingSync/Debug

event log:

Log Name: Microsoft-Windows-SettingSync/Debug

Source: Microsoft-Windows-SettingSync

Date: <date and time>

Event ID: 6065

Task Category: None

Level: Error

Keywords: User: <User SID>

Computer: WIN10DESKTOP

Description:
shell\roaming\cloudsync\cloudsyncengine\cloudsyncengine.cpp(990)\SettingSyncH
ost.exe!00007FF701A2A8C2: (caller: 00007FF701A2A3D9) ReturnHr[PreRelease](17)
tid(1060) 80070533 This user can't sign in because this account is currently disabled.
CallContext:[\AttemptSyncActivity]
Cause
The tenant has not been provisioned with the RMSBASIC subscription. This happens
automatically when Enterprise State Roaming is enabled in the Azure Active Directory
portal and is used to encrypt the synchronized data. If AllowAdHocSubscriptions is set to
False on the tenant, this configuration can prevent the tenant from being provisioned
with the RMSBASIC subscription.

Resolution

Verify RMSBASIC subscription is enabled on the tenant

1. Open PowerShell and sign in to Azure Active Directory using your Azure Active
Directory credentials. The first line will prompt you for your credentials. The second
line connects to Azure Active Directory.

PowerShell

$msolcred = get-credential connect-msolservice -credential $msolcred

2. Run the following cmdlet to see all the SKUs that the company owns.

PowerShell

Get-MsolAccountSku

3. If RMSBASIC is listed, as in the example output below, you do not need to proceed
with the rest of the steps in this article.

AccountSkuId ActiveUnits WarningUnits ConsumedUnits

--------------- ------------ --------------- -----------------

tenantname:ENTERPRISEPACK 25 0 14

tenantname:INTUNE_A 25 0 23

tenantname:AAD_PREMIUM 100 0 21

tenantname:RIGHTSMANAGEMENT_ADHOC 1000 0 18

tenantname: RMSBASIC 1000 0 18

 4. If RMSBASIC is not present, as in the example output below, proceed with the
steps in the next section.

AccountSkuId ActiveUnits WarningUnits ConsumedUnits

--------------- ------------ --------------- -----------------

tenantname:ENTERPRISEPACK 25 0 14

tenantname:INTUNE_A 25 0 23

tenantname:AAD_PREMIUM 100 0 21

tenantname:RIGHTSMANAGEMENT_ADHOC 1000 0 18

Verify AllowAdHocSubscriptions is set to "True" on the

tenant
The tenant cannot be provisioned with the RMSBASIC subscription if
AllowAdHocSubscriptions is set to False on the tenant. Use these steps to verify the
configuration of AllowAdHocSubscriptions and temporarily set it to True to obtain the
RMSBASIC subscription.

1. Open PowerShell and sign in to Azure Active Directory using your Azure Active
Directory credentials. The first line will prompt you for your credentials. The second
line connects to Azure Active Directory.

PowerShell

$msolcred = get-credential connect-msolservice -credential $msolcred

2. Run the following cmdlet to determine if your tenant has AllowAdHocSubscriptions

set to True or False.

PowerShell

Get-MsolCompanyInformation | fl AllowAdHocSubscriptions

3. If AllowAdHocSubscriptions is set to True, you do not need to proceed with rest of

the steps. If it is False, you can run the following command to enable
AllowAdHocSubscriptions . You can set it back to False in a later step.

PowerShell
 Set-MsolCompanySettings -AllowAdHocSubscriptions $true

4. In the Azure AD portal, disable and re-enable Enterprise State Roaming. See the
Verify USERS MAY SYNC SETTINGS AND ENTERPRISE APP DATA is enabled on
the tenant section.

5. Run the Get-MsolAccountSku cmdlet to see if the RMSBASIC subscription has been
added:

PowerShell

Get-MsolAccountSku

Verify USERS MAY SYNC SETTINGS AND ENTERPRISE APP

DATA is enabled on the tenant
After obtaining a Premium Azure AD subscription, follow these steps to enable
Enterprise State Roaming:

1. Sign in to the Azure classic portal.

2. On the left side, select ACTIVE DIRECTORY, and then select the directory for which
you want to enable Enterprise State Roaming.
3. Go to the CONFIGURE tab.
4. Scroll down the page, look for USERS MAY SYNC SETTINGS AND ENTERPRISE
APP DATA, and verify that ALL or SELECTED is selected.
5. If All or SELECTED is already selected, select None, save, and go back to the
previously selected ALL or SELECTED with the original SG option, and then save
again. For a reference with screenshots, see Enable Enterprise State Roaming in
Azure Active Directory.

(Optional) Set AllowAdHocSubscriptions to "False" on the

tenant
If you want to set AllowAdHocSubscriptions back to False, use this cmdlet after the
RMSBASIC subscription has been provisioned on the tenant:

PowerShell

Set-MsolCompanySettings -AllowAdHocSubscriptions $false

More information
Azure Active Directory PowerShell Module
Get-MsolAccountsku
Set-MsolCompanySettings
How administrators can control the accounts created for RMS for individuals
50,000 seats are assigned to the RIGHTSMANAGEMENT_ADHOC SKU in your Office
365 organization

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
A faulty split-brain DNS configuration
can prevent a seamless SSO sign-in
experience
Article • 04/20/2022 • 4 minutes to read

This article describes the conditions in which Active Directory Federation Services (AD
FS) doesn't behave as expected when you sign in to Office 365 services by using a single
sign-on (SSO)-enabled user ID.

Original product version:   Cloud Services (Web roles/Worker roles), Azure Active
Directory, Microsoft Intune, Azure Backup, Office 365 Identity Management

Original KB number:   2715326

Symptoms
When you sign in to a Microsoft cloud service such as Office 365, Microsoft Azure, or
Microsoft Intune by using a single sign-on (SSO) enabled user ID, the connection to
Active Directory Federation Services (AD FS) does not behave as expected. The
connection fails together with one of the following results:

Computers that sign in from inside the on-premises network connect to the AD FS
proxy IP address, and a forms-based authentication prompt appears. However, an
Integrated Windows Authentication experience is expected.
Computers that sign in from inside the on-premises network and then try to
connect to the AD FS proxy service are denied because of firewall settings.

Cause
These symptoms can be caused by a faulty split-brain DNS configuration that is required
for correct internal and external name resolution of DNS services. One of the following
causes is most likely:

The split-brain internal DNS resolution isn't set up for the domain in which the AD
FS service resides.
AD FS service name resolution isn't set in the split-brain internal DNS resolution of
the on-premises environment.

Resolution
To resolve this issue, follow these steps:

Step 1: Establish the split-brain DNS zone in internal DNS

To do this, follow these steps on the on-premises DNS server:

1. Open the DNS Management Console. To do this, open Administrative Tools, and
then double-click DNS.

2. In the left navigation pane, expand DNS, expand the server name, and then select
Forward Lookup Zones.

3. If there's no entry that's displayed for the DNS zone within which the AD FS service
endpoint is hosted, create the zone. To do this, right-click Forward Lookup Zones,
and then select New Zone.

4. Complete the wizard. When you do this, select Primary Zone, and then name the
zone for the DNS domain of the AD FS server.

２ Warning

Completing this step effectively stops on-premises computers from resolving

server names to public IP addresses by using the DNS server that resolves
public requests for the domain. Any extranet service endpoints that have to
be used by on-premises clients must have an A record created within the
split-brain DNS configuration to enable the connection.

Step 2: Advertise the AD FS service endpoint in the split-

brain DNS domain
In the DNS Management Console that you opened earlier, follow these steps:

1. Browse to and then select the DNS zone for the domain of the AD FS server.
2. Right-click the domain name, and then select New Host (A or AAAA).
3. Enter the following values:

Name: The AD FS service name

IP address: The on-premises private IP address of the AD FS Federation
Service farm.
Step 3: Clear the DNS cache on the server and client to
test the solution
1. In the DNS Management Console that you opened earlier, right-click the server
name, and then select Clear Cache.

2. On the client computer, select Start, select All Programs, select Accessories, right-
click Command Prompt, and then select Run As Administrator.

3. Type the following command, and then press Enter:

Console

Ipconfig /flushdns

Retest SSO sign-in to confirm that this resolves the issue.

More information
Split-brain DNS is a common configuration that's used to make sure that on-premises
client computers resolve a server name to internal IP addresses, even though public DNS
resolution resolves the same service name to a different public IP address. When you set
up AD FS for on-premises service, this configuration is needed to make sure that on-
premises client computers' authentication experience to the AD FS service is handled
differently (by the AD FS Federation Service farm) than external client computers that
are being serviced by the AD FS Proxy Service.

Without this configuration, all AD FS clients will be serviced by the same IP address
when they connect to the AD FS service, whether they are connected from the on-
premises network or are accessing remotely from an Internet location. This limits the
seamless authentication experience possible for on-premises, Active Directory-
authenticated clients, because the AD FS Proxy Service that is exposing the AD FS
service to the Internet does not expect the accessing client to be able to provide an
Integrated Windows Authentication response without a prompt (because remote
computers are not authentication to Active Directory).

To overcome this limitation, it's desirable to override the default name resolution that is
given to on-premises clients by creating an identically named domain in on-premises
DNS. Because the DNS distributed architecture returns the first response that is found to
a forward lookup query, this effectively masks the public DNS domain advertisements
for that domain for all on-premises client computer requests because their requests are
handled by on-premises DNS servers first.
Contact us for help
If you have questions or need help, create a support request , or ask Azure community
support.
A user is displayed as disabled or
enabled for Microsoft Azure Multi-
Factor Authentication but behaves as
the opposite
Article • 04/20/2022 • 2 minutes to read

Original product version:   Active Directory

Original KB number:   2934588

This article provides a solution to an issue in which a user is displayed as disabled or

enabled for Microsoft Azure Multi-Factor Authentication but behaves as the opposite.
This is an expected behavior.

Symptoms

Issue 1
When Microsoft Azure Multi-Factor Authentication is enabled, a user may be displayed
as disabled even though the user behaves as enabled.

Issue 2
When Microsoft Azure Multi-Factor Authentication is disabled, a user may be displayed
as enabled even though the user behaves as disabled

Cause
This problem occurs if the user is added in another directory as a guest user. Consider
the following example:

User John ( John@contoso.com ) is created in contoso.onmicrosoft.com . This is his home

directory. John is then added to a guest directory at fabrikam.onmicrosoft.com as a
guest user. When the administrator of fabrikam.onmicrosoft.com examines the guest
user, the user is displayed as disabled for Multi-Factor Authentication.

Resolution
This behavior is by design. Multi-Factor Authentication behavior is always based on the
user's home directory status. If you want to change the desired Multi-Factor
Authentication behavior, you or an administrator should make this change from the
user's home directory.

More information
Guest users are users from one directory who are added to another directory. For
example, a user from contoso.onmicrosoft.com may be added to
fabrikam.onmicrosoft.com . In this case, the user is still authenticated by using the

settings that are defined in the user's home directory ( contoso.onmicrosoft.com ).

７ Note

To quickly check whether a user is a guest user, notice whether the check box next
to the user on the Manage Multi-Factor Auth screen is dimmed. A dimmed check
box indicates that the user is a guest user.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Troubleshoot account lockout in AD FS
on Windows Server
Article • 04/20/2022 • 11 minutes to read

This article provides steps to troubleshoot an account lockout issue in Microsoft Active
Directory Federation Services (AD FS) on Windows Server.

Original product version:   Windows Server 2019, Windows Server 2016, Windows Server
2012 R2, Windows Server 2012

Original KB number:   4471013

You may experience an account lockout issue in AD FS on Windows Server. To

troubleshoot this issue, check the following points first:

If you have Azure Active Directory (Azure AD) Connect Health configured for AD FS
servers, go to the Use Connect Health to generate data for user login activities
section.
If you don't have Azure Active Directory (Azure AD) Connect Health configured for
AD FS servers, go to the Collect AD FS event logs from AD FS and Web Application
Proxy servers section.

Use Connect Health to generate data for user

login activities
You can use Connect Health to generate data about user login activity. Connect Health
produces reports about the top bad password attempts that are made on the AD FS
farm.

Refer to the information in this article to analyze the list of user accounts and IPs of the
bad password attempt. Then, go to Analyze the IP and username of the accounts that
are affected by bad password attempts.

Collect AD FS event logs from AD FS and Web

Application Proxy servers

Step 1: Collect AD FS event logs from AD FS and Web

Application Proxy servers
To collect event logs, you first must configure AD FS servers for auditing. If you have a
load balancer for your AD FS farm, you must enable auditing on each AD FS server in
the farm. Auditing does not have to be configured on the Web Application Proxy
servers.

To configure AD FS servers for auditing, you can use the following method:

Manually configure AD FS servers for auditing

Step 2: Search the AD FS logs

For Windows Server 2012 R2 or Windows Server 2016 AD FS, search all AD FS Servers'
security event logs for "Event ID 411 Source AD FS Auditing" events. Be aware of the
following information about "411 events":

You can download the ADFS Account Lockout and Bad Cred Search (AD
FSBadCredsSearch.ps1)PowerShell script to search your AD FS servers for "411"
events. The script provides a CSV file that contains the UserPrincipalName, IP
address of the submitter, and time of all bad credential submissions to your AD FS
farm. Open the CSV file in Excel, and quickly filter by user name, IP address, or
time.
These events contain the user principal name (UPN) of the targeted user.
These events contain a message "token validation failed" message that states
whether the event indicates a bad password attempt or an account lockout.
If the server has "411" events displayed but the IP address field isn't in the event,
make sure that you have the latest AD FS hotfix applied to your servers. For more
information, see MS16-020: Security update for Active Directory Federation
Services to address denial of service: February 9, 2016 .

For Windows Server 2008 R2 or Windows Server 2012 AD FS, you won't have the
necessary Event 411 details. Instead, download and run the following PowerShell script
to correlate security events 4625 (bad password attempts) and 501 (AD FS audit details)
to find the details about the affected users.

You can download the ADFS Security Audit Events Parser (ADFSSecAuditParse.ps1)
PowerShell script to search your AD FS servers for events. The script provides a CSV
file that contains the UserPrincipalName, IP address of the submitter, and time of
all bad credential submissions to your AD FS farm.
You can also use this method to investigate which connections are successful for
the users in the "411" events. You can search the AD FS "501" events for more
details.
 When you run the PowerShell script to search the events, pass the UPN of the user
who is identified in the "411" events, or search by account lockout reports.
The IP address of the malicious submitters is displayed in one of two fields in the
"501" events.
For web-based scenarios and most application authentication scenarios, the
malicious IP will be in the x-ms-client-ip field.

Analyze the IP and username of the accounts

that are affected by bad password attempts
After you enumerate the IP addresses and user names, identify the IPs that are for
unexpected locations of access.

Are the attempts made from external unknown IPs?

If the attempts are made from external unknown IPs, go to Update AD FS servers
with latest hotfixes.
If the attempts are not made from external unknown IPs, go to Make sure that
credentials are updated in the service or application.

Update AD FS servers with latest hotfixes

To make sure that AD FS servers have the latest functionality, apply the latest hotfixes
for the AD FS and Web Application Proxy servers. Additionally, hotfix 3134222 is
required on Windows Server 2012 R2 to log IP addresses in Event 411 that will be used
later.

Check whether the extranet lockout is enabled

Use Get-ADFSProperties to check whether the extranet lockout is enabled.

If the extranet lockout is enabled, go to Check extranet lockout and internal

lockout thresholds.
If the extranet lockout isn't enabled, start the steps below for the appropriate
version of AD FS.

Steps to check the lockout status

For Windows Server 2012 R2 or newer version

Smart lockout is a new feature that will be available soon in AD FS 2016 and 2012 R2
through an update. This section will be updated with the appropriate steps for enabling
smart lockout as soon as the feature is available. Then, go to Check extranet lockout and
internal lockout thresholds.

For Windows Server 2008 R2 Windows or older version

We recommend that you upgrade the AD FS servers to Windows Server 2012 R2 or

Windows Server 2016. For more information, see Upgrading to AD FS in Windows Server
2016. Then, follow the steps for Windows Server 2012 R2 or newer version.

Step 1: Check extranet lockout and internal lockout thresholds

Make sure that extranet lockout and internal lockout thresholds are configured correctly.
For more information, see Recommended security configurations. Generally, the
ExtranetLockoutThreshold should be less than the lockout threshold for AD so that user
gets locked out for extranet access only without also getting locked out in Active
Directory for internal access.

Step 2: Enable modern authentication and Certificate-based

authentication

We recommend that you enable modern authentication, certificate-based

authentication, and the other features that are listed in this step to lower the risk of
brute force attacks.

Deploy modern authentication

In addition to removing one of the attack vectors that are currently being used through
Exchange Online, deploying modern authentication for your Office client applications
enables your organization to benefit from multifactor authentication. Modern
authentication is supported by all the latest Office applications across the Windows, iOS,
and Android platforms.

For more information, see How to deploy modern authentication for Office 365 .

Because user name and password-based access requests will continue to be vulnerable
despite our proactive and reactive defenses, organizations should plan to adopt non-
password-based access methods as soon as possible.

The following non-password-based authentication types are available for AD FS and the
Web Application Proxy.
Certificate-based authentication

When certificate-based authentication is used as an alternative to user name and

password-based access, user accounts and access are protected in the following
manner:

Because users do not use their passwords over the Internet, those passwords
are less susceptible to disclosure. User name and password endpoints can be
blocked completely at the firewall. This removes the attack vector for lockout or
brute force attacks.

Even if user name and password endpoints are kept available at the firewall,
malicious user name and password-based requests that cause a lockout do not
affect access requests that use certificates. Therefore, the legitimate user's
access is preserved.

For more information about certificate-based authentication for Azure Active

Directory and Office 365, see this Azure Active Directory Identity Blog article .

Azure Multi-Factor Authentication (MFA)

Azure MFA is another non-password-based access method that you can use in the
same manner as certificate-based authentication to avoid using password and
user-name endpoints completely.

Azure MFA can be used to protect your accounts in the following scenarios.

Scenarios Advantage

Using Azure Adding Azure MFA or any additional authentication provider to AD FS

MFA as and requiring that the additional method be used for extranet requests
additional protects your accounts from access by using a stolen or brute-forced
authentication password. This can be done in AD FS 2012 R2 and 2016.
over the
extranet

Using Azure This is a new capability in AD FS 2016 to enable password-free access by

MFA as primary using Azure MFA instead of the password. This guards against both
authentication password breaches and lockouts.

For more information about how to configure Azure MFA by using AD FS, see
Configure AD FS 2016 and Azure MFA

Windows Hello for Business

 Windows Hello for Business is available in Windows 10. Windows Hello for
Business enables password-free access from the extranet, based on strong
cryptographic keys that are tied to both the user and the device.

Windows Hello for Business is supported by AD FS in Windows Server 2016. See

Authenticating identities without passwords through Windows Hello for Business.

Step 3: Disable legacy authentication and unused endpoints

Disable the legacy endpoints that are used by EAS clients through Exchange Online,
such as the following:

/adfs/services/trust/13/usernamemixed endpoint

７ Note

Doing this might disrupt some functionality. However, it can help reduce the
surface vectors that are available for attackers to exploit. Also, we recommend that
you disable unused endpoints.

Check whether the issue is resolved.

Make sure that credentials are updated in the

service or application
If the user account is used as a service account, the latest credentials might not be
updated for the service or application. In this situation, the service might keep trying to
authenticate by using the wrong credentials. This causes a lockout condition.

To resolve this issue, check the service account configuration in the service or
application to make sure that the credentials are correct. If not, follow the next step.

Clear cached credentials in the application

If user credentials are cached in one of the applications, repeated authentication
attempts can cause the account to become locked. To resolve this issue, clear the
cached credentials in the application. Check whether the issue is resolved.

ADFS Account Lockout and Bad Cred Search

PARAM ($PastDays = 1, $PastHours)
#************************************************

# ADFSBadCredsSearch.ps1

# Version 1.0

# Date: 6-20-2016

# Author: Tim Springston [MSFT]

# Description: This script will parse the ADFS server's (not proxy) security
ADFS

# for events which indicate an incorrectly entered username or password.

The script can specify a

# past period to search the log for and it defaults to the past 24 hours.
Results will be placed into a CSV for

# review of UPN, IP address of submitter, and timestamp.

#************************************************

cls

if ($PastHours -gt 0)

{$PastPeriod = (Get-Date).AddHours(-($PastHours))}

else

{$PastPeriod = (Get-Date).AddDays(-($PastDays)) }

$Outputfile = $Pwd.path + "\BadCredAttempts.csv"

$CS = get-wmiobject -class win32_computersystem

$Hostname = $CS.Name + '.' + $CS.Domain

$Instances = @{}

$OSVersion = gwmi win32_operatingsystem

[int]$BN = $OSVersion.Buildnumber

if ($BN -lt 9200){$ADFSLogName = "AD FS 2.0/Admin"}

else {$ADFSLogName = "AD FS/Admin"}

$Users = @()

$IPAddresses = @()

$Times = @()

$AllInstances = @()

Write-Host "Searching event log for bad credential events..."

if ($BN -ge 9200) {Get-Winevent -FilterHashTable @{LogName= "Security";

StartTime=$PastPeriod; ID=411} -ErrorAction SilentlyContinue | Where-Object
{$_.Message -match "The user name or password is incorrect"} | % {

$Instance = New-Object PSObject

$UPN = $_.Properties[2].Value

$UPN = $UPN.Split("-")[0]

$IPAddress = $_.Properties[4].Value

$Users += $UPN

$IPAddresses += $IPAddress

$Times += $_.TimeCreated

add-member -inputobject $Instance -membertype noteproperty -name

"UserPrincipalName" -value $UPN

add-member -inputobject $Instance -membertype noteproperty -name "IP

Address" -value $IPAddress

add-member -inputobject $Instance -membertype noteproperty -name "Time" -

value ($_.TimeCreated).ToString()
$AllInstances += $Instance

$Instance = $null

$AllInstances | select * | Export-Csv -Path $Outputfile -append -force -

NoTypeInformation

Write-Host "Data collection finished. The output file can be found at

$outputfile`."

$AllInstances = $null

ADFS Security Audit Events Parser

PARAM ($SearchCriteria, $PastDays = 1, $PastHours)

#************************************************

# ADFSSecAuditParse.ps1

# Version 1.0

# Date: 2-2-2016

# Author: Tim Springston [MSFT]

# Description: This script will parse an ADFS Security event log file (EVTX)

# and search for audit events related to a specific user or other criteria.

# The script will work for the each ADFS login instance for a given
criteria during a stated time frame.

# If you need to locate a second then filter and save the event log to
focus in.

# Return an array of initial instance IDs with the criteria, run the search
function against each and output

# a unique text file for each.

#************************************************

cls

if ($PastHours -gt 0)

$PastPeriod = (Get-Date).AddHours(-($PastHours))

else

{$PastPeriod = $PastDays}

$CS = get-wmiobject -class win32_computersystem

$Hostname = $CS.Name + '.' + $CS.Domain

$Instances = @()

Get-Winevent -ComputerName $Hostname -LogName Security | Where-Object

{(($_.ID -eq 501) `

-and ($_.Properties.Value -contains $SearchCriteria) -and ($_.TimeCreated -

gt $PastPeriod))} | % { $Instances += $_.Properties[0].Value}

function FindADFSAuditEvents {

param ($valuetomatch, $counter, $instance, $PastPeriod)

$Results = $pwd.Path + "\" + $SearchCriteria + "-ADFSSecAudit" + '-' +

$Counter + ".txt"

 $SearchString = $SearchCriteria + " and instance " + $Instance + " in

Security event log."

"Security Audit Events which match $SearchString" | Out-File $Results -

Encoding UTF8

Get-WinEvent -ComputerName $Hostname -LogName Security -WarningAction

SilentlyContinue | `

Where-Object -ErrorAction SilentlyContinue {($_.TimeCreated -gt

$PastPeriod) -and (($_.Properties -contains $ValueToMatch) -or
($_.Properties[0].Value -match $Instance))} | % {

$Event = New-object PSObject

add-member -inputobject $Event -membertype noteproperty -name "Event ID" -

value $_.ID

add-member -inputobject $Event -membertype noteproperty -name "Provider" -

value $_.ProviderName

add-member -inputobject $Event -membertype noteproperty -name "Machine

Name" -value $_.MachineName

add-member -inputobject $Event -membertype noteproperty -name "User ID" -

value $_.UserID

add-member -inputobject $Event -membertype noteproperty -name "Time

Created " -value $_.TimeCreated
$Event | FL *

$Event | Out-File $Results -Encoding UTF8 -Append

$_.Properties | FL *

$_.Properties | Out-File $Results -Encoding UTF8 -Append

$DateTimeExport = $_.TimeCreated

$DateTime = (($DateTimeExport.ToShortDateString()).Replace('/','-') + '@' +

(($DateTimeExport.ToShortTimeString()).Replace(' ','')))

$DateTime = $DateTime.Replace(':','')

$Results2 = $pwd.Path + "\" + $SearchCriteria + '-' + $DateTime + "-

ADFSSecAudit" + $Counter + ".txt"
Rename-Item -Path $Results -NewName $Results2

$Counter = 1

foreach ($instance in $Instances)

{

FindADFSAuditEvents -ValueToMatch $SearchCriteria -Instance $Instance -

PastPeriod $PastPeriod -Counter $Counter

$Counter++

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Troubleshoot Azure Multi-Factor
Authentication issues
Article • 04/20/2022 • 2 minutes to read

This article contains information to help you troubleshoot common issues that you may
encounter when you use Windows Multi-Factor Authentication for Microsoft Office 365
or Microsoft Azure.

Original product version:   Cloud Services (Web roles/Worker roles), Azure Active
Directory, Microsoft Intune, Azure Backup, Office 365 Identity Management

Original KB number:   2937344

Summary
Scenario Content

You don't receive a text or voice call that contains the verification code for Azure 2834956
Multi-Factor Authentication

"Sorry! We can't process your request" error when you try to set up security 2909939
verification settings for Azure Multi-Factor Authentication

Can't use Azure Multi-Factor Authentication to sign in to cloud services after you 2834954
lose your phone or the phone number changes

"We did not receive the expected response" error message when you try to sign in 2834968
by using Azure Multi-Factor Authentication

"Account verification system is having trouble" error message when you try to sign 2834966
in by using a work or school account

Can't sign in to an Office app by using a work or school account 2834958

2412085
You can't sign in to Office 365, Azure, or Intune

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Error when you run the Azure Active
Directory Sync tool Configuration
Wizard: The user name or password is
incorrect
Article • 04/20/2022 • 2 minutes to read

Original product version:   Cloud Services (Web roles/Worker roles), Azure Active
Directory, Microsoft Intune, Office 365 Identity Management

Original KB number:   2965539

Symptoms
When you run the Azure Active Directory Sync tool Configuration Wizard, you receive
the following error message:

The user name or password is incorrect.

Additionally, event ID 611 is logged to the Application log in Event Viewer:

Event ID: 611

Level: Information

Source: Directory Synchronization

Description:

Password synchronization failed for domain: ChildDomain.Contoso.Com . Details:

Microsoft.Online.PasswordSynchronization.SynchronizationManagerException:
Unable to open connection to domain: ChildDomain.Contoso.Com . Error: An
 exception occurred while attempting to locate a domain controller for domain
ChildDomain.Contoso.Com . --->
Microsoft.Online.PasswordSynchronization.DirectoryReplicationServices.DrsCommun
icationException: An exception occurred while attempting to locate a domain
controller for domain ChildDomain.Contoso.Com . --->
System.Security.Authentication.AuthenticationException: The user name or password
is incorrect.

---> System.Runtime.InteropServices.COMException: The user name or password is

incorrect.

Cause
This problem occurs if the enterprise admin account credentials that are specified in the
wizard are not unique in the Active Directory forest. Password mismatches between two
or more identically named accounts in multi-domain forests can cause the wizard to fail.

Consider the following example scenario:

Contoso\admin is the enterprise admin account that's specified in the Azure Active
Directory Sync tool Configuration Wizard.
Contoso\admin and Fabrikam\admin are two accounts that have the same name
but that exist in different domains.
Each account has a different password.

In this scenario, the password of Contoso\admin is used for all domains in the Active
Directory forest during the configuration process. For example, if the password is
"Password1," "Password1" is used for Fabrikam\admin. This causes the wizard to fail.

Resolution
To resolve this problem, do one of the following:

Create an enterprise admin account in which the value of the sAMAccountName

attribute is unique and does not exist in each domain.
Update the passwords of all accounts that have identical names so that the
password is the same for all those accounts.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Error when you try to reset your
password in Azure, Office 365, or
Intune: Oops! We encountered an
unexpected error while contacting you
Article • 04/20/2022 • 2 minutes to read

This article describes an issue in which you receive an error message when you try to
reset your password in Microsoft Azure, Office 365, or Microsoft Intune. To resolve this
problem, work with your administrator to update your telephone number(s).

Original product version:   Azure Active Directory, Microsoft Intune, Cloud Services (Web
roles/Worker roles)

Original KB number:   2951260

Symptoms
When you try to reset your password in Microsoft Azure, Microsoft Office 365, or
Microsoft Intune, you receive the following error message:

Oops! We encountered an unexpected error while contacting you.

Cause
This issue occurs because the telephone number that we have on file may be incorrect,
and we were unable to reach you.

Resolution
To resolve this problem, work with your administrator to update your telephone
number(s).

７ Note

If available, try to use another method such as using your mobile phone, office
telephone, or mobile app.
Contact us for help
If you have questions or need help, create a support request , or ask Azure community
support.
Error when trying to reset password in
Azure, Office 365, or Intune: We could
not verify your account
Article • 04/20/2022 • 2 minutes to read

Original product version:   Cloud Services (Web roles/Worker roles), Azure Active
Directory, Microsoft Intune, Azure Backup, Office 365 Identity Management

Original KB number:   2951274

Symptoms
When a new user tries to reset password in Microsoft Azure, Microsoft Office 365, or
Microsoft Intune, the user receives the following error message:

Reset your password

We could not verify your account

If you'd like, we can contact an administrator in your organization to reset your

password for you..

Resolution
Assign a Microsoft Azure Active Directory Premium license to the user. Users must have
an Azure Active Directory Premium license to be able to reset their own password.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
You don't receive a text or voice call that
contains the verification code for Azure
AD Multi-Factor Authentication
Article • 04/20/2022 • 2 minutes to read

Original product version:   Cloud Services (Web roles/Worker roles), Azure Active
Directory, Microsoft Intune, Azure Backup, Office 365 Identity Management

Original KB number:   2834956

Symptoms
Consider the following scenario:

You're a global admin who has Microsoft Azure AD Multi-Factor Authentication

(MFA) enabled
You don't receive the text message or voice call that contains your verification
code.

In this scenario, you can't sign in to your work or school account, such as Office 365,
Azure, or Microsoft Intune.

Resolution
To fix this problem, follow these steps:

1. If you have set up other options for security verification, select Other verification
options, and then try again by selecting a different option. Also, make sure that
your phone numbers are correct in your user account settings.
2. Ask another global admin to confirm whether your phone numbers are set
correctly in your user settings.

If steps 1 and 2 don't resolve the problem, your user account may be blocked from
using Azure AD MFA. To check whether your user account is blocked, ask a global admin
for your Microsoft cloud service to perform the following steps:

If you have an Azure AD MFA or Azure Active Directory Premium subscription

1. Go to the Azure portal , and then open Azure Active Directory.

2. If you want to change the default active directory, click Manage tenants, choose
the active directory, and then click Switch.
 3. Choose Users, open the profile of the user that has the problem.
4. Check whether the Block sign in is enabled. If yes, disable the option.

If you have Office 365 and don't have an Azure AD MFA or Azure Active Directory
Premium subscription, contact Office 365 Support.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
General password writeback
troubleshooting steps
Article • 04/20/2022 • 4 minutes to read

This article describes general troubleshooting steps to resolve password writeback

issues. These steps are a good way to start the process if you have to consult other
content that explains more specific issues.

Focus on the exact failure scenario

You should be consistent about how the password issue is reproduced or tested.
Understand exactly what the failure scenario is, and learn the repro steps. Because a
password reset and a password change are two different operations, focus on one
operation, and use the same steps for that operation to reproduce the issue. The
difference between the operations is as follows.

Operation Characteristics

Password The user or administrator doesn't know or doesn't provide the current password.
reset

Password Only a user can initiate a password change. Users have to enter their current
change password before they can specify a new password.

Contrast working versus nonworking users

Does the operation fail for one user but succeed for another user? In this situation, try to
determine the differences between a working and nonworking user. You can use the
following steps:

1. Get information about certain Active Directory users by running the Ldifde
command or the Get-ADUser PowerShell cmdlet.

2. Run user commands in Azure Active Directory (Azure AD) PowerShell to get
information about those users in Azure AD.

3. Compare the Active Directory and Azure AD information about those two users
offline, especially in terms of:

Administrator roles and groups

Organizational unit placement
 The last time that the object and password were synced
Other differences

Keep this information handy while you're troubleshooting an issue.

Use the same domain controller

Try to use the same domain controller every time that you test or make changes. To
control which domain controller is getting contacted for password writeback operations,
set a single preferred domain controller in the Active Directory Connector, and then
restart the ADSync service. Change the preferred domain controller to the nearest one,
or use the domain controller that owns the primary domain controller (PDC) emulator
role.

To set the preferred domain controller, follow these steps:

1. Open the Synchronization Service Manager. To do this, select Start, enter azure ad,
select the Azure AD Connect group, and then select Synchronization Service.

2. Select the Connectors tab, and then select the applicable Active Directory
connector. In the Actions pane, select Properties to open the Properties dialog
box.

3. In the Connector Designer pane, select Configure Directory Partitions. In the

Configure Directory Partitions pane, select a directory partition from the list.

4. In the Domain controller connection settings group, select the Only use preferred
domain controllers checkbox. Then, select Configure.

5. Make the appropriate changes in the Configure Preferred DCs dialog box.

Depending on the issue, it might actually help to try different domain controllers,
instead. Then, you can determine whether the issue can be isolated to a specific domain
controller or occurs on any domain controller.

In addition, when you use the Active Directory Users and Computers snap-in, change
the connected domain controller to the same one that you used for Azure AD Connect.
Follow these steps:

1. Open the Active Directory Users and Computers snap-in. To do this, select Start,
search on dsa.msc, and then press Enter.

2. In the navigation pane, right-click the domain name, and then select the Change
Domain Controller menu item.
 3. In the Change Directory Server dialog box, select the This Domain Controller or
AD LDS instance option.

4. In the list of domain controllers, select the domain controller that matches the one
that you selected for Azure AD Connect, and then select OK.

Temporarily relax the local Active Directory

password policy
To troubleshoot password writeback operations, we recommend that you temporarily
modify the local Active Directory password policy. Set the minimum password age to
zero to allow users to change their password more than one time consecutively. If
password complexity is required, use a combination of uppercase letters, lowercase
letters, and numerals. Because password history is usually enforced to a default of 24
remembered passwords, always use another password in every reset or change attempt.
For example, increment an integer suffix (1, 2, 3, and so on) for every reset or change.

Check application events by using the Event

Viewer
These troubleshooting articles for specific password writeback issues contain many
examples of application events that provide details about the issues. These examples
show that the Event Viewer snap-in (Eventvwr.msc) is the most effective Windows tool to
troubleshoot password writeback.

Identify the exact account name for the AD DS

Connector
Recheck the name of the current account for the Active Directory Domain Connector.
Make sure that this account has the same name as the account that the Azure AD
Connect server uses. To find this account name, see Identify the AD DS Connector
account.

Learn which writeback operations are

supported or unsupported
To review the lists of supported and unsupported password writeback operations, see
How does self-service password reset writeback work in Azure Active Directory?.
Contact us for help
If you have questions or need help, create a support request , or ask Azure community
support.
Troubleshoot password writeback access
rights and permissions
Article • 06/04/2022 • 13 minutes to read

This article describes the access rights and permissions that are required in the domain
root, the user object, and the Builtin container in Active Directory. It also discusses the
following items:

Required domain group policies

How to identify the Active Directory Domain Services (AD DS) Connector account
that Microsoft Azure AD Connect uses
How to check existing permissions on that account
How to avoid replication issues

This information can help you troubleshoot specific problems that involve password
writeback.

Identify the AD DS Connector account

Before you check for password writeback permissions, verify the current AD DS
Connector account (also known as the MSOL_ account) in Azure AD Connect. Verifying
this account helps you avoid taking the wrong steps during password writeback
troubleshooting.

To identify the AD DS Connector account:

1. Open the Synchronization Service Manager. To do this, select Start, enter azure ad
connect, select Azure AD Connect in the search results, and then select
Synchronization Service.

2. Select the Connectors tab, and then select the applicable Active Directory
connector. In the Actions pane, select Properties to open the Properties dialog
box.

3. In the left pane of the Properties window, select Connect to Active Directory
Forest, and then copy the account name that appears as User name.

Check existing permissions of the AD DS

Connector account
To set the correct Active Directory permissions for password writeback, use the built-in
ADSyncConfig PowerShell module. The ADSyncConfig module includes a method to set
permissions for password writeback by using the Set-
ADSyncPasswordWritebackPermissions cmdlet.

To check whether the AD DS Connector account (that is, the MSOL_ account) has the
correct permissions for a specific user, use one of the following tools:

Active Directory Users and Computers snap-in on the Microsoft Management

Console (MMC)
Command prompt
PowerShell

Active Directory Users and Computers snap-in

Use the MMC snap-in for Active Directory Users and Computers. Follow these steps:

1. Select Start, enter dsa.msc, and then select the Active Directory Users and
Computers snap-in in the search results.

2. Select View > Advanced Features.

3. In the console tree, find and select the user account that you want to check the
permissions for. Then, select the Properties icon.

4. In the Properties dialog box for the account, select the Security tab, and then
select the Advanced button.

5. In the Advanced Security Settings dialog box for the account, select the Effective
Permissions tab. Then, in the Group or user name section, select the Select
button.

6. In the Select User, Computer, or Group dialog box, select Advanced > Find Now
to show the selection list. In the Search results box, select the MSOL_ account
name.

7. Select OK two times to return to the Effective Permissions tab in the Advanced
Security Settings dialog box. Now, you can view the list of effective permissions
for the MSOL_ account that are assigned to the user account. The list of the default
permissions that are required for password writeback is shown in the Required
permissions on the user object section in this article.

Command prompt
Use the dsacls command to display the access control lists (ACLs, or permissions) of the
AD DS Connector account. The following command stores the command output in a
text file, although you can modify it to display the output on the console:

cmd

dsacls "CN=User01,OU=Sync,DC=Contoso,DC=com" > dsaclsDomainContoso.txt

You can use this method to analyze the permissions for any Active Directory object.
However, it isn't useful to compare permissions between objects because the text
output isn't sorted.

PowerShell
Use the Get-Acl cmdlet to get the AD DS Connector account permissions, and then store
the output as an XML file by using the Export-Clixml cmdlet, as follows:

PowerShell

Set-Location AD:

Get-Acl "DC=Contoso,DC=com" | Export-Clixml aclDomainContoso.xml

The PowerShell method is useful for offline analysis. It lets you import the file by using
the Import-Clixml cmdlet. It also keeps the original structure of the ACL and its
properties. You can use this method to analyze the permissions for any Active Directory
object.

Avoid replication issues when fixing

permissions
When you fix Active Directory permissions, the changes to Active Directory might not
take effect immediately. Active Directory permissions are also subject to replications
across the forest in the same manner that Active Directory objects are. How do you
mitigate the Active Directory replication issues or delays? You set a preferred domain
controller in Azure AD Connect, and work on only that domain controller for any
changes. When you use the Active Directory Users and Computers snap-in, right-click
the domain root in the console tree, select the Change Domain Controller menu item,
and then pick the same preferred domain controller.

For a quick sanity check within Active Directory, run domain controller diagnostics by
using the dcdiag command. Then, run the repadmin /replsummary command to view a
summary of replication problems. The following commands store the command output
to text files, although you can modify them to display the output on the console:

cmd

dcdiag > dcdiag.txt

repadmin /replsum > replsum.txt

Required permissions on the Active Directory

domain root
This section describes the expected Active Directory permissions for password writeback
on the Active Directory domain root. Don't confuse this root with the root of the Active
Directory forest. A forest can have multiple Active Directory domains. Each domain must
have the correct permissions set in its own root, so that password writeback can work
for users in that domain.

You can view the existing Active Directory permissions in the security properties of the
domain root. Follow these steps:

1. Open the Active Directory Users and Computers snap-in.

2. In the console tree, locate and select the Active Directory domain root, and then
select the Properties icon.

3. In the Properties dialog box for the account, select the Security tab.

Each of the following subsections contains a table of domain root default permissions.
This table shows the required permission entries for the group or user name that's in the
subsection title. To view and modify the current permission entries to match the
requirements for each group or user name, follow these steps for each subsection:

1. On the Security tab, select the Advanced button to view the Advanced Security
Settings dialog box. The Permissions tab shows the current list of domain root
permissions for each Active Directory identity (Principal).

2. Compare the current permissions list against the list of default permissions for
each Active Directory identity (Principal).

3. If necessary, select Add to add required permission entries that are missing from
the current list. Or, select a permission entry, and then select Edit to modify that
entry to meet the requirement. Repeat this step until the current permission entries
match the subsection table.
 4. Select OK to accept the changes in the Advanced Security Settings dialog box and
return to the Properties dialog box.

７ Note

The permissions on the Active Directory domain root aren't inherited from any
parent container.

Root default permissions for the AD DS Connector

account (Allow)

Permission Apply to

Reset password Descendant User objects

(blank) Descendant msDS-Device objects

Replicating Directory Changes This object only

Replicating Directory Changes All This object only

Read all properties Descendant publicFolder objects

Read/write all properties Descendant InetOrgPerson objects

Read/write all properties Descendant Group objects

Read/write all properties Descendant User objects

Read/write all properties Descendant Contact objects

Root default permissions for Authenticated Users (Allow)

Permission Apply to

Enable per user reversibly encrypted password This object only

Unexpire password This object only

Update password not required bit This object only

Special This object only

(blank) This object and all descendant objects

Root default permissions for Everyone (Deny + Allow)

Type Permission Apply to

Deny Delete all child objects This object only

Allow Read all properties This object only

Root default permissions for Pre-Windows 2000

Compatible Access (Allow)

Permission Apply to

Special Descendant InetOrgPerson objects

Special Descendant Group objects

Special Descendant User objects

Special This object only

List contents This object and all descendant objects

Root default permissions for SELF (Allow)

Permission Apply to

(blank) This object and all descendant objects

Special All descendant objects

Validated write to computer attributes Descendant Computer objects

(blank) Descendant Computer objects

Required permissions on the user object

This section describes the expected Active Directory permissions for password writeback
on the target user object that has to update the password. To view the existing security
permissions, follow these steps to show the security properties of the user object:

1. Return to the Active Directory Users and Computers snap-in.

2. Use the console tree or the Action > Find menu item to select the target user
object, and then select the Properties icon.
 3. In the Properties dialog box for the account, select the Security tab.

Each of the following subsections contains a table of user default permissions. This table
shows the required permission entries for the group or user name that's in the
subsection title. To view and modify the current permission entries to match the
requirements for each group or user name, follow these steps for each subsection:

1. On the Security tab, select the Advanced button to view the Advanced Security
Settings dialog box.

2. Make sure that the Disable Inheritance button is displayed near the bottom of the
dialog box. If the Enable Inheritance button is displayed instead, select that
button. The enable inheritance feature allows all the permissions from parent
containers and organizational units to be inherited by this object. This change
resolves the issue.

3. On the Permissions tab, compare the current permissions list against the list of
default permissions for each Active Directory identity (Principal). The Permissions
tab displays the current list of user permissions for each Active Directory identity
(Principal).

4. If necessary, select Add to add required permission entries that are missing from
the current list. Or, select a permission entry, and then select Edit to modify that
entry to meet the requirement. Repeat this step until the current permission entries
match the subsection table.

5. Select OK to accept the changes in Advanced Security Settings dialog box and
return to the Properties dialog box.

７ Note

Unlike for the Active Directory domain root, the required permissions for the user
object are usually inherited from the domain root, or from a parent container or
organizational unit. Permissions that were set directly on the object will indicate an
inheritance from None. The inheritance of the access control entry (ACE) isn't
important as long as the values in the Type, Principal, Access, and Applies to
columns for the permission are the same. However, certain permissions can be set
only in the domain root. These entities are listed in the subsection tables.

User default permissions for the AD DS Connector

account (Allow)
 Permission Inherited from Apply to

Reset password <domain root> Descendant User objects

(blank) <domain root> Descendant msDS-Device objects

Read all properties <domain root> Descendant publicFolder objects

Read/write all properties <domain root> Descendant InetOrgPerson objects

Read/write all properties <domain root> Descendant Group objects

Read/write all properties <domain root> Descendant User objects

Read/write all properties <domain root> Descendant Contact objects

User default permissions for Authenticated Users (Allow)

Permission Inherited from Apply to

Read general information None This object only

Read public information None This object only

Read personal information None This object only

Read web information None This object only

Read permissions None This object only

Read Exchange information <domain root> This object and all descendant objects

User default permissions for Everyone (Allow)

Permission Inherited from Apply to

Change password None This object only

User default permissions for Pre-Windows 2000

Compatible Access (Allow)
The Special permissions in this table include List contents, Read all properties, and
Read permissions rights.

Permission Inherited from Apply to

 Permission Inherited from Apply to

Special <domain root> Descendant InetOrgPerson objects

Special <domain root> Descendant Group objects

Special <domain root> Descendant User objects

List contents <domain root> This object and all descendant objects

User default permissions for SELF (Allow)

The Special permissions in this table include Read/Write private information rights
only.

Permission Inherited from Apply to

Change password None This object only

Send as None This object only

Receive as None This object only

Read/write personal information None This object only

Read/write phone and mail options None This object only

Read/write web information None This object only

Special None This object only

Validated write to computer attributes <domain root> Descendant Computer objects

(blank) <domain root> Descendant Computer objects

(blank) <domain root> This object and all descendant objects

Special <domain root> This object and all descendant objects

Required permissions on the SAM server object

This section describes the expected Active Directory permissions for password writeback
on the Security Account Manager (SAM) server object
(CN=Server,CN=System,DC=Contoso,DC=com). To find the security properties of the
SAM server object (samServer), follow these steps:

1. Return to the Active Directory Users and Computers snap-in.

 2. In the console tree, locate and select the System container.

3. Locate and select Server (the samServer object), and then select the Properties
icon.

4. In the Properties dialog box for the object, select the Security tab.

5. Select the Advanced Security Settings dialog box. The Permissions tab displays
the current list of samServer object permissions for each Active Directory identity
(Principal).

6. Verify that at least one of the following principals is listed in the access control
entry for the samServer object. If only Pre-Windows 2000 Compatible Access is
listed, make sure that Authenticated Users is a member of this built-in group.

Permissions for Pre-Windows 2000 Compatible Access

(Allow)
Special permissions must include the List contents, Read all properties, and Read
permissions rights.

Permissions for Authenticated Users (Allow)

Special permissions must include the List contents, Read all properties, and Read
permissions rights.

Required permissions on the Builtin container

This section describes the expected Active Directory permissions for password writeback
on the Builtin container. To view the existing security permissions, follow these steps to
get to the security properties of the built-in object:

1. Open to the Active Directory Users and Computers snap-in.

2. In the console tree, locate and select the Builtin container, and then select the
Properties icon.

3. In the Properties dialog box for the account, select the Security tab.

4. Select the Advanced button to view the Advanced Security Settings dialog box.
The Permissions tab displays the current list of Builtin container permissions for
each Active Directory identity (Principal).
 5. Compare this current permissions list against the list of required allow permissions
for the MSOL_ account, as follows.

Permission Inherited from Apply to

Read/write all properties <domain root> Descendant InetOrgPerson objects

Read/write all properties <domain root> Descendant Group objects

Read/write all properties <domain root> Descendant User objects

Read/write all properties <domain root> Descendant Contact objects

6. If necessary, select Add to add required permission entries that are missing from
the current list. Or, select a permission entry, and then select Edit to modify that
entry to meet the requirement. Repeat this step until the current permission entries
match the subsection table.

7. Select OK to exit the Advanced Security Settings dialog box and return to the
Properties dialog box.

Other required Active Directory permissions

In the Pre-Windows 2000 Compatible Access group properties, go to the Members tab,
and make sure that Authenticated Users is a member of this group. Otherwise, you
might experience issues that affect password writeback on Azure AD Connect and Active
Directory (especially on older versions).

Required domain group policies

To make sure that you have the correct domain group policies, follow these steps:

1. Select Start, enter secpol.msc, and then select Local Security Policy in the search
results.

2. In the console tree, under Security Settings, expand Local Policies, and then select
User Rights Assignment.

3. In the list of policies, select Impersonate a client after authentication, and then
select the Properties icon.

4. In the Properties dialog box, make sure that the following groups are listed on the
Local Security Setting tab:
 Administrators
LOCAL SERVICE
NETWORK SERVICE
SERVICE

For more information, see the default values for the Impersonate a client after
authentication policy.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Troubleshoot error code 8023062C:
Insecure password reset or change
Article • 04/20/2022 • 2 minutes to read

This article describes how to troubleshoot a password writeback error that occurs when
Azure AD Connect tries to make a password change or reset in an insecure
configuration. This situation occurs specifically when Azure AD Connect tries to do a
password change or reset without having a 128-bit Transport Layer Security (TLS) or
Secure Sockets Layer (SSL) connection.

Symptoms
When a user or administrator tries to change or reset a password in Azure AD, password
writeback to the on-premises directory fails and returns an "8023062C (0x8023062c)"
error code and the following error message:

The password could not be set because the server is not configured for insecure
setting of passwords, or a 128 bit TLS or SSL connection is required.

Cause
Microsoft Azure AD Connect has been configured not to require that Lightweight
Directory Access Protocol (LDAP) traffic be signed and encrypted.

Solution
Make sure that the Sign and Encrypt LDAP Traffic setting is enabled in three places
within Synchronization Service Manager by following these steps:

1. Open the Synchronization Service Manager. To do this, open the Start menu, go to
the Azure AD Connect group, and then select Synchronization Service.

2. Select the Connectors tab, and then select the applicable Active Directory
connector. In the Actions pane, select Properties.

3. On the left side of the Properties dialog box, select Connect to Active Directory
Forest, and then select the Options button. In the Connection Options dialog box,
turn on Sign and Encrypt LDAP Traffic, and then select OK.
 4. On the left side of the Properties dialog box, select Configure Directory Partitions.
Then, in the Configure Directory Partitions pane, select a directory partition from
the list.

5. In the Domain controller connection settings group, select the Options button. In
the Connection Options dialog box, turn on Sign and Encrypt LDAP Traffic, and
then select OK.

6. In the Credentials group, check whether the Alternate credentials for this
directory partition option is selected. If that option isn't selected, go to step 8.
Otherwise, select the Set Credentials button, and then select Options in the
Credentials dialog box.

7. In the Connection Options dialog box, turn on Sign and Encrypt LDAP Traffic, and
then select OK two times to return to the Properties dialog box.

8. Select OK to save the changes and return to Synchronization Service Manager.

9. Select Start, enter services.msc, and then select the Services snap-in. Select
Microsoft Azure AD Sync from the list of services, and then select the Restart
Service icon.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Troubleshoot error SSPR_009:
Synchronized Azure AD Administrator
can't reset password from the cloud
Article • 04/20/2022 • 2 minutes to read

This article explains how to troubleshoot a password reset error that occurs when a
synchronized user who has an Azure Active Directory (Azure AD) Administrator role tries
unsuccessfully to reset their password.

This scenario occurs after the user visits the sign-in page at
https://login.microsoftonline.com and selects Can't access your account?, Forgot my
password, or reset it now. Then, the browser redirects the user to the self-service
password reset (SSPR) page at https://passwordreset.microsoftonline.com to start the
SSPR process. This process requires that the user enter a "captcha" code. If the
operation is successful, password writeback sends a password reset request for the user
to an on-premises Active Directory domain. Simultaneously, SSPR sets the new
password in Azure AD. If the operation is unsuccessful, an "SSPR_009" error is returned
instead. If the error occurs, use this article to fix the problem.

Symptoms
After a synchronized user tries unsuccessfully to reset a password by entering a captcha
code, the browser displays the following error message:

You can't reset your own password because password reset isn't turned on for your
organization.

SSPR_009: Your organization hasn't turned on password reset. If you're an

administrator, you can get more information from the "How to enable password
reset" article. If you're not an administrator, you can provide this information when
you contact your administrator.

７ Note

This scenario occurs only for Azure AD users who have an Azure AD Administrator
role assigned to them. The password change or reset flow works as expected for
standard accounts.
Cause
SSPR for Administrators isn't enabled on the tenant. SSPR for Administrators (SSPR-A)
was the first implementation of SSPR. After SSPR for Users (SSPR-U) was introduced,
users could have two separate configurations.

The old SSPR-A implementation is used when an Azure AD account has an admin role,
such as Global Administrator or Billing Administrator. However, the SSPR management
on the Azure portal is for SSPR-U only. Therefore, SSPR-A might not be enabled on the
tenant.

Solution
Enable SSPR-A on the tenant by running the Set-MsolCompanySettings PowerShell
cmdlet, as follows:

PowerShell

Set-MsolCompanySettings -SelfServePasswordResetEnabled $true

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Troubleshoot error SSPR_0029: Your
organization hasn't properly set up the
on-premises configuration for password
reset
Article • 08/19/2022 • 7 minutes to read

This article helps you troubleshoot the self-service password reset (SSPR) error
"SSPR_0029: Your organization hasn't properly set up the on-premises configuration for
password reset" that occurs after the user or admin enters and confirms a new password
on the SSPR page.

Symptoms
A user or administrator takes the following steps, and then receives an SSPR_0029 error:

1. At a Microsoft account sign-in page or Microsoft Azure sign-in page in the

https://login.microsoftonline.com domain, a user or admin selects Can't access
your account?, Forgot my password, or reset it now.

2. The user or admin selects the Work or school account account type. Then, they're
redirected to the SSPR page at https://passwordreset.microsoftonline.com to
start the Get back into your account flow.

3. On the Who are you? screen, the user or admin enters their user ID, completes a
case-insensitive captcha security challenge, and then selects Next.

4. On the Why are you having trouble signing in? screen, the user or admin selects I
forgot my password > Next.

5. On the choose a new password screen, the user or admin enters and confirms a
new password string, and then selects Finish. Then, a We're sorry screen appears
and presents the following message:

SSPR_0029: Your organization hasn't properly set up the on-premises

configuration for password reset.

If you're an administrator, you can get more information from the

Troubleshoot password writeback article. If you're not an administrator, you
can provide this information when you contact your administrator.
Cause 1: Can't use password writeback to reset
the password of a synchronized Windows
Active Directory administrator
You're a synchronized Windows Active Directory admin who belongs (or used to belong)
to an on-premises Active Directory protected group, and you can't use SSPR and
password writeback to reset your on-premises password.

Solution: None (behavior is by design)

For security, administrator accounts that exist within a local Active Directory protected
group can't be used together with password writeback. Administrators can change their
password in the cloud, but can't reset a forgotten password. For more information, see
How does self-service password reset writeback work in Azure Active Directory.

Cause 2: AD DS Connector account doesn't

have the right Active Directory permissions
The synchronized user is missing the correct permissions in Active Directory.

Solution: Resolve Active Directory permission issues

To resolve issues that affect Active Directory permissions, see Password Writeback access
rights and permissions.

Workaround: Target a different Active Directory domain

controller

７ Note

Password writeback has a dependency on the legacy API NetUserGetInfo. The

NetUserGetInfo API requires a complex set of allowed permissions in Active

Directory that can be difficult to identify, especially when an Azure AD Connect

server is running on a domain controller. For more information, see Applications
using NetUserGetInfo and similar APIs rely on read access to certain Active
Directory objects.
Do you have a scenario in which an Azure AD Connect server is running on a domain
controller, and it isn't possible to resolve Active Directory permissions? In this case, we
recommend that you deploy Azure AD Connect server on a member server instead of a
domain controller. Or, configure your Active Directory connector to Only use preferred
domain controllers by using the following steps:

1. On the Start menu, search for and select Synchronization Service Manager.

2. In the Synchronization Service Manager window, select the Connectors tab.

3. Right-click the Active Directory connector from the list of connectors, and then
select Properties.

4. In the Connector Designer pane of the Properties dialog box, select Configure
Directory Partitions.

5. In the Configure Directory Partitions pane, select the Only use preferred domain
controllers option, and then select Configure.

6. In the Configure Preferred DCs dialog box, add one or more server names that
point to a different domain controller (or domain controllers) than the local host.

7. To save your changes and return to the main window, select OK three times,
including in the Warning dialog box that shows an advanced configuration
disclaimer.

Cause 3: Servers aren't allowed to make remote

calls to Security Accounts Manager (SAM)
In this case, two similar application error events are logged: Event ID 33004 and 6329.
Event ID 6329 differs from 33004 because it contains an ERROR_ACCESS_DENIED error code
in the stack trace when the server tries to make a remote call to SAM:

ERR_: MMS(####): admaexport.cpp(2944): Failed to acquire user information:

Contoso\MSOL_############. Error Code: ERROR_ACCESS_DENIED

This situation can occur if the Azure AD Connect server or the domain controller has or
had a hardening security setting applied with a Domain Group Policy Object (GPO) or in
the Local Security Policy of the server. To check whether this is the case, follow these
steps:

1. Open an administrative Command Prompt window, and run the following

commands:
 Console

md C:\Temp

gpresult /h C:\Temp\GPreport.htm

start C:\Temp\GPreport.htm

2. Open the C:\Temp\gpresult.htm file in your web browser, and expand Computer
Details > Settings > Policies > Windows Settings > Security Settings > Local
Policies/Security Options > Network Access. Then, check whether you have a
setting that's named Network access: Restrict clients allowed to make remote calls
to SAM.

3. To open the Local Security Policy snap-in, select Start, enter secpol.msc, press Enter,
and then expand Local Policies > Expand Security Options.

4. In the list of policies, select Network access: Restrict clients allowed to make
remote calls to SAM. The Security Setting column will show Not Defined if the
setting isn't enabled, or it displays an O:BAG:... security descriptor value if the
setting is enabled. If the setting is enabled, you can also select the Properties icon
to see the Access Control List (ACL) that's currently applied.

７ Note

By default, this policy setting is turned off. When this setting is applied on a
device through a GPO or a Local Policy setting, a registry value that's named
RestrictRemoteSam is created in the
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\ registry
path. However, this registry setting can be difficult to clear after it's defined
and applied to the server. Disabling the Group Policy setting or clearing the
Define this policy setting option in Group Policy Management Console
(GPMC) doesn't remove the registry entry. Therefore, the server still restricts
which clients are allowed to make remote calls to SAM.

How do you accurately verify that the Azure AD Connect server or the domain
controller is still restricting remote calls to SAM? You check whether the
registry entry remains present by running the Get-ItemProperty cmdlet in
PowerShell:

PowerShell

Get-ItemProperty -Path HKLM:\System\CurrentControlSet\Control\Lsa -

Name RestrictRemoteSam

Does the PowerShell output show that a RestrictRemoteSam registry entry is still
present? If so, you have two possible solutions.

Solution 1: Add the AD DS Connector account to the list

of allowed users
Keep the Network access: Restrict clients allowed to make remote calls to SAM policy
setting enabled and applied on the Azure AD Connect server, but add the Active
Directory Domain Services (AD DS) Connector account (MSOL_ account) to the list of
allowed users. For instructions, see the following steps:

1. If you don't know the name of your AD DS Connector account, see Identify the AD
DS Connector account.

2. In the GPMC or Local Security Policy snap-in, go back to the property dialog box
for that policy setting.

3. Select Edit Security to display the Security Settings for Remote Access to SAM
dialog box.

4. In the Group or user names list, select Add to display the Select Users or Groups
dialog box. In the Enter the object names to select box, enter the name of the AD
DS Connector account (MSOL_ account), and then select OK to exit that dialog box.

5. Select the AD DS Connector account in the list. Under Permissions for <account
name>, in the Remote Access row, select Allow.

6. Select OK two times to accept the policy setting changes and return to the list of
policy settings.

7. Open an administrative Command Prompt window, and run the gpupdate

command to force a Group Policy update:

Console

gpupdate /force

Solution 2: Remove the Network access: Restrict clients

allowed to make remote calls to SAM policy setting, then
manually delete the RestrictRemoteSam registry entry
1. If the security setting is applied from the Local Security Policy, go to step #4.
2. Open the GPMC snap-in from a Domain Controller, and edit the respective Domain
GPO.

3. Expand Computer Configuration > Policies > Windows Settings > Security
Settings > Computer Configuration > Local Policies > Security Options.

4. In the list of security options, select Network access: Restrict clients allowed to
make remote calls to SAM, open Properties, and then disable Define this policy
setting.

5. Open an administrative Command Prompt window, and run the gpupdate

command to force a Group Policy update:

Console

gpupdate /force

6. To generate a new Group Policy result report (GPreport.htm), run the gpresult
command, and then open the new report in a web browser:

Console

md C:\Temp

gpresult /h C:\Temp\GPreport.htm

start C:\Temp\GPreport.htm

7. Check the report to make sure that the policy setting for Network access: Restrict
clients allowed to make remote calls to SAM isn't defined.

8. Open an administrative PowerShell console.

9. To remove the RestrictRemoteSam registry entry, run the Remove-ItemProperty

cmdlet:

PowerShell

Remove-ItemProperty -Path HKLM:\System\CurrentControlSet\Control\Lsa -

Name RestrictRemoteSam

７ Note

If you delete the RestrictRemoteSam registry entry without removing the

Domain GPO setting, this registry entry will be re-created on the next Group
Policy refresh cycle, and the SSPR_0029 error will reoccur.
Contact us for help
If you have questions or need help, create a support request , or ask Azure community
support.
Troubleshoot admin password resets in
Microsoft 365 admin center
Article • 04/20/2022 • 2 minutes to read

This article describes a password writeback issue that occurs after an administrator
resets a user password in the Microsoft 365 admin center.

Symptoms
A user who recently had an administrator reset their password can't sign in to on-
premises Active Directory by using the new password. Additionally, the previous
password might still work.

Cause
An administrator has reset the password of a user in the Microsoft 365 admin center .
Although the user can sign in online by using the new password, the new password isn't
synchronized back to on-premises Active Directory.

Currently, the Microsoft 365 admin center doesn't use the self-service password reset
(SSPR) and password writeback libraries. When an administrator resets a user password
in the Microsoft 365 admin center, the password is reset in Azure AD, but the new
password isn't updated in on-premises Active Directory. Therefore, the user password is
now out-of-sync between on-premises Active Directory and Azure AD.

Solution
To make sure that password writeback updates the new password in on-premises Active
Directory, the administrator who changes or resets the password must use the Azure
portal instead of the Microsoft 365 admin center .

For more information, see How does self-service password reset writeback work in Azure
Active Directory?.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Troubleshoot delays after the first sign-
in following a forced password change
Article • 04/20/2022 • 2 minutes to read

This article describes how to troubleshoot a password writeback issue when a user is
forced to change their password on first sign-in.

Symptoms
After a user makes a required password change on first sign-in, they receive this
warning message:

Your password was successfully updated, but our servers take a little time to catch
up. Please try signing in again in a few minutes.

Cause
When a user is forced to change their password on first sign-in in Azure Active Directory
(Azure AD), the password writeback process accepts the temporary password for sign-in,
and the user is prompted to provide a new password. Password writeback tries to
change the password on-premises, and then waits. If the on-premises update succeeds,
password writeback tries to change the password in Azure AD. During a password
change operation, password writeback verifies the current password, and then provides
the new password to be updated in the respective directory.

However, a timing issue might cause this warning if an attempt to sign in occurs
immediately after the on-premises Active Directory password was reset. This issue
occurs if the user has the User must change password at next logon option selected,
and the domain authentication is configured for Pass-through Authentication (PTA).

In this scenario, the user tries to sign in before password hash synchronization finishes
syncing the temporary password to Azure AD. But because PTA is configured, the
authentication is redirected to on-premises Active Directory. The user can now sign in to
Azure AD successfully and is then forced to change the password on the first sign-in. If
the password change is successful, password writeback updates the new password in
on-premises Active Directory and in Azure AD. However, the sign-in message says "our
servers take a little time to catch up." This is because the temporary password didn't
match the current password in Azure AD.
Solution
After an Active Directory administrator resets the password on-premises, Azure AD
Connect takes at least two minutes to sync that temporary password to Azure AD. To
avoid receiving this warning message, the user has to wait at least two minutes to sign
in and update the password. This provides time for password hash synchronization to
sync the temporary password.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Troubleshoot password resets that are
blocked by on-premises policy
Article • 04/20/2022 • 3 minutes to read

This article helps you troubleshoot a scenario in which a user or administrator can't reset
or change a password because the on-premises Active Directory password policy
disallows it.

Symptoms
In the Azure portal , you take the following steps:

1. Select Azure Active Directory > Users.

2. Choose a user from the list.
3. Select the Reset password link.
4. Enter a temporary password for the user to use.
5. Select the Reset password button.

In this scenario, you receive the following error message:

Unfortunately, you cannot reset this user's password because your on-premises
policy does not allow it. Please review your on-premises policy to ensure that it is
setup correctly.

Cause
The error message is sent by an on-premises domain controller. To obtain more
information about the problem, follow these steps.

７ Note

This procedure requires that you enable your domain controller's audit policy for
Account Management - Failure events. For more information, see Audit account
management.

1. Go to an on-premises domain controller.

2. Open the Event Viewer snap-in. To do this, select Start, enter eventvwr.msc, and
then press Enter.
 3. Under the Event Viewer (Local) node in the sidebar, expand Windows Logs, and
then select Security.

4. Look for audit events that contain Event ID 4724, Audit Failure (in the Keywords
column) and User Account Management (in the Task Category column). These
events should resemble the following example:

Output

Log Name: Security

Source: Microsoft-Windows-Security-Auditing

Date: 11/5/2020 2:44:01 AM

Event ID: 4724

Task Category: User Account Management

Level: Information

Keywords: Audit Failure

User: N/A

Computer: ADDS01.Contoso.net
Description:

An attempt was made to reset an account's password.

Subject:

Security ID: Contoso\MSOL_73c8a9aa6173

Account Name: MSOL_73c8a9aa6173

Account Domain: Contoso

Logon ID: 0xF91C5C

Target Account:

Security ID: Contoso\User01

Account Name: User01

Account Domain: Contoso

Event Xml:

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">

<System>

...

</System>

</Event>

This example confirms that password writeback is working as expected. However, the
password that's entered doesn't meet the local Active Directory password policy. The
policy might be violated because of password length, complexity, age, or other
requirements.

Solution
Provide a password that meets the local Active Directory password policy.
First, verify the current settings for the password policy to be able to determine any
violations. Then, go to the domain controller, and use one or more of the following
methods:

From an on-premises domain controller, open an administrative Command Prompt

window, and run the net accounts command:

Output

C:\>net accounts

Force user logoff how long after time expires?: Never

Minimum password age (days): 0

Maximum password age (days): 42

Minimum password length: 7

Length of password history maintained: 24

Lockout threshold: Never

Lockout duration (minutes): 30

Lockout observation window (minutes): 30

Computer role: PRIMARY

The command completed successfully.

Alternatively, open an administrative PowerShell window, and then run the Get-
ADDefaultDomainPasswordPolicy cmdlet:

Output

PS C:\WINDOWS\system32> Get-ADDefaultDomainPasswordPolicy

ComplexityEnabled : True

DistinguishedName : DC=contoso,DC=net

LockoutDuration : 00:30:00

LockoutObservationWindow : 00:30:00

LockoutThreshold : 0

MaxPasswordAge : 42:00:00

MinPasswordAge : 00:00:00

MinPasswordLength : 7

objectClass : {domainDNS}

objectGuid : 01234567-89ab-cdef-0123-456789abcdef

PasswordHistoryCount : 24

ReversibleEncryptionEnabled : False

In an administrative Command Prompt window, export a Group Policy report in

HTML format by running gpresult /h GPreport.htm . Open the exported report
(GPreport.htm) in a browser window, and then view the policy settings under
Account Policies/Password Policy.
Was the local Active Directory password policy configured by using fine-grained
password policies? If so, check the resultant password policy for the target user by
running the net user command ( net user <username> /domain ):

Output

C:\>net user User01 /domain

User name User01

Full Name User01

Comment

User's comment

Country/region code 000 (System Default)

Account active Yes

Account expires Never

Password last set 11/5/2020 1:57:43 PM

Password expires 12/17/2020 1:57:43 PM

Password changeable 11/5/2020 1:57:43 PM

Password required Yes

User may change password Yes

Workstations allowed All

Logon script

User profile

Home directory

Last logon Never

Logon hours allowed All

Local Group Memberships

Global Group memberships *Domain Users

The command completed successfully.

Is the entered password compliant with the local Active Directory password policy, but
the issue persists? If so, check whether you're using Azure AD Password Protection in
your on-premises AD DS environment, or if you have any third-party password filter
software installed on your domain controllers.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Error when you try to run the Azure
Active Directory Sync Tool
Configuration wizard: The Enterprise
Administrator credentials that you
supplied are not valid
Article • 04/20/2022 • 2 minutes to read

Original product version:   Cloud Services (Web roles/Worker roles), Azure Active
Directory, Microsoft Intune, Azure Backup, Office 365 Identity Management

Original KB number:   2386471

Symptoms
When you try to run the Microsoft Azure Active Directory Sync Tool Configuration
Wizard, you receive the following error message:

The Enterprise Administrator credentials that you supplied are not valid. Supply valid
credentials and try again.

Cause
This issue may occur if you entered incorrect credentials on the Active Directory
Credentials page of the Directory Sync Tool Configuration Wizard.

Resolution
To resolve this issue, follow these steps:

1. Make sure that you provide credentials for an account that has enterprise admin
permissions for your company's local Active Directory installation.
2. Make sure that you enter the correct user name and password for the user
account.
3. Make sure that the computer on which the Directory Sync Tool Configuration
Wizard is installed can communicate with your company's domain controllers and
can authenticate to the local Active Directory.
 ７ Note

The account must have enterprise admin permissions in the Active Directory forest
to which the computer that's running the Directory Sync Tool Configuration Wizard
is joined.

To check whether an account has enterprise admin permissions, follow these steps:

1. On a domain controller or computer that has the Windows Server Administration

Toolkit installed, start Active Directory Users and Computers. To do this, click Start,
click Run, type dsa.msc in the Open box, and then click OK.

2. Right-click the domain, and then click Find.

3. In the Name box, type enterprise admins, and then click Find Now.
 4. Double-click Enterprise Admins, and then click the Members tab.

5. Check whether the user is listed in the Members list. If the user isn't in the list, one
of the members of this list must log on and add the user to this list. Or, a member
of this list can use their credentials in the Directory Sync Tool Configuration Wizard.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
One or more Azure Active Directory
Connect services don't start
Article • 05/28/2022 • 2 minutes to read

This article describes an issue that prevents Microsoft Azure Active Directory (Azure AD)
Connect services from starting.

Original product version:   Azure Active Directory, Office 365 Identity Management

Original KB number:   2995030

Symptoms
You discover that one or more Azure AD Connect services don't start. For example, the
Microsoft Azure AD Sync service (ADSync) doesn't start.

Solution 1: Set User Rights Assignment

permissions within Group Policy
Make group policy changes if necessary so that the ADSync service account can log on
locally, as a service, and as a batch job. Because a domain group policy takes
precedence over a local group policy, you need to check the settings for both types of
group policies.

1. Select Start, enter gpedit.msc in the search box, and then press Enter to open the
Local Group Policy Editor snap-in.

2. In the console tree, under Computer Configuration, expand Windows Settings >
Security Settings > Local Policies, and then select User Rights Assignment.

3. Verify that the ADSync service account is added for the following policy settings:

Allow log on locally

Log on as a batch job
Log on as a service

4. For domain group policies, open an administrative command prompt.

5. Run the following gpresult command, which generates a group policy report:

cmd
 gpresult /H gpresult.htm

6. Open the resulting group policy report (gpresult.htm).

7. If User Rights Assignment settings are applied through any domain group policy
object (GPO), use the Group Policy Management console (gpmc.msc) from a
domain controller to take one of the following actions:

Remove the following policy settings from the Winning GPO:

Allow log on locally
Log on as a batch job
Log on as a service

Update the Winning GPO to include the ADSync service account.

8. If you made any changes to the local group policy or domain group policy, restart
the computer to apply the changes.

Solution 2: Troubleshoot error messages in

directory synchronization logging
You can also try to find and fix the problem by scanning the application and system
events in the directory synchronization logs. For more information, see Troubleshoot
other error messages.

Solution 3: Reinstall directory synchronization

If solutions 1 and 2 don't resolve the issue, remove and then reinstall directory
synchronization.

For example, if you use the Azure Active Directory Sync tool, remove and then reinstall
it. Or, if you use Azure AD Sync, remove and then reinstall it.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Azure AD Management Agent hangs
during Full Import or Delta Import with
error:
System.Collections.Generic.KeyNotFoun
dException
Article • 04/20/2022 • 2 minutes to read

This article provides a resolution to an issue in which the Azure Active Directory (Azure
AD) Management Agent stops responding with error
System.Collections.Generic.KeyNotFoundException.

Original product version:   Active Directory

Original KB number:   3096482

Symptoms
When you run a Full Import or a Delta Import on the Microsoft Azure AD Connector,
one of the following actions occur:

The following error is logged in the Application log:

FIMSynchronizationService Event 6801

The extensible extension returned an unsupported error.

The stack trace is:

"System.Collections.Generic.KeyNotFoundException: The given key was not

present in the dictionary.

at System.Collections.Generic.Dictionary`2.get_Item(TKey key)

at System.Collections.ObjectModel.KeyedCollection`2.get_Item(TKey key)

at
Microsoft.Azure.ActiveDirectory.Connector.Connector.GetConnectorSpaceEn
tryChange(SyncObject syncObject)

at System.Linq.Enumerable.WhereSelectListIterator`2.MoveNext()

at System.Collections.Generic.List`1.InsertRange(Int32 index,
IEnumerable`1 collection)

at
Microsoft.Azure.ActiveDirectory.Connector.Connector.GetImportEntriesCor
e()

at
Microsoft.Azure.ActiveDirectory.Connector.Connector.GetImportEntries(Ge
tImportEntriesRunStep getImportEntriesRunStep)

 You receive the following error message:

DirectorySynchronization Event 109:

Failure while importing entries from Windows Azure Active Directory.

Exception: System.Collections.Generic.KeyNotFoundException: The given
key was not present in the dictionary.

at System.Collections.Generic.Dictionary`2.get_Item(TKey key)

at System.Collections.ObjectModel.KeyedCollection`2.get_Item(TKey key)

at
Microsoft.Azure.ActiveDirectory.Connector.Connector.GetConnectorSpaceEn
tryChange(SyncObject syncObject)

at System.Linq.Enumerable.WhereSelectListIterator`2.MoveNext()

at System.Collections.Generic.List`1.InsertRange(Int32 index,
IEnumerable`1 collection)

at
Microsoft.Azure.ActiveDirectory.Connector.Connector.GetImportEntriesCor
e()

at
Microsoft.Azure.ActiveDirectory.Connector.Connector.GetImportEntries(Ge
tImportEntriesRunStep getImportEntriesRunStep).

Resolution
To resolve this problem, select the missing object type (device). To do this, follow these
steps:

1. Open Management Agent for the Azure AD directory in the Forefront Identity
Manager (FIM) Sync console.

2. Click Connectors, and then click Azure Active Directory.

3. In the Actions pane, click Properties.

７ Note

The Properties window opens.

4. Under Connector Design, click Select Object Types.

5. In the Select Object Types pane, locate and then select the device check box.

6. Click OK three times.

Status
Microsoft has confirmed that this is a problem in the Microsoft products that are listed
in the "Applies to" section.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Azure AD Connect is not working
correctly after an automatic upgrade
Article • 04/20/2022 • 2 minutes to read

This article discusses an issue in which Azure AD Connect is only partially upgraded or
the password synchronization and the password writeback features are disabled.

Original product version:   Azure Active Directory

Original KB number:   4038479

Symptoms
When you run Azure AD Connect 1.1.443.0 or an earlier version, you experience one of
the following issues:

Azure AD Connect is only partially upgraded, the scheduler is suspended, and no

automatic synchronization cycle occurs.
Azure AD Connect is upgraded correctly, the scheduler is enabled, and object
changes are synchronized correctly to Azure Active Directory (Azure AD). However,
the password synchronization feature or the password writeback feature is
disabled.

Cause
A problem in the automatic upgrade feature for Azure AD Connect causes the
Microsoft.Azure.ActiveDirectory.Synchronization.Upgrader.exe process to terminate
because of an unhandled exception. Therefore, the automatic upgrade does not finish.
To verify this, follow these steps:

Step 1: Determine whether automatic upgrade recently

tried to upgrade Azure AD Connect
Examine the log files in the %ProgramData%\AADConnect folder. Log files that have a title
of SyncEngine-AutoUpgrader-[Date]-[Time].log indicate the time that the automatic
upgrade occurred.
Step 2: Determine whether Azure AD Connect is partially
upgraded
Run the Azure AD Connect wizard. If Azure AD Connect is partially upgraded, you are
prompted to upgrade Azure AD Connect.

Step 3: Compare the installed version of Azure AD

Connect with the version in the server configuration
During automatic upgrade, the current installation of Azure AD Connect is upgraded,
and then the version in the server configuration is updated. If the two versions don't
match, Azure AD Connect is only partially upgraded.
To check which version of Azure AD Connect is installed, open the Programs and
Features item in Control Panel, and examine the version number of Azure AD Connect.

To check the version of Azure AD Connect in the server configuration, run the following
command in Windows PowerShell, and look for the value of the
Microsoft.Synchronize.ServerConfigurationVersion property:

PowerShell

(Get-ADSyncGlobalSettings).Parameters | select Name,Value

Check the status of the scheduler by running the following command:

PowerShell

Get-ADSyncScheduler

If the value of SchedulerSuspended is True, the scheduler is suspended.

Step 4: Verify that password synchronization and
password writeback are enabled
If Azure AD Connect is upgraded correctly, open the Azure AD Connect wizard, and then
select Review your solution to verify that the password synchronization and password
writeback features are enabled.

Workaround
To work around this issue, follow these steps:

1. Start the Azure AD Connect wizard, and then select Upgrade.

2. After the upgrade is complete, verify that the installed version of Azure AD
Connect matches the version in the server configuration.

3. If you have previously enabled the password synchronization feature or the

password writeback feature, verify that the feature remains enabled after the
upgrade is complete.
 4. If any of the features is disabled after the upgrade, select Customize
synchronization options in the Azure AD Connect wizard, and then manually
enable the feature.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Unable to connect to Azure Information
Protection using Windows PowerShell
Article • 04/20/2022 • 2 minutes to read

７ Note

Microsoft Azure Information Protection was previously known as Microsoft Azure

Rights Management.

This article resolves an issue where you can't connect to the Azure Information
Protection Service using Windows PowerShell in Office 365.

Original product version:   Azure Active Directory, Azure Information Protection

Original KB number:   2797755

Symptoms
When you try to connect to Microsoft Azure Information Protection using Windows
PowerShell in Microsoft Office 365, you get an error message that resembles the
following:

PS C:\> Connect-AipService

Connect-AipService : The attempt to connect to the Azure Information Protection

service failed. Verify that the user name and password you are using are
correct and try again. If you have continued problems, see

http://go.microsoft.com/fwlink/?LinkId=251909.

The correlation ID is 1df4c755-f859-4284-907b-be5d2a551260. Please note and

provide this value if asked by support for it.

At line:1 char:1

+ Connect-AipService

+ ~~~~~~~~~~~~~~~~~~

+ CategoryInfo : NotSpecified: (:) [Connect-AipService],

ApplicationFailedException
 + FullyQualifiedErrorId :

NotSpecified,Microsoft.RightsManagementServices.Online.Admin.PowerShell.Connect
AipServiceCommand

Cause
This issue occurs if one or more of the following conditions are true:

You entered the wrong user name or password.

You aren't a company administrator.
You don't have a subscription that includes Azure Information Protection.
The network is preventing you from connecting to Azure Information Protection.

Resolution

７ Note

If Azure Information Protection isn't enabled for your company, you use the
Microsoft 365 admin center to enable it. For more info about how to do this, read
Azure Information Protection deployment road map.

To resolve this issue, make sure that the following are true:

Make sure that you enter the correct user name and password. To check that you
entered them correctly, sign in to the Office 365 portal .
You must be a global administrator to connect to Azure Information Protection.
To use Azure Information Protection, you must have a subscription that includes
Azure Information Protection.
Work with the network administrator to make sure that the network meets the
requirements for connecting to Azure Information Protection. The requirements
are as follows:
Incoming and outgoing connections to *.aadrm.com are enabled.
Incoming and outgoing connections to *.cloudapp.net ( rmsoprod*-b-
rms*.cloudapp.net ) are enabled.
Port 443 is open.

More information
For more information on Azure Information Protection, visit AIPService.
Contact us for help
If you have questions or need help, create a support request , or ask Azure community
support.
Can't enable the Device writeback
option in Azure AD Connect
Article • 04/20/2022 • 3 minutes to read

Original product version:   Cloud Services (Web roles/Worker roles), Azure Active
Directory, Office 365 Identity Management, Microsoft Intune

Original KB number:   3085068

Symptoms
When you run the Azure Active Directory (Azure AD) Connect configuration wizard, you
can't enable the Device writeback option on the Customize synchronization options
page.

Cause
This issue can occur if one of the following conditions is true:

Your Azure AD organization isn't enabled for device writeback.

One or more of the domain controllers that hold an operations master role (also
known as a flexible single master operations or FSMO role) in your environment
aren't replicating.

Resolution

Step 1: Troubleshoot FSMO role or replication issues

1. Run the repadmin /showrepl command to display a report that shows replication
status. To do this, follow these steps:

a. Open a command prompt as an administrator.

b. Run the following command:

Console

repadmin /showrepl * /csv > replication.csv

c. Examine the Replication.csv file, and then troubleshoot and correct any errors.
 2. Seize the FSMO role. In some instances, the server that holds an FMSO role may
not be advertising itself correctly. Seizing itself may fix the issue. To do this, follow
these steps:

a. On a domain controller or a computer that has the Remote Server

Administration Tools Pack installed, open a command prompt as an
administrator.

b. Run the following command:

Console

netdom query FSMO

3. For each computer that's listed in the output, follow the steps in the "Seize FSMO
roles" section of Using Ntdsutil.exe to transfer or seize FSMO roles to a domain
controller .

Step 2: Enable the organization for device writeback

Follow these steps on the server on which Azure AD Connect is installed:

1. Make sure that the Remote Server Administration Tools Pack is installed. For more
information, see Installing or Removing the Remote Server Administration Tools
Pack .

2. Open Active Directory Module for Windows PowerShell as an administrator. For

more information, see Active Directory Administration with Windows PowerShell .

3. Go to %ProgramFiles%\Microsoft Azure Active Directory Connect\AdPrep , and then

run the following commands:

Console

Import-module .\AdSyncPrep.psm1

Console

Initialize-ADSyncDeviceWriteBack -domainname <domain.com>

In this command, the placeholder <domain.com> represents your Active Directory

domain. For example, run Initialize-ADSyncDeviceWriteBack -domainname
contoso.com .
 You may have to run this command for each domain in your Active Directory
environment.

4. When you're prompted, enter the enterprise administrator user name.

5. Open the Azure AD Connect configuration wizard. You should now be able to
enable device writeback.

More information
On the server on which Azure AD Connect is installed, review the logs in the following
location:

C:\Users\<UserAccount which AAD Connect was

installed>\AppData\Local\AADConnect\trace-<DateTime>.log

You may see an error message that resembles the following:

[13:15:30.864] [ 18] [ERROR]

ADPowerShellQueyProvider:SearchAdSyncDirectoryObjects Failed to run the ldap
search query. Parameter values passed to PowerShell:

ForestFqdn : <Forest_Name>

AdConnectorId : <ID>

PropertiesToRetrieve : msDS-
DeviceLocation,name,displayName,distinguishedName,objectClass

NamingContextType : Configuration

BaseDnType : Relative

AdConnectorUserName : <Domain>\MSOL_d95558f154ee

BaseDn : CN=Services

LdapFilter : (objectClass=msDS-DeviceRegistrationService)

SearchScope : Subtree

Exception Details :

System.Management.Automation.CmdletInvocationException: Error HRESULT E_FAIL

has been returned from a call to a COM component. --->
System.Runtime.InteropServices.COMException: Error HRESULT E_FAIL has been
returned from a call to a COM component. at
MmsServerRCW.IMMSServer2.SearchADSyncDirectoryObjects(String forestFqdn,
Guid& adConnectorGuid, String namingContextType, String baseDnType, String
baseDn, String ldapFilter, String searchScope, String propertiesToLoad, String
userName, String password, String& outputSerializedResult) at
Microsoft.IdentityManagement.PowerShell.Cmdlet.AdSyncDirectorySearchResult.Pro
cessRecord()
You may also see the following event 2092 warning message logged in Event Viewer on
the domain controller that's experiencing the issue:

Event ID: 2092

Task Category: Replicaiton

Level: Warning

Description:

This server is the owner of the following FSMO role, but does not consider it valid.
For the partition which contains the FSMO, this server has not replicated successfully
with any of its partners since this server has been restarted. Replication errors are
preventing validation of this role.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Can't manage or remove objects that
were synchronized through the Azure
Active Directory Sync tool
Article • 04/20/2022 • 3 minutes to read

This article describes an issue that you can't manage or remove objects that were
created through directory synchronization from Azure AD. It provides two resolutions
for this issue according to different reasons.

Original product version:   Cloud Services (Web roles/Worker roles), Azure Active
Directory, Microsoft Intune, Azure Backup, Office 365 Identity Management

Original KB number:   2619062

Symptoms
You try to manually manage or remove objects that were created through directory
synchronization from Azure Active Directory (Azure AD):

For example, you want to remove an orphaned user account that was synced to Azure
AD from your on-premises Active Directory Domain Services (AD DS).

In this scenario, you can't remove the orphaned user account by using the Microsoft
cloud service portal in Office 365, Azure, or Microsoft Intune, or by using Windows
PowerShell.

Cause
This issue may occur if one or more of the following conditions are true:

The on-premises AD DS is no longer available. So you can't manage or delete the

object from the on-premises environment.
You deleted an object from the on-premises AD DS. However, the object wasn't
deleted from your cloud service organization. This behavior is unexpected.

Resolution

The on-premises AD DS is no longer available. Therefore,

you can't manage or delete the object from the on-
premises environment
You want to manage objects in Office 365, Azure, or Intune and you no longer want to
use directory synchronization.

1. If you're not running Windows 10, install the 64-bit version of the Microsoft Online
Services Sign-in Assistant: Microsoft Online Services Sign-in Assistant for IT
Professionals RTW .

2. Install the Microsoft Azure Active Directory Module for Windows PowerShell:
a. Open an elevated Windows PowerShell command prompt (run Windows
PowerShell as an administrator).
b. Run the Install-Module MSOnline command.

3. Disable directory synchronization by running the following command:

PowerShell

Set-MsolDirSyncEnabled -EnableDirSync $false

4. Check that directory synchronization was fully disabled by using the Windows
PowerShell. To do it, run the following command periodically:

PowerShell

(Get-MSOLCompanyInformation).DirectorySynchronizationEnabled

This command will return True or False. Continue to run this command periodically
until it returns False, and then go to the next step.

It may take 72 hours for deactivation to be completed. The time depends on the
number of objects that are in your cloud service subscription account.

5. Try to update an object by using Windows PowerShell or by using the cloud service
portal.

Step 4 may take a while to be completed. There's a process in the cloud service
environment that computes attribute values. The process must be completed
before the objects can be changed by using Windows PowerShell or by using
the cloud service portal.

You delete an object from an on-premises AD DS.

However, the object isn't deleted from your cloud service
subscription account
Force directory synchronization by using the steps on this article: Start the Scheduler

If some updates and deletions are propagated, but some deletions aren't
synchronized to the cloud service, follow typical directory synchronization
troubleshooting procedures.

If all updates and deletions aren't synchronized to the cloud service, contact
Support.

７ Note

As an alternative resolution for this scenario, an object can be manually

deleted in the cloud service. However, the object can't be updated in the
cloud service. For more information about how to resolve this issue, see the
following Microsoft Knowledge Base article: Object deletions aren't
synchronized to Azure AD when using the Azure Active Directory Sync
tool .  

More information
To re-enable directory synchronization, run the following command:

PowerShell

Set-MsolDirSyncEnabled -EnableDirSync $true

It's important to plan carefully when you re-enable directory synchronization. If you
used the cloud service portal or Windows PowerShell to make any changes directly to
the objects that were originally synchronized from on-premises AD DS, the changes will
be overwritten by on-premises attributes and settings the first time that synchronization
occurs after directory synchronization is re-enabled.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Error when you run
DirSyncConfigShell.psc1 in Windows
Server 2008 R2: Could not load file or
assembly
Article • 04/20/2022 • 2 minutes to read

This article describes a scenario in which you receive an error when you run
DirSyncConfigShell.psc1 after you install version 6765.0006 of the Directory Sync tool
on a Windows Server 2008 R2-based computer.

Original product version:   Azure Active Directory, Cloud Services (Web roles/Worker
roles), Microsoft Intune, Azure Backup, Office 365 Identity Management

Original KB number:   2964373

Symptoms
When you run DirSyncConfigShell.psc1 after you install version 6765.0006 of the
Microsoft Azure Active Directory Sync Tool on a Windows Server 2008 R2-based
computer, you receive the following error message:

WARNING: The following errors occurred when loading console c:\program

files\windows azure active directory sync\dirsyncfonfigshell.psc1: Cannot load
Windows PowerShell snap-in coexistence-configuration because of the following
error: could not load file or assembly 'file:///c:\programSync\Microsoft
Online.Coexistence.PS.Config.dll' or one of its dependencies. This assembly is built
by a runtime newer than the currently loaded runtime and cannot be loaded.
For
example, this issue occurs when you run DirSyncConfigShell.psc1 to force directory
synchronization.

Cause
This issue occurs if Windows Management Framework 3.0 is not installed on the
Windows Server 2008 R2-based computer.

Resolution
Do one of the following:
 Install Windows Management Framework 3.0 on the Windows Server 2008 R2-
based computer. For more information, see Windows Management Framework
3.0 .
Run the Directory Sync tool from a Windows Server 2012 R2-based computer. To
install the Directory Sync tool, see Install or upgrade the Directory Sync tool.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Users can no longer sign in after you
run the Convert-
MSOLDomaintoFederated command to
convert an existing domain
Article • 04/20/2022 • 2 minutes to read

This article provides information about troubleshooting an issue in which users can no
longer access Office 365, Azure, or Microsoft Intune after running the Convert-
MSOLDomaintoFederated command to convert an existing domain from standard

authentication to federated authentication.

Original product version:   Cloud Services (Web roles/Worker roles), Azure Active
Directory, Microsoft Intune, Azure Backup, Office 365 Identity Management

Original KB number:   2662960

Symptoms
During setup of single sign-on (SSO) in a Microsoft cloud service such as Office 365,
Microsoft Azure, or Microsoft Intune, you run the Convert-MSOLDomaintoFederated
command to convert an existing domain from standard authentication to federated
authentication. However, after you do this, users who are associated with that domain
can no longer access the cloud service.

Cause
This issue occurs if SSO isn't set up correctly or if the setup isn't completed.

２ Warning

It's a Microsoft best practice to always have at least one administrator user ID that's
associated with the default domain so that administrative access to the
organization isn't lost if SSO is compromised.

Resolution
To resolve this issue, use one of the following methods, as appropriate for your
situation.

Method 1: Troubleshoot SSO setup

Use this method only if all the following conditions are true:

The problem isn't caused by a service outage.

Immediately restoring user access isn't required.

To diagnose and troubleshoot SSO setup, see Troubleshoot single sign-on setup issues
in Office 365, Intune, or Azure .

Method 2: Revert the domain federation back to standard

authentication if the AD FS server isn't available
Use this method only if all the following conditions are true:

The problem is caused by a service outage that requires immediately restoring user
access.
The AD FS server is unavailable.

If these conditions are true, reset the authentication setting for the domain and for each
user account to use standard authentication. To do this, follow these steps:

1. Start the Azure Active Directory Module for Windows PowerShell. To do this, select
Start, select All Programs, select Windows Azure Active Directory, right-click
Windows Azure Active Directory Module for Windows PowerShell, and then
select Run as administrator.

2. To convert the domain, run the following commands in the order in which they are
presented. Press Enter after you type each command.

PowerShell

$cred = Get-Credential

When you're prompted, enter cloud service administrator credentials that are not
SSO-enabled.

PowerShell

Connect-MsolService -credential $cred

 PowerShell

Set-MSOLDomainAuthentication -Authentication Managed -DomainName

<federated domain name>

７ Note

In this command, the placeholder <federated domain name> represents the

name of the domain for which SSO isn't working.

3. For each user who has a user principal name (UPN) suffix that's associated with the
domain, run the following command:

PowerShell

Convert-MSOLFederatedUser -UserPrincipalName <string>

７ Note

In this command, the placeholder <string> represents the value of the UPN
for the user who is being converted.

More information

） Important

In scenarios in which the last Microsoft cloud services organization administrator is

assigned the domain suffix of a federated domain and in which that administrator
becomes SSO-enabled, subsequent AD FS failures will limit running the connect-
MSOLService command and may prevent the remediation of SSO problems. It's a
best practice recommendation that Microsoft cloud services organization
administrators always keep at least one global administrator account that isn't SSO-
enabled to allow for troubleshooting SSO problems by using the Azure Active
Directory Module for Windows PowerShell.

If this problem occurs, contact Microsoft Support to have the domain federation
reversed temporarily so that the administrator (who is no longer SSO-enabled) can
regain access to troubleshoot SSO-related problems.
Contact us for help
If you have questions or need help, create a support request , or ask Azure community
support.
Can't sync SystemMailbox or
DiscoveryMailboxSearch accounts using
Azure Active Directory Sync tool
Article • 04/20/2022 • 2 minutes to read

This article provides information about resolve a problem in which you receive errors
when trying to use the Azure Active Directory Sync tool to synchronize the
SystemMailbox and DiscoverySearchMailbox user accounts.

Original product version:   Cloud Services (Web roles/Worker roles), Azure Active
Directory, Microsoft Intune, Azure Backup, Office 365 Identity Management

Original KB number:   2804688

Symptoms
When you use the Microsoft Azure Active Directory Sync tool to sync the following user
accounts, you receive directory synchronization errors:

SystemMailbox{1f05a927-beed-480c-b962-
da8d1d7e16a8}@<DomainNameName>
SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}@<DomainName>
DiscoverySearchMailbox{D919BA05-46A6-415f-80AD-
7E09334BB852}@<DomainNameName>

Cause
This issue occurs if the three user accounts that were created during Microsoft Exchange
Server 2010 installation are missing the attribute data. In this case, the attribute data is
used by the Azure Active Directory Sync tool to filter out these user accounts and stop
them from being synced to the cloud.

Resolution
To resolve this issue, use one of the following methods, as appropriate for your
situation.

Method 1
On the domain controller or a computer on which the Active Directory Domain Services
Administration Tools are installed, follow these steps:

1. Open Active Directory Users and Computers.

2. On the View menu, select Advanced Features.

3. Select the Users container.

4. Double-click each SystemMailbox user account, and then follow these steps for
each account:
a. Select Attribute Editor.
b. Find the mailNickName attribute, and then populate the attribute by using the
value that's included in the mail attribute.
c. Select OK.

5. Double-click each DiscoverySearchMailbox user account, and then follow these

steps for each account:
a. Select Attribute Editor.
b. Find the mailNickName attribute, and then populate the attribute by using the
value that is included in the mail attribute.
c. Find the msExchRecipientTypeDetails attribute, and then set the value of the
attribute to 536870912.
d. Select OK.

Method 2

On the computer on which the Directory Sync tool is installed, follow these steps:

1. Open an elevated command prompt.

2. Open Windows PowerShell, type Import-Module DirSync , and then press Enter.

3. After the Windows PowerShell session starts, run the following cmdlet:

PowerShell

Start-OnlineCoexistenceSync

If the methods did not work, see Recreate missing arbitration mailboxes.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Error when you try to reset your
password in Azure, Office 365, or
Intune: We could not verify your
account
Article • 04/20/2022 • 2 minutes to read

This article describes a problem in which you receive an error message "We could not
verify your account" when you try to reset your password in Microsoft Azure, Office 365,
or Microsoft Intune. To resolve this problem, work with your administrator to update
your telephone number.

Original product version:   Azure Active Directory, Microsoft Intune, Cloud Services (Web
roles/Worker roles)

Original KB number:   2951246

Symptoms
When you use Microsoft Azure, Microsoft Office 365, or Microsoft Intune, you may
receive the following error message when you try to reset your password:

We could not verify your account.

Cause
This problem may occur because there are no telephone numbers on file for you.

Resolution
To resolve this problem, work with your administrator to update your telephone
number(s).

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Security group is still mail-enabled after
it is disabled through a sync in on-
premises AD
Article • 04/20/2022 • 2 minutes to read

This article provides information about resolving an issue in which a security group
remains mail-enabled after it is disabled through a sync in on-premises AD.

Original product version:   Azure Active Directory

Original KB number:   4096314

Symptoms
Consider the following scenario:

You have a security group that has an email address that is specified in on-
premises Active Directory (on-premises AD).
The security group is synchronized to Azure Active Directory (Azure AD).
You remove the email address from the security group in on-premises AD.
You run  a synchronization.
In this scenario, the security group remains mail-
enabled, and it still has the original email address that was assigned to it in Azure
AD.

Cause
When a mail-enabled security group is synchronized to Azure AD, the email address that
uses the original domain ( onmicrosoft.com ) is appended to the group as the secondary
email address. If you delete the primary email address, the email address that has the
original domain becomes the primary email address.

The following is the impact of this issue:

The affected group does not exist in Global Address List (GAL) for on-premises
users, so the user cannot choose the group in the From filed when they send
emails.
For Exchange Online users, the affected group can be found in GAL to choose
from. However, email does not reach the recipient since the group's mail address
was changed to alias@contoso.onmicrosoft.com .
 On-premises users cannot use the affected group to set permission such as access
to a shared calendar.
For Exchange Online users, the affected group can be used to set access to a
calendar.

Workaround
To work around this issue, use one of the following methods:

Delete the security group from the Admin Portal, and then run the synchronization
again.

Move the security group to another organizational unit (OU) that has not been
synchronized (filtered out). When you do this, the group is removed from the
cloud. Then, move the group back to the original OU.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Azure Active Directory Joined
computers experience a three hours
delay during boot
Article • 04/20/2022 • 2 minutes to read

Original product version:   Azure Active Directory

Original KB number:   4565997

Symptoms
Consider the following scenario:

1. You are using Azure AD Connect to federate (synchronize) users from an on-
premises Active Directory domain to Azure AD.
2. The computer is Azure AD joined, and the workgroup name is the same as the on-
premises domain's NetBIOS name.
3. You have logged on to this computer with a federated user at least once.

In this case, the computer takes approximately three hours to progress to the logon
screen when you restart the OS. During this time, you will see a black screen that
displays an activity icon (a spinning circle of dots). Approximately three hours after
starting, the startup process finishes, and the interactive logon screen is displayed and
the user can log in without issues.

This slow startup experience is not dependent on the hardware configuration.

Computers that have "excellent" hardware specifications can also experience this
problem.

Cause
This issue occurs because Windows unexpectedly evaluates a condition in which a wait
time of 10,000 seconds is initiated. This timeout condition is manifested as a three-hour
startup delay.

７ Note

For reference, 10,000 seconds = 167 minutes = 2 hours 47 minutes.

Resolution
To resolve this issue, use a workgroup name that does not match the NetBIOS name of
the on-premises domain.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Directory synchronization to Azure
Active Directory stops or you're warned
that sync hasn't registered in more than
a day
Article • 04/20/2022 • 5 minutes to read

This article describes a performance problem in Azure Active Directory Sync Tool. The
tool either stops syncing, or reports that sync hasn't run in more than 24 hours.

Original product version:   Azure Active Directory, Microsoft Intune, Azure Backup, Office
365 Identity Management

Original KB number:   2882421

Symptoms
You experience one of the following symptoms:

The Microsoft Azure Active Directory Sync Tool stops syncing.

You receive email messages that say that Azure Active Directory (Azure AD) didn't
register a synchronization attempt in the last 24 hours.
In the MIISClient.exe tool, you receive a "Stopped-Server-Down" message or a
"Stopped-Extension-DLL-Exception" message.
You're unable to start one or more of the directory synchronization services.

７ Note

By default, directory synchronization runs every three hours.

Cause
This issue may occur if one or more of the following conditions are true:

The work or school account that was used in the configuration wizard to set up
directory synchronization has one of the following problems:
The account was deleted.
The account was disabled.
The account password expired.
 The logon account for one or more directory synchronization services has one of
the following problems:
The account was deleted.
The account was disabled.
The account password expired.

７ Note

The logon account for the directory synchronization service is automatically

configured and should not be modified.

The admin account that's used for directory synchronization was changed.

You have network connection issues.

Directory synchronization services are stopped.

Resolution

Method 1: Manually verify that the service is started and

that the admin account can sign in
1. Select Start, select Run, type Services.msc, and then select OK.

2. Locate the Azure Active Directory Synchronization appliance service, and then
check whether the service is started. If the service isn't started, right-click it, and
then select Start.

If you're using the Azure Active Directory Sync Tool, look for Azure Active
Directory Sync Service.
If you're using Azure Active Directory Connect, look for Microsoft Azure AD
Sync.

3. Verify that the admin account that's being used for directory synchronization still
exists. And verify that the account is allowed to sign in. If the account still exists,
reset the password, and then verify that you can sign in. If you're prompted,
change the password.

If you don't know the global administrator account that's used to configure
directory synchronization, follow these steps on the server on which you installed
the directory synchronization appliance:
 a. Go to %ProgramFiles%\Microsoft Azure AD Sync\UIShell\ , and then run
Miisclient.exe.

７ Note

If you're using Azure Active Directory Connect or the Azure Active Directory
Sync Service, select Start, and then search for and open Synchronization
Service.

b. Select Connectors, and then double-click the Azure Active Directory connector.

c. Select Connectivity.

d. Make note of the UserName value. It's the global administrator account that's
used to configure directory synchronization.

4. On the directory synchronization server, run the Azure Active Directory

Synchronization appliance configuration wizard. Type the new password for the
admin account that's used for directory synchronization, and then follow the
remaining steps in the wizard.

5. When you're prompted, select the Force directory synchronization check box.

Method 2: Resolve the problem with the logon account

for the directory synchronization service
1. Select Start, select Run, type Services.msc, and then select OK.

2. Locate the Azure Active Directory Synchronization appliance service:

If you're using the Azure Active Directory Sync Tool, look for Azure Active
Directory Sync Service.
If you're using Azure Active Directory Connect, look for Microsoft Azure AD
Sync. Right-click the service, and then select Properties. On the Log On tab,
note the account name that's listed.

７ Note

Reconfiguring any of the directory synchronization services to log on as a

local system account isn't supported and may introduce problems.
3. On a domain controller or a computer that has the Administration Tools installed,
open Active Directory Users and Computers (Dsa.msc), right-click the domain
name, and then select Find. Type the name of the account that you noted in step 2,
and then select Find now.

If you find the account, go to step 4.

If you can't find the account, it may have been deleted. For more information
about how to restore this account, see Active Directory Recycle Bin Step-by-
Step Guide. If you can't restore the account, you must uninstall and then
reinstall the directory synchronization client.

4. Right-click the account, and then select Properties. On the Account tab, under
Account options,  follow these steps:
a. Make sure that the Password never expires check box is selected.
b. Make sure that the Account is disabled check box is cleared. Then, take one of
the following actions:

If the Account is disabled check box is selected, clear it to enable the

account. Then, restart the Azure Active Directory Synchronization appliance
service. To do so, select Start, select Run, type Services.msc, and then select
OK. Locate the service, right-click it, and then select Restart.
If you're using the Azure Active Directory Sync Tool, look for Azure Active
Directory Sync Service.
If you're using Azure Active Directory Connect, look for Microsoft Azure
AD Sync.
If the Account is disabled check box is already cleared, go to step 5.

5. If the Account is disabled  check box is already cleared, it's possible that the
password for the account was manually changed. To set a new password, open
Active Directory Users and Computers, locate and right-click the account, and then
select Reset Password  to reset the password. Note the password that you set
because you'll have to use it in the next step.

6. Set the password on the logon account for the directory synchronization services:

a. select Start, select Run, type Services.msc, and then select OK.

b. Set the password for the following services, depending on the client that you're
using. To do so, right-click the appropriate service, select Properties, select the
Log On tab, and then type the password.

Azure Active Directory Synchronization client Azure Active Directory Connect

 Azure Active Directory Synchronization client Azure Active Directory Connect

Forefront Identity Manager Synchronization Service

Azure AD Sync
SQL Server (MOSONLINE) (if present)

Azure Active Directory Sync Service

c. Start the service or services for which you set the new password.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Email addresses aren't synced to Azure
Active Directory
Article • 04/20/2022 • 2 minutes to read

This article describes an issue in which users are synced to Azure AD but one or more
SMTP proxy addresses aren't synced. This issue occurs if duplicate SMTP proxy
addresses exist.

Original product version:   Azure Active Directory

Original KB number:   3166798

Symptoms
Although your users are synced to Azure Active Directory (Azure AD), one or more SMTP
proxy addresses aren't synced. Additionally, you may see a message that resembles one
of the following:

In the Office 365 portal:

There is an error on one or more user accounts. To see which users are affected and
the detailed error message, select the "users with errors" view, and then select the
user's display name.

We detected a duplicate Proxy address conflict on the value <value>. All attribute
values need to be unique across objects. To resolve this conflict, first determine
which object should be using the conflicting value. Then, update or remove the
conflicting value from the other object(s). This error was detected on <Date and
Time>.

From an email report:

This object has been updated in your Azure Active Directory, but with some
modified properties, because the following attributes are associated with another
object [ProxyAddresses SMTP: john@contoso.com ;].

This issue occurs if another object has the same SMTP proxy address.

Resolution
To resolve this issue, find the users who have duplicate SMTP proxy addresses, and then
change the addresses so that they are unique. To do this, follow these steps.

Step 1: Check your local directory

Use the IdFix DirSync Error Remediation Tool to identify duplicate or invalid attributes.

To resolve duplicate attributes by using the IdFix Tool, see "Duplicate" is displayed in the
ERROR column.

For more information about the IdFix tool, go to IdFix DirSync Error Remediation Tool .

Step 2: Check Azure AD

You can use the Office 365 portal or the Azure Active Directory Module for Windows
PowerShell to check Azure AD for duplicate attributes.

７ Note

The report in the Office 365 portal only displays user objects that have these errors.
The report doesn't show information about conflicts between groups, contacts, or
public folders. See Method 2 to learn how to view conflicts for the other objects.

Method 1: Use the Office 365 portal

1. Sign in to the Office 365 portal (https://portal.office.com ) as an administrator.

2. In the Microsoft 365 admin center, go to Users, and then select Active users.

A warning at the top of the page is displayed if there are duplicate attribute
conflicts on any object in your organization.

3. To filter the view to display only users with errors, select Users with errors.

4. Select an object to view details about the conflict. This information is displayed in
the lower-right corner of the page.

5. Change the email address so that it's unique.

Method 2: Use the Azure AD Module for Windows PowerShell

To learn more about how to use the Azure AD Module for Windows PowerShell to
identify objects that have duplicate values, see Identity synchronization and duplicate
attribute resiliency.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Password Hash Sync is automatically
enabled during Azure AD Connect Pass-
through Authentication
Article • 04/20/2022 • 3 minutes to read

This article can help you fix a problem in which Password Hash Synchronization is
automatically enabled in Azure AD connector.

Original product version:   Azure Active Directory

Original KB number:   4051623

The following versions of Microsoft Azure Active Directory (AD) Connect have issues that
affect the Change user sign-in task:

1.1.557.0
1.1.558.0
1.1.561.0
1.1.614.0

These issues affect the Pass-through Authentication users who don't want to use
Password Hash Synchronization.

The issues are fixed in Azure AD Connect version 1.1.644.0.

Problem 1: Password Synchronization is

enabled when User sign-in method is set to
Pass-through Authentication

Scenario 1
You have an existing Azure AD Connect deployment that has both Password
Synchronization and Pass-through Authentication disabled.
After you enable Pass-through Authentication by using the Change user sign-in
task, Password Hash Synchronization is automatically enabled.

Scenario 2
 You have an existing Azure AD Connect deployment that has Password
Synchronization disabled and Pass-through Authentication enabled.
After you enable or disable the Seamless Single Sign-on option by using the
Change user sign-in task, Password Hash Synchronization is automatically enabled.

Background information about this issue

Prior to Azure AD Connect version 1.1.557.0, Password Synchronization was a
prerequisite for enabling Pass-through Authentication. Therefore, Password
Synchronization was enabled when Pass-through Authentication was enabled.
Because Password Synchronization is no longer required for Pass-through
Authentication, we changed this process in Azure AD Connect version 1.1.557.0 so
that it does not enable Password Synchronization when Pass-through
Authentication is enabled during an Azure AD Connect installation.
However, the same change was not applied to the Change user sign-in task. If you
use the task to enable Pass-through Authentication to an existing Azure AD
Connect deployment, Password Synchronization is automatically enabled. This
issue is fixed in Azure AD Connect version 1.1.644.0 to make sure that Password
Hash Synchronization remains disabled when Pass-through Authentication is
enabled by using the Change user sign-in task.

Problem 2: Incorrect prompt about

disabled Password Synchronization if User sign-
in method is set to Pass-through
Authentication
You have an existing Azure AD Connect deployment that has Password
Synchronization enabled and Pass-through Authentication disabled.
After you enable Pass-through Authentication by using the Change user sign-in
task, Password Hash Synchronization remains enabled.

Background information about this issue

By design, if Password Hash Synchronization is enabled, changing the user sign-in task
to any other option does not disable Password Hash Synchronization. This issue is fixed
in Azure AD Connect version 1.1.644.0 to prevent the display of the prompt window that
states that Password Hash Synchronization is disabled.
Resolution
To resolve this issue, follow these steps:

1. Run Azure AD Connect, and then select View current configuration. In the details
pane, check whether Password synchronization is enabled on your tenant.

2. Disable the Password synchronization feature. To do this, follow these steps:

a. Run Azure AD Connect, and then select Configure.
b. Select the Customize synchronization options task.
c. On the Optional features page, clear the Password synchronization feature
check box.
d. Complete the wizard.

Optionally, if you want to clear password hashes that are already synchronized to Azure
AD, follow these steps:

1. Make sure that the Password writeback feature is disabled on your tenant. To do
that, follow these steps:
a. Run Azure AD Connect, and then select Configure.
b. Select the Customize synchronization options task.
c. On the Optional features page, clear the Password writeback feature check
box.
d. Complete the wizard.
 2. Use the Set-MsolUserPassword cmdlet to set random passwords on all affected
users. You have to run this cmdlet five times for each user because Azure AD stores
the last four password hashes in the password hash history.

７ Note

The Set-MsolUserPassword cmdlet does not work if the user is using a federated
domain. To clear password hashes for the user in the federated domain, you must
change the UPN of the user to a non-federated domain, and then run the cmdlet to
set the random password. After that, revert the UPN of the user to the original
state.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Enable support for TLS 1.2 in your environment
for Azure AD TLS 1.1 and 1.0 deprecation
Article • 10/06/2022 • 13 minutes to read

To improve the security posture of your tenant, and to remain in compliance with industry standards,
Microsoft Azure Active Directory (Azure AD) will soon stop supporting the following Transport Layer
Security (TLS) protocols and ciphers:

TLS 1.1
TLS 1.0
3DES cipher suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA)

How this change might affect your organization

Do your applications communicate with or authenticate against Azure Active Directory? Then those
applications might not work as expected if they can't use TLS 1.2 to communicate. This situation includes:

Azure AD Connect
Azure AD PowerShell
Azure AD Application Proxy connectors
PTA agents
Legacy browsers
Applications that are integrated with Azure AD

Why this change is being made

These protocols and ciphers are being deprecated for the following reasons:

To follow the latest compliance standards for the Federal Risk and Authorization Management
Program (FedRAMP) .
To improve security when users interact with our cloud services.

The services are being deprecated on the following dates:

TLS 1.0, 1.1 and 3DES Cipher suite in U.S. government instances starting on March 31, 2021.
TLS 1.0, 1.1 and 3DES Cipher suite in public instances starting January 31, 2022. (This date has been
postponed from June 30th, 2021 to January 31st, 2022, to give administrators more time to remove
the dependency on legacy TLS protocols and ciphers (TLS 1.0,1.1 and 3DES).)

Enable support for TLS 1.2 in your environment

How do you maintain a secure connection to Azure Active Directory (Azure AD) and Microsoft 365
services? You enable your client apps and client and server operating system (OS) for TLS 1.2 and modern
cipher suites.

Guidelines for enabling TLS 1.2 on clients

 Update Windows and the default TLS that you use for "WinHTTP".
Identify and reduce you dependency on the client apps and operating systems that don't support TLS
1.2.
Enable TLS 1.2 for applications and services that communicate with Azure AD.
Update and configure your .NET Framework installation to support TLS 1.2.
Make sure that applications and PowerShell (that use Microsoft Graph ) and Azure AD PowerShell
scripts are hosted and run on a platform that supports TLS 1.2.
Make sure that your web browser has the latest updates. We recommend that you use the new
Microsoft Edge browser (based on Chromium). For more information, see the Microsoft Edge release
notes for Stable Channel.
Make sure that your web proxy supports TLS 1.2. For more information about how to update a web
proxy, check with the vendor of your web proxy solution.

For more information, see the following articles:

How to enable TLS 1.2 on clients

Preparing for TLS 1.2 in Office 365 and Office 365 GCC - Microsoft 365 Compliance

Update the Windows OS and the default TLS that you use for
WinHTTP
These operating systems natively support TLS 1.2 for client-server communications over WinHTTP:

Windows 10
Windows 8.1
Windows Server 2016
Windows Server 2012 R2
Later versions of Windows and Windows Server

Verify that you haven't explicitly disabled TLS 1.2 on these platforms.

By default, earlier versions of Windows (such as Windows 8 and Windows Server 2012) don't enable TLS
1.2 or TLS 1.1 for secure communications by using WinHTTP. For these earlier versions of Windows:

1. Install Update 3140245 .

2. Enable the registry values from the Enable TLS 1.2 on client or server operating systems section.

You can configure those values to add TLS 1.2 and TLS 1.1 to the default secure protocols list for WinHTTP.

For more information, see How to enable TLS 1.2 on clients.

７ Note

By default, an OS that supports TLS 1.2 (for example, Windows 10) also supports legacy versions of
the TLS protocol. When a connection is made by using TLS 1.2 and it doesn’t get a timely response, or
when the connection is reset, the OS might try to connect to the target web service by using an older
TLS protocol (such as TLS 1.0 or 1.1). This usually occurs if the network is busy, or if a packet drops in
the network. After the temporary fallback to the legacy TLS, the OS will try again to make a TLS 1.2
connection.
 What will be the status of such fallback traffic after Microsoft stops supporting the legacy TLS? The OS
might still try to make a TLS connection by using the legacy TLS protocol. But if the Microsoft service
is no longer supporting the older TLS protocol, the legacy TLS-based connection won’t succeed. This
will force the OS to try the connection again by using TLS 1.2 instead.

Identify and reduce dependency on clients that don't support TLS 1.2
Update the following clients to provide uninterrupted access:

Android version 4.3 and earlier versions

Firefox version 5.0 and earlier versions
Internet Explorer versions 8-10 on Windows 7 and earlier versions
Internet Explorer 10 on Windows Phone 8.0
Safari 6.0.4 on OS X 10.8.4 and earlier versions

For more information, see Handshake Simulation for various clients connecting to www.microsoft.com,
courtesy SSLLabs.com.

Enable TLS 1.2 on common server roles that communicate with Azure
AD
Azure AD Connect (install the latest version)
Do you also want to enable TLS 1.2 between the sync engine server and a remote SQL Server?
Then make sure you have the required versions installed for TLS 1.2 support for Microsoft SQL
Server .

Azure AD Connect Authentication Agent (pass-through authentication) (version 1.5.643.0 and later
versions)

Azure Application Proxy (version 1.5.1526.0 and later versions enforce TLS 1.2)

Active Directory Federation Services (AD FS) for servers that are configured to use Azure Multi-Factor
Authentication (Azure MFA)

NPS servers that are configured to use the NPS extension for Azure AD MFA

MFA Server version 8.0.x or later versions

Azure AD Password Protection proxy service

Action required

1. We highly recommend that you run the latest version of the agent, service, or connector.

2. By default, TLS 1.2 is enabled on Windows Server 2012 R2 and later versions. In rare instances,
the default OS configuration might have been modified to disable TLS 1.

To make sure that TLS 1.2 is enabled, we recommend that you explicitly add the registry values
from the Enable TLS 1.2 on client or server operating systems section on servers that are
running Windows Server and that communicate with Azure AD.
 3. Most of the previously listed services are dependent on .NET Framework. Make sure it's
updated as described in the Update and configure .NET Framework to support TLS 1.2 section.

For more information, see the following articles:

TLS 1.2 enforcement - Enforce TLS 1.2 for the Azure AD Registration Service
Azure AD Connect: TLS 1.2 enforcement for Azure Active Directory Connect
Understand Azure AD Application Proxy connectors

Enable TLS 1.2 on client or server operating systems

Registry strings
To manually configure and enable TLS 1.2 at the operating system level, you can add the following
DWORD values.

For Windows 2012 R2, Windows 8.1, and later OS, TLS 1.2 is enabled by default. Thus, the following
registry values aren't required unless they were set with different values.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
1.2\Client
"DisabledByDefault": 00000000
"Enabled": 00000001
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
1.2\Server
"DisabledByDefault": 00000000
"Enabled": 00000001
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319
"SchUseStrongCrypto": 00000001

To enable TLS 1.2 by using a PowerShell script, see TLS 1.2 enforcement for Azure AD Connect.

Update and configure .NET Framework to support TLS 1.2

Managed Azure AD-integrated applications and Windows PowerShell scripts (using Azure AD PowerShell
V1 (Microsoft MSOnline), V2 (AzureAD), Microsoft Graph ) may use .NET Framework.

Install .NET updates to enable strong cryptography

Determine the .NET version

First, determine the installed .NET versions.

For more information, see Determine which versions and service pack levels of .NET Framework are
installed.

Install .NET updates

Install the .NET updates so that you can enable strong cryptography. Some versions of .NET Framework
might have to be updated to enable strong cryptography.

Use these guidelines:

.NET Framework 4.6.2 and later versions support TLS 1.2 and TLS 1.1. Check the registry settings. No
other changes are required.

Update .NET Framework 4.6 and earlier versions to support TLS 1.2 and TLS 1.1.

For more information, see .NET Framework versions and dependencies.

Do you use .NET Framework 4.5.2 or 4.5.1 on Windows 8.1 or Windows Server 2012? Then the
relevant updates and details are also available from Microsoft Update Catalog .
Also see Microsoft Security Advisory 2960358.

For any computer that communicates across the network and runs a TLS 1.2-enabled system, set the
following registry DWORD values.

For 32-bit applications that are running on a 32-bit OS and 64-bit applications that are running on a
64-bit OS, update the following subkey values:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727
"SystemDefaultTlsVersions": 00000001
"SchUseStrongCrypto": 00000001

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319
"SystemDefaultTlsVersions": 00000001
"SchUseStrongCrypto": 00000001

For 32-bit applications that are running on 64-bit OSs, update the following subkey values:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727
"SystemDefaultTlsVersions": dword:00000001
"SchUseStrongCrypto": dword:00000001
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319
"SystemDefaultTlsVersions": dword:00000001
"SchUseStrongCrypto": dword:00000001

For example, set these values on:

Configuration Manager clients

Remote site system roles that aren't installed on the site server
The site server itself

For more information, see the following articles:

TLS Cipher Suites supported by Azure AD

How to enable TLS 1.2 on clients
Transport Layer Security (TLS) best practices with the .NET Framework
Solving the TLS 1.0 Problem - Security documentation

Overview of new telemetry in the sign-in logs

To help you identify any clients or apps that still use legacy TLS in your environment, view the Azure AD
sign-in logs. For clients or apps that sign in over legacy TLS, Azure AD marks the Legacy TLS field in
Additional Details with True. The Legacy TLS field only appears if the sign-in occurred over legacy TLS. If
you don’t see any legacy TLS in your logs, you're ready to switch to TLS 1.2.

To find the sign-in attempts that used legacy TLS protocols, an administrator can review the logs by:

Exporting and querying the logs in Azure Monitor.

Downloading the last seven days of logs in JavaScript Object Notation (JSON) format.
Filtering and exporting sign-in logs using PowerShell.

These methods are described below.

Azure Monitor

You can query the sign-in logs using Azure Monitor. Azure Monitor is a powerful log analysis,
monitoring, and alerting tool. Use Azure Monitor for:

Azure AD logs
Azure resources logs
Logs from independent software tools

７ Note

You need an Azure AD Premium license to export reporting data to Azure Monitor.

To query for legacy TLS entries using Azure Monitor:

1. In Integrate Azure AD logs with Azure Monitor logs, follow the instructions for how to access the
Azure AD sign-in logs in Azure Monitor.

2. In the query definition area, paste the following Kusto Query Language query:

Kusto

// Interactive sign-ins only

SigninLogs

| where AuthenticationProcessingDetails has "Legacy TLS"

and AuthenticationProcessingDetails has "True"

| extend JsonAuthProcDetails = parse_json(AuthenticationProcessingDetails)

| mv-apply JsonAuthProcDetails on (

where JsonAuthProcDetails.key startswith "Legacy TLS"

| project HasLegacyTls=JsonAuthProcDetails.value

| where HasLegacyTls == true

// Non-interactive sign-ins

AADNonInteractiveUserSignInLogs

| where AuthenticationProcessingDetails has "Legacy TLS"

and AuthenticationProcessingDetails has "True"

| extend JsonAuthProcDetails = parse_json(AuthenticationProcessingDetails)

| mv-apply JsonAuthProcDetails on (

where JsonAuthProcDetails.key startswith "Legacy TLS"

| project HasLegacyTls=JsonAuthProcDetails.value

| where HasLegacyTls == true

 // Workload Identity (service principal) sign-ins

AADServicePrincipalSignInLogs

| where AuthenticationProcessingDetails has "Legacy TLS"

and AuthenticationProcessingDetails has "True"

| extend JsonAuthProcDetails = parse_json(AuthenticationProcessingDetails)

| mv-apply JsonAuthProcDetails on (

where JsonAuthProcDetails.key startswith "Legacy TLS"

| project HasLegacyTls=JsonAuthProcDetails.value

| where HasLegacyTls == true

3. Select Run to execute the query. The log entries that match the query appear in the Results tab
below the query definition.

4. To learn more about the source of the legacy TLS request, look for the following fields:

UserDisplayName
AppDisplayName
ResourceDisplayName
UserAgent

View details about log entries in the Azure AD portal

After you obtain the logs, you can get more details about legacy TLS-based sign-in log entries in the Azure
AD portal. Follow these steps:

1. In the Azure portal , search for and select Azure Active Directory.

2. In the Overview page menu, select Sign-in logs.

3. Select a sign-in log entry for a user.

4. Select the Additional details tab. (If you don't see this tab, first select the ellipsis (...) in the right
corner to view the full list of tabs.)

5. Check for a Legacy TLS (TLS 1.0, 1.1, or 3DES) value that's set to True. If you see that particular field
and value, the sign-in attempt was made using legacy TLS. If the sign-in attempt was made using TLS
1.2, that field doesn't appear.

For more information, see Sign-in logs in Azure Active Directory.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community support.
Error when upgrading Azure AD
Connect: Unable to install the
synchronization service
Article • 04/20/2022 • 2 minutes to read

Original product version:   Office 365 Identity Management, Azure Active Directory

Original KB number:   4054462

Symptoms
When you try to upgrade Azure Active Directory Connect, you receive the following
error message:

An Error occurred while Upgrading from Azure Active Directory Sync. Unable to
upgrade the Synchronization Service. Please see the Event log for additional details.

The detailed event log resembles the following:

Date/Time[ 12] [INFO ] ServiceControllerProvider: StartService status: Running

Date/Time[ 12] [ERROR] Error during sync engine upgrade. System.Exception:
Unable to upgrade the Synchronization Service. Please see the event log for
additional details. --->
Microsoft.Azure.ActiveDirectory.Client.Framework.ProcessExecutionFailedException:
Error installing msi package 'Synchronization Service.msi'. Full log is available at
'C:\ProgramData\AADConnect\Synchronization Service_Install-DateTime.log'.

Action startTime: DetectServiceAccount.

CustomAction DetectServiceAccount
returned actual error code 1603 (note this may not be 100% accurate if translation
happened inside sandbox)
Action endedTime: DetectServiceAccount. Return value 3.
Action endedTime: INSTALL. Return value 3.
MSI (s) (14:AC)Time: Note: 1: 1708
MSI
(s) (14:AC)Time: Product: Microsoft Azure AD Connect synchronization services --
Installation operation failed.
MSI (s) (14:AC)Time: Windows Installer installed the
product. Product Name: Microsoft Azure AD Connect synchronization services.
Product Version: 1.1.614.0. Product Language: 1033. Manufacturer: Microsoft
Corporation. Installation success or error status: 1603.
MSI (s) (14:AC)Time: Deferring
clean up of packages/files, if any exist
MSI (s) (14:AC)Time: MainEngineThread is
returning 1603
MSI (s) (14:80)Time: RESTART MANAGER: Session closed.
Cause
The underlying service account was configured by using the user principal name (UPN)
instead of Domain\SamAccountName.

Resolution
To resolve this issue, follow these steps:

1. Start the Service Console on the Azure AD Connect server.

2. Locate the Microsoft Azure AD Sync  service, and then right-click the service.
3. Select Properties, and then select Logons.
4. Set the account by using Domain\SamAccountName instead of using the UPN.
5. Select Apply and OK.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Error: 80070005 when you run the Azure
Active Directory Sync Services config
wizard
Article • 04/20/2022 • 2 minutes to read

Original product version:   Azure Active Directory, Microsoft Intune, Azure Backup, Office
365 Identity Management

Original KB number:   2988408

Symptoms
When you run the Azure Active Directory Sync (AAD Sync) Services config wizard, you
receive the following message:

Retrieving the COM class factory for remote component with CSLID {...} from
machine ... failed due to the following error: 80070005

Cause
This issue may occur if you're not a member of the ADSyncAdmins group on the local
computer or if you have just installed AAD Sync Services.

Resolution
To resolve this issue, sign out and then sign in to the computer. If the issue persists,
follow these steps:

1. Select Start, type compmgmt.msc in the search box, and then press Enter to open
Computer Management.
2. Under Computer Management, expand Local Users and Groups, and then expand
Groups.
3. Make sure that the ADSyncAdmins group exists. If this group is missing, create a
new group, and name it ADSyncAdmins.
4. Add yourself to the ADSyncAdmins group.
5. Sign out, and then sign in to the computer again.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Table-valued parameter errors after
Azure AD Connect is installed on
Windows Server 2019
Article • 04/20/2022 • 2 minutes to read

This article describes a problem in which synchronization errors appear after Microsoft
Azure AD Connect is installed on Windows Server 2019-based servers.

Original product version:  Azure Active Directory, Windows Server 2019

Symptoms
You experience one or more of various symptoms, such as password hash sync failures
or receiving "staging-error" discovery errors during the import cycle (shown in the
following screenshot).

When this problem occurs, Event ID 6301 is logged in the server Application log, as
follows:

Log Name: Application

Source: ADSync

Date: 8/22/2019 11:11:17 PM

 Event ID: 6301

Task Category: Server

Level: Error

Keywords: Classic

User: N/A

Computer: AADConnect.contoso.com

Description: The server encountered an unexpected error in the synchronization

engine:

"BAIL: MMS(7996): ..\sql.cpp(7524): 0x80004005 >

(Unspecified error)

** BAIL: MMS(7996): x:\bt\1011518\repo\src\dev\sync\server\sqlstore\rcvtvp.h(158):

0x80004005 (Unspecified error) **

** BAIL: MMS(7996): x:\bt\1011518\repo\src\dev\sync\server\sqlstore\rcvtvp.h(52):

0x80004005 (Unspecified error) **

BAIL: MMS(7996): ..\sproc.cpp(1124): 0x80004005 (Unspecified error)

BAIL: MMS(7996): ..\csobj.cpp(15789): 0x80004005 (Unspecified error)

BAIL: MMS(7996): ..\tower.cpp(10511): 0x80004005 (Unspecified error)

BAIL: MMS(7996): x:\bt\1011518\repo\src\dev\sync\server\sqlstore\csobj.h(1379):

0x80004005 (Unspecified error)

BAIL: MMS(7996): ..\csobj.cpp(1368): 0x80004005 (Unspecified error)

BAIL: MMS(7996): ..\nscsimp.cpp(531): 0x80004005 (Unspecified error)

BAIL: MMS(7996): ..\syncstage.cpp(923): 0x80004005 (Unspecified error)

BAIL: MMS(7996): ..\syncstage.cpp(1666): 0x80004005 (Unspecified error)

BAIL: MMS(7996): ..\syncstage.cpp(414): 0x80004005 (Unspecified error)

Azure AD Sync 1.5.45.0"

This event indicates that an error occurs when Azure AD Connect attempts a read or
write operation over the LocalDB database by using table-valued parameters.

For more information about table-valued parameters, see Use Table-Valued Parameters
(Database Engine).

Cause
This problem is caused by incompatible language settings for programs that do not
support Unicode.
The service account defaults to UTF-8 for worldwide language support when it is
enabled. The LocalDB database version in Windows Server 2019 does not support this
format.

Resolution
To resolve this problem, clear the checkbox next to Beta: Use Unicode UTF-8 for
worldwide language support (shown in the previous screenshot), and then restart the
server.

To change the setting, follow these steps:

1. On the Azure AD Connect server, open Control Panel, and then select Clock,
Language and Region.
2. Select Region.

3. Select the Administrative tab, and then select Change System locale.
4. If the Use Unicode UTF-8 for worldwide language support setting is enabled,
clear it.
 5. Select OK, and then restart the server.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Error when you run the Azure Active
Directory Sync tool configuration
wizard: Failed to get address for
method: CreateIdentityHandle2
Article • 04/20/2022 • 2 minutes to read

Original product version:   Cloud Services (Web roles/Worker roles), Azure Active
Directory, Microsoft Intune, Azure Backup, Office 365 Identity Management

Original KB number:   3037953

Symptoms
When you run the Microsoft Azure Active Directory Sync tool configuration wizard, you
receive the following error message:

Failed to get address for method: CreateIdentityHandle2 from library C:\Program

Files\Common Files\Microsoft Shared\Microsoft Online Services\msoidcli.dll.
GetLastError code: 127

Cause
This problem occurs if you're running an earlier version of the Microsoft Online Services
Sign-in Assistant.

Resolution
To resolve this issue, follow these steps:

1. Uninstall any versions of the Microsoft Online Services Sign-in Assistant that are
currently installed on the directory synchronization computer.
2. Install the latest version of the Microsoft Online Services Sign-In Assistant from
Microsoft Online Services Sign-In Assistant for IT Professionals RTW .

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Error when you try to install Azure
Active Directory Module for Windows
PowerShell: You must have Windows
PowerShell 2.0 or greater installed
Article • 04/20/2022 • 2 minutes to read

This article describes an issue in which you can't install Azure Active Directory Module
for Windows PowerShell. It provides a resolution.

Original product version:   Azure Active Directory, Office 365 User and Domain
Management, Office 365 Identity Management

Original KB number:   2913017

Symptoms
When you try to install Azure Active Directory Module for Windows PowerShell, you
receive the following error message:

In order to install Windows Azure Active Directory Module for PowerShell, you must
have Windows PowerShell 2.0 or greater installed on this computer.

Resolution
To resolve this issue, try one of the following methods. If one doesn't work for you, try
another one.

Method 1: Install Azure Active Directory Module for

Windows PowerShell when you log on as local admin
1. Log on as a local admin. (Just logging on as a domain admin may not work.)
2. Install Azure Active Directory Module for PowerShell.

Method 2: Make sure that Windows PowerShell 2.0 is

enabled
1. Log on as a local admin. (Just logging on as a domain admin may not work.)
 2. In Control Panel, select Programs and Features, or select Uninstall a program
under Programs.
3. Select Turn Window features on or off.
4. In the Windows Feature window, make sure that the Windows PowerShell 2.0
checkbox is selected, and then select OK.
5. Install Azure Active Directory Module for PowerShell.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Changes to domain-based filtering in
Synchronization Service Manager fail to
sync
Article • 04/20/2022 • 2 minutes to read

This article describes an issue in which changes to domain-based filtering in the Active
Directory management agent or the Active Directory Connector fail to sync.

Original product version:   Azure Active Directory, Cloud Services (Web roles/Worker
roles), Microsoft Intune, Azure Backup, Office 365 Identity Management

Original KB number:   2998261

Symptoms
After you make a change to domain-based filtering in the Active Directory management
agent or the Active Directory Connector, the run profile action fails to sync. In this
situation, you receive the following error message:

missing-partition-for-run-step

Additionally, an instance of event ID 6020 is logged in Event Viewer:

Source: FIMSynchronization

Event ID: 6020

Description:

The management agent "Active Directory Connector" failed on run profile "Delta
Sync" because a partition specified in the configuration could not be located.

User Action

Refresh and verify the partition configuration for the management agent and the
target partition.

Cause
This issue may occur if the run profile isn't updated.

Resolution
If you're removing a domain from the sync process
1. In Synchronization Service Manager, select the Management Agents tab or the
Connectors tab.
2. Right-click the management agent or the Connector type for Active Directory
Domain Services, and then select Configure Run Profiles.
3. Look for the step that has a Partition value that contains a string of alphanumeric
characters (for example, {B3C9A66A-4C9C-457A-97B9-A0107037A416}), and then
select Delete Step.
4. Select Apply, and then select OK.
5. Repeat steps 3-4 for each run profile.
6. Right-click the same management agent or Connector again, and then select Run.
7. Select Full Sync, and then select OK.

If you're adding a domain to be synced

1. In Synchronization Service Manager, select the Management Agents tab or the
Connectors tab.
2. Right-click the management agent or the Connector type for Active Directory
Domain Services, and then select Configure Run Profiles.
3. In the navigation pane (on the left), select a Management Agent run profile.
4. Select New Step.
5. Under Type, select the option that resembles the run profile that you selected in
step 3, and then select Next.
6. Under Partition, select the domain that you want to add, and then select Finish.
7. Repeat steps 3-6 for each run profile.
8. Right-click the same management agent or Connector again, and then select Run.
9. Select Full Sync, and then select OK.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
High CPU usage in Azure AD Connect
Health for Sync
Article • 04/20/2022 • 2 minutes to read

This article provides information about resolving an issue in which high CPU usage
occurs in Azure Active Directory Connect Health for Sync.

Original product version:   Azure Active Directory

Original KB number:   4346822

Symptoms
You experience slow performance and high CPU usage (up to 100 percent) on a
computer that runs the Azure Active Directory (Azure AD) Connect Health for Sync
monitoring agent. In Task Manager, you notice that the
Microsoft.Online.Reporting.MonitoringAgent.Startup  process is causing the high CPU
usage.

７ Note

This issue is not limited to any specific Azure AD Connect Health versions or

operating system versions.

Cause
This issue occurs because the June 2018 update for .NET Framework 4.7.2 is installed on
the computer, and the Azure AD Connect Health for Sync monitoring agent does not
fully support this update.

The following .NET Framework update would cause the high CPU issue by the
monitoring agent.

.NET Framework update System version

KB4338420 Windows Server 2008

KB4338606 Windows Server 2008 R2

KB4054542 Windows Server 2012

 .NET Framework update System version

KB4054566 Windows Server 2012 R2

KB4054590 KB4338814 KB4338419 KB4338605 KB4345418 General

Resolution

For Connect Health for AD DS and AD FS

To resolve this issue for Active Directory Domain Services (AD DS) and Active Directory
Federation Services (AD FS), install the new Azure AD Connect Health agent version,
3.1.7.0, that was released in July 2018. The agent can be downloaded from Connect
Health public documentation.

For Azure AD Connect

To resolve this issue for Azure AD Connect, install the latest version of Azure AD
Connect .

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Error when Azure AD Connect cannot
authenticate to Azure AD: Unable to
communicate with the Windows Azure
Active Directory service
Article • 04/20/2022 • 2 minutes to read

This article provides information about troubleshooting a problem in which your identity
sync client cannot authenticate to Microsoft Azure Active Directory if there is an
unauthenticated proxy server.

Original product version:   Azure Active Directory

Original KB number:   3013032

Symptoms
If your environment includes an unauthenticated proxy server, your identity sync client
may not authenticate to Microsoft Azure Active Directory.

For example, you experience this issue when you use an identity sync client such as
Azure AD Connect, Azure Active Directory Sync Services (Azure AD Sync), or the Azure
Active Directory Sync Tool.

If you're using Azure AD Connect or Azure AD Sync:

The wizard displays the following configuration error message:

Ready to configure.

We have gathered enough information to configure Azure AD Sync and will now
create a default configuration.

Failed even after 5 retries. Action: PingProvisioningServiceEndPoint, Exception:

Unable to communicate with the Windows Azure Active Directory service. Tracking
ID: 01601250-7951-469c-8973-34e2a8e1ca10 See the event log for more details.

When this problem occurs, an "Error 906" entry that resembles the following is logged in
the Azure AD Connect or Azure AD Sync log. This entry indicates that the identity sync
appliance tries to make a direct connection to the Internet.

AzureActiveDirectoryDirectorySyncTool Error: 906 :

System.Management.Automation.CmdletInvocationException: Failed even after 5
 retries. Action: PingProvisioningServiceEndPoint, Exception: Unable to communicate
with the Windows Azure Active Directory service. Tracking ID: 90edf657-f63e-46cc-
94ec-df88817f4c73 See the event log for more details.. --->
Microsoft.IdentityManagement.PowerShell.ObjectModel.SynchronizationConfigurati
onValidationException: Failed even after 5 retries. Action:
PingProvisioningServiceEndPoint, Exception: Unable to communicate with the
Windows Azure Active Directory service. Tracking ID: 90edf657-f63e-46cc-94ec-
df88817f4c73 See the event log for more details..

If you're using the Azure Active Directory Sync Tool:

The following Directory Synchronization event ID 0 is logged in the Application log of

the identify sync client computer:

Log name: Application

Source: Directory Synchronization

Event ID: 0

Task Category: None

Level: Error

Description:

Unable to establish a connection to the authentication service. Contact Technical

Support.0 GetAuthState() failed with -2147186688 state. HResult:0. Contact Technical
Support. (0x80048862)

Additionally, a Network Monitor (Netmon.exe) trace indicates that the Microsoft Online
Services Sign-in Assistant uses the proxy and accesses login.microsoftonline.com .

Cause
This problem occurs because the Microsoft .NET Framework on which your identity sync
appliance is based doesn't recognize your proxy settings.

Resolution
To fix this issue, follow these steps:

1. Open the following file:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config .

2. Add the following text to the end of the file:

 <system.net> <defaultProxy> <proxy usesystemdefault="true"

proxyaddress="http://<PROXYIP>:80" bypassonlocal="true" /> </defaultProxy>

</system.net>

７ Note

In this text, the placeholder <PROXYIP> represents the actual proxy IP

address. For more information about the proxy settings in this context, see
Element (Network Settings).

More information
For more information, see Error on .NET client that consumes a web service through an
HTTP proxy server .

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Error (LogonUser() Failed with error
code: 1789) after you enter enterprise
administrator credentials in the Azure
Active Directory Sync tool Configuration
Wizard
Article • 04/20/2022 • 2 minutes to read

Original product version:   Cloud Services (Web roles/Worker roles), Azure Active
Directory, Microsoft Intune, Azure Backup, Office 365 Identity Management

Original KB number:   2508225

Symptoms
After you enter your enterprise admin credentials in the Microsoft Azure Active
Directory Sync Tool Configuration Wizard, you receive the following error message:

LogonUser() Failed with error code: 1789

Cause
This issue typically occurs when the computer on which you're running the Directory
Sync tool can't authenticate with Active Directory.

Resolution
To resolve this issue, use one or more of the following methods:

Restart the computer.

Join the computer to a workgroup and then join the computer back to the domain.

1. Select Start, right-click Computer, and then select Properties.

2. Under Computer name, domain, and workgroup settings, select Change
Settings.
3. Select the Computer Name tab, and then select Change.
4. Select the Workgroup option, and then type a workgroup in the Workgroup
dialog box.
5. Restart the computer.
 6. Repeat steps 1 through 3.
7. Select the Domain option, and then type the domain name in the Domain
dialog box to add the computer back to the domain.
8. Restart the computer.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Resolve Model database corruption in
SQLLocalDB
Article • 07/23/2022 • 3 minutes to read

This article describes a known issue in the SQLLocalDB utility that can prevent the
ADSync service from starting because of a corrupted Model database. This issue mainly
affects Azure Active Directory (Azure AD) Connect 2.x servers that run on a Microsoft
SQL Server 2019 LocalDB.

The issue is caused by a bug in the SQL Server backup logic that creates an inconsistent
state in the SQL Server Model database start page. After a backup occurs, the Model
database is set to FULL recovery mode ( dbi_status == 0x40010000), and the
dbi_dbbackupLSN (the log sequence number (LSN) for the database backup) is set to a

value that points to a log file. However, the actual recovery mode that is governed by
the Master database is SIMPLE .

In SIMPLE recovery mode, database logs are truncated automatically. In FULL recovery
mode, logs are truncated only after a backup. When SQLLocalDB is restarted after the
log file is truncated, it detects a backup LSN that's earlier than the earliest log file.
Therefore, it won't start the service.

Review the guidance in the next sections to learn how to do the following tasks:

Correctly identify whether the Azure AD Connect service (ADSync) doesn't start
because of Model database corruption.

Mitigate the issue by recovering the Model database from a corrupted state.

Apply a permanent fix to make sure that this Model database corruption doesn't
occur again.

Symptoms
You can verify that the issue is based on the following events in the Azure AD Connect
server:

Event Viewer: Application, EventID 528, Source: SQLLocalDB 15.0

Output
 WaitForMultipleObjects

575

{Application Error}

The application was unable to start correctly (0x%lx). Click OK to

close the application.

3714

Event Viewer: Application, EventIDs 2005 and 6226, Source: ADSync

Output

0x8023044a

OriginalError=0x80004005 OLEDB Provider error(s):

Description = 'Login timeout expired'

Failure Code = 0x80004005

SQLLocalDB error.log file in <ADSync service profile

path>\AppData\Local\Microsoft\Microsoft SQL Server Local
DB\Instances\ADSync2019

Output

<yyyy-MM-dd HH:mm:ss.##> spid14s The resource database build

version is 15.00.4138. This is an informational message only. No user
action is required.

<yyyy-MM-dd HH:mm:ss.##> spid8s Starting up database 'msdb'.

<yyyy-MM-dd HH:mm:ss.##> spid14s Starting up database 'model'.

<yyyy-MM-dd HH:mm:ss.##> spid14s Error: 9003, Severity: 20, State:

1.

<yyyy-MM-dd HH:mm:ss.##> spid14s The log scan number (41:488:1)

passed to log scan in database 'model' is not valid. This error may
indicate data corruption or that the log file (.ldf) does not match the
data file (.mdf). If this error occurred during replication, re-create
the publication. Otherwise, restore from backup if the problem results
in a failure during startup.

<yyyy-MM-dd HH:mm:ss.##> spid14s SQL Trace was stopped due to

server shutdown. Trace ID = '1'. This is an informational message only;
no user action is required.

Mitigation

） Important

Only apply the mitigation steps that are described here if all of these conditions
occur:
 The version of Azure AD Connect is 2.0.x.x.

Azure AD Connect is installed with SQL LocalDB.

All of the conditions that are listed in Symptoms are present.

To recover the Model database from a corrupted state, follow these steps:

1. Go to one of the following ADSync Service profile locations, depending on the

service account that's running (such as a domain account, virtual service account,
or managed service account):

C:\Users\<service account>\
C:\Users\ADSyncMSAxxxx$\
C:\Windows\ServiceProfiles\ADSync\

2. Open the error.log file from the ADSync2019 instance folder in the following
directory path:

<service profile path>\AppData\Local\Microsoft\Microsoft SQL Server Local

DB\Instances\ADSync2019\

3. Find the following error entry in the log to verify that the Model database is
corrupted:

Output

<yyyy-MM-dd HH:mm:ss.##> spid14s Error: 9003, Severity: 20, State:

1.

<yyyy-MM-dd HH:mm:ss.##> spid14s The log scan number (41:488:1)

passed to log scan in database 'model' is not valid. This error may
indicate data corruption or that the log file (.ldf) does not match the
data file (.mdf). If this error occurred during replication, re-create
the publication. Otherwise, restore from backup if the problem results
in a failure during startup.

4. If error "9003" exists in this entry, rename the model.mdf and modellog.ldf files in
this folder to old_model.mdf and old_modellog.ldf, respectively.

5. Open the SQL Templates folder at C:\Program Files\Microsoft SQL

Server\150\LocalDB\Binn\Templates.

6. Copy the model.mdf and modellog.ldf files to the ADSync2019 instance folder from
step 2.

7. Start the ADSync service.

Solution
Microsoft has introduced a fix for this issue in Azure AD Connect version 2.1.1.0. If the
sync service (ADSync) can't be started, you need to apply the steps in the Mitigation
section before you can upgrade Azure AD Connect.

To prevent the corruption issues in the SQLLocalDB Model database, install the latest
Azure AD Connect build, which is available at Azure AD Connect: Version release history.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Error when you try to install the Azure
Active Directory Sync Tool: The
computer must be joined to a domain
Article • 04/20/2022 • 2 minutes to read

Original product version:   Cloud Services (Web roles/Worker roles), Azure Active
Directory, Microsoft Intune, Azure Backup, Office 365 Identity Management

Original KB number:   2419250

Symptoms
When you try to install the Microsoft Azure Active Directory Sync Tool, you may receive
the following error message:

The computer must be joined to a domain.

Cause
This issue may occur if the computer isn't joined to an Active Directory Domain Services
(AD DS) domain or if the computer doesn't register a host (A) resource record with its
Domain Name System (DNS).

Resolution
To resolve this issue, use one of the following methods.

Method 1: Computer isn't joined to an AD DS domain

Join the computer to an AD DS domain. To do this, follow these steps:

1. On the computer that you want to join to a domain, select Start, select Control
Panel, and then double-click System.
2. Under Computer name, domain, and workgroup settings, select Change settings.
3. On the Computer Name tab, select Change.
4. Under Member of, select Domain, type the name of the domain that this
computer will join, and then select OK.
5. Select OK, and then restart the computer.
Method 2: Computer is already joined to an AD DS
domain
If the computer is already joined to an AD DS domain, make sure that the computer's
DNS settings are correct and that a host (A) resource record for the computer is
registered with DNS. To do this, follow these steps:

1. Open Network Connections.

2. Right-click the network connection that you want to set up, and then select
Properties.

3. Do one of the following, as appropriate for the connection that you want to set up:

For a local area connection: On the General tab, select Internet Protocol
(TCP/IP), and then select Properties.
For all other connections: On the Networking tab, select Internet Protocol
(TCP/IP), and then select Properties.

4. If you want to obtain DNS server addresses from a Dynamic Host Configuration
Protocol (DHCP) server, select Obtain DNS server address automatically.

5. If you want to configure DNS server addresses manually, select Use the following
DNS server addresses. In the Preferred DNS server box, type the IP addresses of
the preferred DNS server. In the Alternate DNS server box, type the IP addresses
of the alternative DNS server.

6. Select OK two times, and then close Network Connections.

7. At a command prompt, type the following commands, and press ENTER after each
command:

Console

ipconfig /flushdns

Console

ipconfig /registerdns

8. If the issue isn't resolved, restart the computer that has Directory Sync Tool
installed.
 9. If the issue still isn't resolved, make sure that the computer that has the Directory
Sync Tool is installed can communicate with the computer that's running AD DS.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Number added to user names and email
addresses when users are synced to
Azure AD
Article • 04/20/2022 • 2 minutes to read

This article provides information about troubleshooting an issue in which a number is

added to user names and email addresses when users are synced to Azure AD. This
issue occurs if there are duplicate user principal names (UPN).

Original product version:   Azure Active Directory

Original KB number:   3166795

Symptoms
When users are synced to Azure Active Directory (Azure AD), a number is added to their
UPN and SMTP proxy address. For example: john1234@contoso.onmicrosoft.com .

７ Note

When users are created in Azure AD, their user principal name (UPN) will also be
used as one of the SMTP proxy addresses. Therefore, the SMTP proxy address will
also contain the number.

Additionally, you may see one of the following messages:

In the Office 365 portal:

There is an error on one or more user accounts. To see which users are affected and
the detailed error message, select the "users with errors" view, and then click the
user's display name.

[DIRSYNC ERROR]: This User has been synced to your Azure Active Directory, but we
had to modify the UserPrincipalName property from john@contoso.com to
john1234@contoso.onmicrosoft .com because an existing user, john@contoso.com , was

already created with this value. john@contoso.com to

john1234@contoso.onmicrosoft.com because an existing user, john@contoso.com , was

already created with this value.

From an email report:

This object has been updated in your Azure Active Directory, but with some
modified properties, because the following attributes are associated with another
object [ProxyAddresses SMTP: john@contoso.com ;].

This object has been updated in your Azure Active Directory, but with some
modified properties, because the following attributes are associated with another
object [UserPrincipalName john@contoso.com ;].

This issue occurs if another object has the same UPN.

Resolution
To resolve this issue, find the users who have duplicate UPNs, and then change the
UPNs so that they are unique. To do this, follow these steps.

Step 1: Check your local directory

Use the IdFix DirSync Error Remediation Tool to identify duplicate or invalid attributes.

To resolve duplicate attributes by using the IdFix Tool, see "Duplicate" is displayed in the
ERROR column .

For more information about the IdFix tool, go to IdFix DirSync Error Remediation Tool .

Step 2: Check Azure AD

You can use the Office 365 portal or the Azure Active Directory Module for Windows
PowerShell to check Azure AD for duplicate attributes.

Method 1: Use the Office 365 portal

1. Sign in to the Office 365 portal as an administrator.

2. In the Microsoft 365 admin center, go to Users, and then select Active users.

A warning at the top of the page is displayed if there are duplicate attribute
conflicts on any object in your organization.
 3. Select an object to view details about the conflict. This information is displayed in
the lower-right corner of the page.

4. Change the user name so that it's unique.

Method 2: Use the Azure AD Module for Windows PowerShell

To learn more about how to use the Azure AD Module for Windows PowerShell to
identify objects that have duplicate values, see Identity synchronization and duplicate
attribute resiliency.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
An error displays in a directory
synchronization report: This company
has exceeded the number of objects
that can be synchronized
Article • 04/20/2022 • 5 minutes to read

This article describes how to increase the Active Directory directory service quota for
directory synchronization in an Office 365, Azure, or Microsoft Intune environment.

Original product version:   Cloud Services (Web roles/Worker roles), Azure Active
Directory, Microsoft Intune, Azure Backup, Office 365 User and Domain Management

Original KB number:   2812409

Symptoms
You receive an email message from MSOnlineServicesTeam@MicrosoftOnline.com that
contains the following error message:

Error 016: Synchronization has been stopped. This company has exceeded the
number of objects that can be synchronized. Contact Microsoft Online Services
Support.

７ Note

This article can also be used if you just want to request to increase the directory
service quota in case you're planning to have more than the allowed number of
objects in a Microsoft cloud service such as Office 365, Azure, or Microsoft Intune,
and you don't use Active Directory synchronization. The current directory service
quota in Azure Active Directory (Azure AD) is 50,000 objects.

Cause
This issue occurs because the number of objects that you created in your Azure AD
exceed your directory service limit. Azure AD limits how many objects can be created by
each organization. Groups, contacts, and user objects in your Azure AD organization are
counted as part of your organization's directory usage.
Your default directory service quota is calculated according to the following guidelines:

If you don't have any verified domains, the current directory service quota in Azure
AD is 50,000 objects.

1. If your organization was created before October 5, 2011, your default

directory service quota is 10,000 objects.
2. If your organization was created after October 5, 2011 and before May 2012,
your default directory service quota is 20,000 objects.
3. If your organization was created after May 2012, your default directory
service quota is 50,000 objects.

If you have at least one verified domain, the default directory service quota in
Azure AD is 300,000 objects.

Resolution
When the number of groups, contacts, and user objects in your on-premises Active
Directory exceed your directory service quota, you can request an increase to the
directory service quota limitation for your company. This increase lets you sync more
objects than the current default limit when you use directory synchronization.

To continue to create objects in your organization, you must either add a domain or
request an increase to your directory service quota. To do this, use the following
methods.

Method 1
If you don't have a verified domain, you must add a domain to increase your quota limit
to 300,000 objects. For more information, see Add your domain .

Method 2
If you have more than 300,000 objects in your on-premises Active Directory directory
service, to increase the number of objects that can be synced beyond 300,000, contact
Microsoft Support.

More information
A directory service quota is implemented by using the cloud service as a method to limit
the maximum number of objects that can be created and owned by a single security
principal. All objects that are synced by using directory synchronization to a company
have the creator/owner value set to the default admins group for that company. For
example, the admins group is set as follows: admins@contoso1.microsoftonline.com .
Therefore, this configuration prevents users from creating an unlimited number of
objects by using directory synchronization. If a company has a legitimate need to sync
more than the directory service quota limit, submit a service request to technical
support.

Frequently asked questions

Question 1: Do objects that were manually added through the cloud service portal or
through the cloud service API, such as Exchange Online PowerShell, count against my
online company quota?

Answer 1: Yes.

Question 2: Do deleted objects count against my online company quota?

Answer 2: Yes. When a cloud service customer deletes an object from an online
company, the deleted object is put into a deleted objects container in the directory
service. The object remains in the deleted objects container until the tombstone lifetime
expires. The expiration is currently set to 30 days.

For example, consider the following scenario. An online company is evaluating a cloud
service by using a nonproduction on-premises Active Directory environment. The cloud
service organization was created before October 5, 2011, and the default sync limit is
10,000 objects. The company performs a bulk sync of 8,000 group objects and contact
objects by using the Directory Sync tool. Later, the online company decides to do the
following:

1. Delete those group objects and contact objects from the company's on-premises
nonproduction Active Directory DS environment.
2. Add 8,000 user objects to its on-premises nonproduction Active Directory DS
environment.
3. Sync the updates to its online company.

The 8,000 group objects and contact objects are moved to the deleted objects container
in the directory service. And these objects continue to consume up to 25 percent of the
online company quota until they are permanently removed after the 30-day tombstone
period. (This percentage is equal to 2,000 objects, or 8,000 × 25 percent.) Therefore,
after syncing the 5,000 new user objects, the online company will consume 10,000
objects of its available Active Directory quota, 2,000 from deleted objects plus 8,000
from new user objects. During the 30-day tombstone period (and this period may
coincide with the online company evaluation period), the online company may be
unable to add any additional objects by using directory synchronization. This condition
occurs because the online company's directory service quota has been reached.

In this scenario, the online company that's performing the evaluation of the cloud
service must reduce the number of objects in its nonproduction on-premises Active
Directory DS environment to complete the product evaluation. However, if the online
company can't reduce the number of objects, the company must request an increase in
its directory service quota.

Question 3: Does having more than one verified domain mean that I can have a quota
that's higher than 300,000 objects?

Answer 3: No. You're granted a directory quota of 300,000 objects if you have one or
more verified domains. You're not granted a quota of 300,000 objects for each verified
domain that you register.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Object deletions aren't synchronized to
Azure AD when using the Azure Active
Directory Sync tool
Article • 04/20/2022 • 2 minutes to read

Original product version:   Cloud Services (Web roles/Worker roles), Azure Active
Directory, Microsoft Intune, Azure Backup, Office 365 Identity Management

Original KB number:   2709902

Symptoms
Consider the following scenario:

You have an on-premises Active Directory object.

Directory synchronization is used to sync the Active Directory object to Microsoft
Azure Active Directory (Azure AD). It creates a linked object.
You delete the on-premises Active Directory object.

In this scenario, the linked object isn't removed from Azure AD.

Cause
This issue may occur if one of the following conditions is true:

Directory synchronization hasn't yet occurred.

Directory synchronization unexpectedly failed to delete a specific cloud object and
results in an orphaned Azure AD object.

Resolution
To fix this issue, follow these steps:

1. Force directory synchronization .

2. Check that directory synchronization occurred correctly. For more information, see
Verify directory synchronization .

3. If sync is working correctly but the Active Directory object deletion is still not
propagated to Azure AD, manually remove the orphaned object. To do so, use one
 of the following cmdlets in Azure Active Directory Module for Windows
PowerShell:

PowerShell

Remove-MsolContact

PowerShell

Remove-MsolGroup

PowerShell

Remove-MsolUser

For example, to manually remove orphaned user ID john.smith@contoso.com that

was originally created by using directory synchronization, you would run the
following cmdlet:

PowerShell

Remove-MsolUser -UserPrincipalName John.Smith@Contoso.com

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
One or more objects don't sync when using
Azure Active Directory Sync tool
Article • 07/11/2022 • 10 minutes to read

This article resolves an issue that one or more Active Directory Domain Services (AD DS) object
attributes don't sync to Azure Active Directory (Azure AD) through the Azure Active Directory Sync tool.

Original product version:   Cloud Services (Web roles/Worker roles), Azure Active Directory, Microsoft
Intune, Azure Backup, Office 365 Identity Management

Original KB number:   2643629

Symptoms
One or more AD DS objects or attributes don't sync to Microsoft Azure AD as expected. When Active
Directory synchronization runs, an object doesn't sync, and you experience one of the following
symptoms:

You receive an error message that states that an attribute has a duplicate value.
You receive an error message that states that one or more attributes violate formatting
requirements such as character set or character length.
You don't receive an error message, and directory synchronization seems to be completed.
However, some objects or attributes aren't updated as expected.

Some examples of the error message that you may receive:

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.

Cause
This issue occurs for one of the following reasons:

The domain value that's used by AD DS attributes hasn't been verified.

One or more object attributes that require a unique value have a duplicate attribute value (such as
the proxyAddresses attribute or the U serPrincipalName attribute) in an existing user account.

One or more object attributes violate formatting requirements that restrict the characters and the
character length of attribute values.

One or more object attributes match exclusion rules for directory synchronization.
 The following table shows the default sync scoping rules:

Object type Attribute name Condition of attribute when

synchronization fails

Contact DisplayName Contains "MSOL"

msExchHideFromAddressLists Is set to "True"

Security-enabled group isCriticalSystemObject Is set to "True"

Mail-enabled groups
proxyAddresses
Has no "SMTP:" address entry

(security group or distribution

list) and
and

mail is not present

Mail-enabled contacts proxyAddresses

Has no "SMTP:" address entry

and
and

mail is not present

iNetOrgPerson sAMAccountName Is not present

isCriticalSystemObject Is present

User mailNickName Starts with "SystemMailbox"

mailNickName Starts with "CAS_"

and

contains "}"

sAMAccountName Starts with "CAS_"

and

contains "}"

sAMAccountName Equals "SUPPORT_388945a0"

sAMAccountName Equals "MSOL_AD_Sync"

sAMAccountName Is not present

isCriticalSystemObject Is set to "True"

The user principal name (UPN) was changed after the initial synchronization and must be updated
manually.

Exchange Online Simple Mail Transfer Protocol (SMTP) addresses of synced users aren't populated
appropriately in the on-premises Active Directory schema.

Resolution
To resolve this issue, use one of the following methods, as appropriate for your situation.

Run IdFix to check for duplicates, missing attributes, and rule

violations
Use the IdFix DirSync Error Remediation Tool to find objects and errors that prevent synchronization
to Azure AD.

If you see "Blank" in the ERROR column after you run IdFix, the displayName attribute of the
object isn't defined. To resolve this issue, specify a value for the displayName attribute of the
object using these steps:

1. In the UPDATE column for the object, type the name of its displayName attribute.
2. In the ACTION column, click EDIT, and then click Apply.
3. Repeat steps 1 and 2 for each object that has a "blank" entry in the ERROR column.
4. Run IdFix again to look for more object errors.

If you see "Duplicate" in the ERROR column after you run IdFix, two or more objects have the
same email address. To resolve this problem, specify a unique email address for the object using
these steps:

1. In the UPDATE column for the object, type an email address that isn't already used.
2. In the ACTION column, click EDIT, and then click Apply.
3. Run IdFix again to look for more object errors.

Determine attribute conflicts that are caused by objects that

weren't created in Azure AD through directory synchronization
To determine attribute conflicts caused by user objects that were created by using management tools
(and that weren't created in Azure AD through directory synchronization), follow these steps:

1. Determine the unique attributes of the on-premises AD DS user account. To do it, on a computer
that has Windows Support Tools installed, follow these steps:

a. Select Start, select Run, type ldp.exe, and then select OK.

b. Select Connection, select Connect, type the computer name of an AD DS domain controller,
and then select OK.

c. Select Connection, select Bind, and then select OK.

d. Select View, select Tree View, select the AD DS domain in the BaseDN drop-down list, and
then select OK.

e. In the navigation pane, locate and then double-click the object that isn't syncing correctly. The
Details pane on the right side of the window lists all object attributes. The following example
shows the object attributes:
f. Record the values of the userPrincipalName attribute and each SMTP address in the multivalue
proxyAddresses attribute. You'll need these values later.

Attribute name Example Notes

 Attribute name Example Notes

proxyAddresses proxyAddresses (3): x500:/o=Exchange/ou=Exchange Administrative Group

(FYDIBOHF23SPDLT)/cn=Recipients/cn=1ae75fca0d3a4303802cea9ca50fcd4f- 1. The
7628376; smtp: 7628376@service.contoso.com ; SMTP: 7628376@contoso.com ; number
that's
displayed in
parentheses
next to the
attribute
label
indicates
the number
of proxy
address
values in
the
multivalue
attribute.

2. Each
distinct
proxy
address
value is
indicated
by a
semicolon
(;).

3. The
primary
SMTP proxy
address
value is
indicated
by
uppercase
"SMTP:"

userPrincipalName 7628376@contoso.com

７ Note

Ldp.exe is included in Windows Server 2008 and in the Windows Server 2003 Support
Tools. The Windows Server 2003 Support Tools are included in the Windows Server 2003
installation media. Or, to obtain the Support Tools, go to the following Microsoft website:
Windows Server 2003 Service Pack 2 32-bit Support Tools

2. Connect to Azure AD by using the Azure Active Directory Module for Windows PowerShell. For
more info, go to Manage Azure AD using Windows PowerShell.

Leave the console window open. You'll need to use it in the next step.
 3. Check for the duplicate userPrincipalName attributes.

In the console connection that you opened in step 2, type the following commands in the order in
which they are presented. Press Enter after each command:

PowerShell

$userUPN = "<search UPN>"

７ Note

In this command, the placeholder "<search UPN>" represents the UserPrincipalName

attribute that you recorded in step 1f.

PowerShell

Get-MSOLUser -UserPrincipalName $userUPN | where {$_.LastDirSyncTime -eq $null}

Leave the console window open. You'll use it again in the next step.

4. Check for duplicate proxyAddresses attributes. In the console connection that you opened in step
2, run the following command:

PowerShell

Import-Module ExchangeOnlineManagement

5. For each proxy address entry that you recorded in step 1f, type the following commands in the
order in which they are presented. Press Enter after each command:

PowerShell

$proxyAddress = "<search proxyAddress>"

７ Note

In this command, the placeholder "<search proxyAddress>" represents the value of a

proxyAddresses attribute that you recorded in step 1f.

PowerShell

Get-EXOMailbox | where {[string] $str = ($_.EmailAddresses);

$str.tolower().Contains($proxyAddress.tolower()) -eq $true} | foreach {get-MSOLUser -
UserPrincipalName $_.MicrosoftOnlineServicesID | where {($_.LastDirSyncTime -eq
$null)}}

Items that are returned after you run the commands in step 3 and 4 represent user objects that weren't
created through directory synchronization and that have attributes that conflict with the object that
isn't syncing correctly.

Update AD DS attributes to remove duplicates, rules violations, and

scoping exclusions
Identify the specific attributes that are preventing synchronization based on the following information:

Administrative email messages

The report from the output of the Office 365 Deployment Readiness Tool
Default directory synchronization scoping rules and custom rules

After a specific attribute value is identified, edit the attribute value using one of these methods:

Use the Active Directory Users and Computers tool to edit the attribute value.

1. Open Active Directory Users and Computers, and then select the root node of the AD DS domain.
2. Select View, and then make sure that the Advanced Features option is selected.
3. In the left navigation pane, locate the user object, right-click it, and then select Properties.
4. On the Object Editor tab, locate the attribute that you want. Select Edit, and then edit the
attribute value to the value that you want.
5. Select OK two times.

Use Active Directory Service Interfaces (ADSI) Edit to update object attributes in AD DS.
You can
download and install ADSI Edit as a part of the Windows Server Toolkit. To use ADSI Edit to edit
attributes, follow these steps.

２ Warning

This procedure requires ADSI Edit. Using ADSI Edit incorrectly can cause serious problems that
may require you to reinstall your operating system. Microsoft cannot guarantee that problems that
result from the incorrect use of ADSI Edit can be resolved. Use ADSI Edit at your own risk.

1. Select Start, select Run, type ADSIEdit.msc, and then select OK.
2. Right-click ADSI Edit in the navigation pane, select Connect to, and then select OK to load the
domain partition.
3. Locate the user object, right-click it, and then select Properties.
4. In the Attributes list, locate the attribute that you want. Select Edit, and then edit the attribute
value to the value that you want.
5. Select OK two times, and then exit ADSI Edit.

Create a new group and add it to the built-in group that's not
being synced
To resolve the issue in the scenario that some built-in groups (such as the Domain Users group) aren't
synced, create a new group that contains all the applicable members and appropriate permissions of
the built-in group. Then, add that group as a member to the built-in group that's not synced. Use the
new group instead of the built-in group to manage members. By using this method, you still manage
only one group.
You don't want to change the attributes of the built-in group or change the scoping rules of the
identity sync appliance to allow critical system objects to be synced. It may trigger other unexpected
behavior.

Use SMTP matching to cause an on-premises user object to sync to

an existing user object
For more information, see How to use SMTP matching to match on-premises user accounts to Office
365 user accounts for directory synchronization .

Manually update a user account UPN

To update a user account UPN that was licensed after initial directory synchronization has occurred,
follow these steps:

1. Install Azure Active Directory V2 PowerShell Module. For more information, see Azure Active
Directory V2 PowerShell Module .

2. Run the following cmdlets at the Azure Active Directory V2 PowerShell prompt:

PowerShell

$cred = get-credential

７ Note

When you're prompted, enter your admin credentials.

PowerShell

Connect-AzureAD

PowerShell

Set-AzureADUser -ObjectId [CurrentUPN] -UserPrincipalName [NewUPN]

Update user SMTP addresses by using on-premises Active Directory

attributes
When SMTP attributes aren't synced to Exchange Online in an expected way, you may have to update
the on-premises Active Directory attributes. To update on-premises Active Directory attributes so that
the correct email address displays in Exchange Online, use Resolution 2 to manipulate the attributes in
the following table.

On-premises Active Example On-premises Active Example Exchange Online email addresses
Directory attribute name Directory attribute value
 On-premises Active Example On-premises Active Example Exchange Online email addresses
Directory attribute name Directory attribute value

proxyAddresses SMTP: user1@contoso.com Primary SMTP: user1@contoso.com

Secondary SMTP: user1@contoso.onmicrosoft.com

proxyAddresses smtp: user1@contoso.com Primary SMTP: user1@contoso.onmicrosoft.com

Secondary SMTP: user1@contoso.com

proxyAddresses SMTP: user1@contoso.com

Primary SMTP: user1@contoso.com

smtp: user1@sub.contoso.com Secondary SMTP: user1@sub.contoso.com

Secondary SMTP: user1@contoso.onmicrosoft.com

mail User1@contoso.com Primary SMTP: user1@contoso.com

Secondary SMTP: user1@contoso.onmicrosoft.com

UserPrincipalName User1@contoso.com Primary SMTP: user1@contoso.com

Secondary SMTP: user1@contoso.onmicrosoft.com

The Microsoft Online Email Routing Address (MOERA) entry that's associated with the default domain
(such as user1@contoso.onmicrosoft.com ) is an interpreted value that's based on a user account's alias.
This specialty email address is inextricably linked to each Exchange Online recipient. You can't manage,
delete, or create additional MOERA addresses for any recipient. However, the MOERA address can be
over-ridden as the primary SMTP address by using the attributes in the on-premises Active Directory
user object.

７ Note

The presence of data in the proxyAddresses attribute completely masks data in the mail attribute
for Exchange Online email address population.

７ Note

The presence of data in the proxyAddresses attribute, the mail attribute, or both attributes
completely mask UserPrincipalName data for Exchange Online email address population. The UPN
can be used to manage email addresses. However, an admin can decide to manage the email
address and UPN separately by populating proxyAddresses or mail attributes.

We highly recommend that one of these attributes is used consistently to manage Exchange Online
email addresses for synced users.

More information
The Windows PowerShell commands that are mentioned in this article require the Azure Active
Directory Module for Windows PowerShell. For more information about the Azure Active Directory
Module for Windows PowerShell, see the following article:

Manage Azure AD using Windows PowerShell.

For more information about filtering directory synchronization by attributes, see the following
Microsoft TechNet wiki article:

List of Attributes that are Synced by the Azure Active Directory Sync Tool

Contact us for help

If you have questions or need help, create a support request , or ask Azure community support.
Azure AD Connect Health shows old
information about on-premises Azure
AD Connect server
Article • 08/18/2022 • 3 minutes to read

This article discusses an issue in which Azure AD Connect Health shows outdated
information about the on-premises Azure AD Connect server.

Original product version:   Azure Active Directory

Original KB number:   4053427

Symptoms
Azure AD Connect Health blade no longer shows up-to-date information (for example,
synchronization errors) about the on-premises Azure AD Connect server. In some cases,
the Azure AD Connect Health Insight Service that is running on the Azure AD Connect
server crashes and generates the following Windows Application event:

Log Name: Application

Source: Application Error

Date: 10/19/2017 8:03:19 AM

Event ID: 1000

Task Category: (100)

Level: Error

Keywords: Classic

User: N/A

Computer: XXXXXXX

Description: Faulting application name:

Microsoft.Identity.AadConnect.Health.AadSync.Host.exe, version: 3.0.68.0, time
stamp: 0x5965450e Faulting module name: ntdll.dll, version: 6.3.9600.18696, time
stamp: 0x59153753 Exception code: 0xc0000374 Fault offset: 0x00000000000f1c00
Faulting process id: 0x624 Faulting application start time: 0x01d348d2403fcb09
Faulting application path: C:\Program Files\Microsoft Azure AD Connect Health Sync
Agent\Insights\Microsoft.Identity.AadConnect.Health.AadSync.Host.exe Faulting
module path: C:\Windows\SYSTEM32\ntdll.dll Report Id: 7eb31450-b4c5-11e7-
80cb-005056ba3ca2 Faulting package full name: Faulting package-relative
application ID:
Cause
The issue occurs if there is version mismatch between Azure AD Connect
Synchronization Service and Azure AD Connect Health for Sync applications. This issue
may occur if either component was not successfully upgraded during the last Azure AD
Connect upgrade or auto-upgrade.

To verify that an existing Azure AD Connect server has a version compatibility issue
between the two applications, follow these steps:

1. Get the version of the applications from the Programs item in Control Panel.

2. Compare the version information against the following compatibility table:

Synchronization Service version Compatible Health Agent version

1.1.614.0 (or earlier version) 3.0.68.0 (or earlier version) 3.0.127.0

1.1.647.0 (or later version) 3.0.103.0 3.0.129.0

Resolution
To resolve this issue, use one of the following methods.

Method 1
Manually upgrade your Azure AD Connect server to version 1.1.649.0 or a later version.
During the manual upgrade, both applications will be upgraded to the versions that are
compatible with each other.

For more information about how to upgrade Azure AD Connect server, see the following
Azure article: Azure AD Connect: Upgrade from a previous version to the latest

Method 2
Manually reinstall Health Agent for Sync to a version that is compatible with the
Synchronization Service version that is installed on the Azure AD Connect server. For
example, you have an existing Azure AD Connect server that has Synchronization Service
version 1.1.647.0 and Health Agent for Sync version 3.0.68.0. To resolve the
incompatibility issue, you can reinstall Health Agent for Sync version 3.0.129.0.

To reinstall Health Agent for Sync:

1. Determine the version of Health Agent that is compatible with the version of Azure
AD Connect Synchronization Service that you have installed. If you have Azure AD
Connect Synchronization Service version 1.1.647.0 or a later version, use Health
Agent Version 3.0.129.0.

2. Download a copy of the Health Agent installer

(AadConnectHealthAadSyncSetup.exe) from the following Microsoft Download
Center website:

Download and install Azure AD Connect Health Agent

3. Log on to the Azure AD Connect server by using an account that has Local

Administrator rights.

4. To uninstall the existing version of Health Agent, follow these steps:

a. Go to Control Panel > Program and Features. Select Microsoft Azure AD
Connect Health Agent for Sync, and then select Uninstall.

７ Note

This opens the setup window for the Health Agent.

b. In the setup window for Health Agent, select Uninstall.

c. After the uninstallation process finishes, select Close.

5. To install the compatible version of Health Agent:

a. Double-click the downloaded executable file.

b. On the Setup screen, select Install.

c. After the installation finishes, select Close.

） Important

Do not select Configure.

 d. Start a new PowerShell session. Register the installed Health Agent with Azure
AD by running the following cmdlet:

PowerShell

Register-AzureADConnectHealthSyncAgent -AttributeFiltering:$false -
StagingMode:$false

e. When you are prompted for credentials, provide your Azure AD Global Admin
credentials.

f. Wait about two hours, and then verify that the Health panel is showing up-to-
date information about Sync.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Password hash synchronization stops
working after updating Azure Active
Directory credentials in FIM
Article • 04/20/2022 • 2 minutes to read

This article describes an issue in which password hash synchronization stops working in
an Azure environment. This occurs after you update your global administrator
credentials in Microsoft Forefront Identity Manager (FIM).

Original product version:   Azure Active Directory, Cloud Services (Web roles/Worker
roles), Microsoft Intune, Azure Backup, Office 365 Identity Management

Original KB number:   2962509

Symptoms
After you update your global administrator credentials in FIM for directory
synchronization, password hash synchronization stops working. Additionally, one of the
following events may be logged in the Application log in Event Viewer:

Event Source Level Description

ID

115 Directory Synchronization Information Error Description: Access to Windows Azure

Active Directory has been denied. Contact
Technical Support.

0 Directory Synchronization Error The user name or password is incorrect. Verify

your user name, and then type your password
again.

655 Directory Synchronization Error The user name or password is incorrect. Verify
your user name, and then type your password
again.

6900 FIMSynchronizationService Error The server encountered an unexpected error

while processing a password change
notification:

"The user name or password is incorrect.

Verify your user name, and then type your
password again.
Resolution
To resolve this issue, run the Azure Active Directory Sync tool Configuration Wizard. For
more information about how to do this, see Synchronize your directories.

More information
Alternatively, you can restart the Forefront Identity Manager Synchronization Service. To
do this, follow these steps:

1. Click Start, point to Administrative Tools, and then click Services.

2. In the list of services, right-click Forefront Identity Manager Synchronization
Service, and then click Stop.
3. Right-click Forefront Identity Manager Synchronization Service, and then click
Start.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Password isn't synced from Azure AD to
on-premises after the password is
changed or reset
Article • 04/20/2022 • 2 minutes to read

This article describes an issue in which password isn't synced from Azure AD to on-
premises directory after the password is changed or reset.

Original product version:   Azure Active Directory

Original KB number:   3187256

Symptoms
When a password reset or a password change action is performed, the password isn't
synchronized from Azure Active Directory (Azure AD) to the on-premises directory using
Azure AD Connect.

Additionally, you may see the following message, or the password will not write back to
your on-premises directory:

Your request could not be processed

We're sorry but we cannot reset your password at this time. This is due to a
temporary connectivity issue, so if you try again later, resetting your password may
succeed. If the issue persists, please contact your admin to reset your password for
you.

Cause
This issue can occur for many reasons. The following is a list of known causes:

Prerequisites are not met for password writeback.

Permissions are not set up correctly for password writeback.
The password reset agent in Azure AD Connect isn't running.
There's a network connectivity issue between the password reset service in Azure
AD and your local environment where Azure AD Connect is running.

Resolution
Before troubleshooting this issue, it's important to know which scenarios allow password
writeback. The following table lists scenarios in which password writeback occurs and
doesn't occur.

Scenario Password
writeback

Users who perform self-service password reset through Yes

https://passwordreset.microsoftonline.com

Admins who perform self-service password reset through Yes

https://passwordreset.microsoftonline.com

Password change in My Apps or in Office 365 portal Yes

Admins who perform password resets by using the Azure Management Portal Yes

Admins who perform password resets by using the Microsoft 365 admin center No

Passwords at new user creation through Azure Management Portal, Microsoft 365 No

admin center, or Azure AD PowerShell Module

Admins who perform password resets by using PowerShell Modules V1 No

(MSOnline) or V2 (AzureAD)

To resolve this issue, see the Troubleshoot Password Writeback section of How to

troubleshoot Password Management.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Password hash synchronization for
Azure AD stops working and event ID
611 is logged
Article • 04/20/2022 • 2 minutes to read

Original product version:   Cloud Services (Web roles/Worker roles), Azure Active
Directory, Microsoft Intune, Azure Backup, Office 365 Identity Management

Original KB number:   2867278

Symptoms
Password hash synchronization for Microsoft Azure Active Directory stops working after
several days. Additionally, in Event Viewer, the following event ID 611 error is logged in
the Application log:

Password synchronization failed for domain: Contoso.com .

Resolution
Install the latest version of the Azure Active Directory Synchronization tool. For more
information, see Install or upgrade the Directory Sync tool.

More information
You may see one or more of the following error details for Event ID 611.

Description Cause More

information

Microsoft.Online.PasswordSynchronization.
Windows Server Update to
SynchronizationManagerException: Recovery task failed. ---> 2003 domain the latest
Microsoft.Online.PasswordSynchronization.
controllers version of
DirectoryReplicationServices.DrsException: RPC Error 8439: The handle certain Azure AD
distinguished name specified for this replication operation is scenarios Connect to
invalid. There was an error calling _IDL_DRSGetNCChanges . unexpectedly. resolve this
issue.
Description Cause More
information

Microsoft.Online.PasswordSynchronization.
It's a known Update to
DirectoryReplicationServices.DrsException: RPC Error 8593: The issue that was the latest
directory service cannot perform the requested operation fixed in Azure version of
because the servers involved are of different replication epochs Active Directory Azure AD
(which is related to a domain rename that is in progress). Sync tool build Connect to
1.0.6455.0807. resolve this
issue.

System.ArgumentOutOfRangeException: Not a valid Win32 It's a known Update to

FileTime. issue that was the latest
fixed in Azure version of
Active Directory Azure AD
Sync tool build Connect to
1.0.6455.0807. resolve this
issue.

System.ArgumentException: An item with the same key has It's a known Update to
already been added. issue that was the latest
fixed in Azure version of
Active Directory Azure AD
Sync tool build tool to
1.0.6455.0807. resolve this
issue.
 Description Cause More
information

Password synchronization failed for domain: Contoso.com . AD DS Update to

Details:
Connector the latest
Microsoft.Online.PasswordSynchronization.
Account is version of
DirectoryReplicationServices.DrsException: RPC Error 8453: missing the Azure AD
Replication access was denied. There was an error calling following Connect,
_IDL_DRSGetNCChanges .
extended and follow
permissions on the article
at Microsoft.Online.PasswordSynchronization.
AD: "Azure AD
DirectoryReplicationServices.DrsRpcConnection.OnGetChanges( Connect:
ReplicationState syncState)
Replicating Configure
Directory AD DS
at Microsoft.Online.PasswordSynchronization.
Changes Connector
DirectoryReplicationServices.DrsConnection.GetChanges( Replicating Account
ReplicationState replicationState)
Directory Permissions"
Changes on how to
at Microsoft.Online.PasswordSynchronization.
All add the
RetryUtility.ExecuteWithRetry[T](Func 1 operation, Func 1 correct
shouldAbort, RetryPolicyHandler retryPolicy)
Active
Directory
at Microsoft.Online.PasswordSynchronization.
permissions.

DeltaSynchronizationTask.SynchronizeCredentialsToCloud()

at Microsoft.Online.PasswordSynchronization.

PasswordSynchronizationTask.SynchronizeSecrets()

at Microsoft.Online.PasswordSynchronization.

SynchronizationExecutionContext.SynchronizeDomain()

at Microsoft.Online.PasswordSynchronization.

SynchronizationManager.SynchronizeDomain(
SynchronizationExecutionContext syncExecutionContext).

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
How the proxyAddresses attribute is
populated in Azure AD
Article • 06/02/2022 • 8 minutes to read

This article describes how the proxyAddresses attribute is populated in Azure Active
Directory (Azure AD) and discusses common scenarios to help you understand how the
proxyAddresses attribute is populated in Azure AD.

Original product version:   Azure Active Directory

Original KB number:   3190357

The proxyAddresses attribute in Active Directory is a multi-value property that can

contain various known address entries. For example, it can contain SMTP addresses,
X500 addresses, SIP addresses, and so on. When an object is synchronized to Azure AD,
the values that are specified in the mail or proxyAddresses attribute in Active Directory
are copied to a shadow mail or proxyAddresses attribute in Azure AD, and then are used
to calculate the final proxyAddresses of the object in Azure AD according to internal
Azure AD rules. The logic that populates mail, mailNickName and proxyAddresses
attributes in Azure AD is called proxy calculation and it takes into account many
different aspects of the on-premises Active Directory data, such as:

Set or update the Primary SMTP address and additional secondary addresses
based on the on-premises ProxyAddresses or UserPrincipalName.
Set or update the Mail attribute based on the calculated Primary SMTP address.
Set or update the MailNickName attribute based on the on-premises
MailNickName or Primary SMTP address prefix.
Discard on-premises addresses that have a reserved domain suffix, e.g.
@*.onmicrosoft.com, @*.microsoftonline.com;
Discard on-premises ProxyAddresses with legacy protocols like MSMAIL, X400, etc;
Discard malformed on-premises addresses or not compliant with RFC 5322, e.g.
missing protocol prefix "SMTP:", containing a space or other invalid character;
Remove ProxyAddresses with a non-verified domain suffix, if the user is assigned
an Exchange Online license.

Therefore, the values of the Mail and ProxyAddresses attributes for the object in Active
Directory may not be the same as the values of the ProxyAddresses attribute in Azure
AD.

Terminology
The following terminology is used in this article:

Initial domain: The first domain provisioned in the tenant. For example,
Contoso.onmicrosoft.com .

Microsoft Online Email Routing Address (MOERA): The address constructed from
the user's userPrincipalName prefix, plus the initial domain suffix, which is
automatically added to the proxyAddresses in Azure AD. For example,
smtp:john.doe@Contoso.onmicrosoft.com .
UserPrincipalName (UPN): The sign-in address of the user.
Primary SMTP address: The primary email address of an Exchange recipient object,
including the SMTP protocol prefix. For example, SMTP:john.doe@Contoso.com .
Secondary smtp address: Additional email address(es) of an Exchange recipient
object. For example, smtp:john.doe@Contoso.com .
Mail attribute: Holds the primary email address of a user, without the SMTP
protocol prefix. For example, john.doe@Contoso.com .
MailNickName attribute: Holds the alias of an Exchange recipient object. For
example, john.doe .

Scenario 1: User doesn't have the mail,

mailNickName, or proxyAddresses attribute set
You created an on-premises user object that has the following attributes set:

AD:mail : \<not set>

AD:mailNickName : \<not set>
AD:proxyAddresses : {\<not set>}

AD:userPrincipalName : user1upn@Contoso.com

Next, it's synchronized to Azure AD and only the mailNickName attribute is populated
by using the prefix of the UPN, because it's a mandatory attribute:

AAD:mailNickName : user1upn

AAD:UserPrincipalName : user1upn@Contoso.com

Then, it's assigned an Exchange Online license. In this scenario, the following operations
are performed due to proxy calculation:
 Set the primary SMTP address in the proxyAddresses attribute by using the UPN
value.
Populate the mail attribute by using the primary SMTP address.
Add the MOERA as a secondary smtp address in the proxyAddresses attribute, by
using the format of mailNickName@initial domain.

The following attributes are set in Azure AD on the synchronized user object with
Exchange Online license:

AAD:mail : user1upn@Contoso.com

AAD:mailNickName : user1upn

AAD:proxyAddresses : {smtp:user1upn@Contoso.onmicrosoft.com;
SMTP:user1upn@Contoso.com}

AAD:userPrincipalName : user1upn@Contoso.com

Scenario 2: User doesn't have the

mailNickName or proxyAddresses attribute set
You created an on-premises user object that has the following attributes set:

AD:mail : user2mail@Contoso.com

AD:mailNickName : \<not set>

AD:proxyAddresses : {\<not set>}

AD:userPrincipalName : user2upn@Contoso.com

Next, it's synchronized to Azure AD and the following operations are performed due to
proxy calculation:

Set the primary SMTP using the same value of the mail attribute.
Populate the mailNickName attribute by using the primary SMTP address prefix.
Populate the mail attribute by using the primary SMTP address.

The following attributes are set in Azure AD upon initial user provisioning:

AAD:mail : user2mail@Contoso.com

AAD:mailNickName : user2mail
AAD:proxyAddresses : {SMTP:user2mail@Contoso.com}

AAD:userPrincipalName : user2upn@Contoso.com

Then, it's assigned an Exchange Online license. In this scenario, the following operation
is performed as a result of proxy calculation:

Add the UPN as a secondary smtp address in the proxyAddresses attribute.

Add the MOERA as a secondary smtp address in the proxyAddresses attribute, by
using the format of mailNickName@initial domain.

The following attributes are set in Azure AD on the synchronized user object with
Exchange Online license:

AAD:mail : user2mail@Contoso.com

AAD:mailNickName : user2mail
AAD:proxyAddresses : {smtp:user2upn@Contoso.com;
smtp:user2mail@Contoso.onmicrosoft.com; SMTP:user2mail@Contoso.com}

AAD:userPrincipalName : user2upn@Contoso.com

Scenario 3: You change the proxyAddresses

attribute values of the on-premises user
You created an on-premises user object that has the following attributes set:

AD:mail : \<not set>

AD:mailNickName : \<not set>
AD:proxyAddresses : {smtp:user3pa3@Fabrikam.microsoftonline.com,
smtp:user3pa2@Contoso.onmicrosoft.com, SMTP:user3pa1@Contoso.com}

AD:userPrincipalName : user3upn@Contoso.com

Next, it's synchronized to Azure AD and assigned an Exchange Online license. In this
scenario, the following operation is performed as a result of proxy calculation:

Discard addresses that have a reserved domain suffix. In this example, the
following addresses are skipped:
smtp:user3pa2@Contoso.onmicrosoft.com

smtp:user3pa3@Fabrikam.microsoftonline.com
Set the primary SMTP using the same address that's specified in the on-premises
proxyAddresses attribute.
Populate the mailNickName attribute by using the primary SMTP address prefix.
Populate the mail attribute by using the primary SMTP address.
 Add the MOERA as a secondary smtp address in the proxyAddresses attribute, by
using the format of mailNickName@initial domain.
Add the UPN as a secondary smtp address in the proxyAddresses attribute.

The following attributes are set in Azure AD on the synchronized user object:

AAD:mail : user3pa1@Contoso.com

AAD:mailNickName : user3pa1

AAD:proxyAddresses : {smtp:user3upn@Contoso.com;
smtp:user3pa1@Contoso.onmicrosoft.com; SMTP:user3pa1@Contoso.com}

AAD:userPrincipalName : user3upn@Contoso.com

Then, you change the values of the on-premises proxyAddresses attribute to the
following ones:

AD:mail : \<not set>

AD:mailNickName : \<not set>
AD:proxyAddresses : {smtp:user3new3@Fabrikam.microsoftonline.com,
smtp:user3new2@Contoso.onmicrosoft.com, SMTP:user3new1@Contoso.com}

AD:userPrincipalName : user3upn@Contoso.com

In this scenario, the following operation is performed as a result of proxy calculation:

Discard addresses that have a reserved domain suffix. For example, the following
addresses are skipped:
smtp:user3new2@Contoso.onmicrosoft.com

smtp:user3new3@Fabrikam.microsoftonline.com
Replace the new primary SMTP address that's specified in the proxyAddresses
attribute.
Update the mail attribute by using the value of te new primary SMTP address
specified in the proxyAddresses attribute.
Keep the old mailNickName since the on-premises mailNickName is not set nor its
value have changed.
Keep the old MOERA as a secondary smtp address in the proxyAddresses attribute.
Keep the UPN as a secondary SMTP address in the proxyAddresses attribute.

The following attributes are set in Azure AD on the synchronized user object:
 AAD:mail : user3new1@Contoso.com

AAD:mailNickName : user3pa1

AAD:proxyAddresses : {SMTP:user3new1@Contoso.com;
smtp:user3upn@Contoso.com; smtp:user3pa1@Contoso.onmicrosoft.com}

AAD:userPrincipalName : user3upn@Contoso.com

Scenario 4: Exchange Online license is removed

You created an on-premises user object that has the following attributes set:

AD:mail : \<not set>

AD:mailNickName : \<not set>
AD:proxyAddresses : {\<not set>}

AD:userPrincipalName : user4upn@Contoso.com

Next, it's synchronized to Azure AD and assigned an Exchange Online license. In this
scenario, the following operation is performed as a result of proxy calculation:

Set the primary SMTP address in the proxyAddresses attribute by using the UPN
value.
Populate the mailNickName attribute by using the primary SMTP address prefix.
Populate the mail attribute by using the primary SMTP address.
Add the MOERA as a secondary smtp address in the proxyAddresses attribute, by
using the format of mailNickName@initial domain.

The following attributes are set in Azure AD on the synchronized user object:

AAD:mail : user4upn@Contoso.com

AAD:mailNickName : user4upn

AAD:proxyAddresses : {smtp:user4upn@Contoso.onmicrosoft.com;
SMTP:user4upn@Contoso.com}

AAD:userPrincipalName : user4upn@Contoso.com

Then, you remove the Exchange Online license and the following operation is performed
as a result of proxy calculation:

Remove the primary SMTP address in the proxyAddresses attribute corresponding

to the UPN value.
Promote the MOERA from secondary to Primary SMTP address in the
proxyAddresses attribute.
 Update the mail attribute by using the primary SMTP address in the
proxyAddresses attribute(MOERA).

AAD:mail : user4upn@Contoso.onmicrosoft.com

AAD:mailNickName : user4upn

AAD:proxyAddresses : {SMTP:user4upn@Contoso.onmicrosoft.com}

AAD:userPrincipalName : user4upn@Contoso.com

Then, you add a secondary smtp address in the on-premises proxyAddresses attribute:

AD:mail : \<not set>

AD:mailNickName : \<not set>
AD:proxyAddresses : {smtp:user4new@Contoso.com}

AD:userPrincipalName : user4upn@Contoso.com

When the object is synchronized to Azure AD, the following operation is performed as a
result of proxy calculation:

Add the secondary smtp address in the proxyAddresses attribute.

Add the UPN as a secondary smtp address in the proxyAddresses attribute.

The following attributes set in Azure AD on the synchronized user object:

AAD:mail : user4upn@Contoso.onmicrosoft.com

AAD:mailNickName : user4upn

AAD:proxyAddresses : {smtp:user4upn@Contoso.com;
smtp:user4new@Contoso.com; SMTP:user4upn@Contoso.onmicrosoft.com}

AAD:userPrincipalName : user4upn@Contoso.com

Scenario 5: The mailNickName attribute value

is changed
You created an on-premises user object that has the following attributes set:

AD:mail : \<not set>

AD:mailNickName : \<not set>
AD:proxyAddresses : {\<not set>}

AD:userPrincipalName : user5upn@Contoso.com

Next, it's synchronized to Azure AD and assigned an Exchange Online license. In this
scenario, the following operation is performed as a result of proxy calculation:

Set the primary SMTP address in the proxyAddresses attribute by using the UPN
value.
Populate the mailNickName attribute by using the primary SMTP address prefix.
Populate the mail attribute by using the primary SMTP address.
Add the MOERA as a secondary smtp address in the proxyAddresses attribute, by
using the format of mailNickName@initial domain.

The following attributes are set in Azure AD on the synchronized user object:

AAD:mail : user5upn@Contoso.com

AAD:mailNickName : user5upn

AAD:proxyAddresses : {smtp:user5upn@Contoso.onmicrosoft.com;
SMTP:user5upn@Contoso.com}

AAD:userPrincipalName : user5upn@Contoso.com

Then, you change the value of the on-premises mailNickName attribute to the following:

mail : \<not set>

AD:mailNickName : user5new1

AD:proxyAddresses : {\<not set>}

AD:userPrincipalName : user5upn@Contoso.com

In this scenario, the following operation is performed as a result of proxy calculation:

Update the mailNickName attribute by using the same value as the on-premises
mailNickName attribute.
Keep the mail attribute unchanged.
Keep the proxyAddresses attribute unchanged.

The following attributes are set in Azure AD on the synchronized user object:

AAD:mail : user5upn@Contoso.com

AAD:mailNickName : user5new1
AAD:proxyAddresses : {smtp:user5upn@Contoso.onmicrosoft.com;
SMTP:user5upn@Contoso.com}

AAD:userPrincipalName : user5upn@Contoso.com

Scenario 6: Two users have the same

mailNickName attribute
You created two on-premises user objects that have the same mailNickName value:

AD:mail : \<not set>

AD:mailNickName : user6mnn

AD:proxyAddresses : {\<not set>}

AD:userPrincipalName : user6a@Contoso.com

AD:mail : \<not set>

AD:mailNickName : user6mnn

AD:proxyAddresses : {\<not set>}

AD:userPrincipalName : user6b@Contoso.com

Next, they are synchronized to Office 365 and assigned an Exchange Online license. In
this scenario, the following operation is performed as a result of proxy calculation:

Set the primary SMTP address in the proxyAddresses attribute by using the UPN
value.
Populate the mailNickName attribute by using the same value as the on-premises
mailNickName attribute.
Populate the mail attribute by using the primary SMTP address.
For the first user provisioned - Add the MOERA as the secondary smtp address in
the proxyAddresses attribute, by using the format mailNickName@initial domain.
For the second user provisioned, MOERA is already in use by another object - Add
the MOERA as the secondary smtp address, by appending 4 random digits to the
mailNickName as a prefix, plus @initial domain suffix.

The following attributes are set in Azure AD on the synchronized user object:

AAD:mail : user6a@Contoso.com

AAD:mailNickName : user6mnn

AAD:proxyAddresses : {smtp:user6mnn@Contoso.onmicrosoft.com;
SMTP:user6a@Contoso.com}

AAD:userPrincipalName : user6a@Contoso.com

 AAD:mail : user6b@Contoso.com

AAD:mailNickName : user6mnn

AAD:proxyAddresses : {smtp:user6mnn5236@Contoso.onmicrosoft.com;
SMTP:user6b@Contoso.com}

AAD:userPrincipalName : user6b@Contoso.com

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Error when you reset your password in
Azure, Office 365, or Intune: Your
request could not be processed
Article • 04/20/2022 • 2 minutes to read

This article describes a problem in which you receive a "Your request could not be
processed" message when you reset your password in Microsoft Azure, Office 365, or
Microsoft Intune. To resolve this problem, work with your administrator to update your
telephone number(s).

Original product version:   Azure Active Directory, Microsoft Intune, Cloud Services (Web
roles/Worker roles)

Original KB number:   2951268

Symptoms
When you try to reset your password in Microsoft Azure, Microsoft Office 365, or
Microsoft Intune, you receive the following error message:

There was an error processing your request. Please try resetting your password
again by clicking here.

If you are unable to reset your password after retrying, please contact Support for
assistance.

Cause
This problem occurs because the telephone number that we have on file may be
incorrect, and we were unable to reach you.

Resolution
To resolve this problem, work with your administrator to update your telephone
number(s).

７ Note

If available, try to use another method such as using your mobile phone, office
telephone, or mobile app.
Contact us for help
If you have questions or need help, create a support request , or ask Azure community
support.
RPC errors affecting AADConnect
Article • 04/20/2022 • 6 minutes to read

Customers may experience issues where they cannot configure AADConnect and or
enable features due to Remote Procedure Call (RPC) related errors.

Customers may also experience features previously enabled stop working due to these
types of errors.

In the vast majority of cases, the issue is affecting AADConnect and not caused by
AADConnect, so finding the exact underlying problem is crucial to correctly define
troubleshooting steps and identify the right underlying issue causing the errors.

This article cover examples of AADConnect features affected by RPC errors.

Investigating a Remote Procedure Call error

affecting AADConnect
When an issue is identified, it is generally recommended as part of troubleshooting
initial steps, to carefully investigate Application events using Event Viewer. Determining
the system error being returned from the remote procedure call will help you target
your investigation and define the right troubleshooting methods and tools.

For these types of errors, Application events include information about the RPC error
such as in the following examples:

Example 1


Snippet from the Application error event seen in the previous image:

dos

Log Name: Application

Source: Directory Synchronization

Date: 8/10/2020 11:00:39 AM

Event ID: 611

Task Category: None

Level: Error

Keywords: Classic

User: N/A

Computer: server1.contoso.com

Description: Password hash synchronization failed for domain: contoso.com,

domain controller hostname: <not available>, domain controller IP address:
<not available>.

Details:
Microsoft.Online.PasswordSynchronization.SynchronizationManagerException:
Unable to open connection to domain: contoso.com. Error: There was an error
establishing a connection to the directory replication service. Domain
controller hostname: server1.contoso.com, domain controller IP address:
10.0.0.202 --->
Microsoft.Online.PasswordSynchronization.DirectoryReplicationServices.DrsCom
municationException: There was an error establishing a connection to the
directory replication service. Domain controller hostname:
server1.contoso.com, domain controller IP address: 10.0.0.202 --->
Microsoft.Online.PasswordSynchronization.DirectoryReplicationServices.

DrsException: There was an error creating the connection context. --->

Microsoft.Online.PasswordSynchronization.DirectoryReplicationServices.DrsCom
municationException: RPC Error 1722 : The RPC server is unavailable. Error
creating the RPC binding handle

In this case, the RPC communication failed with error "1722 : The RPC server is
unavailable".

System Error Codes 1700-3999

In this example, the error is affecting AADConnect password synchronization feature.

Troubleshooting Example 1
The error in Example 1 is a common networking related error for which troubleshooting
steps can be found in Troubleshoot TCP/IP RPC Errors.

In this scenario, investigating a network trace reveals retransmit packets being sent for
communication with destination port 135, so traffic on this port is being blocked on the
destination server.
 

These errors can manifest intermittently, which adds complexity to the process of
collecting data, like a network trace, for investigation and troubleshooting.

The following steps allow you to automatically collect a network trace, when the error
event id is generated.

７ Note

To automatically collect an network trace, Microsoft Network Monitor must be

installed on the AADConnect server.

Download Netmon

1. From an elevated command prompt, run the following command:

dos

nmcap /network * /Capture /file c:\MSData\%Computername%_Trace.cap:500M

/StopWhen /Frame (ICMP and Ipv4.TotalLength == 328) /CaptureProcesses
/TimeAfter 2s

2. To stop the trace when the error is generated, send a Ping with the correct size.

Prepare the Ping Command in a script (cmd file for instance) that you execute
when the AADConnect throws the Error in Event log.

Ping command:

dos

ping -l 300 -n 2 1.2.3.4

 3. Attach a task that runs the cmd file created in the previous step to the event that is
generated when the issue reproduces. That will trigger the ping command that
stops the trace.

Example 2

Snippet from the Application error event seen in the previous image:

dos

Log Name: Application

Source: Directory Synchronization

Date: 8/3/2020 8:17:55 PM

Event ID: 611

Task Category: None

Level: Error

 Keywords: Classic

User: N/A

Computer: server1.contoso.com

Description: Password hash synchronization failed for domain: contoso.com,

domain controller hostname: server1.contoso.com, domain controller IP
address: 192.168.0.0.

Details:
Microsoft.Online.PasswordSynchronization.SynchronizationManagerException:
Recovery task failed. --->
Microsoft.Online.PasswordSynchronization.DirectoryReplicationServices.

DrsException: RPC Error 8333 : Directory object not found. There was an
error calling _IDL_DRSGetNCChanges.

Other infrastructure configuration issues may contribute to Remote Procedure Call

problems, such as DNS name resolution, Authentication problems, etc.

It's important to note the error number for appropriate investigation and
troubleshooting.

Troubleshooting Example 2
In Example 2 the Remote Procedure Call returned error is 8333, an error for "Directory
object not found"

System Error Codes 8200-8999

AADConnect server was not able to find the user object for which it is trying to perform
Password Hash Synchronization in Active Directory.

More detailed information and troubleshooting guidance can be found in Windows

Server Troubleshooting : RPC Server is unavailable .

Example 3
Snippet from the Application error event seen in the previous image:

dos

Log Name: Application

Source: ADSync

Date: 7/28/2020 7:07:20 PM

Event ID: 6329

Task Category: Server

Level: Error

Keywords: Classic

User: N/A

Computer: server1.contoso.com

Description: An unexpected error has occurred during a password set

operation.

"BAIL: MMS(4984): ..\dnutils.cpp(1341): 0x800700b7 (Cannot create a file

when that file already exists.)

ERR_: MMS(4984):
X:\bt\1016372\repo\src\dev\sync\ma\shared\inc\MAUtils.h(58): Failed getting
registry value 'ADMADoNormalization', 0x2

BAIL: MMS(4984):
X:\bt\1016372\repo\src\dev\sync\ma\shared\inc\MAUtils.h(59): 0x80070002 (The
system cannot find the file specified.): Win32 API failure: 2

BAIL: MMS(4984):
X:\bt\1016372\repo\src\dev\sync\ma\shared\inc\MAUtils.h(114): 0x80070002
(The system cannot find the file specified.)

ERR_: MMS(4984):
X:\bt\1016372\repo\src\dev\sync\ma\shared\inc\MAUtils.h(58): Failed getting
registry value 'ADMARecursiveUserDelete', 0x2

BAIL: MMS(4984):
X:\bt\1016372\repo\src\dev\sync\ma\shared\inc\MAUtils.h(59): 0x80070002 (The
 system cannot find the file specified.): Win32 API failure: 2

BAIL: MMS(4984):
X:\bt\1016372\repo\src\dev\sync\ma\shared\inc\MAUtils.h(114): 0x80070002
(The system cannot find the file specified.)

ERR_: MMS(4984):
X:\bt\1016372\repo\src\dev\sync\ma\shared\inc\MAUtils.h(58): Failed getting
registry value 'ADMARecursiveComputerDelete', 0x2

BAIL: MMS(4984):
X:\bt\1016372\repo\src\dev\sync\ma\shared\inc\MAUtils.h(59): 0x80070002 (The
system cannot find the file specified.): Win32 API failure: 2

BAIL: MMS(4984):
X:\bt\1016372\repo\src\dev\sync\ma\shared\inc\MAUtils.h(114): 0x80070002
(The system cannot find the file specified.)

ERR_: MMS(4984): admaexport.cpp(2939): Failed to acquire user information:

0x6ba

BAIL: MMS(4984): admaexport.cpp(2963): 0x80004005 (Unspecified error)

BAIL: MMS(4984): admaexport.cpp(3296): 0x80004005 (Unspecified error)

ERR_: MMS(4984): ..\ma.cpp(8000): ExportPasswordSet failed with 0x80004005

Azure AD Sync 1.4.18.0"

It's important to know that errors can be represented in their hexadecimal code, like in
this example.

You can also use the hexadecimal error code to search the error symbolic name.

The error "0x6ba" translates to an "RPC Server Unavailable" error 1722. The
troubleshooting steps used in Example 1 also apply here.

System Error Codes 1700-3999

Example 4
Another example with the RPC error represented in its hexadecimal form:

In this case, the error returned "0x5" translates to an access denied error:

System Error Codes 0-499

There may be various reasons to raise an access denied error. Hardening group policies
implemented in Active Directory is one of them. One example is restricting clients
allowed to make calls to SAM:

Network access: Restrict clients allowed to make remote calls to SAM

Other commonly found system error codes

returned in Remote Procedure Call affecting
AADConnect
Error Hexadecimal Error symbolic name Error descriptive text
ID error
representation

1127 0x467 ERROR_DISK_OPERATION_FAILED While accessing the

hard disk, a disk
operation failed even
after retries.

1130 0x46A ERROR_NOT_ENOUGH_SERVER_MEMORY Not enough server

storage is available to
process this
command.

1331 0x533 ERROR_ACCOUNT_DISABLED This user can't sign in

because this account
is currently disabled.

14 0xE ERROR_OUTOFMEMORY Not enough storage is

available to complete
this operation.

1450 0x5AA ERROR_NO_SYSTEM_RESOURCES Insufficient system

resources exist to
complete the
requested service.

1722 0x6BA RPC_S_SERVER_UNAVAILABLE The RPC server is

unavailable.

1723 0x6BB RPC_S_SERVER_TOO_BUSY The RPC server is too

busy to complete this
operation.

1726 0x6BE RPC_S_CALL_FAILED The remote procedure

call failed.
Error Hexadecimal Error symbolic name Error descriptive text
ID error
representation

1727 0x6BF RPC_S_CALL_FAILED_DNE The remote procedure

call failed and did not
execute.

1728 0x6C0 RPC_S_PROTOCOL_ERROR A remote procedure

call (RPC) protocol
error occurred.

1753 0x6D9 EPT_S_NOT_REGISTERED There are no more

endpoints available
from the endpoint
mapper.

1818 0x71A RPC_S_CALL_CANCELLED The remote procedure

call was cancelled.

1825 0x721 RPC_S_SEC_PKG_ERROR A security package

specific error occurred.

5 0x5 ERROR_ACCESS_DENIED Access is denied.

6 0x6 ERROR_INVALID_HANDLE The handle is invalid.

8333 0x208D ERROR_DS_OBJ_NOT_FOUND Directory object not

found.

8420 0x20E4 ERROR_DS_CANT_FIND_EXPECTED_NC The naming context

could not be found.

8439 0x20F7 ERROR_DS_DRA_BAD_DN The distinguished

name specified for this
replication operation
is invalid.

8446 0x20FE ERROR_DS_DRA_OUT_OF_MEM The replication

operation failed to
allocate memory.

8451 0x2103 ERROR_DS_DRA_DB_ERROR The replication

operation
encountered a
database error.

8453 0x2105 ERROR_DS_DRA_ACCESS_DENIED Replication access was

denied.
 Error Hexadecimal Error symbolic name Error descriptive text
ID error
representation

8456 0x2108 ERROR_DS_DRA_SOURCE_DISABLED The source server is

currently rejecting
replication requests.

8465 0x2111 ERROR_DS_DRA_SOURCE_IS_PARTIAL_REPLICA The replication

synchronization
attempt failed because
a master replica
attempted to sync
from a partial replica.

More information
System Error codes can be found through Error Codes.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Can't run scripts in Azure Active
Directory Module for Windows
PowerShell
Article • 04/20/2022 • 2 minutes to read

This article describes an issue in which you receive an error message when you try to run
scripts in Azure Active Directory Module for Windows PowerShell.

Original product version:   Azure Active Directory, Microsoft Intune, Azure Backup, Office
365 User and Domain Management, Office 365 Identity Management

Original KB number:   2411920

Symptoms
When you try to run a script in Microsoft Azure Active Directory Module for Windows
PowerShell, you receive one of the following error messages:

File C:\my_script.ps1 cannot be loaded. The execution of scripts is disabled on this

system. Please see "Get-Help about_signing" for more details.

File C:\Desktop\myscript.ps1 cannot be loaded because running scripts is disabled

on this system. For more information, see about_Execution_Policies at
http://go.microsoft.com/fwlink/?LinkID=135170 .

File C:\my_script.ps1 cannot be loaded. The file C:\my_script.ps1 is not digitally

signed. The script will not execute on the system. For more information, see
about_Execution_Policies at http://go.microsoft.com/fwlink/?LinkID=135170 .

Cause
This issue may occur if one of the following factors is true:

The PowerShell version that you are using is higher than 5.1. The Azure Active
Directory Module only works with PowerShell 3 to 5.1.
The execution policy is set to Restricted. Certain Windows PowerShell cmdlets
can't run if the policy is too restricted.
Resolution
To resolve this issue, follow these steps:

1. Identify the PowerShell version by running $PSVersionTable .

2. Run the Azure Active Directory Module for Windows PowerShell as an

administrator. To do it, select Start, select All Programs, select Windows Azure
Active Directory, right-click Windows Azure Active Directory Module for
Windows PowerShell, and then select Run as administrator.

3. Set the execution policy to Unrestricted. To do it, type the following cmdlet, and
then press Enter:

PowerShell

Set-ExecutionPolicy Unrestricted

4. Run the Windows PowerShell cmdlets that you want.

5. Set the execution policy to Restricted. To do it, type the following cmdlet, and then
press Enter:

PowerShell

Set-ExecutionPolicy Restricted

More information
To help deliver a more secure command-line administration experience, Windows
PowerShell uses "execution policies" to control how Windows PowerShell can be used.
Execution policies define the restrictions under which Windows PowerShell loads files for
execution and configuration. Windows PowerShell runs in the Restricted execution
policy by default. This mode is its most secure mode. In this mode, Windows PowerShell
operates as an interactive shell only.

The four execution policies are as follows:

Restricted is the default execution policy. This policy doesn't run scripts and is
interactive only.
AllSigned policy runs scripts. All scripts and configuration files must be signed by a
publisher that you trust. This policy opens you to the risk of running signed but
malicious scripts, after you confirm that you trust the publisher.
 RemoteSigned policy runs scripts. All scripts and configuration files downloaded
from communication applications must be signed by a publisher that you trust.
These communication applications include Microsoft Outlook, Windows Internet
Explorer, Outlook Express, and Windows Messenger. This policy opens you to the
risk of running malicious scripts that aren't downloaded from these applications.
And you aren't prompted in this situation.
Unrestricted policy runs scripts. All scripts and configuration files downloaded from
communication applications run after you confirm that you understand that the file
originated from the Internet. These communication applications include Outlook,
Internet Explorer, Outlook Express, and Windows Messenger. No digital signature
is required. This policy opens you to the risk of running unsigned, malicious scripts
that are downloaded from these applications.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Separate passwords required for the
computer and work or school account
when using password synchronization
and the Azure Active Directory sync tool
Article • 04/20/2022 • 2 minutes to read

Original product version:   Cloud Services (Web roles/Worker roles), Azure Active
Directory, Microsoft Intune, Azure Backup, Office 365 Identity Management

Original KB number:   2853316

Symptoms
Users have to use different passwords to sign in to their work or school account in a
Microsoft cloud service such as Office 365, Microsoft Azure, or Microsoft Intune and to
log on to their computers. This problem occurs even though you've take the following
actions:

Enabled password synchronization in Azure Active Directory (Azure AD)

Set up Active Directory synchronization to sync user accounts in your on-premises
Active Directory Domain Services (AD DS) environment to Azure AD

Cause
This problem occurs if users' cloud service passwords change. Password synchronization
doesn't sync the cloud service password. Therefore, users in this scenario have different
passwords for their local computer and for the cloud service.

Resolution
To resolve this problem, do one of the following:

Have users change their computer password.

Reset the computer password for the users. When you reset a user's password,
make sure that the User must change password at next logon check box is
cleared.
After directory synchronization occurs, users' computer passwords in the on-premises
Active Directory environment are synced to Azure AD. Users can then log on to their
computers and sign in to the cloud service by using the same password.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Slow performance and high CPU usage
in Azure AD Connect Health for Sync
monitoring agent on a system that has
installed .NET Framework
Article • 04/20/2022 • 2 minutes to read

This article describes an issue that causes slow performance and high CPU usage in
Azure AD Connect Health for Sync monitoring agent on a system that has installed .NET
Framework 4.7.2 or the July 2018 updates for .NET Framework 4.6, 4.6.1, 4.6.2, 4.7, 4.7.1,
or 4.7.2.

Original product version:   Azure Active Directory

Original KB number:   4457331

Symptoms
Assume that you run the Microsoft Azure Active Directory (Azure AD) Connect Health
for Sync monitoring agent on a system that has installed .NET Framework 4.7.2 or the
July 2018 updates for .NET Framework 4.6, 4.6.1, 4.6.2, 4.7, 4.7.1, or 4.7.2. In this scenario,
the system may experience slow performance and high CPU usage.

To see the high CPU usage, start Task Manager, and view the CPU usage of the
MIcrosoft.Online.Reporting.MonitoringAgent.Startup process on the Processes tab.

Cause
This issue occurs because the Azure AD Connect Health for Sync monitoring agent does
not fully support .NET Framework 4.7.2 or the July 2018 updates for .NET Framework 4.6,
4.6.1, 4.6.2, 4.7, 4.7.1, or 4.7.2.
The following updates may cause high CPU usage of the
monitoring agent.

.NET Framework update Server version Type of update

KB 4340007 Windows Server 2008 Security

KB 4340556 Windows Server 2008 R2 Security

KB 4340004 Windows Server 2008 R2 Security

 .NET Framework update Server version Type of update

KB 4340557 Windows Server 2012 Security

KB 4340005 Windows Server 2012 Security

KB 4340558 Windows Server 2012 R2 Security

KB 4340006 Windows Server 2012 R2 Security

KB 4054542 Windows Server 2012 Nonsecurity

KB 4054566 Windows Server 2012 R2 Nonsecurity

KB 4054590 Windows Server 2016 Nonsecurity

KB 4338814 Windows Server 2016 (build 14393.2363) Nonsecurity

KB 4345418 Windows Server 2016 (build 14393.2368) Nonsecurity

Resolution
To resolve this issue, install the update that is appropriate for your environment.

For Connect Health for AD DS and AD FS

Install the Azure AD Connect Health Agent, version 3.1.7.0 that was released in July
2018. This update is available for [download here]/azure/active-
directory/hybrid/how-to-connect-health-agent-install#download-and-install-the-
azure-ad-connect-health-agent).

For Azure AD Connect

Install the latest version of Azure AD Connect that contains the fix for this high
CPU usage issue. This version is available for download here .

７ Note

If you have enabled the auto-upgrade feature on your AAD Connect server,
the latest version will be installed automatically.

Virus-scan claim
Microsoft scanned this file for viruses, using the most current virus-detection software
that was available on the date that the file was posted. The file is stored on security-
enhanced servers that help prevent any unauthorized changes to it.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Troubleshoot Azure AD Connect
upgrade issues
Article • 04/20/2022 • 6 minutes to read

This article describes how to troubleshoot problems that can occur when you upgrade
to the latest version of Azure Active Directory Connect from previous installations of
Azure AD Connect, Azure AD Sync, or DirSync.

２ Warning

You might find some online documentation that includes steps to directly edit the
Windows registry. However, editing the registry can cause serious problems if you
modify the registry incorrectly. The Microsoft Azure Active Directory Connect
product team doesn't support editing the Windows registry.

Original product version: Azure Active Directory

Original KB number: 4051210

Symptoms
Every time that you start the Azure AD Connect setup wizard, the program evaluates all
the related products and Windows Installer packages (.msi) that are currently installed.
To trace this activity, follow these steps:

1. Start the Azure AD Connect wizard, and wait for the first page to open.

2. Open the %ProgramData%\AADConnect\ folder, and analyze the latest installation

trace log.

3. Locate the entries for GetInstalledPackagesByUpgradeCode , where the wizard

evaluates all the related Windows Installer packages that are installed in Windows.
For example:

Output

[10:44:23.095] [ 1] [INFO ] Performing direct lookup of upgrade codes

for: Azure AD Sync Engine

[10:44:23.095] [ 1] [VERB ] Getting list of installed packages by

upgrade code

[10:44:23.095] [ 1] [INFO ] GetInstalledPackagesByUpgradeCode

{545334d7-13cd-4bab-8da1-2775fa8cf7c2}: verified product code
{7c4397b7-9008-4c23-8cda-3b3b8faf4312}.

 [10:44:23.095] [ 1] [INFO ] GetInstalledPackagesByUpgradeCode

{dc9e604e-37b0-4efc-b429-21721cf49d0d}: no registered products found.

[10:44:23.095] [ 1] [INFO ] GetInstalledPackagesByUpgradeCode

{bef7e7d9-2ac2-44b9-abfc-3335222b92a7}: no registered products found.

You can find two similar symptoms near this part of the trace log:
Product was uninstalled but an inconsistent product code is still present in Windows
The wizard is detecting an old installation of the sync engine: "Product Azure AD Sync
Engine (version 1.1.343.0) is installed, needs to be upgraded to version 1.1.380.0."

Output

[10:44:23.095] [ 1] [VERB ] Package=Microsoft Azure AD Connect

synchronization services, Version=1.1.343.0, ProductCode=7c4397b7-9008-4c23-
8cda-3b3b8faf4312, UpgradeCode=545334d7-13cd-4bab-8da1-2775fa8cf7c2

[10:44:23.095] [ 1] [INFO ] Determining installation action for Azure AD

Sync Engine (545334d7-13cd-4bab-8da1-2775fa8cf7c2)

[10:44:23.298] [ 1] [VERB ] Check product code installed: {4e67cad2-d71b-

4f06-a7ae-bb49c566bb93}

[10:44:23.298] [ 1] [INFO ] GetProductInfoProperty({4e67cad2-d71b-4f06-a7ae-

bb49c566bb93}, VersionString): unknown product

[10:44:23.298] [ 1] [INFO ] AzureADSyncEngineComponent: Product Azure AD

Sync Engine (version 1.1.343.0) is installed, needs to be upgraded to
version 1.1.380.0.

However, the Windows Installer information might be inconsistent after this product is
uninstalled and the sync engine is no longer present.

Because the setup wizard is still detecting an old product code, it decides to upgrade
Azure AD Sync Engine instead of doing a clean installation. Later in the upgrade process,
while the installer is checking for the current service status, the installation fails because
the ADSync service isn't present:

Output

[10:44:28.260] [ 1] [INFO ] ServiceControllerProvider: verifying ADSync is

in state (Running)

[10:44:28.291] [ 1] [ERROR] Caught an exception while creating the initial

page set on the root page.

Exception Data (Raw): System.InvalidOperationException: Service ADSync was

not found on computer '.'. ---> System.ComponentModel.Win32Exception: The
specified service does not exist as an installed service

Product was uninstalled but a stale product code is still present in Windows

A stale product code that you find in Windows Installer packages can also cause
upgrade issues.
 Output

[15:29:06.958] [ 1] [INFO ] Performing direct lookup of upgrade codes for:

Azure AD Sync Engine

[15:29:06.959] [ 1] [VERB ] Getting list of installed packages by upgrade

code

[15:29:06.959] [ 1] [INFO ] GetProductInfoProperty({7c4397b7-9008-4c23-8cda-

3b3b8faf4312}, VersionString): unrecognized error (1608)

[15:29:06.959] [ 1] [INFO ] GetInstalledPackagesByUpgradeCode {545334d7-

13cd-4bab-8da1-2775fa8cf7c2}: stale product code {7c4397b7-9008-4c23-8cda-
3b3b8faf4312}.

[15:29:06.959] [ 1] [INFO ] GetInstalledPackagesByUpgradeCode {545334d7-

13cd-4bab-8da1-2775fa8cf7c2}: no registered products found.

[15:29:06.959] [ 1] [INFO ] GetInstalledPackagesByUpgradeCode {dc9e604e-

37b0-4efc-b429-21721cf49d0d}: no registered products found.

[15:29:06.959] [ 1] [INFO ] GetInstalledPackagesByUpgradeCode {bef7e7d9-

2ac2-44b9-abfc-3335222b92a7}: no registered products found.

[15:29:06.963] [ 1] [INFO ] Determining installation action for Azure AD

Sync Engine (545334d7-13cd-4bab-8da1-2775fa8cf7c2)

[15:29:07.059] [ 1] [INFO ] Product Azure AD Sync Engine is not installed.

Azure AD Connect Setup wizard can't detect that an Azure AD Sync Engine is installed.
Setup fails and returns the following error message:

Output

[15:52:17.674] [ 13] [ERROR] PerformConfigurationPageViewModel: Caught

exception while installing synchronization service.

Exception Data (Raw): System.Exception: Unable to install the

Synchronization Service. Please see the event log for additional details. --
->
Microsoft.Azure.ActiveDirectory.Client.Framework.ProcessExecutionFailedExcep
tion: Error installing msi package 'Synchronization Service.msi'. Full log
is available at 'C:\ProgramData\AADConnect\Synchronization Service_Install-
20170525-155217.log'.

...

MSI (s) (C0!08) [15:52:17:605]: Product: Microsoft Azure AD Connect

synchronization services -- Error 25019.The Microsoft Azure AD Connect
synchronization services setup wizard cannot open registry key
SYSTEM\CurrentControlSet\Services\ADSync\Parameters. Try verifying the key
and running this wizard again. The system cannot find the file specified.

CustomAction DetectStoreServer returned actual error code 1603 (note this

may not be 100% accurate if translation happened inside sandbox)

Action ended 15:52:17: DetectStoreServer.

--->
Microsoft.Azure.ActiveDirectory.Client.Framework.ProcessExecutionFailedExcep
tion: Exception: Execution failed with errorCode: 1603.

This error occurs because the MSIEXEC process still tries to upgrade the Azure AD Sync
Engine, as shown in the Synchronization Service_Install-20170525-155217.log file:
 Output

MSI (s) (C0:0C) [15:52:17:386]: PROPERTY CHANGE: Adding WIX_UPGRADE_DETECTED

property. Its value is '{7C4397B7-9008-4C23-8CDA-3B3B8FAF4312}'.

MSI (s) (C0:0C) [15:52:17:386]: PROPERTY CHANGE: Adding MIGRATE property.

Its value is '{7C4397B7-9008-4C23-8CDA-3B3B8FAF4312}'.

...

MSI (s) (C0:D4) [15:52:17:598]: Invoking remote custom action. DLL:

C:\Windows\Installer\MSI1D9A.tmp, Entrypoint: DetectStoreServer

Action start 15:52:17: DetectStoreServer.

MSI (s) (C0!08) [15:52:17:605]: Product: Microsoft Azure AD Connect

synchronization services -- Error 25019.The Microsoft Azure AD Connect
synchronization services setup wizard cannot open registry key
SYSTEM\CurrentControlSet\Services\ADSync\Parameters. Try verifying the key
and running this wizard again. The system cannot find the file specified.

As in the previous case, the Windows Installer upgrading process fails because the
ADSync service entries in the registry aren't present. The product has been previously
uninstalled, leaving the Windows Installer database inconsistent.

Solution
You can clean up the inconsistency on the Windows Installer database for the Azure AD
Sync Engine product code that's identified in the trace log. (The product code can vary.
For the previous examples, the problematic product code is 7c4397b7-9008-4c23-8cda-
3b3b8faf4312.)

After you identify the problematic product code from the trace log, use the following
methods, as appropriate.
Fix Windows Installer issues (if applicable)
The KB3139923 Windows hotfix can cause these Windows Installer issues. Therefore, we
recommend that you uninstall it.

To check whether KB3139923 is installed, go to Settings > Windows Update > Update
history. Or use PowerShell to export a list of all installed hotfixes:

PowerShell

Get-Hotfix |

Select-Object HotFixID, InstalledOn, Description, InstalledBy |

Sort-Object –Property InstalledOn –Descending |

Out-File –FilePath ".\$env:COMPUTERNAME-HotFixes.txt"

1. If the KB3139923 hotfix is present, uninstall it, and then restart the server.

2. Download and install the KB3072630 Windows hotfix , and then restart again.
 Use the Windows Installer command-line tool to uninstall product code

To uninstall the product code for the Azure AD Sync Engine, run the Windows Installer
command-line tool (MsiExec.exe) as follows:

1. Identify the inconsistent or stale product code from the trace log (GUID), as shown
in the "Symptoms" section.

2. Open an administrative Command Prompt window.

3. Enter the following line by susbtituting the actual GUID of the problematic product
code:

cmd

SET productcode={<12345678-0000-abcd-0000-0123456789ab>}

4. Enter the following command, repeat the command, and then restart the server.

７ Note

You might see numerous reported errors because of the corrupted Windows
Installer database. For any dialog box that appears, select Yes.

cmd

SET /a counter+=1

& MSIEXEC /x %productcode% /qn /norestart /l*v

"%ProgramData%\AADConnect\AADConnect_Uninstall-
ForcedUninstall_%counter%.log" EXECUTE_UNINSTALL="1"

5. Start the Azure AD Connect wizard, and wait for the first page to open.

6. Open the %ProgramData%\AADConnect\ folder, and analyze the latest installation

trace log.

7. If the inconsistent or stale product code is no longer present in the log file,
continue the wizard, and complete the installation. Otherwise, go to the next
solution.

Use Program Install and Uninstall troubleshooter tool

The Program Install and Uninstall troubleshooter helps you automatically repair issues if
you're blocked from installing or removing programs. It also fixes corrupted registry
keys.
Fix problems that block programs from being installed or removed (microsoft.com)

After you run the tool, restart the server, and then follow these steps:

1. Start the Azure AD Connect wizard, and wait for the first page to open.

2. Open the %ProgramData%\AADConnect\ folder, and analyze the latest installation

trace log.

3. If the inconsistent or stale product code is no longer present in the log file,
continue the wizard, and complete the installation. If the stale product code is
present, we recommend that you reinstall the Windows operating system because
you can't recover the Windows Installer database from an inconsistent state.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Troubleshoot Azure Active Directory
Sync tool installation and Configuration
Wizard errors
Article • • 10 minutes to read

This article describes how to troubleshoot Azure Active Directory Sync tool installation
and Directory Sync tool Configuration Wizard issues.

Original product version:

End-to-end troubleshooting of Azure
AD Connect objects and attributes
Article • 01/22/2023 • 28 minutes to read

This article is intended to establish a common practice for how to troubleshoot

synchronization issues in Azure Active Directory (Azure AD). This method applies to
situations in which an object or attribute doesn't synchronize to Azure Active AD and
doesn't display any errors on the sync engine, in the Application viewer logs, or in the
Azure AD logs. It's easy to get lost in the details if there's no obvious error. However, by
using best practices, you can isolate the issue and provide insights for Microsoft Support
engineers.

As you apply this troubleshooting method to your environment, over time, you'll be able
to do the following steps:

Troubleshoot the sync engine logic from end to end.

Resolve synchronization issues more efficiently.
Identify issues more quickly by predicting the step in which they'll occur.
Identify the starting point for reviewing data.
Determine the optimal resolution.
The steps that are provided here start at the local Active Directory level and progress
toward Azure AD. These steps are the most common direction of synchronization.
However, the same principles apply to the inverse direction (for example, for attribute
writeback).

Prerequisites
For a better understanding of this article, first read the following prerequisite articles for
a better understanding of how to search for an object in different sources (AD, AD CS,
MV, and so on), and to understand how to check the connectors and lineage of an
object.

Azure AD Connect: Accounts and permissions

Troubleshoot an object that is not synchronizing with Azure Active Directory
Troubleshoot object synchronization with Azure AD Connect sync
Bad troubleshooting practices
The DirSyncEnabled flag in Azure AD controls whether the tenant is prepared to accept
synchronization of objects from on-premises AD.
We've seen many customers fall into
the habit of disabling DirSync on the tenant while troubleshooting object or attribute
synchronization issues. It's easy to turn off directory synchronization by running the
following PowerShell cmdlet:

PowerShell

Set-MsolDirSyncEnabled -EnableDirSync $false "Please DON'T and keep

reading!"

However, this can be catastrophic because it triggers a complex and lengthy back-end
operation to transfer SoA from local AD to Azure AD/Exchange Online for all the synced
objects on the tenant. This operation is necessary to convert each object from
DirSyncEnabled to cloud-only, and clean up all the shadow properties that are synced
from on-premises AD (for example, ShadowUserPrincipalName and
ShadowProxyAddresses). Depending on the size of the tenant, this operation can take
more than 72 hours. Also, it's not possible to predict when the operation will finish.
Never use this method to troubleshoot a sync issue because this will cause additional
harm and won't fix the issue. You'll be blocked from enabling DirSync again until this
disabling operation is complete. Also, after you re-enable DirSync, AADC must again
match all the on-premises objects with existent Azure AD objects. This process can be
disruptive.

The only scenarios in which this command is supported to disable DirSync are as follows:

You are decommissioning your on-premises synchronization server, and you want
to continue managing your identities entirely from the cloud instead of from
hybrid identities.
You have some synced objects in the tenant that you want to keep as cloud-only in
Azure AD and remove from on-premises AD permanently.
You are currently using a custom attribute as the SourceAnchor in AADC (for
example, employeeId), and you are re-installing AADC to start using ms-Ds-
Consistency-Guid/ObjectGuid as the new SourceAnchor attribute (or vice versa).
You have some scenarios that involve risky mailbox and tenant migration
strategies.

In some situations, you might have to temporarily stop synchronization or manually

control AADC sync cycles. For example, you might have to stop synchronization to be
able to run one sync step at a time. However, instead of disabling DirSync, you can stop
only the sync scheduler by running the following cmdlet:

PowerShell

Set-ADSyncScheduler -SyncCycleEnabled $false

And when you're ready, manually start a sync cycle by running the following cmdlet:

PowerShell

Start-ADSyncSyncCycle

Glossary
Acronym/abbreviation Name/description

AADC Azure AD Connect

AADCA AAD Connector Account

AADCS Azure AD Connector Space

AADCS:AttributeA Attribute 'A' in Azure AD Connector Space

ACLs Access Control Lists (also known as ADDS permissions)

ADCA AD Connector Account

ADCS Active Directory Connector Space

ADCS:AttributeA Attribute 'A' in Active Directory Connector Space

ADDS or AD Active Directory Domain Services

CS Connector Space

MV Metaverse

MSOL Account Automatically generated AD Connector Account (MSOL_########)

MV:AttributeA Attribute 'A' in the Metaverse object

SoA Source of Authority

Step 1: Synchronization between ADDS and
ADCS

Objective for Step 1

Determine whether the object or attribute is present and consistent in ADCS. If you can
locate the object in ADCS, and all attributes have the expected values, go to Step 2.

Description for Step 1

Synchronization between ADDS and ADCS occurs at the import step, and is the moment
when AADC reads from the source directory and stores data in the database. That is,
when data is staged in the connector space. During a delta import from AD, AADC
requests all the new changes that occurred after a given directory watermark. This call is
initiated by AADC by using the Directory Services DirSync Control against the Active
Directory Replication Service. This step provides the last watermark as the last successful
AD import, and gives AD the point-in-time reference from when all the (delta) changes
should be retrieved. A full import is different because AADC will import from AD all the
data (in sync scope), and then mark as obsolete (and delete) all the objects that are still
in ADCS but were not imported from AD. All the data between AD and AADC is
transferred through LDAP and is encrypted by default.

If the connection with AD is successful, but the object or attribute is not present in ADCS
(assuming the domain or object is in sync scope), the issue most likely involves ADDS
permissions. The ADCA requires ay least read permissions on the object in AD in order
to import data to ADCS. By default, the MSOL account has explicit read/write
permissions for all user, group, and computer properties. However, this situation might
still be problematic if the following conditions are true:

AADC uses a custom ADCA, but it was not provided sufficient permissions in AD.
A parent OU has blocked inheritance, which prevents propagation of permissions
from the root of the domain.
The object or attribute itself has blocked inheritance, which prevents propagation
of permissions.
The object or attribute has an explicit Deny permission that prevents ADCA from
reading it.

Troubleshooting Active Directory

Connectivity with AD

In the Synchronization Service Manager, the "Import from AD" step shows which domain
controller is contacted under Connection Status. You will most likely see an error here
when there is a connectivity issue that affects AD.

If you have to further troubleshoot connectivity for AD, especially if no errors surfaced in
AADConnect server or if you are still in the process of installing the product, start by
using the ADConnectivityTool.

Connection issues to ADDS have the following causes:

Invalid AD credentials. For example, the ADCA has expired or the password has
changed.
A "failed-search" error, which occurs when DirSync Control doesn't communicate
with the AD Replication Service, typically because of high-network packet
 fragmentation.
A "no-start-ma" error, which occurs when there are name resolution issues (DNS)
in AD.
Other problems that can be caused by name resolution issues, network routing
problems, blocked network ports, high network packet fragmentation, no writable
DCs available, and so on. In such cases, you will likely have to involve the Directory
Services or networking support teams to help troubleshoot.

Troubleshooting summary

Identify which domain controller is used.

Use preferred domain controllers to target the same domain controller.
Correctly identify the ADCA.
Use the ADConnectivityTool to identify the problem.
Use the LDP tool to try to bind against the domain controller with the ADCA.
Contact Directory Services or a networking support team to help you troubleshoot.

Run the Synchronization Troubleshooter

After you troubleshoot AD connectivity, run the Troubleshoot Object Synchronization

tool because this alone can detect the most obvious reasons for an object or attribute
not to synchronize.

AD Permissions
A lack of AD permissions can affect both directions of the synchronization:

When you import from ADDS to ADCS, a lack of permissions can cause AADC to
skip objects or attributes so that AADC cannot get ADDS updates in the import
 stream. This error occurs because the ADCA does not have enough permissions to
read the object.
When you export from ADCS to ADDS, a lack of permissions generates a
"permission-issue" export error.

To check permissions, open the Properties window of an AD object, select Security >
Advanced, and then examine the object's allow/deny ACLs by selecting the Disable
Inheritance button (if inheritance is enabled). You can sort the column contents by Type
to locate all the "deny" permissions. AD permissions can vary widely. However, by
default, you might only see one "Deny ACL" for "Exchange Trusted Subsystem." Most
permissions will be marked as Allow.

The following default permissions are the most relevant:

Authenticated Users

Everyone

Custom ADCA or MSOL account

Pre-Windows 2000 Compatible Access

SELF

The best way to troubleshoot permissions is to use the "Effective Access" feature in AD
Users and Computers console. This feature checks the effective permissions for a given
account (the ADCA) on the target object or attribute that you want to troubleshoot.
 ） Important

Troubleshooting AD permissions can be tricky because a change in ACLs does not

take immediate effect. Always consider that such changes are subject to AD
replication.

For example:

Make sure that you are making the necessary changes directly to the closest
domain controller (see the "Connectivity with AD" section):
Wait for ADDS replications to occur.
If possible, restart ADSync service to clear the cache.

Troubleshooting summary

Identify which domain controller is used.

Use preferred domain controllers to target the same domain controller.
Correctly identify the ADCA.
Use the Configure AD DS Connector Account Permissions tool.
Use the "Effective Access" feature in AD Users and Computers.
Use the LDP tool to bind against the domain controller that has the ADCA, and try
to read the failing object or attribute.
 Temporarily add the ADCA to the Enterprise admins or Domain admins, and restart
the ADSync service.

Important: Do not use this as a solution.

After you verify the permissions issue, remove the ADCA from any highly privileged
groups, and provide the required AD permissions directly to the ADCA.
Engage Directory Services or a network support team to help you troubleshoot the
situation.

AD replications

This issue is less likely to affect AADConnect because it causes greater problems.
However, when AADConnect is importing data from a domain controller by using
delayed replication, it will not import the latest information from AD, which causes sync
issues in which an object or attribute that was recently created or changed in AD does
not sync to AAD because it was not replicated to the domain controller that
AADConnect is contacting. To verify that this is the issue, check the domain controller
that AADC uses for import (see "Connectivity to AD"), and use the AD Users and
Computers console to directly connect to this server (see Change Domain Controller in
the next image). Then, verify that the data on this server corresponds to the latest data,
and whether it is consistent with the respective ADCS data. At this stage, AADC will
generate a greater load on the domain controller and networking layer.
Another approach is to use the RepAdmin tool to check the object's replication
metadata on all domain controllers, get the value from all domain controllers, and check
replication status between domain controllers:

Attribute value from all domain controllers:

repadmin /showattr * "DC=contoso,DC=com" /subtree

/filter:"sAMAccountName=User01" /attrs:pwdLastSet,UserPrincipalName

Object metadata from all DCs:

repadmin /showobjmeta * "CN=username,DC=contoso,DC=com" > username-

ObjMeta.txt

AD Replication Summary

repadmin /replsummary

Troubleshooting summary

Identify which domain controller is used.

Compare data between domain controllers.
Analyze the RepAdmin results.
Contact Directory Services or the network support team to help troubleshoot the
issue.

Domain and OU changes, and object types or attributes filtered or

excluded in ADDS Connector
Changing domain or OU filtering requires a full import
Keep in mind that even if the domain or OU filtering is confirmed, any changes to
domain or OU filtering take effect only after running a full import step.

Attribute filtering with Azure AD app and attribute filtering

An easy-to-miss scenario for attributes not synchronizing is when Azure AD

Connect is configured with the Azure AD app and attribute filtering feature. To
check whether the feature is enabled, and for which attributes, take a General
Diagnostics Report.

Object type excluded in ADDS Connector configuration

This situation does not occur as commonly for users and groups. However, if all the
objects of a specific object type are missing in ADCS, it might be useful to examine
which object types enabled in ADDS Connector configuration.

You can use the Get-ADSyncConnector cmdlet to retrieve the object types that are
enabled on the Connector, as shown in the next image. The following are the
object types that should be enabled by default:

(Get-ADSyncConnector | where Name -eq "Contoso.com").ObjectInclusionList

The following are the object types that should be enabled by default:

７ Note

The publicFolder object type is present only when the Mail Enabled Public
Folder feature is enabled.

Attribute excluded in ADCS

In the same manner, if the attribute is missing for all objects, check whether the
attribute is selected on the AD Connector.

To check for enabled attributes in ADDS Connector, use the Synchronization

Manager, as shown in the next image, or run the following PowerShell cmdlet:

(Get-ADSyncConnector | where Name -eq "Contoso.com").AttributeInclusionList

 ７ Note

Including or excluding object types or attributes in the Synchronization

Service Manager is not supported.

Troubleshooting summary

Check the Azure AD app and attribute filtering feature

Verify that the object type is included in ADCS.
Verify that the attribute is included in ADCS.
Run a full import.

Resources for Step 1

Main resources:

Get-ADSyncConnectorAccount - Identify the correct Connector account used by

AADC

ADConnectivityTool

Identify connectivity problems with ADDS

Trace-ADSyncToolsADImport (ADSyncTools) - Trace data being imported from

ADDS

LDIFDE - Dump object from ADDS to compare data between ADDS and ADCS

LDP - Test AD Bind connectivity and permissions to read object in the security
context of ADCA
 DSACLS - Compare and evaluate ADDS permissions

Set-ADSync< Feature >Permissions - Apply default AADC permissions in ADDS

RepAdmin - Check AD object metadata and AD replication status

Step 2: Synchronization between ADCS and MV

Objective for Step 2

This step checks whether the object or attribute flows from CS to MV (in other words,
whether the object or attribute is projected to the MV). At this stage, make sure that the
object is present, or that the attribute is correct in ADCS (covered in Step 1), and then
start looking at the synchronization rules and lineage of the object.

Description for Step 2

The synchronization between ADCS and MV occurs on the delta/full synchronization
step. At this point, AADC reads the staged data in ADCS, processes all sync rules, and
updates the respective MV object. This MV object will contain CS links (or connectors)
pointing to the CS objects that contribute to its properties and the lineage of sync rules
that were applied in the synchronization step. During this stage, AADC generates more
load on the SQL Server (or LocalDB) and networking layers.

Troubleshooting ADCS > MV for objects

Check the inbound sync rules for provisioning

An object that is present in ADCS but missing in MV indicates that there were no
scoping filters on any of the provisioning sync rules that applied to that object.
Therefore, the object was not projected to MV. This issue might occur if there are
disabled or customized sync rules.

To get a list of inbound provisioning sync rules, run the following command:
Get-ADSyncRule | where {$_.Name -like "In From AD*" -and $_.LinkType -eq

"Provision"} | select Name,Direction,LinkType,Precedence,Disabled | ft

Check the lineage of the ADCS object

You can retrieve the failing object from the ADCS by searching on "DN or Anchor"
in "Search Connector Space." On the Lineage tab, you will probably see that the
object is a Disconnector (no links to MV), and the lineage is empty. Also, check
whether the object has any errors, in case there is a sync error tab.

Run a preview on the ADCS object

Select Preview > Generate Preview > Commit Preview to see whether the object
is projected to MV. If that's the case, then a full sync cycle should fix the issue for
other objects in the same situation.
Export the object to XML

For a more detailed analysis (or for offline analysis), you can collect all the
database data that's related to the object by using the Export-ADSyncObject
cmdlet. This exported information will help determine which rule is filtering out the
object. In other words, which Inbound Scoping Filter in the Provisioning Sync Rules
is preventing the object from being projected to the MV.

Here are some examples of Export-ADsyncObject syntax:

Import-Module "C:\Program Files\Microsoft Azure Active Directory

Connect\Tools\AdSyncTools.psm1"
 Export-ADsyncObject -DistinguishedName

'CN=TestUser,OU=Sync,DC=Domain,DC=Contoso,DC=com' -ConnectorName
'Domain.Contoso.com'

Export-ADsyncObject -ObjectId '{46EBDE97-7220-E911-80CB-000D3A3614C0}' -

Source Metaverse -Verbose

Troubleshooting summary (objects)

Check the scoping filters on the "In From AD" inbound provisioning rules.
Create a preview of the object.
Run a full sync cycle.
Export the object data by using the Export-ADSyncObject script.

Troubleshooting ADCS > MV for attributes

1. Identify the inbound sync rules and transformation rules of the attribute

Each attribute has its own set of transformations rules that are responsible for
directing the value from ADCS to MV. The first step is to identify which sync rules
contain the transformation rule for the attribute that you're troubleshooting.

The best way to identify which sync rules have a transformation rule for a given
attribute is to use the built-in filtering capabilities of the Synchronization Rules
Editor.

2. Check the Lineage of the ADCS Object

Each connector (or link) between the CS and MV will have a lineage that contains
information about the sync rules that are applied to that CS object. The previous
step will tell you which set of inbound sync rules (whether provisioning or joining
sync rules) must be present in the object's lineage to flow the correct value from
ADCS to MV. By examining the lineage on the ADCS object, you'll be able to
determine whether that sync rule was applied to the object.
 If there are multiple connectors (multiple AD forests) linked to the MV object, you
might have to examine the Metaverse Object Properties to determine which
connector is contributing the attribute value to the attribute that you're trying to
troubleshoot. After you've identified the connector, examine the lineage of that
ADCS object.

3. Check the scoping filters on the inbound sync rule

If a sync rule is enabled but not present in the object's lineage, the object should
be filtered out by the sync rule's scoping filter. By checking the sync rule's scoping
filters, the data on the ADCS object, and whether the sync rule is enabled or
disabled, you should be able to determine why that sync rule was not applied to
the ADCS object.

Here is an example of a common troublesome scoping filter from a sync rule

responsible for synchronizing Exchange properties. If the object has a null value for
 mailNickName, then none of the Exchange attributes in the transformation rules
will flow to Azure AD.

4. Run a preview on ADCS object

If you can't determine why the sync rule missing in the ADCS object's lineage, run
a preview by using Generate Preview and Commit Preview for a full
synchronization of the object. If the attribute is updated in the MV and has a
preview, then a full sync cycle should fix the issue for other objects in the same
situation.

5. Export the object to XML

For a more detailed analysis or offline analysis, you can collect all the database
data that's related to the object by using the Export-ADSyncObject script. This
exported information can help you determine which sync rule or transformation
rule missing on the object that's preventing the attribute from being projected to
the MV (see the Export-ADSyncObject examples earlier in this article).

Troubleshooting summary (for attributes)

Identify the correct sync rules and transformation rules responsible for flowing the
attribute to the MV.
Check the lineage of the object.
Check whether sync rules have been enabled.
Check the scoping filters of the sync rules that are missing in the object's lineage.

Advanced troubleshooting of the sync rule pipeline

If you have to further debug the ADSync engine (also known as the MiiServer) in terms
of sync rule processing, you can enable ETW tracing on the .config file (C:\Program
Files\Microsoft Azure AD Sync\Bin\miiserver.exe.config). This method generates an
extensive verbose text file that shows all the processing of sync rules. However, it might
be difficult to interpret all the information. Use this method as a last resort or if it's
indicated by Microsoft Support.

Resources for Step 2

Synchronization Service Manager UI

Synchronization Rules Editor
Export-ADsyncObject script
Start-ADSyncSyncCycle -PolicyType Initial
ETW tracing SyncRulesPipeline (miiserver.exe.config)

Step 3: Synchronization between MV and

AADCS

Objective for Step 3

This step checks whether the object or attribute flows from MV to AADCS. At this point,
make sure that the object is present, or that the attribute is correct in ADCS and MV
(covered in Steps 1 and 2). Then, examine the synchronization rules and lineage of the
object. This step is similar to Step 2, in which the inbound direction from ADCS to MV
was examined, However, at this stage, we'll concentrate on the outbound sync rules and
attribute that flows from MV to AADCS.

Description for Step 3

The synchronization between MV and AADCS occurs in the delta/full synchronization
step, when AADC reads the data in MV, processes all sync rules, and updates the
respective AADCS object. This MV object will contain CS links (also known as
connectors) that point to the CS objects that contribute to its properties and the lineage
of the sync rules that were applied in the synchronization step. At this point, AADC
generates more load on SQL Server (or localDB) and the networking layer.
Troubleshooting MV to AADCS for objects
1. Check the outbound sync rules for provisioning

An object that is present in MV but missing in AADCS indicates that there were no
scoping filters on any of the provisioning sync rules that applied to that object. For
example, see the "Out to AAD" sync rules shown in the next image. Therefore, the
object was not provisioned in AADCS. This error can occur if there are disabled or
customized sync rules.

To get a list of inbound provisioning sync rules, run the following command:

Get-ADSyncRule | where {$_.Name -like "Out to AAD*" -and $_.LinkType -eq

"Provision"} | select Name,Direction,LinkType,Precedence,Disabled | ft

2. Check the lineage of the ADCS object

To retrieve the failing object from the MV, use a Metaverse Search, and then
examine the connectors tab. On this tab, you can determine whether the MV
object is linked to an AADCS object. Also, check whether the object has any errors,
in case a sync error tab is present.

If no AADCS connector is present, the object is most likely set to

cloudFiltered=True. You can verify whether the object is cloud-filtered by
examining the MV attributes for which sync rule is contributing with the
cloudFiltered value.

3. Run a Preview on AADCS object

 Select Preview > Generate Preview > Commit a Preview to determine whether the
object connects to AADCS. If so, then a full sync cycle should fix the issue for other
objects in the same situation.

4. Export the object to XML

For a more detailed analysis or offline analysis, you can collect all the database
data that's related to the object by using the Export-ADSyncObject script. This
exported information, together with the (outbound) sync rules configuration, can
help determine which rule is filtering out the object, and can determine which
outbound scoping filter in the provisioning sync rules is preventing the object from
connecting with the AADCS).

Here are some examples of Export-ADsyncObject syntax:

Import-Module "C:\Program Files\Microsoft Azure Active Directory

Connect\Tools\AdSyncTools.psm1"

Export-ADsyncObject -ObjectId '{46EBDE97-7220-E911-80CB-000D3A3614C0}' -

Source Metaverse -Verbose

Export-ADsyncObject -DistinguishedName 'CN=

{2B4B574735713744676B53504C39424D4C72785247513D3D}' -ConnectorName
'Contoso.onmicrosoft.com - AAD'

Troubleshooting summary for objects

Check the scoping filters on the "Out to AAD" outbound provisioning rules.
Create a preview of the object.
Run a full sync cycle.
Export the object data by using the Export-ADSyncObject script.

Troubleshooting MV to AADCS for attributes

1. Identify the outbound sync rules and transformation rules of the attribute

Each attribute has its own set of transformation rules that are responsible to flow
the value from MV to AADCS. Begin by identifying which sync rules contain the
transformation rule for the attribute that you're troubleshooting.

The best way to identify which sync rules have a transformation rule for a given
attribute is to use the built-in filtering capabilities of the Synchronization Rules
Editor.
2. Check the lineage of the ADCS object

Each connector (or link) between the CS and MV will have a lineage that contains
information about the sync rules applied to that CS object. The previous step will
tell you which set of outbound sync rules (whether provisioning or joining sync
rules) must be present in the object's lineage to flow the correct value from MV to
AADCS. By examining the lineage on the AADCS object, you can determine
whether that sync rule has been applied to the object.

3. Check the scoping filters on the outbound sync rule

If a sync rule is enabled but not present in the object's lineage, it should be filtered
out by the sync rule's scoping filter. By checking the presence of the sync rule's
scoping filters, and the data on the MV object, and whether the sync rule is
enabled or disabled, you should be able to determine why that sync rule wasn't
applied to the AADCS object.
 4. Run a preview on AADCS object

If you determine why the sync rule is missing from the ADCS object's lineage, run a
preview that uses Generate Preview and Commit Preview for a full
synchronization of the object. If the attribute is updated in the MV by having a
preview, then a full sync cycle should fix the issue for other objects in the same
situation.

5. Export the object to XML

For a more detailed analysis or offline analysis, you can collect all the database
data that's related to the object by using the "Export-ADSyncObject" script. This
exported information, together with the (outbound) sync rules configuration, can
help you determine which sync rule or transformation rule is missing from the
object that's preventing the attribute from flowing to AADCS (see the "Export-
ADSyncObject" examples earlier).

Troubleshooting summary for attributes

Identify the correct sync rules and transformation rules that are responsible to flow
the attribute to AADCS.
Check the lineage of the object.
Check that the sync rules are enabled.
Check the scoping filters of the sync rules that are missing in the object's lineage.

Troubleshoot the sync rule pipeline

If you have to further debug the ADSync engine (also known as the MiiServer) in terms
of sync rule processing, you can enable ETW tracing on the .config file (C:\Program
Files\Microsoft Azure AD Sync\Bin\miiserver.exe.config). This method generates an
extensive verbose text file that shows all the processing of sync rules. However, it might
be difficult to interpret all the information. Use this method only as a last resort or if it's
indicated by Microsoft Support.

Resources
Synchronization Service Manager UI
Synchronization Rules Editor
Export-ADsyncObject script
Start-ADSyncSyncCycle -PolicyType Initial
ETW tracing SyncRulesPipeline (miiserver.exe.config)
Step 4: Synchronization between AADCS and
AzureAD

Objective for Step 4

This stage compares the AADCS object with the respective object that's provisioned in
Azure AD.

Description for Step 4

Multiple components and processes that are involved in importing and exporting data
to and from Azure AD can cause the following issues:

Connectivity to the internet

Internal firewalls and ISP connectivity (for example, blocked network traffic)
The Azure AD Gateway in front of DirSync Webservice (also known as the
AdminWebService endpoint)
The DirSync Webservice API
The Azure AD Core directory service

Fortunately, the issues that affect these components usually generate an error in event
logs that can be traced by Microsoft Support. Therefore, these issues are out of scope
for this article. Nevertheless, there are still some "silent" issues that can be examined.
Troubleshooting AADCS
Multiple Active AADC servers exporting to AAD

In a common scenario in which objects in Azure AD flip attribute values back and
forth, there are more than one active AADConnect servers, and one of these
servers loses contact with the local AD but is still connected to the internet and
able to export data to Azure AD. Therefore, every time that this "stale" server
imports a change from AAD on a synchronized object that's made by the other
active server, the sync engine reverts that change based on the stale AD data that's
in the ADCS. A typical symptom in this scenario is that you make a change in AD
that's synced to Azure AD, but the change reverts to the original value a few
minutes later (up to 30 minutes). To quickly mitigate this issue, return to any old
servers or virtual machines that have been decommissioned, and check whether
the ADSync service is still running.

Mobile attribute with DirSyncOverrides

When the Admin uses MSOnline or AzureAD PowerShell module, or if the user
goes to the Office Portal and updates the Mobile attribute, the updated phone
number will be overwritten in AzureAD despite the object being synced from on-
premises AD (also known as DirSyncEnabled).

Together with this update, Azure AD also sets a DirSyncOverrides on the object to
flag that this user has the mobile phone number "overwritten" in Azure AD. From
this point on, any update to the mobile attribute that originates from on-premises
will be ignored because this attribute will no longer be managed by on-premises
AD.

For more information about the BypassDirSyncOverrides feature and how to

restore synchronization of Mobile and otherMobile attributes from Azure AD to
on-premises Active Directory, see How to use the BypassDirSyncOverrides feature
of an Azure AD tenant.

UserPrincipalName changes do not update in Azure AD

If the UserPrincipalName attribute is not updated in Azure AD, while other

attributes sync as expected, it's possible that a feature that's named
SynchronizeUpnForManagedUsers is not enabled on the tenant. This scenario
occurs frequently.

Before this feature was added, any updates to the UPN that came from on-
premises after the user was provisioned in Azure AD and assigned a license were
"silently" ignored. An admin would have to use MSOnline or Azure AD PowerShell
to update the UPN directly in Azure AD. After this feature is updated, any updates
to UPN will flow to Azure AD regardless of whether the user is licensed (managed).

７ Note

After it's enabled, this feature cannot be disabled.

UserPrincipalName updates will work if the user is NOT licensed. However, without
the SynchronizeUpnForManagedUsers feature, UserPrincipalName changes after
the user is provisioned and is assigned a licensed that will NOT be updated in AAD.
Notice that Microsoft does not disable this feature on behalf of the customer.

Invisible characters and ProxyCalc internals

Issues that involve invalid characters that don't produce any sync error are more
troublesome in UserPrincipalName and ProxyAddresses attributes because of the
cascading effect in ProxyCalc processing that will silently discard the value from
on-premises AD. This situation occurs as follows:

1. The resulting UserPrincipalName in Azure AD will be the MailNickName or

CommonName @ (at) initial domain. For example, instead of
John.Smith@Contoso.com, the UserPrincipalName in AAD might become
smithj@Contoso.onmicrosoft.com because there's an invisible character in
the UPN value from on-premises AD.

2. If a ProxyAddress contains a space character, ProxyCalc will discard it and

autogenerate an email address based on MailNickName at Initial Domain.
For example, "SMTP: John.Smith@Contoso.com" will not appear in AAD
because it contains a space character after the colon.

3. Either a UserPrincipalName that includes a space character or a

ProxyAddress that includes an invisible character will cause the same issue.

To troubleshoot a space character in the UserPrincipalName or

ProxyAddress, examine the value that's stored in the local AD from an
LDIFDE or PowerShell exported to a file. An easy trick is to copy the contents
of the exported file, and then paste it into a PowerShell window. The invisible
character will be replaced by a question mark (?), as shown in the following
example.
 ThumbnailPhoto attribute (KB4518417)

There is a general misconception that after you sync ThumbnailPhoto from AD for
the first time, you can no longer update it, which is only partly true.

Usually, the ThumbnailPhoto in Azure AD is continually updated. However, an

issue occurs if the updated picture is no longer retrieved from Azure AD by the
respective workload or partner (for example, EXO or SfBO). This issue causes the
false impression that the picture was not synced from on-premises AD to Azure
AD.

Basic steps to troubleshoot ThumbnailPhoto

1. Make sure that the image is correctly stored in AD and doesn't exceed the
size limit of 100 KB.

2. Check the image in the Accounts Portal or use Get-

AzureADUserThumbnailPhoto because these methods read the
ThumbnailPhoto directly from Azure AD.

3. If the AD (or AzureAD) thumbnailPhoto has the correct image but is not
correct on other online services, the following conditions might apply:

The user's mailbox contains an HD image and is not accepting low-resolution

images from Azure AD thumbnailPhoto. The solution is to directly update the
user's mailbox image.
The user's mailbox image was updated correctly, but you're still seeing the
original image. The solution is to wait at least six hours to see the updated
image in the Office 365 User Portal or the Azure portal.

Additional resources
Troubleshooting Errors during synchronization
Troubleshoot object synchronization with Azure AD Connect sync
Troubleshoot an object that is not synchronizing with Azure Active Directory
Azure AD Connect Single Object Sync
Contact us for help
If you have questions or need help, create a support request , or ask Azure community
support. You can also submit product feedback to Azure community support.
Troubleshoot Azure AD Certificate-
Based Authentication issues
Article • 04/20/2022 • 7 minutes to read

The Certificate-Based Authentication feature in Microsoft Azure Active Directory (AD) for

iOS or Android devices allows Single Sign-On (SSO) by using X.509 certificates. By
enabling this feature, you can log in to accounts or services without having to enter a
user name and password when you connect to your Exchange Online account or Office
mobile applications.

This article provides information to help you troubleshoot Certificate-Based

Authentication issues.

Original product version:   Azure Active Directory

Original KB number:   4032987

General requirements
Certificate-Based Authentication supports only Federated environments by using
Modern Authentication (ADAL). The one exception is Exchange ActiveSync (EAS)
for Exchange Online that can be used by Managed Accounts.
The user certificate that's issued in the user's profile requires the user's routable
email address to be listed in the Subject Alternative Name. This can be in either
the UserPrincipalName or RFC822 format. Azure AD maps the RFC822 value to the
Proxy Address attribute in the directory.

Determine if Certificate-Based Authentication

works on Azure portal
1. Browse to the Azure portal from the device for testing the Certificate-Based
Authentication.

７ Note

The browser cache must be cleared before you try the connection in order for
the user to see the certificate approval prompt.

2. Type the user's email address. This redirects to the ADFS authentication page.
 3. Instead of typing a password (if the forms-based authentication method is enabled
in ADFS), select Sign in using an X.509 certificate, and approve the use of the
client certificate when you are prompted.

If no certificate approval prompt is received after you clear the browser cache on a

device, follow these steps:
a. Verify that the user certificate and the issuing certificate authority root
certificates are installed on the device.
b. Verify that TCP port 49443 is open on the ADFS/Web Application Proxy servers,
and that the certificate chain of the issuing certificate authority is installed on all
ADFS/Web Application Proxy servers.

Determine if Azure AD is correctly configured

1. Run the following PowerShell command to Install the Azure Active Directory
PowerShell (Preview) module:

PowerShell

Install-Module AzureAD

2. To create a trusted certificate authority, use the New-

AzureADTrustedCertificateAuthority cmdlet, and set the crlDistributionPoint
attribute to a correct value.

７ Note

When you create the TrustedRootCertificateAuthority objects in Azure AD,

the CRL URLs that are defined within the .CER file are not used. The
CrlDistributionPoin and DeltaCrlDistributionPoint values must be manually
populated by a web location where Azure AD can access the CRLs. The CRL
paths within the issued certificates do not have to contain the URLs that are
accessible to Azure AD. Also, large CRLs that take more than 15 seconds to
download should be put on a faster link, such as Azure Storage, to avoid
caching delays that can cause intermediate authentication failures.

PowerShell

$cert=Get-Content -Encoding byte "[LOCATION OF THE CER FILE]"

$new_ca=New-Object -TypeName
Microsoft.Open.AzureAD.Model.CertificateAuthorityInformation
$new_ca.AuthorityType=0 $new_ca.TrustedCertificate=$cert
 $new_ca.crlDistributionPoint="<CRL Distribution URL>"

New-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation
$new_ca

3. Make sure that the following values are correctly defined on the
TrustedCertificateAuthority objects according to the following guidelines:

All CrlDistributionPoin and DeltaCrlDistributionPoint URLs must be

accessible from the Internet by the client devices and the ADFS and Web
Application Proxy servers.

The *.CER for the Root CA should be listed as AuthorityType =

RootAuthority.

The *.CER for the Intermediate CA should be listed as follows:

AuthorityType = IntermediateAuthority

AuthorityType = 0 = RootAuthority

AuthorityType = 1 = IntermediateAuthority

７ Note

To make changes to these objects, see Configure the certificate authorities.

4. Run the following commands to make sure that the ADFS settings are not set to
PromptLoginBehavior: true. Otherwise, users will be prompted to enter their user
name and password for some modern apps.

PowerShell

Connect-msolService

PowerShell

Get-MSOLDomainFederationSettings -DomainName contoso.com

７ Note

This occurs because some modern apps send prompt=login to Azure AD in

their request. Azure AD translates this in the ADFS request to
wauth=usernamepassworduri (this tells ADFS to do username/password
authentication) and wfresh=0 (tells ADFS to ignore the SSO state and do a
 fresh authentication). If users have to use Certificate Based Authentication, the
PromptLoginBehavior must be set to False.

To disable PromptLoginBehavior on the Azure AD domain, run the following

command:

PowerShell

Set-MSOLDomainFederationSettings -domainname <domain> -

PromptLoginBehavior Disabled

Determine if the ADFS and Web Application

Proxy configurations are configured correctly
1. Certificate-Based Authentication requires ADFS 2012R2 or a later version, and it
must use Web Application Proxy.

７ Note

Using a third-party Web Application Proxy is not supported unless it supports

all the MUSTs in the MS-ADFSPIP protocol document.

2. The Root *.CER file must be in the computer's Trusted Root Certificate
Authority\Certificates container. Also, all Intermediate *.CER files must be in the
computer's Intermediate Root Certificate Authority\Certificates container. You
can verify this by running certlm.msc  or by running the following certutil.exe
commands at an elevated command prompt:

Console

certutil -verifystore root

Console

certutil -verifystore CA**

3. The client devices, the ADFS servers, and the Web Application Proxy must be able
to resolve the CRL endpoints that exist on the Intermediate CA *.CER and on the
user certificates that were issued to the user profile on the devices.
To verify that the ADFS servers and the Web Application Proxy can resolve these,
follow these steps:
a. Export the Intermediate CA *.CER:
i. View the computer certificate store. To do this, run certlm.msc, expand
\Intermediate Certification Authorities\Certificates, and then double-click
the Intermediate CA certificate.
ii. Click the Details tab, and then click the Copy to file button.
iii. Click Next two times and accept all the defaults in the wizard.
iv. Specify a file name and location, click Next, and then click Finish.
b. On the issuing CA, export one of the user certificates that was issued to a
device. To do this, follow these steps:  

i. Run certsrv.msc, and then select the Issued Certificates node.

ii. In the Issued Common Name column, locate the certificate that was issued
to the user who cannot connect.

iii. Double-click the certificate, and then click the Details  tab to export the
certificate to a *.CER file.

７ Note

If more than one certificate is issued to the user, locate the serial

number for the certificate on the Details  tab, and verify that it matches
the certificate on the device.

iv. Download PSEXEC.EXE , and then copy psexec.exe together with the *.CER
files from the Intermediate CA and user to all ADFS and Web Application
Proxy servers.

v. Open a new command prompt in the SYSTEM security context. To do this,

open an elevated command prompt for each server, and then run the
following command:

Console

psexec -s -i -d cmd.exe

vi. At the new command prompt, run the following commands to determine

whether the CRL can be accessed:

Console
 certutil.exe -verify -urlfetch SubCA.cer >
%computername%_%username%_SubCA.txt

Console

certutil.exe -verify -urlfetch usercert.cer >

%computername%_%username%_usercert.txt

vii. In the output, check the ---------------- Certificate CDP ----------------

section, and determine whether all endpoints can be resolved.

viii. If the ADFS servers cannot resolve the HTTP URL, make sure that the Group
Managed Service Accounts that ADFS is running under has access through
the firewall and proxy. The Web Application Proxy service runs under
Network Service, so the ComputerName$ account requires access through
the firewall and proxy.

4. Pass Through Claims for serialNumber and issuer must be configured for the

Active Directory Claims Provider Trust and for the Microsoft Office 365 Identity
Platform Relying Party Trust. These can be retrieved from the ADFS servers by
running the following PowerShell commands at an elevated prompt:

PowerShell

Get-AdfsClaimsProviderTrust -Name "Active Directory"

@RuleTemplate = "PassThroughClaims"

@RuleName = "<serialnumber AD for cert based auth>"

c:[Type ==

http://schemas.microsoft.com/ws/2008/06/identity/claims/serialnumber]

=> issue(claim = c);

@RuleTemplate = "PassThroughClaims"

@RuleName = "<Issuer AD for cert based auth>"

c:[Type ==

http://schemas.microsoft.com/2012/12/certificatecontext/field/issuer]

=> issue(claim = c);

PowerShell

Get-AdfsRelyingPartyTrust -Name "Microsoft Office 365 Identity

Platform"

@RuleTemplate = "PassThroughClaims"

@RuleName = "<serialnumber RP for cert based auth>"

c:[Type ==

http://schemas.microsoft.com/ws/2008/06/identity/claims/serialnumber]

=> issue(claim = c);

@RuleTemplate = "PassThroughClaims"

@RuleName = "<Issuer RP for cert based auth>"

 c:[Type ==

http://schemas.microsoft.com/2012/12/certificatecontext/field/issuer]

=> issue(claim = c);

5. Because most devices that use certificate authentication are likely to be located
on the extranet (out of the corporate network), you could enable Certificate-Based
Authentication only for the extranet or also for the Intranet, as necessary. To
determine whether the "Certificate Authentication" method is enabled for either or
both options, run the following cmdlet from an elevated PowerShell command
prompt:

PowerShell

Get-AdfsAuthenticationProvider:

----------Output sample----------

AdminName : Certificate Authentication

AllowedForPrimaryExtranet : True

AllowedForPrimaryIntranet : True

AllowedForAdditionalAuthentication : True

AuthenticationMethods : {urn:ietf:rfc:2246,
urn:oasis:names:tc:SAML:1.0:am:X509-PKI,

urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient,

urn:oasis:names:tc:SAML:2.0:ac:classes:X509...}

Descriptions : {}

DisplayNames : {}

Name : CertificateAuthentication

IdentityClaims : {}

IsCustom : False

RequiresIdentity : False

a. Locate the AdminName entry that is named Certificate Authentication.

b. Verify that AllowedForPrimaryExtranet is set to True.
c. Optionally, you can also set AllowedForPrimaryIntranet to True if you want
Certificate-Based Authentication from Intranet users.
d. Click the Details tab, and then click the Copy to file button.

6. TCP port 49443 must be accessible between the client device and ADFS,  also
between the client device and Web Application Proxy servers. To verify that TCP
49443 is listening and bound to ADFS on the ADFS servers and Web Application
Proxy, run the following command:

Console

netsh http show urlacl > %computername%_49443.txt

 If the TCP port 49443  is accessible, you should see output such as the following:

Console

Reserved URL: https://<URL>:49443/adfs/

User: NT SERVICE\adfssrv

Listen: Yes

Delegate: Yes

SDDL: D:(A;;GA;;;S-1-5-80-2246541699-21809830-3603976364-117610243-
975697593)

7. On a client device, try to connect to the CertificateTransport endpoint. For

example, use the following URL for Contoso.com :

https://sts.contoso.com:49443/adfs/services/trust/2005/certificatetransport

７ Note

If the endpoint is accessible and listening, the connection attempt should spin
indefinitely while it waits for an answer.

More information
Azure AD: Certificate based authentication for iOS and Android now in preview.
Get started with certificate based authentication on iOS - Public Preview
ADFS: Certificate Authentication with Azure AD & Office 365

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
How to troubleshoot password synchronization when
using an Azure AD sync appliance
Article • 04/20/2022 • 9 minutes to read

This article helps you troubleshoot common issues that you may encounter when you synchronize passwords from the on-
premises environment to Azure Active Directory (Azure AD) by using Azure AD Connect.

Original product version:   Cloud Services (Web roles/Worker roles), Azure Active Directory, Microsoft Intune, Azure Backup,
Office 365 Identity Management

Original KB number:   2855271

Before you start troubleshooting

Before you perform the troubleshooting steps, make sure that you have the latest version of Azure AD Connect installed.

Additionally, make sure that directory synchronization is in a healthy state. For more information, see Troubleshoot object
synchronization with Azure AD Connect sync.

Some users can't sign in to Office 365, Azure, or Microsoft Intune

In this scenario, passwords of most users appear to be syncing. However, there are some users whose passwords appear
not to sync. The following are scenarios in which a user can't sign in to a Microsoft cloud service, such as Office 365, Azure,
or Intune.

Scenario 1: The "User must change password at next logon" check box is
selected for the user's account
To resolve this issue, follow these steps:

1. Take one of the following actions:

In the user account properties in Active Directory Users and Computers, clear the User must change password
at next logon check box.
Have the user change their on-premises user account password.
Enable the ForcePasswordChangeOnLogOn feature on the Azure AD Connect server.

2. Wait a few minutes for the change to sync between the on-premises Active Directory Domain Services (AD DS) and
Azure AD.

Scenario 2: The user changed their password in the cloud service portal
To resolve this issue, follow these steps:

1. Have the user change their on-premises user account password.

2. Wait a few minutes for the change to sync between the on-premises AD DS and Azure AD.

Scenario 3: Some users don't appear to be syncing to Azure AD

Possible causes are duplicate user names or email addresses.

To resolve this issue, use the IdFix DirSync Error Remediation Tool (IdFix) to help identify potential object-related issues in
the on-premises AD DS. You can install IdFix at the following Microsoft website: IdFix DirSync Error Remediation Tool

For more info about how to troubleshoot this issue, see One or more objects don't sync when using the Azure Active
Directory Sync tool
Scenario 4: Users are moved between filtered and unfiltered scopes
In this scenario, the user is moved to a scope that now allows the user to be synced. It could be when filtering is set up for
domains, organizational units, or attributes.

To resolve this issue, see the How to perform a full password sync section.

Scenario 5: Users can't sign in by using a new password but they can sign in by
using their old password
In this scenario, you're using the Azure AD Sync Service together with password synchronization. After you disable and
then re-enable directory synchronization, users can't sign in by using a new password. However, their old password still
works.

To resolve this issue, re-enable password synchronization. To do it, start the Azure AD sync appliance Configuration Wizard,
and then continue through the screens until you see the option to enable password synchronization.

Scenario 6: Users can't sign in by using their password

In this scenario, the password hash doesn't successfully sync to the Azure AD Sync Service. If the user account was created
in Active Directory running on a version of Windows Server earlier than Windows Server 2003, the account doesn't have a
password hash.

Directory synchronization is running but passwords of all users

aren't synced
In this scenario, passwords of all users appear not to sync. It usually occurs if one of the following conditions is true:

The Synchronize now check box wasn't selected.

You enabled password synchronization after directory sync already occurred.
A full directory sync hasn't yet completed.

） Important

Password sync will not start until a full directory sync has completed.

To resolve this issue, first make sure that you enable password synchronization. To do it, start the Azure AD sync appliance
Configuration Wizard, and then continue through the screens until you see the option to enable password synchronization.

After password synchronization is enabled, you must do a full password sync. See How to perform a full password sync
section.

For more information, see Troubleshoot password hash synchronization with Azure AD Connect sync.

Troubleshoot one user whose password isn't synced

To troubleshoot this issue, see Troubleshoot password hash synchronization with Azure AD Connect sync

You're changing from a single-sign on (SSO) solution to password

synchronization
To resolve this issue, see How to switch from Single Sign-On to Password Sync .
Event ID messages in Event Viewer
The following tables list event ID messages in the Application log that are related to password synchronization.

Informational (no action required)

Event Description Cause

ID

650 Provision credentials batch start. Count: 1 Password synchronization starts retrieving updated passwords from the
on-premises AD DS.

651 Provision credentials batch end. Count: 1 Password synchronization finishes retrieving updated passwords from the
on-premises AD DS.

653 Provision credentials ping start. Password synchronization starts informing Azure AD that there are no
passwords to be synced. It occurs every 30 minutes if no passwords have
been updated in the on-premises AD DS.

654 Provision credentials ping end. Password synchronization finishes informing Azure AD that there are no
passwords to be synced. It occurs every 30 minutes if no passwords were
updated in the on-premises AD DS.

656 Password Change Request - Anchor : Password synchronization indicates that a password change was detected
H552hI9GwEykZwosf74JeOQ==, Dn : CN=Viola and tries to sync it to Azure AD. It identifies the user or users whose
Hanson,OU=Cloud Objects,DC=contoso,DC=local, password changed and will be synced. Each batch contains at least one
Change Date : 05/01/2013 16:34:08 user and at most 50 users.

657 Password Change Result - Anchor : Users whose password successfully synced.
eX5b50Rf+UizRIMe2CA/tg==, Dn : CN=Viola
Hanson,OU=Cloud Objects,DC=contoso,DC=local,
Result : Success.

657 Password Change Result - Anchor : Users whose password didn't sync.
eX5b50Rf+UizRIMe2CA/tg==, Dn : CN=Viola
Hanson,OU=Cloud Objects,DC=contoso,DC=local,
Result : Failed.

Informational (may require action)

Event Description Cause More information

ID

0 The following password changes User or users whose Configure directory synchronization

failed to synchronized and have password wasn't synced

scheduled for retry.
One or more objects don't sync when using the Azure
Active Directory Sync tool
DN = CN=Eli McLean,OU=Cloud
Objects,DC=contoso,DC=local

115 Access to Windows Azure Active Azure AD credentials were Run the Azure AD Configuration Wizard again. See
Directory has been denied. Contact updated through Forefront Password hash synchronization stops working after you
Technical Support. Identity Manager (FIM). update Azure Active Directory credentials in FIM

657 Password Change Result - Anchor : User or users whose Configure directory synchronization

B0H+OD3LM0GEnYODwdPhpg==, password wasn't synced

Result : failed, Extended Error : One or more objects don't sync when using the Azure
Active Directory Sync tool

Error (action required)

Event Description Cause More

ID information
Event Description Cause More
ID information

0 The user name or password is incorrect. Verify your user name, and then type your password again. Azure AD Run the Azure
credentials AD
were updated Configuration
through Wizard again.
Forefront See Password
Identity hash
Manager (FIM). synchronization
stops working
after you
update Azure
Active Directory
credentials in
FIM

611 Password synchronization failed for domain: Contoso.com .

Windows Password hash
Server 2003 synchronization
Microsoft.Online.PasswordSynchronization.SynchronizationManagerException: Recovery task failed. domain for Azure AD
---> Microsoft.Online.PasswordSynchronization.DirectoryReplicationServices.DrsException: RPC controllers stops working
Error 8439 : The distinguished name specified for this replication operation is invalid. There was an handle certain and Event ID
error calling _IDL_DRSGetNCChanges. scenarios 611 is logged
unexpectedly.

611 Password synchronization failed for domain: Contoso.com .

It was a known To resolve this
issue that was issue, update to
Microsoft.Online.PasswordSynchronization.DirectoryReplicationServices.DrsException: RPC Error fixed in Azure latest version of
8593 : The directory service cannot perform the requested operation because the servers involved Active Directory the Azure
are of different replication epochs (which is usually related to a domain rename that is in progress). Sync tool build Active Directory
1.0.6455.0807. Sync tool.

611 Password synchronization failed for domain: Contoso.com

It was a known To resolve this
issue that was issue, update to
System.ArgumentOutOfRangeException: Not a valid Win32 fixed in Azure latest version of
Active Directory the Azure
Sync tool build Active Directory
1.0.6455.0807. Sync tool.

611 Password synchronization failed for domain: Contoso.com .

It was a known To resolve this
issue that was issue, update to
System.ArgumentException: An item with the same key has already been added. fixed in Azure latest version of
Active Directory the Azure
Sync tool build Active Directory
1.0.6455.0807. Sync tool.

652 Failed credential provisioning batch. Error: Microsoft.Online.Coexistence.ProvisionException: An Password Configure

error occurred. Error Code: 90. Error Description: Password Synchronization has not been activated synchronization directory
for this company. Tracking ID: 07e93e8a-cf2d-4f67-9e95-53169c4875e0 Server Name: failed when synchronization
BL2GR1BBA003. ---> retrieving
System.ServiceModel.FaultException1[Microsoft.Online.Coexistence.Schema.AdminWebServiceFault]: updated One or more
Password Synchronization has not been activated for this company. (Fault Detail is equal to passwords from objects don't
Microsoft.Online.Coexistence.Schema.AdminWebServiceFault). the on- sync when
premises AD using the Azure
DS. Active Directory
Sync tool

652 Failed credential provisioning batch. Error: Microsoft.Online.Coexistence. ProvisionRetryException : It was a known To resolve this
An error occurred. Error Code: 81. Error Description: Windows Azure Active Directory is currently issue that was issue, update to
busy. This operation will be retried automatically. fixed in Azure latest version of
Active Directory the Azure
Sync tool build Active Directory
1.0.6455.0807 Sync tool.
Event Description Cause More
ID information

655 Failed credential provisioning ping. Error: Microsoft.Online.Coexistence.ProvisionException: An error Password Configure
occurred. Error Code: 90. Error Description: Password Synchronization has not been activated for synchronization directory
this company. Tracking ID: 0744fa31-1d9b-453a-83d8-c2555d843802 Server Name: BL2GR1BBA005. failed to inform synchronization
---> Azure AD that
System.ServiceModel.FaultException1[Microsoft.Online.Coexistence.Schema.AdminWebServiceFault]: there are no One or more
Password Synchronization has not been activated for this company. (Fault Detail is equal to passwords to objects don't
Microsoft.Online.Coexistence.Schema.AdminWebServiceFault). be synced. It sync when
occurs every 30 using Azure
minutes. Active Directory
Sync tool

655 The user name or password is incorrect. Verify your user name, and then type your password again. Azure AD Run the Azure
credentials AD
were updated Configuration
through FIM. Wizard again.
See the
following
Microsoft
Knowledge
Base article:
Password hash
synchronization
stops working
after updating
Azure Active
Directory
credentials in
FIM

6900 The server encountered an unexpected error while processing a password change notification:
Azure AD Run the Azure
credentials AD
"The user name or password is incorrect. Verify your user name, and then type your password again. were updated Configuration
through FIM. Wizard again.
See the
following
Microsoft
Knowledge
Base article:
Password hash
synchronization
stops working
after updating
Azure Active
Directory
credentials in
FIM

6900 The server encountered an unexpected error while processing a password change notification:
Password sync See the
isn't enabled following
"An error occurred. Error Code: 90. Error Description: Password Synchronization has not been for the Microsoft
activated for this company organization. Knowledge
Base article:
User passwords
aren't synced,
and "Password
Synchronization
has not been
activated for
this company"
error is logged
in Event Viewer
More information

How to perform a full password sync

To do a full password sync, follow these steps, as appropriate for the Azure AD sync appliance that you're using.

1. If you're using the Azure Active Directory Sync tool:

a. On the server where the tool is installed, open PowerShell, and then run the following command:

PowerShell

Import-Module DirSync

b. Run the following commands:

PowerShell

Set-FullPasswordSync

PowerShell

Restart-Service FIMSynchronizationService -Force

2. If you're using the Azure AD Sync Service or Azure AD Connect, run the script that's on this page: Azure AD Sync: How
to Use PowerShell to Trigger a Full Password Sync

Contact us for help

If you have questions or need help, create a support request , or ask Azure community support.
Error when you try to use the New-
MSOLDomain command to add a
subdomain to an existing domain: New-
MsolDomain: Unable to add this domain
Article • 04/20/2022 • 2 minutes to read

Original product version:   Cloud Services (Web roles/Worker roles), Azure Active
Directory, Microsoft Intune, Azure Backup, Office 365 User and Domain Management,
Office 365 Identity Management

Original KB number:   2666578

Symptoms
You try to add a subdomain to an existing domain in a Microsoft cloud service such as
Office 365, Microsoft Intune, or Microsoft Azure by using the New-MSOLDomain
command. However, you receive the following error message:

New-MsolDomain: Unable to add this domain. It is a subdomain and its

authentication type is different from the authentication type of the root domain.

Cause
This issue occurs if you try to use the New-MSOLDomain command to add a subdomain
to an existing domain that's set up for federated authentication. The New-MSOLDomain
command tries to add the subdomain as a standard authentication domain.

Resolution
To add a subdomain to a domain that's set up for federated authentication, follow these
steps:

1. Connect to Azure Active Directory (Azure AD) by using Windows PowerShell. For
more information, see Connect to Azure AD Using Windows PowerShell.

2. Use the New-MSOLFederatedDomain command.

The syntax to add a subdomain is as follows, where <subdomain> is the name of

the subdomain that you want to add:
 PowerShell

New-MSOLFederatedDomain -DomainName:<subdomain>

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
"Unable to authenticate your
credentials" error when you try to
connect to Azure Active Directory
Article • 04/20/2022 • 2 minutes to read

Original product version:   Azure Active Directory, Cloud Services (Web roles/Worker
roles), Microsoft Intune, Azure Backup, Office 365 User and Domain Management, Office
365 Identity Management

Original KB number:   2929554

Symptoms
When you try to connect to Microsoft Azure Active Directory (Azure AD) by using the
Azure Active Directory Module for Windows PowerShell, you receive the following error
message:

Console

Connect-MsolService : Unable to authenticate your credentials. Make sure

that

your user name is in the format: <username>@<domain>. If this issue

persists,

contact Support.

At line:1 char:1

+ Connect-MsolService

+ ~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : OperationStopped: (:) [Connect-MsolService], Mic

rosoftOnlineException

+ FullyQualifiedErrorId : 0x80048862,Microsoft.Online.Administration.Autom

ation.ConnectMsolService

Cause
This issue occurs if one of the following conditions is true:

You used an incorrect format when you entered your user name.
Your user account is enabled for Azure AD Multi-Factor Authentication.

Resolution
Do one of the following, as appropriate for your situation.

Scenario 1: You used an incorrect format when you

entered your user name
Use the following format when you enter your user name:

<user_name >@<domain>

For example, john@contoso.com is in the correct format. Entering john or contoso\john

doesn't work.

Scenario 2: Your user account is enabled for Azure AD

Multi-Factor Authentication
If your user account is enabled for Azure AD Multi-Factor Authentication, Microsoft
doesn't currently support using the Azure Active Directory Module for Windows
PowerShell to connect to Azure AD.

To perform administrative tasks by using the Azure Active Directory Module for
Windows PowerShell, use either of the following methods:

Disable Azure Active Directory Multi-Factor Authentication for the user account.
Use a different admin account that isn't enabled for Azure Active Directory Multi-
Factor Authentication.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Error when you run the Azure AD
Connect wizard: Unable to configure
password writeback
Article • 09/23/2022 • 2 minutes to read

This article describes an issue in which an error message appears when you run the
Azure AD Connect wizard to set up password writeback.

Original product version:   Azure Active Directory

Original KB number:   3185990

Symptoms
When you run the Azure AD Connect wizard, you receive the following error message
during configuration of password writeback:

Unable to configure password writeback. Ensure you have the required license.

Cause
This issue occurs if one of the following conditions are true:

The administrator account that's used to set up Azure AD Connect does not have
the appropriate license.
The time on the server on which Azure AD Connect is installed is out of sync.
The TLS setting is configured correctly.

Resolution
To reoslve this problem, follow these steps:

1. Enable TLS 1.2.

2. Make sure that the administrator account that you use to enable password
writeback is a cloud administrator account (created in Azure AD) and not a
federated account (created in the on-premises Active Directory and synchronized
to Azure AD). Also, make sure that the account has the appropriate Azure AD
subscription license.
 3. Make sure that the time isn't skewed. On the authoritative time server, perform the
steps in the Configuring the Windows Time service to use an external time
source section of How to configure an authoritative time server in Windows
Server

Make sure that the time on the server on which Azure AD Connect is installed matches
the time on the authoritative time server.

More information
If the issue you're experiencing is a scenario in which there's a large time difference
between your local environment and Microsoft cloud services,

you may see the following entries in the Azure AD Connect sync logs. The logs are
located in the %appdata%\Local\AADConnect folder.

Console

Error <Date> <Time> ADSync 6306 Server "The server encountered an unexpected
error while performing an operation for the client.

Error <Date> <Time> ADSync 6800 MA Extension "The password management

extension encountered an error.

The stack trace is:

""Couldn't connect to any service bus endpoint(s)

Error <Date> <Time> PasswordResetService 32001 None TrackingId: 3f369fe9-

c121-4450-8661-82b095bdbf0a,

Couldn't connect to any service bus endpoint(s), Details:

Error <Date> <Time> PasswordResetService 31044 None TrackingId: 3f369fe9-

c121-4450-8661-82b095bdbf0a,

Password writeback service is not in a healthy state. No serviceHost for

service bus endpoints are in

running state. Please refer aka.ms/ssprtroubleshoot, Details: Version:

5.0.0.686

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Error when you run the Azure Active
Directory Sync Tool Configuration
Wizard: Unknown error (0x80005000)
Article • 04/20/2022 • 2 minutes to read

This article provides a resolution to resolve an issue where you receive an error message
when you run the Azure Active Directory Sync Tool Configuration Wizard.

Original product version:   Office 365 Identity Management, Azure Active Directory,
Cloud Services (Web roles/Worker roles), Microsoft Intune, Azure Backup

Original KB number:   3003331

Symptoms
When you run the Azure Active Directory Sync Tool Configuration Wizard, the tool fails,
and you receive the following error message:

Error

Unknown error (0x80005000)

Cause
This problem occurs if the Azure Active Directory Sync Tool Configuration Wizard cannot
configure the domain.

Resolution
To resolve this problem, make sure that all domain controllers are running in a healthy
state. To determine which domain or domain controller is causing the problem, follow
these steps:

1. On the server on which the Azure Active Directory Sync Tool is installed, start
Windows PowerShell.

2. Run the following commands:

PowerShell
 $Forest =
[System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().d
omains

PowerShell

$Forest

3. Examine the information in the output.

In the following example, the dev.contoso.com domain is unreachable. You can

determine this because information about the domain is missing in the output, as
in the following example.

Forest : contoso.com

DomainControllers : {ContosoDC01.contoso.com}

Children : {dev.contoso.com}

DomainMode : Windows2008R2Domain

Parent :

PdcRoleOwner : ContosoDC01.contoso.com

RidRoleOwner : ContosoDC01.contoso.com

InfrastructureRoleOwner : ContosoDC01.contoso.com

Name : contoso.com

Forest :

DomainControllers :

Children :

DomainMode :

Parent :

PdcRoleOwner :

RidRoleOwner :

InfrastructureRoleOwner :

Name : dev.contoso.com

4. Investigate and resolve the problem. Most likely, the domain controller that's
hosting the domain is not running or is not in the network.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
How to use UPN matching for identity
synchronization in Office 365, Azure, or
Intune
Article • 04/20/2022 • 3 minutes to read

Original product version:   Azure Active Directory, Cloud Services (Web roles/Worker
roles), Microsoft Intune

Original KB number:   3164442

Introduction
Sometimes you may have to transfer the source of authority for a user account if that
account was originally authored by using Microsoft cloud services management tools.
These tools include:

The Office 365 portal

Microsoft Azure Active Directory Module for Windows PowerShell
Azure Management Portal
Intune portal

You can transfer the source of authority，so the account can be managed through your
local directory service when using identity synchronization with Azure Active Directory
(Azure AD).

This article discusses how to perform the transfer by using a process known as UPN
matching. This process uses the user principal name (UPN) to match the on-premises
user account to a work or school account in Azure AD.

UPN matching limitations

The UPN matching process has the following technical limitations:

UPN matching can be run only when SMTP matching fails. For more information
about SMTP matching, see How to use SMTP matching to match on-premises user
accounts to Office 365 user accounts for directory synchronization . For UPN
matching to work, make sure that there are no primary SMTP address matches
between on-premises user accounts and user accounts in Azure AD.
 UPN matching can be used only one time for user accounts that were originally
authored by using Office 365 management tools. After that, the work or school
account is bound to the on-premises user by an immutable identity value, not the
UPN.

The cloud user's UPN can't be updated during the UPN matching process. It's
because the UPN is the value that's used to link the on-premises user to the cloud
user.

UPNs are considered unique values. Make sure that no two users have the same
UPN. Otherwise, the sync process fails, and you may receive an error message that
resembles the following example:

Unable to update this object in Microsoft Online Services because the user
principal name that is associated with this object in the local Active Directory is
already associated with another object. To resolve this error, remove the
associated object in your local Active Directory.

How to use UPN matching to match an on-

premises user to a cloud identity
To start the UPN matching process, follow these steps:

1. If you started syncing to Azure AD before March 30, 2016, run the following Azure
AD PowerShell cmdlet to enable UPN soft match for your organization only:

PowerShell

Set-MsolDirSyncFeature -Feature EnableSoftMatchOnUpn -Enable $True

７ Note

UPN soft match is automatically enabled for organizations that started

syncing to Azure AD on or after March 30, 2016.

2. Obtain the UPN from the user account in Azure AD. To do so, use one of the
following methods:

Method 1: Use the Office 365 portal.

a. Sign in to the Office 365 portal as a global admin.
b. Go to the users management page.
 c. Find and then select the user.
d. Note the user name, which is the UPN.

Method 2: Use the Azure portal.

a. Sign in to the Azure portal as a global admin.
b. Select the Active Directory extension, and then select your directory.
c. Go to the users management page.
d. Find and then select the user.
e. Note of the user name, which is the UPN.

3. On a domain controller or a computer that has the Remote Server Administration

Tools installed (RSAT), open Active Directory Users and Computers. Create a user
account, or update an existing user account, by using a user name/UPN that
matches the target user account in Azure AD. For more information, see Create a
User Account in Active Directory Users and Computers.

4. Force directory synchronization. For more information, see Force directory

synchronization .

More information
For more information about UPN soft match, see Azure AD Connect sync service
features.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
User object is missing or filtered from
the Azure Active Directory connector in
Azure Active Directory Sync
Article • 04/20/2022 • 2 minutes to read

This article describes an issue that blocks synchronization for a user object from on-
premises to Azure. A workaround is provided.

Original product version:   Azure Active Directory

Original KB number:   3066176

Symptoms
When you try to sync a user object to Microsoft Azure Active Directory (Azure AD), the
operation is unsuccessful.

When you search for the user object in the metaverse objects, you see only the Active
Directory connector listed on the Connectors tab. The Windows Azure Active Directory
(AAD) connector is not listed. Additionally, no error is returned for this particular user.

You may also notice that the msExchRecipientTypeDetails value for the user object that's
not synchronized correctly is 2. This corresponds with the Linked Mailbox type, and the
user does not have this value.

７ Note

The following value is the only value that triggers filtering of a user object:
msExchRecipientTypeDetails == (0x1000 OR 0x2000 OR 0x4000 OR 0x400000 OR
0x800000 OR 0x1000000 OR 0x20000000) .

For more information about user objects that are filtered, see
How directory
synchronization determines what isn't synced from the on-premises environment to
Windows Azure AD .

Cause
This issue occurs because there is a rule for the sourceAnchor attribute. The rule is used
to determine whether the value of msexchRecipientTypeDetails is 2.
 ７ Note

You can view this rule in the following location: Sync Rules Configuration
Editor\Inbound\In From AD\Common\Transformation. You can also see the target
sourceAnchor attribute and the expression rule as follows:
IIF(IsPresent([msExchRecipientTypeDetails]),IIF([msExchRecipientTypeDetails]=2,NULL,
IIF(IsString([objectGUID]),CStr([objectGUID]),ConvertToBase64([objectGUID]))),IIF(IsStri
ng([objectGUID]),CStr([objectGUID]),ConvertToBase64([objectGUID])))

If msExchRecipientTypeDetails has a value of 2, the value of sourceAnchor is set to

NULL. However, if the value of sourceAnchor is NULL, the user will be filtered.

Workaround
To work around this issue, do one of the following:

Make sure that the Master user account (in Account forest) is synchronized first.
Change the attribute value of msExchRecipientTypeDetails to 1. Use any value
that's not supposed to be filtered by either of the rules.

More information
According to DirSync: List of attributes that are synced by the Azure Active Directory
Sync Tool , one reason a user object is filtered is because of the following:

Console

msExchRecipientTypeDetails == (0x1000 OR 0x2000 OR 0x4000 OR 0x400000 OR

0x800000 OR 0x1000000 OR 0x20000000)

It's an assumption that if the msExchRecipientTypeDetails attribute on a user is set to a

value of 2, the AADSync server will filter this object. This is not true. AADSync is not
filtering this user object, it's just waiting for the master account (from account forest) to
join to the object because it's needed for the UPN and the sourceAnchor.

A value of 2 for the msExchRecipientTypeDetails attribute indicates that the mailbox

type is a "linked mailbox". A linked mailbox is found in an account-resource forest
topology and the user object in account forest must be synchronized before these
resource objects will be provisioned to Azure AD.
Therefore, with the msExchRecipientTypeDetails set to 2 the object is not filtered.
However, when this flag is set, the AADSync waits for the master account (from account
forest) to be synced so that it could join the two objects and create a cloud connector
for the final user object in AADSync.

In the scenario that you do not have an account-resource forest topology, and a user
has msExchRecipientTypeDetails value is 2, changing the value to a value that is similar
to a usual object will sync the user object.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Azure AD Connect excludes a user's
primary group from its group
membership
Article • 04/20/2022 • 2 minutes to read

Original product version:   Azure Active Directory

Original KB number:   4014115

Summary
Microsoft Azure Active Directory (Azure AD) Connect doesn't support primary group
functionality. Therefore, it does not query the PrimaryGroupID attribute to build the
group membership of a user. This may cause problems for users who are still using the
primary group feature.
When you set the primary group for a user, that user is excluded from the
corresponding group membership in Active Directory. Instead, the PrimaryGroupID
attribute is set with that group.

For example:

1. User1 belongs to Group1, which means that Group1 has User1 as a member.
2. The primary group is changed on User1 from Domain Users to Group1:
a. User1 is excluded from Group1 Members.
b. User1 is added as a member of Domain Admins (because it's no longer the
primary group).
c. The User1 PrimaryGroupID attribute is set with the Group1 reference.

Programs that need to query groups to give users access that is based on group
membership should also query for the PrimaryGroupID attribute. However, Azure AD
Connect does not support PrimaryGroupID because of the complexity of group
membership synchronization.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Users in a federated domain see a
yellow exclamation mark in Office 2013
applications
Article • 04/20/2022 • 2 minutes to read

This article describes an issue in which users in a federated domain who aren't synced to
Azure Active Directory (Azure AD) see a yellow exclamation mark in Office 2013
applications.

Original product version:   Azure Active Directory, Office Professional 2013, Office
Standard 2013

Original KB number:   3158020

Symptoms
When a user who is in a federated domain but isn't synchronized to Azure AD opens an
Office 2013 application, they see a yellow exclamation mark.

Cause
By default, Office 2013 uses the Microsoft Online Services Sign-in Assistant (also known
as IDCRL). IDCRL detects that the user's domain is federated and therefore tries to
authenticate the user to Azure AD. Because the user isn't synced to Azure AD, the user
doesn't exist in Azure AD, and this triggers the yellow exclamation mark in the Office
2013 application.

Resolution
Do one of the following.

Set the SignInOptions registry key value to 3

） Important

Follow the steps in this section carefully. Serious problems might occur if you
modify the registry incorrectly. Before you modify it, back up the registry for
restoration in case problems occur.
 ７ Note

Use this procedure for only those users who aren't synced to Azure AD. Using this
procedure for synced users may cause those users to experience sign-in failures.

To resolve this issue for only those users who aren't synced to Azure AD, follow these
steps:

1. Select Start, select Run, type regedit, and then select OK.
2. Locate the following registry subkey:
HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common\SignIn\ .

3. Right-click the SignInOptions registry key, select Modify, type 3 in the Value data
box, and then select OK.
4. Exit Registry Editor. Set the SignInOptions registry key to 3 forces Office 2013 to
authenticate only against the user's local Active Directory service instead of trying
to sign the user in to Azure AD.

Use Office 2016

The yellow exclamation mark isn't displayed in Office 2016 applications.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Error when signing out of online
services: Sorry, but we're having trouble
signing you out
Article • 09/30/2022 • 2 minutes to read

Original product version:   Cloud Services (Web roles/Worker roles), Azure Active
Directory, Microsoft Intune, Azure Backup, Office 365 Identity Management

Original KB number:   2871385

Symptoms
When you try to sign out of online services that use Microsoft Azure Active Directory
(Azure AD), you receive the following error message:

Sorry, but we're having trouble signing you out

Resolution
Use one of the following methods.

Method 1
To sign out, close all web browsers.

Method 2
Clear cookies from the web browser, and then try signing out again. The steps for doing
this vary, depending on the browser that you're using. For more information, see the
following resources:

If you're using Internet Explorer, see How to delete cookie files in Internet
Explorer .
If you're using Safari, go to the following Apple websites:
Safari on Mac
Safari on iOS
If you're using Google Chrome, go to the following Google website: Manage your
cookies and site data .
 If you're using Mozilla Firefox, go to the following Mozilla website: Clear cookies
and site data in Firefox .

Microsoft provides third-party contact information to help you find technical support.
This contact information may change without notice. Microsoft does not guarantee the
accuracy of this third-party contact information.

More information
This problem occurs if third-party cookies are turned on in your web browser. We do not
recommend turning on the use of third-party cookies.

The third-party products that this article discusses are manufactured by companies that
are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about
the performance or reliability of these products.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
How to enable and disable a trace for
the Microsoft Online Services Sign-in
Assistant
Article • 09/30/2022 • 3 minutes to read

This article discusses how to enable and disable a trace for the Microsoft Online Services
Sign-in Assistant. The log files that are generated can help troubleshoot issues that may
occur when you use the Sign-in Assistant in a Microsoft Office 365 environment.

Original product version:   Cloud Services (Web roles/Worker roles), Azure Active
Directory, Microsoft Intune, Azure Backup, Office 365 User and Domain Management

Original KB number:   2433327

７ Note

Use this article only with applications that use the Microsoft Online Services Sign-In
Assistant to assist in authentication to Azure Active Directory (Azure AD).

） Important

Follow the steps in this section carefully. Serious problems might occur if you
modify the registry incorrectly. Before you modify it, back up the registry for
restoration in case problems occur.

Enable debug tracing for the Microsoft Online

Services Sign-in Assistant
To enable debug tracing for the Microsoft Online Services Sign-in Assistant, follow these
steps:

1. Start Notepad, copy and paste the following text to a new file, and then save the
file as Enable_SIA_Debug_Tracing.reg:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSOIdentityCRL\Trace]

 "Folder"="C:\\MSOTrace"

"Flags"=dword:00000001

"level"=dword:00000099

"maxsize"=dword:10485760

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSOIdentityCRL\Trace
]

"Folder"="C:\\MSOTrace"

"Flags"=dword:00000001

"level"=dword:00000099

"maxsize"=dword:10485760

[HKEY_CURRENT_USER\Software\Microsoft\MSOIdentityCRL\Trace]

"Folder"="C:\\MSOTraceLite"

"Flags"=dword:00000001

"level"=dword:00000099

"maxsize"=dword:10485760

2. Run the Enable_SIA_Debug_Tracing.reg file on the computer that's experiencing

the issue to update the registry.

3. Restart the Microsoft Online Services Sign-in Assistant service (if it's installed).

７ Note

The Microsoft Online Services Sign-in Assistant service is required to be

installed only on systems that are running pre-Office 2013 versions of Office
or on systems that use PowerShell to connect to Office 365. If the Microsoft
Online Services Sign-in Assistant service isn't installed on your system, go to
step 4.

To restart the Microsoft Online Services Sign-in Assistant service, do one of the
following:

Select Start, type services.msc in the search box, and then press Enter. Right-
click the Microsoft Online Services Sign-in Assistant service, and then select
Restart.

Open an administrative command prompt, and then run the following

commands (press Enter after each command):

Console

net stop msoidsvc

Console
 net start msoidsvc

4. Reproduce the suspected authentication issue on the computer on which tracing is

enabled.

5. On drive C, locate the MSOTrace and MSOTraceLite folders. These folders contain
the trace files. The names of the trace files are in the following format:

msoidsvctrace{GUID}.txt

７ Note

When the Microsoft Online Services Sign-in Assistant service is running, you
can't rename or delete the debug trace because the file is being used by a
process. However, you can create a copy of the debug trace that you can then
move to another folder or another computer for review.

6. Examine the debug trace files for any relevant exception messages.

Disable debug tracing for the Microsoft Online

Services Sign-in Assistant
To disable debug tracing for the Microsoft Online Services Sign-in Assistant, follow these
steps:

1. Open Notepad, copy and paste the following text to a new file, and then save the
file as Disable_SIA_Debug_Tracing.reg:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSOIdentityCRL\Trace]

"Folder"="C:\\MSOTrace"

"Flags"=dword:00000000

"level"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSOIdentityCRL\Trace
]

"Folder"="C:\\MSOTrace"

"Flags"=dword:00000000

"level"=dword:00000000

[HKEY_CURRENT_USER\Software\Microsoft\MSOIdentityCRL\Trace]

 "Folder"="C:\\MSOTraceLite"

"Flags"=dword:00000000

"level"=dword:00000000

2. Run the Disable_SIA_Debug_Tracing.reg file on the computer that's experiencing

the issue to update the registry.

3. Restart the Microsoft Online Services Sign-in Assistant service (if it's installed).

７ Note

The Microsoft Online Services Sign-in Assistant service is required to be

installed only on systems that are running pre-Office 2013 versions of Office
or on systems that use PowerShell to connect to Office 365. If the Microsoft
Online Services Sign-in Assistant service isn't installed on your system, omit
this step.

To restart the Microsoft Online Services Sign-in Assistant service, do one of the
following:

Select Start, type services.msc in the search box, and then press Enter. Right-
click the Microsoft Online Services Sign-In Assistant service, and then select
Restart.

Open an administrative command prompt, and then run the following

commands (press Enter after each command):

Console

net stop msoidsvc

Console

net start msoidsvc

Analyze logs
Log file locations depend on the specifics of the Folder registry entry that's listed earlier.
In this example, the log is located in the C:\MSOTrace or C:\MSOTraceLite folder,
depending on the application that performs authentication.
Contact us for help
If you have questions or need help, create a support request , or ask Azure community
support.
Error when you run the IdFix tool:
IdFix.exe is not a valid Win32
application
Article • 09/30/2022 • 2 minutes to read

Original product version:   Cloud Services (Web roles/Worker roles), Azure Active
Directory, Microsoft Intune, Azure Backup, Office 365 Identity Management

Original KB number:   2859165

Symptoms
When you try to run the IdFix DirSync Error Remediation Tool in your on-premises Active
Directory Domain Services (AD DS) environment, you receive the following error
message:

IdFix.exe is not a valid Win32 application

Cause
This issue occurs if you're running the IdFix tool on an operating system that's not
supported for the tool.

Resolution
Install and run the IdFix tool on a computer that's running the 64-bit version of
Windows 7 or a later version.

More information
For more information about the IdFix tool, see IdFix DirSync Error Remediation Tool
(This includes a list of system requirements.).

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
IPv6 support in Azure Active Directory
Article • 02/02/2023 • 7 minutes to read

We're excited to bring IPv6 support to Azure Active Directory (Azure AD), to support
customers with increased mobility, and help reduce spending on fast-depleting,
expensive IPv4 addresses. For more information about how this change might affect
Microsoft 365, see IPv6 support in Microsoft 365 services.

If your organization's networks don't support IPv6 today, you can safely ignore this
information until such time that they do.

What's changing?
Our service endpoint URLs will now resolve to return both IPv4 and IPv6 addresses. If a
client platform or network supports IPv6, the connection will mostly be attempted using
IPv6, assuming that the network hops that are in between (such as firewalls or web
proxies) also support IPv6. For environments that don't support IPv6, client applications
will continue to connect to Azure AD over IPv4.

The following features will also support IPv6 addresses:

Named locations
Conditional Access policies
Identity Protection
Sign-in logs

When will IPv6 be supported in Azure AD?

We'll begin introducing IPv6 support to Azure AD in late March 2023.

We know that IPv6 support is a significant change for some organizations. We're
publishing this information now so that customers can make plans to ensure readiness.

What does my organization have to do?

If you have public IPv6 addresses representing your network, take the actions that are
described in the following sections as soon as possible.

For example:
 Some organizations have a Conditional Access policy that blocks access to specific
applications from outside a trusted named location that represents their public
network addresses. This named location contains the IPv4 addresses that are owned
by the customer, but it might not include the public IPv6 addresses that represent
the customer network.

If customers don't update their named locations with these IPv6 addresses, their
users will be blocked.

Named locations
Named locations are shared between many features, such as Conditional Access,
Identity Protection, and B2C. Customers should partner with their network
administrators and internet service providers (ISPs) to identify their public-facing IPv6
addresses. Customers should then use this list to create or update named locations, to
include their identified IPv6 addresses.

Azure AD per-user multifactor authentication

If you're a customer who uses per-user multifactor authentication, have you added IPv4
addresses that represent on-premises trusted networks using trusted IP addresses
instead of named locations? If you have, you might see a multifactor authentication
prompt for a request that was initiated through on-premises IPv6-enabled egress
points.

Using per-user multifactor authentication isn't recommended, unless your Azure AD

licenses don't include Conditional Access and you don't want to use security defaults.

Outbound traffic restrictions

If your organization restricts outbound network traffic to specific IP ranges, you'll have
to update these addresses to include IPv6 endpoints. Administrators can find these IP
ranges in the following articles:

Office 365 URLs and IP address ranges

Azure AD Connect: Troubleshoot Azure AD connectivity issues

For the IP ranges that are specified for Azure AD, make sure that you allow outbound
access in your proxy or firewall.

Device configuration
By default, both IPv6 and IPv4 traffic is supported on Windows and most other
operating system (OS) platforms. Changes to the standard IPv6 configuration may result
in unintended consequences. For more information, see Guidance for configuring IPv6
in Windows for advanced users.

Test Azure AD authentication over IPv6

You can test Azure AD authentication over IPv6 before we enable it worldwide in late
March 2023. This procedure helps validate IPv6 range configurations. The recommended
approach is to use a Name Resolution Policy Table (NRPT) rule pushed to your Azure
AD-joined Windows devices. In Windows Server, NRPT lets you implement a global or
local policy that overrides DNS resolution paths. With this feature, you can redirect DNS
for various fully qualified domain names (FQDNs) to special DNS servers that are
configured to have IPv6 DNS entries for Azure AD sign-in. It's simple to enable and
disable NRPT rules by using a PowerShell script. You can use Microsoft Intune to push
this feature to clients.

７ Note

Microsoft is providing these instructions for testing purposes only. You must
remove the following configurations by May 2023 to ensure that your clients are
using production DNS servers. The DNS servers in the following procedures may be
decommissioned after May 2023.

Configure a client NRPT rule manually

1. Open a PowerShell console as an administrator (right-click the PowerShell icon and
select Run As Administrator).

2. Add an NRPT rule by running the following commands:

PowerShell

$DnsServers = (

"ns1-37.azure-dns.com.",

"ns2-37.azure-dns.net.",

"ns3-37.azure-dns.org.",

"ns4-37.azure-dns.info."

$DnsServerIPs = $DnsServers | Foreach-Object {

(Resolve-DnsName $_).IPAddress | Select-Object -Unique

$params = @{

 Namespace = "login.microsoftonline.com"

NameServers = $DnsServerIPs

DisplayName = "AZURE-AD-NRPT"
}

Add-DnsClientNrptRule @params

3. Verify that your client gets IPv6 responses for login.microsoftonline.com by

running the Resolve-DnsName cmdlet. The command output should resemble the
following text:

Console

PS C:\users\username> Resolve-DnsName login.microsoftonline.com

Name Type TTL Section IPAddress

---- ---- --- ------- ---------

login.microsoftonline.com AAAA 300 Answer 2603:1037:1:c8::8

login.microsoftonline.com AAAA 300 Answer

2603:1036:3000:d8::5

login.microsoftonline.com AAAA 300 Answer

2603:1036:3000:d0::5

login.microsoftonline.com AAAA 300 Answer

2603:1036:3000:d8::4

login.microsoftonline.com AAAA 300 Answer 2603:1037:1:c8::9

login.microsoftonline.com AAAA 300 Answer 2603:1037:1:c8::a

login.microsoftonline.com AAAA 300 Answer

2603:1036:3000:d8::2

login.microsoftonline.com AAAA 300 Answer

2603:1036:3000:d0::7

login.microsoftonline.com A 300 Answer 20.190.151.7

login.microsoftonline.com A 300 Answer 20.190.151.67

login.microsoftonline.com A 300 Answer 20.190.151.69

login.microsoftonline.com A 300 Answer 20.190.151.68

login.microsoftonline.com A 300 Answer 20.190.151.132

login.microsoftonline.com A 300 Answer 20.190.151.70

login.microsoftonline.com A 300 Answer 20.190.151.9

login.microsoftonline.com A 300 Answer 20.190.151.133

4. If you want to remove the NRPT rule, run this PowerShell script:

PowerShell

Get-DnsClientNrptRule | Where-Object {

$_.DisplayName -match "AZURE-AD-NRPT" -or $_.Namespace -match

"login.microsoftonline.com"

} | Remove-DnsClientNrptRule -Force

Deploy NRPT rule with Intune

To deploy the NRPT rule to multiple machines by using Intune, create a Win32 app and
assign it to one or more devices.

Step 1: Create the scripts

Create a folder, and then save the following installation and rollback scripts
(InstallScript.ps1 and RollbackScript.ps1) in it so that you can create the .intunewin file for
use in the deployment.

InstallScript.ps1

PowerShell

# Add Azure AD NRPT rule.

$DnsServers = (

"ns1-37.azure-dns.com.",

"ns2-37.azure-dns.net.",

"ns3-37.azure-dns.org.",

"ns4-37.azure-dns.info."

$DnsServerIPs = $DnsServers | Foreach-Object {

(Resolve-DnsName $_).IPAddress | Select-Object -Unique

# List the rules.

$existingRules = Get-DnsClientNrptRule | Where-Object {

$_.DisplayName -match "AZURE-AD-NRPT" -or $_.Namespace -match

"login.microsoftonline.com"

if ($existingRules) {

Write-Output ("Azure AD NRPT rule exists: {0}" -F $existingRules)

else {

Write-Output "Adding Azure AD NRPT DNS rule for

login.microsoftonline.com ..."

$params = @{

Namespace = "login.microsoftonline.com"

NameServers = $DnsServerIPs

DisplayName = "AZURE-AD-NRPT"

Add-DnsClientNrptRule @params
}

RollbackScript.ps1

PowerShell
 # Remove the Azure AD NRPT rule.

# List the rules.

$existingRules = Get-DnsClientNrptRule | Where-Object {

$_.DisplayName -match "AZURE-AD-NRPT" -or $_.Namespace -match

"login.microsoftonline.com"

if ($existingRules) {

Write-Output "Removing Azure AD NRPT DNS rule for

login.microsoftonline.com ..."

$existingRules | Format-Table

$existingRules | Remove-DnsClientNrptRule -Force

else {

Write-Output "Azure AD NRPT rule does not exist. Device was successfully
remediated."

DetectionScript.ps1

Save the following script (DetectionScript.ps1) in another location. Then, you can
reference the detection script in the application when you create it in Intune.

PowerShell

# Add Azure AD NRPT rule.

$DnsServers = (

"ns1-37.azure-dns.com.",

"ns2-37.azure-dns.net.",

"ns3-37.azure-dns.org.",

"ns4-37.azure-dns.info."

$DnsServerIPs = $DnsServers | Foreach-Object {

(Resolve-DnsName $_).IPAddress | Select-Object -Unique

# List the rules.

$existingRules = Get-DnsClientNrptRule | Where-Object {

$_.DisplayName -match "AZURE-AD-NRPT" -or $_.Namespace -match

"login.microsoftonline.com"

if ($existingRules) {

Write-Output 'Compliant'

Step 2: Package the scripts as a .intunewin file

See Prepare Win32 app content for upload to create a .intunewin file from the folder
and scripts that you previously saved.
Step 3: Create the Win32 application
The following instructions show you how to create the necessary Win32 application. For
more information, see Add, assign, and monitor a Win32 app in Microsoft Intune.

1. Sign in to the Intune portal .

2. Select Apps > All Apps, and then select + Add to create a new Win32 app.

3. In the App type dropdown list, select Windows app (Win32), and then choose
Select.

4. On the App information page, click Select app package file to select the
.intunewin file that you previously created. Select OK to continue.

5. Return to the App information page, and then enter a descriptive Name,
Description, and Publisher for the application. Other fields are optional. Select
Next to continue.

6. On the Program page, enter following information and select Next.

Install command string:

powershell.exe -executionpolicy bypass -NoLogo -NoProfile -

NonInteractive -WindowStyle Hidden -file "InstallScript.ps1"

Uninstall command string:

powershell.exe -executionpolicy bypass -NoLogo -NoProfile -

NonInteractive -WindowStyle Hidden -file "RollbackScript.ps1"

Install behavior:

System

7. In the Requirement page, select both Operating system architectures and set
Minimum Operating system to Windows 10 1607. Select Next to continue.

8. On the Detection page, select Use a custom detection script from the Rules
format dropdown list. Select the browse button beside the Script file box to
choose the detection script. Leave the remaining fields as their default values.
Select Next to continue.

9. Select Next on the Dependencies page to continue without any changes.

10. Select Next on the Supersedence (preview) page to continue without any
changes.

11. On the Assignments page, create assignments based on your requirements, and
then select Next to continue.
 12. Review the information one final time on the Review + create page. Once you
finish your validation, select Create to create the application.

Next steps
We'll keep this article updated. Here's a short link you can use to come back for updated
and new information: https://aka.ms/azureadipv6 .

Use the location condition in a Conditional Access policy

Conditional Access: Block access by location
Find help and get support for Azure Active Directory

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support. You can also submit product feedback to Azure community support.
Error when you run the IdFix tool:
Current security context is not
associated with an Active Directory
domain or forest
Article • 09/30/2022 • 2 minutes to read

Original product version:   Cloud Services (Web roles/Worker roles), Azure Active
Directory, Microsoft Intune, Azure Backup, Office 365 Identity Management

Original KB number:   2859144

Symptoms
When you run the IdFix DirSync Error Remediation Tool to perform a query in your on-
premises Active Directory Domain Services (AD DS) environment, you receive the
following error message:

Exception: Current security context is not associated with an Active Directory

domain or forest.

This issue occurs after you log on to the computer by using a user account that's not a
member of the domain in which you're running the query. The IdFix tool uses the
security context of the user who runs the tool to determine the domain to query.

Resolution
Log on to the computer by using a user account that's a member of the domain in
which you're running the query.

More information
For more information about the IdFix tool, see IdFix DirSync Error Remediation Tool .

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support.
Send Microsoft Authenticator logs and
get an incident ID
Article • 12/20/2022 • 2 minutes to read

Follow these steps to send logs to customer support and get the incident ID.

1. Open Microsoft Authenticator.

2. Tap Send feedback in the app's top menu.
3. Select Having trouble?.
4. Fill out the form, and then select Send to send the feedback and/or logs (Send is
on the top left on iOS, and on the top right on Android).
5. Note the incident ID. You or your administrator will need this ID if you contact
Microsoft Support.

Contact us for help

If you have questions or need help, create a support request , or ask Azure community
support. You can also submit product feedback to Azure community support.
Microsoft Azure Active Directory
diagnostic logs
Article • 09/30/2022 • 2 minutes to read

Original product version:   Azure Active Directory

Original KB number:   4494802

To troubleshoot issues that are related to Azure Active Directory (Azure AD), Microsoft
Support and the Azure Active Directory engineering team can view and download
diagnostic logs that are associated with your Azure AD tenant and on-premises
configuration. Microsoft may access (or make temporary copies of) the data to help
resolve your support incident.

More information
The following table explains the kinds of data that are associated with your Azure AD
tenant and that may be accessed while we troubleshoot your support incident.
Additionally, you may be asked to provide the same types of data from your company's
on-premises environment. Depending upon your tenant, this information may be
automatically uploaded to the Azure AD service or be requested by the Microsoft
Support Engineer to assist in troubleshooting your support incident.

Type Description

Microsoft Information that's maintained in the Azure AD tenant or synchronized from Active
Azure Active Directory on-premises environment, such as Tenant, User, Group, Device, and
Directory related metadata.
Objects

Service Tenant configuration and settings that are related to your Azure tenant
configuration

Azure AD Sign-in logs, audit logs, device registration logs, data previously uploaded (such
audit and as Authenticator App logs), and telemetry that is related to the health of service. 

sign-in logs
Note System-generated logs contain identifiable information about end users,
such as a user name. Telemetry contains primarily pseudonymized data, such as
unique identifiers that are generated by the system. This data cannot, on its own,
identify individual people. However, it can be used to deliver the enterprise
services to users.
Contact us for help
If you have questions or need help, create a support request , or ask Azure community
support.