Skip to content

The special characters of Directory synchronization in an Office 365 environment | Article 1#2 | Part 11#23

In the current article and the next article, we review the main characters of the Directory synchronization process in an Office 365 based environment.The reason that I add two dedicates articles, or this subject is, because of the knowledge about “what happens behind the scenes” of the Directory synchronization, is very crucial to:

  1. Our understanding of the “logic” of the Exchange Online mailbox restore process that we need to follow, in Directory synchronization environment.
  2. Our ability to successfully deal with a scenario, in which the Exchange Online mailbox restores process was implemented inappropriate manner, and in this scenario, we will need to know how to fix the mailbox restore mailbox mistake.

Why do we need to know the Behind the Scenes of Directory synchronization environment in Office 365?

Another rephrasing for this question could be – why do I need to read boring technical information about Directory synchronization and Office 365?

Directory synchronization environment can consider as a complex environment, that defines a logical “binding” of two Active Directory infrastructures, and most of the time, two separated Exchange infrastructures (Exchange on-Premises + Exchange Online in Exchange Hybrid environment).

To be able to deal with Exchange Online mailbox restore scenarios successfully, we will need to be familiar with all the components of the Directory synchronization environment, and understand how this “components” interact with each other.

To be able to understand the “big picture,” we will need to be familiar with the different “layers” of Office 365 in Directory synchronization environment.

Layer 1 – Understanding the logic and the concept of using Directory synchronization and Office 365.

In this layer, we will need how the Directory synchronization “bind” the On-Premise Active Directory with the Office 365 directory – the Azure Active Directory.

The Directory synchronization process “bind” the two different directories using concepts that described as – ImmutableID, Soft Match, and Hard match.

Layer 2 – Understanding the logic and the concept of the relationships, that exists between Active Directory user and his Office 365 user account “replica.”

In this layer, we need to understand the concept such as – “source of authority” that describe a model in which the On-Premise Active Directory is the “source” in which objects are created, and managed.

The Office 365 Directory serve as a “replica,” that contain a copy of the On-Premise Active Directory objects such as a user account, group account, etc.

In other words, On-Premise Active Directory has read and write access to Directory objects and the Office 365 Directory (Azure Active Directory) have only read access to the objects that replicated from Azure Active Directory.

Layer 3 – Understanding the “flow logic” of creating NEW Active Directory user and Deleting Active Directory user in Directory synchronization

Because the Office 365 Directory (Azure Active Directory) considered as “subordinate” of the On-Premise Active Directory, each event such as creating NEW Active Directory user account or deleting On-Premise Active Directory user account, cause “Ripple” that impact the Office 365 Directory.

Why do we need to know the Behind the Scenes of Directory synchronization environment in Office 365 -01

Layer 4 – Understanding the logic of the mandatory need for restoring On-Premise Active Directory user account, in case that we need to recover deleted Exchange Online mailbox.

In a scenario in which we need to recover Exchange Online mailbox in Directory synchronization environment, most of the time, the cause for the “Exchange Online mailbox deletion” is, a deletion of the On-Premise Active Directory user account.

The “right way” for restoring the Exchange Online mailbox is, by restoring the deleted On-Premise Active Directory user account.

Layer 5 – Understanding the source for Exchange Online mailbox recovery mistakes

As mentioned, Directory synchronization environment can consider as complex infrastructure.
Because of this “complexity, one of the most common scenarios is a scenario in which the restore of a deleted Exchange Online mailbox implemented Improperly. In this layer, we need to understand the case for this improperly change Online restore mailbox scenario.

Layer 6 – Understanding the methods that we can use for dealing and repair Exchange Online mailbox recovery mistakes.

Knowing what is the cause for mailbox recovery mistakes is not enough.

In this layer, we will need to be familiar with the methods, and the options, that we can use for fixing the Improperly mailbox restore.

Why do we need to know the Behind the Scenes of Directory synchronization environment in Office 365 -02

The relationship between On-Premise Active Directory user and his Office 365 “user replica”

The simple meaning of Directory synchronization environment is an environment that includes more than one Directory.

The Directory synchronization infrastructure is dealing with the relationship between the “directories,” and the general purpose as the name implies is – implementing a synchronization mechanism which will correlate between the two (or more) different directories.

For example, when “something” happened in Directory A, synchronize the information to Directory B.

Because in Directory synchronization, there are two or more involved directories, one of the most basic configuration settings, relate to the “synchronization model” that will implement.

1. Equal or two-way synchronization model

In case that a NEW object created in the Directory A, the information will be synchronized to Directory B and thus, a NEW object will also create in Directory B.

The same logic is implemented in the opposite direction – when a NEW object created in Directory, B, and the information will synchronized with Directory A, and thus, a NEW object will also create in Directory A.

Directory synchronization infrastructure - Equal or two-way synchronization model -01

2. “Non-Equal” or one-way synchronization model

This type of synchronization model, define a “non-equal” relationship model. In this model, one Directory considers as “source of authority,” and the another Directory considers as a “subordinate” of the “source of authority Directory.”

For example – In case that a NEW object created in the Directory A, the information will be synchronized to Directory B and thus, a NEW object will also create in Directory B.

The same concept is not implemented in the opposite direction because in this case, Directory B serves as a “replica” of Directory A.

Updates such as adding a NEW user account in Directory B will not replicate (synchronized) to Directory A.

In this type of model, most of the time, we should not create any update in Directory B but instead, create all the required updates in Directory A, and the information about the updates will synchronized to Directory B.

Directory synchronization infrastructure in Office 365 based environment -02

Directory synchronization infrastructure in Office 365 based environment

The Directory synchronization model that implemented in an Office 365 based environment is the model which described as – “Non-Equal” or one-way synchronization model.”

Directory synchronization in Office 365 implemented in the following way; the On-Premise Active Directory considers as the “source of authority Directory.”

The management of the objects such as creating a NEW user account or updating the information about existing user accounts, should be created only in the On-Premise Active Directory.

The Directory synchronization server (Azure AD Connect), is the software component, that considers as responsible for “fetching” the information from On-Premise Active Directory, and synchronize the information to the Office 365 Directory meaning – Azure Active Directory.

Directory synchronization infrastructure -Non-Equal or one-way synchronization model -03

To be able to deal with a scenario of restoring Exchange Online mailbox in Directory synchronization based environment or, to “fix” an Exchange Online mailbox recover restore mistake in Directory synchronization environment, we will need to be familiar with the following subjects:

  1. How the On-Premise Active Directory user objects is “bound” to Office 365 user object in Directory synchronization environment.
  2. What is the chain of events that are triggered, when we create a NEW On-Premise Active Directory user account?
  3. What is the chain of events that are triggered, when we delete an On-Premise Active Directory user account?
The gears in Office 365 Directory synchronization environment

The component in Directory synchronization environment

In the following diagram, we can see the involved components in Directory synchronization environment.

  1. On-Premise Active Directory – this is the directory in which the users and group objects are crated + updated.
  2. The Directory synchronization server accesses the On-Premise Active Directory and “pull” the information (user, group, a contact object, etc.).

The Directory synchronization server, access the Azure Active Directory and “push” (synchronize) the information.

  1. The Azure Active Directory can describe as “Office 365 directory services.”
    When the Office 365 Administrator assigned to a particular “Synchronized Office 365 users” an Exchange Online license, the information is synchronized from the Azure Active Directory to Exchange Online infrastructure.
  2. Exchange Online infrastructure – an Exchange Online mailbox created, and associated with the Office 365 user account.
Office 365 and Directory synchronization environment ?- The infrastructure components -01

Management of the “directory objects” in Directory synchronization environment

In a directory synchronized environment, that task of creating “NEW objects” such as – user account and group account, should be created only in the On-Premise Active Directory because of the synchronization model based on the concept of – “one-way synchronization.”

Information from the On-Premise environment synchronized to the cloud, but not vice versa.

Later, we will understand better how these characters are related to scenarios such as a deletion of On-Premise Active Directory user account, and how this deletion impacts the cloud’s infrastructure.

Note: The declaration is not fully accurate because, regarding a very particular property, the synchronization process is implemented when information from Office 365 Directory is “sent” and updated in the On-Premise Active Directory.

For the simplicity purpose, let’s stick to the basic definition that defines the synchronization direction as “one-way synchronization.”

Directory synchronization environment - The Active Directories -02

Directory Synchronization and the concept of “ImmutableID”

As mentioned, Azure Active Directory serves as a replica for On-Premise Active Directory objects and also, the Office 365 Directory, need to “know” about the relationship that exists between the Office 365 user accounts and their “masters” located at the On-Premise Active Directory.

The method that used for enabling the Azure Active Directory to “understand” that a particular Office 365 user account is “replicated” (synchronized) from the On-Premise Active Directory describe as – ImmutableID.

From the Azure Active Directory point of view, the meaning Office 365 that has the ImmutableID is, that this Office 365 user is “bound” to On-Premise Active Directory user account.

The Azure Active Directory “understand” that she is not the owner of this object, but instead, just “host” replicated entity that represents an On-Premise Active Directory user account.

The “binding mechanism” that connects On-Premise Active Directory user with the Office 365 user account

As mentioned, Active Directory objects such as, “User accounts,” are synchronized from the On-Premise Active Directory to the Azure Active Directory.

For example, an On-Premise Active Directory user account named John synced to the “cloud” (Azure Active Directory), and a NEW user named John created in the Azure Active Directory.

Technically, now have two different user accounts, that stored in two different directories.

In Directory synchronization environment, we need to define a logical structure, in which need to relate to two different users accounts as “one entity.”

Metaphorically, we need to implement a mechanism, that “glue” the On-Premise Active Directory user account with the Office 365 Directory user account. Each user account updates in the On-Premise Active Directory of user properties will successfully synchronize to the “matching” Office 365 Directory user account, and the “matching Office 365 users” will be updated respectively.

The method that used for “binding” On-Premise Active Directory object with the cloud Active Directory object implemented by using a value named – ImmutableID.

The relationship between On-Premise Active Directory -Azure Active Directory -01

The term “ImmutableID” sound, strange and mysterious. However, the concept of the “ImmutableID” is quite simple.

In case that the “Office 365 user account” was created via the Directory synchronization process, the “ImmutableID” value of the Office 365 user will populate.

The value of the “ImmutableID” is populated with the GUID value of the On-Premise Active Directory user account.

Now we are dealing with a new term – the GUID!

The term GUID, stand for – Global Unique Identifier.
We use the GUID value as a method for, providing a unique identity for each Active Directory object.
We describe this identity as “unique” because no other Active Directory object could have an identical GUID value.

We can compare the purpose of GUID value to other “identity methods,” such a “social security number” or, the MAC address that each network card has.

We mentioned that the GUID value of the On-Premise Active Directory user account is copied and saved as the ImmutableID value of the Office 365 user account.

If we want to be more accurate, in an Office 365 based environment, the GUID value of the On-Premise Active Directory user is converted into a 64-bit value and then saved as the ImmutableID value.

So technically, if we try to compare the GUID value to the ImmutableID value of the Office 365 user account, we see an apparently different value.

ImmutableId and GUID-02

In the following diagram, we can see an example of the relationship that exists between the On-Premise Active Directory user account and the synchronized cloud user object.

The GUID value of “John” is synchronized as part of John’s attributes to the Office 365 Directory (Azure Active Directory).
When “John cloud user account” is created, the GUID value will be saved in the ImmutableID attribute.

Notice that the values look different!

The reason for the difference is because the original GUID value is undergoing a process of conversion to 64-bit format.

The relationship between On-Premise Active Directory -Azure Active Directory -02

The binding between the Office 365 user account and Exchange Online mailbox.

In case that we assign Exchange Online license to the “synchronized Office 365 user account” (such as John from the previous example), a NEW Exchange Online mailbox is created and “attached” to the Office 365 user account.

The Office 365 user account considers as the “owner” of the Exchange Online mailbox.

The relationship between On-Premise Active Directory -Azure Active Directory -03

The complete binding infrastructure

Now, we can define the following “binding flow” when we create a NEW On-Premise Active Directory user account and assign Exchange Online license to the Office 365 NEW Office 365 user account that created:

  • The Office 365 user account is “attached” to an On-Premise Active Directory user account.
  • When we assign Exchange Online license to the Office 365 user account, a NEW Exchange Online mailbox is created and “attached” to an Office 365 user account.
  • The Office 365 user account, considers as the owner of the Exchange Online mailbox
  • The On-Premise Active Directory user account, consider as “source of authority” relating to the Office 365 user accounts.

A scenario in which the On-Premise Active Directory user account deleted.

  1. In case that the On-Premise Active Directory user account deleted, the consequence will be, that the Office 365 user account will also be deleted.
  2. In case that the Office 365 user account is deleted, the Exchange Online license will be removed.
  3. When the Exchange Online license is removed, the consequence is that the Exchange Online mailbox will also be deleted!

Directory synchronization and the concept of “Hard Match”

The formal term that we use for describing the relationship between On-Premise Active Directory user account and his Office 365 synchronized user account is – Hard Match.

The implementation of the Hard Match relies on the “match” that exists between the GUID value of On-Premise Active Directory user account and the ImmutableID value of his sensitized Office 365 user account “partner.”

Hard match – the Directory synchronization mechanism that glue - On-Premise

When we create a NEW Active Directory user account, and the information is synchronized to the Azure Active Directory (by the Directory synchronization server), the Azure Active Directory creates a NEW user account, which will be “bound” to the On-Premise Active Directory NEW account.

In this case, the Office 365 user ImmutableID value, is populated with the On-Premise Active Directory user GUID value.

The concept of Hard Match -01

From now on, the two different user accounts are “bonded” to each other. In other words, the relationship between the two user account defended as – Hard Match.

The concept of Hard Match -02

The use of the Hard Match mechanism in a scenario of restoring Exchange Online mailbox

An example of the Hard Match concept can be – the process of implementing the “best practice” Exchange Online mailbox restores in Active Directory based environment.

An Active Directory Active Directory user, that was “bound” to the Office 365 user who was considered as an Exchange Online mailbox was restored.

When the information reaches to Azure Active Directory, Azure Active Directory “notice” that the GUID value of the “recovered Active Directory user account” is identical to the ImmutableID value of a “Soft Deleted Office 365 users” (the user who stored in the Azure Active Directory recycle bin).

Because the GUID value and Office 365 ImmutableID value are identical, this is a sure sign that these objects are “related to each other.”

The fact that the Soft Deleted Office 365 has ImmutableID that is identical to the “New synchronized Active Directory user,” means that these two objects were connected in the past.

The process of “binding” the two user objects is considered as – Hard match.

After the process of “binding the two user accounts” (Hard match) is completed, the Azure Active Directory will automatically start the restore process of the Soft Deleted Office 365 user account (number 2 in the diagram).

The restore process of the Office 365 user account based on the following logic – if the On-Premise Active Directory user account (the master of the Office 365 user account) is “alive,” the Office 365 user account that is associated with this Active Directory user account, also need to be “alive” (restored from the Azure Active Directory recycle bin).

The concept of Hard Match -03

Directory Synchronization and the concept of “Soft Match”

In Directory synchronization environment, the term “Soft Match” defines a scenario in which we have On-Premise Active Directory user account and Office 365 user account that have an identical property such as E-mail address or user UPN (user principal name), but they don’t have a relationship of “Hard Match.”

In other words, the Office 365 user account ImmutableID value is “empty.”

For example- On-Premise Active Directory user who E-mail address is – John@o365info.com and Office 365 user who uses the same E-mail address (John@o365info.com).

Theoretically, the scenario is “wrong” because as mentioned, in Office 365 Directory synchronization environment, we should create objects such as user account using the Azure Active Directory.

Theoretically, the scenario in which On-Premise Active Directory user account and Office 365 user account have the same E-mail address is not “allowed.”

The only option for this scenario to realize is if the Office 365 users were created via the Office 365 Directory (Azure Active Directory) in contrary to the guidelines of creating and managing the user account in Office 365 Directory synchronization environment.

The guys who create the Directory synchronization server understood that the reality can be more complicated and that the Directory synchronization will need to adapt to this “non-standard” scenario.

For example – a scenario in which we use non-synchronized environment, and manually creating all the organization users via the Azure Active Directory.

At a later stage, we install Directory synchronization server and start the synchronization process.

The expected result is a “collision.”

In case that two Directory users (On-Premise Active Directory user and Office 365 Directory user), have the same login name or the same E-mail address, this is a “violation” of the standard flow, in which Directory object are supposed to be created only via the On-Premise Active Directory.

The good news is that the Office 365 Directory synchronization is smart enough to recognize such a scenario and to understand that this two-user account’s entity should be “bind” tighter as a “synchronization couple,” even though there is not Hard Match between the two user accounts.

In other words, the Directory synchronization understands that even though there is no “documentation” of the fact that these two Active Directory user accounts are related to each other (have a relationship), the “right procedure” is to bind these two entities together by implementing the mechanism of – Hard match.

In the following diagram, we can see an example to a scenario, in which we have two different users account that their login name – John@o365info.com

When we activate the Directory synchronization server, the Directory synchronization server “inform” the Azure Active Directory about On-Premise Active Directory user account that his login name is John@o365info.com.

The Azure Active Directory, “informs” the Directory synchronization server that she already has a user account with the same login name.

The Directory Synchronization “understand” that he needs to “attach” these user accounts.

The Directory synchronization copies the GUID value of John On-Premise Active Directory user account, convert the value to 64-bit value, and copy the result to the ImmutableID value of the Office 365 John user account.

The concept of Soft Match when restoring Active Directory Soft Deleted user account - Step 1-2

The status of John Office 365 user account is changed from “in cloud” into “synchronized with Active Directory.”
From now on, this two Directory user account considers as a “couple.”
The On-Premise Active Directory user account, consider as the “master” because the On-Premise Active Directory is the source of authority. Each update in the On-Premise Active Directory John user account will be synchronized and “override” existing information in the “John Office 365 user account”.

The concept of Soft Match when restoring Active Directory Soft Deleted user account - Step 2-2

The next article in the current article series

The special characters of Directory synchronization in an Office 365 environment | Article 2#2 | Part 12#23

o365info Team

o365info Team

This article was written by our team of experienced IT architects, consultants, and engineers.

This Post Has 0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *