Jorge's Quest For Knowledge!

All About Identity And Security On-Premises And In The Cloud – It's Just Like An Addiction, The More You Have, The More You Want To Have!

Archive for the ‘Azure AD Connect Health’ Category

(2017-06-19) Azure AD Connect Health For Sync To The Rescue

Posted by Jorge on 2017-06-19


I was playing around with some Azure AD (AAD) features and I required a new synched account in AAD. So I picked one of my existing accounts in the on-premises AD and added the user account to the groups that allowed it to sync to Azure AD, assign it a license for O365, assign a license for EMS and allow it to use SSPR. Instead of waiting for the next sync cycle I decided to force a delta sync within AAD Connect. So far so good. While AAD Connect was synching I decided to prepare some other things.

To my surprise I saw the following error in AAD Connect

image

Figure 1: Error In AAD Connect About “AttributeValueMustBeUnique”

Clicking on [Detail] I saw the following details regarding the error

image

Figure 2: Error Details In AAD Connect About “AttributeValueMustBeUnique”

ERROR = AttributeValueMustBeUnique
Unable to update this object because the following attributes associated with this object have values that may already be associated with another object in your local directory services: [ProxyAddresses SMTP:John.Doe@XXXXX;]. Correct or remove the duplicate values in your local directory. Please refer to
http://support.microsoft.com/kb/2647098 for more information on identifying objects with duplicate attribute values.
Tracking Id: xxxxxxxxxxxxxxxxxxxxxxxxxx
ExtraErrorDetails:
[{"Key":"ObjectId","Value":["xxxxxxxxxxxxxxxxxxxxxxxxx"]},{"Key":"ObjectIdInConflict","Value":["yyyyyyyyyyyyyyyyyyyyyy"]},{"Key":"AttributeConflictName","Value":["ProxyAddresses"]},{"Key":"AttributeConflictValues","Value":["SMTP:John.Doe@XXXXX"]}]

This is basically saying there is another object in AAD with the same value of "SMTP:John.Doe@XXXXX" in the proxyAddresses attribute

Now that was weird because the object with UPN ‘John.Doe@XXXXX’ was never synched to AAD as a user. To be sure I checked if there already was a user with the same UPN and/or proxyAddresses. As I expected there was none. I also knew for sure there was no conflicting object in the on-premises AD. Nevertheless I checked it with ADFIND (instead of PowerShell because hadn’t used for quite some time!). And again as expected there was none! So what the heck is going on!?

First I will tell you what was wrong and why, and after that I will guide you through troubleshooting

At this point in time I’m always using AAD Connect to sync stuff from AD to AAD. I also have a MIM Infrastructure using the AAD connector that also syncs stuff from AD to AAD and more specifically users, groups and contacts. However I had not used that for quite some time. What I had forgotten was that in the past I synched my mailbox enabled user accounts to AAD (Office 365) as contacts. So almost all on-premises users exist as contacts in AAD.

Definition of the issue:

The error in figure 2 is misleading as it is telling me to check my on-premises AD to resolve the conflict, but there is NO conflict in my on-premises AD!

Just to be sure I used:

  • ADFIND/PowerShell to query for any object with the same UPN value or the same proxyAddress value – Only 1 object was returned which was expected
  • IDFIX to check for conflicts – No conflicts found for this object in the on-premises AD – This was expected
  • Directory Synchronization Troubleshooter to check for conflicts – No conflicts found for this object in the on-premises AD – This was expected

Now it was time to check AAD. It had to be in AAD somewhere, but what was causing it!? I was looking at all troubleshooting capabilities.

I found the following blog posts that ONLY focus on user accounts in AAD

Looking at the error in figure 2:

  • “ObjectId” contains the objectID of the object I was trying to sync to AAD
  • “ObjectIdInConflict” contains the objectID of the object already in AAD with which the conflict was being caused

Therefore I needed to query AAD using the objectID in “ObjectIdInConflict”. I decided to use the CMDlets in the MSONLINE module

To look for users in AAD with that same objectID, I executed:

Get-MsolUser -ObjectId <objectid value in “ObjectIdInConflict”>

No result

To look for groups in AAD with that same objectID, I executed:

Get-MsolGroup -ObjectId <objectid value in “ObjectIdInConflict”>

No result

I suddenly remembered about my MIM infrastructure and what it was synching, so I decided to also execute:

Get-MsolContact -ObjectId <objectid value in “ObjectIdInConflict”>

Bingo! One object was returned! Yeah!

Now I do not have many objects. Howeverm if you do have many object, this might take quite some time as unfortunately the MSONLINE module does not have a CMDlet like ‘Get-MsolObject’. However, the AzureAD module does have such a CMDlet that allows you to search across object types, being:

Get-AzureADObjectByObjectId -ObjectIds <objectid value in “ObjectIdInConflict”>

Again, Bingo! One object was returned! Yeah!

I also received the following e-mail telling me about the conflict. To be honest, the mail is not really helpful from an informational perspective. It is however from a warning perspective. With the latter I mean it triggers me to go look in Azure AD Connect Health, which will tell me what is wrong and why.

image

Figure 3: Mail From AAD Telling Me About the Conflict Error

Another option for troubleshooting this is Azure AD Connect Health for Sync. Trust me when I say that Azure AD Connect Health tells what is wrong and why. It showed me the sync error including all the specifics around the error in one view. Really really helpful! Let’s have a look at this!

Go to the Azure AD Portal (https://portal.azure.com/) and then go to the Azure AD Connect Health blade. In my case I have Azure AD Connect Health for Sync, ADFS and AD. So should you!. Make it easy on yourself!

Although Azure AD Connect Sync tile so as healthy, to its left, does tell you there is a sync error. Click on that tile.

image

Figure 4: Azure AD Connect Health In The Azure AD Portal

A new window opens with all the sync errors by type. In this case it is about the “Duplicate Attribute” issue. I clicked on that tile

image

Figure 5: Azure AD Connect Health For Sync With Errors By Type

A new window opens with all the sync errors about “Duplicate Attributes”. In my case I had and saw an error about a duplicate value in the proxyAddresses attribute. I clicked on the listed object.

image

Figure 6: Azure AD Connect Health For Sync With A “Duplicate Attribute” Error For An Object

A new window opens with all the details about the “Duplicate Attribute” conflict and the objects involved. At the bottom you can see the conflicting attribute and the conflicting value. Now I know I have to get rid of the contact object to make it possible for the user account in AD to get a corresponding user account in AAD.

image

Figure 7: Azure AD Connect Health For Sync With “Duplicate Attribute” Error Details

BINGO!!! Smile

Now my suggestion for this is:

  • Make sure to get Azure AD Connect Health up and running
  • As soon as you see an error in AAD Connect (figure 1 and 2) or receive the e-mail (figure 3) about it, make sure to read it carefully. At this point in time I would say to go right away to the Azure AD Connect Health blade in the Azure AD Portal and check there what could be wrong. It is very likely it will tell you what is wrong and why!

Additional information:

Cheers,
Jorge

 

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Azure AD Connect, Azure AD Connect Health, PowerShell, Windows Azure Active Directory | 1 Comment »

(2017-01-15) Azure AD Connect Health Telling The ADFS Farm Just Dropped Dead!

Posted by Jorge on 2017-01-15


When you get any or all of the following mails from Azure AD Connect, your ADFS farm is hosed and you are in big trouble. Make sure this does NOT happen to you!

(Don’t worry, this is just my test/demo environment that was turned for the holidays)

image

image

image

Figure 1: E-mail From Azure AD Connect Health Mentioning The Token Signing Certificate Has Expired

image

image

image

Figure 2: E-mail From Azure AD Connect Health Mentioning The Token Encryption/Decryption Certificate Has Expired

image

image

Figure 3: E-mail From Azure AD Connect Health Mentioning The SSL Certificate Has Expired

In addition, your ADFS Admin Event Log only displays one color, RED, lots of it!

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Federation Services (ADFS), Azure AD Connect Health, Certificates, Windows Azure Active Directory | Leave a Comment »

(2016-07-20) Installing And Configuring Azure AD Connect Health For Active Directory Domain Services

Posted by Jorge on 2016-07-20


This blog post show you how to configure Azure AD Connect Health for AD/ADDS

First download the Azure AD Connect Health Agent for AD/ADDS from here

After the download move/copy the executable to every DC you want to install the Azure AD Connect Health for AD/ADDS on

Double-click on the executable

Click [Install]

image

Figure 1: Azure AD Connect Health – Install Screen

After the installation ends, you need to determine how your DCs have access to the internet.

If the DC has a direct connection, you need to only open up firewall ports first before continuing.

If the DC must have access through a proxy, you must configure the proxy settings first before continuing

There are several options to source the proxy settings from

[1] If you want to source the settings from Internet Explorer use: Set-AzureAdConnectHealthProxySettings -ImportFromInternetSettings

[2] If you want to source the settings from WinHTTP use: Set-AzureAdConnectHealthProxySettings -ImportFromWinHttp

[3] If you want to source the settings manually use: Set-AzureAdConnectHealthProxySettings -HttpsProxyAddress <PROXYSERVER>:<PORT>

Afterwards you can view the proxy settings in use by Azure AD Connect Health through: Get-AzureAdConnectHealthProxySettings

Additional info regarding the URLs accessed by Azure AD Connect Health see: https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-health-agent-install/

If your DC supports cookies and JavaScript or IE Enhanced Security Configuration has been disabled:

Click [Configure Now]

If your DC does not support cookies and JavaScript or IE Enhanced Security Configuration has been or is enabled:

Click [Close] and continue with figure 9

image

Figure 2: Azure AD Connect Health – Configure Screen

Specify either native Azure AD credentials or federated credentials. In either case, the credentials must have the Global Administrator role in Azure AD!

image

Figure 3: Azure AD Connect Health – Initial Credentials Screen

…because I used federated credentials, I’m redirected to ADFS

image

Figure 4: Azure AD Connect Health – Redirection To ADFS

…specify the password belonging to the specified user name

image

Figure 5: Azure AD Connect Health – Credentials Screen

…registration continues

image

Figure 6: Azure AD Connect Health – Registration Of The Agent

If you clicked [Configure Now] in figure 2 and your DC did not support cookies and JavaScript or IE Enhanced Security Configuration has been or is enabled, you will see the following message

Close the screen by clicking the red cross in the upper right corner

image

Figure 7: Azure AD Connect Health – Message About Cookies And/Or Javascript Not Being Supported

Closing the screen above throws the following errors

image

Figure 8: Azure AD Connect Health – Additional Errors

Open a new PowerShell command prompt window and type:

Import-Module AdHealthAdds

$azureADCreds = Get-Credential

Specify either native Azure AD credentials or federated credentials. In either case, the credentials must have the Global Administrator role in Azure AD!

image

Figure 9: Azure AD Connect Health – Starting Registration And Entering Native Azure Credentials

In the existing PowerShell command prompt window type:

Register-AzureADConnectHealthADDSAgent -Credential $azureADCreds

image

Figure 10: Azure AD Connect Health – Registration Of The Agent

Done! After doing on all the DCs, you can go to https://portal.azure.com/ and check the health of your AD/ADDS

PS: The installation of the Azure AD Connect Health Agent for ADFS is very similar!

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Domain Services (ADDS), Azure AD Connect Health, Azure AD Connect Health, Windows Azure Active Directory | Leave a Comment »

(2016-07-19) Azure AD Connect Health For Active Directory Domain Services Has Been Released

Posted by Jorge on 2016-07-19


Microsoft has released Azure AD Connect Health for AD/ADDS! COOL!

More information:

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

 

Posted in Active Directory Domain Services (ADDS), Azure AD Connect Health, Azure AD Connect Health, Windows Azure Active Directory | Leave a Comment »

(2016-05-16) Azure AD Connect Health Throws An Error During Azure AD Connect Install

Posted by Jorge on 2016-05-16


During the installation of Azure AD connect you might experience and see the following during the installation/configuration of the “Azure AD Connect Health Agent for Sync”

Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object

image

Figure 1: Azure AD Connect Health For Sync Crashing

The installation of “Azure AD Connect Health Agent for Sync” crashed, it tried to find a solution, and in the end I was allowed to close the program. This happened about 3 times or so. Then the regular azure AD Connect installation continued. The Sync Engine is working perfectly afterwards without any issues.

It may appear the “Azure AD Connect Health Agent for Sync” installation has failed. Au contraire! The installation of “Azure AD Connect Health Agent for Sync” succeeded, but its registration is actually failing!

With Azure AD Connect two components require internet access. A third, the Azure AD PowerShell CMDlets if installed in addition manually, also requires internet access.

If you are using direct connections you only need to open up the correct firewall ports to specific URLs/IP addresses.

If you are using a proxy server to connect through, the proxy server must be configured to allow all three components to target the proxy server for internet access to specific URLs/IP addresses

For authentication and access, both the Azure AD PowerShell CMDlets and Azure AD Connect Sync Engine requires access to the following URLs:
(Details –>
Office 365 URLs and IP address ranges)

  • *.microsoftonline.com (port 443)
  • *.windows.net(port 443)
  • secure.aadcdn.microsoftonline-p.com (port 443)
  • mscrl.microsoft.com (port 80)

For authentication and access, the Azure AD Connect Health Agent requires access to the following URLs:
(Details –>
Office 365 URLs and IP address ranges and Azure AD Connect Health Agent Installation)

  • *.blob.core.windows.net (port 443)
  • *.queue.core.windows.net (port 443)
  • *.table.core.windows.net(port 443)
  • *.servicebus.windows.net (port: 5671 recommended, if 5671 is blocked, the agent falls back to 443)
  • *.adhybridhealth.azure.com(port 443)
  • policykeyservice.dc.ad.msft.net (port 443)
  • login.windows.net (port 443)
  • login.microsoftonline.com (port 443)
  • secure.aadcdn.microsoftonline-p.com (port 443)
  • management.azure.com (port 443)

All the three components have their way of configuring proxy settings. However, you can only configure two of those components before the installations. The third one also requires internet access prior to the installation, but you can only configure the proxy settings after the installation of the Azure AD Connect Health Agent. Kinda of a chicken and the egg scenario. This is the reason why the above error occurs.

Prior to the installation of the Azure AD PowerShell CMDlets configure the proxy as follows:

NETSH.EXE WINHTTP SHOW PROXY

NETSH.EXE WINHTTP SET PROXY PROXY-SERVER="<PROXYSERVER>:<PORT>" BYPASS-LIST="<wildcard domain 1>;<wildcard domain 1>;<local>"

NETSH.EXE WINHTTP SHOW PROXY

REMARK: Because you might use PowerShell to connect to internal resources, make sure to configure all top level domains in your internal network in the bypass-list. For every internal domain configure it as shown between the double quotes “*.domain.com”. If these proxy settings are configure PowerShell will use them. if you do not configure the internal domains in the bypass list you might experience connection issues as explained in this blog post.

Prior to the installation of the Azure AD Connect configure the proxy as follows:

Edit the file “C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config” and configure the following section at the end of the file, just before the </configuration> line

    <system.net>

        <defaultProxy>

            <proxy

                usesystemdefault="true"

                proxyaddress="="<PROXYSERVER>:<PORT>"

                bypassonlocal="true"

            />

            <bypasslist>

                <add address="<regular expression for internal top level domain Azure AD Connect is connecting to>" />

            </bypasslist>

        </defaultProxy>

    </system.net>

REMARK: For every internal domain (*.domain.com) Azure AD Connect is connecting to configure it as shown between the double quotes “.*\.domain\.com$”.

Now start the Azure AD Connect installation, configure what needs to be configured. At some point in time, if internet access needs to go through a proxy and it is a tightly controlled proxy, you most likely will experience what is shown in figure 1. The Azure AD Connect Health Agent installation will try crash three times in total. After the installation of Azure AD connect successfully finishes, you need to manually register the Azure AD Connect Health Agent.

If you execute the following commands for the Azure AD Connect Health Agent

$azureUserName="<USERNAME>"

$azurePassword='<PASSWORD>’

$azureSecurePassword = ConvertTo-SecureString $azurePassword -AsPlainText -Force

$azureCreds = New-Object System.Management.Automation.PSCredential $azureUserName, $azureSecurePassword

Register-AzureADConnectHealthSyncAgent -Credential $azureCreds

…without first configuring the proxy settings for Azure AD Connect Health, you will see:

Click [Close Program]

image

Figure 2: First Crashing Occurrence After Registering Azure AD Connect Health Agent Manually

Click [Close Program]

image

Figure 3: Second Crashing Occurrence After Registering Azure AD Connect Health Agent Manually

Click [Close Program]

image

Figure 4: Third Crashing Occurrence After Registering Azure AD Connect Health Agent Manually

Click [Close Program]

image

Figure 5: Notification The Azure AD Connect Health Agent Registration Failed

In the Application Event Log you will something similar to the following 3 times:

Application: Microsoft.Identity.Health.AadSync.MonitoringAgent.Startup.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.NullReferenceException
Stack:
   at Microsoft.Identity.Health.Common.ETWTraceListener.Write(System.Object)
   at System.Diagnostics.TraceSource.TraceEvent(System.Diagnostics.TraceEventType, Int32, System.String)
   at Microsoft.Online.Reporting.MonitoringAgent.AgentTrace.LogEvent(Int32, System.Diagnostics.EventLogEntryType, System.String, System.String, System.Object[])
   at Microsoft.Online.Reporting.MonitoringAgent.AgentTrace.LogError(Int32, System.String, System.String, System.Object[])
   at Microsoft.Online.Reporting.MonitoringAgent.Startup.Program.Main(System.String[])

Faulting application name: Microsoft.Identity.Health.AadSync.MonitoringAgent.Startup.exe, version: 1.1.28.2, time stamp: 0x55e8976e
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x00007ffcbd764169
Faulting process id: 0x1618
Faulting application start time: 0x01d1aa7df40424dd
Faulting application path: C:\Program Files\Microsoft Azure AD Connect Health Sync Agent\Monitor\Microsoft.Identity.Health.AadSync.MonitoringAgent.Startup.exe
Faulting module path: unknown
Report Id: 36758953-1671-11e6-80d4-001dd8b72864
Faulting package full name:
Faulting package-relative application ID:

Fault bucket 129024325829, type 5
Event Name: CLR20r3
Response: Not available
Cab Id: 0

Problem signature:
P1: 4IQPNWPJFYKLTMQR4N2HHQMZN041TJWC
P2: 1.1.28.2
P3: 55e8976e
P4: Microsoft.Identity.AadConnect.Health.AadSync.Utils
P5: 2.6.107.0
P6: 56b4f9ab
P7: 163
P8: 1e
P9: System.NullReferenceException
P10:

Attached files:
C:\Users\XXXX\AppData\Local\Temp\WERC02B.tmp.WERInternalMetadata.xml

These files may be available here:
C:\Users\XXXX\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_4IQPNWPJFYKLTMQR_468cf53638b6fdf68ca8c15c4fe379c96dbec3_eb61a0cf_5903cc60

Analysis symbol:
Rechecking for solution: 0
Report Id: 36758953-1671-11e6-80d4-001dd8b72864
Report Status: 0
Hashed bucket: b10faeb2a429840ab102a724bbd62245

Now, the correct way to do this right for the Azure AD Connect Health Agent is by executing the following commands…

Get-AzureAdConnectHealthProxySettings

If you used NETSH earlier to configure WinHTTP proxy settings, now use –> Set-AzureAdConnectHealthProxySettings -ImportFromWinHttp

If you DID NOT used NETSH earlier to configure WinHTTP proxy settings, now use –> Set-AzureAdConnectHealthProxySettings -HttpsProxyAddress <PROXYSERVER>:<PORT>

Get-AzureAdConnectHealthProxySettings

$azureUserName="<USERNAME>"

$azurePassword='<PASSWORD>’

$azureSecurePassword = ConvertTo-SecureString $azurePassword -AsPlainText -Force

$azureCreds = New-Object System.Management.Automation.PSCredential $azureUserName, $azureSecurePassword

Register-AzureADConnectHealthSyncAgent -Credential $azureCreds

You should now see something similar to:

image

Figure 6: Notification The Azure AD Connect Health Agent Registration Was Successful

You should be good now! Smile

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Azure AD Connect, Azure AD Connect Health, Windows Azure Active Directory | Leave a Comment »

 
%d bloggers like this: