Azure AD Connect – Using AuthoritativeNull in a Sync Rule

There is a feature in Azure AD Connect that became available in the November 2015 build 1.0.9125.0 (listed here), which has not had much fanfare but can certainly come in handy in tricky situations. I happened to be working on a project that required the DNS domain linked to an old Office 365 tenant to be removed so that it could be used in a new tenant. Although the old tenant was no long used for Exchange Online services, it held onto the domain in question, and Azure AD Connect was being used to synchronise objects between the on-premise Active Directory and Azure Active Directory.

Trying to remove the domain using the Office 365 Portal will reveal if there are any items that need to be remediated prior to removing the domain from the tenant, and for this customer it showed that there were many user and group objects that still had the domain used as the userPrincipalName value, and in the mail and proxyAddresses attribute values. The AuthoritativeNull literal could be used in this situation to blank out these values against user and groups (ie. Distribution Lists) so that the domain can be released. I’ll attempt to show the steps in a test environment, and bear with me as this is a lengthy blog.

Trying to remove the domain listed the items needing attention, as shown in the following screenshots:

This report showed that three actions are required to remove the domain values out of the attributes:

  • userPrincipalName
  • proxyAddresses
  • mail

userPrincipalName is simple to resolve by changing the value in the on-premise Active Directory using a different domain suffix, then synchronising the changes to Azure Active Directory so that the default or another accepted domain is set.

Clearing the proxyAddresses and mail attribute values is possible using the AuthoritativeNull literal in Azure AD Connect. NOTE: You will need to assess the outcome of performing these steps depending on your scenario. For my customer, we were able to perform these steps without affecting other services required from the old Office 365 tenant.

Using the Synchronization Rules Editor, locate and edit the In from AD – User Common rule. Editing the out-of-the-box rules will display a message to suggest you create an editable copy of the rule and disable the original rule which is highly recommended, so click Yes.

The rule is cloned as shown below and we need to be mindful of the Precedence value which we will get to shortly.

Select Transformations and edit the proxyAddresses attribute, set the FlowType to Expression, and set the Source to AuthoritativeNull.

I recommend setting the Precedence value in the new cloned rule to be the same as the original rule, in this case value 104. Firstly edit the original rule to a value such as 1001, and you can also notice the original rule is already set to Disabled.

Set the cloned rule Precedence value to 104.

Prior to performing a Full Synchronization run profile to process the new logic, I prefer and recommend to perform a Preview by selecting a user affected and previewing a Full Synchronization change. As can be seen below, the proxyAddresses value will be deleted.

The same process would need to be done for the mail attribute.

Once the rules are set, launch the following PowerShell command to perform a Full Import/Full Synchronization cycle in Azure AD Connect:

  • Start-ADSyncSyncCycle -PolicyType Initial

Once the cycle is completed, attempt to remove the domain again to check if any other items need remediation, or you might see a successful domain removal. I’ve seen it take upto 30 minutes or so before being able to remove the domain if all remediation tasks have been completed.

There will be other scenarios where using the AuthoritativeNull literal in a Sync Rule will come in handy. What others can you think of? Leave a description in the comments.

Active Directory – What are Linked Attributes?

A customer request to add some additional attributes to their Azure AD tenant via Directory Extensions feature in the Azure AD Connect tool, lead me into further investigation. My last blog here set out the customer request, but what I didn’t detail in that blog was one of the attributes they also wanted to extend into Azure AD was directReports, an attribute they had used in the past for their custom built on-premise applications to display the list of staff the user was a manager for. This led me down a rabbit hole where it took a while to reach the end.

With my past experience in using Microsoft Identity Manager (formally Forefront Identity Manager), I knew directReports wasn’t a real attribute stored in Active Directory, but rather a calculated value shown using the Active Directory Users and Computers console. The directReports was based on the values of the manager attribute that contained the reference to the user you were querying (phew, that was a mouthful). This is why directReport and other similar type of attributes such as memberOf were not selectable for Directory Extension in the Azure AD Connect tool. I had never bothered to understand it further than that until the customer also asked for a list of these type of attributes so that they could tell their application developers they would need a different technique to determine these values in Azure AD. This is where the investigation started which I would like to summarise as I found it very difficult to find this information in one place.

In short, these attributes in the Active Directory schema are Linked Attributes as detailed in this Microsoft MSDN article here:

Linked attributes are pairs of attributes in which the system calculates the values of one attribute (the back link) based on the values set on the other attribute (the forward link) throughout the forest. A back-link value on any object instance consists of the DNs of all the objects that have the object’s DN set in the corresponding forward link. For example, “Manager” and “Reports” are a pair of linked attributes, where Manager is the forward link and Reports is the back link. Now suppose Bill is Joe’s manager. If you store the DN of Bill’s user object in the “Manager” attribute of Joe’s user object, then the DN of Joe’s user object will show up in the “Reports” attribute of Bill’s user object.

I then found this article here which further explained these forward and back links in respect of which are writeable and which are read-only, the example below referring to the linked attributes member/memberOf:

Not going too deep into the technical details, there’s another thing we need to know when looking at group membership and forward- and backlinks: forward-links are writable and backlinks are read-only. This means that only forward-links changed and the corresponding backlinks are computed automatically. That also means that only forward-links are replicated between DCs whereas backlinks are maintained by the DCs after that.

The take-out from this is the value in the forward-link can be updated, the member attribute in this case, but you cannot update the back-link memberOf. Back-links are always calculated automatically by the system whenever an attribute that is a forward-link is modified.

My final quest was to find the list of linked attributes without querying the Active Directory schema which then led me to this article here, which listed the common linked attributes:

  • altRecipient/altRecipientBL
  • dLMemRejectPerms/dLMemRejectPermsBL
  • dLMemSubmitPerms/dLMemSubmitPermsBL
  • msExchArchiveDatabaseLink/msExchArchiveDatabaseLinkBL
  • msExchDelegateListLink/msExchDelegateListBL
  • publicDelegates/publicDelegatesBL
  • member/memberOf
  • manager/directReports
  • owner/ownerBL

There is further, deeper technical information about linked attributes such as “distinguished name tags” (DNT) and what is replicated between DCs versus what is calculated locally on a DC, which you can read in your own leisure in the articles listed throughout this blog. But I hope the summary is enough information on how they work.

Azure AD Connect – Multi-valued Directory Extensions

I happened to be at a customer site working on an Azure project when I was asked to cast a quick eye over an issue they had been battling with. They had an Azure AD Connect server synchronising user and group objects between their corporate Active Directory and their Azure AD, used for Office 365 services and other Azure-based applications. Their intention was to synchronise some additional attributes from their Active Directory to Azure AD so that they could be used by some of their custom built Azure applications. These additional attributes were a combination of standard Active Directory attributes as well as some custom schema extended attributes.

They were following the guidance from the Microsoft article listed here. As mentioned in the article, ‘Directory extensions allows you to extend the schema in Azure AD with your own attributes from on-premises Active Directory‘. When running the Azure AD Connect installation wizard and trying to find the attributes in the dropdown list, some of their desired attributes were not listed as shown below. An example attribute they wanted to synchronise was postalAddress which was not in the list.

After browsing the dropdown list trying to determine why some of their desired attributes were missing, I noticed multi-valued attributes were missing, such as the description standard Active Directory attribute which I knew was a multi-valued attribute.

I checked the schema in Active Directory and it was clear the postalAddress attribute was multi-valued.

The customer pointed me back to the Microsoft article which clearly stated that the valid attribute candidates included multi-valued strings and binary attributes. With the time I had remaining, I reviewed their Azure AD Connect implementation and tried a few techniques in the synchronisation service such as:

  • refreshing the schema of the on-premise Active Directory management agent
  • enabled the attribute in the properties of the on-premise Active Directory management agent as by default it was not checked

I next checked the Azure AD Connect release notes (here) and quickly noticed the cause of the issue which had to do with the version of Connect they were using, which was a few releases old. It was from version released in April 2016 which added support for multi-valued attributes to Directory Extensions, while the version running by the customer was from only a couple of months earlier.

After upgrading Azure AD Connect to currently released version, the customer was able to successfully select these multi-valued attributes.

Microsoft are very good at keeping the release notes upto date as new versions of Azure AD Connect are released, currently every 1-2 months. The lessons learned are to check the release notes to view the new features and bug fixes in releases to determine if you need to upgrade the tool.

Azure AD Connect manual sync cycle with powershell, Start-ADSyncSyncCycle

Originally posted on Lucian’s blog at Follow Lucian on Twitter @LucianFrango.


This morning at Kloud NSW HQ (otherwise known as the Kloud office, or the office, or anything else that does not sound cool or interesting at all) James Lewis (@Jimmy_Lewis on Twitter) asked the question:

What is the powershell cmdlet to kick off a manual sync in AADConnect?

Back in the olden days, as they say, in DirSync there was a powershell cmdlet called:


As Microsoft do often times, this cmdlet has changed. However, the reason this has changed is because of the way the sync process is now handled in AADConnect. The AADConnect Sync Scheduler has come about to replace the pre-existing process of an external sync engine tied to a Windows service and Windows task scheduler.

The new scheduler is responsible to complete two key tasks: run and manage the synchronisation cycle where import, sync and export processes are looked after; and to complete regular maintenance tasks, like for example renew certificates and keys for password reset and device registration (DRS), to name a few.

Read More


Feb 2016 Azure AD Connect Upgrade Fails – IndexOutOfRangeException resolution

I’ve been doing some work for a client recently who decided to upgrade their Azure AD Connect appliance to the latest February release. This was a prerequisite task for future work to follow. As an aside, it’s always nice to run the current version of the sync client. Microsoft regularly update the client to provide new features and improvements. A key driver for this client in particular was the fact that the new client ( – Released 16/2/2016) will allow you to synchronise every 30 minutes, which is a welcome change from the previous 3-hour sync cycles.

The detailed Azure AD Connect version release history can be found – here

So it was decided… we would upgrade.

All sounds fairly painless really, yeah?

We completed the usual preparation tasks, such as forcing a sync, exporting the connector space, taking backups and snapshots etc. All of this completed as expected. We were ready to kick off the installation process of the new client (shown below.)

Shortly after the client upgrade process completed, I was greeted with this wonderful window.

The log file tells me this:

[11:36:13.912] [ 1] [INFO ] Found existing persisted state context.

[11:36:13.912] [ 1] [ERROR] Caught an exception while creating the initial page set on the root page.

Exception Data (Raw): System.IndexOutOfRangeException: Index was outside the bounds of the array.

at Microsoft.Online.Deployment.Types.Utility.AdDomainInfoEncoder.ConvertBack(Object value, Type targetType, Object parameter, CultureInfo culture)

at Microsoft.Online.Deployment.Types.PersistedState.PersistedStateElement.ToContext(PersistedStateContainer state, PropertyInfo propertyInfo, PersistedElementAttribute attr, Object& value)

at Microsoft.Online.Deployment.Types.Context.LocalContextBase.LoadFromState(PersistedStateContainer state, IPowerShell powerShell)

at Microsoft.Online.Deployment.OneADWizard.UI.WizardPages.RootPageViewModel.GetInitialPagesCore()

at Microsoft.Online.Deployment.OneADWizard.UI.WizardPages.RootPageViewModel.GetInitialPages()

[11:36:41.346] [ 1] [INFO ] Opened log file at path C:\Users\xxxxxx\AppData\Local\AADConnect\trace-20160218-113613.log

To resolve this issue, we need to action the following

  1. Make sure the AAD Connect wizard is not running.

  2. Open this file: %ProgramData%\AADConnect\PersistedState.xml

  3. Take a backup (copy and rename PersistedState.xml to PersistedState.old)

  4. Proceed to edit the xml file using your favourite text editor.

  5. Find a section that looks like this:


We need to update the <Value> element to look like this:


The value must be populated twice, separated by a comma.

You can now save the file and restart the AAD Connect wizard. It will now launch as expected.

Following on from this I was able to complete the upgrade as per normal.

I can also now see that the sync cycle has been reduce to 30 minutes post upgrade (shown below.)

It appears that Microsoft have logged an official bug fix for this, However… this should get you out of trouble in the short term.

Happy upgrading!

Azure AD Connect – “The specified domain does not exist or cannot be contacted” when adding an untrusted AD forest

I ran into a little issue while on site with a customer who required AAD Connect to be configured for use in a multi-forest environment with three forests. There was a forest trust between two of the forests, however the third forest did not have any trusts in place. Prior to implementing this solution, we ran up a test environment to do a run through and document the steps required for an implementation plan.

The test environment consisted of three Windows Server 2012 AD forests all at 2012 functional level –, and and a single Office 365 tenant,

I installed the AAD Connect application into the forest, and proceeded to run through the wizard. All was well until I came to adding the untrusted forest, to the “configured directory” list. I could add the trusted forest ( easily enough, however when I attempted to add I received the helpful little error message “The specified domain does not exist or cannot be contacted”.

“That’s interesting” I thought. I know I created the domain, so it exists. And I can ping the domain using the FQDN, so it’s definitely resolvable and contactable.

Specified domain does not exist

Authenticating to the forest with either the NetBIOS name format, KLOUDLESS\jason or the user principal name (UPN) format, ended up with the same error “The specified domain does not exist or cannot be contacted”. After some poking around (and input from a helpful architect on site) a solution was found.

In the USERNAME field, use the FQDN of the authenticating domain instead of the NetBIOS name, so in my case it was\jason instead of KLOUDLESS\jason

Now, my colleagues have suggested that this issue may be an environmental one relating to name resolution, and I tend to agree.

In my case, each domain had its own integrated DNS with secondary zones for each of the other domain names, so had integrated DNS with secondary zones for and And so forth for each of the forests. Name resolution was functional to all domains from all domains.

Either way, in the case of my test environment, using the FQDN of the authenticating forest provides the outcome we were looking for, and I hope that if you happen to come across this issue, I’ve saved you a little bit of time.


[UPDATED] Azure AD Connect: SyncRuleEditor.exe and why is targetAddress missing

Originally posted on Lucian’s blog here @ Follow Lucian on Twitter @LucianFrango. Send Lucian an email.

Today is back to AAD Connect. I want to talk about Office 365 migrations and how they can be tricky with various options and scenarios around hybrid or non hybrid. On a recent project we were migrating a client from IBM Lotus Notes to Exchange Online in Office 365. The plan and proposed solution was designed to not use Exchange Server Hybrid on-premises and use Dell Software Migrator for a direct migration from on-premises to the cloud.

The client has never had Exchange Server on-premises before and was running a well-managed ADDS deployment spanning three sites across three continents. To allow for the schema requirements for Exchange Online, Exchange Server 2013 was downloaded and the ADDS schema was extended with that from Exchange Server 2013. All simple, standard stuff right?..

Read More

How to provision Azure Active Directory Connect

Originally posted by Lucian Franghiu on his blog over at, #clouduccino.

Time flies when you’re connecting to Azure AD. Late last month Microsoft announced that Azure AD Connect is now generally available. At the time of writing this, the synchronisation app itself still isn’t the default sync standard for Azure and obtaining the installer requires a quick Google. Since I’m deploying it for a client, I thought I’d run through the install process for future reference.

AADConnect provides allot of new functionality like for example this new fandangled ADDS password sync. In this scenario I’m keeping federation services, so ADFS will be deployed, which is more aligned with the previous or most common enterprise identity design.

This is going to be a long blog post with allot of screen shots (you’re welcome) on how to deploy Azure AD Connect. I’ll be going though the wizard process which will follow the automated process to deploy AADConnect, ADFS and ADFS WAP servers- pretty cool indeed.

At the moment AADConnect still isn’t the standard synchronisation service for Office 365 or Azure AD and requires download from the Microsoft Download Centre. To begin with, I’ve downloaded the AADConnect installer from this location.

Read More

Azure Active Directory Connect high-availability using ‘Staging Mode’

With the Azure Active Directory Connect product (AAD Connect) being announced as generally available to the market (more here, download here), there is a new feature available that will provide a greater speed of recovery of the AAD Sync component. This feature was not available with the previous AAD Sync or DirSync tools and there is little information about it available in the community, so hopefully this model can be considered for your synchronisation design.

Even though the AAD Sync component within the AAD Connect product is based on the Forefront Identity Manager (FIM) synchronisation service, it does not take on the same recovery techniques as FIM. For AAD Sync, you prepare two servers (ideally in different data centres) and install AAD Connect. Your primary server would be configured to perform the main role to synchronise identities between your Active Directory and Azure Active Directory, and the second server installed in much the same way but configured with the setting ‘enable staging mode’ being selected. Both servers are independent and do not share any components such as SQL Server, and the second server is performing the same tasks as the primary except for the following:

  • No exports occur to your on-premise Active Directory
  • No exports occur to Azure Active Directory
  • Password synchronisation and password writeback are disabled.

Should the primary server go offline for a long period of time or become unrecoverable, you can enable the second server by simply running the installation wizard again and disabling staging mode. When the task schedule next runs, it will perform a delta import and synchronisation and identify any differences between the state of the previous primary server and the current server.

Some other items you might want to consider with this design.

  • Configure the task schedule on the second server so that it runs soon after the primary server completes. By default the task schedule runs every 3 hours and launches at a time which is based on when it was installed, therefore the second server task schedule can launch up to a few hours after the primary server runs. Based on the average amount of work the primary server takes, configure the task schedule on the second server to launch say 5-10 minutes later
  • AAD Sync includes a tool called CSExportAnalyzer which displays changes that are staged to be exported to Active Directory or Azure Active Directory. This tool is useful to report on pending exports while the server is in ‘staging mode’
  • Consider using ‘custom sync groups’ which are located in your Active Directory domain. The default installation of the AAD Sync component will create the following groups locally on the server: ADSyncAdmins, ADSyncOperators, ADSyncBrowse and ADSyncPasswordSet. With more than one AAD Sync server, these groups need to be managed on the servers and kept in sync manually. Having the groups in your Active Directory will simplify this administration.

    NOTE: This feature is not yet working with the current AAD Connect download and this blog will be updated when working 100%.

The last two items will be detailed in future blogs.