Unfortunately, Every time the Essentials Services integration is run, it checks for Multiple DC’s and since multiple DC’s are blocked for now, the wizard won’t finish. In other words, even if just keep one domain controller and run the wizards, then promote another DC and try to re-configure any of the integration wizards, it will still fail.

I understand that this certainly is not a good option, but let me assure you that work is going on in the attempt to fix this behavior. There is no time frame however.

You should be aware of the following before you deploy Services Integration features:

1. Windows Azure Active Directory integration will be turned on automatically when you turn on either Office 365 or Windows Intune. This is because they both leverage Windows Azure Active Directory as a common identity platform.

2. Currently, the Services Integration features, including Windows Azure Active Directory integration, Office 365 integration, Windows Intune integration, and on-premises Exchange integration, are only supported in a single domain controller environment. In addition, the integration wizard must be run on a domain controller.

Thanks for opening this this bug. The root cause of this bug is sid S-1-5-32-555 is not recognized by local component. It may happen when run client connector after upgrade a machine with Windows 8 Pro Pack . We already have a bug to track this issue. And there is a workaround for this issue: Skip domain join during client deployment by adding a registry key. Please add this key and try again.

Tonight I was facing an interesting problem I did not had before. I just had reinstalled a Server 2012 Essentials VM and was configuring this for internetaccess to patch and configure it. Though i had entered a vaild IP and a vaild Gatway I misstyped the Gateway IP to be the same as the local OS IP. In my case 192.168.46.2. Recognizing my error I reopened the IPv4 config dialog and change the IP to 192.168.46.1 which is the gateway IP:

Then I tried accessing the internet for Patches and things, but that failed… hmm, well troubleshooting is my job and so. I went on pinging the gateway IP 192.168.46.1, which succeded, then I ping a FQDN, which failed…hmm, ok went to check for DNS settings, all ok.

So went on an pinged one of the google DNS Server 8.8.8.8 which also failed:

Interesting… so how come you get to the gateway IP just fine, but not bejond? Well that’s usually a matter of the Gateway/Firewall/Router, right? Ok, so checked the setting of the Gateway multiple times all seemed right… As the Gateway is a TMG I went on to monitor traffic coming from the VM:

Ping to the Gateway IP showed up just as expeted and were allowed.

But any other traffic to the internet, e.g. pinging 8.8.8.8 didn’t even show up in the LOG… interesting…

Then I fired a “route print” on the VM and found something interesting, two default gateways:

WTH??!! Ok, now that’s not right and might cause the trouble…ie So I tried to reset the gateway using the IP config dialog, which did not work as it always kept the wrong gateway of 192.168.46.2 in the deafult route.

Ok, so the let’s use “route delete 0.0.0.0” and then reset the correct gateway in IPv4 setting:

and after resetting the correct gateway of 192.168.46.1 in IPv4 setings:

after this pinging the web and DNS resolutions started to work just fine: