Azure AD Connect No-Start-Connection

This morning, I ran into an issue with Azure AD Connect that I had never seen before. I received an email alert from Azure AD stating that Password Synchronization was not working for my forest, and the suggested fix was to restart the ADSync service on the server. I restarted the service and then forced a sync to verify it was working.

After forcing the sync, I opened miisclient and noticed some strange errors. We sync multiple on-prem AD forests to Azure AD, and the status for one of them was “no-start-connection”. That error in itself does not seem significant to me. However, after clicking on the “failed-connection” link in the Connection Status pane, things became much more clear.

The domain controllers for the forest in question are in a datacenter that is geographically separated from the datacenter that our Azure AD Sync server lives in. The two sites are connected via a S2S VPN.

There was obviously some type of connection issue between our two datacenters. In my case, the issue was transient, and resolved itself after a few minutes. But if you’re experiencing this error message, check your L2/L3 connection. Also, verify DNS is working and someone didn’t make changes to your firewall(s). Just walk up or down the OSI model and you’ll eventually find the problem.

Azure AD Connect Health: Latest Data is not Available in Azure Portal

I recently had to create a new Azure AD Connect server, and found that it was not able to report health status in the Azure Portal. After some troubleshooting/research, I was able to get the health status report working by registering the health agent on the server with Azure AD Health Services. Doing this involves running one PowerShell cmdlet on your AD Connect server and providing global administrator credentials.  

First, let’s test the status of the agent communication:

If you do not receive any errors, that means the Azure AD Connect Health agent on your server is able to successfully communicate with the cloud service. Now, let’s register the agent:

You will be prompted for credentials. The credentials you provide need to be a global administrator account in your Azure AD tenant.

You should receive some output stating that the registration is successful (or it failed).

 Now, just go back to the Azure Portal and refresh the page. The message stating that the
"latest data is not available" should be gone.

Removing a Forest from Azure AD Connect

In an organization with multiple Active Directory forests, you may want to sync objects from trusted forests. Adding trusted forests to Azure AD Sync is a simple process that I will likely cover in a future article. The focus of this post is the not-so-obvious process of removing a forest from Azure AD Connect. This can be a daunting and somewhat scary thing to do. Not fully understanding the process or having someone to guide you can leave you with thoughts like “what happens when I remove the forest from Azure AD Sync? Do on-premises objects get deleted? Are cloud objects deleted?”. I will try to answer these questions to the best of my ability and hopefully make the process simple and stress-free for you.

To get started, we first need to open PowerShell and disable the AD Sync scheduler. You can do this by running the “Set-ADSyncScheduler” cmdlet:

This cmdlet is included in the ADSync PowerShell module. You may need to load the module prior to using the cmdlet (Import-Module ADSync).

The next step is to open FIM (miisclient) located in the install directory of Microsoft Azure AD Sync. By default, this is C:\Program Files\Microsoft Azure AD Sync\UIShell\miisclient.exe. Once you have FIM open, click on the Connectors tab, then right click on the connector for the forest that you want to delete, and click “Delete”.

You will then be prompted, asking if you want to just delete the Connector Space, or delete the Connector and the Connector Space. The former open removes all data, but keeps the configuration in case you want to use it again later. The latter option deleted the data and the configuration. This open should only be used if you don’t plan on syncing the forest again.

The connector for the forest is now deleted, but what actually happens? Your on-premises objects do not get removed for the forest, and cloud objects are removed. Simple enough, right?

Now you just need to re-enable the AD Sync Scheduler with this cmdlet: 

Set-ADSyncScheduler -SyncCycleEnabled $true

One last thing to mention… You may receive an email from the Microsoft Online Services Team stating that the identity synchronization failed due to a deletion threshold being met. By default, Azure AD Connect will not allow you to delete more than 500 objects in your cloud directory. This is to protect you from making a careless (potentially resume generating) mistake. The email will look something like this:

If you are certain that you want to proceed with deleting the objects, here are the steps:

1 1) Disable the deletion threshold protection. Open PowerShell on your Azure AD Sync server and type   in this cmdlet: Disable-ADSyncExportDeletionThreshold. You will be prompted for credentials,   sign-in with an Azure AD Global Admin account.

2 2) Open FIM (miisclient), and click on the “Connectors” button at the top of the window. Right click   on the connector of type “Windows Azure Active Directory”, and select “Run…”.

3) Next, click Export and then click Ok. 

1      4) Allow the connector to run. This will take a few minutes. You can monitor the progress by clicking the Operations button.

2      

5   5) Once this completes, you need to re-enable the deletion threshold. You can do this by running this cmdlet: Enable-ADSyncExportDeletionThreshold -DeletionThreshold 500. You will be prompted for credentials again. Just type in your Azure AD Global Admin creds. You can even lower the threshold if you’d like. I set mine to 100.