(2017-09-11) Registering The Azure AD Connect Health Agent Through A Proxy

If you need to register your Azure AD Connect Health Agent for ADFS, Sync or ADDS through a proxy, you need to first configure the proxy server and port for Azure AD Connect Health.

You have the following options:

• Read the current proxy settings for AAD Connect Health –> Get-AzureAdConnectHealthProxySettings
• Import from Internet Explorer (if confgured) –> Set-AzureAdConnectHealthProxySettings -ImportFromInternetSettings
• Import from WinHTTP (if configured) –> Set-AzureAdConnectHealthProxySettings -ImportFromWinHttp
• Specify Proxy addresses manually –> Set-AzureAdConnectHealthProxySettings -HttpsProxyAddress <fqdn>:<port>
• Clear existing proxy configuration –> Set-AzureAdConnectHealthProxySettings -NoProxy

–

Now let’s assume you have used one of the options to configure the proxy settings. After that you can use the following PowerShell commands to register the Azure AD Connect Health Agent

$azureADUserName = "<replace this with a native or federated account that has the global admin role and is NOT MFA enabled/enforced>"

$azureADPassword = ‘<replace this with the password>’

$azureADSecurePassword = ConvertTo-SecureString $azureADPassword -AsPlainText –Force

$azureADCreds = New-Object System.Management.Automation.PSCredential $azureADUserName, $azureADSecurePassword

REMARK: specifying the credentials through PowerShell may be required if the server installing Azure AD Connect Health does not support cookies and/or javascript.

REMARK: Of course you can also use –> $azureADCreds = Get-Credential

–

For Azure AD Connect Health for ADFS –> Register-AzureADConnectHealthADFSAgent -Credential $azureADCreds

For Azure AD Connect Health for ADDS –> Register-AzureADConnectHealthADDSAgent-Credential $azureADCreds

For Azure AD Connect Health for Sync –> Register-AzureADConnectHealthSyncAgent-Credential $azureADCreds –AttributeFiltering [$false | $true] -StagingMode [$false | $true]

–

If the registration is succesful, you should see something similar to te following

Figure 1: Successful Registration Of Azure AD Connect Health (In This Case For ADFS)

–

However, you may see the following error:

Figure 2: Unsuccessful Registration Of Azure AD Connect Health (In This Case For ADFS) With The Error: “user_realm_discovery_failed: User Realm Discovery Failed”

–

Always when receiving an error, open the specified log file to see/understand what went wrong.

–

In this case opening the file I saw the following:

–

2017-08-25 07:20:39.295 ProductName: Azure AD Connect Health AD FS Agent, FileVersion: 3.0.68.0, Current UTC Time: 2017-08-25 07:20:39Z

2017-08-25 07:20:39.295 AHealthServiceUri (ARM): https://management.azure.com/providers/Microsoft.ADHybridHealthService/

2017-08-25 07:20:39.31 AdHybridHealthServiceUri: https://s1.adhybridhealth.azure.com/

2017-08-25 07:20:39.326 AHealthServiceUri (ARM): https://management.azure.com/providers/Microsoft.ADHybridHealthService/

2017-08-25 07:20:39.326 AdHybridHealthServiceUri: https://s1.adhybridhealth.azure.com/

2017-08-25 07:20:39.373 User Context outbound connections to https://management.azure.com/providers/Microsoft.ADHybridHealthService/ will use proxy address https://management.azure.com/providers/Microsoft.ADHybridHealthService/ (if equal, no proxy is used)

2017-08-25 07:20:39.373 Service Context: Outbound connections to https://management.azure.com/providers/Microsoft.ADHybridHealthService/ will use proxy address http://proxy.iamtec.nl:3128/ (if equal, no proxy is used)

2017-08-25 07:20:39.373 UploadLogFileFromDisk: arguments LogFileLocation=C:\Users\XXX\AppData\Local\Temp\3\AdHealthAdfsAgentConfiguration.2017-08-25_09-20-39.log;ProductName=Azure AD Connect Health AD FS Agent;ProductVersion=3.0.68.0;MachineName=SERVER;ServiceUri=https://s1.adhybridhealth.azure.com/;Result=started;type=registration,activityId=432fd061-6219-498a-8a98-bf68d90a5431

2017-08-25 07:20:39.389 UploadLogFileFromDisk: TenantId: unknown

2017-08-25 07:20:39.389 UploadLogFileFromDisk: MachineId: unknown

2017-08-25 07:20:39.389 UploadLogFileFromDisk: reading file contents of C:\Users\XXX\AppData\Local\Temp\3\AdHealthAdfsAgentConfiguration.2017-08-25_09-20-39.log

2017-08-25 07:20:39.389 UploadLogFileFromDisk: log length: 1842

2017-08-25 07:20:39.389 UploadFile: start, url: https://s1.adhybridhealth.azure.com/providers/Microsoft.ADHybridHealthService/diagnostics/logs/installer/product/Azure-AD-Connect-Health-AD-FS-Agent/version/3.0.68.0/machine/SERVER?result=started&type=registration

powershell.exe Information: 0 : AdHealthWebproxy settings: HttpsProxyAddress: http://proxy.iamtec.nl:3128/, initialization status: Succeeded; Registry value did not exist; Value was not a string, No Initialization Exception

2017-08-25 07:20:40.451 UploadFile: upload successful

2017-08-25 07:20:40.451 UploadLogFileFromDisk: response: Http response code: OK

"log successfully uploaded"

2017-08-25 07:20:40.451 AHealthServiceApiVersion: 2014-01-01

2017-08-25 07:20:40.451 –> https://management.core.windows.net/

powershell.exe Information: 0 : 8/25/2017 7:20:40 AM:  – AdHealthAgentConfigurationUtility: ADAL .NET with assembly version ‘2.24.0.0’, file version ‘2.24.30411.1323’ and informational version ‘4482033c814db2fd31423c79b5027d0b5dfb7a6d’ is running…

powershell.exe Information: 0 : 8/25/2017 7:20:40 AM: 432eb23e-19c6-4c97-9bc2-ca4f7138fb3e – AcquireTokenNonInteractiveHandler: === Token Acquisition started:

                Authority: https://login.windows.net/common/

                Resource: https://management.core.windows.net/

                ClientId: cf6d7e68-f018-4e0a-a7b3-126e053fb88d

                CacheType: Microsoft.IdentityModel.Clients.ActiveDirectory.TokenCache (0 items)

                Authentication Target: User

powershell.exe Information: 0 : 8/25/2017 7:20:40 AM: 432eb23e-19c6-4c97-9bc2-ca4f7138fb3e – <RunAsync>d__0: No matching token was found in the cache

powershell.exe Information: 0 : 8/25/2017 7:20:40 AM: 432eb23e-19c6-4c97-9bc2-ca4f7138fb3e – AsyncMethodBuilderCore: Sending user realm discovery request to ‘https://login.windows.net/common/UserRealm/jorge@iamtec.nl?api-version=1.0&#8217;

powershell.exe Error: 0 : 8/25/2017 7:21:10 AM: 432eb23e-19c6-4c97-9bc2-ca4f7138fb3e – AsyncMethodBuilderCore: Microsoft.IdentityModel.Clients.ActiveDirectory.AdalServiceException: user_realm_discovery_failed: User realm discovery failed —> System.Net.WebException: The operation has timed out

   at System.Net.HttpWebRequest.GetResponse()

   at Microsoft.IdentityModel.Clients.ActiveDirectory.HttpWebRequestWrapper.<GetResponseSyncOrAsync>d__2.MoveNext()

— End of stack trace from previous location where exception was thrown —

   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)

   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

   at Microsoft.IdentityModel.Clients.ActiveDirectory.UserRealmDiscoveryResponse.<CreateByDiscoveryAsync>d__0.MoveNext()

   — End of inner exception stack trace —

   at Microsoft.IdentityModel.Clients.ActiveDirectory.UserRealmDiscoveryResponse.<CreateByDiscoveryAsync>d__0.MoveNext()

— End of stack trace from previous location where exception was thrown —

   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)

   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()

   at Microsoft.IdentityModel.Clients.ActiveDirectory.AcquireTokenNonInteractiveHandler.<PreTokenRequest>d__4.MoveNext()

— End of stack trace from previous location where exception was thrown —

   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)

   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

   at Microsoft.IdentityModel.Clients.ActiveDirectory.AcquireTokenHandlerBase.<RunAsync>d__0.MoveNext()

                ErrorCode: user_realm_discovery_failed

                StatusCode: 0

2017-08-25 07:21:10.645 Microsoft.IdentityModel.Clients.ActiveDirectory.AdalServiceException: user_realm_discovery_failed: User realm discovery failed —> System.Net.WebException: The operation has timed out

   at System.Net.HttpWebRequest.GetResponse()

   at Microsoft.IdentityModel.Clients.ActiveDirectory.HttpWebRequestWrapper.<GetResponseSyncOrAsync>d__2.MoveNext()

— End of stack trace from previous location where exception was thrown —

   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)

   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

   at Microsoft.IdentityModel.Clients.ActiveDirectory.UserRealmDiscoveryResponse.<CreateByDiscoveryAsync>d__0.MoveNext()

   — End of inner exception stack trace —

   at Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext.RunAsyncTask[T](Task`1 task)

   at Microsoft.Identity.Health.Common.Clients.PowerShell.ConfigurationModule.AdHealthAgentConfigurationUtility.ObtainAadAccessTokenWithExistingCredential(PSCredential psCredential)

   at Microsoft.Identity.Health.Common.Clients.PowerShell.ConfigurationModule.RegisterADHealthAgent.ProcessRecord()

                ErrorCode: user_realm_discovery_failed

                StatusCode: 0

2017-08-25 07:21:10.66 UploadLogFileFromDisk: arguments LogFileLocation=C:\Users\XXX\AppData\Local\Temp\3\AdHealthAdfsAgentConfiguration.2017-08-25_09-20-39.log;ProductName=Azure AD Connect Health AD FS Agent;ProductVersion=3.0.68.0;MachineName=SERVER;ServiceUri=https://s1.adhybridhealth.azure.com/;Result=failed;type=registration,activityId=432fd061-6219-498a-9b98-bf68d90a5431

2017-08-25 07:21:10.66 UploadLogFileFromDisk: TenantId: unknown

2017-08-25 07:21:10.66 UploadLogFileFromDisk: MachineId: unknown

2017-08-25 07:21:10.66 UploadLogFileFromDisk: reading file contents of C:\Users\XXX\AppData\Local\Temp\3\AdHealthAdfsAgentConfiguration.2017-08-25_09-20-39.log

2017-08-25 07:21:10.66 UploadLogFileFromDisk: log length: 7608

2017-08-25 07:21:10.66 UploadFile: start, url: https://s1.adhybridhealth.azure.com/providers/Microsoft.ADHybridHealthService/diagnostics/logs/installer/product/Azure-AD-Connect-Health-AD-FS-Agent/version/3.0.68.0/machine/SERVER?result=failed&type=registration

2017-08-25 07:21:11.082 UploadFile: upload successful

2017-08-25 07:21:11.082 UploadLogFileFromDisk: response: Http response code: OK

"log successfully uploaded"

–

The green lines above list what/where things go wrong. In this case user realm discovery is failing. However, the yellow lines are giving you a hint why things are going wrong.

–

Looking at the second yellow line you see the service context is using the proxy server configured for Azure AD Connect Health. However, the first yellow line tells you the user context context is not using any proxy server at all. Because of that it is failing the realm discovery

–

The solution for this is to configure the user context with a proxy server and port. That is done by configuring the proxy settings in Internet Explorer with the same values

Figure 3: Configuring The User Context With Proxy Settings

–

After doing this, retry registration.

–

If it still fails check the log file again. You might see the following:

–

powershell.exe Information: 0 : 9/11/2017 11:54:12 AM: 68215d80-864f-43af-9b6a-8f3f41f276af – <RunAsync>d__0: No matching token was found in the cache

powershell.exe Information: 0 : 9/11/2017 11:54:12 AM: 68215d80-864f-43af-9b6a-8f3f41f276af – AsyncMethodBuilderCore: Sending user realm discovery request to ‘https://login.windows.net/common/UserRealm/jorge@iamtec.nl?api-version=1.0&#8217;

powershell.exe Error: 0 : 9/11/2017 11:54:12 AM: 68215d80-864f-43af-9b6a-8f3f41f276af – AsyncMethodBuilderCore: Microsoft.IdentityModel.Clients.ActiveDirectory.AdalServiceException: user_realm_discovery_failed: User realm discovery failed —> System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. —> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.

   at System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, Exception exception)

   at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)

at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)

–

In this case, your proxy server is terminating SSL traffic for inspection. If you have not imported the root certificate of the certificate being used by the proxy server into the “Trusted Root Certificate Authority” store, you will see an error like this. Import the root certificate of the certificate being used by the proxy server into the “Trusted Root Certificate Authority” store to fix this.

–

Hope this helps you!

–

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/ ###################
————————————————————————————————————————————————————-

Advertisement

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

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

Figure 1: Error In AAD Connect About “AttributeValueMustBeUnique”

–

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

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:

• Somewhere in the past, MIM synched user ‘John.Doe@XXXXX’ as contact to AAD
• Now I wanted to sync user ‘John.Doe@XXXXX’ as user to AAD using AAD Connect

–

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

• How to fix Attribute Value Must Be Unique “AttributeValueMustBeUnique” error message when trying to sync an object from on-premises Active Directory to Office 365
• Duplicate or invalid attributes prevent directory synchronization in Office 365

–

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.

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.

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

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.

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.

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

–

BINGO!!!

–

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:

• Identity synchronization and duplicate attribute resiliency
• Troubleshooting Errors during synchronization

–

–

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/ ###################
————————————————————————————————————————————————————-

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

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)

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

–

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

–

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/ ########
———————————————————————————————

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

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]

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

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!

Figure 3: Azure AD Connect Health – Initial Credentials Screen

–

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

Figure 4: Azure AD Connect Health – Redirection To ADFS

–

…specify the password belonging to the specified user name

Figure 5: Azure AD Connect Health – Credentials Screen

–

…registration continues

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

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

–

Closing the screen above throws the following errors

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!

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

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/ ########
———————————————————————————————

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

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

–

More information:

• Blog post: https://blogs.technet.microsoft.com/enterprisemobility/2016/07/19/introducing-azuread-connect-health-for-windows-server-ad/
• Channel 9 Video: https://channel9.msdn.com/Series/Azure-Active-Directory-Videos-Demos/Azure-AD-Connect-Health-monitors-on-premises-AD-Domain-Services
• Documentation: https://aka.ms/aadchdocs
• Download the agent” https://aka.ms/aadchaddsagent

–

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/ ########
———————————————————————————————

 

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

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

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]

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

–

Click [Close Program]

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

–

Click [Close Program]

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

–

Click [Close Program]

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:

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

–

You should be good now!

–

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/ ########
———————————————————————————————