Yesterday (Tuesday October 11th, 2016) I started a routine install of Azure AD Connect. This project is for an upgrade from FIM 2010 R2 for a long time client; if you were wondering.
Unfortunately at the end of the process, when essentially the final part of the install was running, during the “Configure” process, I ran into some trouble.
Strike 1
I received the following error:
An error occurred executing Configure AAD Sync task: user_realm_discovery_failed: User realm discovery failed
This happened with the current, as of this blog post, version of Azure AD Connect: 1.1.281.0 (release: Sep 7th 2016).
I did a quick Google, as you do, and found a few articles that matched the same error. The first one I went to was by Mark Parris. His blog post (available here) had all the makings of a solution. I followed those instructions to try and resolve my issue.
The solution required the following steps (with some of my own additions):
- Open Explorer
- Navigate to the following path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config
- Find the file called machine.config
- Create a new folder in the same directory called “Original”
- Copy the file there as a backup in case things go wrong
- Open machine.config with notepad to edit it
- At the bottom, before the </configuration>, enter in the following:
<system.net> <defaultProxy enabled=”false”></defaultProxy> </system.net>
I followed those instructions and saved the file to my desktop. I removed the notepad added .txt extension and before saving the file to the directory, I checked the logs to make sure I was indeed having the same issue. Small error on my part there. I’ll just blame it on the jet lag. Something (the log file) I should have checked first. Nevertheless, I checked.
Strange. I didn’t have the same error as Mark. My install had the following error:
Operation failed. The remote server returned an error: (400) Bad Request.. Retrying…Exception = TraceEventType = RegistrationAgentType = NotAnAgentServiceType
I know my client was using a proxy though, so, for the sake of testing, as this deployment was in staging mode anyway, I copied the machine.config file from the server desktop to the path and overwrote the file. My logic was that the .NET config with proxy “false” setting would bypass the proxy. Unfortunately that was not the case.
Strike 2
I selected the retry option in the Azure AD Connect installer and waited for the result. Not quite the same error, but, an error nonetheless:
An error occurred executing Configure AAD Sync task: the given key was not present in the dictionary.
What a dictionary has to do with Azure AD Connect is beyond me. Technology is complicated, so I didn’t judge it. I went back to a few other of the search results in Google. One of the others was from Tarek El-Touny. His blog post (available here) was similar to Mark’s, but, had some different options regarding the proxy settings in the machine.config file.
Here’s what Tarek suggested to enter in that machine.config file:
<system.net> <defaultProxy enabled="true" useDefaultCredentials="true"> <proxy usesystemdefault="true" proxyaddress="http://<PROXYADDRESS>:<PROXYPORT>" bypassonlocal="true" /> </defaultProxy> </system.net>
Since I did have a proxy, this made more sense. Originally with the proxy “false” setting, I thought that would bypass or disable usage of the proxy. I was wrong.
Here’s a sample of the machine.config file for your reference:
After I amended the machine.config file and saved it to the correct location, I started another retry of the installation. This time there was good news! It successfully finalised the installation and went on to configuration.
Final words
Over the last few months I’ve not done any hands on technical work. Yes, some architecture and design, some work orders and pre-sales, but, to get back on the tools was good. Unfortunately for me, a little rusty, but, thanks to the blog-sphere out there and the brains trust of other awesome people, I managed to work my way through the problem.
Best, Lucian