ADConnect

Table of Contents
Overview
What is Azure AD Connect?
What is Azure AD Connect Sync?
Users and contacts
Architecture
Declarative Provisioning
Default configuration
What is Azure AD Connect and Federation?
Get started
Prerequisites
Install Azure AD Connect
Express settings
Custom settings
Upgrade from DirSync
Upgrade from a previous version
How to
Plan and design
Design concepts
Topologies for Azure AD Connect
Special considerations for instances
Manage Azure AD Connect
Renew certs for O365 and Azure AD
Enable device writeback
User sign-on options
Multiple domain support for federating
Automatic upgrade
Manage Azure AD Connect Sync
Prevent accidental deletes
Password synchronization
Azure AD service account
Installation wizard
Change the default configuration
Configure Filtering
Scheduler
Directory extensions
Synchronization Service Manager
Manage Federation Services
Manage and customize
Troubleshoot
Connectivity
Errors during synchronization
Reference
Identity synchronization and duplicate attribute resiliency
Hybrid Identity Required Ports and Protocols
Features in preview
Version History
Accounts and permissions
Azure AD Connect Sync
Attributes synchronized to Azure Active Directory
Connector Version Release History
Functions Reference
Operational tasks and consideration
Azure AD federation compatibility list
Technical Concepts
Service features
Related
Monitor your on-premises identity infrastructure and synchronization services in the
cloud
Hybrid Identity Design Guide
Resources
Azure AD Connect FAQ
DirSync Deprecation
Connect Active Directory with Azure Active
Directory.
2/7/2017 7 min to read Edit on GitHub
Azure AD Connect will integrate your on-premises directories with Azure Active Directory. This allows you to
provide a common identity for your users for Office 365, Azure, and SaaS applications integrated with Azure
AD. This topic will guide you through the planning, deployment, and operation steps. It is a collection of links
to the topics related to this area.
IMPORTANT
Azure AD Connect is the best way to connect your on-premises directory with Azure AD and Office 365. This is a great
time to upgrade to Azure AD Connect from Windows Azure Active Directory Sync (DirSync) or Azure AD Sync as these
tools are now deprecated and will reach end of support on April 13, 2017.
Why use Azure AD Connect

Integrating your on-premises directories with Azure AD makes your users more productive by providing a
common identity for accessing both cloud and on-premises resources. Users and organizations can take
advantage of the following:
Users can use a single identity to access on-premises applications and cloud services such as Office 365.
Single tool to provide an easy deployment experience for synchronization and sign-in.
Provides the newest capabilities for your scenarios. Azure AD Connect replaces older versions of identity
integration tools such as DirSync and Azure AD Sync. For more information, see Hybrid Identity directory
integration tools comparison.
How Azure AD Connect works
Azure Active Directory Connect is made up of three primary components: the synchronization services, the
optional Active Directory Federation Services component, and the monitoring component named Azure AD
Connect Health.
Synchronization - This component is responsible for creating users, groups, and other objects. It is also
responsible for making sure identity information for your on-premises users and groups is matching the
cloud.
AD FS - Federation is an optional part of Azure AD Connect and can be used to configure a hybrid
environment using an on-premises AD FS infrastructure. This can be used by organizations to address
complex deployments, such as domain join SSO, enforcement of AD sign-in policy, and smart card or 3rd
party MFA.
Health Monitoring - Azure AD Connect Health can provide robust monitoring and provide a central
location in the Azure portal to view this activity. For additional information, see Azure Active Directory
Connect Health.

You can find the download for Azure AD Connect on Microsoft Download Center.
SOLUTION SCENARIO
Before you start - Hardware and prerequisites Steps to complete before you start to install Azure AD
Connect.
Express settings If you have a single forest AD then this is the

recommended option to use.
User sign in with the same password using password
synchronization.
Customized settings Used when you have multiple forests. Supports many
on-premises topologies.
Customize your sign-in option, such as ADFS for
federation or use a 3rd party identity provider.
Customize synchronization features, such as filtering and
writeback.
Upgrade from DirSync Used when you have an existing DirSync server already
running.
SOLUTION SCENARIO
Upgrade from Azure AD Sync or Azure AD Connect There are several different methods depending on your
preference.
After installation you should verify it is working as expected and assign licenses to the users.
Next steps to Install Azure AD Connect
TOPIC LINK
Download Azure AD Connect Download Azure AD Connect
Install using Express settings Express installation of Azure AD Connect
Install using Customized settings Custom installation of Azure AD Connect
Upgrade from DirSync Upgrade from Azure AD sync tool (DirSync)
After installation Verify the installation and assign licenses
Learn more about Install Azure AD Connect

You also want to prepare for operational concerns. You might want to have a stand-by server so you easily
can fall over if there is a disaster. If you plan to make frequent configuration changes, you should plan for a
staging mode server.
TOPIC LINK
Supported topologies Topologies for Azure AD Connect
Design concepts Azure AD Connect design concepts
Accounts used for installation More about Azure AD Connect credentials and permissions
Operational planning Azure AD Connect sync: Operational tasks and

considerations
User sign-in options Azure AD Connect User sign-in options
Configure sync features

Azure AD Connect comes with several features you can optionally turn on or are enabled by default. Some
features might sometimes require more configuration in certain scenarios and topologies.
Filtering is used when you want to limit which objects are synchronized to Azure AD. By default all users,
contacts, groups, and Windows 10 computers are synchronized. You can change the filtering based on
domains, OUs, or attributes.
Password synchronization synchronizes the password hash in Active Directory to Azure AD. The end-user can
use the same password on-premises and in the cloud but only manage it in one location. Since it uses your
on-premises Active Directory as the authority, you can also use your own password policy.
Password writeback will allow your users to change and reset their passwords in the cloud and have your on-
premises password policy applied.
Device writeback will allow a device registered in Azure AD to be written back to on-premises Active
Directory so it can be used for conditional access.
The prevent accidental deletes feature is turned on by default and protects your cloud directory from
numerous deletes at the same time. By default it allows 500 deletes per run. You can change this setting
depending on your organization size.
Automatic upgrade is enabled by default for express settings installations and ensures your Azure AD
Connect is always up to date with the latest release.
Next steps to configure sync features
TOPIC LINK
Configure filtering Azure AD Connect sync: Configure filtering
Password synchronization Azure AD Connect sync: Implement password

synchronization
Password writeback Getting started with password management
Device writeback Enabling device writeback in Azure AD Connect
Prevent accidental deletes Azure AD Connect sync: Prevent accidental deletes
Automatic upgrade Azure AD Connect: Automatic upgrade
Customize Azure AD Connect sync

Azure AD Connect sync comes with a default configuration that is intended to work for most customers and
topologies. But there are always situations where the default configuration does not work and must be
adjusted. It is supported to make changes as documented in this section and linked topics.
If you have not worked with a synchronization topology before you want to start to understand the basics
and the terms used as described in the technical concepts. Azure AD Connect is the evolution of MIIS2003,
ILM2007, and FIM2010. Even if some things are identical, a lot has changed as well.
The default configuration assumes there might be more than one forest in the configuration. In those
topologies a user object might be represented as a contact in another forest. The user might also have a
linked mailbox in another resource forest. The behavior of the default configuration is described in users and
contacts.
The configuration model in sync is called declarative provisioning. The advanced attribute flows are using
functions to express attribute transformations. You can see and examine the entire configuration using tools
which comes with Azure AD Connect. If you need to make configuration changes, make sure you follow the
best practices so it is easier to adopt new releases.
Next steps to customize Azure AD Connect sync
TOPIC LINK
All Azure AD Connect sync articles Azure AD Connect sync
Technical concepts Azure AD Connect sync: Technical Concepts

TOPIC LINK
Understanding the default configuration Azure AD Connect sync: Understanding the default
configuration
Understanding users and contacts Azure AD Connect sync: Understanding Users and
Contacts
Declarative provisioning Azure AD Connect Sync: Understanding Declarative

Provisioning Expressions
Change the default configuration Best practices for changing the default configuration
Configure federation features

ADFS can be configured to support multiple domains. For example you might have multiple top domains you
need to use for federation.
if your ADFS server has not been configured to automatically update certificates from Azure AD or if you use
a non-ADFS solution, then you will be notified when you have to update certificates.
Next steps to configure federation features
TOPIC LINK
All AD FS articles Azure AD Connect and federation
Configure ADFS with subdomains Multiple Domain Support for Federating with Azure AD
Manage AD FS farm AD FS management and customizaton with Azure AD

Connect
Manually updating federation certificates Renewing Federation Certificates for Office 365 and Azure
AD
More information and references

TOPIC LINK
Version history Version history
Compare DirSync, Azure ADSync, and Azure AD Connect Directory integration tools comparison
Non-ADFS compatibility list for Azure AD Azure AD federation compatibility list
Attributes synchronized Attributes synchronized
Monitoring using Azure AD Connect Health Azure AD Connect Health
Frequently Asked Questions Azure AD Connect FAQ
Additional Resources
Ignite 2015 presentation on extending your on-premises directories to the cloud.
Azure AD Connect sync: Understand and customize
synchronization
The Azure Active Directory Connect synchronization services (Azure AD Connect sync) is a main component of
Azure AD Connect. It takes care of all the operations that are related to synchronize identity data between your
on-premises environment and Azure AD. Azure AD Connect sync is the successor of DirSync, Azure AD Sync,
and Forefront Identity Manager with the Azure Active Directory Connector configured.
This topic is the home for Azure AD Connect sync (also called sync engine) and lists links to all other topics
related to it. For links to Azure AD Connect, see Integrating your on-premises identities with Azure Active
Directory.
The sync service consists of two components, the on-premises Azure AD Connect sync component and the
service side in Azure AD called Azure AD Connect sync service. The service is common for DirSync, Azure AD
Sync, and Azure AD Connect.
Azure AD Connect sync topics

TOPIC WHAT IT COVERS AND WHEN TO READ
Azure AD Connect sync fundamentals
Understanding the architecture For those of you who are new to the sync engine and want
to learn about the architecture and the terms used.
Technical concepts A short version of the architecture topic and briefly explains
the terms used.
Topologies for Azure AD Connect Describes the different topologies and scenarios the sync
engine supports.
Custom configuration
Running the installation wizard again Explains what options you have available when you run the
Azure AD Connect installation wizard again.
Understanding Declarative Provisioning Describes the configuration model called declarative

provisioning.
Understanding Declarative Provisioning Expressions Describes the syntax for the expression language used in
declarative provisioning.
Understanding the default configuration Describes the out-of-box rules and the default
configuration. Also describes how the rules work together
for the out-of-box scenarios to work.
Understanding Users and Contacts Continues on the previous topic and describes how the
configuration for users and contacts works together, in
particular in a multi-forest environment.
How to make a change to the default configuration Walks you through how to make a common configuration
change to attribute flows.
Best practices for changing the default configuration Support limitations and for making changes to the out-of-
box configuration.
Configure Filtering Describes the different options for how to limit which
objects are being synchronized to Azure AD and step-by-
step how to configure these options.
Features and scenarios
Prevent accidental deletes Describes the prevent accidental deletes feature and how to
configure it.
Scheduler Describes the built-in scheduler, which is importing,

synchronizing, and exporting data.
Implement password synchronization Describes how password synchronization works, how to

implement, and how to operate and troubleshoot.
Device writeback Describes how device writeback works in Azure AD Connect.
Directory extensions Describes how to extend the Azure AD schema with your
own custom attributes.
Sync Service
Azure AD Connect sync service features Describes the sync service side and how to change sync
settings in Azure AD.
Duplicate attribute resiliency Describes how to enable and use userPrincipalName and
proxyAddresses duplicate attribute values resiliency.
Operations and UI
Synchronization Service Manager Describes the Synchronization Service Manager UI, including
Operations, Connectors, Metaverse Designer, and
Metaverse Search tabs.
Operational tasks and considerations Describes operational concerns, such as disaster recovery.
How To...
Reset the Azure AD account How to reset the credentials of the service account used to
connect from Azure AD Connect sync to Azure AD.
More information and references
Ports Lists which ports you need to open between the sync
engine and your on-premises directories and Azure AD.
Attributes synchronized to Azure Active Directory Lists all attributes being synchronized between on-premises
AD and Azure AD.
Functions Reference Lists all functions available in declarative provisioning.
Integrating your on-premises identities with Azure Active Directory
Azure AD Connect sync: Understanding Users and
Contacts
There are several different reasons why you would have multiple Active Directory forests and there are several
different deployment topologies. Common models include an account-resource deployment and GAL synced
forests after a merger & acquisition. But even if there are pure models, hybrid models are common as well. The
default configuration in Azure AD Connect sync does not assume any particular model but depending on how user
matching was selected in the installation guide, different behaviors can be observed.
In this topic, we will go through how the default configuration behaves in certain topologies. We will go through
the configuration and the Synchronization Rules Editor can be used to look at the configuration.
There are a few general rules the configuration assumes:
Regardless of which order we import from the source Active Directories, the end result should always be the
same.
An active account will always contribute sign-in information, including userPrincipalName and
sourceAnchor.
A disabled account will contribute userPrincipalName and sourceAnchor, unless it is a linked mailbox, if there is
no active account to be found.
An account with a linked mailbox will never be used for userPrincipalName and sourceAnchor. It is assumed
that an active account will be found later.
A contact object might be provisioned to Azure AD as a contact or as a user. You dont really know until all
source Active Directory forests have been processed.
Contacts
Having contacts representing a user in a different forest is common after a merger & acquisition where a GALSync
solution is bridging two or more Exchange forests. The contact object is always joining from the connector space
to the metaverse using the mail attribute. If there is already a contact object or user object with the same mail
address, the objects are joined together. This is configured in the rule In from AD Contact Join. There is also a
rule named In from AD Contact Common with an attribute flow to the metaverse attribute
sourceObjectType with the constant Contact. This rule has very low precedence so if any user object is joined to
the same metaverse object, then the rule In from AD User Common will contribute the value User to this
attribute. With this rule, this attribute will have the value Contact if no user has been joined and the value User if at
least one user has been found.
For provisioning an object to Azure AD, the outbound rule Out to AAD Contact Join will create a contact object
if the metaverse attribute sourceObjectType is set to Contact. If this attribute is set to User, then the rule Out to
AAD User Join will create a user object instead. It is possible that an object is promoted from Contact to User
when more source Active Directories are imported and synchronized.
For example, in a GALSync topology we will find contact objects for everyone in the second forest when we import
the first forest. This will stage new contact objects in the AAD Connector. When we later import and synchronize
the second forest, we will find the real users and join them to the existing metaverse objects. We will then delete
the contact object in AAD and create a new user object instead.
If you have a topology where users and represented as contacts, make sure you select to match users on the mail
attribute in the installation guide. If you select another option, then you will have an order dependent
configuration. Contact objects will always join on the mail attribute, but user objects will only join on the mail
attribute if this option was selected in the installation guide. You could then end up with two different objects in
the metaverse with the same mail attribute if the contact object was imported before the user object. During
export to Azure AD, an error will be thrown. This behavior is by design and would indicate bad data or that the
topology was not correctly identified during the installation.
Disabled accounts
Disabled accounts are synchronized as well to Azure AD. Disabled accounts are common to represent resources in
Exchange, for example conference rooms. The exception is users with a linked mailbox; as previously mentioned,
these will never provision an account to Azure AD.
The assumption is that if a disabled user account is found, then we will not find another active account later and
the object is provisioned to Azure AD with the userPrincipalName and sourceAnchor found. In case another active
account will join to the same metaverse object, then its userPrincipalName and sourceAnchor will be used.
Changing sourceAnchor
When an object has been exported to Azure AD then it is not allowed to change the sourceAnchor anymore. When
the object has been exported the metaverse attribute cloudSourceAnchor is set with the sourceAnchor value
accepted by Azure AD. If sourceAnchor is changed and not match cloudSourceAnchor, the rule Out to AAD
User Join will throw the error sourceAnchor attribute has changed. In this case, the configuration or data must
be corrected so the same sourceAnchor is present in the metaverse again before the object can be synchronized
again.
Azure AD Connect Sync: Customizing Synchronization options
Azure AD Connect sync: Understanding the
architecture
This topic covers the basic architecture for Azure AD Connect sync. In many aspects, it is similar to its predecessors
MIIS 2003, ILM 2007, and FIM 2010. Azure AD Connect sync is the evolution of these technologies. If you are
familiar with any of these earlier technologies, the content of this topic will be familiar to you as well. If you are new
to synchronization, then this topic is for you. It is however not a requirement to know the details of this topic to be
successful in making customizations to Azure AD Connect sync (called sync engine in this topic).
Architecture
The sync engine creates an integrated view of objects that are stored in multiple connected data sources and
manages identity information in those data sources. This integrated view is determined by the identity information
retrieved from connected data sources and a set of rules that determine how to process this information.
Connected Data Sources and Connectors
The sync engine processes identity information from different data repositories, such as Active Directory or a SQL
Server database. Every data repository that organizes its data in a database-like format and that provides standard
data-access methods is a potential data source candidate for the sync engine. The data repositories that are
synchronized by sync engine are called connected data sources or connected directories (CD).
The sync engine encapsulates interaction with a connected data source within a module called a Connector. Each
type of connected data source has a specific Connector. The Connector translates a required operation into the
format that the connected data source understands.
Connectors make API calls to exchange identity information (both read and write) with a connected data source. It
is also possible to add a custom Connector using the extensible connectivity framework. The following illustration
shows how a Connector connects a connected data source to the sync engine.
Data can flow in either direction, but it cannot flow in both directions simultaneously. In other words, a Connector
can be configured to allow data to flow from the connected data source to sync engine or from sync engine to the
connected data source, but only one of those operations can occur at any one time for one object and attribute. The
direction can be different for different objects and for different attributes.
To configure a Connector, you specify the object types that you want to synchronize. Specifying the object types
defines the scope of objects that are included in the synchronization process. The next step is to select the attributes
to synchronize, which is known as an attribute inclusion list. These settings can be changed any time in response to
changes to your business rules. When you use the Azure AD Connect installation wizard, these settings are
configured for you.
To export objects to a connected data source, the attribute inclusion list must include at least the minimum
attributes required to create a specific object type in a connected data source. For example, the sAMAccountName
attribute must be included in the attribute inclusion list to export a user object to Active Directory because all user
objects in Active Directory must have a sAMAccountName attribute defined. Again, the installation wizard does
this configuration for you.
If the connected data source uses structural components, such as partitions or containers to organize objects, you
can limit the areas in the connected data source that are used for a given solution.
Internal structure of the sync engine namespace
The entire sync engine namespace consists of two namespaces that store the identity information. The two
namespaces are:
The connector space (CS)
The metaverse (MV)
The connector space is a staging area that contains representations of the designated objects from a connected
data source and the attributes specified in the attribute inclusion list. The sync engine uses the connector space to
determine what has changed in the connected data source and to stage incoming changes. The sync engine also
uses the connector space to stage outgoing changes for export to the connected data source. The sync engine
maintains a distinct connector space as a staging area for each Connector.
By using a staging area, the sync engine remains independent of the connected data sources and is not affected by
their availability and accessibility. As a result, you can process identity information at any time by using the data in
the staging area. The sync engine can request only the changes made inside the connected data source since the
last communication session terminated or push out only the changes to identity information that the connected
data source has not yet received, which reduces the network traffic between the sync engine and the connected
data source.
In addition, sync engine stores status information about all objects that it stages in the connector space. When new
data is received, sync engine always evaluates whether the data has already been synchronized.
The metaverse is a storage area that contains the aggregated identity information from multiple connected data
sources, providing a single global, integrated view of all combined objects. Metaverse objects are created based on
the identity information that is retrieved from the connected data sources and a set of rules that allow you to
customize the synchronization process.
The following illustration shows the connector space namespace and the metaverse namespace within the sync
engine.
Sync engine identity objects

The objects in the sync engine are representations of either objects in the connected data source or the integrated
view that sync engine has of those objects. Every sync engine object must have a globally unique identifier (GUID).
GUIDs provide data integrity and express relationships between objects.
Connector space objects
When sync engine communicates with a connected data source, it reads the identity information in the connected
data source and uses that information to create a representation of the identity object in the connector space. You
cannot create or delete these objects individually. However, you can manually delete all objects in a connector
space.
All objects in the connector space have two attributes:
A globally unique identifier (GUID)
A distinguished name (also known as DN)
If the connected data source assigns a unique attribute to the object, then objects in the connector space can also
have an anchor attribute. The anchor attribute uniquely identifies an object in the connected data source. The sync
engine uses the anchor to locate the corresponding representation of this object in the connected data source. Sync
engine assumes that the anchor of an object never changes over the lifetime of the object.
Many of the Connectors use a known unique identifier to generate an anchor automatically for each object when it
is imported. For example, the Active Directory Connector uses the objectGUID attribute for an anchor. For
connected data sources that do not provide a clearly defined unique identifier, you can specify anchor generation
as part of the Connector configuration.
In that case, the anchor is built from one or more unique attributes of an object type, neither of which changes, and
that uniquely identifies the object in the connector space (for example, an employee number or a user ID).
A connector space object can be one of the following:
A staging object
A placeholder
Staging Objects
A staging object represents an instance of the designated object types from the connected data source. In addition
to the GUID and the distinguished name, a staging object always has a value that indicates the object type.
Staging objects that have been imported always have a value for the anchor attribute. Staging objects that have
been newly provisioned by sync engine and are in the process of being created in the connected data source do not
have a value for the anchor attribute.
Staging objects also carry current values of business attributes, and operational information needed by sync engine
to perform the synchronization process. Operational information includes flags that indicate the type of updates
that are staged on the staging object. If a staging object has received new identity information from the connected
data source that has not yet been processed, the object is flagged as pending import. If a staging object has new
identity information that has not yet been exported to the connected data source, it is flagged as pending export.
A staging object can be an import object or an export object. The sync engine creates an import object by using
object information received from the connected data source. When sync engine receives information about the
existence of a new object that matches one of the object types selected in the Connector, it creates an import object
in the connector space as a representation of the object in the connected data source.
The following illustration shows an import object that represents an object in the connected data source.
The sync engine creates an export object by using object information in the metaverse. Export objects are exported
to the connected data source during the next communication session. From the perspective of the sync engine,
export objects do not exist in the connected data source yet. Therefore, the anchor attribute for an export object is
not available. After it receives the object from sync engine, the connected data source creates a unique value for the
anchor attribute of the object.
The following illustration shows how an export object is created by using identity information in the metaverse.
The sync engine confirms the export of the object by reimporting the object from the connected data source. Export
objects become import objects when sync engine receives them during the next import from that connected data
source.
Placeholders
The sync engine uses a flat namespace to store objects. However, some connected data sources such as Active
Directory use a hierarchical namespace. To transform information from a hierarchical namespace into a flat
namespace, sync engine uses placeholders to preserve the hierarchy.
Each placeholder represents a component (for example, an organizational unit) of an object's hierarchical name
that has not been imported into sync engine but is required to construct the hierarchical name. They fill gaps
created by references in the connected data source to objects that are not staging objects in the connector space.
The sync engine also uses placeholders to store referenced objects that have not yet been imported. For example, if
sync is configured to include the manager attribute for the Abbie Spencer object and the received value is an object
that has not been imported yet, such as CN=Lee Sperry,CN=Users,DC=fabrikam,DC=com, the manager
information is stored as placeholders in the connector space. If the manager object is later imported, the
placeholder object is overwritten by the staging object that represents the manager.
Metaverse objects
A metaverse object contains the aggregated view that sync engine has of the staging objects in the connector
space. Sync engine creates metaverse objects by using the information in import objects. Several connector space
objects can be linked to a single metaverse object, but a connector space object cannot be linked to more than one
metaverse object.
Metaverse objects cannot be manually created or deleted. The sync engine automatically deletes metaverse objects
that do not have a link to any connector space object in the connector space.
To map objects within a connected data source to a corresponding object type within the metaverse, sync engine
provides an extensible schema with a predefined set of object types and associated attributes. You can create new
object types and attributes for metaverse objects. Attributes can be single-valued or multivalued, and the attribute
types can be strings, references, numbers, and Boolean values.
Relationships between staging objects and metaverse objects
Within the sync engine namespace, the data flow is enabled by the link relationship between staging objects and
metaverse objects. A staging object that is linked to a metaverse object is called a joined object (or connector
object). A staging object that is not linked to a metaverse object is called a disjoined object (or disconnector
object). The terms joined and disjoined are preferred to not confuse with the Connectors responsible for importing
and exporting data from a connected directory.
Placeholders are never linked to a metaverse object
A joined object comprises a staging object and its linked relationship to a single metaverse object. Joined objects
are used to synchronize attribute values between a connector space object and a metaverse object.
When a staging object becomes a joined object during synchronization, attributes can flow between the staging
object and the metaverse object. Attribute flow is bidirectional and is configured by using import attribute rules
and export attribute rules.
A single connector space object can be linked to only one metaverse object. However, each metaverse object can be
linked to multiple connector space objects in the same or in different connector spaces, as shown in the following
illustration.
The linked relationship between the staging object and a metaverse object is persistent and can be removed only
by rules that you specify.
A disjoined object is a staging object that is not linked to any metaverse object. The attribute values of a disjoined
object are not processed any further within the metaverse. The attribute values of the corresponding object in the
connected data source are not updated by sync engine.
By using disjoined objects, you can store identity information in sync engine and process it later. Keeping a staging
object as a disjoined object in the connector space has many advantages. Because the system has already staged
the required information about this object, it is not necessary to create a representation of this object again during
the next import from the connected data source. This way, sync engine always has a complete snapshot of the
connected data source, even if there is no current connection to the connected data source. Disjoined objects can
be converted into joined objects, and vice versa, depending on the rules that you specify.
An import object is created as a disjoined object. An export object must be a joined object. The system logic
enforces this rule and deletes every export object that is not a joined object.
Sync engine identity management process

The identity management process controls how identity information is updated between different connected data
sources. Identity management occurs in three processes:
Import
Synchronization
Export
During the import process, sync engine evaluates the incoming identity information from a connected data source.
When changes are detected, it either creates new staging objects or updates existing staging objects in the
connector space for synchronization.
During the synchronization process, sync engine updates the metaverse to reflect changes that have occurred in
the connector space and updates the connector space to reflect changes that have occurred in the metaverse.
During the export process, sync engine pushes out changes that are staged on staging objects and that are flagged
as pending export.
The following illustration shows where each of the processes occurs as identity information flows from one
connected data source to another.
Import process
During the import process, sync engine evaluates updates to identity information. Sync engine compares the
identity information received from the connected data source with the identity information about a staging object
and determines whether the staging object requires updates. If it is necessary to update the staging object with
new data, the staging object is flagged as pending import.
By staging objects in the connector space before synchronization, sync engine can process only the identity
information that has changed. This process provides the following benefits:
Efficient synchronization. The amount of data processed during synchronization is minimized.
Efficient resynchronization. You can change how sync engine processes identity information without
reconnecting the sync engine to the data source.
Opportunity to preview synchronization. You can preview synchronization to verify that your assumptions
about the identity management process are correct.
For each object specified in the Connector, the sync engine first tries to locate a representation of the object in the
connector space of the Connector. Sync engine examines all staging objects in the connector space and tries to find
a corresponding staging object that has a matching anchor attribute. If no existing staging object has a matching
anchor attribute, sync engine tries to find a corresponding staging object with the same distinguished name.
When sync engine finds a staging object that matches by distinguished name but not by anchor, the following
special behavior occurs:
If the object located in the connector space has no anchor, then sync engine removes this object from the
connector space and marks the metaverse object it is linked to as retry provisioning on next
synchronization run. Then it creates the new import object.
If the object located in the connector space has an anchor, then sync engine assumes that this object has either
been renamed or deleted in the connected directory. It assigns a temporary, new distinguished name for the
connector space object so that it can stage the incoming object. The old object then becomes transient, waiting
for the Connector to import the rename or deletion to resolve the situation.
If sync engine locates a staging object that corresponds to the object specified in the Connector, it determines what
kind of changes to apply. For example, sync engine might rename or delete the object in the connected data source,
or it might only update the objects attribute values.
Staging objects with updated data are marked as pending import. Different types of pending imports are available.
Depending on the result of the import process, a staging object in the connector space has one of the following
pending import types:
None. No changes to any of the attributes of the staging object are available. Sync engine does not flag this
type as pending import.
Add. The staging object is a new import object in the connector space. Sync engine flags this type as pending
import for additional processing in the metaverse.
Update. Sync engine finds a corresponding staging object in the connector space and flags this type as pending
import so that updates to the attributes can be processed in the metaverse. Updates include object renaming.
Delete. Sync engine finds a corresponding staging object in the connector space and flags this type as pending
import so that the joined object can be deleted.
Delete/Add. Sync engine finds a corresponding staging object in the connector space, but the object types do
not match. In this case, a delete-add modification is staged. A delete-add modification indicates to the sync
engine that a complete resynchronization of this object must occur because different sets of rules apply to this
object when the object type changes.
By setting the pending import status of a staging object, it is possible to reduce significantly the amount of data
processed during synchronization because doing so allows the system to process only those objects that have
updated data.
Synchronization process
Synchronization consists of two related processes:
Inbound synchronization, when the content of the metaverse is updated by using the data in the connector
space.
Outbound synchronization, when the content of the connector space is updated by using data in the metaverse.
By using the information staged in the connector space, the inbound synchronization process creates in the
metaverse the integrated view of the data that is stored in the connected data sources. Either all staging objects or
only those with a pending import information are aggregated, depending on how the rules are configured.
The outbound synchronization process updates export objects when metaverse objects change.
Inbound synchronization creates the integrated view in the metaverse of the identity information that is received
from the connected data sources. Sync engine can process identity information at any time by using the latest
identity information that it has from the connected data source.
Inbound synchronization
Inbound synchronization includes the following processes:
Provision (also called Projection if it is important to distinguish this process from outbound synchronization
provisioning). The Sync engine creates a new metaverse object based on a staging object and links them.
Provision is an object-level operation.
Join. The Sync engine links a staging object to an existing metaverse object. A join is an object-level operation.
Import attribute flow. Sync engine updates the attribute values, called attribute flow, of the object in the
metaverse. Import attribute flow is an attribute-level operation that requires a link between a staging object and
a metaverse object.
Provision is the only process that creates objects in the metaverse. Provision affects only import objects that are
disjoined objects. During provision, sync engine creates a metaverse object that corresponds to the object type of
the import object and establishes a link between both objects, thus creating a joined object.
The join process also establishes a link between import objects and a metaverse object. The difference between join
and provision is that the join process requires that the import object are linked to an existing metaverse object,
where the provision process creates a new metaverse object.
Sync engine tries to join an import object to a metaverse object by using criteria that is specified in the
Synchronization Rule configuration.
During the provision and join processes, sync engine links a disjoined object to a metaverse object, making them
joined. After these object-level operations are completed, sync engine can update the attribute values of the
associated metaverse object. This process is called import attribute flow.
Import attribute flow occurs on all import objects that carry new data and are linked to a metaverse object.
Outbound synchronization
Outbound synchronization updates export objects when a metaverse object change but is not deleted. The
objective of outbound synchronization is to evaluate whether changes to metaverse objects require updates to
staging objects in the connector spaces. In some cases, the changes can require that staging objects in all connector
spaces be updated. Staging objects that are changed are flagged as pending export, making them export objects.
These export objects are later pushed out to the connected data source during the export process.
Outbound synchronization has three processes:
Provisioning
Deprovisioning
Export attribute flow
Provisioning and deprovisioning are both object-level operations. Deprovisioning depends on provisioning
because only provisioning can initiate it. Deprovisioning is triggered when provisioning removes the link between
a metaverse object and an export object.
Provisioning is always triggered when changes are applied to objects in the metaverse. When changes are made to
metaverse objects, sync engine can perform any of the following tasks as part of the provisioning process:
Create joined objects, where a metaverse object is linked to a newly created export object.
Rename a joined object.
Disjoin links between a metaverse object and staging objects, creating a disjoined object.
If provisioning requires sync engine to create a new connector object, the staging object to which the metaverse
object is linked is always an export object, because the object does not yet exist in the connected data source.
If provisioning requires sync engine to disjoin a joined object, creating a disjoined object, deprovisioning is
triggered. The deprovisioning process deletes the object.
During deprovisioning, deleting an export object does not physically delete the object. The object is flagged as
deleted, which means that the delete operation is staged on the object.
Export attribute flow also occurs during the outbound synchronization process, similar to the way that import
attribute flow occurs during inbound synchronization. Export attribute flow occurs only between metaverse and
export objects that are joined.
Export process
During the export process, sync engine examines all export objects that are flagged as pending export in the
connector space, and then sends updates to the connected data source.
The sync engine can determine the success of an export but it cannot sufficiently determine that the identity
management process is complete. Objects in the connected data source can always be changed by other processes.
Because sync engine does not have a persistent connection to the connected data source, it is not sufficient to make
assumptions about the properties of an object in the connected data source based only on a successful export
notification.
For example, a process in the connected data source could change the objects attributes back to their original
values (that is, the connected data source could overwrite the values immediately after the data is pushed out by
sync engine and successfully applied in the connected data source).
The sync engine stores export and import status information about each staging object. If values of the attributes
that are specified in the attribute inclusion list have changed since the last export, the storage of import and export
status enables sync engine to react appropriately. Sync engine uses the import process to confirm attribute values
that have been exported to the connected data source. A comparison between the imported and exported
information, as shown in the following illustration, enables sync engine to determine whether the export was
successful or if it needs to be repeated.
For example, if sync engine exports attribute C, which has a value of 5, to a connected data source, it stores C=5 in
its export status memory. Each additional export on this object results in an attempt to export C=5 to the connected
data source again because sync engine assumes that this value has not been persistently applied to the object (that
is, unless a different value was imported recently from the connected data source). The export memory is cleared
when C=5 is received during an import operation on the object.
Next steps
Learn more about the Azure AD Connect sync configuration.
Learn more about Integrating your on-premises identities with Azure Active Directory.
Azure AD Connect sync: Understanding Declarative
Provisioning
This topic explains the configuration model in Azure AD Connect. The model is called Declarative Provisioning and
it allows you to make a configuration change with ease. Many things described in this topic are advanced and not
required for most customer scenarios.
Overview
Declarative provisioning is processing objects coming in from a source connected directory and determines how
the object and attributes should be transformed from a source to a target. An object is processed in a sync pipeline
and the pipeline is the same for inbound and outbound rules. An inbound rule is from a connector space to the
metaverse and an outbound rule is from the metaverse to a connector space.
The pipeline has several different modules. Each one is responsible for one concept in object synchronization.
Source, The source object

Scope, Finds all sync rules that are in scope
Join, Determines relationship between connector space and metaverse
Transform, Calculates how attributes should be transformed and flow
Precedence, Resolves conflicting attribute contributions
Target, The target object
Scope
The scope module is evaluating an object and determines the rules that are in scope and should be included in the
processing. Depending on the attributes values on the object, different sync rules are evaluated to be in scope. For
example, a disabled user with no Exchange mailbox does have different rules than an enabled user with a mailbox.
The scope is defined as groups and clauses. The clauses are inside a group. A logical AND is used between all
clauses in a group. For example, (department =IT AND country = Denmark). A logical OR is used between groups.
The scope in this picture should be read as (department = IT AND country = Denmark) OR (country=Sweden). If
either group 1 or group 2 is evaluated to true, then the rule is in scope.
The scope module supports the following operations.
OPERATION DESCRIPTION
EQUAL, NOTEQUAL A string compare that evaluates if value is equal to the value
in the attribute. For multi-valued attributes, see ISIN and
ISNOTIN.
LESSTHAN, LESSTHAN_OR_EQUAL A string compare that evaluates if value is less than of the
value in the attribute.
CONTAINS, NOTCONTAINS A string compare that evaluates if value can be found

somewhere inside value in the attribute.
STARTSWITH, NOTSTARTSWITH A string compare that evaluates if value is in the beginning of

the value in the attribute.
ENDSWITH, NOTENDSWITH A string compare that evaluates if value is in the end of the
GREATERTHAN, GREATERTHAN_OR_EQUAL A string compare that evaluates if value is greater than of the
ISNULL, ISNOTNULL Evaluates if the attribute is absent from the object. If the
attribute is not present and therefore null, then the rule is in
scope.
ISIN, ISNOTIN Evaluates if the value is present in the defined attribute. This
operation is the multi-valued variation of EQUAL and
NOTEQUAL. The attribute is supposed to be a multi-valued
attribute and if the value can be found in any of the attribute
values, then the rule is in scope.
ISBITSET, ISNOTBITSET Evaluates if a particular bit is set. For example, can be used to
evaluate the bits in userAccountControl to see if a user is
enabled or disabled.
ISMEMBEROF, ISNOTMEMBEROF The value should contain a DN to a group in the connector

space. If the object is a member of the group specified, the
rule is in scope.
Join
The join module in the sync pipeline is responsible for finding the relationship between the object in the source
and an object in the target. On an inbound rule, this relationship would be an object in a connector space finding a
relationship to an object in the metaverse.
The goal is to see if there is an object already in the metaverse, created by another Connector, it should be
associated with. For example, in an account-resource forest the user from the account forest should be joined with
the user from the resource forest.
Joins are used mostly on inbound rules to join connector space objects together to the same metaverse object.
The joins are defined as one or more groups. Inside a group, you have clauses. A logical AND is used between all
clauses in a group. A logical OR is used between groups. The groups are processed in order from top to bottom.
When one group has found exactly one match with an object in the target, then no other join rules are evaluated. If
zero or more than one object is found, processing continues to the next group of rules. For this reason, the rules
should be created in the order of most explicit first and more fuzzy at the end.
The joins in this picture are processed from top to bottom. First the sync pipeline sees if there is a match on
employeeID. If not, the second rule sees if the account name can be used to join the objects together. If that is not a
match either, the third and final rule is a more fuzzy match by using the name of user.
If all join rules have been evaluated and there is not exactly one match, the Link Type on the Description page is
used. If this option is set to Provision, then a new object in the target is created.
An object should only have one single sync rule with join rules in scope. If there are multiple sync rules where join
is defined, an error occurs. Precedence is not used to resolve join conflicts. An object must have a join rule in scope
for attributes to flow with the same inbound/outbound direction. If you need to flow attributes both inbound and
outbound to the same object, you must have both an inbound and an outbound sync rule with join.
Outbound join has a special behavior when it tries to provision an object to a target connector space. The DN
attribute is used to first try a reverse-join. If there is already an object in the target connector space with the same
DN, the objects are joined.
The join module is only evaluated once when a new sync rule comes into scope. When an object has joined, it is
not disjoining even if the join criteria is no longer satisfied. If you want to disjoin an object, the sync rule that
joined the objects must go out of scope.
Metaverse delete
A metaverse object remains as long as there is one inbound sync rule in scope with Link Type set to Provision or
StickyJoin. A StickyJoin is used when a Connector is not allowed to provision a new object to the metaverse, but
when it has joined, it must be deleted in the source before the metaverse object is deleted.
When a metaverse object is deleted, all objects associated with an outbound sync rule marked for provision are
marked for a delete.
Transformations
The transformations are used to define how attributes should flow from the source to the target. The flows can
have one of the following flow types: Direct, Constant, or Expression. A direct flow, flows an attribute value as-is
with no additional transformations. A constant value sets the specified value. An expression uses the declarative
provisioning expression language to express how the transformation should be. The details for the expression
language can be found in the understanding declarative provisioning expression language topic.
The Apply once checkbox defines that the attribute should only be set when the object is initially created. For
example, this configuration can be used to set an initial password for a new user object.
Merging attribute values
In the attribute flows there is a setting to determine if multi-valued attributes should be merged from several
different Connectors. The default value is Update, which indicates that the sync rule with highest precedence
should win.
There is also Merge and MergeCaseInsensitive. These options allow you to merge values from different sources.
For example, it can be used to merge the member or proxyAddresses attribute from several different forests.
When you use this option, all sync rules in scope for an object must use the same merge type. You cannot define
Update from one Connector and Merge from another. If you try, you receive an error.
The difference between Merge and MergeCaseInsensitive is how to process duplicate attribute values. The sync
engine makes sure duplicate values are not inserted into the target attribute. With MergeCaseInsensitive,
duplicate values with only a difference in case are not going to be present. For example, you should not see both
"SMTP:bob@contoso.com" and "smtp:bob@contoso.com" in the target attribute. Merge is only looking at the
exact values and multiple values where there only is a difference in case might be present.
The option Replace is the same as Update, but it is not used.
Control the attribute flow process
When multiple inbound sync rules are configured to contribute to the same metaverse attribute, then precedence
is used to determine the winner. The sync rule with highest precedence (lowest numeric value) is going to
contribute the value. The same happens for outbound rules. The sync rule with highest precedence wins and
contribute the value to the connected directory.
In some cases, rather than contribute a value, the sync rule should determine how other rules should behave.
There are some special literals used for this case.
For inbound Synchronization Rules, the literal NULL can be used to indicate that the flow has no value to
contribute. Another rule with lower precedence can contribute a value. If no rule contributed a value, then the
metaverse attribute is removed. For an outbound rule, if NULL is the final value after all sync rules have been
processed, then the value is removed in the connected directory.
The literal AuthoritativeNull is similar to NULL but with the difference that no lower precedence rules can
contribute a value.
An attribute flow can also use IgnoreThisFlow. It is similar to NULL in the sense that it indicates there is nothing
to contribute. The difference is that it does not remove an already existing value in the target. It is like the attribute
flow has never been there.
Here is an example:
In Out to AD - User Exchange hybrid the following flow can be found:
IIF([cloudSOAExchMailbox] = True,[cloudMSExchSafeSendersHash],IgnoreThisFlow)
This expression should be read as: if the user mailbox is located in Azure AD, then flow the attribute from Azure AD
to AD. If not, do not flow anything back to Active Directory. In this case, it would keep the existing value in AD.
ImportedValue
The function ImportedValue is different than all other functions since the attribute name must be enclosed in
quotes rather than square brackets:
ImportedValue("proxyAddresses") .
Usually during synchronization an attribute uses the expected value, even if it hasnt been exported yet or an error
was received during export (top of the tower). An inbound synchronization assumes that an attribute that hasnt
yet reached a connected directory eventually reaches it. In some cases, it is important to only synchronize a value
that has been confirmed by the connected directory (hologram and delta import tower).
An example of this function can be found in the out-of-box Synchronization Rule In from AD User Common from
Exchange. In Hybrid Exchange, the value added by Exchange online should only be synchronized when it has been
confirmed that the value was exported successfully:
proxyAddresses <- RemoveDuplicates(Trim(ImportedValue("proxyAddresses")))
Precedence
When several sync rules try to contribute the same attribute value to the target, the precedence value is used to
determine the winner. The rule with highest precedence, lowest numeric value, is going to contribute the attribute
in a conflict.
This ordering can be used to define more precise attribute flows for a small subset of objects. For example, the
out-of-box-rules make sure that attributes from an enabled account (User AccountEnabled) have precedence
from other accounts.
Precedence can be defined between Connectors. That allows Connectors with better data to contribute values first.
Multiple objects from the same connector space
If you have several objects in the same connector space joined to the same metaverse object, precedence must be
adjusted. If several objects are in scope of the same sync rule, then the sync engine is not able to determine
precedence. It is ambiguous which source object should contribute the value to the metaverse. This configuration
is reported as ambiguous even if the attributes in the source have the same value.
For this scenario, you need to change the scope of the sync rules so the source objects have different sync rules in
scope. That allows you to define different precedence.
Next steps
Read more about the expression language in Understanding Declarative Provisioning Expressions.
See how declarative provisioning is used out-of-box in Understanding the default configuration.
See how to make a practical change using declarative provisioning in How to make a change to the default
configuration.
Continue to read how users and contacts work together in Understanding Users and Contacts.
Overview topics
Azure AD Connect sync: Understand and customize synchronization
Reference topics
Azure AD Connect sync: Functions Reference
Azure AD Connect sync: Understanding Declarative
Provisioning Expressions
Azure AD Connect sync builds on declarative provisioning first introduced in Forefront Identity Manager 2010. It
allows you to implement your complete identity integration business logic without the need to write compiled
code.
An essential part of declarative provisioning is the expression language used in attribute flows. The language used
is a subset of Microsoft Visual Basic for Applications (VBA). This language is used in Microsoft Office and users
with experience of VBScript will also recognize it. The Declarative Provisioning Expression Language is only using
functions and is not a structured language. There are no methods or statements. Functions are instead nested to
express program flow.
For more details, see Welcome to the Visual Basic for Applications language reference for Office 2013.
The attributes are strongly typed. A function only accepts attributes of the correct type. It is also case-sensitive.
Both function names and attribute names must have proper casing or an error is thrown.
Language definitions and Identifiers

Functions have a name followed by arguments in brackets: FunctionName(argument 1, argument N).
Attributes are identified by square brackets: [attributeName]
Parameters are identified by percent signs: %ParameterName%
String constants are surrounded by quotes: For example, "Contoso" (Note: must use straight quotes "" and not
smart quotes )
Numeric values are expressed without quotes and expected to be decimal. Hexadecimal values are prefixed
with &H. For example, 98052, &HFF
Boolean values are expressed with constants: True, False.
Built-in constants and literals are expressed with only their name: NULL, CRLF, IgnoreThisFlow
Functions
Declarative provisioning uses many functions to enable the possibility to transform attribute values. These
functions can be nested so the result from one function is passed in to another function.
Function1(Function2(Function3()))
The complete list of functions can be found in the function reference.

Parameters
A parameter is defined either by a Connector or by an administrator using PowerShell. Parameters usually contain
values that are different from system to system, for example the name of the domain the user is located in. These
parameters can be used in attribute flows.
The Active Directory Connector provided the following parameters for inbound Synchronization Rules:
PARAMETER NAME COMMENT
Domain.Netbios Netbios format of the domain currently being imported, for

example FABRIKAMSALES
PARAMETER NAME COMMENT
Domain.FQDN FQDN format of the domain currently being imported, for

example sales.fabrikam.com
Domain.LDAP LDAP format of the domain currently being imported, for

example DC=sales,DC=fabrikam,DC=com
Forest.Netbios Netbios format of the forest name currently being imported,

for example FABRIKAMCORP
Forest.FQDN FQDN format of the forest name currently being imported,

for example fabrikam.com
Forest.LDAP LDAP format of the forest name currently being imported, for
example DC=fabrikam,DC=com
The system provides the following parameter, which is used to get the identifier of the Connector currently
running:
Connector.ID
Here is an example that populates the metaverse attribute domain with the netbios name of the domain where
the user is located:
domain <- %Domain.Netbios%
Operators
The following operators can be used:
Comparison: <, <=, <>, =, >, >=
Mathematics: +, -, *, -
String: & (concatenate)
Logical: && (and), || (or)
Evaluation order: ( )
Operators are evaluated left to right and have the same evaluation priority. That is, the * (multiplier) is not
evaluated before - (subtraction). 2*(5+3) is not the same as 2*5+3. The brackets ( ) are used to change the
evaluation order when left to right evaluation order isn't appropriate.
Multi-valued attributes
The functions can operate on both single-valued and multi-valued attributes. For multi-valued attributes, the
function operates over every value and applies the same function to every value.
For example:
Trim([proxyAddresses]) Do a Trim of every value in the proxyAddress attribute.
Word([proxyAddresses],1,"@") & "@contoso.com" For every value with an @-sign, replace the domain with
@contoso.com.
IIF(InStr([proxyAddresses],"SIP:")=1,NULL,[proxyAddresses]) Look for the SIP-address and remove it from the
values.
Next steps
Read more about the configuration model in Understanding Declarative Provisioning.
See how declarative provisioning is used out-of-box in Understanding the default configuration.
configuration.
Overview topics
Reference topics
Azure AD Connect sync: Understanding the default
configuration
This article explains the out-of-box configuration rules. It documents the rules and how these rules impact the
configuration. It also walks you through the default configuration of Azure AD Connect sync. The goal is that the
reader understands how the configuration model, named declarative provisioning, is working in a real-world
example. This article assumes that you have already installed and configure Azure AD Connect sync using the
installation wizard.
To understand the details of the configuration model, read Understanding Declarative Provisioning.
Out-of-box rules from on-premises to Azure AD

The following expressions can be found in the out-of-box configuration.
User out-of-box rules
These rules also apply to the iNetOrgPerson object type.
A user object must satisfy the following to be synchronized:
Must have a sourceAnchor.
After the object has been created in Azure AD, then sourceAnchor cannot change. If the value is changed on-
premises, the object stops synchronizing until the sourceAnchor is changed back to its previous value.
Must have the accountEnabled (userAccountControl) attribute populated. With an on-premises Active
Directory, this attribute is always present and populated.
The following user objects are not synchronized to Azure AD:
IsPresent([isCriticalSystemObject]) . Ensure many out-of-box objects in Active Directory, such as the built-in
administrator account, are not synchronized.
IsPresent([sAMAccountName]) = False . Ensure user objects with no sAMAccountName attribute are not
synchronized. This case would only practically happen in a domain upgraded from NT4.
Left([sAMAccountName], 4) = "AAD_" , Left([sAMAccountName], 5) = "MSOL_" . Do not synchronize the service
account used by Azure AD Connect sync and its earlier versions.
Do not synchronize Exchange accounts that would not work in Exchange Online.
[sAMAccountName] = "SUPPORT_388945a0"
Left([mailNickname], 14) = "SystemMailbox{"
(Left([mailNickname], 4) = "CAS_" && (InStr([mailNickname], "}") > 0))
(Left([sAMAccountName], 4) = "CAS_" && (InStr([sAMAccountName], "}")> 0))
Do not synchronize objects that would not work in Exchange Online.
CBool(IIF(IsPresent([msExchRecipientTypeDetails]),BitAnd([msExchRecipientTypeDetails],&H21C07000) >
0,NULL))
This bitmask (&H21C07000) would filter out the following objects:
Mail-enabled Public Folder
System Attendant Mailbox
Mailbox Database Mailbox (System Mailbox)
Universal Security Group (wouldn't apply for a user, but is present for legacy reasons)
Non-Universal Group (wouldn't apply for a user, but is present for legacy reasons)
Mailbox Plan
Discovery Mailbox
CBool(InStr(DNComponent(CRef([dn]),1),"\\0ACNF:")>0) . Do not synchronize any replication victim objects.
The following attribute rules apply:
sourceAnchor <- IIF([msExchRecipientTypeDetails]=2,NULL,..) . The sourceAnchor attribute is not contributed
from a linked mailbox. It is assumed that if a linked mailbox has been found, the actual account is joined later.
Exchange related attributes are only synchronized if the attribute mailNickName has a value.
When there are multiple forests, then attributes are consumed in the following order:
1. Attributes related to sign-in (for example userPrincipalName) are contributed from the forest with an
enabled account.
2. Attributes that can be found in an Exchange GAL (Global Address List) are contributed from the forest
with an Exchange Mailbox.
3. If no mailbox can be found, then these attributes can come from any forest.
4. Exchange related attributes (technical attributes not visible in the GAL) are contributed from the forest
where mailNickname ISNOTNULL .
5. If there are multiple forests that would satisfy one of these rules, then the creation order (date/time) of
the Connectors (forests) is used to determine which forest contributes the attributes.
Contact out-of-box rules
A contact object must satisfy the following to be synchronized:
The contact must be mail-enabled. It is verified with the following rules:
IsPresent([proxyAddresses]) = True) . The proxyAddresses attribute must be populated.
A primary email address can be found in either the proxyAddresses attribute or the mail attribute. The
presence of an @ is used to verify that the content is an email address. One of these two rules must be
evaluated to True.
(Contains([proxyAddresses], "SMTP:") > 0) && (InStr(Item([proxyAddresses],
Contains([proxyAddresses], "SMTP:")), "@") > 0))
. Is there an entry with "SMTP:" and if there is, can an @ be found in the string?
(IsPresent([mail]) = True && (InStr([mail], "@") > 0) . Is the mail attribute populated and if it
is, can an @ be found in the string?
The following contact objects are not synchronized to Azure AD:
IsPresent([isCriticalSystemObject]) . Ensure no contact objects marked as critical are synchronized. Shouldn't
be any with a default configuration.
((InStr([displayName], "(MSOL)") > 0) && (CBool([msExchHideFromAddressLists]))) .
(Left([mailNickname], 4) = "CAS_" && (InStr([mailNickname], "}") > 0)) . These objects wouldn't work in
Exchange Online.
Group out-of-box rules
A group object must satisfy the following to be synchronized:
Must have less than 50,000 members. This count is the number of members in the on-premises group.
If it has more members before synchronization starts the first time, the group is not synchronized.
If the number of members grow from when it was initially created, then when it reaches 50,000
members it stops synchronizing until the membership count is lower than 50,000 again.
Note: The 50,000 membership count is also enforced by Azure AD. You are not able to synchronize
groups with more members even if you modify or remove this rule.
If the group is a Distribution Group, then it must also be mail enabled. See Contact out-of-box rules for this
rule is enforced.
The following group objects are not synchronized to Azure AD:
IsPresent([isCriticalSystemObject]) . Ensure many out-of-box objects in Active Directory, such as the built-in
administrators group, are not synchronized.
[sAMAccountName] = "MSOL_AD_Sync_RichCoexistence" . Legacy group used by DirSync.
BitAnd([msExchRecipientTypeDetails],&H40000000) . Role Group.
ForeignSecurityPrincipal out-of-box rules

FSPs are joined to "any" (*) object in the metaverse. In reality, this join only happens for users and security groups.
This configuration ensures that cross-forest memberships are resolved and represented correctly in Azure AD.
Computer out-of-box rules
A computer object must satisfy the following to be synchronized:
userCertificate ISNOTNULL . Only Windows 10 computers populate this attribute. All computer objects with a
value in this attribute are synchronized.
Understanding the out-of-box rules scenario

In this example, we are using a deployment with one account forest (A), one resource forest (R), and one Azure AD
directory.
In this configuration, it is assumed there is an enabled account in the account forest and a disabled account in the
resource forest with a linked mailbox.
Our goal with the default configuration is:
Attributes related to sign-in are synchronized from the forest with the enabled account.
Attributes that can be found in the GAL (Global Address List) are synchronized from the forest with the
mailbox. If no mailbox can be found, any other forest is used.
If a linked mailbox is found, the linked enabled account must be found for the object to be exported to Azure
AD.
Synchronization Rule Editor
The configuration can be viewed and changed with the tool Synchronization Rules Editor (SRE) and a shortcut to it
can be found in the start menu.
The SRE is a resource kit tool and it is installed with Azure AD Connect sync. To be able to start it, you must be a
member of the ADSyncAdmins group. When it starts, you see something like this:
In this pane, you see all Synchronization Rules created for your configuration. Each line in the table is one
Synchronization Rule. To the left under Rule Types, the two different types are listed: Inbound and Outbound.
Inbound and Outbound is from the view of the metaverse. You are mainly going to focus on the inbound rules in
this overview. The actual list of Synchronization Rules depends on the detected schema in AD. In the picture
above, the account forest (fabrikamonline.com) does not have any services, such as Exchange and Lync, and no
Synchronization Rules have been created for these services. However, in the resource forest
(res.fabrikamonline.com) you find Synchronization Rules for these services. The content of the rules is different
depending on the version detected. For example, in a deployment with Exchange 2013 there are more attribute
flows configured than in Exchange 2010/2007.
Synchronization Rule
A Synchronization Rule is a configuration object with a set of attributes flowing when a condition is satisfied. It is
also used to describe how an object in a connector space is related to an object in the metaverse, known as join
or match. The Synchronization Rules have a precedence value indicating how they relate to each other. A
Synchronization Rule with a lower numeric value has a higher precedence and in an attribute flow conflict, higher
precedence wins the conflict resolution.
As an example, look at the Synchronization Rule In from AD User AccountEnabled. Mark this line in the SRE
and select Edit.
Since this rule is an out-of-box rule, you receive a warning when you open the rule. You should not make any
changes to out-of-box rules, so you are asked what your intentions are. In this case, you only want to view the
rule. Select No.
A Synchronization Rule has four configuration sections: Description, Scoping filter, Join rules, and
Transformations.
Description
The first section provides basic information such as a name and description.
You also find information about which connected system this rule is related to, which object type in the connected
system it applies to, and the metaverse object type. The metaverse object type is always person regardless when
the source object type is a user, iNetOrgPerson, or contact. The metaverse object type should never change so it is
created as a generic type. The Link Type can be set to Join, StickyJoin, or Provision. This setting works together
with the Join Rules section and is covered later.
You can also see that this sync rule is used for password sync. If a user is in scope for this sync rule, the password
is synchronized from on-premises to cloud (assuming you have enabled the password sync feature).
Scoping filter
The Scoping Filter section is used to configure when a Synchronization Rule should apply. Since the name of the
Synchronization Rule you are looking at indicates it should only be applied for enabled users, the scope is
configured so the AD attribute userAccountControl must not have the bit 2 set. When the sync engine finds a
user in AD, it applies this sync rule when userAccountControl is set to the decimal value 512 (enabled normal
user). It does not apply the rule when the user has userAccountControl set to 514 (disabled normal user).
The scoping filter has Groups and Clauses that can be nested. All clauses inside a group must be satisfied for a
Synchronization Rule to apply. When multiple groups are defined, then at least one group must be satisfied for
the rule to apply. That is, a logical OR is evaluated between groups and a logical AND is evaluated inside a group.
An example of this configuration can be found in the outbound Synchronization Rule Out to AAD Group Join.
There are several synchronization filter groups, for example one for security groups ( securityEnabled EQUAL True )
and one for distribution groups ( securityEnabled EQUAL False ).
This rule is used to define which Groups should be provisioned to Azure AD. Distribution Groups must be mail
enabled to be synchronized with Azure AD, but for security groups an email is not required.
Join rules
The third section is used to configure how objects in the connector space relate to objects in the metaverse. The
rule you have looked at earlier does not have any configuration for Join Rules, so instead you are going to look at
In from AD User Join.
The content of the join rule depends on the matching option selected in the installation wizard. For an inbound
rule, the evaluation starts with an object in the source connector space and each group in the join rules is
evaluated in sequence. If a source object is evaluated to match exactly one object in the metaverse using one of
the join rules, the objects are joined. If all rules have been evaluated and there is no match, then the Link Type on
the description page is used. If this configuration is set to Provision, then a new object is created in the target, the
metaverse. To provision a new object to the metaverse is also known as to project an object to the metaverse.
The join rules are only evaluated once. When a connector space object and a metaverse object are joined, they
remain joined as long as the scope of the Synchronization Rule is still satisfied.
When evaluating Synchronization Rules, only one Synchronization Rule with join rules defined must be in scope.
If multiple Synchronization Rules with join rules are found for one object, an error is thrown. For this reason, the
best practice is to have only one Synchronization Rule with join defined when multiple Synchronization Rules are
in scope for an object. In the out-of-box configuration for Azure AD Connect sync, these rules can be found by
looking at the name and find those with the word Join at the end of the name. A Synchronization Rule without
any join rules defined applies the attribute flows when another Synchronization Rule joined the objects together
or provisioned a new object in the target.
If you look at the picture above, you can see that the rule is trying to join objectSID with
msExchMasterAccountSid (Exchange) and msRTCSIP-OriginatorSid (Lync), which is what we expect in an
account-resource forest topology. You find the same rule on all forests. The assumption is that every forest could
be either an account or resource forest. This configuration also works if you have accounts that live in a single
forest and do not have to be joined.
Transformations
The transformation section defines all attribute flows that apply to the target object when the objects are joined
and the scope filter is satisfied. Going back to the In from AD User AccountEnabled Synchronization Rule,
you find the following transformations:
To put this configuration in context, in an Account-Resource forest deployment, it is expected to find an enabled
account in the account forest and a disabled account in the resource forest with Exchange and Lync settings. The
Synchronization Rule you are looking at contains the attributes required for sign-in and these attributes should
flow from the forest where there is an enabled account. All these attribute flows are put together in one
Synchronization Rule.
A transformation can have different types: Constant, Direct, and Expression.
A constant flow always flows a hardcoded value. In the case above, it always sets the value True in the
metaverse attribute named accountEnabled.
A direct flow always flows the value of the attribute in the source to the target attribute as-is.
The third flow type is Expression and it allows for more advanced configurations.
The expression language is VBA (Visual Basic for Applications), so people with experience of Microsoft Office or
VBScript will recognize the format. Attributes are enclosed in square brackets, [attributeName]. Attribute names
and function names are case-sensitive, but the Synchronization Rules Editor evaluates the expressions and
provide a warning if the expression is not valid. All expressions are expressed on a single line with nested
functions. To show the power of the configuration language, here is the flow for pwdLastSet, but with additional
comments inserted:
// If-then-else
IIF(
// (The evaluation for IIF) Is the attribute pwdLastSet present in AD?
IsPresent([pwdLastSet]),
// (The True part of IIF) If it is, then from right to left, convert the AD time format to a .Net datetime,
change it to the time format used by Azure AD, and finally convert it to a string.
CStr(FormatDateTime(DateFromNum([pwdLastSet]),"yyyyMMddHHmmss.0Z")),
// (The False part of IIF) Nothing to contribute
NULL
)
See Understanding Declarative Provisioning Expressions for more information on the expression language for
attribute flows.
Precedence
You have now looked at some individual Synchronization Rules, but the rules work together in the configuration.
In some cases, an attribute value is contributed from multiple synchronization rules to the same target attribute.
In this case, attribute precedence is used to determine which attribute wins. As an example, look at the attribute
sourceAnchor. This attribute is an important attribute to be able to sign in to Azure AD. You can find an attribute
flow for this attribute in two different Synchronization Rules, In from AD User AccountEnabled and In from
AD User Common. Due to Synchronization Rule precedence, the sourceAnchor attribute is contributed from
the forest with an enabled account first when there are several objects joined to the metaverse object. If there are
no enabled accounts, then the sync engine uses the catch-all Synchronization Rule In from AD User Common.
This configuration ensures that even for accounts that are disabled, there is still a sourceAnchor.
The precedence for Synchronization Rules is set in groups by the installation wizard. All rules in a group have the
same name, but they are connected to different connected directories. The installation wizard gives the rule In
from AD User Join highest precedence and it iterates over all connected AD directories. It then continues with
the next groups of rules in a predefined order. Inside a group, the rules are added in the order the Connectors
were added in the wizard. If another Connector is added through the wizard, the Synchronization Rules are
reordered and the new Connectors rules are inserted last in each group.
Putting it all together
We now know enough about Synchronization Rules to be able to understand how the configuration works with
the different Synchronization Rules. If you look at a user and the attributes that are contributed to the metaverse,
the rules are applied in the following order:
NAME COMMENT
In from AD User Join Rule for joining connector space objects with metaverse.
In from AD UserAccount Enabled Attributes required for sign-in to Azure AD and Office 365.
We want these attributes from the enabled account.
NAME COMMENT
In from AD User Common from Exchange Attributes found in the Global Address List. We assume the
data quality is best in the forest where we have found the
users mailbox.
In from AD User Common Attributes found in the Global Address List. In case we didnt
find a mailbox, any other joined object can contribute the
attribute value.
In from AD User Exchange Only exists if Exchange has been detected. It flows all
infrastructure Exchange attributes.
In from AD User Lync Only exists if Lync has been detected. It flows all
infrastructure Lync attributes.
Next steps
Read more about the configuration model in Understanding Declarative Provisioning.
Read more about the expression language in Understanding Declarative Provisioning Expressions.
Continue reading how the out-of-box configuration works in Understanding Users and Contacts
configuration.
Overview topics
Azure AD Connect and federation
Azure AD Connect lets you configure federation with the on-premises AD FS and Azure AD. With federation sign
on, you can enable users to sign on to Azure AD based services with their on-premises passwords and, while on the
corporate network, without having to enter their passwords again. The federation option with AD FS allows you to
deploy a new or specify an existing AD FS in Windows Server 2012 R2 farm.
This topic is the home for information on Federation related functionalities for Azure AD Connect and lists links to
all other topics related to it. For links to Azure AD Connect, see Integrating your on-premises identities with Azure
Active Directory.
Azure AD Connect - federation topics

Azure AD Connect user sign-in options
Understanding User sign-in options Description of various user sign-in options and how they
affect Azure sign-in user experience
AD FS installation using Azure AD Connect
Pre-requisites Pre-requisites for a successful AD FS installation via Azure AD

Connect
Configure AD FS farm How to install a new AD FS farm using Azure AD Connect
Modifying the AD FS configuration
Repairing the trust How to repair current trust between on-premises AD FS and
Office 365 / Azure
Adding a new AD FS server Expanding AD FS farm with additional AD FS server post initial
installation
Adding a new AD FS WAP server Expanding AD FS farm with additional WAP server post initial
installation
Add a new federated domain Add another domain to be federated with Azure AD
Post installation tasks
Add custom company logo / illustration Modify the sign-in experience by specifying the custom logo
that will be shown on the AD FS sign-in page
Add sign-in description Changing sign-in description on the AD FS sign-in page
Modifying AD FS claim rules Modify / add claim rules in AD FS corresponding to Azure AD

Connect sync configuration
Additional resources
AD FS deployment in Azure
High availability cross-geographic AD FS deployment in Azure with Azure Traffic Manager
Prerequisites for Azure AD Connect
This topic describes the pre-requisites and the hardware requirements for Azure AD Connect.
Before you install Azure AD Connect

Before you install Azure AD Connect, there are a few things that you need.
Azure AD
An Azure subscription or an Azure trial subscription. This is only required for accessing the Azure portal and not
for using Azure AD Connect. If you are using PowerShell or Office 365 you do not need an Azure subscription
to use Azure AD Connect. If you have an Office 365 license you can also use the Office 365 portal. With a paid
Office 365 license you can also get into the Azure portal from the Office 365 portal.
You can also use the Azure AD preview functionality in the Azure portal. This portal does not require an
Azure license.
Add and verify the domain you plan to use in Azure AD. For example, if you plan to use contoso.com for your
users then make sure this domain has been verified and you are not only using the contoso.onmicrosoft.com
default domain.
An Azure AD tenant allows by default 50k objects. When you verify your domain, the limit is increased to 300k
objects. If you need even more objects in Azure AD you need to open a support case to have the limit increased
even further. If you need more than 500k objects then you need a license, such as Office 365, Azure AD Basic,
Azure AD Premium, or Enterprise Mobility Suite.
Prepare your on-premises data
Review optional sync features you can enable in Azure AD and evaluate which features you should enable.
On-premises servers and environment
The AD schema version and forest functional level must be Windows Server 2003 or later. The domain
controllers can run any version as long as the schema and forest level requirements are met.
If you plan to use the feature password writeback the Domain Controllers must be on Windows Server 2008
(with latest SP) or later. If your DCs are on 2008 (pre-R2) then you must also apply hotfix KB2386717.
The domain controller used by Azure AD must be writable. It is not supported to use a RODC (read-only
domain controller) and Azure AD Connect does not follow any write redirects.
Azure AD Connect cannot be installed on Small Business Server or Windows Server Essentials. The server must
be using Windows Server standard or better.
The Azure AD Connect server must have a full GUI installed. It is not supported to install on server core.
Azure AD Connect must be installed on Windows Server 2008 or later. This server may be a domain controller
or a member server if using express settings. If you use custom settings, the server can also be stand-alone and
does not have to be joined to a domain.
If you install Azure AD Connect on Windows Server 2008, make sure to apply the latest hotfixes from Windows
Update. The installation is not able to start with an unpatched server.
If you plan to use the feature password synchronization, the Azure AD Connect server must be on Windows
Server 2008 R2 SP1 or later.
The Azure AD Connect server must have .NET Framework 4.5.1 or later and Microsoft PowerShell 3.0 or later
installed.
If Active Directory Federation Services is being deployed, the servers where AD FS or Web Application Proxy
are installed must be Windows Server 2012 R2 or later. Windows remote management must be enabled on
these servers for remote installation.
If Active Directory Federation Services is being deployed, you need SSL Certificates.
If Active Directory Federation Services is being deployed, then you need to configure name resolution.
Azure AD Connect requires a SQL Server database to store identity data. By default a SQL Server 2012 Express
LocalDB (a light version of SQL Server Express) is installed and the service account for the service is created on
the local machine. SQL Server Express has a 10GB size limit that enables you to manage approximately 100,000
objects. If you need to manage a higher volume of directory objects, you need to point the installation wizard to
a different installation of SQL Server.
If you use a separate SQL Server, then these requirements apply:
Azure AD Connect supports all flavors of Microsoft SQL Server from SQL Server 2008 (with SP4) to SQL
Server 2016. Microsoft Azure SQL Database is not supported as a database.
You must use a case-insensitive SQL collation. These are identified with a _CI_ in their name. It is not
supported to use a case-sensitive collation, identified by _CS_ in their name.
You can only have one sync engine per database instance. It is not supported to share the database
instance with FIM/MIM Sync, DirSync, or Azure AD Sync.
Accounts
An Azure AD Global Administrator account for the Azure AD directory you wish to integrate with. This must be
a school or organization account and cannot be a Microsoft account.
If you use express settings or upgrade from DirSync, then you must have an Enterprise Administrator account
for your local Active Directory.
Accounts in Active Directory if you use the custom settings installation path.
Azure AD Connect server configuration
If your global administrators have MFA enabled, then the URL https://secure.aadcdn.microsoftonline-
p.com must be in the trusted sites list. You are prompted to add this to the trusted sites list if it is not added
before you are prompted for an MFA challenge. You can use Internet Explorer to add it to your trusted sites.
Connectivity
The Azure AD Connect server needs DNS resolution for both intranet and internet. The DNS server must be
able to resolve names both to your on-premises Active Directory as well as the Azure AD endpoints.
If you have firewalls on your Intranet and you need to open ports between the Azure AD Connect servers and
your domain controllers, then see Azure AD Connect Ports for more information.
If your proxy or firewall limit which URLs can be accessed, then the URLs documented in Office 365 URLs and
IP address ranges must be opened.
If you are using the Microsoft Cloud in Germany or the Microsoft Azure Government cloud, then see
Azure AD Connect sync service instances considerations for URLs.
Azure AD Connect is by default using TLS 1.0 to communicate with Azure AD. You can change this to TLS 1.2 by
following the steps in Enable TLS 1.2 for Azure AD Connect.
If you are using an outbound proxy for connecting to the Internet, the following setting in the
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config file must be added for
the installation wizard and Azure AD Connect sync to be able to connect to the Internet and Azure AD. This text
must be entered at the bottom of the file. In this code, <PROXYADRESS> represents the actual proxy IP address
or host name.
<system.net>
<defaultProxy>
<proxy
usesystemdefault="true"
proxyaddress="http://<PROXYADDRESS>:<PROXYPORT>"
bypassonlocal="true"
/>
</defaultProxy>
</system.net>
If your proxy server requires authentication, then the service account must be located in the domain and you
must use the customized settings installation path to specify a custom service account. You also need a
different change to machine.config. With this change in machine.config the installation wizard and sync engine
respond to authentication requests from the proxy server. In all installation wizard pages, excluding the
Configure page, the signed in user's credentials are used. On the Configure page at the end of the installation
wizard, the context is switched to the service account that was created by you. The machine.config section
should look like this.
<system.net>
<defaultProxy enabled="true" useDefaultCredentials="true">
<proxy
usesystemdefault="true"
proxyaddress="http://<PROXYADDRESS>:<PROXYPORT>"
bypassonlocal="true"
/>
</defaultProxy>
</system.net>
See MSDN for more information about the default proxy Element.
If you have problems with connectivity, please see Troubleshoot connectivity problems.
Other
Optional: A test user account to verify synchronization.
Component prerequisites
PowerShell and .Net Framework
Azure AD Connect depends on Microsoft PowerShell and .NET Framework 4.5.1. You need this version or a later
version installed on your server. Depending on your Windows Server version, do the following:
Windows Server 2012R2
Microsoft PowerShell is installed by default, no action is required.
.NET Framework 4.5.1 and later releases are offered through Windows Update. Make sure you have
installed the latest updates to Windows Server in the Control Panel.
Windows Server 2008R2 and Windows Server 2012
The latest version of Microsoft PowerShell is available in Windows Management Framework 4.0,
available on Microsoft Download Center.
.NET Framework 4.5.1 and later releases are available on Microsoft Download Center.
Windows Server 2008
The latest supported version of PowerShell is available in Windows Management Framework 3.0,
available on Microsoft Download Center.
.NET Framework 4.5.1 and later releases are available on Microsoft Download Center.
Enable TLS 1.2 for Azure AD Connect
Azure AD Connect is using TLS 1.0 by default for encrypting the communication between the sync engine server
and Azure AD. You can change this by configuring .Net applications to use TLS 1.2 by default on the server. More
information about TLS 1.2 can be found in Microsoft Security Advisory 2960358.
1. TLS 1.2 cannot be enabled on Windows Server 2008. You need Windows Server 2008R2 or later. Make sure
you have the .Net 4.5.1 hotfix installed for your operating system, see Microsoft Security Advisory 2960358.
You might have this or a later release installed on your server already.
2. If you use Windows Server 2008R2, then make sure TLS 1.2 is enabled. On Windows Server 2012 server and
later versions, TLS 1.2 should already be enabled.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001
3. For all operating systems, set this registry key and restart the server.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 "SchUseStrongCrypto"=dword:00000001
4. If you also want to enable TLS 1.2 between the sync engine server and a remote SQL Server, then make sure
you have the required versions installed for TLS 1.2 support for Microsoft SQL Server.
Prerequisites for federation installation and configuration

Windows Remote Management
When using Azure AD Connect to deploy Active Directory Federation Services or the Web Application Proxy, check
the requirements below to ensure connectivity and configuration will succeed:
If the target server is domain joined, ensure that Windows Remote Managed is enabled
In an elevated PSH command window, use command Enable-PSRemoting force
If the target server is a non-domain joined WAP machine, there are a couple of additional requirements
On the target machine (WAP machine):
Ensure the winrm (Windows Remote Management / WS-Management) service is running via the
Services snap-in
In an elevated PSH command window, use command Enable-PSRemoting force
On the machine on which the wizard is running (if the target machine is non-domain
joined or untrusted domain):
In an elevated PSH command window, use the command
Set-Item WSMan:\localhost\Client\TrustedHosts Value <DMZServerFQDN> -Force Concatenate
In Server Manager:
add DMZ WAP host to machine pool (server manager -> Manage -> Add Servers...use
DNS tab)
Server Manager All Servers tab: right click WAP server and choose Manage As..., enter local
(not domain) creds for the WAP machine
To validate remote PSH connectivity, in the Server Manager All Servers tab: right click WAP
server and choose Windows PowerShell. A remote PSH session should open to ensure
remote PowerShell sessions can be established.
SSL Certificate Requirements
Important: its strongly recommended to use the same SSL certificate across all nodes of your AD FS farm as well
as all Web Application proxy servers.
The certificate must be an X509 certificate.
You can use a self-signed certificate on federation servers in a test lab environment. However, for a production
environment, we recommend that you obtain the certificate from a public CA.
If using a certificate that is not publicly trusted, ensure that the certificate installed on each Web
Application Proxy server is trusted on both the local server and on all federation servers
The identity of the certificate must match the federation service name (for example, sts.contoso.com).
The identity is either a subject alternative name (SAN) extension of type dNSName or, if there are no
SAN entries, the subject name specified as a common name.
Multiple SAN entries can be present in the certificate, provided one of them matches the federation
service name.
If you are planning to use Workplace Join, an additional SAN is required with the value
enterpriseregistration. followed by the User Principal Name (UPN) suffix of your organization, for
example, enterpriseregistration.contoso.com.
Certificates based on CryptoAPI next generation (CNG) keys and key storage providers are not supported. This
means you must use a certificate based on a CSP (cryptographic service provider) and not a KSP (key storage
provider).
Wild card certificates are supported.
Name resolution for federation servers
Set up DNS records for the AD FS federation service name (e.g. sts.contoso.com) for both the intranet (your
internal DNS server) and the extranet (public DNS through your domain registrar). For the intranet DNS record
ensure that you use A records and not CNAME records. This is required for windows authentication to work
correctly from your domain joined machine.
If you are deploying more than one AD FS server or Web Application Proxy server, then ensure that you have
configured your load balancer and that the DNS records for the AD FS federation service name (for example
sts.contoso.com) point to the load balancer.
For windows integrated authentication to work for browser applications using Internet Explorer in your
intranet, ensure that the AD FS federation service name (for example sts.contoso.com) is added to the intranet
zone in IE. This can be controlled via group policy and deployed to all your domain joined computers.
Azure AD Connect supporting components

The following is a list of components that Azure AD Connect installs on the server where Azure AD Connect is
installed. This list is for a basic Express installation. If you choose to use a different SQL Server on the Install
synchronization services page, then SQL Express LocalDB is not installed locally.
Azure AD Connect Health
Microsoft Online Services Sign-In Assistant for IT Professionals (installed but no dependency on it)
Microsoft SQL Server 2012 Command Line Utilities
Microsoft SQL Server 2012 Express LocalDB
Microsoft SQL Server 2012 Native Client
Microsoft Visual C++ 2013 Redistribution Package
Hardware requirements for Azure AD Connect

The table below shows the minimum requirements for the Azure AD Connect sync computer.
NUMBER OF OBJECTS IN
ACTIVE DIRECTORY CPU MEMORY HARD DRIVE SIZE
Fewer than 10,000 1.6 GHz 4 GB 70 GB
10,00050,000 1.6 GHz 4 GB 70 GB
50,000100,000 1.6 GHz 16 GB 100 GB

NUMBER OF OBJECTS IN
ACTIVE DIRECTORY CPU MEMORY HARD DRIVE SIZE
For 100,000 or more objects

the full version of SQL
Server is required
100,000300,000 1.6 GHz 32 GB 300 GB
300,000600,000 1.6 GHz 32 GB 450 GB
More than 600,000 1.6 GHz 32 GB 500 GB
The minimum requirements for computers running AD FS or Web Application Servers is the following:
CPU: Dual core 1.6 GHz or higher
MEMORY: 2GB or higher
Azure VM: A2 configuration or higher
Next steps
Select which installation type to use for Azure AD
Connect
Azure AD Connect has two installation types for new installation: Express and customized. This topic helps you to
decide which option to use during installation.
Express
Express is the most common option and is used by about 90% of all new installations. It was designed to provide a
configuration that works for the most common customer scenarios.
It assumes:
You have a single Active Directory forest on-premises.
You have an enterprise administrator account you can use for the installation.
You have less than 100,000 objects in your on-premises Active Directory.
You get:
Password synchronization from on-premises to Azure AD for single sign-on.
A configuration that synchronizes users, groups, contacts, and Windows 10 computers.
Synchronization of all eligible objects in all domains and all OUs.
Automatic upgrade is enabled to make sure you always use the latest available version.
Options where you can still use Express:
If you do not want to synchronize all OUs, you can still use Express and on the last page, unselect Start the
synchronization process...*. Then run the installation wizard again and change the OUs in configuration
options and enable scheduled sync.
You want to enable one of the features in Azure AD Premium, such as Password writeback. First go through
express to get the initial installation completed. Then run the installation wizard again and change the
configuration options.
Custom
The customized path allows many more options than express. It should be used in all cases where the configuration
described in previous section for express is not representative for your organization.
Use when:
You do not have access to an enterprise admin account in Active Directory.
You have more than one forest or you plan to synchronize more than one forest in the future.
You have domains in your forest not reachable from the Connect server.
You plan to use federation or pass-through authentication for user sign-in.
You have more than 100,000 objects and need to use a full SQL Server.
You plan to use group-based filtering and not only domain or OU-based filtering.

If you are currently using DirSync, then follow the steps in Upgrade from DirSync to upgrade your existing
configuration. There are two different upgrade options:
In-place upgrade to install Connect on the same server.
Parallel deployment to install Connect on a new server while the existing DirSync server is still operational.
Upgrade from Azure AD Sync

If you are currently using Azure AD Sync, then you can follow the same steps as when you upgrade from one
Connect version to a newer. There are two different upgrade options:
In-place upgrade to install Connect on the same server.
Swing-migration to install Connect on a new server while the existing Azure AD Sync server is still operational.
Migrate from FIM2010 or MIM2016

If you are currently using Forefront Identity Manager 2010 or Microsoft Identity Manager 2016 with the Azure AD
Connector, then your only option is a migration. Follow the steps described in swing-migration. In the steps, replace
any mention of Azure AD Sync with FIM2010/MIM2016.
Next steps
Depending on the option you have selected to use, use the table of content to the left to find your article with the
detailed steps.
Getting started with Azure AD Connect using express
settings
Azure AD Connect Express Settings is used when you have a single-forest topology and password
synchronization for authentication. Express Settings is the default option and is used for the most commonly
deployed scenario. You are only a few short clicks away to extend your on-premises directory to the cloud.
Before you start installing Azure AD Connect, make sure to download Azure AD Connect and complete the pre-
requisite steps in Azure AD Connect: Hardware and prerequisites.
If express settings does not match your topology, see related documentation for other scenarios.
Express installation of Azure AD Connect

You can see these steps in action in the videos section.
1. Sign in as a local administrator to the server you wish to install Azure AD Connect on. You should do this on
the server you wish to be the sync server.
2. Navigate to and double-click AzureADConnect.msi.
3. On the Welcome screen, select the box agreeing to the licensing terms and click Continue.
4. On the Express settings screen, click Use express settings.
5. On the Connect to Azure AD screen, enter the username and password of a global administrator for your Azure
AD. Click Next.
If you receive an error and have problems with connectivity, then see Troubleshoot connectivity problems.
6. On the Connect to AD DS screen, enter the username and password for an enterprise admin account. You can
enter the domain part in either NetBios or FQDN format, that is, FABRIKAM\administrator or
fabrikam.com\administrator. Click Next.
7. The Azure AD sign-in configuration page only shows if you did not complete verify your domains in the
prerequisites.
If you see this page, then review every domain marked Not Added and Not Verified. Make sure those
domains you use have been verified in Azure AD. Click the Refresh symbol when you have verified your
domains.
8. On the Ready to configure screen, click Install.
Optionally on the Ready to configure page, you can unselect the Start the synchronization process as
soon as configuration completes checkbox. You should unselect this checkbox if you want to do
additional configuration, such as filtering. If you unselect this option, the wizard configures sync but
leaves the scheduler disabled. It does not run until you enable it manually by rerunning the installation
wizard.
If you have Exchange in your on-premises Active Directory, then you also have an option to enable
Exchange Hybrid deployment. Enable this option if you plan to have Exchange mailboxes both in the
cloud and on-premises at the same time.
9. When the installation completes, click Exit.
10. After the installation has completed, sign off and sign in again before you use Synchronization Service
Manager or Synchronization Rule Editor.
Videos
For a video on using the express installation, see:
Next steps
Now that you have Azure AD Connect installed you can verify the installation and assign licenses.
Learn more about these features, which were enabled with the installation: Automatic upgrade, Prevent accidental
deletes, and Azure AD Connect Health.
Learn more about these common topics: scheduler and how to trigger sync.
Related documentation
TOPIC
Azure AD Connect overview

TOPIC
Install using customized settings
Accounts used for installation

Custom installation of Azure AD Connect
Azure AD Connect Custom settings is used when you want more options for the installation. It is used if you have
multiple forests or if you want to configure optional features not covered in the express installation. It is used in all
cases where the express installation option does not satisfy your deployment or topology.
requisite steps in Azure AD Connect: Hardware and prerequisites. Also make sure you have required accounts
available as described in Azure AD Connect accounts and permissions.
If customized settings does not match your topology, for example to upgrade DirSync, see related documentation
for other scenarios.
Custom settings installation of Azure AD Connect

Express Settings
On this page, click Customize to start a customized settings installation.
Install required components
When you install the synchronization services, you can leave the optional configuration section unchecked and
Azure AD Connect sets up everything automatically. It sets up a SQL Server 2012 Express LocalDB instance, create
the appropriate groups, and assign permissions. If you wish to change the defaults, you can use the following
table to understand the optional configuration options that are available.
OPTIONAL CONFIGURATION DESCRIPTION
Use an existing SQL Server Allows you to specify the SQL Server name and the instance
name. Choose this option if you already have a database
server that you would like to use. Enter the instance name
followed by a comma and port number in Instance Name if
your SQL Server does not have browsing enabled.
Use an existing service account By default Azure AD Connect creates a local service account
for the synchronization services to use. The password is
generated automatically and unknown to the person
installing Azure AD Connect. If you use a remote SQL server
or use a proxy that requires authentication, you need a
service account in the domain and know the password. In
those cases, enter the service account to use. Make sure the
user running the installation is an SA in SQL so a login for the
service account can be created. See Azure AD Connect
accounts and permissions
Specify custom sync groups By default Azure AD Connect creates four groups local to the
server when the synchronization services are installed. These
groups are: Administrators group, Operators group, Browse
group, and the Password Reset Group. You can specify your
own groups here. The groups must be local on the server and
cannot be located in the domain.
User sign-in
After installing the required components, you are asked to select your users single sign-on method. The following
table provides a brief description of the available options. For a full description of the sign-in methods, see User
sign-in.
SINGLE SIGN ON OPTION DESCRIPTION
Password Sync Users are able to sign in to Microsoft cloud services, such as
Office 365, using the same password they use in their on-
premises network. The users passwords are synchronized to
Azure AD as a password hash and authentication occurs in
the cloud. See Password synchronization for more
information.
Pass-through Authentication (Preview) Users are able to sign in to Microsoft cloud services, such as
premises network. The users password is passed through to
the on-premises Active Directory controller to be validated.
Federation with AD FS Users are able to sign in to Microsoft cloud services, such as
premises network. The users are redirected to their on-
premises AD FS instance to sign in and authentication occurs
on-premises.
Do not configure Neither feature is installed and configured. Choose this option
if you already have a 3rd party federation server or another
existing solution in place.
Enable Single Sign on This options is available with both password sync and Pass-
through authentication and provides a single sign on
experience for desktop users on the corporate network. See
Single sign-on for more information.
Note for AD FS customers this option is not available because
AD FS already offers the same level of single sign on.
(if PTA is not released at the same time)
Sign On Option This options is available for password sync customers and
provides a single sign on experience for desktop users on the
corporate network.
See Single sign-on for more information.
Note for AD FS customers this option is not available because
AD FS already offers the same level of single sign on.
Connect to Azure AD
On the Connect to Azure AD screen, enter a global admin account and password. If you selected Federation with
AD FS on the previous page, do not sign in with an account in a domain you plan to enable for federation. A
recommendation is to use an account in the default onmicrosoft.com domain, which comes with your Azure AD
directory.
This account is only used to create a service account in Azure AD and is not used after the wizard has completed.
If your global admin account has MFA enabled, then you need to provide the password again in the sign-in popup
and complete the MFA challenge. The challenge could be a providing a verification code or a phone call.
The global admin account can also have Privileged Identity Management enabled.
If you receive an error and have problems with connectivity, then see Troubleshoot connectivity problems.
Pages under the section Sync
Connect your directories
To connect to your Active Directory Domain Service, Azure AD Connect needs the credentials of an account with
sufficient permissions. You can enter the domain part in either NetBios or FQDN format, that is,
FABRIKAM\syncuser or fabrikam.com\syncuser. This account can be a regular user account because it only needs
the default read permissions. However, depending on your scenario, you may need more permissions. For more
information, see Azure AD Connect Accounts and permissions
Azure AD sign-in configuration

This page allows you to review the UPN domains present in on-premises AD DS and which have been verified in
Azure AD. This page also allows you to configure the attribute to use for the userPrincipalName.
Review every domain marked Not Added and Not Verified. Make sure those domains you use have been
verified in Azure AD. Click the Refresh symbol when you have verified your domains. For more information, see
add and verify the domain
UserPrincipalName - The attribute userPrincipalName is the attribute users use when they sign in to Azure AD
and Office 365. The domains used, also known as the UPN-suffix, should be verified in Azure AD before the users
are synchronized. Microsoft recommends to keep the default attribute userPrincipalName. If this attribute is non-
routable and cannot be verified, then it is possible to select another attribute. You can for example select email as
the attribute holding the sign-in ID. Using another attribute than userPrincipalName is known as Alternate ID.
The Alternate ID attribute value must follow the RFC822 standard. An Alternate ID can be used with both
password sync and federation.
NOTE
When you enable Pass-through Authentication you must have at least one verified domain in order to continue through
the wizard.
WARNING
Using an Alternate ID is not compatible with all Office 365 workloads. For more information, refer to Configuring Alternate
Login ID.
Domain and OU filtering

By default all domains and OUs are synchronized. If there are some domains or OUs you do not want to
synchronize to Azure AD, you can unselect these domains and OUs.
This page in the wizard is configuring domain-based and OU-based filtering. If you plan to make changes, then
see domain-based filtering and ou-based filtering before you make these changes. Some OUs are essential for the
functionality and should not be unselected.
If you use OU-based filtering, new OUs added later are synchronized by default. If you want the behavior that new
OUs should not be synchronized, then you can configure it after the wizard has completed with ou-based filtering.
If you plan to use group-based filtering, then make sure the OU with the group is included and not filtered with
OU-filtering. OU filtering is evaluated before group-based filtering.
It is also possible that some domains are not reachable due to firewall restrictions. These domains are unselected
by default and have a warning.
If you see this warning, make sure that these domains are indeed unreachable and the warning is expected.
Uniquely identifying your users
The Matching across forests feature allows you to define how users from your AD DS forests are represented in
Azure AD. A user might either be represented only once across all forests or have a combination of enabled and
disabled accounts. The user might also be represented as a contact in some forests.
SETTING DESCRIPTION
Users are only represented once across all forests All users are created as individual objects in Azure AD. The
objects are not joined in the metaverse.
Mail attribute This option joins users and contacts if the mail attribute has
the same value in different forests. Use this option when your
contacts have been created using GALSync.
ObjectSID and msExchangeMasterAccountSID/ msRTCSIP- This option joins an enabled user in an account forest with a
OriginatorSid disabled user in a resource forest. In Exchange, this
configuration is known as a linked mailbox. This option can
also be used if you only use Lync and Exchange is not present
in the resource forest.
sAMAccountName and MailNickName This option joins on attributes where it is expected the sign-in
ID for the user can be found.
A specific attribute This option allows you to select your own attribute.
Limitation: Make sure to pick an attribute that already can
be found in the metaverse. If you pick a custom attribute (not
in the metaverse), the wizard cannot complete.
Source Anchor - The attribute sourceAnchor is an attribute that is immutable during the lifetime of a user object.
It is the primary key linking the on-premises user with the user in Azure AD. Since the attribute cannot be
changed, you must plan for a good attribute to use. A good candidate is objectGUID. This attribute is not changed,
unless the user account is moved between forests/domains. In a multi-forest environment where you move
accounts between forests, another attribute must be used, such as an attribute with the employeeID. Avoid
attributes that would change when a person marries or change assignments. You cannot use attributes with an @-
sign, so email and userPrincipalName cannot be used. The attribute is also case-sensitive so when you move an
object between forests, make sure to preserve the upper/lower case. Binary attributes are base64-encoded, but
other attribute types remain in its unencoded state. In federation scenarios and some Azure AD interfaces, this
attribute is also known as immutableID. More information about the source anchor can be found in the design
concepts.
Sync filtering based on groups
The filtering on groups feature allows you to sync only a small subset of objects for a pilot. To use this feature,
create a group for this purpose in your on-premises Active Directory. Then add users and groups that should be
synchronized to Azure AD as direct members. You can later add and remove users to this group to maintain the
list of objects that should be present in Azure AD. All objects you want to synchronize must be a direct member of
the group. Users, groups, contacts, and computers/devices must all be direct members. Nested group membership
is not resolved. When you add a group as a member, only the group itself is added and not its members.
WARNING
This feature is only intended to support a pilot deployment. Do not use it in a full-blown production deployment.
In a full-blown production deployment, it is going to be hard to maintain a single group with all objects to
synchronize. Instead you should use one of the methods in Configure filtering.
Optional Features
This screen allows you to select the optional features for your specific scenarios.
WARNING
If you currently have DirSync or Azure AD Sync active, do not activate any of the writeback features in Azure AD Connect.
OPTIONAL FEATURES DESCRIPTION
Exchange Hybrid Deployment The Exchange Hybrid Deployment feature allows for the co-
existence of Exchange mailboxes both on-premises and in
Office 365. Azure AD Connect is synchronizing a specific set
of attributes from Azure AD back into your on-premises
directory.
Azure AD app and attribute filtering By enabling Azure AD app and attribute filtering, the set of
synchronized attributes can be tailored. This option adds two
more configuration pages to the wizard. For more
information, see Azure AD app and attribute filtering.
Password synchronization If you selected federation as the sign-in solution, then you
can enable this option. Password synchronization can then be
used as a backup option. For additional information, see
Password synchronization.
If you selected Pass-through Authentication this option is
enabled by default to ensure support for legacy clients and as
a backup option. For additional information, see Password
synchronization.
Password writeback By enabling password writeback, password changes that

originate in Azure AD is written back to your on-premises
directory. For more information, see Getting started with
password management.
OPTIONAL FEATURES DESCRIPTION
Group writeback If you use the Office 365 Groups feature, then you can have
these groups represented in your on-premises Active
Directory. This option is only available if you have Exchange
present in your on-premises Active Directory. For more
information, see Group writeback.
Device writeback Allows you to writeback device objects in Azure AD to your

on-premises Active Directory for conditional access scenarios.
For more information, see Enabling device writeback in Azure
AD Connect.
Directory extension attribute sync By enabling directory extensions attribute sync, attributes
specified are synced to Azure AD. For more information, see
Directory extensions.
Azure AD app and attribute filtering

If you want to limit which attributes to synchronize to Azure AD, then start by selecting which services you are
using. If you make configuration changes on this page, a new service has to be selected explicitly by rerunning the
Based on the services selected in the previous step, this page shows all attributes that are synchronized. This list is
a combination of all object types being synchronized. If there are some particular attributes you need to not
synchronize, you can unselect those attributes.
WARNING
Removing attributes can impact functionality. For best practices and recommendations, see attributes synchronized.
Directory Extension attribute sync

You can extend the schema in Azure AD with custom attributes added by your organization or other attributes in
Active Directory. To use this feature, select Directory Extension attribute sync on the Optional Features page.
You can select more attributes to sync on this page.
For more information, see Directory extensions.
Enabling Single sign on (SSO )
Configuring single sign-on for use with Password Synchronization or Pass-through authentication is a simple
process that you only need to complete once for each forest that is being synchronized to Azure AD. Configuration
involves two steps as follows:
1. Create the necessary computer account in your on-premises Active Directory.
2. Configure the intranet zone of the client machines to support single sign on.
Create the computer account in Active Directory
For each forest that has been added in Azure AD Connect, you will need to supply Domain Administrator
credentials so that the computer account can be created in each forest. The credentials are only used to create the
account and are not stored or used for any other operation. Simply add the credentials on the Enable Single sign
on page of the Azure AD Connect wizard as shown:
NOTE
You can skip a particular forest if you do not wish to use Single sign on with that forest.
Configure the Intranet Zone for client machines

To ensure that the client sign-ins automatically in the intranet zone you need to ensure that two URLs are part of
the intranet zone. This ensures that the domain joined computer automatically sends a Kerberos ticket to Azure AD
when it is connected to the corporate network. On a computer that has the Group Policy management tools.
1. Open the Group Policy Management tools
2. Edit the Group policy that will be applied to all users. For example, the Default Domain Policy.
3. Navigate to User Configuration\Administrative Templates\Windows Components\Internet
Explorer\Internet Control Panel\Security Page and select Site to Zone Assignment List per the image
below.
4. Enable the policy, and enter the following two items in the dialog box.
Value: https://autologon.microsoftazuread-sso.com
Data: 1
Value: https://aadg.windows.net.nsatc.net
Data: 1
5. It should look similar to the following:
6. Click Ok twice.
Configuring federation with AD FS

Configuring AD FS with Azure AD Connect is simple with just a few clicks. The following is required before the
configuration.
A Windows Server 2012 R2 server for the federation server with remote management enabled
A Windows Server 2012 R2 server for the Web Application Proxy server with remote management enabled
An SSL certificate for the federation service name you intend to use (for example sts.contoso.com)
AD FS configuration pre -requisites
To configure your AD FS farm using Azure AD Connect, ensure WinRM is enabled on the remote servers. In
addition, go through the ports requirement listed in Table 3 - Azure AD Connect and Federation Servers/WAP.
Create a new AD FS farm or use an existing AD FS farm
You can use an existing AD FS farm or you can choose to create a new AD FS farm. If you choose to create a new
one, you are required to provide the SSL certificate. If the SSL certificate is protected by a password, you are
prompted for the password.
If you choose to use an existing AD FS farm, you are taken directly to the configuring the trust relationship
between AD FS and Azure AD screen.
Specify the AD FS servers
Enter the servers that you want to install AD FS on. You can add one or more servers based on your capacity
planning needs. Join all servers to Active Directory before you perform this configuration. Microsoft recommends
installing a single AD FS server for test and pilot deployments. Then add and deploy more servers to meet your
scaling needs by running Azure AD Connect again after initial configuration.
NOTE
Ensure that all your servers are joined to an AD domain before you do this configuration.
Specify the Web Application Proxy servers
Enter the servers that you want as your Web Application proxy servers. The web application proxy server is
deployed in your DMZ (extranet facing) and supports authentication requests from the extranet. You can add one
or more servers based on your capacity planning needs. Microsoft recommends installing a single Web
application proxy server for test and pilot deployments. Then add and deploy more servers to meet your scaling
needs by running Azure AD Connect again after initial configuration. We recommend having an equivalent
number of proxy servers to satisfy authentication from the intranet.
NOTE
If the account you use is not a local admin on the AD FS servers, then you are prompted for admin credentials.
Ensure that there is HTTP/HTTPS connectivity between the Azure AD Connect server and the Web Application Proxy server
before you run this step.
Ensure that there is HTTP/HTTPS connectivity between the Web Application Server and the AD FS server to allow
authentication requests to flow through.
You are prompted to enter credentials so that the web application server can establish a secure connection to the
AD FS server. These credentials need to be a local administrator on the AD FS server.
Specify the service account for the AD FS service

The AD FS service requires a domain service account to authenticate users and lookup user information in Active
Directory. It can support two types of service accounts:
Group Managed Service Account - Introduced in Active Directory Domain Services with Windows Server
2012. This type of account provides services, such as AD FS, a single account without needing to update the
account password regularly. Use this option if you already have Windows Server 2012 domain controllers in
the domain that your AD FS servers belong to.
Domain User Account - This type of account requires you to provide a password and regularly update the
password when the password changes or expires. Use this option only when you do not have Windows Server
2012 domain controllers in the domain that your AD FS servers belong to.
If you selected Group Managed Service Account and this feature has never been used in Active Directory, you are
prompted for Enterprise Admin credentials. These credentials are used to initiate the key store and enable the
feature in Active Directory.
Select the Azure AD domain that you wish to federate

This configuration is used to setup the federation relationship between AD FS and Azure AD. It configures AD FS to
issue security tokens to Azure AD and configures Azure AD to trust the tokens from this specific AD FS instance.
This page only allows you to configure a single domain in the initial installation. You can configure more domains
later by running Azure AD Connect again.
Verify the Azure AD domain selected for federation
When you select the domain to be federated, Azure AD Connect provides you with necessary information to verify
an unverified domain. See Add and verify the domain for how to use this information.
NOTE
AD Connect tries to verify the domain during the configure stage. If you continue to configure without adding the necessary
DNS records, the wizard is not able to complete the configuration.
Configure and verify pages

The configuration happens on this page.
NOTE
Before you continue installation and if you configured federation, make sure that you have configured Name resolution for
federation servers.
Staging mode
It is possible to setup a new sync server in parallel with staging mode. It is only supported to have one sync server
exporting to one directory in the cloud. But if you want to move from another server, for example one running
DirSync, then you can enable Azure AD Connect in staging mode. When enabled, the sync engine import and
synchronize data as normal, but it does not export anything to Azure AD or AD. The features password sync and
password writeback are disabled while in staging mode.
While in staging mode, it is possible to make required changes to the sync engine and review what is about to be
exported. When the configuration looks good, run the installation wizard again and disable staging mode. Data is
now exported to Azure AD from this server. Make sure to disable the other server at the same time so only one
server is actively exporting.
For more information, see Staging mode.
Verify your federation configuration
Azure AD Connect verifies the DNS settings for you when you click the Verify button.
In addition, perform the following verification steps:

Validate that you can sign in from a browser from a domain joined machine on the intranet: Connect to
https://myapps.microsoft.com and verify the sign-in with your logged in account. The built-in AD DS
administrator account is not synchronized and cannot be used for verification.
Validate that you can sign in from a device from the extranet. On a home machine or a mobile device, connect
to https://myapps.microsoft.com and supply your credentials.
Validate rich client sign-in. Connect to https://testconnectivity.microsoft.com, choose the Office 365 tab and
chose the Office 365 Single Sign-On Test.
Next steps
After the installation has completed, sign out and sign in again to Windows before you use Synchronization
Service Manager or Synchronization Rule Editor.
Learn more about these features, which were enabled with the installation: Prevent accidental deletes and Azure
AD Connect Health.
Azure AD Connect: Upgrade from DirSync
Azure AD Connect is the successor to DirSync. You find the ways you can upgrade from DirSync in this topic.
These steps do not work for upgrading from another release of Azure AD Connect or from Azure AD Sync.
requisite steps in Azure AD Connect: Hardware and prerequisites. In particular, you want to read about the
following, since these areas are different from DirSync:
The required version of .Net and PowerShell. Newer versions are required to be on the server than what
DirSync needed.
The proxy server configuration. If you use a proxy server to reach the internet, this setting must be configured
before you upgrade. DirSync always used the proxy server configured for the user installing it, but Azure AD
Connect uses machine settings instead.
The URLs required to be open in the proxy server. For basic scenarios, those scenarios also supported by
DirSync, the requirements are the same. If you want to use any of the new features included with Azure AD
Connect, some new URLs must be opened.
NOTE
Once you have enabled your new Azure AD Connect server to start synchronizing changes to Azure AD, you must not roll
back to using DirSync or Azure AD Sync. Downgrading from Azure AD Connect to legacy clients including DirSync and
Azure AD Sync is not supported and can lead to issues such as data loss in Azure AD.
If you are not upgrading from DirSync, see related documentation for other scenarios.

Depending on your current DirSync deployment, there are different options for the upgrade. If the expected
upgrade time is less than three hours, then the recommendation is to do an in-place upgrade. If the expected
upgrade time is more than three hours, then the recommendation is to do a parallel deployment on another
server. It is estimated that if you have more than 50,000 objects it takes more than three hours to do the upgrade.
SCENARIO
In-place upgrade
Parallel deployment
NOTE
When you plan to upgrade from DirSync to Azure AD Connect, do not uninstall DirSync yourself before the upgrade. Azure
AD Connect will read and migrate the configuration from DirSync and uninstall after inspecting the server.
In-place upgrade
The expected time to complete the upgrade is displayed by the wizard. This estimate is based on the assumption
that it takes three hours to complete an upgrade for a database with 50,000 objects (users, contacts, and groups).
If the number of objects in your database is less than 50,000, then Azure AD Connect recommends an in-place
upgrade. If you decide to continue, your current settings are automatically applied during upgrade and your
server automatically resumes active synchronization.
If you want to do a configuration migration and do a parallel deployment, then you can override the in-place
upgrade recommendation. You might for example take the opportunity to refresh the hardware and operating
system. For more information, see the parallel deployment section.
Parallel deployment
If you have more than 50,000 objects, then a parallel deployment is recommended. This deployment avoids any
operational delays experienced by your users. The Azure AD Connect installation attempts to estimate the
downtime for the upgrade, but if you've upgraded DirSync in the past, your own experience is likely to be the best
guide.
Supported DirSync configurations to be upgraded
The following configuration changes are supported with upgraded DirSync:
Domain and OU filtering
Alternate ID (UPN)
Password sync and Exchange hybrid settings
Your forest/domain and Azure AD settings
Filtering based on user attributes
The following change cannot be upgraded. If you have this configuration, the upgrade is blocked:
Unsupported DirSync changes, for example removed attributes and using a custom extension DLL
In those cases, the recommendation is to install a new Azure AD Connect server in staging mode and verify the
old DirSync and new Azure AD Connect configuration. Reapply any changes using custom configuration, as
described in Azure AD Connect Sync custom configuration.
The passwords used by DirSync for the service accounts cannot be retrieved and are not migrated. These
passwords are reset during the upgrade.
High-level steps for upgrading from DirSync to Azure AD Connect
1. Welcome to Azure AD Connect
2. Analysis of current DirSync configuration
3. Collect Azure AD global admin password
4. Collect credentials for an enterprise admin account (only used during the installation of Azure AD Connect)
5. Installation of Azure AD Connect
Uninstall DirSync (or temporarily disable it)
Optionally begin synchronization
Additional steps are required when:
You're currently using Full SQL Server - local or remote
You have more than 50,000 objects in scope for synchronization
In-place upgrade
1. Launch the Azure AD Connect installer (MSI).
2. Review and agree to license terms and privacy notice.
3. Click next to begin analysis of your existing DirSync installation.

4. When the analysis completes, you see the recommendations on how to proceed.
If you use SQL Server Express and have less than 50,000 objects, the following screen is shown:
If you use a full SQL Server for DirSync, you see this page instead:
The information regarding the existing SQL Server database server being used by DirSync is displayed.
Make appropriate adjustments if needed. Click Next to continue the installation.
If you have more than 50,000 objects, you see this screen instead:
To proceed with an in-place upgrade, click the checkbox next to this message: Continue upgrading
DirSync on this computer. To do a parallel deployment instead, you export the DirSync configuration
settings and move the configuration to the new server.
5. Provide the password for the account you currently use to connect to Azure AD. This must be the account
currently used by DirSync.
If you receive an error and have problems with connectivity, see Troubleshoot connectivity problems.
6. Provide an enterprise admin account for Active Directory.
7. You're now ready to configure. When you click Upgrade, DirSync is uninstalled and Azure AD Connect is
configured and begins synchronizing.
8. After the installation has completed, sign out and sign in again to Windows before you use Synchronization
Service Manager, Synchronization Rule Editor, or try to make any other configuration changes.
Parallel deployment
Export the DirSync configuration
Parallel deployment with more than 50,000 objects
If you have more than 50,000 objects, then the Azure AD Connect installation recommends a parallel deployment.
A screen similar to the following is displayed:
If you want to proceed with parallel deployment, you need to perform the following steps:
Click the Export settings button. When you install Azure AD Connect on a separate server, these settings are
migrated from your current DirSync to your new Azure AD Connect installation.
Once your settings have been successfully exported, you can exit the Azure AD Connect wizard on the DirSync
server. Continue with the next step to install Azure AD Connect on a separate server
Parallel deployment with less than 50,000 objects
If you have less than 50,000 objects but still want to do a parallel deployment, then do the following:
1. Run the Azure AD Connect installer (MSI).
2. When you see the Welcome to Azure AD Connect screen, exit the installation wizard by clicking the "X" in
the top right corner of the window.
3. Open a command prompt.
4. From the install location of Azure AD Connect (Default: C:\Program Files\Microsoft Azure Active Directory
Connect) execute the following command: AzureADConnect.exe /ForceExport .
5. Click the Export settings button. When you install Azure AD Connect on a separate server, these settings are
migrated from your current DirSync to your new Azure AD Connect installation.
Once your settings have been successfully exported, you can exit the Azure AD Connect wizard on the DirSync
server. Continue with the next step to install Azure AD Connect on a separate server.
Install Azure AD Connect on separate server
When you install Azure AD Connect on a new server, the assumption is that you want to perform a clean install of
Azure AD Connect. Since you want to use the DirSync configuration, there are some extra steps to take:
1. Run the Azure AD Connect installer (MSI).
2. When you see the Welcome to Azure AD Connect screen, exit the installation wizard by clicking the "X" in
the top right corner of the window.
3. Open a command prompt.
4. From the install location of Azure AD Connect (Default: C:\Program Files\Microsoft Azure Active Directory
Connect) execute the following command: AzureADConnect.exe /migrate . The Azure AD Connect installation
wizard starts and presents you with the following screen:
5. Select the settings file that exported from your DirSync installation.
6. Configure any advanced options including:
A custom installation location for Azure AD Connect.
An existing instance of SQL Server (Default: Azure AD Connect installs SQL Server 2012 Express). Do not
use the same database instance as your DirSync server.
A service account used to connect to SQL Server (If your SQL Server database is remote then this
account must be a domain service account). These options can be seen on this screen:
7. Click Next.
8. On the Ready to configure page, leave the Start the synchronization process as soon as the
configuration completes checked. The server is now in staging mode so changes are not exported to Azure
AD.
9. Click Install.
10. After the installation has completed, sign out and sign in again to Windows before you use Synchronization
Service Manager, Synchronization Rule Editor, or try to make any other configuration changes.
NOTE
Synchronization between Windows Server Active Directory and Azure Active Directory begins, but no changes are exported
to Azure AD. Only one synchronization tool can be actively exporting changes at a time. This state is called staging mode.
Verify that Azure AD Connect is ready to begin synchronization

To verify that Azure AD Connect is ready to take over from DirSync, you need to open Synchronization Service
Manager in the group Azure AD Connect from the start menu.
In the application, go to the Operations tab. On this tab, confirm that the following operations have completed:
Import on the AD Connector
Import on the Azure AD Connector
Full Sync on the AD Connector
Full Sync on the Azure AD Connector
Review the result from these operations and ensure there are no errors.
If you want to see and inspect the changes that are about to be exported to Azure AD, then read how to verify the
configuration under staging mode. Make required configuration changes until you do not see anything
unexpected.
You are ready to switch from DirSync to Azure AD when you have completed these steps and are happy with the
result.
Uninstall DirSync (old server)
In Programs and features find Windows Azure Active Directory sync tool
Uninstall Windows Azure Active Directory sync tool
The uninstallation might take up to 15 minutes to complete.
If you prefer to uninstall DirSync later, you can also temporarily shut down the server or disable the service. If
something goes wrong, this method allows you to re-enable it. However, it is not expected that the next step will
fail so this should not be needed.
With DirSync uninstalled or disabled, there is no active server exporting to Azure AD. The next step to enable
Azure AD Connect must be completed before any changes in your on-premises Active Directory will continue to
be synchronized to Azure AD.
Enable Azure AD Connect (new server)
After installation, reopening Azure AD connect will allow you to make additional configuration changes. Start
Azure AD Connect from the start menu or from the shortcut on the desktop. Make sure you do not try to run the
installation MSI again.
You should see the following:
Select Configure staging mode.

Turn off staging by unchecking the Enabled staging mode checkbox.
Click the Next button

On the confirmation page, click the install button.
Azure AD Connect is now your active server and you must not switch back to using your existing DirSync server.
Next steps
Learn more about these new features, which were enabled with the installation: Automatic upgrade, Prevent
accidental deletes, and Azure AD Connect Health.
Azure AD Connect: Upgrade from a previous version
to the latest
This topic describes the different methods you can use to upgrade your Azure AD Connect installation to the latest
release. We recommend that you keep yourself current with the releases of Azure AD Connect. The steps described
in swing migration are also used when you make a substantial configuration change.
If you want to upgrade from DirSync, see Upgrade from Azure AD sync tool (DirSync) instead.
There are a few different strategies to upgrade Azure AD Connect.
METHOD DESCRIPTION
Automatic upgrade For customers with an express installation, this is the easiest
method.
In-place upgrade If you have a single server, upgrade the installation in-place
on the same server.
Swing migration With two servers, you can prepare one of the servers with the
new release or configuration and change active server when
you are ready.
For required permissions, see permissions required for upgrade.
NOTE
Once you have enabled your new Azure AD Connect server to start synchronizing changes to Azure AD, you must not roll
back to using DirSync or Azure AD Sync. Downgrading from Azure AD Connect to legacy clients including DirSync and Azure
AD Sync is not supported and can lead to issues such as data loss in Azure AD.
In-place upgrade
An in-place upgrade works for moving from Azure AD Sync or Azure AD Connect. It will not work for DirSync or
for a solution with FIM + Azure AD Connector.
This method is preferred when you have a single server and less than about 100,000 objects. If there are any
changes to the out-of-box sync rules, a full import and full synchronization occur after the upgrade. This ensures
that the new configuration is applied to all existing objects in the system. This might take a few hours depending
on the number of objects in scope of the sync engine. The normal delta synchronization scheduler, by default every
30 minutes, is suspended but password synchronization continues. You might consider to do the in-place upgrade
during a weekend. If there are no changes to the out-of-box configuration with the new Azure AD Connect release,
then a normal delta import/sync will start instead.
If you have made changes to out-of-box synchronization rules, these will be set back to default configuration on
upgrade. To make sure your configuration is kept between upgrades, make sure the changes are made as
described in Best practices for changing the default configuration.
Swing migration
If you have a complex deployment or very many objects, it might be impractical to do an in-place upgrade on the
live system. This could for some customers take multiple days and during this time no delta changes will be
processed. This method is also used when you plan to make substantial changes to your configuration and you
want to try them out before these are pushed to the cloud.
The recommended method for these scenarios is to use a swing migration. You need (at least) two servers, one
active and one staging server. The active server (solid blue lines in the picture below) is responsible for the active
production load. The staging server (dashed purple lines in the picture below) is prepared with the new release or
configuration and when fully ready, this server is made active. The previous active server, now with the old version
or configuration installed, is made the staging server and upgraded.
The two servers can use different versions. For example, the active server you plan to decommission can use Azure
AD Sync and the new staging server can use Azure AD Connect. If you use swing migration to develop a new
configuration it is a good idea to have the same versions on the two servers.
Note: It has been noted that some customers prefer to have three or four servers for this scenario. When the
staging server is upgraded, you do not have a backup server in case of a disaster recovery. With three or four
servers, one set of primary/standby servers with the new version can be prepared, ensuring there are always a
staging server ready to take over.
These steps also works to move from Azure AD Sync or a solution with FIM + Azure AD Connector. These steps do
not work for DirSync, but the same swing migration (also called parallel deployment) method with steps for
DirSync can be found in Upgrade Azure Active Directory sync (DirSync).
Swing migration steps
1. If you use Azure AD Connect on both servers and plan to only do a configuration change, make sure your active
server and staging server are both using the same version. That makes it easier to compare differences later. If
you are upgrading from Azure AD Sync, then these servers have different versions. If you are upgrading from
an older Azure AD Connect version, it is a good idea to start with the two servers using the same version, but it
is not required.
2. If you have made some custom configuration and your staging server does not have it, follow the steps under
Move custom configuration from active to staging server.
3. If you are upgrading from an earlier release of Azure AD Connect, upgrade the staging server to the latest
version. If you are moving from Azure AD Sync, then install Azure AD Connect on your staging server.
4. Let the sync engine run full import and full synchronization on your staging server.
5. Verify that the new configuration did not cause any unexpected changes using the steps under Verify in Verify
the configuration of a server. If something is not as expected, correct, run import and sync, and verify until the
data looks good. These steps can be found in the linked topic.
6. Switch the staging server to be the active server. This is the final step switch active server in Verify the
configuration of a server.
7. If you are upgrading Azure AD Connect, upgrade the server now in staging mode to the latest release. Follow
the same steps as before to get the data and configuration upgraded. If you upgraded from Azure AD Sync, you
can now turn off and decommission your old server.
Move custom configuration from active to staging server
If you have made configuration changes to the active server, you need to make sure the same changes are applied
to the staging server.
The custom sync rules you have created can be moved with PowerShell. Other changes must be applied the same
way on both systems and cannot be migrated.
Thing you must make sure is configured the same way on both servers:
Connection to the same forests.
Any Domain and OU filtering.
The same optional features, such as password sync and password writeback.
Move synchronization rules
To move a custom synchronization rule, do the following:
1. Open Synchronization Rules Editor on your active server.
2. Select your custom rule. Click Export. This brings up a notepad window. Save the temporary file with a PS1
extension. This makes it a PowerShell script. Copy the ps1 file to the staging server.
3. The Connector GUID is different on the staging server and must be changed. To get the GUID, start
Synchronization Rules Editor, select one of the out-of-box rules representing the same connected system,
and click Export. Replace the GUID in your PS1 file with the GUID from the staging server.
4. In a PowerShell prompt, run the PS1 file. This will create the custom synchronization rule on the staging server.
5. If you have multiple custom rules, repeat for all custom rules.
Next steps
Azure AD Connect: Design concepts
The purpose of this topic is to describe areas that must be thought through during the implementation design of
Azure AD Connect. This topic is a deep dive on certain areas and these concepts are briefly described in other
topics as well.
sourceAnchor
The sourceAnchor attribute is defined as an attribute immutable during the lifetime of an object. It uniquely
identifies an object as being the same object on-premises and in Azure AD. The attribute is also called
immutableId and the two names are used interchangeable.
The word immutable, that is "cannot be changed", is important to this topic. Since this attributes value cannot be
changed after it has been set, it is important to pick a design that supports your scenario.
The attribute is used for the following scenarios:
When a new sync engine server is built, or rebuilt after a disaster recovery scenario, this attribute links existing
objects in Azure AD with objects on-premises.
If you move from a cloud-only identity to a synchronized identity model, then this attribute allows objects to
"hard match" existing objects in Azure AD with on-premises objects.
If you use federation, then this attribute together with the userPrincipalName is used in the claim to uniquely
identify a user.
This topic only talks about sourceAnchor as it relates to users. The same rules apply to all object types, but it is only
for users this problem usually is a concern.
Selecting a good sourceAnchor attribute
The attribute value must follow the following rules:
Be less than 60 characters in length
Characters not being a-z, A-Z, or 0-9 are encoded and counted as 3 characters
Not contain a special character: \ ! # $ % & * + / = ? ^ ` { } | ~ < > ( ) ' ; : , [ ] " @ _
Must be globally unique
Must be either a string, integer, or binary
Should not be based on user's name, these changes
Should not be case-sensitive and avoid values that may vary by case
Should be assigned when the object is created
If the selected sourceAnchor is not of type string, then Azure AD Connect Base64Encode the attribute value to
ensure no special characters appear. If you use another federation server than ADFS, make sure your server can
also Base64Encode the attribute.
The sourceAnchor attribute is case-sensitive. A value of JohnDoe is not the same as johndoe. But you should
not have two different objects with only a difference in case.
If you have a single forest on-premises, then the attribute you should use is objectGUID. This is also the attribute
used when you use express settings in Azure AD Connect and also the attribute used by DirSync.
If you have multiple forests and do not move users between forests and domains, then objectGUID is a good
attribute to use even in this case.
If you move users between forests and domains, then you must find an attribute that does not change or can be
moved with the users during the move. A recommended approach is to introduce a synthetic attribute. An attribute
that could hold something that looks like a GUID would be suitable. During object creation, a new GUID is created
and stamped on the user. A custom sync rule can be created in the sync engine server to create this value based on
the objectGUID and update the selected attribute in ADDS. When you move the object, make sure to also copy the
content of this value.
Another solution is to pick an existing attribute you know does not change. Commonly used attributes include
employeeID. If you consider an attribute that contains letters, make sure there is no chance the case (upper case
vs. lower case) can change for the attribute's value. Bad attributes that should not be used include those attributes
with the name of the user. In a marriage or divorce, the name is expected to change, which is not allowed for this
attribute. This is also one reason why attributes such as userPrincipalName, mail, and targetAddress are not
even possible to select in the Azure AD Connect installation wizard. Those attributes also contain the "@" character,
which is not allowed in the sourceAnchor.
Changing the sourceAnchor attribute
The sourceAnchor attribute value cannot be changed after the object has been created in Azure AD and the identity
is synchronized.
For this reason, the following restrictions apply to Azure AD Connect:
The sourceAnchor attribute can only be set during initial installation. If you rerun the installation wizard, this
option is read-only. If you need to change this setting, then you must uninstall and reinstall.
If you install another Azure AD Connect server, then you must select the same sourceAnchor attribute as
previously used. If you have earlier been using DirSync and move to Azure AD Connect, then you must use
objectGUID since that is the attribute used by DirSync.
If the value for sourceAnchor is changed after the object has been exported to Azure AD, then Azure AD
Connect sync throws an error and does not allow any more changes on that object before the issue has been
fixed and the sourceAnchor is changed back in the source directory.
Azure AD sign-in
While integrating your on-premises directory with Azure AD, it is important to understand how the
synchronization settings can affect the way user authenticates. Azure AD uses userPrincipalName (UPN) to
authenticate the user. However, when you synchronize your users, you must choose the attribute to be used for
value of userPrincipalName carefully.
Choosing the attribute for userPrincipalName
When you are selecting the attribute for providing the value of UPN to be used in Azure one should ensure
The attribute values conform to the UPN syntax (RFC 822), that is it should be of the format username@domain
The suffix in the values matches to one of the verified custom domains in Azure AD
In express settings, the assumed choice for the attribute is userPrincipalName. If the userPrincipalName attribute
does not contain the value you want your users to sign in to Azure, then you must choose Custom Installation.
Custom domain state and UPN
It is important to ensure that there is a verified domain for the UPN suffix.
John is a user in contoso.com. You want John to use the on-premises UPN john@contoso.com to sign in to Azure
after you have synced users to your Azure AD directory contoso.onmicrosoft.com. To do so, you need to add and
verify contoso.com as a custom domain in Azure AD before you can start syncing the users. If the UPN suffix of
John, for example contoso.com, does not match a verified domain in Azure AD, then Azure AD replaces the UPN
suffix with contoso.onmicrosoft.com.
Non-routable on-premises domains and UPN for Azure AD
Some organizations have non-routable domains, like contoso.local, or simple single label domains like contoso.
You are not able to verify a non-routable domain in Azure AD. Azure AD Connect can sync to only a verified
domain in Azure AD. When you create an Azure AD directory, it creates a routable domain that becomes default
domain for your Azure AD for example, contoso.onmicrosoft.com. Therefore, it becomes necessary to verify any
other routable domain in such a scenario in case you don't want to sync to the default onmicrosoft.com domain.
Read Add your custom domain name to Azure Active Directory for more info on adding and verifying domains.
Azure AD Connect detects if you are running in a non-routable domain environment and would appropriately
warn you from going ahead with express settings. If you are operating in a non-routable domain, then it is likely
that the UPN of the users have non-routable suffixes too. For example, if you are running under contoso.local,
Azure AD Connect suggests you to use custom settings rather than using express settings. Using custom settings,
you are able to specify the attribute that should be used as UPN to sign in to Azure after the users are synced to
Azure AD.
Next steps
Topologies for Azure AD Connect
This article describes various on-premises and Azure Active Directory (Azure AD) topologies that use Azure AD
Connect sync as the key integration solution. This article includes both supported and unsupported configurations.
Here's the legend for pictures in the article:
DESCRIPTION SYMBOL
On-premises Active Directory forest
On-premises Active Directory with filtered import
Azure AD Connect sync server
Azure AD Connect sync server staging mode
GALSync with Forefront Identity Manager (FIM) 2010 or

Microsoft Identity Manager (MIM) 2016
Azure AD Connect sync server, detailed
Azure AD
Unsupported scenario
Single forest, single Azure AD tenant
The most common topology is a single on-premises forest, with one or multiple domains, and a single Azure AD
tenant. For Azure AD authentication, password synchronization is used. The express installation of Azure AD
Connect supports only this topology.
Single forest, multiple sync servers to one Azure AD tenant
Having multiple Azure AD Connect sync servers connected to the same Azure AD tenant is not supported, except
for a staging server. It's unsupported even if these servers are configured to synchronize with a mutually exclusive
set of objects. You might have considered this topology if you can't reach all domains in the forest from a single
server, or if you want to distribute load across several servers.
Multiple forests, single Azure AD tenant
Many organizations have environments with multiple on-premises Active Directory forests. There are various
reasons for having more than one on-premises Active Directory forest. Typical examples are designs with account-
resource forests and the result of a merger or acquisition.
When you have multiple forests, all forests must be reachable by a single Azure AD Connect sync server. You don't
have to join the server to a domain. If necessary to reach all forests, you can place the server in a perimeter
network (also known as DMZ, demilitarized zone, and screened subnet).
The Azure AD Connect installation wizard offers several options to consolidate users who are represented in
multiple forests. The goal is that a user is represented only once in Azure AD. There are some common topologies
that you can configure in the custom installation path in the installation wizard. On the Uniquely identifying
your users page, select the corresponding option that represents your topology. The consolidation is configured
only for users. Duplicated groups are not consolidated with the default configuration.
Common topologies are discussed in the sections about separate topologies, full mesh, and the account-resource
topology.
The default configuration in Azure AD Connect sync assumes:
Each user has only one enabled account, and the forest where this account is located is used to authenticate the
user. This assumption is for both password sync and federation. UserPrincipalName and
sourceAnchor/immutableID come from this forest.
Each user has only one mailbox.
The forest that hosts the mailbox for a user has the best data quality for attributes visible in the Exchange
Global Address List (GAL). If there's no mailbox for the user, any forest can be used to contribute these attribute
values.
If you have a linked mailbox, there's also an account in a different forest used for sign-in.
If your environment does not match these assumptions, the following things happen:
If you have more than one active account or more than one mailbox, the sync engine picks one and ignores the
other.
A linked mailbox with no other active account is not exported to Azure AD. The user account is not represented
as a member in any group. A linked mailbox in DirSync is always represented as a normal mailbox. This change
is intentionally a different behavior to better support multiple-forest scenarios.
You can find more details in Understanding the default configuration.
Multiple forests, multiple sync servers to one Azure AD tenant
Having more than one Azure AD Connect sync server connected to a single Azure AD tenant is not supported. The
exception is the use of a staging server.
Multiple forests, separate topologies
In this environment, all on-premises forests are treated as separate entities. No user is present in any other forest.
Each forest has its own Exchange organization, and there's no GALSync between the forests. This topology might
be the situation after a merger/acquisition or in an organization where each business unit operates independently.
These forests are in the same organization in Azure AD and appear with a unified GAL. In the preceding picture,
each object in every forest is represented once in the metaverse and aggregated in the target Azure AD tenant.
Multiple forests: match users
Common to all these scenarios is that distribution and security groups can contain a mix of users, contacts, and
Foreign Security Principals (FSPs). FSPs are used in Active Directory Domain Services (AD DS) to represent
members from other forests in a security group. All FSPs are resolved to the real object in Azure AD.
Multiple forests: full mesh with optional GALSync
A full mesh topology allows users and resources to be located in any forest. Commonly, there are two-way trusts
between the forests.
If Exchange is present in more than one forest, there might be (optionally) an on-premises GALSync solution. Every
user is then represented as a contact in all other forests. GALSync is commonly implemented through FIM 2010 or
MIM 2016. Azure AD Connect cannot be used for on-premises GALSync.
In this scenario, identity objects are joined via the mail attribute. A user who has a mailbox in one forest is joined
with the contacts in the other forests.
Multiple forests: account-resource forest
In an account-resource forest topology, you have one or more account forests with active user accounts. You also
have one or more resource forests with disabled accounts.
In this scenario, one (or more) resource forest trusts all account forests. The resource forest typically has an
extended Active Directory schema with Exchange and Lync. All Exchange and Lync services, along with other
shared services, are located in this forest. Users have a disabled user account in this forest, and the mailbox is
linked to the account forest.
Office 365 and topology considerations

Some Office 365 workloads have certain restrictions on supported topologies:
WORKLOAD RESTRICTIONS
WORKLOAD RESTRICTIONS
Exchange Online If there's more than one on-premises Exchange organization

(that is, Exchange has been deployed to more than one
forest), you must use Exchange 2013 SP1 or later. For more
information, see Hybrid deployments with multiple Active
Directory forests.
Skype for Business When you're using multiple on-premises forests, only the
account-resource forest topology is supported. For more
information, see Environmental requirements for Skype for
Business Server 2015.
Staging server
Azure AD Connect supports installing a second server in staging mode. A server in this mode reads data from all
connected directories but does not write anything to connected directories. It uses the normal synchronization
cycle and therefore has an updated copy of the identity data.
In a disaster where the primary server fails, you can fail over to the staging server. You do this in the Azure AD
Connect wizard. This second server can be located in a different datacenter because no infrastructure is shared
with the primary server. You must manually copy any configuration change made on the primary server to the
second server.
You can use a staging server to test a new custom configuration and the effect that it has on your data. You can
preview the changes and adjust the configuration. When you're happy with the new configuration, you can make
the staging server the active server and set the old active server to staging mode.
You can also use this method to replace the active sync server. Prepare the new server and set it to staging mode.
Make sure it's in a good state, disable staging mode (making it active), and shut down the currently active server.
It's possible to have more than one staging server when you want to have multiple backups in different
datacenters.
Multiple Azure AD tenants

We recommend having a single tenant in Azure AD for an organization. Before you plan to use multiple Azure AD
tenants, see the article Administrative units management in Azure AD. It covers common scenarios where you can
use a single tenant.
There's a 1:1 relationship between an Azure AD Connect sync server and an Azure AD tenant. For each Azure AD
tenant, you need one Azure AD Connect sync server installation. The Azure AD tenant instances are isolated by
design. That is, users in one tenant can't see users in the other tenant. If you want this separation, this is a
supported configuration. Otherwise, you should use the single Azure AD tenant model.
Each object only once in an Azure AD tenant
In this topology, one Azure AD Connect sync server is connected to each Azure AD tenant. The Azure AD Connect
sync servers must be configured for filtering so that each has a mutually exclusive set of objects to operate on. You
can, for example, scope each server to a particular domain or organizational unit.
A DNS domain can be registered in only a single Azure AD tenant. The UPNs of the users in the on-premises Active
Directory instance must also use separate namespaces. For example, in the preceding picture, three separate UPN
suffixes are registered in the on-premises Active Directory instance: contoso.com, fabrikam.com, and
wingtiptoys.com. The users in each on-premises Active Directory domain use a different namespace.
There is no GALSync between the Azure AD tenant instances. The address book in Exchange Online and Skype for
Business shows only users in the same tenant.
This topology has the following restrictions on otherwise supported scenarios:
Only one of the Azure AD tenants can enable an Exchange hybrid with the on-premises Active Directory
instance.
Windows 10 devices can be associated with only one Azure AD tenant.
The single sign-on (SSO) option for password synchronization and pass-through authentication can be used
with only one Azure AD tenant.
The requirement for a mutually exclusive set of objects also applies to writeback. Some writeback features are not
supported with this topology because they assume a single on-premises configuration. These features include:
Group writeback with default configuration.
Device writeback.
Each object multiple times in an Azure AD tenant
These tasks are unsupported:
Sync the same user to multiple Azure AD tenants.
Make a configuration change so that users in one Azure AD tenant appear as contacts in another Azure AD
tenant.
Modify Azure AD Connect sync to connect to multiple Azure AD tenants.
GALSync by using writeback
Azure AD tenants are isolated by design. These tasks are unsupported:

Change the configuration of Azure AD Connect sync to read data from another Azure AD tenant.
Export users as contacts to another on-premises Active Directory instance by using Azure AD Connect sync.
GALSync with on-premises sync server
You can use FIM 2010 or MIM 2016 on-premises to sync users (via GALSync) between two Exchange
organizations. The users in one organization appear as foreign users/contacts in the other organization. These
different on-premises Active Directory instances can then be synchronized with their own Azure AD tenants.
Next steps
To learn how to install Azure AD Connect for these scenarios, see Custom installation of Azure AD Connect.
Learn more about integrating your on-premises identities with Azure Active Directory.
Azure AD Connect: Special considerations for
instances
Azure AD Connect is most commonly used with the world-wide instance of Azure AD and Office 365. But there are
also other instances and these have different requirements for URLs and other special considerations.
Microsoft Cloud Germany

The Microsoft Cloud Germany is a sovereign cloud operated by a German data trustee.
URLS TO OPEN IN PROXY SERVER
*.microsoftonline.de
*.windows.net
+Certificate Revocation Lists
When you sign in to your Azure AD tenant, you must use an account in the onmicrosoft.de domain.
Features currently not present in the Microsoft Cloud Germany:
Azure AD Connect Health is not available.
Automatic updates is not available.
Password writeback is not available.
Other Azure AD Premium services are not available.
Microsoft Azure Government cloud

The Microsoft Azure Government cloud is a cloud for US government.
This cloud has been supported by earlier releases of DirSync. From build 1.1.180 of Azure AD Connect, the next
generation of the cloud is supported. This generation is using US-only based endpoints and have a different list of
URLs to open in your proxy server.
URLS TO OPEN IN PROXY SERVER
*.microsoftonline.com
*.gov.us.microsoftonline.com
+Certificate Revocation Lists
Azure AD Connect is not able to automatically detect that your Azure AD tenant is located in the Government cloud.
Instead you need to take the following actions when you install Azure AD Connect.
1. Start the Azure AD Connect installation.
2. When you see the first page where you are supposed to accept the EULA, do not continue but leave the
installation wizard running.
3. Start regedit and change the registry key HKLM\SOFTWARE\Microsoft\Azure AD Connect\AzureInstance to the value
2 .
4. Go back to the Azure AD Connect installation wizard, accept the EULA, and continue. During installation, make
sure to use the custom configuration installation path (and not Express installation). Then continue the
installation as usual.
Features currently not present in the Microsoft Azure Government cloud:
Azure AD Connect Health is not available.
Automatic updates is not available.
Password writeback is not available.
Other Azure AD Premium services are not available.
Next steps
Next steps and how to manage Azure AD Connect
The following are advanced operational topics that allow you to customize Azure Active Directory Connect to
meet your organization's needs and requirements.
Add additional sync administrators

By default only the user who did the installation and local administrators will be able to manage the installed sync
engine. For additional people to be able to access and manage the sync engine, locate the group named
ADSyncAdmins on the local server and add them to this group.
Assigning licenses to Azure AD Premium and Enterprise Mobility users

Now that your users have been synchronized to the cloud, you will need to assign them a license so they can get
going with cloud apps such as Office 365.
To assign an Azure AD Premium or Enterprise Mobility Suite License
1. Sign-in to the Azure Portal as an Administrator.
2. On the left, select Active Directory.
3. On the Active Directory page, double-click on the directory that has the users you wish to enable.
4. At the top of the directory page, select Licenses.
5. On the Licenses page, select Active Directory Premium or Enterprise Mobility Suite, and then click Assign.
6. In the dialog box, select the users you want to assign licenses to, and then click the check mark icon to save the
changes.
Verifying the scheduled synchronization task

If you want to check on the status of a synchronization you can do this by checking in the Azure portal.
To verify the scheduled synchronization task
1. Sign-in to the Azure Portal as an Administrator.
2. On the left, select Active Directory.
3. On the Active Directory page, double-click on the directory that has the users you wish to enable.
4. At the top of the directory page, select Directory Integration.
5. Under integration with local active directory note the last sync time.
Starting a scheduled synchronization task

If you need to run a synchronization task you can do this by running through the Azure AD Connect wizard again.
You will need to provide your Azure AD credentials. In the wizard, select the Customize synchronization
options task and click next through the wizard. At the end, ensure that the Start the synchronization process
as soon as the initial configuration completes box is checked.
For more information on the Azure AD Connect sync: Scheduler, see Azure AD Connect Scheduler
Additional tasks available in Azure AD Connect

After your initial installation of Azure AD Connect, you can always start the wizard again from the Azure AD
Connect start page or desktop shortcut. You will notice that going through the wizard again provides some new
options in the form of Additional tasks.
The following table provides a summary of these tasks and a brief description on each of them.
ADDITIONAL TASK DESCRIPTION
View the selected scenario Allows you to view your current Azure AD Connect solution.
This includes general settings, synchronized directories, synch
settings, etc.
Customize Synchronization options Allows you to change the current configuration including
adding additional Active Directory forests to the configuration
or enabling sync options such as user, group, device or
password write-back.
Enable Staging Mode This allows you to stage information that will later be
synchronized but nothing will be exported to Azure AD or
Active Directory. This allows you to preview the
synchronizations before they occur.
Next steps
Renew federation certificates for Office 365 and
Azure Active Directory
Overview
For successful federation between Azure Active Directory (Azure AD) and Active Directory Federation Services (AD
FS), the certificates used by AD FS to sign security tokens to Azure AD should match what is configured in Azure
AD. Any mismatch can lead to broken trust. Azure AD ensures that this information is kept in sync when you
deploy AD FS and Web Application Proxy (for extranet access).
This article provides you additional information to manage your token signing certificates and keep them in sync
with Azure AD, in the following cases:
You are not deploying the Web Application Proxy, and therefore the federation metadata is not available in the
extranet.
You are not using the default configuration of AD FS for token signing certificates.
You are using a third-party identity provider.
Default configuration of AD FS for token signing certificates

The token signing and token decrypting certificates are usually self-signed certificates, and are good for one year.
By default, AD FS includes an auto-renewal process called AutoCertificateRollover. If you are using AD FS 2.0 or
later, Office 365 and Azure AD automatically update your certificate before it expires.
Renewal notification from the Office 365 portal or an email
NOTE
If you received an email or a portal notification asking you to renew your certificate for Office, see Managing changes to
token signing certificates to check if you need to take any action. Microsoft is aware of a possible issue that can lead to
notifications for certificate renewal being sent, even when no action is required.
Azure AD attempts to monitor the federation metadata, and update the token signing certificates as indicated by
this metadata. 30 days before the expiration of the token signing certificates, Azure AD checks if new certificates
are available by polling the federation metadata.
If it can successfully poll the federation metadata and retrieve the new certificates, no email notification or
warning in the Office 365 portal is issued to the user.
If it cannot retrieve the new token signing certificates, either because the federation metadata is not reachable
or automatic certificate rollover is not enabled, Azure AD issues an email notification and a warning in the
Office 365 portal.
IMPORTANT
If you are using AD FS, to ensure business continuity, please verify that your servers have the following updates so that
authentication failures for known issues do not occur. This mitigates known AD FS proxy server issues for this renewal and
future renewal periods:
Server 2012 R2 - Windows Server May 2014 rollup
Server 2008 R2 and 2012 - Authentication through proxy fails in Windows Server 2012 or Windows 2008 R2 SP1
Check if the certificates need to be updated

Step 1: Check the AutoCertificateRollover state
On your AD FS server, open PowerShell. Check that the AutoCertificateRollover value is set to True.
Get-Adfsproperties
NOTE
If you are using AD FS 2.0, first run Add-Pssnapin Microsoft.Adfs.Powershell.
Step 2: Confirm that AD FS and Azure AD are in sync

On your AD FS server, open the Azure AD PowerShell prompt, and connect to Azure AD.
NOTE
You can download Azure AD PowerShell here.
Connect-MsolService
Check the certificates configured in AD FS and Azure AD trust properties for the specified domain.
Get-MsolFederationProperty -DomainName <domain.name> | FL Source, TokenSigningCertificate

If the thumbprints in both the outputs match, your certificates are in sync with Azure AD.
Step 3: Check if your certificate is about to expire
In the output of either Get-MsolFederationProperty or Get-AdfsCertificate, check for the date under "Not After." If
the date is less than 30 days away, you should take action.
FEDERATION
AUTOCERTIFICATEROLL CERTIFICATES IN SYNC METADATA IS PUBLICLY
OVER WITH AZURE AD ACCESSIBLE VALIDITY ACTION
Yes Yes Yes - No action needed. See

Renew token signing
certificate
automatically.
Yes No - Less than 15 days Renew immediately.

See Renew token
signing certificate
manually.
No - - Less than 30 days Renew immediately.

See Renew token
signing certificate
manually.
[-] Does not matter
Renew the token signing certificate automatically (recommended)

You don't need to perform any manual steps if both of the following are true:
You have deployed Web Application Proxy, which can enable access to the federation metadata from the
extranet.
You are using the AD FS default configuration (AutoCertificateRollover is enabled).
Check the following to confirm that the certificate can be automatically updated.
1. The AD FS property AutoCertificateRollover must be set to True. This indicates that AD FS will
automatically generate new token signing and token decryption certificates, before the old ones expire.
2. The AD FS federation metadata is publicly accessible. Check that your federation metadata is publicly
accessible by navigating to the following URL from a computer on the public internet (off of the corporate
network):
https://(your_FS_name)/federationmetadata/2007-06/federationmetadata.xml
where (your_FS_name) is replaced with the federation service host name your organization uses, such as
fs.contoso.com. If you are able to verify both of these settings successfully, you do not have to do anything else.
Example: https://fs.contoso.com/federationmetadata/2007-06/federationmetadata.xml
Renew the token signing certificate manually

You may choose to renew the token signing certificates manually. For example, the following scenarios might
work better for manual renewal:
Token signing certificates are not self-signed certificates. The most common reason for this is that your
organization manages AD FS certificates enrolled from an organizational certificate authority.
Network security does not allow the federation metadata to be publicly available.
In these scenarios, every time you update the token signing certificates, you must also update your Office 365
domain by using the PowerShell command, Update-MsolFederatedDomain.
Step 1: Ensure that AD FS has new token signing certificates
Non-default configuration
If you are using a non-default configuration of AD FS (where AutoCertificateRollover is set to False), you are
probably using custom certificates (not self-signed). For more information about how to renew the AD FS token
signing certificates, see Guidance for customers not using AD FS self-signed certificates.
Federation metadata is not publicly available
On the other hand, if AutoCertificateRollover is set to True, but your federation metadata is not publicly
accessible, first make sure that new token signing certificates have been generated by AD FS. Confirm you have
new token signing certificates by taking the following steps:
1. Verify that you are logged on to the primary AD FS server.
2. Check the current signing certificates in AD FS by opening a PowerShell command window, and running
the following command:
PS C:>Get-ADFSCertificate CertificateType token-signing
NOTE
If you are using AD FS 2.0, you should run Add-Pssnapin Microsoft.Adfs.Powershell first.
3. Look at the command output at any certificates listed. If AD FS has generated a new certificate, you should see
two certificates in the output: one for which the IsPrimary value is True and the NotAfter date is within 5
days, and one for which IsPrimary is False and NotAfter is about a year in the future.
4. If you only see one certificate, and the NotAfter date is within 5 days, you need to generate a new certificate.
5. To generate a new certificate, execute the following command at a PowerShell command prompt:
PS C:\>Update-ADFSCertificate CertificateType token-signing .
6. Verify the update by running the following command again: PS C:>Get-ADFSCertificate CertificateType token-
signing
Two certificates should be listed now, one of which has a NotAfter date of approximately one year in the future,
and for which the IsPrimary value is False.
Step 2: Update the new token signing certificates for the Office 365 trust
Update Office 365 with the new token signing certificates to be used for the trust, as follows.
1. Open the Microsoft Azure Active Directory Module for Windows PowerShell.
2. Run $cred=Get-Credential. When this cmdlet prompts you for credentials, type your cloud service
administrator account credentials.
3. Run Connect-MsolService Credential $cred. This cmdlet connects you to the cloud service. Creating a context
that connects you to the cloud service is required before running any of the additional cmdlets installed by the
tool.
4. If you are running these commands on a computer that is not the AD FS primary federation server, run Set-
MSOLAdfscontext -Computer , where is the internal FQDN name of the primary AD FS server. This cmdlet
creates a context that connects you to AD FS.
5. Run Update-MSOLFederatedDomain DomainName . This cmdlet updates the settings from AD FS into the
cloud service, and configures the trust relationship between the two.
NOTE
If you need to support multiple top-level domains, such as contoso.com and fabrikam.com, you must use the
SupportMultipleDomain switch with any cmdlets. For more information, see Support for Multiple Top Level Domains.
Repair Azure AD trust by using Azure AD Connect

If you configured your AD FS farm and Azure AD trust by using Azure AD Connect, you can use Azure AD Connect
to detect if you need to take any action for your token signing certificates. If you need to renew the certificates, you
can use Azure AD Connect to do so.
For more information, see Repairing the trust.
Azure AD Connect: Enabling device writeback
NOTE
A subscription to Azure AD Premium is required for device writeback.
The following documentation provides information on how to enable the device writeback feature in Azure AD
Connect. Device Writeback is used in the following scenarios:
Enable conditional access based on devices to ADFS (2012 R2 or higher) protected applications (relying party
trusts).
This provides additional security and assurance that access to applications is granted only to trusted devices. For
more information on conditional access, see Managing Risk with Conditional Access and Setting up On-premises
Conditional Access using Azure Active Directory Device Registration.
IMPORTANT
Devices must be located in the same forest as the users. Since devices must be written back to a single forest, this feature
does not currently support a deployment with multiple user forests.
Only one device registration configuration object can be added to the on-premises Active Directory forest. This feature is not
compatible with a topology where the on-premises Active Directory is synchronized to multiple Azure AD directories.
Part 1: Install Azure AD Connect

1. Install Azure AD Connect using Custom or Express settings. Microsoft recommends to start with all users and
groups successfully synchronized before you enable device writeback.
Part 2: Prepare Active Directory

Use the following steps to prepare for using device writeback.
1. From the machine where Azure AD Connect is installed, launch PowerShell in elevated mode.
2. If the Active Directory PowerShell module is NOT installed, install it using the following command:
Install-WindowsFeature Name AD-Domain-Services IncludeManagementTools
3. If the Azure Active Directory PowerShell module is NOT installed, then download and install it from Azure
Active Directory Module for Windows PowerShell (64-bit version). This component has a dependency on the
sign-in assistant, which is installed with Azure AD Connect.
4. With enterprise admin credentials, run the following commands and then exit PowerShell.
Import-Module 'C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1'
Initialize-ADSyncDeviceWriteback {Optional:DomainName [name] Optional:-AdConnectorAccount [account]}
Enterprise admin credentials are required since changes to the configuration namespace are needed. A domain
admin will not have enough permissions.
Description:
If they do not exist already, creates and configures new containers and objects under CN=Device Registration
Configuration,CN=Services,CN=Configuration,[forest-dn].
If they do not exist already, creates and configures new containers and objects under CN=RegisteredDevices,
[domain-dn]. Device objects will be created in this container.
Sets necessary permissions on the Azure AD Connector account, to manage devices on your Active Directory.
Only needs to run on one forest, even if Azure AD Connect is being installed on multiple forests.
Parameters:
DomainName: Active Directory Domain where device objects will be created. Note: All devices for a given
Active Directory forest will be created in a single domain.
AdConnectorAccount: Active Directory account that will be used by Azure AD Connect to manage objects in
the directory. This is the account used by Azure AD Connect sync to connect to AD. If you installed using
express settings, it is the account prefixed with MSOL_.
Part 3: Enable device writeback in Azure AD Connect

Use the following procedure to enable device writeback in Azure AD Connect.
1. Run the installation wizard again. Select customize synchronization options from the Additional Tasks
page and click Next.
2. In the Optional Features page, device writeback will no longer be grayed out. Please note that if the Azure AD
Connect prep steps are not completed device writeback will be grayed out in the Optional features page.
Check the box for device writeback and click next. If the checkbox is still disabled, see the troubleshooting
section.
3. On the writeback page, you will see the supplied domain as the default Device writeback forest.
4. Complete the installation of the Wizard with no additional configuration changes. If needed, refer to Custom
installation of Azure AD Connect.
Enable conditional access

Detailed instructions to enable this scenario are available within Setting up On-premises Conditional Access using
Azure Active Directory Device Registration.
Verify Devices are synchronized to Active Directory

Device writeback should now be working properly. Be aware that it can take up to 3 hours for device objects to be
written-back to AD. To verify that your devices are being synced properly, do the following after the sync rules
complete:
1. Launch Active Directory Administrative Center.
2. Expand RegisteredDevices, within the Domain that is being federated.
3. Current registered devices will be listed there.
Troubleshooting
The writeback checkbox is still disabled
If the checkbox for device writeback is not enabled even though you have followed the steps above, the following
steps will guide you through what the installation wizard is verifying before the box is enabled.
First things first:
Make sure at least one forest has Windows Server 2012R2. The device object type must be present.
If the installation wizard is already running, then any changes will not be detected. In this case, complete the
installation wizard and run it again.
Make sure the account you provide in the initialization script is actually the correct user used by the Active
Directory Connector. To verify this, follow these steps:
From the start menu, open Synchronization Service.
Open the Connectors tab.
Find the Connector with type Active Directory Domain Services and select it.
Under Actions, select Properties.
Go to Connect to Active Directory Forest. Verify that the domain and user name specified on this
screen match the account provided to the script.
Verify configuration in Active Directory:

Verify that the Device Registration Service is located in the location below
(CN=DeviceRegistrationService,CN=Device Registration Services,CN=Device Registration
Configuration,CN=Services,CN=Configuration) under configuration naming context.
Verify there is only one configuration object by searching the configuration namespace. If there is more than
one, delete the duplicate.
On the Device Registration Service object, make sure the attribute msDS-DeviceLocation is present and has a
value. Lookup this location and make sure it is present with the objectType msDS-DeviceContainer.
Verify the account used by the Active Directory Connector has required permissions on the Registered Devices
container found by the previous step. This is the expected permissions on this container:
Verify the Active Directory account has permissions on the CN=Device Registration
Configuration,CN=Services,CN=Configuration object.
Additional Information
Managing Risk With Conditional Access
Setting up On-premises Conditional Access using Azure Active Directory Device Registration
Next steps
Azure AD Connect User Sign on options
Azure AD Connect allows your users to sign on to both cloud and on-premises resources using the same
passwords. This article describes key concepts for every identity model to help you choose the identity you want to
use for your sign-in to Azure AD.
If youre already familiar with Azure AD identity model and want to learn more about a specific method, just click
below on appropriate topic.
Password Sync with single sign on (SSO)
Pass-through authentication
Federated SSO (with ADFS)
Choosing the User sign-in method for your organization

For most organizations who just want to enable user sign on to Office 365, SaaS applications and other Azure AD
based resources, the default Password synchronization option is recommended. Some organizations, however,
have a particular reasons that they are not able to use this option and can choose either federated sign on option
such as AD FS or Pass-through authentication. The table below helps you to make the right choice.
I NEED TO PHS AND SSO PTA WITH SSO AD FS
Sync new user, contact, and x x x

group accounts created in
my on-premises Active
Directory to the cloud
automatically
Set up my tenant for Office x x x

365 hybrid scenarios
Enable my users to sign in x x x

and access cloud services
using their on-premises
password
Implement single sign-on x x x

using corporate credentials
Ensure no passwords are x* x

stored in the cloud
Enable on-premises multi- x

factor authentication
solutions
*Through a light weight connector.

NOTE
Pass-through authentication currently has some limitations with rich clients. See Pass-through authentication for more
details.
Password synchronization
With password synchronization, hashes of user passwords are synchronized from your on-premises Active
Directory to Azure AD. When passwords are changed or reset on premises, the new passwords are synchronized
immediately to Azure AD so that your users can always use the same password for cloud resources as they do on-
premises. The passwords are never sent to Azure AD nor stored in Azure AD in clear text. Password
synchronization can be used together with password write-back to enable self service password reset in Azure AD.
In addition you can also enable single sign on (SSO) for users on domain joined machines that are on the
corporate network. With single sign on, enabled users only need to enter a username to securely access cloud
resources.
More information about password synchronization

Pass-through Authentication
With pass-through authentication, the users password is validated against the on-premises Active Directory
controller and the password does not need to be present in Azure AD in any form. This allows for on-premises
policies to be evaluated during authentication to cloud services, such as logon hour restrictions. Pass-through
authentication utilizes a simple agent on a Windows Server 2012 R2 domain joined machine in the on-premises
environment, which listens for password validation requests. This agent does not require any inbound ports to be
open to the Internet.
In addition, you can also enable single sign on for users on domain joined machines that are on the corporate
network. With single sign on, enabled users only need to enter a username to securely access cloud resources.
More information on pass-through authentication and Single sign on.

Federation using a new or existing AD FS in Windows Server 2012 R2 farm
With federated sign on, your users can sign on to Azure AD based services with their on-premises passwords and,
while on the corporate network, without having to even enter their passwords. The federation option with AD FS
allows you to deploy a new or specify an existing AD FS in Windows Server 2012 R2 farm. If you choose to specify
an existing farm, Azure AD Connect will configure the trust between your farm and Azure AD so that your users
can sign on.
To deploy Federation with AD FS in Windows Server 2012 R2, you will need the following
If you are deploying a new farm:
A Windows Server 2012 R2 server for the federation server.
A Windows Server 2012 R2 server for the Web Application Proxy.
a .pfx file with one SSL certificate for your intended federation service name, such as fs.contoso.com.
If you are deploying a new farm or using an existing farm:
Local administrator credentials on your federation servers.
Local administrator credentials on any workgroup (non-domain joined) servers on which you intend to deploy
the Web Application Proxy role.
The machine on which you execute the wizard must be able to connect to any other machines on which you
want to install AD FS or Web Application Proxy via Windows Remote Management.
Configuring SSO with AD FS
Sign on using an earlier version of AD FS or a third party solution
If you have already configured cloud sign on using an earlier version of AD FS (such as AD FS 2.0) or a third party
federation provider, you can choose to skip user sign in configuration via Azure AD Connect. This will enable you
to get the latest synchronization and other capabilities of Azure AD Connect while still using your existing solution
for sign on.
Azure AD third-party federation compatibility list
User sign-in and user principal name (UPN)

Understanding user principal name
In Active Directory, the default UPN suffix is the DNS name of the domain in which the user account was created.
In most cases, this is the domain name registered as the enterprise domain on the Internet. However, you can add
more UPN suffixes using Active Directory Domains and Trusts.
The UPN of the user is of the format username@domain. For example, for an Active Directory domain named
'contoso.com', a user named John might have the UPN 'john@contoso.com'. The UPN of the user is based on RFC
822. Although UPN and email share the same format, the value of UPN for a user may or may not be equal to the
email address of the user.
User principal name in Azure AD
Azure AD Connect wizard will use the userPrincipalName attribute or let you specify the attribute (in custom
install) to be used from on-premises as the user principal name in Azure AD. This is the value that will be used for
signing in to Azure AD. If the value of the user principal name attribute does not correspond to a verified domain
in Azure AD, then Azure AD will replace it with a default .onmicrosoft.com value.
Every directory in Azure Active Directory comes with a built-in domain name in the form contoso.onmicrosoft.com
that lets you get started using Azure or other Microsoft services. You can improve and simplify sign-in experience
using custom domains. For information on custom domain names in Azure AD and how to verify a domain, please
read Add your custom domain name to Azure Active Directory
Azure AD sign-in configuration

Azure AD sign-in configuration with Azure AD Connect
Azure AD sign-in experience is dependent on whether Azure AD is able to match the user principal name suffix of a
user being synced to one of the custom domains verified in the Azure AD directory. Azure AD Connect provides
help while configuring Azure AD sign-in settings, so that user sign-in experience in cloud is similar to the on-
premises experience. Azure AD Connect lists the UPN suffixes defined for the domain(s) and tries to match them
with a custom domain in Azure AD and helps you with the appropriate action that needs to be taken. The Azure AD
sign-in page lists out the UPN suffixes defined for the on-premises Active Directory and displays the
corresponding status against each suffix. The status values can be one of the below:
STATE DESCRIPTION ACTION NEEDED
Verified Azure AD Connect found a matching No action is needed

verified domain in Azure AD. All users
for this domain can sign-in using their
on-premises credentials
Not Verified Azure AD Connect could find a Verify the custom domain in Azure AD.
matching custom domain in Azure AD Learn more
but it is not verified. UPN suffix of the
users of this domain will be changed to
default .onmicrosoft.com suffix after
sync if domain is not verified.
Not Added Azure AD Connect could not find a Add and verify a custom domain
custom domain corresponding to the corresponding to the UPN suffix Learn
UPN suffix. UPN suffix of users from this More
domain will be changed to default
.onmicrosoft.com if the domain is not
added and verifeid in Azure.
Azure AD sign-in page lists the UPN suffix(s) defined for the on-premises Active Directory and the corresponding
custom domain in Azure AD with the current verification status. In custom installation, you can now select the
attribute for user principal name on the Azure AD sign-in page.
You can click on the refresh button to re-fetch the latest status of the custom domains from Azure AD.
Selecting attribute for user principal name in Azure AD
UserPrincipalName - The attribute userPrincipalName is the attribute users will use when they sign-in to Azure AD
and Office 365. The domains used, also known as the UPN-suffix, should be verified in Azure AD before the users
are synchronized. It is strongly recommended to keep the default attribute userPrincipalName. If this attribute is
non-routable and cannot be verified then it is possible to select another attribute, for example email, as the
attribute holding the sign-in ID. This is known as Alternate ID. The Alternate ID attribute value must follow the
RFC822 standard. An Alternate ID can be used with both password Single Sign-On (SSO) and federation SSO as
the sign-in solution.
NOTE
Using an Alternate ID is not compatible with all Office 365 workloads and pass-through authentication. For more
information, please refer to Configuring Alternate Login ID.
Different custom domain states and effect on Azure sign-in experience

It is very important to understand the relationship between the custom domain states in your Azure AD directory
and the UPN suffixes defined on-premises. Let us go through the different possible Azure sign-in experiences
when you are setting up sycnhronization using Azure AD Connnect.
For the information below, let us assume that we are concerned with the UPN suffix contoso.com which is used in
the on-premises directory as part of UPN, for example user@contoso.com.
E x p re s s Se t t i n g s / P a s s w o rd Sy n c h ro n i z a t i o n
STATE EFFECT ON USER AZURE SIGN-IN EXPERIENCE

Not added In this case no custom domain for contoso.com has been
added in Azure AD directory. Users who have UPN on-
premises with suffix @contoso.com, will not be able to use
their on-premises UPN to sign-in to Azure. They will instead
have to use a new UPN provided to them by Azure AD by
adding the suffix for default Azure AD directory. For example,
if you are syncing users to Azure AD directory
azurecontoso.onmicrosoft.com then the on-premises user
user@contoso.com will be given a UPN of
user@azurecontoso.onmicrosoft.com
Not verified In this case we have a custom domain contoso.com added in

Azure AD directory, however it is not yet verified. If you go
ahead with syncing users without verifying the domain, then
the users will be assigned a new UPN by Azure AD just like it
did in the 'Not added' scenario.
Verified In this case we have a custom domain contoso.com already

added and verified in Azure AD for the UPN suffix. Users will
be able to use their on-premises user principal name, e.g.
user@contoso.com, to sign-in to Azure after they are synced
to Azure AD
A D F S F e d e ra t i o n
You cannot create a federation with the default .onmicrosoft.com domain in Azure AD, or an unverified custom
domain in Azure AD. When you are running the Azure AD Connect wizard, if you select an unverified domain to
create a federation with then Azure AD Connect will prompt you with necessary records to be created where your
DNS is hosted for the domain. For more information see here.
If you selected User sign-in option as "Federation with AD FS", then you must have a custom domain to continue
with creating a federation in Azure AD. For our discussion, this means that we should have a custom domain
contoso.com added in Azure AD directory.
Not added In this case Azure AD Connect could not find a matching
custom domain for the UPN suffix contoso.com in Azure AD
directory. You need to add a custom domain contoso.com if
you need users to sign-in using AD FS with their on-premises
UPN like user@contoso.com.
Not verified In this case Azure AD Connect will prompt you with
appropriate details on how you can verify your domain at a
later stage
Verified In this case you can go ahead with the configuration without
any further action
Changing user sign-in method

You can change the user sign-in method from Federation to Password Sync or to Pass-through authentication
using the tasks available in Azure AD Connect after the initial configuration of Azure AD Connect using the wizard.
Run the Azure AD Connect wizard again and you will be presented with a list of tasks that you can perform. Select
Change user sign-in from the list of tasks.
On the next page, you will be asked to provide the credentials for Azure AD.
On the User sign-in page, select the desired user sign-in.

NOTE
If you are making only a temporary switch to password synchronization, then check the Do not convert user accounts.
Not checking on the option will lead to conversion of each user to federated and it can take several hours.
Next steps
Learn more about Azure AD Connect: Design concepts
Multiple Domain Support for Federating with Azure
AD
The following documentation provides guidance on how to use multiple top-level domains and sub-domains
when federating with Office 365 or Azure AD domains.
Multiple top-level domain support

Federating multiple, top-level domains with Azure AD requires some additional configuration that is not required
when federating with one top-level domain.
When a domain is federated with Azure AD, several properties are set on the domain in Azure. One important one
is IssuerUri. This is a URI that is used by Azure AD to identify the domain that the token is associated with. The URI
doesnt need to resolve to anything but it must be a valid URI. By default, Azure AD sets this to the value of the
federation service identifier in your on-premises AD FS configuration.
NOTE
The federation service identifier is a URI that uniquely identifies a federation service. The federation service is an instance of
AD FS that functions as the security token service.
You can vew IssuerUri by using the PowerShell command

Get-MsolDomainFederationSettings -DomainName <your domain> .
A problem arises when we want to add more than one top-level domain. For example, let's say you have setup
federation between Azure AD and your on-premises environment. For this document I am using bmcontoso.com.
Now I have added a second, top-level domain, bmfabrikam.com.
When we attempt to convert our bmfabrikam.com domain to be federated, we receive an error. The reason for this
is, Azure AD has a constraint that does not allow the IssuerUri property to have the same value for more than one
domain.
SupportMultipleDomain Parameter
To workaround this, we need to add a different IssuerUri which can be done by using the -SupportMultipleDomain
parameter. This parameter is used with the following cmdlets:
New-MsolFederatedDomain
Convert-MsolDomaintoFederated
Update-MsolFederatedDomain
This parameter makes Azure AD configure the IssuerUri so that it is based on the name of the domain. This will be
unique across directories in Azure AD. Using the parameter allows the PowerShell command to complete
successfully.
Looking at the settings of our new bmfabrikam.com domain you can see the following:
Note that -SupportMultipleDomain does not change the other endpoints which are still configured to point to our
federation service on adfs.bmcontoso.com.
Another thing that -SupportMultipleDomain does is that it ensures that the AD FS system includes the proper
Issuer value in tokens issued for Azure AD. It does this by taking the domain portion of the users UPN and setting
this as the domain in the IssuerUri, i.e. https://{upn suffix}/adfs/services/trust.
Thus during authentication to Azure AD or Office 365, the IssuerUri element in the users token is used to locate
the domain in Azure AD. If a match cannot be found the authentication will fail.
For example, if a users UPN is bsimon@bmcontoso.com, the IssuerUri element in the token AD FS issues will be
set to http://bmcontoso.com/adfs/services/trust. This will match the Azure AD configuration, and authentication
will succeed.
The following is the customized claim rule that implements this logic:
c:[Type == "http://schemas.xmlsoap.org/claims/UPN"] => issue(Type =

"http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value = regexreplace(c.Value, ".+@(?
<domain>.+)", "http://${domain}/adfs/services/trust/"));
IMPORTANT
In order to use the -SupportMultipleDomain switch when attempting to add new or convert already added domains, you
need to have setup your federated trust to support them originally.
How to update the trust between AD FS and Azure AD

If you did not setup the federated trust between AD FS and your instance of Azure AD, you may need to re-create
this trust. This is because, when it is originally setup without the -SupportMultipleDomain parameter, the IssuerUri
is set with the default value. In the screenshot below you can see the IssuerUri is set to
https://adfs.bmcontoso.com/adfs/services/trust.
So now, if we have successfully added an new domain in the Azure AD portal and then attempt to convert it using
Convert-MsolDomaintoFederated -DomainName <your domain> , we get the following error.
If you try to add the -SupportMultipleDomain switch we will receive the following error:
Simply trying to run Update-MsolFederatedDomain -DomainName <your domain> -SupportMultipleDomain on the original
domain will also result in an error.
Use the steps below to add an additional top-level domain. If you have already added a domain and did not use
the -SupportMultipleDomain parameter start with the steps for removing and updating your original domain. If
you have not added a top-level domain yet you can start with the steps for adding a domain using PowerShell of
Azure AD Connect.
Use the following steps to remove the Microsoft Online trust and update your original domain.
1. On your AD FS federation server open AD FS Management.
2. On the left, expand Trust Relationships and Relying Party Trusts
3. On the right, delete the Microsoft Office 365 Identity Platform entry.
4. On a machine that has Azure Active Directory Module for Windows PowerShell installed on it run the
following: $cred=Get-Credential .
5. Enter the username and password of a global administrator for the Azure AD domain you are federating with
6. In PowerShell enter Connect-MsolService -Credential $cred
7. In PowerShell enter Update-MSOLFederatedDomain -DomainName <Federated Domain Name> -SupportMultipleDomain .
This is for the original domain. So using the above domains it would be:
Update-MsolFederatedDomain -DomainName bmcontoso.com -SupportMultipleDomain
Use the following steps to add the new top-level domain using PowerShell
1. On a machine that has Azure Active Directory Module for Windows PowerShell installed on it run the
following: $cred=Get-Credential .
2. Enter the username and password of a global administrator for the Azure AD domain you are federating with
3. In PowerShell enter Connect-MsolService -Credential $cred
4. In PowerShell enter New-MsolFederatedDomain SupportMultipleDomain DomainName
Use the following steps to add the new top-level domain using Azure AD Connect.
1. Launch Azure AD Connect from the desktop or start menu
2. Choose Add an additional Azure AD Domain
3. Enter your Azure AD and Active Directory credentials
4. Select the second domain you wish to configure for federation.
5. Click Install
Verify the new top-level domain
By using the PowerShell command Get-MsolDomainFederationSettings -DomainName <your domain> you can view the
updated IssuerUri. The screenshot below shows the federation settings were updated on our original domain
http://bmcontoso.com/adfs/services/trust
And the IssuerUri on our new domain has been set to https://bmfabrikam.com/adfs/services/trust
Support for Sub-domains

When you add a sub-domain, because of the way Azure AD handled domains, it will inherit the settings of the
parent. This means that the IssuerUri needs to match the parents.
So lets say for example that I have bmcontoso.com and then add corp.bmcontoso.com. This means that the
IssuerUri for a user from corp.bmcontoso.com will need to be http://bmcontoso.com/adfs/services/trust.
However the standard rule implemented above for Azure AD, will generate a token with an issuer as
http://corp.bmcontoso.com/adfs/services/trust. which will not match the domain's required value and
authentication will fail.
How To enable support for sub-domains
In order to work around this the AD FS relying party trust for Microsoft Online needs to be updated. To do this,
you must configure a custom claim rule so that it strips off any sub-domains from the users UPN suffix when
constructing the custom Issuer value.
The following claim will do this:
"http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value = regexreplace(c.Value,
"^.*@([^.]+\.)*?(?<domain>([^.]+\.?){2})$", "http://${domain}/adfs/services/trust/"));
[!NOTE] The last number in the regular expression set the how many parent domains there is in your root domain.
Here i have bmcontoso.com so two parent domains are necessary. If three parent domains were to be kept (i.e.:
corp.bmcontoso.com), then the number would have been three. Eventualy a range can be indicated, the match will
always be made to match the maximum of domains. "{2,3}" will match two to three domains (i.e.: bmfabrikam.com
and corp.bmcontoso.com).
Use the following steps to add a custom claim to support sub-domains.
1. Open AD FS Management
2. Right click the Microsoft Online RP trust and choose Edit Claim rules
3. Select the third claim rule, and replace
4. Replace the current claim:

".+@(?<domain>.+)","http://${domain}/adfs/services/trust/"));
with

"^.*@([^.]+\.)*?(?<domain>([^.]+\.?){2})$", "http://${domain}/adfs/services/trust/"));
5. Click Ok. Click Apply. Click Ok. Close AD FS Management.
Azure AD Connect: Automatic upgrade
This feature was introduced with build 1.1.105.0 (released February 2016).
Overview
Making sure your Azure AD Connect installation is always up to date has never been easier with the automatic
upgrade feature. This feature is enabled by default for express installations and DirSync upgrades. When a new
version is released, your installation is automatically upgraded.
Automatic upgrade is enabled by default for the following:
Express settings installation and DirSync upgrades.
Using SQL Express LocalDB, which is what Express settings always use. DirSync with SQL Express also use
LocalDB.
The AD account is the default MSOL_ account created by Express settings and DirSync.
Have less than 100,000 objects in the metaverse.
The current state of automatic upgrade can be viewed with the PowerShell cmdlet Get-ADSyncAutoUpgrade . It has
the following states:
STATE COMMENT
Enabled Automatic upgrade is enabled.
Suspended Set by the system only. The system is no longer eligible to

receive automatic upgrades.
Disabled Automatic upgrade is disabled.
You can change between Enabled and Disabled with Set-ADSyncAutoUpgrade . Only the system should set the
state Suspended.
Automatic upgrade is using Azure AD Connect Health for the upgrade infrastructure. For automatic upgrade to
work, make sure you have opened the URLs in your proxy server for Azure AD Connect Health as documented
in Office 365 URLs and IP address ranges.
If the Synchronization Service Manager UI is running on the server, then the upgrade is suspended until the UI
is closed.
Troubleshooting
If your Connect installation does not upgrade itself as expected, then follow these steps to find out what could be
wrong.
First, you should not expect the automatic upgrade to be attempted the first day a new version is released. There
is an intentional randomness before an upgrade is attempted so don't be alarmed if your installation isn't
upgraded immediately.
If you think something is not right, then first run Get-ADSyncAutoUpgrade to ensure automatic upgrade is enabled.
Then, make sure you have opened the required URLs in your proxy or firewall. Automatic update is using Azure
AD Connect Health as described in the overview. If you use a proxy, make sure Health has been configured to use
a proxy server. Also test the Health connectivity to Azure AD.
With the connectivity to Azure AD verified, it is time to look into the eventlogs. Start the event viewer and look in
the Application eventlog. Add an eventlog filter for the source Azure AD Connect Upgrade and the event id
range 300-399.
You can now see the eventlogs associated with the status for automatic upgrade.
The result code has a prefix with an overview of the state.
RESULT CODE PREFIX DESCRIPTION
Success The installation was successfully upgraded.
UpgradeAborted A temporary condition stopped the upgrade. It will be retried

again and the expectation is that it succeeds later.
UpgradeNotSupported The system has a configuration that is blocking the system

from being automatically upgraded. It will be retried to see if
the state is changing, but the expectation is that the system
must be upgraded manually.
Here is a list of the most common messages you find. It does not list all, but the result message should be clear
with what the problem is.
RESULT MESSAGE DESCRIPTION
UpgradeAborted
UpgradeAbortedCouldNotSetUpgradeMarker Could not write to the registry.

RESULT MESSAGE DESCRIPTION
UpgradeAbortedInsufficientDatabasePermissions The built-in administrators group does not have permissions

to the database. Manually upgrade to the latest version of
Azure AD Connect to address this issue.
UpgradeAbortedInsufficientDiskSpace There is not enough disc space to support an upgrade.
UpgradeAbortedSecurityGroupsNotPresent Could not find and resolve all security groups used by the
sync engine.
UpgradeAbortedServiceCanNotBeStarted The NT Service Microsoft Azure AD Sync failed to start.
UpgradeAbortedServiceCanNotBeStopped The NT Service Microsoft Azure AD Sync failed to stop.
UpgradeAbortedServiceIsNotRunning The NT Service Microsoft Azure AD Sync is not running.
UpgradeAbortedSyncCycleDisabled The SyncCycle option in the scheduler has been disabled.
UpgradeAbortedSyncExeInUse The synchronization service manager UI is open on the

server.
UpgradeAbortedSyncOrConfigurationInProgress The installation wizard is running or a sync was scheduled

outside the scheduler.
UpgradeNotSupported
UpgradeNotSupportedCustomizedSyncRules You have added your own custom rules to the configuration.
UpgradeNotSupportedDeviceWritebackEnabled You have enabled the device writeback feature.
UpgradeNotSupportedGroupWritebackEnabled You have enabled the group writeback feature.
UpgradeNotSupportedInvalidPersistedState The installation is not an Express settings or a DirSync

upgrade.
UpgradeNotSupportedMetaverseSizeExceeeded You have more than 100,000 objects in the metaverse.
UpgradeNotSupportedMultiForestSetup You are connecting to more than one forest. Express setup
only connects to one forest.
UpgradeNotSupportedNonLocalDbInstall You are not using a SQL Server Express LocalDB database.
UpgradeNotSupportedNonMsolAccount The AD Connector account is not the default MSOL_ account

anymore.
UpgradeNotSupportedStagingModeEnabled The server is set to be in staging mode.
UpgradeNotSupportedUserWritebackEnabled You have enabled the user writeback feature.
Next steps
Azure AD Connect sync: Prevent accidental deletes
This topic describes the prevent accidental deletes (preventing accidental deletions) feature in Azure AD Connect.
When installing Azure AD Connect, prevent accidental deletes is enabled by default and configured to not allow
an export with more than 500 deletes. This feature is designed to protect you from accidental configuration
changes and changes to your on-premises directory that would affect many users and other objects.
What is prevent accidental deletes

Common scenarios when you see many deletes include:
Changes to filtering where an entire OU or domain is unselected.
All objects in an OU are deleted.
An OU is renamed so all objects in it are considered to be out of scope for synchronization.
The default value of 500 objects can be changed with PowerShell using Enable-ADSyncExportDeletionThreshold .
You should configure this value to fit the size of your organization. Since the sync scheduler runs every 30
minutes, the value is the number of deletes seen within 30 minutes.
If there are too many deletes staged to be exported to Azure AD, then the export stops and you receive an email
like this:
Hello (technical contact). At (time) the Identity synchronization service detected that the number of deletions
exceeded the configured deletion threshold for (organization name). A total of (number) objects were sent for
deletion in this Identity synchronization run. This met or exceeded the configured deletion threshold value of
(number) objects. We need you to provide confirmation that these deletions should be processed before we
will proceed. Please see the preventing accidental deletions for more information about the error listed in this
email message.
You can also see the status stopped-deletion-threshold-exceeded when you look in the Synchronization Service
Manager UI for the Export profile.
If this was unexpected, then investigate and take corrective actions. To see which objects are about to be deleted,
do the following:
1. Start Synchronization Service from the Start Menu.
2. Go to Connectors.
3. Select the Connector with type Azure Active Directory.
4. Under Actions to the right, select Search Connector Space.
5. In the pop-up under Scope, select Disconnected Since and pick a time in the past. Click Search. This page
provides a view of all objects about to be deleted. By clicking each item, you can get additional information
about the object. You can also click Column Setting to add additional attributes to be visible in the grid.
If all the deletes are desired, then do the following:

1. To temporarily disable this protection and let those deletes go through, run the PowerShell cmdlet:
Disable-ADSyncExportDeletionThreshold . Provide an Azure AD Global Administrator account and password.
2. With the Azure Active Directory Connector still selected, select the action Run and select Export.
3. To re-enable the protection, run the PowerShell cmdlet: Enable-ADSyncExportDeletionThreshold .
Next steps
Overview topics
Implementing password synchronization with Azure
AD Connect sync
This topic provides you with the information you need to synchronize your user passwords from an on-premises
Active Directory (AD) to a cloud-based Azure Active Directory (Azure AD).
What is password synchronization

The probability that you are blocked from getting your work done due to a forgotten password is related to the
number of different passwords you need to remember. The more passwords you need to remember, the higher
the probability to forget one. Questions and calls about password resets and other password-related issues
demand the most helpdesk resources.
Password synchronization is a feature to synchronize user passwords from an on-premises Active Directory to a
cloud-based Azure Active Directory (Azure AD). This feature enables you to sign in to Azure Active Directory
services (such as Office 365, Microsoft Intune, CRM Online, and Azure AD Domain Services) using the same
password you are using to sign in to your on-premises Active Directory.
By reducing the number of passwords your users need to maintain to just one, password synchronization helps
you to:
Improve the productivity of your users
Reduce your helpdesk costs
Also, if you select to use Federation with AD FS, you can optionally enable password synchronization as a
backup in case your AD FS infrastructure fails.
Password synchronization is an extension to the directory synchronization feature implemented by Azure AD
Connect sync. To use password synchronization in your environment, you need to:
Configure directory synchronization between your on-premises AD and your Azure Active Directory
Enable password synchronization
For more details, see Integrating your on-premises identities with Azure Active Directory
NOTE
For more details about Active Directory Domain Services that are configured for FIPS and password synchronization, see
Password Sync and FIPS.
How password synchronization works

The Active Directory domain service stores passwords in form of a hash value representation of the actual user
password. A hash value is a result of a one-way mathematical function (the "hashing algorithm"). There is no
method to revert the result of a one-way function to the plain text version of a password. You cannot use a
password hash to sign in to your on-premises network.
To synchronize your password, Azure AD Connect sync extracts your password hash from the on-premises
Active Directory. Extra security processing is applied to the password hash before it is synchronized to the Azure
Active Directory authentication service. Passwords are synchronized on a per-user basis and in chronological
order.
The actual data flow of the password synchronization process is similar to the synchronization of user data such
as DisplayName or Email Addresses. However, passwords are synchronized more frequently than the standard
directory synchronization window for other attributes. The password synchronization process runs every 2
minutes. You cannot modify the frequency of this process. When you synchronize a password, it overwrites the
existing cloud password.
The first time, you enable the password synchronization feature, it performs an initial synchronization of the
passwords of all in-scope users. You cannot explicitly define a subset of user passwords you want to synchronize.
When you change an on-premises password, the updated password is synchronized, most often in a matter of
minutes. The password synchronization feature automatically retries failed synchronization attempts. If an error
occurs during an attempt to synchronize a password, an error is logged in your event viewer.
The synchronization of a password has no impact on the currently logged on user. Your current cloud service
session is not immediately affected by a synchronized password change that occurs while you are signed in to a
cloud service. However, when the cloud service requires you to authenticate again, you need to provide your new
password.
NOTE
Password sync is only supported for the object type user in Active Directory. It is not supported for the iNetOrgPerson
object type.
How password synchronization works with Azure AD Domain Services

You can also use the password synchronization feature to synchronize your on-premises passwords to the Azure
AD Domain Services. This scenario allows the Azure AD Domain Services to authenticate your users in the cloud
with all the methods available in your on-premises AD. The experience of this scenario is similar to using the
Active Directory Migration Tool (ADMT) in an on-premises environment.
Security considerations
When synchronizing passwords, the plain-text version of your password is not exposed to the password
synchronization feature, to Azure AD, or any of the associated services.
Also, there is no requirement on the on-premises Active Directory to store the password in a reversibly
encrypted format. A digest of the Active Directory password hash is used for the transmission between the on-
premises AD and Azure Active Directory. The digest of the password hash cannot be used to access resources in
your on-premises environment.
Password policy considerations
There are two types of password policies that are affected by enabling password synchronization:
1. Password Complexity Policy
2. Password Expiration Policy
Password complexity policy
When you enable password synchronization, the password complexity policies in your on-premises Active
Directory override complexity policies in the cloud for synchronized users. You can use all valid passwords of
your on-premises Active Directory to access Azure AD services.
NOTE
Passwords for users that are created directly in the cloud are still subject to password policies as defined in the cloud.
Password expiration policy

If a user is in the scope of password synchronization, the cloud account password is set to "Never Expire". You
can continue to sign in to your cloud services using a synchronized password that has been expired in your on-
premises environment. Your cloud password is updated the next time you change the password in the on-
premises environment.
Overwriting synchronized passwords
An administrator can manually reset your password using Windows PowerShell.
In this case, the new password overrides your synchronized password and all password policies defined in the
cloud are applied to the new password.
If you change your on-premises password again, the new password is synchronized to the cloud, and overrides
the manually updated password.
Enabling password synchronization

Password synchronization is automatically enabled, when you install Azure AD Connect using the Express
Settings. For more details, see Getting started with Azure AD Connect using express settings.
If you use custom settings when you install Azure AD Connect, you enable password synchronization on the user
sign-in page. For more details, see Custom installation of Azure AD Connect.
Password synchronization and FIPS
If your server has been locked down according to Federal Information Processing Standard (FIPS), then MD5 has
been disabled.
To enable MD5 for password synchronization, perform the following steps:
1. Go to %programfiles%\Azure AD Sync\Bin.
2. Open miiserver.exe.config.
3. Go to the configuration/runtime node (at the end of the file).
4. Add the following node: <enforceFIPSPolicy enabled="false"/>
5. Save your changes.
For reference, this snip is how it should look like:
<configuration>
<runtime>
<enforceFIPSPolicy enabled="false"/>
</runtime>
</configuration>
For information about security and FIPS see AAD Password Sync, Encryption and FIPS compliance
Troubleshooting password synchronization

If passwords are not synchronizing as expected, it can either be for a subset of users or for all users.
If you have an issue with individual objects, then see Troubleshoot one object that is not synchronizing
passwords.
If you have an issue where no passwords are synchronized, see Troubleshoot issues where no passwords are
synchronized.
Troubleshoot one object that is not synchronizing passwords
You can easily troubleshoot password synchronization issues by reviewing the status of an object.
Start in Active Directory Users and Computers. Find the user and verify that User must change password at
next logon is unselected.
If it is selected, then ask the user to sign in and change the password. Temporary passwords are not
synchronized to Azure AD.
If it looks correct in Active Directory, then the next step is to follow the user in the sync engine. By following the
user from on-premises Active Directory to Azure AD, you can see if there is a descriptive error on the object.
1. Start the Synchronization Service Manager.
2. Click Connectors.
3. Select the Active Directory Connector the user is located in.
4. Select Search Connector Space.
5. Locate the user you are looking for.
6. Select the lineage tab and make sure that at least one Sync Rule shows Password Sync as True. In the
default configuration, the name of the Sync Rule is In from AD - User AccountEnabled.
7. Then follow the user through the metaverse to the Azure AD Connector space. The connector space object
should have an outbound rule with Password Sync set to True. In the default configuration, the name of the
sync rule is Out to AAD - User Join.
8. To see the password sync details of the object for the past week, click Log....
If the object log is empty, then Azure AD Connect has not been able to read the password hash from Active
Directory. Look into the eventlog for errors.
The status column can have the following values:
STATUS DESCRIPTION
Success Password has been successfully synchronized.
FilteredByTarget Password is set to User must change password at next

logon. Password has not been synchronized.
NoTargetConnection No object in the metaverse or in the Azure AD connector

space.
SourceConnectorNotPresent No object found in the on-premises Active Directory

connector space.
TargetNotExportedToDirectory The object in the Azure AD connector space has not yet been
exported.
MigratedCheckDetailsForMoreInfo Log entry was created before build 1.0.9125.0 and is shown
in its legacy state.
Troubleshoot issues where no passwords are synchronized

Start by running the script in the section Get the status of password sync settings. It gives you an overview of the
password sync configuration.
If the feature is not enabled in Azure AD or if the sync channel status is not enabled, then run the Connect
installation wizard. Select Customize synchronization options and unselect password sync. This change
temporarily disables the feature. Then run the wizard again and re-enable password sync. Run the script again to
verify that the configuration is correct.
If the script shows that there is no heartbeat, then run the script in Trigger a full sync of all passwords. This script
can also be used for other scenarios where the configuration is correct but passwords are not synchronized.
If you installed Azure AD Connect with customized settings, make sure you have granted the account used by the
AD Connector the permissions "Replicate Directory Changes" and "Replicate Directory Changes All". See
accounts and permissions for all permissions needed by this account. Without those permissions, the account
will not have permissions to read password hashes in Active Directory.
Then look into the application eventlog. If there is a global problem with password synchronization and the
service is operational, as verified by the previous steps, there should be an error with more details.
Get the status of password sync settings
Import-Module ADSync
$connectors = Get-ADSyncConnector
$aadConnectors = $connectors | Where-Object {$_.SubType -eq "Windows Azure Active Directory (Microsoft)"}
$adConnectors = $connectors | Where-Object {$_.ConnectorTypeName -eq "AD"}
if ($aadConnectors -ne $null -and $adConnectors -ne $null)
{
if ($aadConnectors.Count -eq 1)
{
$features = Get-ADSyncAADCompanyFeature -ConnectorName $aadConnectors[0].Name
Write-Host
Write-Host "Password sync feature enabled in your Azure AD directory: " $features.PasswordHashSync
foreach ($adConnector in $adConnectors)
{
Write-Host
Write-Host "Password sync channel status BEGIN -------------------------------------------------
------ "
Write-Host
Get-ADSyncAADPasswordSyncConfiguration -SourceConnector $adConnector.Name
Write-Host
$pingEvents =
Get-EventLog -LogName "Application" -Source "Directory Synchronization" -InstanceId 654 -
After (Get-Date).AddHours(-3) |
Where-Object {
$_.Message.ToUpperInvariant().Contains($adConnector.Identifier.ToString("D").ToUpperInvariant()) } |
Sort-Object { $_.Time } -Descending
if ($pingEvents -ne $null)
{
Write-Host "Latest heart beat event (within last 3 hours). Time " $pingEvents[0].TimeWritten
}
else
{
Write-Warning "No ping event found within last 3 hours."
}
Write-Host
Write-Host "Password sync channel status END ---------------------------------------------------
---- "
Write-Host
}
}
else
{
Write-Warning "More than one Azure AD Connectors found. Please update the script to use the
appropriate Connector."
}
}
Write-Host
if ($aadConnectors -eq $null)
{
Write-Warning "No Azure AD Connector was found."
}
if ($adConnectors -eq $null)
{
Write-Warning "No AD DS Connector was found."
}
Write-Host
Trigger a full sync of all passwords

You can trigger a full sync of all passwords using the following script:
$adConnector = "<CASE SENSITIVE AD CONNECTOR NAME>"
$aadConnector = "<CASE SENSITIVE AAD CONNECTOR NAME>"
Import-Module adsync
$c = Get-ADSyncConnector -Name $adConnector
$p = New-Object Microsoft.IdentityManagement.PowerShell.ObjectModel.ConfigurationParameter
"Microsoft.Synchronize.ForceFullPasswordSync", String, ConnectorGlobal, $null, $null, $null
$p.Value = 1
$c.GlobalParameters.Remove($p.Name)
$c.GlobalParameters.Add($p)
$c = Add-ADSyncConnector -Connector $c
Set-ADSyncAADPasswordSyncConfiguration -SourceConnector $adConnector -TargetConnector $aadConnector -Enable
$false
Set-ADSyncAADPasswordSyncConfiguration -SourceConnector $adConnector -TargetConnector $aadConnector -Enable
$true
Next steps
Azure AD Connect sync: How to manage the Azure
AD service account
The service account used by the Azure AD Connector is supposed to be service free. If you need to reset its
credentials, then this topic is for you. For example, if a Global Administrator has by mistake reset the password on
the service account using PowerShell.
Reset the credentials

If the service account defined on the Azure AD Connector cannot contact Azure AD due to authentication problems,
the password can be reset.
1. Sign in to the Azure AD Connect sync server and start PowerShell.
2. Run Add-ADSyncAADServiceAccount .
3. Provide Azure AD Global admin credentials.

This cmdlet resets the password for the service account and update it both in Azure AD and in the sync engine.
Known issues these steps can solve

This section is a list of errors reported by customers that were fixed by a credentials reset on the Azure AD service
account.
Event 6900
The server encountered an unexpected error while processing a password change notification:
AADSTS70002: Error validating credentials. AADSTS50054: Old password is used for authentication.
Event 659
Error while retrieving password policy sync configuration.
Microsoft.IdentityModel.Clients.ActiveDirectory.AdalServiceException:
AADSTS70002: Error validating credentials. AADSTS50054: Old password is used for authentication.
Next steps
Overview topics
Azure AD Connect sync: Running the installation
wizard a second time
The first time you run the Azure AD Connect installation wizard, it walks you through how to configure your
installation. If you run the installation wizard again, it offers options for maintenance.
You can find the installation wizard in the start menu named Azure AD Connect.
When you start the installation wizard, you see a page with these options:
If you have installed ADFS with Azure AD Connect, you have even more options. The additional options you have
for ADFS are documented in ADFS management.
Select one of the tasks and click Next to continue.
IMPORTANT
While you have the installation wizard open, all operations in the sync engine are suspended. Make sure you close the
installation wizard as soon as you have completed your configuration changes.
View current configuration
This option gives you a quick view of your currently configured options.
Click Previous to go back. If you select Exit, you close the installation wizard.
Customize synchronization options

This option is used to make changes to the sync configuration. You see a subset of options from the custom
configuration installation path. You see this option even if you used express installation initially.
Add more directories. For removing a directory, see Delete a Connector.
Change Domain and OU filtering.
Remove Group filtering.
Change optional features.
The other options from the initial installation cannot be changed and are not available. These options are:
Change the attribute to use for userPrincipalName and sourceAnchor.
Change the joining method for objects from different forest.
Enable group-based filtering.
Refresh directory schema

This option is used if you have changed the schema in one of your on-premises AD DS forests. For example, you
might have installed Exchange or upgraded to a Windows Server 2012 schema with device objects. In this case,
you need to instruct Azure AD Connect to read the schema again from AD DS and update its cache. This action also
regenerates the Sync Rules. If you add the Exchange schema, as an example, the Sync Rules for Exchange are
added to the configuration.
When you select this option, all the directories in your configuration are listed. You can keep the default setting and
refresh all forests or unselect some of them.
Configure staging mode

This option allows you to enable and disable staging mode on the server. More information about staging mode
and how it is used can be found in Operations.
The option shows if staging is currently enabled or disabled:
To change the state, select this option and select or unselect the checkbox.
Change user sign-in

This option allows you to change from password sync to federation or the other way around. You cannot change to
do not configure.
For more information on this option, see user sign-in.
Next steps
Learn more about the configuration model used by Azure AD Connect sync in Understanding Declarative
Provisioning.
Overview topics
Azure AD Connect sync: Best practices for changing
the default configuration
The purpose of this topic is to describe supported and unsupported changes to Azure AD Connect sync.
The configuration created by Azure AD Connect works as is for most environments that synchronize on-
premises Active Directory with Azure AD. However, in some cases, it is necessary to apply some changes to a
configuration to satisfy a particular need or requirement.
Changes to the service account

Azure AD Connect sync is running under a service account created by the installation wizard. This service account
holds the encryption keys to the database used by sync. It is created with a 127 characters long password and the
password is set to not expire.
It is unsupported to change or reset the password of the service account. Doing so destroys the encryption
keys and the service is not able to access the database and is not able to start.
Changes to the scheduler

Starting with the releases from build 1.1 (February 2016) you can configure the scheduler to have a different sync
cycle than the default 30 minutes.
Changes to Synchronization Rules

The installation wizard provides a configuration that is supposed to work for the most common scenarios. In case
you need to make changes to the configuration, then you must follow these rules to still have a supported
configuration.
You can change attribute flows if the default direct attribute flows are not suitable for your organization.
If you want to not flow an attribute and remove any existing attribute values in Azure AD, then you need to
create a rule for this scenario.
Disable an unwanted Sync Rule rather than deleting it. A deleted rule is recreated during an upgrade.
To change an out-of-box rule, you should make a copy of the original rule and disable the out-of-box rule. The
Sync Rule Editor prompts and helps you.
Export your custom synchronization rules using the Synchronization Rules Editor. The editor provides you with
a PowerShell script you can use to easily recreate them in a disaster recovery scenario.
WARNING
The out-of-box sync rules have a thumbprint. If you make a change to these rules, the thumbprint is no longer matching.
You might have problems in the future when you try to apply a new release of Azure AD Connect. Only make changes the
way it is described in this article.
Disable an unwanted Sync Rule

Do not delete an out-of-box sync rule. It is recreated during next upgrade.
In some cases, the installation wizard has produced a configuration that is not working for your topology. For
example, if you have an account-resource forest topology but you have extended the schema in the account forest
with the Exchange schema, then rules for Exchange are created for the account forest and the resource forest. In
this case, you need to disable the Sync Rule for Exchange.
In the picture above, the installation wizard has found an old Exchange 2003 schema in the account forest. This
schema extension was added before the resource forest was introduced in Fabrikam's environment. To ensure no
attributes from the old Exchange implementation are synchronized, the sync rule should be disabled as shown.
Change an out-of-box rule
The only time you should change an out-of-box rule is when you need to change the join rule. If you need to
change an attribute flow, then you should create a sync rule with higher precedence than the out-of-box rules. The
only rule you practically need to clone is the rule In from AD - User Join. You can override all other rules with a
higher precedence rule.
If you need to make changes to an out-of-box rule, then you should make a copy of the out-of-box rule and
disable the original rule. Then make the changes to the cloned rule. The Sync Rule Editor is helping you with those
steps. When you open an out-of-box rule, you are presented with this dialog box:
Select Yes to create a copy of the rule. The cloned rule is then opened.
On this cloned rule, make any necessary changes to scope, join, and transformations.
Next steps
Overview topics
Azure AD Connect sync: Configure Filtering
With filtering, you can control which objects should appear in Azure AD from your on-premises directory. The
default configuration takes all objects in all domains in the configured forests. In general, this is the
recommended configuration. End users using Office 365 workloads, such as Exchange Online and Skype for
Business, benefit from a complete Global Address List so they can send email and call everyone. With the default
configuration, they would get the same experience they would get with an on-premises implementation of
Exchange or Lync.
In some cases, it is required to make some changes to the default configuration. Here are some examples:
You plan to use the multi-Azure AD-directory topology. Then you need to apply a filter to control which object
should be synchronized to a particular Azure AD directory.
You run a pilot for Azure or Office 365 and you only want a subset of users in Azure AD. In the small pilot, it is
not important to have a complete Global Address List to demonstrate the functionality.
You have many service accounts and other non-personal accounts you do not want in Azure AD.
For compliance reasons you do not delete any user accounts on-premises. You only disable them. But in Azure
AD you only want active accounts to be present.
This article covers how to configure the different filtering methods.
IMPORTANT
Microsoft does not support modification or operation of the Azure AD Connect sync outside of those actions formally
documented. Any of these actions may result in an inconsistent or unsupported state of Azure AD Connect sync and as a
result, Microsoft cannot provide technical support for such deployments.
Basics and important notes

In Azure AD Connect sync, you can enable filtering at any time. If you start with a default configuration of
directory synchronization and then configure filtering, the objects that are filtered out are no longer synchronized
to Azure AD. As a result of this change, any objects in Azure AD that were previously synchronized but were then
filtered are deleted in Azure AD.
Before you start making changes to filtering, make sure you disable the scheduled task so you do not accidentally
export changes that you have not yet verified to be correct.
Since filtering can remove many objects at the same time, you want to make sure your new filters are correct
before you start exporting any changes to Azure AD. After you have completed the configuration steps, it is
strongly recommended that you follow the verification steps before you export and make changes to Azure AD.
To protect you from deleting many objects by accident, the feature prevent accidental deletes is on by default. If
you delete many objects due to filtering (500 by default), you need to follow the steps in this article to allow the
deletes to go through to Azure AD.
If you use a build before November 2015 (1.0.9125), make a change to filter configuration and you use password
synchronization, then you need to trigger a full sync of all passwords after you have completed the configuration.
For steps on how to trigger a password full sync see Trigger a full sync of all passwords. If you are on 1.0.9125 or
later, then the regular full synchronization action also calculates if passwords should be synchronized and this
extra step is no longer required.
If user objects were inadvertently deleted in Azure AD because of a filtering error, you can recreate the user
objects in Azure AD by removing your filtering configurations and then synchronize your directories again. This
action restores the users from the recycle bin in Azure AD. However, you cannot undelete other object types. For
example, if you accidentally delete a security group and it was used to ACL a resource, the group and its ACLs
cannot be recovered.
Azure AD Connect only deletes objects it has once considered to be in scope. If there are objects in Azure AD that
were created by another sync engine and these objects are not in scope, adding filtering do not remove them. For
example, if you start with a DirSync server and it created a complete copy of your entire directory in Azure AD
and you install a new Azure AD Connect sync server in parallel with filtering enabled from the beginning, it does
not remove the extra objects created by DirSync.
The filtering configuration is retained when you install or upgrade to a newer version of Azure AD Connect. It is
always a best practice to verify that the configuration was not inadvertently changed after an upgrade to a newer
version before running the first synchronization cycle.
If you have more than one forest, then the filtering configurations described in this topic must be applied to every
forest (assuming you want the same configuration for all of them).
Disable scheduled task
To disable the built-in scheduler that triggers a synchronization cycle every 30 minutes, follow these steps:
1. Go to a PowerShell prompt.
2. Run Set-ADSyncScheduler -SyncCycleEnabled $False to disable the scheduler.
3. Make the changes as documented in this topic.
4. Run Set-ADSyncScheduler -SyncCycleEnabled $True to enable the scheduler again.
If you use an Azure AD Connect build before 1.1.105.0

To disable the scheduled task that triggers a synchronization cycle every 3 hours, follow these steps:
1. Start Task Scheduler from the start menu.
2. Directly under Task Scheduler Library, find the task named Azure AD Sync Scheduler, right-click, and
select Disable.
3. You can now make configuration changes and run the sync engine manually from the synchronization
service manager console.
After you have completed all your filtering changes, don't forget to come back and Enable the task again.
Filtering Options
The following filtering configuration types can be applied to the Directory Synchronization tool:
Group based: Filtering based on a single group can only be configured on initial install using the installation
wizard. It is not further covered in this topic.
Domain-based: This option enables you to select which domains that synchronize to Azure AD. It also allows
you to add and remove domains from the sync engine configuration when you make changes to your on-
premises infrastructure after you installed Azure AD Connect sync.
Organizational-Unitbased: This filtering option enables you to select which OUs synchronize to Azure AD.
This option is for all object types in selected OUs.
Attributebased: This option allows you to filter objects based on attribute values on the objects. You can
also have different filters for different object types.
You can use multiple filtering options at the same time. For example, you can use OU-based filtering to only
include objects in one OU and at the same time attribute-based filtering to filter the objects further. When you
use multiple filtering methods, the filters use a logical AND between the filters.
Domain-based filtering
This section provides you with the steps to configure your domain filter. If you have added or removed domains
in your forest after you have installed Azure AD Connect, you also have to update the filtering configuration.
The preferred way to change domain-based filtering is by running the installation wizard and change domain and
OUs filtering. The installation wizard is automating all the tasks documented in this topic.
You should only follow these steps if you for some reason are unable to run the installation wizard.
Domain-based filtering configuration consists of these steps:
Select the domains that should be included in the synchronization.
For each added and removed domain, adjust the run profiles.
Apply and verify changes.
Select domains to be synchronized
To set the domain filter, do the following steps:
1. Sign in to the server that is running Azure AD Connect sync by using an account that is a member of the
ADSyncAdmins security group.
2. Start Synchronization Service from the start menu.
3. Select Connectors and in the Connectors list, select the Connector with the type Active Directory Domain
Services. From Actions, select Properties.
4. Click Configure Directory Partitions.

5. In the Select directory partitions list, select and unselect the domains as needed. Verify that only the
partitions you want to synchronize are selected.
If you have changed your on-premises AD infrastructure and added or removed domains from the forest, then
click the Refresh button to get an updated list. When you refresh, you are asked for credentials. Provide any
credentials with read access to your on-premises Active Directory. It does not have to be the user that is pre-
populated in the dialog box.
6. When you are done, close the Properties dialog by clicking OK. If you have removed domains from the forest,
a message pop-up saying a domain was removed and that configuration will be cleaned up.
7. Continue to adjust the run profiles.
Update Run Profiles
If you have updated your domain filter, you also need to update the run profiles.
1. In the Connectors list, make sure the Connector you changed in the previous step is selected. From Actions,
select Configure Run Profiles.
2. Find and identify the following profiles:

Full Import
Full Synchronization
Delta Import
Delta Synchronization
Export
3. For each profile, adjust added and removed domains.
a. For each of the five profiles, take the following steps for each added domain:
a. Select the run profile and click New Step.
b. On the Configure Step page, in the Type drop-down, select the step type with the same name
as the profile you are configuring. Then click Next.
c. On the Connector Configuration page, in the Partition drop-down, select the name of the
domain you have added to your domain filter.
d. To close the Configure Run Profile dialog, click Finish.

b. For each of the five profiles, take the following steps for each removed domain:
a. Select the run profile.
b. If the Value of the Partition attribute is a GUID, select the run step and click Delete Step.
c. Verify your change. The result should be that each domain you want to synchronize should be listed as
a step in each run profile.
4. To close the Configure Run Profiles dialog, click OK.
5. To complete the configuration you need to run a Full import and Delta sync. Continue reading the section
Organizational-unitbased filtering
The preferred way to change OU-based filtering is by running the installation wizard and change domain and
OUs filtering. The installation wizard is automating all the tasks documented in this topic.
You should only follow these steps if you for some reason are unable to run the installation wizard.
To configure organizational-unitbased filtering, do the following steps:
3. Select Connectors and in the Connectors list, select the Connector with the type Active Directory Domain
Services. From Actions, select Properties.
4. Click Configure Directory Partitions, select the domain you want to configure, and then click Containers.
5. When prompted, provide any credentials with read access to your on-premises Active Directory. It does not
have to be the user that is pre-populated in the dialog box.
6. In the Select Containers dialog box, clear the OUs that you dont want to synchronize with the cloud
directory, and then click OK.
The Computers container should be selected for your Windows 10 computers to be successfully
synchronized to Azure AD. If your domain joined computers are located in other OUs, make sure those
are selected.
The ForeignSecurityPrincipals container should be selected if you have multiple forests with trusts.
This container allows cross-forest security group membership to be resolved.
The RegisteredDevices OU should be selected if you have enabled the device writeback feature. If you
use another writeback feature, such as group writeback, make sure these locations are selected.
Select any other OU where Users, iNetOrgPersons, Groups, Contacts, and Computers are located. In the
picture, all these OUs are located in the ManagedObjects OU.
If you use group-based filtering, then the OU where the group is located must be included.
Note: You can configure if new OUs added after the filtering configuration has completed should be
synchronized or not synchronized. See next section for details.
7. When you are done, close the Properties dialog by clicking OK.
8. To complete the configuration you need to run a Full import and Delta sync. Continue reading the section
Synchronize new OUs
New OUs created after filtering has been configured are synchronized by default. This state is indicated by a
checkmark in the box. You can then unselect some sub-OUs by explicitly unselect those. To get this behavior, click
the box until it becomes white with a blue checkbox (its default state). Then unselect any sub-OUs you do not
want to synchronize.
If all sub-OUs are synchronized, then the box is white with a blue checkbox.
If some sub-OUs have been unselected, then the box is instead gray with a white checkbox.
With this configuration, a new OU created under ManagedObjects is synchronized.

The Azure AD Connect installation wizard always creates this configuration.
Do not synchronize new OUs
You can configure the sync engine to not synchronize new OUs after the filtering configuration has completed.
This state is indicated in the UI with the box being solid gray with no checkmark. To get this behavior, click the
box until it becomes white with no checkmark. Then select the sub-OUs you want to synchronize.
With this configuration, a new OU created under ManagedObjects is not synchronized.
Attribute-based filtering
Make sure you are on the November 2015 (1.0.9125) or later build for these steps to work.
Attribute based filtering is the most flexible way to filter objects. You can use the power of declarative
provisioning to control almost every aspect of when an object should be synchronized to Azure AD.
Filtering can be applied both on the inbound from Active Directory to the metaverse and outbound from the
metaverse to Azure AD. It is recommended to apply filtering on inbound since that is easiest to maintain.
Outbound filtering should only be used if it is required to join objects from more than one forest before the
evaluation can take place.
Inbound filtering
Inbound based filtering is using the default configuration where objects going to Azure AD must have the
metaverse attribute cloudFiltered not set to a value to be synchronized. If this attribute's value is set to True, then
the object is not synchronized. It should not be set to False by design. To make sure other rules have the ability to
contribute a value, this attribute is only supposed to have the values True or NULL (absent).
In the inbound filtering, you use the power of scope to determine which objects should or should not be
synchronized. This is where you make adjustments to fit your own organization's requirements. The scope
module has group and clause to determine when a sync rule should be in scope. A group contains one or many
clause. There is a logical AND between multiple clauses and a logical OR between multiple groups.
Let us look at an example:
This should be read as (department = IT) OR (department = Sales AND c = US).

In the samples and steps below, you use the user object as an example, but you can use this for all object types.
In the samples below, the precedence value start with 500. This value ensures these rules are evaluated after the
out-of-box rules (lower precedence, higher numeric value).
Negative filtering, "do not sync these"
In the following example, you filter out (not synchronize) all users where extensionAttribute15 have the value
NoSync.
2. Start Synchronization Rules Editor from the start menu.
3. Make sure Inbound is selected and click Add New Rule.
4. Give the rule a descriptive name, such as "In from AD User DoNotSyncFilter". Select the correct forest, User
as the CS object type, and Person as the MV object type. As Link Type, select Join and in precedence type
a value currently not used by another Synchronization Rule (for example 500), and then click Next.
5. In Scoping filter, click Add Group, click Add Clause, and in attribute select ExtensionAttribute15. Make
sure the Operator is set to EQUAL and type the value NoSync in the Value box. Click Next.
6. Leave the Join rules empty, and then click Next.

7. Click Add Transformation, select the FlowType to Constant, select the Target Attribute cloudFiltered and
in the Source text box, type True. Click Add to save the rule.
8. To complete the configuration you need to run a Full sync. Continue reading the section Apply and verify
changes.
Positive filtering, "only sync these"
Expressing positive filtering can be more challenging since you have to also consider objects that are not obvious
to be synchronized, such as conference rooms.
The positive filtering option requires two sync rules. One (or several) with the correct scope of objects to
synchronize and a second catch-all sync rule that filter out all objects that have not yet been identified as an
object that should be synchronized.
In the following example, you only synchronize user objects where the department attribute has the value Sales.
3. Make sure Inbound is selected and click Add New Rule.
4. Give the rule a descriptive name, such as "In from AD User Sales sync". Select the correct forest, User as the
CS object type, and Person as the MV object type. As Link Type, select Join and in precedence type a
value currently not used by another Synchronization Rule (for example 501), and then click Next.
5. In Scoping filter, click Add Group, click Add Clause, and in attribute select department. Make sure the
Operator is set to EQUAL and type the value Sales in the Value box. Click Next.

7. Click Add Transformation, select the FlowType to Constant, select the Target Attribute cloudFiltered
and in the Source text box, type False. Click Add to save the rule.
This is a special case where you set cloudFiltered explicitly to False.

We now have to create the catch-all sync rule.
8. Give the rule a descriptive name, such as "In from AD User Catch-all filter". Select the correct forest, User as
the CS object type, and Person as the MV object type. As Link Type, select Join and in precedence type a
value currently not used by another Synchronization Rule (for example 600). You have selected a precedence
value higher (lower precedence) than the previous sync rule but also left some room so we can add more
filtering sync rules later when you want to start synchronizing additional departments. Click Next.
9. Leave Scoping filter empty, and click Next. An empty filter indicates the rule should be applied to all objects.
11. Click Add Transformation, select the FlowType to Constant, select the Target Attribute cloudFiltered and
in the Source text box, type True. Click Add to save the rule.
changes.
If you need to, then you can create more rules of the first type where you include more objects in our
synchronization.
Outbound filtering
In some cases, it is necessary to do the filtering only after the objects have joined in the metaverse. It could, for
example, be required to look at the mail attribute from the resource forest and the userPrincipalName attribute
from the account forest to determine if an object should be synchronized. In these cases, you create the filtering
on the outbound rule.
In this example, you change the filtering so only users where both mail and userPrincipalName end with
@contoso.com are synchronized:
3. Under Rules Type, click Outbound.
4. Find the rule named Out to AAD User Join SOAInAD. Click Edit.
5. In the pop-up, answer Yes to create a copy of the rule.
6. On the Description page, change precedence to an unused value, for example 50.
7. Click Scoping filter on the left-hand navigation. Click Add clause, in Attribute select mail, in Operator select
ENDSWITH, and in Value type @contoso.com. Click Add clause, in Attribute select userPrincipalName, in
Operator select ENDSWITH, and in Value type @contoso.com.
8. Click Save.
changes.
Apply and verify changes

After you have made your configuration changes, these must be applied to the objects already present in the
system. It could also be that objects not currently in the sync engine should be processed and the sync engine
needs to read the source system again to verify its content.
If you changed configuration using domain or organizational-unit filtering, then you need to do Full import
followed by Delta synchronization.
If you changed configuration using attribute filtering, then you need to do Full synchronization.
Take the following steps:
2. Select Connectors and in the Connectors list, select the Connector where you made a configuration change
earlier. From Actions, select Run.
3. In the Run profiles, select the operation mentioned in the previous section. If you need to run two actions, run
the second after the first one has completed (the State column is Idle for the selected Connector).
After the synchronization, all changes are staged to be exported. Before you actually make the changes in Azure
AD, you want to verify that all these changes are correct.
1. Start a cmd prompt and go to %Program Files%\Microsoft Azure AD Sync\bin
2. Run: csexport "Name of Connector" %temp%\export.xml /f:x
The name of the Connector can be found in Synchronization Service. It has a name similar to "contoso.com
AAD" for Azure AD.
3. Run: CSExportAnalyzer %temp%\export.xml > %temp%\export.csv
4. You now have a file in %temp% named export.csv that can be examined in Microsoft Excel. This file contains all
changes that are about to be exported.
5. Make necessary changes to the data or configuration and run these steps again (Import, Synchronize, and
Verify) until the changes that are about to be exported are expected.
When you are satisfied, export the changes to Azure AD.
1. Select Connectors and in the Connectors list, select the Azure AD Connector. From Actions, select Run.
2. In the Run profiles, select Export.
3. If your configuration changes delete many objects, then you see an error on the export when the number is
more than the configured threshold (by default 500). If you see this error, then you need to temporarily
disable the feature prevent accidental deletes.
Now it is time to enable the scheduler again.
1. Start Task Scheduler from the start menu.
2. Directly under Task Scheduler Library, find the task named Azure AD Sync Scheduler, right-click, and
select Enable.
Group-based filtering
Group-based filtering can be configured the first time you install Azure AD Connect using custom installation. It is
intended for a pilot deployment where only a small set of objects should be synchronized. When you have
disabled group-based filtering, it cannot be enabled again. It is not supported to use group based filtering in a
custom configuration. It is only supported to configure this feature with the installation wizard. When you have
completed your pilot, then you should use one of the other filtering options in this topic.
Next steps
Azure AD Connect sync: Scheduler
This topic describes the built-in scheduler in Azure AD Connect sync (a.k.a. sync engine).
This feature was introduced with build 1.1.105.0 (released February 2016).
Overview
Azure AD Connect sync synchronize changes occurring in your on-premises directory using a scheduler. There
are two scheduler processes, one for password sync and another for object/attribute sync and maintenance tasks.
This topic covers the latter.
In earlier releases, the scheduler for objects and attributes was external to the sync engine. It used Windows task
scheduler or a separate Windows service to trigger the synchronization process. The scheduler is with the 1.1
releases built-in to the sync engine and do allow some customization. The new default synchronization frequency
is 30 minutes.
The scheduler is responsible for two tasks:
Synchronization cycle. The process to import, sync, and export changes.
Maintenance tasks. Renew keys and certificates for Password reset and Device Registration Service (DRS).
Purge old entries in the operations log.
The scheduler itself is always running, but it can be configured to only run one or none of these tasks. For
example, if you need to have your own synchronization cycle process, you can disable this task in the scheduler
but still run the maintenance task.
Scheduler configuration
To see your current configuration settings, go to PowerShell and run Get-ADSyncScheduler . It shows you
something like this picture:
If you see The sync command or cmdlet is not available when you run this cmdlet, then the PowerShell
module is not loaded. This problem could happen if you run Azure AD Connect on a domain controller or on a
server with higher PowerShell restriction levels than the default settings. If you see this error, then run
Import-Module ADSync to make the cmdlet available.
AllowedSyncCycleInterval. The most frequently interval Azure AD allows synchronizations to occur. You
cannot synchronize more frequently than this setting and still be supported.
CurrentlyEffectiveSyncCycleInterval. The schedule currently in effect. It has the same value as
CustomizedSyncInterval (if set) if it is not more frequent than AllowedSyncInterval. If you use a build before
1.1.281 and you change CustomizedSyncCycleInterval, this change takes effect after next synchronization
cycle. From build 1.1.281 the change takes effect immediately.
CustomizedSyncCycleInterval. If you want the scheduler to run at any other frequency than the default 30
minutes, then you configure this setting. In the picture above, the scheduler has been set to run every hour
instead. If you set this setting to a value lower than AllowedSyncInterval, then the latter is used.
NextSyncCyclePolicyType. Either Delta or Initial. Defines if the next run should only process delta changes,
or if the next run should do a full import and sync. The latter would also reprocess any new or changed rules.
NextSyncCycleStartTimeInUTC. Next time the scheduler starts the next sync cycle.
PurgeRunHistoryInterval. The time operation logs should be kept. These logs can be reviewed in the
synchronization service manager. The default is to keep these logs for 7 days.
SyncCycleEnabled. Indicates if the scheduler is running the import, sync, and export processes as part of its
operation.
MaintenanceEnabled. Shows if the maintenance process is enabled. It updates the certificates/keys and
purges the operations log.
IsStagingModeEnabled. Shows if staging mode is enabled. If this setting is enabled, then it suppresses the
exports from running but still run import and synchronization.
You can change some of these settings with Set-ADSyncScheduler . The following parameters can be modified:
CustomizedSyncCycleInterval
NextSyncCyclePolicyType
PurgeRunHistoryInterval
SyncCycleEnabled
MaintenanceEnabled
The scheduler configuration is stored in Azure AD. If you have a staging server, any change on the primary server
also affects the staging server (except IsStagingModeEnabled).
CustomizedSyncCycleInterval
Syntax: Set-ADSyncScheduler -CustomizedSyncCycleInterval d.HH:mm:ss
d - days, HH - hours, mm - minutes, ss - seconds
Example: Set-ADSyncScheduler -CustomizedSyncCycleInterval 03:00:00
Changes the scheduler to run every 3 hours.
Example: Set-ADSyncScheduler -CustomizedSyncCycleInterval 1.0:0:0
Changes change the scheduler to run daily.
Disable the scheduler
If you need to make configuration changes, then you want to disable the scheduler. For example, when you
configure filtering or make changes to synchronization rules.
To disable the scheduler, run Set-ADSyncScheduler -SyncCycleEnabled $false .
When you've made your changes, do not forget to enable the scheduler again with
Set-ADSyncScheduler -SyncCycleEnabled $true .
Start the scheduler

The scheduler is by default run every 30 minutes. In some cases, you might want to run a sync cycle in between
the scheduled cycles or you need to run a different type.
Delta sync cycle
A delta sync cycle includes the following steps:
Delta import on all Connectors
Delta sync on all Connectors
Export on all Connectors
It could be that you have an urgent change that must be synchronized immediately, which is why you need to
manually run a cycle. If you need to manually run a cycle, then from PowerShell run
Start-ADSyncSyncCycle -PolicyType Delta .
Full sync cycle

If you have made one of the following configuration changes, you need to run a full sync cycle (a.k.a. Initial):
Added more objects or attributes to be imported from a source directory
Made changes to the Synchronization rules
Changed filtering so a different number of objects should be included
If you have made one of these changes, then you need to run a full sync cycle so the sync engine has the
opportunity to reconsolidate the connector spaces. A full sync cycle includes the following steps:
Full Import on all Connectors
Full Sync on all Connectors
Export on all Connectors
To initiate a full sync cycle, run Start-ADSyncSyncCycle -PolicyType Initial from a PowerShell prompt. This
command starts a full sync cycle.
Stop the scheduler

If the scheduler is currently running a synchronization cycle, you might need to stop it. For example if you start
the installation wizard and you get this error:
When a sync cycle is running, you cannot make configuration changes. You could wait until the scheduler has
finished the process, but you can also stop it so you can make your changes immediately. Stopping the current
cycle is not harmful and pending changes are processed with next run.
1. Start by telling the scheduler to stop its current cycle with the PowerShell cmdlet Stop-ADSyncSyncCycle .
2. If you use a build before 1.1.281, then stopping the scheduler does not stop the current Connector from its
current task. To force the Connector to stop, take the following actions:
Start Synchronization Service from the start menu. Go to Connectors, highlight the Connector with
the state Running, and select Stop from the Actions.
The scheduler is still active and starts again on next opportunity.
Custom scheduler
The cmdlets documented in this section are only available in build 1.1.130.0 and later.
If the built-in scheduler does not satisfy your requirements, then you can schedule the Connectors using
PowerShell.
Invoke -ADSyncRunProfile
You can start a profile for a Connector in this way:
Invoke-ADSyncRunProfile -ConnectorName "name of connector" -RunProfileName "name of profile"
The names to use for Connector names and Run Profile Names can be found in the Synchronization Service
Manager UI.
The Invoke-ADSyncRunProfile cmdlet is synchronous, that is, it does not return control until the Connector has
completed the operation, either successfully or with an error.
When you schedule your Connectors, the recommendation is to schedule them in the following order:
1. (Full/Delta) Import from on-premises directories, such as Active Directory
2. (Full/Delta) Import from Azure AD
3. (Full/Delta) Synchronization from on-premises directories, such as Active Directory
4. (Full/Delta) Synchronization from Azure AD
5. Export to Azure AD
6. Export to on-premises directories, such as Active Directory
This order is how the built-in scheduler runs the Connectors.
Get-ADSyncConnectorRunStatus
You can also monitor the sync engine to see if it is busy or idle. This cmdlet returns an empty result if the sync
engine is idle and is not running a Connector. If a Connector is running, it returns the name of the Connector.
Get-ADSyncConnectorRunStatus
In the picture above, the first line is from a state where the sync engine is idle. The second line from when the
Azure AD Connector is running.
Scheduler and installation wizard

If you start the installation wizard, then the scheduler is temporarily suspended. This behavior is because it is
assumed you make configuration changes and these settings cannot be applied if the sync engine is actively
running. For this reason, do not leave the installation wizard open since it stops the sync engine from performing
any synchronization actions.
Next steps
Azure AD Connect sync: Directory extensions
Directory extensions allows you to extend the schema in Azure AD with your own attributes from on-premises
Active Directory. This feature allows you to build LOB apps consuming attributes you continue to manage on-
premises. These attributes can be consumed through Azure AD Graph directory extensions or Microsoft Graph.
You can see the attributes available using Azure AD Graph explorer and Microsoft Graph explorer respectively.
At present no Office 365 workload consumes these attributes.
You configure which additional attributes you want to synchronize in the custom settings path in the installation
wizard.
The installation shows the following attributes, which are valid candidates:
User and Group object types
Single-valued attributes: String, Boolean, Integer, Binary
Multi-valued attributes: String, Binary
The list of attributes is read from the schema cache created during installation of Azure AD Connect. If you have
extended the Active Directory schema with additional attributes, then the schema must be refreshed before these
new attributes are visible.
An object in Azure AD can have up to 100 directory extensions attributes. The max length is 250 characters. If an
attribute value is longer, then it is truncated by the sync engine.
During installation of Azure AD Connect, an application is registered where these attributes are available. You can
see this application in the Azure portal.
These attributes are now available through Graph:
The attributes are prefixed with extension_{AppClientId}_. The AppClientId has the same value for all attributes in
your Azure AD tenant.
Next steps
Azure AD Connect sync: Synchronization Service
Manager
The Synchronization Service Manager UI is used to configure more advanced aspects of the sync engine and to
see the operational aspects of the service.
You start the Synchronization Service Manager UI from the start menu. It is named Synchronization Service
and can be found in the Azure AD Connect group.
Click the links at the top of this topic to learn more about the different tabs in the UI.
Next steps
Manager
The operations tab shows the results from the most recent operations. This tab is key to understand and
troubleshoot issues.
Understand the information visible in the operations tab

The top half shows all runs in chronic order. By default, the operations log keeps information about the last seven
days, but this setting can be changed with the scheduler. You want to look for any run that does not show a success
status. You can change the sorting by clicking the headers.
The Status column is the most important information and shows the most severe problem for a run. Here is a
quick summary of the most common statuses in order of priority to investigate (where * indicate several possible
error strings).
STATUS COMMENT
stopped-* The run could not complete. For example, if the remote system
is down and cannot be contacted.
stopped-error-limit There are more than 5,000 errors. The run was automatically
stopped due to the large number of errors.
completed-*-errors The run completed, but there are errors (fewer than 5,000)
that should be investigated.
STATUS COMMENT
completed-*-warnings The run completed, but some data is not in the expected state.
If you have errors, then this message is usually only a
symptom. Until you have addressed errors, you should not
investigate warnings.
success No issues.
When you select a row, the bottom updates to show the details of that run. To the far left of the bottom, you might
have a list saying Step #. This list only appears if you have multiple domains in your forest where each domain is
represented by a step. The domain name can be found under the heading Partition. Under Synchronization
Statistics, you can find more information about the number of changes that were processed. You can click the links
to get a list of the changed objects. If you have objects with errors, those errors show up under Synchronization
Errors.
Troubleshoot errors in operations tab
When you have errors, both the object in error and the error itself are links that provides more information.
Start by clicking the error string (sync-rule-error-function-triggered in the picture). You are first presented with
an overview of the object. To see the actual error, click the button Stack Trace. This trace provides debug level
information for the error.
TIP: You can right-click in the call stack information box, choose select all, and copy. You can then copy the
stack and look at the error in your favorite editor, such as Notepad.
If the error is from SyncRulesEngine, then the call stack information first has a list of all attributes on the
object. Scroll down until you see the heading InnerException =>.
The line after shows the error. In the picture above, the error is from a custom Sync Rule Fabrikam created.
If the error itself does not give enough information, then it is time to look at the data itself. You can click the link
with the object identifier and Follow an object and its data through the system.
Next steps
Manager
The Connectors tab is used to manage all systems the sync engine is connected to.
Connector actions
ACTION COMMENT
Create Do not use. For connecting to additional AD forests, use the

Properties Used for domain and OU filtering.
Delete Used to either delete the data in the connector space or to

delete connection to a forest.
Configure Run Profiles Except for domain filtering, nothing to configure here. You can
use this action to see already configured run profiles.
Run Used to start a one-off run of a profile.
Stop Stops a Connector currently running a profile.
Export Connector Do not use.

ACTION COMMENT
Import Connector Do not use.
Update Connector Do not use.
Refresh Schema Refreshes the cached schema. It is preferred to use the option
in the installation wizard instead, since that also updates sync
rules.
Search Connector Space Used to find objects and to Follow an object and its data
through the system.
Delete
The delete action is used for two different things.
The option Delete connector space only removes all data, but keep the configuration.
The option Delete Connector and connector space removes the data and the configuration. This option is used
when you do not want to connect to a forest anymore.
Both options sync all objects and update the metaverse objects. This action is a long running operation.
Configure Run Profiles
This option allows you to see the run profiles configured for a Connector.
Search Connector Space
The search connector space action is useful to find objects and troubleshoot data issues.
Start by selecting a scope. You can search based on data (RDN, DN, Anchor, Sub-Tree), or state of the object (all
other options).
If you for example do a Sub-Tree search, you get all objects in one OU.
From this grid you can select an object, select properties, and follow it from the source connector space, through
the metaverse, and to the target connector space.
Follow an object and its data through the system

When you are troubleshooting a problem with data, follow an object from the source connector space, to the
metaverse, and to the target connector space is a key procedure to understand why data does not have the
expected values.
Connector Space Object Properties
Import
When you open a cs object, there are several tabs at the top. The Import tab shows the data that is staged after an
import.
The Old Value shows what currently is stored in the system and the New Value what has been received from the
source system and has not been applied yet. In this case, since there is a synchronization error, the change cannot
be applied.
Error
The error page is only visible if there is a problem with the object. See the details on the operations page for more
information on how to troubleshoot synchronization errors.
Lineage
The lineage tab shows how the connector space object is related to the metaverse object. You can see when the
Connector last imported a change from the connected system and which rules applied to populate data in the
metaverse.
In the Action column, you can see there is one Inbound sync rule with the action Provision. That indicates that as
long as this connector space object is present, the metaverse object remains. If the list of sync rules instead shows a
sync rule with direction Outbound and Provision, it indicates that this object is deleted when the metaverse
object is deleted.
You can also see in the PasswordSync column that the inbound connector space can contribute changes to the
password since one sync rule has the value True. This password is then sent to Azure AD through the outbound
rule.
From the lineage tab, you can get to the metaverse by clicking Metaverse Object Properties.
At the bottom of all tabs are two buttons: Preview and Log.
Preview
The preview page is used to synchronize one single object. It is useful if you are troubleshooting some customer
sync rules and want to see the effect of a change on a single object. You can select between Full Sync and Delta
sync. You can also select between Generate Preview, which only keeps the change in memory, and Commit
Preview, which stages all changes to target connector spaces.
You can inspect the object and which rule applied for a particular attribute flow.
Log
The Log page is used to see the password sync status and history.
Metaverse Object Properties
Attributes
On the attributes tab, you can see the values and which Connector contributed it.
Connectors
The Connectors tab shows all connector spaces that have a representation of the object.
This tab also allows you to navigate to the connector space object.
Next steps
Manager
For most customers, there is nothing to configure here.
Next steps
Manager
The metaverse search tab is useful for troubleshooting data-related problems. In the top half, you can create a
query based on a combination of attributes. When you are satisfied with your query, click Search. The result is
visible in the bottom grid. You can select which columns should be visible with Column Settings.
In the search results, select an object and Properties to see the metaverse object properties.
Next steps
Active Directory Federation Services management
and customization with Azure AD Connect
This article details tasks related to Active Directory Federation Services (AD FS) that can be performed by using
Microsoft Azure Active Directory Connect, plus other common AD FS tasks that may be required for a complete
configuration of an AD FS farm.
TOPIC WHAT IT COVERS
AD FS management
Repair the trust Repairing the federation trust with Office 365
Add an AD FS server Expanding the AD FS farm with an additional AD FS server
Add an AD FS web application proxy server Expanding the AD FS farm with an additional WAP server
Add a federated domain Adding a federated domain
AD FS customization
Add a custom company logo or illustration Customizing an AD FS sign-in page with a company logo and
illustration
Add a sign-in description Adding a sign-in page description
Modify AD FS claim rules Modifying AD FS claims for various federation scenarios
AD FS management
Azure AD Connect provides various tasks related to AD FS that can be performed by using the Azure AD Connect
wizard with minimal user intervention. After you have finished installing Azure AD Connect by running the wizard,
you can run the wizard again to perform additional tasks.
Repair the trust
Azure AD Connect can check for the current health of the AD FS and Azure Active Directory trust and take
appropriate actions to repair the trust. Follow these steps to repair your Azure AD and AD FS trust.
1. Select Repair AAD and ADFS Trust from the list of additional tasks.
2. On the Connect to Azure AD page, provide your global administrator credentials for Azure AD, and click Next.
3. On the Remote access credentials page, enter the credentials for the domain administrator.
After you click Next, Azure AD Connect will check for certificate health and show any issues.
The Ready to configure page will show the list of actions that will be performed to repair the trust.
4. Click Install to repair the trust.
NOTE
Azure AD Connect can only repair or act on certificates that are self-signed. Azure AD Connect cannot repair third-party
certificates.
Add an AD FS server
NOTE
Azure AD Connect requires the PFX certificate file to add an AD FS server. Therefore, you can perform this operation only if
you configured the AD FS farm by using Azure AD Connect.
1. Select Deploy an additional Federation Server and click Next.

2. On the Connect to Azure AD page, enter your global administrator credentials for Azure AD and click Next.
3. Provide the domain administrator credentials.

4. Azure AD Connect will ask for the password of the PFX file that you provided while configuring your new
AD FS farm with Azure AD Connect. Click Enter Password to provide the password for the PFX file.
5. On the AD FS Servers page, enter the server name or IP address to be added to the AD FS farm.
6. Click Next and go through the final Configure page. After Azure AD Connect has finished adding the
servers to the AD FS farm, you will be given the option to verify the connectivity.
Add an AD FS web application proxy server
NOTE
Azure AD Connect requires the PFX certificate file to add a web application proxy server. Therefore, you will be able to
perform this operation only if you configured the AD FS farm by using Azure AD Connect.
1. Select Deploy Web Application Proxy from the list of available tasks.
2. Provide the Azure global administrator credentials.
3. On the Specify SSL certificate page, provide the password for the PFX file that you provided when
configuring the AD FS farm with Azure AD Connect.
4. Add the server to be added as a web application proxy. Because the web application proxy server might not be
joined to the domain, the wizard will ask for administrative credentials to the server being added.
5. On the Proxy trust credentials page, provide administrative credentials to configure the proxy trust and
access the primary server in the AD FS farm.
6. On the Ready to configure page, the wizard shows the list of actions that will be performed.
7. Click Install to finish the configuration. After the configuration is complete, the wizard gives you the option to
verify the connectivity to the servers. Click Verify to check connectivity.
Add a federated domain

It's easy to add a domain to be federated with Azure AD by using Azure AD Connect. Azure AD Connect adds the
domain for federation and modifies the claim rules to correctly reflect the issuer when you have multiple domains
federated with Azure AD.
1. To add a federated domain, select the task Add an additional Azure AD domain.
2. On the next page of the wizard, provide the global administrator credentials for Azure AD.
3. On the Remote access credentials page, provide the domain administrator credentials.
4. On the next page, the wizard will provide a list of Azure AD domains with which you can federate your on-
premises directory. Choose the domain from the list.
After you choose the domain, the wizard will provide you with appropriate information regarding further
actions that the wizard will take and the impact of the configuration. In some cases, if you select a domain
that is not yet verified in Azure AD, the wizard will provide you with information to help you verify the
domain. See Add your custom domain name to Azure Active Directory for more details.
5. Click Next, and the Ready to configure page will show the list of actions that Azure AD Connect will perform.
Click Install to finish the configuration.
AD FS customization
The following sections provide details about some of the common tasks that you may have to perform when
customizing your AD FS sign-in page.
Add a custom company logo or illustration
To change the logo of the company that is displayed on the Sign-in page, use the following Windows PowerShell
cmdlet and syntax.
NOTE
The recommended dimensions for the logo are 260x35 @ 96 dpi with a file size no greater than 10 KB.
Set-AdfsWebTheme -TargetName default -Logo @{path="c:\Contoso\logo.PNG"}
NOTE
The TargetName parameter is required. The default theme that is released with AD FS is named Default.
Add a sign-in description

To add a sign-in page description to the Sign-in page, use the following Windows PowerShell cmdlet and syntax.
Set-AdfsGlobalWebContent -SignInPageDescriptionText "<p>Sign-in to Contoso requires device registration. Click

<A href='http://fs1.contoso.com/deviceregistration/'>here</A> for more information.</p>"
Modify AD FS claim rules

AD FS supports a rich claim language that you can use to create custom claim rules. For more information, see The
Role of the Claim Rule Language.
The following sections describe how you can write custom rules for some scenarios pertaining to Azure AD and AD
FS federation.
Immutable ID conditional on a value being present in the attribute
Azure AD Connect lets you specify an attribute to be used as a source anchor when objects are synced to Azure AD.
If the value in the custom attribute is not empty, you might want to issue an immutable ID claim. For example, you
might select ms-ds-consistencyguid as the attribute for the source anchor and want to issue ImmutableID as
ms-ds-consistencyguid in case the attribute has a value against it. If there is no value against the attribute, issue
objectGuid as the immutable ID. You can construct the set of custom claim rules as described in the following
section.
Rule 1: Query attributes
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
=> add(store = "Active Directory", types = ("http://contoso.com/ws/2016/02/identity/claims/objectguid",
"http://contoso.com/ws/2016/02/identity/claims/msdsconcistencyguid"), query = "; objectGuid,ms-ds-
consistencyguid;{0}", param = c.Value);
In this rule, you are querying the values of ms-ds-consistencyguid and objectGuid for the user from Active
Directory. Change the store name to an appropriate store name in your AD FS deployment. Also change the claims
type to a proper claims type for your federation as defined for objectGuid and ms-ds-consistencyguid.
Also, by using add and not issue, you avoid adding an outgoing issue for the entity and can use the values as
intermediate values. You will issue the claim in a later rule after you establish which value to use as the immutable
ID.
Rule 2: Check if ms-ds-consistencyguid exists for the user
NOT EXISTS([Type == "http://contoso.com/ws/2016/02/identity/claims/msdsconcistencyguid"])

=> add(Type = "urn:anandmsft:tmp/idflag", Value = "useguid");
This rule defines a temporary flag called idflag that is set to useguid if there is no ms-ds-concistencyguid
populated for the user. The logic behind this is the fact that AD FS does not allow empty claims. So when you add
claims http://contoso.com/ws/2016/02/identity/claims/objectguid and
http://contoso.com/ws/2016/02/identity/claims/msdsconcistencyguid in Rule 1, you end up with an
msdsconsistencyguid claim only if the value is populated for the user. If it is not populated, AD FS sees that it will
have an empty value and drops it immediately. All objects will have objectGuid, so that claim will always be there
after Rule 1 is executed.
Rule 3: Issue ms-ds-consistencyguid as immutable ID if it's present
c:[Type == "http://contoso.com/ws/2016/02/identity/claims/msdsconcistencyguid"]
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Value = c.Value);
This is an implicit Exist check. If the value for the claim exists, then issue that as the immutable ID. The previous
example uses the nameidentifier claim. You will have to change this to the appropriate claim type for immutable
ID in your environment.
Rule 4: Issue objectGuid as immutable ID if ms-ds-consistencyGuid is not present
c1:[Type == "urn:anandmsft:tmp/idflag", Value =~ "useguid"]
&& c2:[Type == "http://contoso.com/ws/2016/02/identity/claims/objectguid"]
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Value = c2.Value);
In this rule, you are simply checking the temporary flag idflag. You decide whether to issue the claim based on its
value.
NOTE
The sequence of these rules is important.
SSO with a subdomain UPN

You can add more than one domain to be federated by using Azure AD Connect, as described in Add a new
federated domain. You must modify the UPN claim so that the issuer ID corresponds to the root domain and not
the subdomain, because the federated root domain also covers the child.
By default, the claim rule for issuer ID is set as:
c:[Type
== http://schemas.xmlsoap.org/claims/UPN]
=> issue(Type = http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid, Value =

regexreplace(c.Value, .+@(?<domain>.+), http://${domain}/adfs/services/trust/));
The default rule simply takes the UPN suffix and uses it in the issuer ID claim. For example, John is a user in
sub.contoso.com, and contoso.com is federated with Azure AD. John enters john@sub.contoso.com as the user
name while signing in to Azure AD, and the default issuer ID claim rule in AD FS handles it in the following manner.
c:[Type
== http://schemas.xmlsoap.org/claims/UPN]

regexreplace(john@sub.contoso.com, .+@(?<domain>.+), http://${domain}/adfs/services/trust/));
Claim value: http://sub.contoso.com/adfs/services/trust/
To have only the root domain in the issuer claim value, change the claim rule to match the following.
c:[Type == http://schemas.xmlsoap.org/claims/UPN]

regexreplace(c.Value, ^((.*)([.|@]))?(?<domain>[^.]*[.].*)$, http://${domain}/adfs/services/trust/));
Next steps
Learn more about user sign-in options.
Troubleshoot connectivity issues with Azure AD
Connect
This article explains how connectivity between Azure AD Connect and Azure AD works and how to troubleshoot
connectivity issues. These issues are most likely to be seen in an environment with a proxy server.
Troubleshoot connectivity issues in the installation wizard

Azure AD Connect is using Modern Authentication (using the ADAL library) for authentication. The installation
wizard and the sync engine proper require machine.config to be properly configured since these two are .NET
applications.
In this article, we show how Fabrikam connects to Azure AD through its proxy. The proxy server is named
fabrikamproxy and is using port 8080.
First we need to make sure machine.config is correctly configured.
NOTE
In some non-Microsoft blogs, it is documented that changes should be made to miiserver.exe.config instead. However, this
file is overwritten on every upgrade so even if it works during initial install, the system stops working on first upgrade. For
that reason, the recommendation is to update machine.config instead.
The proxy server must also have the required URLs opened. The official list is documented in Office 365 URLs and
IP address ranges.
Of these URLs, the following table is the absolute bare minimum to be able to connect to Azure AD at all. This list
does not include any optional features, such as password writeback, or Azure AD Connect Health. It is documented
here to help in troubleshooting for the initial configuration.
URL PORT DESCRIPTION
mscrl.microsoft.com HTTP/80 Used to download CRL lists.
*.verisign.com HTTP/80 Used to download CRL lists.
*.entrust.com HTTP/80 Used to download CRL lists for MFA.

URL PORT DESCRIPTION
*.windows.net HTTPS/443 Used to sign in to Azure AD.
secure.aadcdn.microsoftonline-p.com HTTPS/443 Used for MFA.
*.microsoftonline.com HTTPS/443 Used to configure your Azure AD

directory and import/export data.
Errors in the wizard

The installation wizard is using two different security contexts. On the page Connect to Azure AD, it is using the
currently signed in user. On the page Configure, it is changing to the account running the service for the sync
engine. If there is an issue, it appears most likely already at the Connect to Azure AD page in the wizard since the
proxy configuration is global.
The following issues are the most common errors you encounter in the installation wizard.
The installation wizard has not been correctly configured
This error appears when the wizard itself cannot reach the proxy.
If you see this error, verify the machine.config has been correctly configured.
If that looks correct, follow the steps in Verify proxy connectivity to see if the issue is present outside the wizard
as well.
A Microsoft account is used
If you use a Microsoft account rather than a school or organization account, you see a generic error.
The MFA endpoint cannot be reached

This error appears if the endpoint https://secure.aadcdn.microsoftonline-p.com cannot be reached and your
global admin has MFA enabled.
If you see this error, verify that the endpoint secure.aadcdn.microsoftonline-p.com has been added to the
proxy.
The password cannot be verified
If the installation wizard is successful in connecting to Azure AD, but the password itself cannot be verified you see
this error:
Is the password a temporary password and must be changed? Is it actually the correct password? Try to sign in
to https://login.microsoftonline.com (on another computer than the Azure AD Connect server) and verify the
account is usable.
Verify proxy connectivity
To verify if the Azure AD Connect server has actual connectivity with the Proxy and Internet, use some PowerShell
to see if the proxy is allowing web requests or not. In a PowerShell prompt, run
Invoke-WebRequest -Uri https://adminwebservice.microsoftonline.com/ProvisioningService.svc . (Technically the first
call is to https://login.microsoftonline.com and this URI works as well, but the other URI is faster to respond.)
PowerShell uses the configuration in machine.config to contact the proxy. The settings in winhttp/netsh should not
impact these cmdlets.
If the proxy is correctly configured, you should get a success status:
If you receive Unable to connect to the remote server, then PowerShell is trying to make a direct call without
using the proxy or DNS is not correctly configured. Make sure the machine.config file is correctly configured.
If the proxy is not correctly configured, you get an error:
ERROR ERROR TEXT COMMENT
403 Forbidden The proxy has not been opened for the
requested URL. Revisit the proxy
configuration and make sure the URLs
have been opened.
407 Proxy Authentication Required The proxy server required a sign-in and
none was provided. If your proxy server
requires authentication, make sure to
have this setting configured in the
machine.config. Also make sure you are
using domain accounts for the user
running the wizard and for the service
account.
The communication pattern between Azure AD Connect and Azure

AD
If you have followed all these preceding steps and still cannot connect, you might at this point start looking at
network logs. This section is documenting a normal and successful connectivity pattern. It is also listing common
red herrings that can be ignored when you are reading the network logs.
There are calls to https://dc.services.visualstudio.com. It is not required to have this URL open in the proxy for
the installation to succeed and these calls can be ignored.
You see that dns resolution lists the actual hosts to be in the DNS name space nsatc.net and other namespaces
not under microsoftonline.com. However, there are not any web service requests on the actual server names
and you do not have to add these URLs to the proxy.
The endpoints adminwebservice and provisioningapi are discovery endpoints and used to find the actual
endpoint to use. These endpoints are different depending on your region.
Reference proxy logs
Here is a dump from an actual proxy log and the installation wizard page from where it was taken (duplicate
entries to the same endpoint have been removed). This section can be used as a reference for your own proxy and
network logs. The actual endpoints might be different in your environment (in particular those URLs in italic).
Connect to Azure AD
TIME URL
1/11/2016 8:31 connect://login.microsoftonline.com:443
1/11/2016 8:31 connect://adminwebservice.microsoftonline.com:443
1/11/2016 8:32 connect://bba800-anchor.microsoftonline.com:443
1/11/2016 8:33 connect://provisioningapi.microsoftonline.com:443
1/11/2016 8:33 connect://bwsc02-relay.microsoftonline.com:443
Configure
TIME URL
1/11/2016 8:46 connect://provisioningapi.microsoftonline.com:443
1/11/2016 8:46 connect://bwsc02-relay.microsoftonline.com:443
Initial Sync
TIME URL
1/11/2016 8:48 connect://login.windows.net:443
Authentication errors
This section covers errors that can be returned from ADAL (the authentication library used by Azure AD Connect)
and PowerShell. The error explained should help you in understand your next steps.
Invalid Grant
Invalid username or password. For more information, see The password cannot be verified.
Unknown User Type
Your Azure AD directory cannot be found or resolved. Maybe you try to login with a username in an unverified
domain?
User Realm Discovery Failed
Network or proxy configuration issues. The network cannot be reached. See Troubleshoot connectivity issues in
the installation wizard.
User Password Expired
Your credentials have expired. Change your password.
AuthorizationFailure
Unknown issue.
Authentication Cancelled
The multi-factor authentication (MFA) challenge was cancelled.
ConnectToMSOnline
Authentication was successful, but Azure AD PowerShell has an authentication problem.
AzureRoleMissing
Authentication was successful. You are not a global administrator.
PrivilegedIdentityManagement
Authentication was successful. Privileged identity management has been enabled and you are currently not a
global administrator. For more information, see Privileged Identity Management.
CompanyInfoUnavailable
Authentication was successful. Could not retrieve company information from Azure AD.
RetrieveDomains
Authentication was successful. Could not retrieve domain information from Azure AD.
Unexpected exception
Shown as Unexpected error in the installation wizard. Can happen if you try to use a Microsoft Account rather
than a school or organization account.
Troubleshooting steps for previous releases.
With releases starting with build number 1.1.105.0 (released February 2016), the sign-in assistant was retired. This
section and the configuration should no longer be required, but is kept as reference.
For the single-sign in assistant to work, winhttp must be configured. This configuration can be done with netsh.
The Sign-in assistant has not been correctly configured

This error appears when the Sign-in assistant cannot reach the proxy or the proxy is not allowing the request.
If you see this error, look at the proxy configuration in netsh and verify it is correct.
If that looks correct, follow the steps in Verify proxy connectivity to see if the issue is present outside the wizard
as well.
Next steps
Troubleshooting Errors during synchronization
Errors could occur when identity data is synchronized from Windows Server Active Directory (AD DS) to Azure
Active Directory (Azure AD). This article provides an overview of different types of sync errors, some of the possible
scenarios that cause those errors and potential ways to fix the errors. This article includes the common error types
and may not cover all the possible errors.
This article assumes the reader is familiar with the underlying design concepts of Azure AD and Azure AD Connect.
With the latest version of Azure AD Connect (August 2016 or higher), a report of Synchronization Errors is available
in the Azure Portal as part of Azure AD Connect Health for sync.
Starting September 1, 2016 Azure Active Directory Duplicate Attribute Resiliency feature will be enabled by default
for all the new Azure Active Directory Tenants. This feature will be automatically enabled for existing tenants in the
upcoming months.
Azure AD Connect performs 3 types of operations from the directories it keeps in sync: Import, Synchronization and
Export. Errors can take place in all the operations. This article mainly focuses on errors during Export to Azure AD.
Errors during Export to Azure AD

Following section describes different types of synchronization errors that can occur during the export operation to
Azure AD using the Azure AD connector. This connector can be identified by the name format being
"contoso.onmicrosoft.com". Errors during Export to Azure AD indicate that the operation (add, update, delete etc.)
attempted by Azure AD Connect (Sync Engine) on Azure Active Directory failed.
Data Mismatch Errors

InvalidSoftMatch
Description
When Azure AD Connect (sync engine) instructs Azure Active Directory to add or update objects, Azure AD
matches the incoming object using the sourceAnchor attribute to the immutableId attribute of objects in
Azure AD. This match is called a Hard Match.
When Azure AD does not find any object that matches the immutableId attribute with the sourceAnchor
attribute of the incoming object, before provisioning a new object, it falls back to use the ProxyAddresses and
UserPrincipalName attributes to find a match. This match is called a Soft Match. The Soft Match is designed to
match objects already present in Azure AD (that are sourced in Azure AD) with the new objects being
added/updated during synchronization that represent the same entity (users, groups) on premises.
InvalidSoftMatch error occurs when the hard match does not find any matching object AND soft match finds
a matching object but that object has a different value of immutableId than the incoming object's SourceAnchor,
suggesting that the matching object was synchronized with another object from on premises Active Directory.
In other words, in order for the soft match to work, the object to be soft-matched with should not have any value
for the immutableId. If any object with immutableId set with a value is failing the hard-match but satisfying the
soft-match criteria, the operation would result in an InvalidSoftMatch synchronization error.
Azure Active Directory schema does not allow two or more objects to have the same value of the following
attributes. (This is not an exhaustive list.)
ProxyAddresses
UserPrincipalName
onPremisesSecurityIdentifier
ObjectId
NOTE
Azure AD Attribute Duplicate Attribute Resiliency feature is also being rolled out as the default behavior of Azure Active
Directory. This will reduce the number of synchronization errors seen by Azure AD Connect (as well as other sync clients) by
making Azure AD more resilient in the way it handles duplicated ProxyAddresses and UserPrincipalName attributes present in
on premises AD environments. This feature does not fix the duplication errors. So the data still needs to be fixed. But it allows
provisioning of new objects which are otherwise blocked from being provisioned due to duplicated values in Azure AD. This
will also reduce the number of synchronization errors returned to the synchronization client. If this feature is enabled for your
Tenant, you will not see the InvalidSoftMatch synchronization errors seen during provisioning of new objects.
Example Scenarios for InvalidSoftMatch

1. Two or more objects with the same value of ProxyAddresses attribute exists in on premises Active Directory.
Only one is getting provisioned in Azure AD.
2. Two or more objects with the same value of userPrincipalName exists in on premises Active Directory. Only one
is getting provisioned in Azure AD.
3. An object was added in the on premises Active Directory with the same value of ProxyAddresses attribute as
that of an existing object in Azure Active Directory. The object added on premises is not getting provisioned in
Azure Active Directory.
4. An object was added in on premises Active Directory with the same value of userPrincipalName attribute as that
of an account in Azure Active Directory. The object is not getting provisioned in Azure Active Directory.
5. A synced account was moved from Forest A to Forest B. Azure AD Connect (sync engine) was using ObjectGUID
attribute to compute the SourceAnchor. After the forest move, the value of the SourceAnchor is different. The
new object (from Forest B) is failing to sync with the existing object in Azure AD.
6. A synced object got accidentally deleted from on premises Active Directory and a new object was created in
Active Directory for the same entity (such as user) without deleting the account in Azure Active Directory. The
new account fails to sync with the existing Azure AD object.
7. Azure AD Connect was uninstalled and re-installed. During the re-installation, a different attribute was chosen as
the SourceAnchor. All the objects that had previously synced stopped syncing with InvalidSoftMatch error.
Example case:
1. Bob Smith is a synced user in Azure Active Directory from on premises Active Directory of contoso.com
2. Bob Smith's UserPrincipalName is set as bobs@contoso.com.
3. "abcdefghijklmnopqrstuv==" is the SourceAnchor calculated by Azure AD Connect using Bob Smith's
objectGUID from on premises Active Directory, which is the immutableId for Bob Smith in Azure Active
Directory.
4. Bob also has following values for the proxyAddresses attribute:
smtp:bobs@contoso.com
smtp:bob.smith@contoso.com
smtp:bob@contoso.com
5. A new user, Bob Taylor, is added to the on premises Active Directory.
6. Bob Taylor's UserPrincipalName is set as bobt@contoso.com.
7. "abcdefghijkl0123456789=="" is the sourceAnchor calculated by Azure AD Connect using Bob Taylor's
objectGUID from on premises Active Directory. Bob Taylor's object has NOT synced to Azure Active Directory
yet.
8. Bob Taylor has the following values for the proxyAddresses attribute
smtp:bobt@contoso.com
smtp:bob.taylor@contoso.com
9. During sync, Azure AD Connect will recognize the addition of Bob Taylor in on premises Active Directory and ask
Azure AD to make the same change.
10. Azure AD will first perform hard match. That is, it will search if there is any object with the immutableId equal to
"abcdefghijkl0123456789==". Hard Match will fail as no other object in Azure AD will have that immutableId.
11. Azure AD will then attempt to soft-match Bob Taylor. That is, it will search if there is any object with
proxyAddresses equal to the three values, including smtp:bob@contoso.com
12. Azure AD will find Bob Smith's object to match the soft-match criteria. But this object has the value of
immutableId = "abcdefghijklmnopqrstuv==". which indicates this object was synced from another object from
on premises Active Directory. Thus, Azure AD cannot soft-match these objects and results in an
InvalidSoftMatch sync error.
How to fix InvalidSoftMatch error
The most common reason for the InvalidSoftMatch error is two objects with different SourceAnchor (immutableId)
have the same value for the ProxyAddresses and/or UserPrincipalName attributes, which are used during the soft-
match process on Azure AD. In order to fix the Invalid Soft Match
1. Identify the duplicated proxyAddresses, userPrincipalName or other attribute value that's causing the error. Also
identify which two (or more) objects are involved in the conflict. The report generated by Azure AD Connect
Health for sync can help you identify the two objects.
2. Identify which object should continue to have the duplicated value and which object should not.
3. Remove the duplicated value from the object that should NOT have that value. Note that you should make the
change in the directory where the object is sourced from. In some cases, you may need to delete one of the
objects in conflict.
4. If you made the change in the on premises AD, let Azure AD Connect sync the change.
Note that Sync error report within Azure AD Connect Health for sync is updated every 30 minutes and includes the
errors from the latest synchronization attempt.
NOTE
ImmutableId, by definition, should not change in the lifetime of the object. If Azure AD Connect was not configured with
some of the scenarios in mind from the above list, you could end up in a situation where Azure AD Connect calculates a
different value of the SourceAnchor for the AD object that represents the same entity (same user/group/contact etc) that has
an existing Azure AD Object that you wish to continue using.
Related Articles
Duplicate or invalid attributes prevent directory synchronization in Office 365
ObjectTypeMismatch
Description
When Azure AD attempts to soft match two objects, it is possible that two objects of different "object type" (such as
User, Group, Contact etc.) have the same values for the attributes used to perform the soft match. As duplication of
these attributes is not permitted in Azure AD, the operation can result in "ObjectTypeMismatch" synchronization
error.
Example Scenarios for ObjectTypeMismatch error
A mail enabled security group is created in Office 365. Admin adds a new user or contact in on premises AD
(that's not synchronized to Azure AD yet) with the same value for the ProxyAddresses attribute as that of the
Office 365 group.
Example case
1. Admin creates a new mail enabled security group in Office 365 for the Tax department and provides an email
address as tax@contoso.com. This assigns the ProxyAddresses attribute for this group with the value of
smtp:tax@contoso.com
2. A new user joins Contoso.com and an account is created for the user on premises with the proxyAddress as
smtp:tax@contoso.com
3. When Azure AD Connect will sync the new user account, it will get the "ObjectTypeMismatch" error.
How to fix ObjectTypeMismatch error
The most common reason for the ObjectTypeMismatch error is two objects of different type (User, Group, Contact
etc.) have the same value for the ProxyAddresses attribute. In order to fix the ObjectTypeMismatch:
1. Identify the duplicated proxyAddresses (or other attribute) value that's causing the error. Also identify which two
(or more) objects are involved in the conflict. The report generated by Azure AD Connect Health for sync can
help you identify the two objects.
4. If you made the change in the on premises AD, let Azure AD Connect sync the change. Sync error report within
Azure AD Connect Health for sync gets updated every 30 minutes and includes the errors from the latest
synchronization attempt.
Duplicate Attributes
AttributeValueMustBeUnique
Description
Azure Active Directory schema does not allow two or more objects to have the same value of the following
attributes. That is each object in Azure AD is forced to have a unique value of these attributes at a given instance.
ProxyAddresses
UserPrincipalName
If Azure AD Connect attempts to add a new object or update an existing object with a value for the above attributes
that is already assigned to another object in Azure Active Directory, the operation results in the
"AttributeValueMustBeUnique" sync error.
Possible Scenarios:
1. Duplicate value is assigned to an already synced object, which conflicts with another synced object.
Example case:
1. Bob Smith is a synced user in Azure Active Directory from on premises Active Directory of contoso.com
2. Bob Smith's UserPrincipalName on premises is set as bobs@contoso.com.
3. Bob also has following values for the proxyAddresses attribute:
smtp:bobs@contoso.com
smtp:bob.smith@contoso.com
4. A new user, Bob Taylor, is added to the on premises Active Directory.
5. Bob Taylor's UserPrincipalName is set as bobt@contoso.com.
6. Bob Taylor has the following values for the ProxyAddresses attribute i. smtp:bobt@contoso.com ii.
smtp:bob.taylor@contoso.com
7. Bob Taylor's object is synchronized with Azure AD successfully.
8. Admin decided to update Bob Taylor's ProxyAddresses attribute with the following value: i.
9. Azure AD will attempt to update Bob Taylor's object in Azure AD with the above value, but that operation will fail
as that ProxyAddresses value is already assigned to Bob Smith, resulting in "AttributeValueMustBeUnique" error.
How to fix AttributeValueMustBeUnique error
The most common reason for the AttributeValueMustBeUnique error is two objects with different SourceAnchor
(immutableId) have the same value for the ProxyAddresses and/or UserPrincipalName attributes. In order to fix
AttributeValueMustBeUnique error
1. Identify the duplicated proxyAddresses, userPrincipalName or other attribute value that's causing the error. Also
identify which two (or more) objects are involved in the conflict. The report generated by Azure AD Connect
Health for sync can help you identify the two objects.
4. If you made the change in the on premises AD, let Azure AD Connect sync the change for the error to get fixed.
Related Articles
-Duplicate or invalid attributes prevent directory synchronization in Office 365
Data Validation Failures

IdentityDataValidationFailed
Description
Azure Active Directory enforces various restrictions on the data itself before allowing that data to be written into
the directory. This is to ensure that end users get the best possible experiences while using the applications that
depend on this data.
Scenarios
a. The UserPrincipalName attribute value has invalid/unsupported characters. b. The UserPrincipalName attribute
does not follow the required format.
How to fix IdentityDataValidationFailed error
a. Ensure that the userPrincipalName attribute has supported characters and required format.
Related Articles
Prepare to provision users through directory synchronization to Office 365
DataValidationFailed
Description
This is a specific case that results in a "DataValidationFailed" sync error when the suffix of a user's
UserPrincipalName is changed from one federated domain to another federated domain.
Scenarios
For a synchronized user, the UserPrincipalName suffix was changed from one federated domain to another
federated domain on premises. For example, UserPrincipalName = bob@contoso.com was changed to
UserPrincipalName = bob@fabrikam.com.
Example
1. Bob Smith, an account for Contoso.com, gets added as a new user in Active Directory with the
UserPrincipalName bob@contoso.com
2. Bob moves to a different division of Contoso.com called Fabrikam.com and his UserPrincipalName is changed to
bob@fabrikam.com
3. Both contoso.com and fabrikam.com domains are federated domains with Azure Active Directory.
4. Bob's userPrincipalName does not get updated and results in a "DataValidationFailed" sync error.
How to fix
If a user's UserPrincipalName suffix was updated from bob@contoso.com to bob@fabrikam.com, where both
contoso.com and fabrikam.com are federated domains, then follow these steps to fix the sync error
1. Update the user's UserPrincipalName in Azure AD from bob@contoso.com to bob@contoso.onmicrosoft.com.
You can use the following PowerShell command with the Azure AD PowerShell Module:
Set-MsolUserPrincipalName -UserPrincipalName bob@contoso.com -NewUserPrincipalName
bob@contoso.onmicrosoft.com
2. Allow the next sync cycle to attempt synchronization. This time synchronization will be successful and it will
update the UserPrincipalName of Bob to bob@fabrikam.com as expected.
Related Articles
Changes aren't synced by the Azure Active Directory Sync tool after you change the UPN of a user account to
use a different federated domain
LargeObject
Description
When an attribute exceeds the allowed size limit, length limit or count limit set by Azure Active Directory schema,
the synchronization operation results in the LargeObject or ExceededAllowedLength sync error. Typically this
error occurs for the following attributes
userCertificate
thumbnailPhoto
proxyAddresses
Possible Scenarios
1. Bob's userCertificate attribute is storing too many certificates assigned to Bob. These may include older, expired
certificates. The hard limit is 50 certificates, but the recommendation is to have less than 25 certificates.
2. Bob's thumbnailPhoto set in Active Directory is too large to be synced in Azure AD.
3. During automatic population of the ProxyAddresses attribute in Active Directory, an object got assigned >500
ProxyAddresses.
How to fix
1. Ensure that the attribute causing the error is within the allowed limitation.
Related links
Locate Active Directory Objects in Active Directory Administrative Center
How to query Azure Active Directory for an object using Azure Active Directory PowerShell
Identity synchronization and duplicate attribute
resiliency
Duplicate Attribute Resiliency is a feature in Azure Active Directory that will eliminate friction caused by
UserPrincipalName and ProxyAddress conflicts when running one of Microsofts synchronization tools.
These two attributes are generally required to be unique across all User, Group, or Contact objects in a given
Azure Active Directory tenant.
NOTE
Only Users can have UPNs.
The new behavior that this feature enables is in the cloud portion of the sync pipeline, therefore it is client agnostic
and relevant for any Microsoft synchronization product including Azure AD Connect, DirSync and MIM +
Connector. The generic term sync client is used in this document to represent any one of these products.
Current behavior
If there is an attempt to provision a new object with a UPN or ProxyAddress value that violates this uniqueness
constraint, Azure Active Directory blocks that object from being created. Similarly, if an object is updated with a
non-unique UPN or ProxyAddress, the update fails. The provisioning attempt or update is retried by the sync client
upon each export cycle, and continues to fail until the conflict is resolved. An error report email is generated upon
each attempt and an error is logged by the sync client.
Behavior with Duplicate Attribute Resiliency

Instead of completely failing to provision or update an object with a duplicate attribute, Azure Active Directory
quarantines the duplicate attribute which would violate the uniqueness constraint. If this attribute is required for
provisioning, like UserPrincipalName, the service assigns a placeholder value. The format of these temporary
values is
+<4DigitNumber>@.onmicrosoft.com.
If the attribute is not required, like a ProxyAddress, Azure Active Directory simply quarantines the conflict
attribute and proceeds with the object creation or update.
Upon quarantining the attribute, information about the conflict is sent in the same error report email used in the
old behavior. However, this info only appears in the error report one time, when the quarantine happens, it does
not continue to be logged in future emails. Also, since the export for this object has succeeded, the sync client does
not log an error and does not retry the create / update operation upon subsequent sync cycles.
To support this behavior a new attribute has been added to the User, Group, and Contact object classes:
DirSyncProvisioningErrors
This is a multi-valued attribute that is used to store the conflicting attributes that would violate the uniqueness
constraint should they be added normally. A background timer task has been enabled in Azure Active Directory
that runs every hour to look for duplicate attribute conflicts that have been resolved, and automatically removes
the attributes in question from quarantine.
Enabling Duplicate Attribute Resiliency
Duplicate Attribute Resiliency will be the new default behavior across all Azure Active Directory tenants. It will be
on by default for all tenants that enabled synchronization for the first time on August 22nd, 2016 or later. Tenants
that enabled sync prior to this date will have the feature enabled in batches. This rollout will begin in September
2016, and an email notification will be sent to each tenant's technical notification contact with the specific date
when the feature will be enabled.
Once Duplicate Attribute Resiliency has been turned on it cannot be disabled.
To check if the feature is enabled for your tenant, you can do so by downloading the latest version of the Azure
Active Directory PowerShell module and running:
Get-MsolDirSyncFeatures -Feature DuplicateUPNResiliency
Get-MsolDirSyncFeatures -Feature DuplicateProxyAddressResiliency
If you would like to proactively enable the feature before it is turned on for your tenant, you can do so by
downloading the latest version of the Azure Active Directory PowerShell module and running:
Set-MsolDirSyncFeature -Feature DuplicateUPNResiliency -Enable $true
Set-MsolDirSyncFeature -Feature DuplicateProxyAddressResiliency -Enable $true
Identifying Objects with DirSyncProvisioningErrors

There are currently two methods to identify objects that have these errors due to duplicate property conflicts,
Azure Active Directory PowerShell and the Office 365 Admin Portal. There are plans to extend to additional portal
based reporting in the future.
Azure Active Directory PowerShell
For the PowerShell cmdlets in this topic, the following is true:
All of the following cmdlets are case sensitive.
The ErrorCategory PropertyConflict must always be included. There are currently no other types of
ErrorCategory, but this may be extended in the future.
First, get started by running Connect-MsolService and entering credentials for a tenant administrator.
Then, use the following cmdlets and operators to view errors in different ways:
1. See All
2. By Property Type
3. By Conflicting Value
4. Using a String Search
5. Sorted
6. In a Limited Quantity or All
See all
Once connected, to see a general list of attribute provisioning errors in the tenant run:
Get-MsolDirSyncProvisioningError -ErrorCategory PropertyConflict
This produces a result like the following:

By property type
To see errors by property type, add the -PropertyName flag with the UserPrincipalName or ProxyAddresses
argument:
Get-MsolDirSyncProvisioningError -ErrorCategory PropertyConflict -PropertyName UserPrincipalName
Or
Get-MsolDirSyncProvisioningError -ErrorCategory PropertyConflict -PropertyName ProxyAddresses
By conflicting value
To see errors relating to a specific property add the -PropertyValue flag (-PropertyName must be used as well
when adding this flag):
Get-MsolDirSyncProvisioningError -ErrorCategory PropertyConflict -PropertyValue User@domain.com -PropertyName
UserPrincipalName
Using a string search

To do a broad string search use the -SearchString flag. This can be used independently from all of the above
flags, with the exception of -ErrorCategory PropertyConflict, which is always required:
Get-MsolDirSyncProvisioningError -ErrorCategory PropertyConflict -SearchString User
In a limited quantity or all

1. MaxResults can be used to limit the query to a specific number of values.
2. All can be used to ensure all results are retrieved in the case that a large number of errors exists.
Get-MsolDirSyncProvisioningError -ErrorCategory PropertyConflict -MaxResults 5
Office 365 admin portal

You can view directory synchronization errors in the Office 365 admin center. The report in the Office 365 portal
only displays User objects that have these errors. It does not show info about conflicts between Groups and
Contacts.
For instructions on how to view directory synchronization errors in the Office 365 admin center, see Identify
directory synchronization errors in Office 365.
Identity synchronization error report
When an object with a duplicate attribute conflict is handled with this new behavior a notification is included in the
standard Identity Synchronization Error Report email that is sent to the Technical Notification contact for the
tenant. However, there is an important change in this behavior. In the past, information about a duplicate attribute
conflict would be included in every subsequent error report until the conflict was resolved. With this new behavior,
the error notification for a given conflict does only appear once- at the time the conflicting attribute is quarantined.
Here is an example of what the email notification looks like for a ProxyAddress conflict:
Resolving conflicts
Troubleshooting strategy and resolution tactics for these errors should not differ from the way duplicate attribute
errors were handled in the past. The only difference is that the timer task sweeps through the tenant on the
service-side to automatically add the attribute in question to the proper object once the conflict is resolved.
The following article outlines various troubleshooting and resolution strategies: Duplicate or invalid attributes
prevent directory synchronization in Office 365.
Known issues
None of these known issues causes data loss or service degradation. Several of them are aesthetic, others cause
standard pre-resiliency duplicate attribute errors to be thrown instead of quarantining the conflict attribute, and
another causes certain errors to require extra manual fix-up.
Core behavior:
1. Objects with specific attribute configurations continue to receive export errors as opposed to the duplicate
attribute(s) being quarantined.
For example:
a. New user is created in AD with a UPN of Joe@contoso.com and ProxyAddress
smtp:Joe@contoso.com
b. The properties of this object conflict with an existing Group, where ProxyAddress is
SMTP:Joe@contoso.com.
c. Upon export, a ProxyAddress conflict error is thrown instead of having the conflict attributes
quarantined. The operation is retried upon each subsequent sync cycle, as it would have been before the
resiliency feature was enabled.
2. If two Groups are created on-premises with the same SMTP address, one fails to provision on the first attempt
with a standard duplicate ProxyAddress error. However, the duplicate value is properly quarantined upon the
next sync cycle.
Office Portal Report:
1. The detailed error message for two objects in a UPN conflict set is the same. This indicates that they have both
had their UPN changed / quarantined, when in fact only a one of them had any data changed.
2. The detailed error message for a UPN conflict shows the wrong displayName for a user who has had their
UPN changed/quarantined. For example:
a. User A syncs up first with UPN = User@contoso.com.
b. User B is attempted to be synced up next with UPN = User@contoso.com.
c. User Bs UPN is changed to User1234@contoso.onmicrosoft.com and User@contoso.com is added
to DirSyncProvisioningErrors.
d. The error message for User B should indicate that User A already has User@contoso.com as a UPN,
but it shows User Bs own displayName.
Identity synchronization error report:
The link for steps on how to resolve this issue is incorrect:
It should point to https://aka.ms/duplicateattributeresiliency.
See also
Azure AD Connect sync
Identify directory synchronization errors in Office 365
Hybrid Identity Required Ports and Protocols
The following document is a technical reference on the required ports and protocols for implementing a hybrid
identity solution. Use the following illustration and refer to the corresponding table.
Table 1 - Azure AD Connect and On-premises AD

This table describes the ports and protocols that are required for communication between the Azure AD Connect
server and on-premises AD.
PROTOCOL PORTS DESCRIPTION
DNS 53 (TCP/UDP) DNS lookups on the destination forest.
Kerberos 88 (TCP/UDP) Kerberos authentication to the AD

forest.
MS-RPC 135 (TCP/UDP) Used during the initial configuration of

the Azure AD Connect wizard when it
binds to the AD forest.
LDAP 389 (TCP/UDP) Used for data import from AD. Data is
encrypted with Kerberos Sign & Seal.
LDAP/SSL 636 (TCP/UDP) Used for data import from AD. The data
transfer is signed and encrypted. Only
used if you are using SSL.
RPC 49152- 65535 (Random high RPC Port) Used during the initial configuration of
(TCP/UDP) Azure AD Connect when it binds to the
AD forests. See KB929851, KB832017,
and KB224196 for more information.
Table 2 - Azure AD Connect and Azure AD

server and Azure AD.
HTTP 80 (TCP/UDP) Used to download CRLs (Certificate

Revocation Lists) to verify SSL
certificates.
HTTPS 443(TCP/UDP) Used to synchronize with Azure AD.
For a list of URLs and IP addresses you need to open in your firewall, see Office 365 URLs and IP address ranges.
Table 3 - Azure AD Connect and AD FS Federation Servers/WAP

server and AD FS Federation/WAP servers.
HTTP 80 (TCP/UDP) Used to download CRLs (Certificate

Revocation Lists) to verify SSL
certificates.
HTTPS 443(TCP/UDP) Used to synchronize with Azure AD.
WinRM 5985 WinRM Listener
Table 4 - WAP and Federation Servers

This table describes the ports and protocols that are required for communication between the Federation servers
and WAP servers.
HTTPS 443(TCP/UDP) Used for authentication.
Table 5 - WAP and Users

This table describes the ports and protocols that are required for communication between users and the WAP
servers.
HTTPS 443(TCP/UDP) Used for device authentication.
TCP 49443 (TCP) Used for certificate authentication.
Table 6a & 6b - Pass-through Authentication with Single Sign On

(SSO) and Password Hash Sync with Single Sign On (SSO)
The following tables describes the ports and protocols that are required for communication between the Azure AD
Connect and Azure AD.
Table 6a - Pass-through Authentication with SSO
PROTOCOL PORT NUMBER DESCRIPTION
HTTP 80 Enable outbound HTTP traffic for

security validation such as SSL.
HTTPS 443 Enable user authentication against

Azure AD
HTTPS 1010010120 Enable responses from the connector

back to the Azure AD
Azure service bus 9352, 5671 Enable communication between the

Connector toward the Azure service for
incoming requests.
HTTPS 9350 Optional, to enables better performance

for incoming requests
HTTPS 8080/443 Enable the Connector bootstrap

sequence and Connector automatic
update
HTTPS 9090 Enable Connector registration (required

only for the Connector registration
process)
HTTPS 9091 Enable Connector trust certificate

automatic renewal
Table 6b - Password Hash Sync with SSO

PROTOCOL PORT NUMBER DESCRIPTION
HTTPS 9090 Enable SSO registration (required only

for the SSO registration process).
Table 7a & 7b - Azure AD Connect Health agent for (AD FS/Sync) and
Azure AD
The following tables describe the endpoints, ports, and protocols that are required for communication between
Azure AD Connect Health agents and Azure AD
Table 7a - Ports and Protocols for Azure AD Connect Health agent for (AD FS/Sync) and Azure AD
This table describes the following outbound ports and protocols that are required for communication between the
Azure AD Connect Health agents and Azure AD.
HTTPS 443(TCP/UDP) Outbound
Azure Service Bus 5671 (TCP/UDP) Outbound
7b - Endpoints for Azure AD Connect Health agent for (AD FS/Sync) and Azure AD
For a list of endpoints, see the Requirements section for the Azure AD Connect Health agent.
More details about features in preview
This topic describes how to use features currently in preview.
Group writeback
The option for group writeback in optional features allows you to writeback Office 365 Groups to a forest with
Exchange installed. This is a group that is always mastered in the cloud. If you have Exchange on-premises, then
you can write back these groups to on-premises so users with an on-premises Exchange mailbox can send and
receive emails from these groups.
More information about Office 365 Groups and how to use them can be found here.
An Office 365 group is represented as a distribution group in on-premises AD DS. Your on-premises Exchange
server must be on Exchange 2013 cumulative update 8 (released in March 2015) or Exchange 2016 to recognize
this new group type.
Notes during the preview
The address book attribute is currently not populated in the preview. Without this attribute, the group is not
visible in the GAL. The easiest way to populate this attribute is to use the Exchange PowerShell cmdlet
update-recipient .
Only forests with the Exchange schema are valid targets for groups. If no Exchange was detected, then group
writeback is not possible to enable.
Only single-forest Exchange organization deployments are currently supported. If you have more than one
Exchange organization on-premises, then you need an on-premises GALSync solution for these groups to
appear in your other forests.
The Group writeback feature does not handle security groups or distribution groups.
NOTE
A subscription to Azure AD Premium is required for group writeback.
User writeback
IMPORTANT
The user writeback preview feature was removed in the August 2015 update to Azure AD Connect. If you have enabled it,
then you should disable this feature.
Next steps
Continue your Custom installation of Azure AD Connect.
Azure AD Connect: Version Release History
The Azure Active Directory team regularly updates Azure AD Connect with new features and functionality. Not all
additions are applicable to all audiences.
This article is designed to help you keep track of the versions that have been released, and to understand whether
you need to update to the newest version or not.
This is list of related topics:
TOPIC
Steps to upgrade from Azure AD Connect
Required permissions
Download
1.1.380.0
Released: 2016 December
Fixed issue:
Fixed the issue where the issuerid claim rule for ADFS is missing in this build.
NOTE
This build will not be available to customers through the Azure AD Connect Auto Upgrade feature.
1.1.371.0
Known issue:
The issuerid claim rule for ADFS is missing in this build. The issuerid claim rule is required if you are federating
multiple domains with Azure AD. If you are using Azure AD Connect to manage your on-premises ADFS
deployment, upgrading to this build will remove the existing issuerid claim rule from your ADFS configuration.
You can work around the issue by adding the issuerid claim rule after install/upgrade. For details on adding
issuerid claim rule, please refer to this article on Multiple Domain Support for Federating with Azure AD.
Fixed issue:
Azure AD Connect installation or upgrade fails if Port 9090 is not opened for outbound connection.
NOTE
1.1.370.0
Known issues:
Port 9090 must be open outbound to complete installation.
New Features:
Pass-through Authentication (Preview).
NOTE
1.1.343.0
Released: 2016 November
Known issue:
Fixed issues:
Sometimes, installing Azure AD Connect fails because it is unable to create a local service account whose
password meets the level of complexity specified by the organization's password policy.
Fixed an issue where join rules are not re-evaluated when an object in the connector space simultaneously
becomes out-of-scope for one join rule and become in-scope for another. This can happen if you have two or
more join rules whose join conditions are mutually exclusive.
Fixed an issue where inbound synchronization rules (from Azure AD) which do not contain join rules are not
processed if they have lower precedence values than those containing join rules.
Improvements:
Added support for installing Azure AD Connect on Windows Server 2016 standard or better.
Added support for using SQL Server 2016 as the remote database for Azure AD Connect.
1.1.281.0
Released: 2016 August
Fixed issues:
Changes to sync interval does not take place until after next sync cycle completes.
Azure AD Connect wizard does not accept Azure AD account whose username starts with an underscore (_).
Azure AD Connect wizard fails to authenticate Azure AD account provided if account password contains too
many special characters. Error message "Unable to validate credentials. An unexpected error has occurred." is
returned.
Uninstalling staging server disables password synchronization in Azure AD tenant and causes password
synchronization to fail with active server.
Password synchronization fails in uncommon cases when there is no password hash stored on the user.
When Azure AD Connect server is enabled for staging mode, password writeback is not temporarily disabled.
Azure AD Connect wizard does not show the actual password synchronization and password writeback
configuration when server is in staging mode. It always shows them as disabled.
Configuration changes to password synchronization and password writeback are not persisted by Azure AD
Connect wizard when server is in staging mode.
Improvements:
Updated Start-ADSyncSyncCycle cmdlet to indicate whether it is able to successfully start a new sync cycle or
not.
Added Stop-ADSyncSyncCycle cmdlet to terminate sync cycle and operation which are currently in progress.
Updated Stop-ADSyncScheduler cmdlet to terminate sync cycle and operation which are currently in progress.
When configuring Directory Extensions in Azure AD Connect wizard, AD attribute of type "Teletex string" can
now be selected.
1.1.189.0
Released: 2016 June
Fixed issues and improvements:
Azure AD Connect can now be installed on a FIPS compliant server.
For password synchronization, see Password Sync and FIPS
Fixed an issue where a NetBIOS name could not be resolved to the FQDN in the Active Directory Connector.
1.1.180.0
Released: 2016 May
New features:
Warns and helps you verifying domains if you didnt do it before running Azure AD Connect.
Added support for Microsoft Cloud Germany.
Added support for the latest Microsoft Azure Government cloud infrastructure with new URL requirements.
Added filtering to the Sync Rule Editor to make it easy to find sync rules.
Improved performance when deleting a connector space.
Fixed an issues when the same object was both deleted and added in the same run (called delete/add).
A disabled Sync Rule will no longer re-enable included objects and attributes on upgrade or directory schema
refresh.
1.1.130.0
Released: 2016 April
New features:
Added support for multi-valued attributes to Directory Extensions.
Added support for more configuration variations for automatic upgrade to be considered eligible for upgrade.
Added some cmdlets for custom scheduler.
1.1.119.0
Released: 2016 March
Fixed issues:
Made sure Express install cannot be used on Windows Server 2008 (pre-R2) since password sync is not
supported on this operating system.
Upgrade from DirSync with a custom filter configuration did not work as expected.
When upgrading to a newer release and there are no changes to the configuration, a full
import/synchronization should not be scheduled.
1.1.110.0
Released: 2016 February
Fixed issues:
Upgrade from earlier releases does not work if installation is not in the default C:\Program Files folder.
If you install and unselect Start the synchronization process.. at the end of the installation wizard, re-running
the installation wizard will not enable the scheduler.
The scheduler will not work as expected on servers where the date/time format is not US-en. It will also block
Get-ADSyncScheduler to return correct times.
If you installed an earlier release of Azure AD Connect with ADFS as the sign-in option and upgrade, you cannot
run the installation wizard again.
1.1.105.0
New features:
Automatic upgrade feature for Express settings customers.
Support for the global admin using MFA and PIM in the installation wizard.
You need to allow your proxy to also allow traffic to https://secure.aadcdn.microsoftonline-p.com if you
use MFA.
You need to add https://secure.aadcdn.microsoftonline-p.com to your trusted sites list for MFA to
properly work.
Allow changing the user's sign-in method after initial install.
Allow Domain and OU filtering in the installation wizard. This also allows connecting to forests where not all
domains are available.
Scheduler is built-in to the sync engine.
Features promoted from preview to GA:
Device writeback.
Directory extensions.
New preview features:
The new default sync cycle interval is 30 minutes. Used to be 3 hours for all earlier releases. Adds support to
change the scheduler behavior.
Fixed issues:
The verify DNS domains page didn't always recognize the domains.
Prompts for domain admin credentials when configuring ADFS .
The on-premises AD accounts are not recognized by the installation wizard if located in a domain with a
different DNS tree than the root domain.
1.0.9131.0
Fixed issues:
Password sync might not work when you change passwords in AD DS, but works when you do set password.
When you have a proxy server, authentication to Azure AD might fail during installation or un upgrade on the
configuration page.
Updating from a previous release of Azure AD Connect with a full SQL Server will fail if you are not SA in SQL.
Updating from a previous release of Azure AD Connect with a remote SQL Server will show the error Unable to
access the ADSync SQL database.
1.0.9125.0
Released: 2015 November
New features:
Can reconfigure the ADFS to Azure AD trust.
Can refresh the Active Directory schema and regenerate Sync Rules.
Can disable a sync rule.
Can define "AuthoritativeNull" as a new literal in a Sync Rule.
Azure AD Connect Health for sync.
Support for Azure AD Domain Services password synchronization.
New supported scenario:
Supports multiple on-premises Exchange organizations. See Hybrid deployments with multiple Active Directory
forests for more information.
Fixed issues:
Password synchronization issues:
An object moved from out-of-scope to in-scope will not have its password synchronized. This incudes
both OU and attribute filtering.
Selecting a new OU to include in sync does not require a full password sync.
When a disabled user is enabled the password does not sync.
The password retry queue is infinite and the previous limit of 5,000 objects to be retired has been
removed.
Improved troubleshooting.
Not able to connect to Active Directory with Windows Server 2016 forest-functional level.
Not able to change the group used for group filtering after initial install.
Will no longer create a new user profile on the Azure AD Connect server for every user doing a password
change with password writeback enabled.
Not able to use Long Integer values in Sync Rules scopes.
The checkbox "device writeback" remains disabled if there are unreachable domain controllers.
1.0.8667.0
Released: 2015 August
New features:
The Azure AD Connect installation wizard is now localized to all Windows Server languages.
Added support for account unlock when using Azure AD password management.
Fixed issues:
Azure AD Connect installation wizard crashes if another user continues installation rather than the person who
first started the installation.
If a previous uninstall of Azure AD Connect fails to uninstall Azure AD Connect sync cleanly, it is not possible to
reinstall.
Cannot install Azure AD Connect using Express install if the user is not in the root domain of the forest or if a
non-English version of Active Directory is used.
If the FQDN of the Active Directory user account cannot be resolved, a misleading error message Failed to
commit the schema is shown.
If the account used on the Active Directory Connector is changed outside the wizard, the wizard will fail on
subsequent runs.
Azure AD Connect sometimes fails to install on a domain controller.
Cannot enable and disable Staging mode if extension attributes have been added.
Password writeback fails in some configuration because of a bad password on the Active Directory Connector.
DirSync cannot be upgraded if dn is used in attribute filtering.
Excessive CPU usage when using password reset.
Removed preview features:
The preview feature User writeback was temporarily removed based on feedback from our preview customers.
It will be re-added later when we have addressed the provided feedback.
1.0.8641.0
Released: 2015 June
Initial release of Azure AD Connect.
Changed name from Azure AD Sync to Azure AD Connect.
New features:
Express settings installation
Can configure ADFS
Can upgrade from DirSync
Prevent accidental deletes
Introduced staging mode
User writeback
Group writeback
Device writeback
Directory extensions
1.0.494.0501
Released: 2015 May
New Requirement:
Azure AD Sync now requires the .Net framework version 4.5.1 to be installed.
Fixed issues:
Password writeback from Azure AD is failing with a servicebus connectivity error.
1.0.491.0413
Released: 2015 April
The Active Directory Connector does not process deletes correctly if the recycle bin is enabled and there are
multiple domains in the forest.
The performance of import operations has been improved for the Azure Active Directory Connector.
When a group has exceeded the membership limit (by default, the limit is set to 50k objects), the group was
deleted in Azure Active Directory. The new behavior is that the group will remain, an error is thrown and no new
membership changes will be exported.
A new object cannot be provisioned if a staged delete with the same DN is already present in the connector
space.
Some objects are marked for being synchronized during a delta sync although there is no change staged on the
object.
Forcing a password sync also removes the preferred DC list.
CSExportAnalyzer has problems with some objects states.
New features:
A join can now connect to ANY object type in the MV.
1.0.485.0222
Improvements:
Improved import performance.
Fixed issues:
Password Sync honors the cloudFiltered attribute used by attribute filtering. Filtered objects will no longer be in
scope for password synchronization.
In rare situations where the topology had very many domain controllers, password sync doesnt work.
Stopped-server when importing from the Azure AD Connector after device management has been enabled in
Azure AD/Intune.
Joining Foreign Security Principals (FSPs) from multiple domains in same forest causes an ambiguous-join
error.
1.0.475.1202
New features:
It is now supported to do password synchronization with attribute based filtering. For more details, see
Password synchronization with filtering.
The attribute msDS-ExternalDirectoryObjectID is written back to AD. This adds support for Office 365
applications using OAuth2 to access both, Online and On-Premises mailboxes in a Hybrid Exchange
Deployment.
Fixed upgrade issues:
A newer version of the sign-in assistant is available on the server.
A custom installation path was used to install Azure AD Sync.
An invalid custom join criterion blocks the upgrade.
Other fixes:
Fixed the templates for Office Pro Plus.
Fixed installation issues caused by user names that start with a dash.
Fixed losing the sourceAnchor setting when running the installation wizard a second time.
Fixed ETW tracing for password synchronization
1.0.470.1023
Released: 2014 October
New features:
Password synchronization from multiple on-premises AD to Azure AD.
Localized installation UI to all Windows Server languages.
Upgrading from AADSync 1.0 GA
If you already have Azure AD Sync installed, there is one additional step you have to take in case you have changed
any of the out-of-box Synchronization Rules. After you have upgraded to the 1.0.470.1023 release, the
synchronization rules you have modified are duplicated. For each modified Sync Rule do the following:
Locate the Sync Rule you have modified and take a note of the changes.
Delete the Sync Rule.
Locate the new Sync Rule created by Azure AD Sync and re-apply the changes.
Permissions for the AD account
The AD account must be granted additional permissions to be able to read the password hashes from AD. The
permissions to grant are named Replicating Directory Changes and Replicating Directory Changes All. Both
permissions are required to be able to read the password hashes
1.0.419.0911
Released: 2014 September
Initial release of Azure AD Sync.
Next steps
Azure AD Connect: Accounts and permissions
The Azure AD Connect installation wizard offers two different paths:

In Express Settings, the wizard requires more privileges so that it can setup your configuration easily, without
requiring you to create users or configure permissions separately.
In Custom Settings, the wizard offers you more choices and options, but there are some situations in which you
need to ensure you have the correct permissions yourself.
Related documentation
If you did not read the documentation on Integrating your on-premises identities with Azure Active Directory, the
following table provides links to related topics.
TOPIC LINK
Download Azure AD Connect Download Azure AD Connect
Install using Express settings Express installation of Azure AD Connect
Install using Customized settings Custom installation of Azure AD Connect
Upgrade from DirSync Upgrade from Azure AD sync tool (DirSync)
After installation Verify the installation and assign licenses
Express settings installation

In Express settings, the installation wizard asks for AD DS Enterprise Admin credentials so your on-premises Active
Directory can be configured with required permissions for Azure AD Connect. If you are upgrading from DirSync,
the AD DS Enterprise Admins credentials are used to reset the password for the account used by DirSync. You also
need Azure AD Global Administrator credentials.
WIZARD PAGE CREDENTIALS COLLECTED PERMISSIONS REQUIRED USED FOR
N/A User running the installation Administrator of the local Creates the local account
wizard server that is used as the sync
engine service account.
Connect to Azure AD Azure AD directory Global administrator role in Enabling sync in the Azure
credentials Azure AD AD directory.
Creation of the Azure AD
account that is used for on-
going sync operations in
Azure AD.
Connect to AD DS On-premises Active Member of the Enterprise Creates an account in

Directory credentials Admins (EA) group in Active Active Directory and grants
Directory permissions to it. This
created account is used to
read and write directory
information during
synchronization.
Enterprise Admin credentials

These credentials are only used during the installation and are not used after the installation has completed. The
Enterprise Admin, not the Domain Admin should make sure the permissions in Active Directory can be set in all
domains.
Global Admin credentials
These credentials are only used during the installation and are not used after the installation has completed. It is
used to create the Azure AD account used for synchronizing changes to Azure AD. The account also enables sync
as a feature in Azure AD.
Permissions for the created AD DS account for express settings
The account created for reading and writing to AD DS have the following permissions when created by express
settings:
PERMISSION USED FOR
Replicate Directory Changes Password sync

Replicate Directory Changes All
Read/Write all properties User Import and Exchange hybrid
Read/Write all properties iNetOrgPerson Import and Exchange hybrid
Read/Write all properties Group Import and Exchange hybrid
Read/Write all properties Contact Import and Exchange hybrid
Reset password Preparation for enabling password writeback
Custom settings installation

When using custom settings, the account used to connect to Active Directory must be created before the
installation. The permissions you must grant this account can be found in create the AD DS account.
N/A User running the installation Administrator of the local By default, creates the local
wizard server account that is used as the
If using a full SQL Server, sync engine service account.
the user must be System The account is only created
Administrator (SA) in SQL when the admin does not
specify a particular account.
Install synchronization AD or local user account User, permissions are If the admin specifies an
services, Service account credentials granted by the installation account, this account is used
option wizard as the service account for
the sync service.
Connect to Azure AD Azure AD directory Global administrator role in Enabling sync in the Azure
credentials Azure AD AD directory.
Creation of the Azure AD
account that is used for on-
going sync operations in
Azure AD.
Connect your directories On-premises Active The permissions depend on This account is used to read
Directory credentials for which features you enable and write directory
each forest that is connected and can be found in Create information during
to Azure AD the AD DS account synchronization.
AD FS Servers For each server in the list, Domain Administrator Installation and
the wizard collects configuration of the AD FS
credentials when the logon server role.
credentials of the user
running the wizard are
insufficient to connect
Web application proxy For each server in the list, Local admin on the target Installation and
servers the wizard collects machine configuration of WAP server
credentials when the logon role.
credentials of the user
running the wizard are
insufficient to connect
Proxy trust credentials Federation service trust Domain account that is a Initial enrollment of FS-WAP
credentials (the credentials local administrator of the AD trust certificate.
the proxy uses to enroll for a FS server
trust certificate from the FS
AD FS Service Account page, AD user account credentials Domain user The AD user account whose
"Use a domain user account credentials are provided is
option" used as the logon account
of the AD FS service.
Create the AD DS account

When you install Azure AD Connect, the account you specify on the Connect your directories page must be
present in Active Directory and have required permissions granted. The installation wizard does not verify the
permissions and any issues are only found during synchronization.
Which permissions you require depends on the optional features you enable. If you have multiple domains, the
permissions must be granted for all domains in the forest. If you do not enable any of these features, the default
Domain User permissions are sufficient.
FEATURE PERMISSIONS
Password sync Replicate Directory Changes

Replicate Directory Changes All
FEATURE PERMISSIONS
Exchange hybrid deployment Write permissions to the attributes documented in Exchange

hybrid writeback for users, groups, and contacts.
Password writeback Write permissions to the attributes documented in Getting

started with password management for users.
Device writeback Permissions granted with a PowerShell script as described in

device writeback.
Group writeback Read, Create, Update, and Delete group objects in the OU
where the distributions groups should be located.
Upgrade
When you upgrade from one version of Azure AD Connect to a new release, you need the following permissions:
PRINCIPAL PERMISSIONS REQUIRED USED FOR
User running the installation wizard Administrator of the local server Update binaries.
User running the installation wizard Member of ADSyncAdmins Make changes to Sync Rules and other
configuration.
User running the installation wizard If you use a full SQL server: DBO (or Make database level changes, such as
similar) of the sync engine database updating tables with new columns.
More about the created accounts

Active Directory account
If you use express settings, then an account is created in Active Directory that is used for synchronization. The
created account is located in the forest root domain in the Users container and has its name prefixed with MSOL_.
The account is created with a long complex password that does not expire. If you have a password policy in your
domain, make sure long and complex passwords would be allowed for this account.
Azure AD Connect sync service accounts

A local service account is created by the installation wizard (unless you specify the account to use in custom
settings). The account is prefixed AAD_ and used for the actual sync service to run as. If you install Azure AD
Connect on a Domain Controller, the account is created in the domain. If you use a remote server running SQL
server or if you use a proxy that requires authentication, the AAD_ service account must be located in the domain.
The account is created with a long complex password that does not expire.
This account is used to store the passwords for the other accounts in a secure way. These other accounts
passwords are stored encrypted in the database. The private keys for the encryption keys are protected with the
cryptographic services secret-key encryption using Windows Data Protection API (DPAPI). You should not reset the
password on the service account since Windows will then destroy the encryption keys for security reasons.
If you use a full SQL Server, then the service account is the DBO of the created database for the sync engine. The
service will not function as intended with any other permissions. A SQL login is also created.
The account is also granted permissions to files, registry keys, and other objects related to the Sync Engine.
Azure AD service account
An account in Azure AD is created for the sync service's use. This account can be identified by its display name.
The name of the server the account is used on can be identified in the second part of the user name. In the picture,
the server name is FABRIKAMCON. If you have staging servers, each server has its own account. There is a limit of
10 sync service accounts in Azure AD.
The service account is created with a long complex password that does not expire. It is granted a special role
Directory Synchronization Accounts that has only permissions to perform directory synchronization tasks. This
special built-in role cannot be granted outside the Azure AD Connect wizard and the Azure portal shows this
account with the role User.
Next steps
Azure AD Connect sync: Attributes synchronized to
This topic lists the attributes that are synchronized by Azure AD Connect sync.
The attributes are grouped by the related Azure AD app.
Attributes to synchronize
A common question is what is the list of minimum attributes to synchronize. The default and recommended
approach is to keep the default attributes so a full GAL (Global Address List) can be constructed in the cloud and to
get all features in Office 365 workloads. In some cases, there are some attributes that your organization does not
want synchronized to the cloud since these attributes contain sensitive or PII (Personally identifiable information)
data, like in this example:
In this case, start with the list of attributes in this topic and identify those attributes that would contain sensitive or
PII data and cannot be synchronized. Then deselect those attributes during installation using Azure AD app and
attribute filtering.
WARNING
When deselecting attributes, you should be cautious and only deselect those attributes absolutely not possible to
synchronize. Unselecting other attributes might have a negative impact on features.
Office 365 ProPlus

ATTRIBUTE NAME USER COMMENT
accountEnabled X Defines if an account is enabled.
cn X
displayName X
objectSID X mechanical property. AD user identifier

used to maintain sync between Azure
AD and AD.
pwdLastSet X mechanical property. Used to know

when to invalidate already issued
tokens. Used by both password sync
and federation.
sourceAnchor X mechanical property. Immutable

identifier to maintain relationship
between ADDS and Azure AD.
usageLocation X mechanical property. The users

country. Used for license assignment.
userPrincipalName X UPN is the login ID for the user. Most

often the same as [mail] value.
Exchange Online
ATTRIBUTE NAME USER CONTACT GROUP COMMENT
accountEnabled X Defines if an account

is enabled.
assistant X X
authOrig X X X
c X X
cn X X
co X X
company X X
countryCode X X
department X X
description X X X
displayName X X X
dLMemRejectPerms X X X
dLMemSubmitPerms X X X
extensionAttribute1 X X X
facsimiletelephonenu X X
mber
givenName X X
homePhone X X
info X X X This attribute is

currently not
consumed for groups.
Initials X X
l X X
legacyExchangeDN X X X
mailNickname X X X
mangedBy X
manager X X
member X
mobile X X
msDS- X X X
HABSeniorityIndex
msDS- X X X
PhoneticDisplayName
msExchArchiveGUID X
msExchArchiveName X
msExchAssistantNam X X
e
msExchAuditAdmin X
msExchAuditDelegate X
msExchAuditDelegate X
Admin
msExchAuditOwner X
msExchBlockedSender X X
sHash
msExchBypassAudit X
msExchCoManagedBy X
Link
msExchDelegateListLi X
nk
msExchELCExpirySusp X
ensionEnd
msExchELCExpirySusp X
ensionStart
msExchELCMailboxFla X
gs
msExchEnableModera X X
tion
msExchExtensionCust X X X This attribute is

omAttribute1 currently not
consumed by
Exchange Online.

consumed by
Exchange Online.

consumed by
Exchange Online.

consumed by
Exchange Online.

consumed by
Exchange Online.
msExchHideFromAddr X X X
essLists
msExchImmutableID X
msExchLitigationHold X X X
Date
msExchLitigationHold X X X
Owner
msExchMailboxAuditE X
nable
msExchMailboxAuditL X
ogAgeLimit
msExchMailboxGuid X
msExchModeratedByL X X X
ink
msExchModerationFla X X X
gs
msExchRecipientDispl X X X
ayType
msExchRecipientType X X X
Details
msExchRemoteRecipie X
ntType
msExchRequireAuthT X X X
oSendTo
msExchResourceCapa X
city
msExchResourceDispl X
ay
msExchResourceMeta X
Data
msExchResourceSearc X
hProperties
msExchRetentionCom X X X
ment
msExchRetentionURL X X X
msExchSafeRecipients X X
Hash
msExchSafeSendersHa X X
sh
msExchSenderHintTra X X X
nslations
msExchTeamMailboxE X
xpiration
msExchTeamMailbox X
Owners
msExchTeamMailboxS X
harePointUrl
msExchUserHoldPolici X
es
msOrg- X
IsOrganizational
objectSID X X mechanical property.

AD user identifier
used to maintain sync
between Azure AD
and AD.
oOFReplyToOriginato X
r
otherFacsimileTelepho X X
ne
otherHomePhone X X
otherTelephone X X
pager X X
physicalDeliveryOffice X X
Name
postalCode X X
proxyAddresses X X X
publicDelegates X X X
pwdLastSet X mechanical property.

Used to know when
to invalidate already
issued tokens. Used
by both password
sync and federation.
reportToOriginator X
reportToOwner X
securityEnabled X Derived from

groupType
sn X X
sourceAnchor X X X mechanical property.

Immutable identifier
to maintain
relationship between
ADDS and Azure AD.
st X X
streetAddress X X
targetAddress X X
telephoneAssistant X X
telephoneNumber X X
thumbnailphoto X X
title X X
unauthOrig X X X
usageLocation X mechanical property.

The users country.
Used for license
assignment.
userCertificate X X
userPrincipalName X UPN is the login ID

for the user. Most
often the same as
[mail] value.
userSMIMECertificate X X
s
wWWHomePage X X
SharePoint Online

is enabled.
authOrig X X X
c X X
cn X X
co X X
company X X
countryCode X X
department X X
description X X X
displayName X X X
dLMemRejectPerms X X X
dLMemSubmitPerms X X X
mber
givenName X X
hideDLMembership X
homephone X X
info X X X
initials X X
ipPhone X X
l X X
mail X X X
mailnickname X X X
managedBy X
manager X X
member X
middleName X X
mobile X X
msExchTeamMailboxE X
xpiration
msExchTeamMailbox X
Owners
harePointLinkedBy
harePointUrl

AD user identifier
between Azure AD
and AD.
oOFReplyToOriginato X
r
otherFacsimileTelepho X X
ne
otherHomePhone X X
otherIpPhone X X
otherMobile X X
otherPager X X
otherTelephone X X
pager X X
Name
postalCode X X
postOfficeBox X X
preferredLanguage X

Used to know when
issued tokens. Used
by both password
reportToOriginator X
reportToOwner X

groupType
sn X X

to maintain
ADDS and Azure AD.
st X X
streetAddress X X
targetAddress X X
telephoneAssistant X X
telephoneNumber X X
thumbnailphoto X X
title X X
unauthOrig X X X
url X X

The users country.
Used for license
assignment.

for the user. Most
often the same as
[mail] value.
wWWHomePage X X
Lync Online

is enabled.
c X X
cn X X
co X X
company X X
department X X
description X X X
displayName X X X
facsimiletelephonenu X X X
mber
givenName X X
homephone X X
ipPhone X X
l X X
mail X X X
mailNickname X X X
managedBy X
manager X X
member X
mobile X X
msExchHideFromAddr X X X
essLists
msRTCSIP- X
ApplicationOptions
msRTCSIP- X X
DeploymentLocator
msRTCSIP-Line X X
msRTCSIP- X X
OptionFlags
msRTCSIP-OwnerUrn X
msRTCSIP- X X
PrimaryUserAddress
msRTCSIP- X X
UserEnabled

AD user identifier
between Azure AD
and AD.
otherTelephone X X
Name
postalCode X X
preferredLanguage X

Used to know when
issued tokens. Used
by both password

groupType
sn X X

to maintain
ADDS and Azure AD.
st X X
streetAddress X X
telephoneNumber X X
thumbnailphoto X X
title X X

The users country.
Used for license
assignment.

for the user. Most
often the same as
[mail] value.
wWWHomePage X X
Azure RMS

is enabled.
cn X X Common name or
alias. Most often the
prefix of [mail] value.
displayName X X X A string that

represents the name
often shown as the
friendly name (first
name last name).
mail X X X full email address.
member X

AD user identifier
between Azure AD
and AD.
proxyAddresses X X X mechanical property.

Used by Azure AD.
Contains all
secondary email
addresses for the
user.

Used to know when
issued tokens.

groupType.

to maintain
ADDS and Azure AD.

The users country.
Used for license
assignment.
userPrincipalName X This UPN is the login

ID for the user. Most
often the same as
[mail] value.
Intune

is enabled.
c X X
cn X X
description X X X
displayName X X X
mail X X X
mailnickname X X X
member X

AD user identifier
between Azure AD
and AD.

Used to know when
issued tokens. Used
by both password

groupType

to maintain
ADDS and Azure AD.

The users country.
Used for license
assignment.

for the user. Most
often the same as
[mail] value.
Dynamics CRM

is enabled.
c X X
cn X X
co X X
company X X
countryCode X X
description X X X
displayName X X X
mber
givenName X X
l X X
managedBy X
manager X X
member X
mobile X X

AD user identifier
between Azure AD
and AD.
Name
postalCode X X
preferredLanguage X

Used to know when
issued tokens. Used
by both password

groupType
sn X X

to maintain
ADDS and Azure AD.
st X X
streetAddress X X
telephoneNumber X X
title X X

The users country.
Used for license
assignment.

for the user. Most
often the same as
[mail] value.
3rd party applications

This group is a set of attributes used as the minimal attributes needed for a generic workload or application. It can
be used for a workload not listed in another section or for a non-Microsoft app. It is explicitly used for the
following:
Yammer (only User is consumed)
Hybrid Business-to-Business (B2B) cross-org collaboration scenarios offered by resources like SharePoint
This group is a set of attributes that can be used if the Azure AD directory is not used to support Office 365,
Dynamics, or Intune. It has a small set of core attributes.

is enabled.
cn X X
displayName X X X
givenName X X
mail X X
managedBy X
mailNickName X X X
member X
objectSID X mechanical property.

AD user identifier
between Azure AD
and AD.

Used to know when
issued tokens. Used
by both password
sn X X

to maintain
ADDS and Azure AD.

The users country.
Used for license
assignment.

for the user. Most
often the same as
[mail] value.
Windows 10
A Windows 10 domain-joined computer(device) synchronizes some attributes to Azure AD. For more information
on the scenarios, see Connect domain-joined devices to Azure AD for Windows 10 experiences. These attributes
always synchronize and Windows 10 does not appear as an app you can unselect. A Windows 10 domain-joined
computer is identified by having the attribute userCertificate populated.
ATTRIBUTE NAME DEVICE COMMENT
accountEnabled X
deviceTrustType X Hardcoded value for domain-joined

computers.
displayName X
ms-DS-CreatorSID X Also called registeredOwnerReference.
objectGUID X Also called deviceID.
objectSID X Also called onPremisesSecurityIdentifier.
operatingSystem X Also called deviceOSType.
operatingSystemVersion X Also called deviceOSVersion.
userCertificate X
These attributes for user are in addition to the other apps you have selected.
domainFQDN X Also called dnsDomainName. For

example, contoso.com.
domainNetBios X Also called netBiosName. For example,

CONTOSO.
Exchange hybrid writeback

These attributes are written back from Azure AD to on-premises Active Directory when you select to enable
Exchange hybrid. Depending on your Exchange version, fewer attributes might be synchronized.
msDS- X Derived from

ExternalDirectoryObje cloudAnchor in Azure
ctID AD. This attribute is
new in Exchange
2016.
msExchArchiveStatus X Online Archive:

Enables customers to
archive mail.
msExchBlockedSender X Filtering: Writes back

sHash on-premises filtering
and online safe and
blocked sender data
from clients.
msExchSafeRecipients X Filtering: Writes back

Hash on-premises filtering
and online safe and
blocked sender data
from clients.
msExchSafeSendersHa X Filtering: Writes back

sh on-premises filtering
and online safe and
blocked sender data
from clients.
msExchUCVoiceMailS X Enable Unified

ettings Messaging (UM) -
Online voice mail:
Used by Microsoft
Lync Server
integration to indicate
to Lync Server on-
premises that the
user has voice mail in
online services.
msExchUserHoldPolici X Litigation Hold:

es Enables cloud services
to determine which
users are under
Litigation Hold.
proxyAddresses X X X Only the x500

address from
Exchange Online is
inserted.
Device writeback
Device objects are created in Active Directory. These objects can be devices joined to Azure AD or domain-joined
Windows 10 computers.
ATTRIBUTE NAME DEVICE COMMENT
altSecurityIdentities X
displayName X
dn X
msDS-CloudAnchor X
msDS-DeviceID X
msDS-DeviceObjectVersion X
msDS-DeviceOSType X
msDS-DeviceOSVersion X
msDS-DevicePhysicalIDs X
msDS-KeyCredentialLink X Only with Windows Server 2016 AD

schema
msDS-IsCompliant X
msDS-IsEnabled X
msDS-IsManaged X
msDS-RegisteredOwner X
Notes
When using an Alternate ID, the on-premises attribute userPrincipalName is synchronized with the Azure AD
attribute onPremisesUserPrincipalName. The Alternate ID attribute, for example mail, is synchronized with the
Azure AD attribute userPrincipalName.
In the lists above, the object type User also applies to the object type iNetOrgPerson.
Next steps
Connector Version Release History
The Connectors for Forefront Identity Manager (FIM) and Microsoft Identity Manager (MIM) are updated frequently.
NOTE
This topic is on FIM and MIM only. These Connectors are not supported on Azure AD Connect.
This topic list all versions of the Connectors that have been released.
Related links:
Download Latest Connectors
Generic LDAP Connector reference documentation
Generic SQL Connector reference documentation
Web Services Connector reference documentation
PowerShell Connector reference documentation
Lotus Domino Connector reference documentation
1.1.117.0
Released: 2016 March
New Connector
Initial release of the Generic SQL Connector.
New features:
Generic LDAP Connector:
Added support for delta import with Isode.
Web Services Connector:
Updated the csEntryChangeResult activity and setImportErrorCode activity to allow object level errors to
be returned back to the sync engine.
Updated the SAP6 and SAP6User templates to use the new object level error functionality.
Lotus Domino Connector:
For export, you need one certifier per address book. You can now use the same password for all certifiers
to make the management easier.
Fixed issues:
Generic LDAP Connector:
For IBM Tivoli DS, some reference attributes were not detected correctly.
For Open LDAP during a delta import, whitespaces at the beginning and end of strings were truncated.
For Novell and NetIQ, an export that moved an object between OUs/containers and at the same time
renamed the object failed.
Web Services Connector:
If the web service had multiple end-points for same binding, then the Connector did not correctly
discover these end-points.
Lotus Domino Connector:
An export of the fullName attribute to a mail-in database did not work.
An export which both added and removed member from a group only exported the added members.
If a Notes Document is invalid (the attribute isValid set to false), then the Connector fails.
Older releases
Before March 2016, the Connectors were released as support topics.
Generic LDAP
KB3078617 - 1.0.0597, 2015 September
KB3044896 - 1.0.0549, 2015 March
KB3031009 - 1.0.0534, 2015 January
KB3008177 - 1.0.0419, 2014 September
KB2936070 - 4.3.1082, 2014 March
WebServices
KB3008178 - 1.0.0419, 2014 September
PowerShell
KB3008179 - 1.0.0419, 2014 September
Lotus Domino
KB3096533 - 1.0.0597, 2015 September
KB3044895 - 1.0.0549, 2015 March
KB2977286 - 5.3.0712, 2014 August
KB2932635 - 5.3.1003, 2014 February
KB2899874 - 5.3.0721, 2013 October
KB2875551 - 5.3.0534, 2013 August
Next steps
In Azure AD Connect, functions are used to manipulate an attribute value during synchronization.
The Syntax of the functions is expressed using the following format:
<output type> FunctionName(<input type> <position name>, ..)
If a function is overloaded and accepts multiple syntaxes, all valid syntaxes are listed.
The functions are strongly typed and they verify that the type passed in matches the documented type.
If the type does not match, an error is thrown.
The types are expressed with the following syntax:
bin Binary
bool Boolean
dt UTC Date/Time
enum Enumeration of known constants
exp Expression, which is expected to evaluate to a Boolean
mvbin Multi-Valued Binary
mvstr Multi-Valued String
mvref Multi-Valued Reference
num Numeric
ref Reference
str String
var A variant of (almost) any other type
void doesnt return a value
The functions with the types mvbin, mvstr, and mvref can only work on multi-valued attributes. Functions with
bin, str, and ref work on both single-valued and multi-valued attributes.
Functions Reference
LIST OF FUNCTIONS
Conversion
CBool CDate CGuid ConvertFromBase64
ConvertToBase64 ConvertFromUTF8He ConvertToUTF8Hex CNum

x
CRef CStr StringFromGuid StringFromSid
Date / Time
DateAdd DateFromNum FormatDateTime Now
NumFromDate
LIST OF FUNCTIONS
Directory
DNComponent DNComponentRev EscapeDNComponent
Evaluation
IsBitSet IsDate IsEmpty IsGuid
IsNull IsNullOrEmpty IsNumeric IsPresent
IsString
Math
BitAnd BitOr RandomNum
Multi-valued
Contains Count Item ItemOrNull
Join RemoveDuplicates Split
Program Flow
Error IIF Switch
Text
GUID InStr InStrRev LCase
Left Len LTrim Mid
PadLeft PadRight PCase Replace
ReplaceChars Right RTrim Trim
UCase Word
BitAnd
Description:
The BitAnd function sets specified bits on a value.
Syntax:
num BitAnd(num value1, num value2)
value1, value2: numeric values that should be ANDed together

Remarks:
This function converts both parameters to the binary representation and sets a bit to:
0 - if one or both of the corresponding bits in mask and flag are 0
1 - if both of the corresponding bits are 1.
In other words, it returns 0 in all cases except when the corresponding bits of both parameters are 1.
Example:
BitAnd(&HF, &HF7)
Returns 7 because hexadecimal "F" AND "F7" evaluate to this value.
BitOr
Description:
The BitOr function sets specified bits on a value.
Syntax:
num BitOr(num value1, num value2)
value1, value2: numeric values that should be ORed together

Remarks:
This function converts both parameters to the binary representation and sets a bit to 1 if one or both of the
corresponding bits in mask and flag are 1, and to 0 if both of the corresponding bits are 0. In other words, it
returns 1 in all cases except where the corresponding bits of both parameters are 0.
CBool
Description:
The CBool function returns a Boolean based on the evaluated expression
Syntax:
bool CBool(exp Expression)
Remarks:
If the expression evaluates to a nonzero value, then CBool returns True, else it returns False.
Example:
CBool([attrib1] = [attrib2])
Returns True if both attributes have the same value.
CDate
Description:
The CDate function returns a UTC DateTime from a string. DateTime is not a native attribute type in Sync but is
used by some functions.
Syntax:
dt CDate(str value)
Value: A string with a date, time, and optionally time zone

Remarks:
The returned string is always in UTC.
Example:
CDate([employeeStartTime])
Returns a DateTime based on the employees start time
CDate("2013-01-10 4:00 PM -8")
Returns a DateTime representing "2013-01-11 12:00 AM"
CGuid
Description:
The CGuid function converts the string representation of a GUID to its binary representation.
Syntax:
bin CGuid(str GUID)
A String formatted in this pattern: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx or {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}
Contains
Description:
The Contains function finds a string inside a multi-valued attribute
Syntax:
num Contains (mvstring attribute, str search) - case-sensitive
num Contains (mvstring attribute, str search, enum Casetype)
num Contains (mvref attribute, str search) - case-sensitive
attribute: the multi-valued attribute to search.
search: string to find in the attribute.
Casetype: CaseInsensitive or CaseSensitive.
Returns index in the multi-valued attribute where the string was found. 0 is returned if the string is not found.
Remarks:
For multi-valued string attributes, the search finds substrings in the values.
For reference attributes, the searched string must exactly match the value to be considered a match.
Example:
IIF(Contains([proxyAddresses],"SMTP:")>0,[proxyAddresses],Error("No primary SMTP address found."))
If the proxyAddresses attribute has a primary email address (indicated by uppercase "SMTP:"), then return the
proxyAddress attribute, else return an error.
ConvertFromBase64
Description:
The ConvertFromBase64 function converts the specified base64 encoded value to a regular string.
Syntax:
str ConvertFromBase64(str source) - assumes Unicode for encoding
str ConvertFromBase64(str source, enum Encoding)
source: Base64 encoded string

Encoding: Unicode, ASCII, UTF8
Example
ConvertFromBase64("SABlAGwAbABvACAAdwBvAHIAbABkACEA")
ConvertFromBase64("SGVsbG8gd29ybGQh", UTF8)
Both examples return "Hello world!"
ConvertFromUTF8Hex
Description:
The ConvertFromUTF8Hex function converts the specified UTF8 Hex encoded value to a string.
Syntax:
str ConvertFromUTF8Hex(str source)
source: UTF8 2-byte encoded sting

Remarks:
The difference between this function and ConvertFromBase64([],UTF8) in that the result is friendly for the DN
attribute.
This format is used by Azure Active Directory as DN.
Example:
ConvertFromUTF8Hex("48656C6C6F20776F726C6421")
Returns "Hello world!"
ConvertToBase64
Description:
The ConvertToBase64 function converts a string to a Unicode base64 string.
Converts the value of an array of integers to its equivalent string representation that is encoded with base-64
digits.
Syntax:
str ConvertToBase64(str source)
Example:
ConvertToBase64("Hello world!")
Returns "SABlAGwAbABvACAAdwBvAHIAbABkACEA"
ConvertToUTF8Hex
Description:
The ConvertToUTF8Hex function converts a string to a UTF8 Hex encoded value.
Syntax:
str ConvertToUTF8Hex(str source)
Remarks:
The output format of this function is used by Azure Active Directory as DN attribute format.
Example:
ConvertToUTF8Hex("Hello world!")
Returns 48656C6C6F20776F726C6421
Count
Description:
The Count function returns the number of elements in a multi-valued attribute
Syntax:
num Count(mvstr attribute)
CNum
Description:
The CNum function takes a string and returns a numeric data type.
Syntax:
num CNum(str value)
CRef
Description:
Converts a string to a reference attribute
Syntax:
ref CRef(str value)
Example:
CRef("CN=LC Services,CN=Microsoft,CN=lcspool01,CN=Pools,CN=RTC Service," & %Forest.LDAP%)
CStr
Description:
The CStr function converts to a string data type.
Syntax:
str CStr(num value)
str CStr(ref value)
str CStr(bool value)
value: Can be a numeric value, reference attribute, or Boolean.

Example:
CStr([dn])
Could return "cn=Joe,dc=contoso,dc=com"
DateAdd
Description:
Returns a Date containing a date to which a specified time interval has been added.
Syntax:
dt DateAdd(str interval, num value, dt date)
interval: String expression that is the interval of time you want to add. The string must have one of the
following values:
yyyy Year
q Quarter
m Month
y Day of year
d Day
w Weekday
ww Week
h Hour
n Minute
s Second
value: The number of units you want to add. It can be positive (to get dates in the future) or negative (to get
dates in the past).
date: DateTime representing date to which the interval is added.
Example:
DateAdd("m", 3, CDate("2001-01-01"))
Adds 3 months and returns a DateTime representing "2001-04-01".
DateFromNum
Description:
The DateFromNum function converts a value in ADs date format to a DateTime type.
Syntax:
dt DateFromNum(num value)
Example:
DateFromNum([lastLogonTimestamp])
DateFromNum(129699324000000000)
Returns a DateTime representing 2012-01-01 23:00:00
DNComponent
Description:
The DNComponent function returns the value of a specified DN component going from left.
Syntax:
str DNComponent(ref dn, num ComponentNumber)
dn: the reference attribute to interpret

ComponentNumber: The component in the DN to return
Example:
DNComponent([dn],1)
If dn is "cn=Joe,ou=," it returns Joe
DNComponentRev
Description:
The DNComponentRev function returns the value of a specified DN component going from right (the end).
Syntax:
str DNComponentRev(ref dn, num ComponentNumber)
str DNComponentRev(ref dn, num ComponentNumber, enum Options)
dn: the reference attribute to interpret

ComponentNumber - The component in the DN to return
Options: DC Ignore all components with "dc="
Example:
If dn is "cn=Joe,ou=Atlanta,ou=GA,ou=US, dc=contoso,dc=com" then
DNComponentRev([dn],3)
DNComponentRev([dn],1,"DC")
Both return US.
Error
Description:
The Error function is used to return a custom error.
Syntax:
void Error(str ErrorMessage)
Example:
IIF(IsPresent([accountName]),[accountName],Error("AccountName is required"))
If the attribute accountName is not present, throw an error on the object.
EscapeDNComponent
Description:
The EscapeDNComponent function takes one component of a DN and escapes it so it can be represented in LDAP.
Syntax:
str EscapeDNComponent(str value)
Example:
EscapeDNComponent("cn=" & [displayName]) & "," & %ForestLDAP%)
Makes sure the object can be created in an LDAP directory even if the displayName attribute has characters that
must be escaped in LDAP.
FormatDateTime
Description:
The FormatDateTime function is used to format a DateTime to a string with a specified format
Syntax:
str FormatDateTime(dt value, str format)
value: a value in the DateTime format

format: a string representing the format to convert to.
Remarks:
The possible values for the format can be found here: User-Defined Date/Time Formats (Format Function)
Example:
FormatDateTime(CDate("12/25/2007"),"yyyy-mm-dd")
Results in "2007-12-25".
FormatDateTime(DateFromNum([pwdLastSet]),"yyyyMMddHHmmss.0Z")
Can result in "20140905081453.0Z"
GUID
Description:
The function GUID generates a new random GUID
Syntax:
str GUID()
IIF
Description:
The IIF function returns one of a set of possible values based on a specified condition.
Syntax:
var IIF(exp condition, var valueIfTrue, var valueIfFalse)
condition: any value or expression that can be evaluated to true or false.

valueIfTrue: If the condition evaluates to true, the returned value.
valueIfFalse: If the condition evaluates to false, the returned value.
Example:
IIF([employeeType]="Intern","t-" & [alias],[alias])
If the user is an intern, returns the alias of a user with "t-" added to the beginning of it, else returns the users alias
as is.
InStr
Description:
The InStr function finds the first occurrence of a substring in a string
Syntax:
num InStr(str stringcheck, str stringmatch)
num InStr(str stringcheck, str stringmatch, num start)
num InStr(str stringcheck, str stringmatch, num start , enum compare)
stringcheck: string to be searched

stringmatch: string to be found
start: starting position to find the substring
compare: vbTextCompare or vbBinaryCompare
Remarks:
Returns the position where the substring was found or 0 if not found.
Example:
InStr("The quick brown fox","quick")
Evalues to 5
InStr("repEated","e",3,vbBinaryCompare)
Evaluates to 7
InStrRev
Description:
The InStrRev function finds the last occurrence of a substring in a string
Syntax:
num InstrRev(str stringcheck, str stringmatch)
num InstrRev(str stringcheck, str stringmatch, num start)
num InstrRev(str stringcheck, str stringmatch, num start, enum compare)
stringcheck: string to be searched

stringmatch: string to be found
start: starting position to find the substring
compare: vbTextCompare or vbBinaryCompare
Remarks:
Returns the position where the substring was found or 0 if not found.
Example:
InStrRev("abbcdbbbef","bb")
Returns 7
IsBitSet
Description:
The function IsBitSet Tests if a bit is set or not
Syntax:
bool IsBitSet(num value, num flag)
value: a numeric value that is evaluated.flag: a numeric value that has the bit to be evaluated
Example:
IsBitSet(&HF,4)
Returns True because bit "4" is set in the hexadecimal value "F"
IsDate
Description:
If the expression can be evaluates as a DateTime type, then the IsDate function evaluates to True.
Syntax:
bool IsDate(var Expression)
Remarks:
Used to determine if CDate() can be successful.
IsEmpty
Description:
If the attribute is present in the CS or MV but evaluates to an empty string, then the IsEmpty function evaluates to
True.
Syntax:
bool IsEmpty(var Expression)
IsGuid
Description:
If the string could be converted to a GUID, then the IsGuid function evaluated to true.
Syntax:
bool IsGuid(str GUID)
Remarks:
A GUID is defined as a string following one of these patterns: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx or {xxxxxxxx-
xxxx-xxxx-xxxx-xxxxxxxxxxxx}
Used to determine if CGuid() can be successful.
Example:
IIF(IsGuid([strAttribute]),CGuid([strAttribute]),NULL)
If the StrAttribute has a GUID format, return a binary representation, otherwise return a Null.
IsNull
Description:
If the expression evaluates to Null, then the IsNull function returns true.
Syntax:
bool IsNull(var Expression)
Remarks:
For an attribute, a Null is expressed by the absence of the attribute.
Example:
IsNull([displayName])
Returns True if the attribute is not present in the CS or MV.
IsNullOrEmpty
Description:
If the expression is null or an empty string, then the IsNullOrEmpty function returns true.
Syntax:
bool IsNullOrEmpty(var Expression)
Remarks:
For an attribute, this would evaluate to True if the attribute is absent or is present but is an empty string.
The inverse of this function is named IsPresent.
Example:
IsNullOrEmpty([displayName])
Returns True if the attribute is not present or is an empty string in the CS or MV.
IsNumeric
Description:
The IsNumeric function returns a Boolean value indicating whether an expression can be evaluated as a number
type.
Syntax:
bool IsNumeric(var Expression)
Remarks:
Used to determine if CNum() can be successful to parse the expression.
IsString
Description:
If the expression can be evaluated to a string type, then the IsString function evaluates to True.
Syntax:
bool IsString(var expression)
Remarks:
Used to determine if CStr() can be successful to parse the expression.
IsPresent
Description:
If the expression evaluates to a string that is not Null and is not empty, then the IsPresent function returns true.
Syntax:
bool IsPresent(var expression)
Remarks:
The inverse of this function is named IsNullOrEmpty.
Example:
Switch(IsPresent([directManager]),[directManager], IsPresent([skiplevelManager]),[skiplevelManager],
IsPresent([director]),[director])
Item
Description:
The Item function returns one item from a multi-valued string/attribute.
Syntax:
var Item(mvstr attribute, num index)
attribute: multi-valued attribute
index: index to an item in the multi-valued string.
Remarks:
The Item function is useful together with the Contains function since the latter function returns the index to an
item in the multi-valued attribute.
Throws an error if index is out of bounds.
Example:
Mid(Item([proxyAddress],Contains([proxyAddress], "SMTP:")),6)
Returns the primary email address.
ItemOrNull
Description:
The ItemOrNull function returns one item from a multi-valued string/attribute.
Syntax:
var ItemOrNull(mvstr attribute, num index)
attribute: multi-valued attribute

index: index to an item in the multi-valued string.
Remarks:
The ItemOrNull function is useful together with the Contains function since the latter function returns the index to
an item in the multi-valued attribute.
If index is out of bounds, then returns a Null value.
Join
Description:
The Join function takes a multi-valued string and returns a single-valued string with specified separator inserted
between each item.
Syntax:
str Join(mvstr attribute)
str Join(mvstr attribute, str Delimiter)
attribute: Multi-valued attribute containing strings to be joined.

delimiter: Any string, used to separate the substrings in the returned string. If omitted, the space character (" ")
is used. If Delimiter is a zero-length string ("") or Nothing, all items in the list are concatenated with no
delimiters.
Remarks
There is parity between the Join and Split functions. The Join function takes an array of strings and joins them
using a delimiter string, to return a single string. The Split function takes a string and separates it at the delimiter,
to return an array of strings. However, a key difference is that Join can concatenate strings with any delimiter
string, Split can only separate strings using a single character delimiter.
Example:
Join([proxyAddresses],",")
Could return: "SMTP:john.doe@contoso.com,smtp:jd@contoso.com"
LCase
Description:
The LCase function converts all characters in a string to lower case.
Syntax:
str LCase(str value)
Example:
LCase("TeSt")
Returns "test".
Left
Description:
The Left function returns a specified number of characters from the left of a string.
Syntax:
str Left(str string, num NumChars)
string: the string to return characters from

NumChars: a number identifying the number of characters to return from the beginning (left) of string
Remarks:
A string containing the first numChars characters in string:
If numChars = 0, return empty string.
If numChars < 0, return input string.
If string is null, return empty string.
If string contains fewer characters than the number specified in numChars, a string identical to string (that is,
containing all characters in parameter 1) is returned.
Example:
Left("John Doe", 3)
Returns "Joh".
Len
Description:
The Len function returns number of characters in a string.
Syntax:
num Len(str value)
Example:
Len("John Doe")
Returns 8
LTrim
Description:
The LTrim function removes leading white spaces from a string.
Syntax:
str LTrim(str value)
Example:
LTrim(" Test ")
Returns "Test "
Mid
Description:
The Mid function returns a specified number of characters from a specified position in a string.
Syntax:
str Mid(str string, num start, num NumChars)

start: a number identifying the starting position in string to return characters from
NumChars: a number identifying the number of characters to return from position in string
Remarks:
Return numChars characters starting from position start in string.
A string containing numChars characters from position start in string:
If start > the length of string, return input string.
If start <= 0, return input string.
If there are not numChar characters remaining in string from position start, as many characters as possible are
returned.
Example:
Mid("John Doe", 3, 5)
Returns "hn Do".
Mid("John Doe", 6, 999)
Returns "Doe"
Now
Description:
The Now function returns a DateTime specifying the current date and time, according to your computer's system
date and time.
Syntax:
dt Now()
NumFromDate
Description:
The NumFromDate function returns a date in ADs date format.
Syntax:
num NumFromDate(dt value)
Example:
NumFromDate(CDate("2012-01-01 23:00:00"))
Returns 129699324000000000
PadLeft
Description:
The PadLeft function left-pads a string to a specified length using a provided padding character.
Syntax:
str PadLeft(str string, num length, str padCharacter)
string: the string to pad.

length: An integer representing the desired length of string.
padCharacter: A string consisting of a single character to use as the pad character
Remarks:
If the length of string is less than length, then padCharacter is repeatedly appended to the beginning (left) of
string until it has a length equal to length.
PadCharacter can be a space character, but it cannot be a null value.
If the length of string is equal to or greater than length, string is returned unchanged.
If string has a length greater than or equal to length, a string identical to string is returned.
If the length of string is less than length, then a new string of the desired length is returned containing string
padded with a padCharacter.
If string is null, the function returns an empty string.
Example:
PadLeft("User", 10, "0")
Returns "000000User".
PadRight
Description:
The PadRight function right-pads a string to a specified length using a provided padding character.
Syntax:
str PadRight(str string, num length, str padCharacter)
string: the string to pad.

length: An integer representing the desired length of string.
padCharacter: A string consisting of a single character to use as the pad character
Remarks:
If the length of string is less than length, then padCharacter is repeatedly appended to the end (right) of string
until it has a length equal to length.
padCharacter can be a space character, but it cannot be a null value.
If the length of string is equal to or greater than length, string is returned unchanged.
If string has a length greater than or equal to length, a string identical to string is returned.
If the length of string is less than length, then a new string of the desired length is returned containing string
padded with a padCharacter.
If string is null, the function returns an empty string.
Example:
PadRight("User", 10, "0")
Returns "User000000".
PCase
Description:
The PCase function converts the first character of each space delimited word in a string to upper case, and all
other characters are converted to lower case.
Syntax:
String PCase(string)
Remarks:
This function does not currently provide proper casing to convert a word that is entirely uppercase, such as an
acronym.
Example:
PCase("TEsT")
Returns "Test".
PCase(LCase("TEST"))
Returns "Test"
RandomNum
Description:
The RandomNum function returns a random number between a specified interval.
Syntax:
num RandomNum(num start, num end)
start: a number identifying the lower limit of the random value to generate
end: a number identifying the upper limit of the random value to generate
Example:
Random(100,999)
Can return 734.
RemoveDuplicates
Description:
The RemoveDuplicates function takes a multi-valued string and make sure each value is unique.
Syntax:
mvstr RemoveDuplicates(mvstr attribute)
Example:
RemoveDuplicates([proxyAddresses])
Returns a sanitized proxyAddress attribute where all duplicate values have been removed.
Replace
Description:
The Replace function replaces all occurrences of a string to another string.
Syntax:
str Replace(str string, str OldValue, str NewValue)
string: A string to replace values in.

OldValue: The string to search for and to replace.
NewValue: The string to replace to.
Remarks:
The function recognizes the following special monikers:
\n New Line
\r Carriage Return
\t Tab
Example:
Replace([address],"\r\n",", ")
Replaces CRLF with a comma and space, and could lead to "One Microsoft Way, Redmond, WA, USA"
ReplaceChars
Description:
The ReplaceChars function replaces all occurrences of characters found in the ReplacePattern string.
Syntax:
str ReplaceChars(str string, str ReplacePattern)
string: A string to replace characters in.

ReplacePattern: a string containing a dictionary with characters to replace.
The format is {source1}:{target1},{source2}:{target2},{sourceN},{targetN} where source is the character to find and
target the string to replace with.
Remarks:
The function takes each occurrence of defined sources and replaces them with the targets.
The source must be exactly one (unicode) character.
The source cannot be empty or longer than one character (parsing error).
The target can have multiple characters, for example :oe, :ss.
The target can be empty indicating that the character should be removed.
The source is case-sensitive and must be an exact match.
The , (comma) and : (colon) are reserved characters and cannot be replaced using this function.
Spaces and other white characters in the ReplacePattern string are ignored.
Example:
%ReplaceString% = :,:A,:A,:O,:a,:a,,o
ReplaceChars("Rksmrgs",%ReplaceString%)
Returns Raksmorgas
ReplaceChars("ONeil",%ReplaceString%)
Returns "ONeil", the single tick is defined to be removed.
Right
Description:
The Right function returns a specified number of characters from the right (end) of a string.
Syntax:
str Right(str string, num NumChars)

NumChars: a number identifying the number of characters to return from the end (right) of string
Remarks:
NumChars characters are returned from the last position of string.
A string containing the last numChars characters in string:
If string contains fewer characters than the number specified in NumChars, a string identical to string is returned.
Example:
Right("John Doe", 3)
Returns "Doe".
RTrim
Description:
The RTrim function removes trailing white spaces from a string.
Syntax:
str RTrim(str value)
Example:
RTrim(" Test ")
Returns " Test".
Split
Description:
The Split function takes a string separated with a delimiter and makes it a multi-valued string.
Syntax:
mvstr Split(str value, str delimiter)
mvstr Split(str value, str delimiter, num limit)
value: the string with a delimiter character to separate.

delimiter: single character to be used as the delimiter.
limit: maximum number of values that can return.
Example:
Split("SMTP:john.doe@contoso.com,smtp:jd@contoso.com",",")
Returns a multi-valued string with 2 elements useful for the proxyAddress attribute.
StringFromGuid
Description:
The StringFromGuid function takes a binary GUID and converts it to a string
Syntax:
str StringFromGuid(bin GUID)
StringFromSid
Description:
The StringFromSid function converts a byte array containing a security identifier to a string.
Syntax:
str StringFromSid(bin ObjectSID)
Switch
Description:
The Switch function is used to return a single value based on evaluated conditions.
Syntax:
var Switch(exp expr1, var value1[, exp expr2, var value [, exp expr, var valueN]])
expr: Variant expression you want to evaluate.

value: Value to be returned if the corresponding expression is True.
Remarks:
The Switch function argument list consists of pairs of expressions and values. The expressions are evaluated from
left to right, and the value associated with the first expression to evaluate to True is returned. If the parts aren't
properly paired, a run-time error occurs.
For example, if expr1 is True, Switch returns value1. If expr-1 is False, but expr-2 is True, Switch returns value-2,
and so on.
Switch returns a Nothing if:
None of the expressions are True.
The first True expression has a corresponding value that is Null.
Switch evaluates all expressions, even though it returns only one of them. For this reason, you should watch for
undesirable side effects. For example, if the evaluation of any expression results in a division by zero error, an
error occurs.
Value can also be the Error function, which would return a custom string.
Example:
Switch([city] = "London", "English", [city] = "Rome", "Italian", [city] = "Paris", "French", True,
Error("Unknown city"))
Returns the language spoken in some major cities, otherwise returns an Error.
Trim
Description:
The Trim function removes leading and trailing white spaces from a string.
Syntax:
str Trim(str value)
Example:
Trim(" Test ")
Returns "Test".
Trim([proxyAddresses])
Removes leading and trailing spaces for each value in the proxyAddress attribute.
UCase
Description:
The UCase function converts all characters in a string to upper case.
Syntax:
str UCase(str string)
Example:
UCase("TeSt")
Returns "TEST".
Word
Description:
The Word function returns a word contained within a string, based on parameters describing the delimiters to use
and the word number to return.
Syntax:
str Word(str string, num WordNumber, str delimiters)
string: the string to return a word from.

WordNumber: a number identifying which word number should return.
delimiters: a string representing the delimiter(s) that should be used to identify words
Remarks:
Each string of characters in string separated by the one of the characters in delimiters are identified as words:
If number < 1, returns empty string.
If string is null, returns empty string.
If string contains less than number words, or string does not contain any words identified by delimiters, an empty
string is returned.
Example:
Word("The quick brown fox",3," ")
Returns "brown"
Word("This,string!has&many separators",3,",!&#")
Would return "has"
Understanding Declarative Provisioning Expressions
Azure AD Connect sync: Operational tasks and
consideration
The objective of this topic is to describe operational tasks for Azure AD Connect sync.
Staging mode
Staging mode can be used for several scenarios, including:
High availability.
Test and deploy new configuration changes.
Introduce a new server and decommission the old.
With a server in staging mode, you can make changes to the configuration and preview the changes before you
make the server active. It also allows you to run full import and full synchronization to verify that all changes are
expected before you make these changes into your production environment.
During installation, you can select the server to be in staging mode. This action makes the server active for
import and synchronization, but it does not run any exports. A server in staging mode is not running password
sync or password writeback, even if you selected these features during installation. When you disable staging
mode, the server starts exporting, enables password sync, and enables password writeback.
You can still force an export by using the synchronization service manager.
A server in staging mode continues to receive changes from Active Directory and Azure AD. It always has a copy of
the latest changes and can very fast take over the responsibilities of another server. If you make configuration
changes to your primary server, it is your responsibility to make the same changes to the server in staging mode.
For those of you with knowledge of older sync technologies, the staging mode is different since the server has its
own SQL database. This architecture allows the staging mode server to be located in a different datacenter.
Verify the configuration of a server
To apply this method, follow these steps:
1. Prepare
2. Import and Synchronize
3. Verify
4. Switch active server
Prepare
1. Install Azure AD Connect, select staging mode, and unselect start synchronization on the last page in the
installation wizard. This mode allows you to run the sync engine manually.
2. Sign off/sign in and from the start menu select Synchronization Service.
Import and Synchronize
1. Select Connectors, and select the first Connector with the type Active Directory Domain Services. Click Run,
select Full import, and OK. Do these steps for all Connectors of this type.
2. Select the Connector with type Azure Active Directory (Microsoft). Click Run, select Full import, and OK.
3. Make sure the tab Connectors is still selected. For each Connector with type Active Directory Domain
Services, click Run, select Delta Synchronization, and OK.
4. Select the Connector with type Azure Active Directory (Microsoft). Click Run, select Delta
Synchronization, and OK.
You have now staged export changes to Azure AD and on-premises AD (if you are using Exchange hybrid
deployment). The next steps allow you to inspect what is about to change before you actually start the export to
the directories.
Verify
1. Start a cmd prompt and go to %ProgramFiles%\Microsoft Azure AD Sync\bin
2. Run: csexport "Name of Connector" %temp%\export.xml /f:x
The name of the Connector can be found in Synchronization Service. It has a name similar to "contoso.com
AAD" for Azure AD.
3. Run: CSExportAnalyzer %temp%\export.xml > %temp%\export.csv
4. You have a file in %temp% named export.csv that can be examined in Microsoft Excel. This file contains all
changes that are about to be exported.
5. Make necessary changes to the data or configuration and run these steps again (Import and Synchronize and
Verify) until the changes that are about to be exported are expected.
Understanding the export.csv file
Most of the file is self-explanatory. Some abbreviations to understand the content:
OMODT Object Modification Type. Indicates if the operation at an object level is an Add, Update, or Delete.
AMODT Attribute Modification Type. Indicates if the operation at an attribute level is an Add, Update, or
delete.
If the attribute value is multi-valued, then not every change is displayed. Only the number of values added and
removed is visible.
Switch active server
1. On the currently active server, either turn off the server (DirSync/FIM/Azure AD Sync) so it is not exporting to
Azure AD or set it in staging mode (Azure AD Connect).
2. Run the installation wizard on the server in staging mode and disable staging mode.
Disaster recovery
Part of the implementation design is to plan for what to do if there is a disaster where you lose the sync server.
There are different models to use and which one to use depends on several factors including:
What is your tolerance for not being able make changes to objects in Azure AD during the downtime?
If you use password synchronization, do the users accept that they have to use the old password in Azure AD in
case they change it on-premises?
Do you have a dependency on real-time operations, such as password writeback?
Depending on the answers to these questions and your organizations policy, one of the following strategies can
be implemented:
Rebuild when needed.
Have a spare standby server, known as staging mode.
Use virtual machines.
If you do not use the built-in SQL Express database, then you should also review the SQL High Availability section.
Rebuild when needed
A viable strategy is to plan for a server rebuild when needed. Usually, installing the sync engine and do the initial
import and sync can be completed within a few hours. If there isnt a spare server available, it is possible to
temporarily use a domain controller to host the sync engine.
The sync engine server does not store any state about the objects so the database can be rebuilt from the data in
Active Directory and Azure AD. The sourceAnchor attribute is used to join the objects from on-premises and the
cloud. If you rebuild the server with existing objects on-premises and the cloud, then the sync engine matches
those objects together again on reinstallation. The things you need to document and save are the configuration
changes made to the server, such as filtering and synchronization rules. These custom configurations must be
reapplied before you start synchronizing.
Have a spare standby server - staging mode
If you have a more complex environment, then having one or more standby servers is recommended. During
installation, you can enable a server to be in staging mode.
For more details, see staging mode.
Use virtual machines
A common and supported method is to run the sync engine in a virtual machine. In case the host has an issue, the
image with the sync engine server can be migrated to another server.
SQL High Availability
If you are not using the SQL Server Express that comes with Azure AD Connect, then high availability for SQL
Server should also be considered. The only high availability solution supported is SQL clustering. Unsupported
solutions include mirroring and Always On.
Next steps
Overview topics
Azure AD federation compatibility list
Azure Active Directory provides single-sign on and enhanced application access security for Office 365 and other
Microsoft Online services for hybrid and cloud-only implementations without requiring any non-Microsoft
solution. Office 365, like most of Microsofts Online services, is integrated with Azure Active Directory for directory
services, authentication and authorization. Azure Active Directory also provides single sign-on to thousands of
SaaS applications and on-premises web applications. Please see the Azure Active Directory application gallery for
supported SaaS applications.
For organizations that have invested in non-Microsoft federation solutions, this topic contains guidance for
configuring single sign-on for their Windows Server Active Directory users with Microsoft Online services by using
non-Microsoft identity providers from the Azure Active Directory federation compatibility list below.
Oxford Computer Group, a third-party, on behalf of Microsoft, tested these single sign-on experiences using non-
Microsoft identity providers against a set of use cases common with Azure Active Directory.
For information on how you can get your third-party identity provider listed here, contact Oxford Computer Group
at idp@oxfordcomputergroup.com.
IMPORTANT
Oxford Computer Group tested only the federation functionality of these single sign-on scenarios. Oxford Computer Group
did not perform any testing of the synchronization, two-factor authentication, etc. components of these single sign-on
scenarios.
Use of Sign-in by Alternate ID to UPN is also not tested in this program.

Optimal IDM Virtual Identity Server Federation Services
PingFederate 6.11
PingFederate 7.2
PingFederate 8.x
Centrify
IBM Tivoli Federated Identity Manager 6.2.2
SecureAuth IdP 7.2.0
CA SiteMinder 12.52
RadiantOne CFS 3.0
Okta
OneLogin
NetIQ Access Manager 4.0.1
BIG-IP with Access Policy Manager BIG-IP ver. 11.3x 11.6x
VMware Workspace Portal version 2.1
Sign&go 5.3
IceWall Federation Version 3.0
CA Secure Cloud
Dell One Identity Cloud Access Manager v7.1
AuthAnvil Single Sign On 4.5
Sailpoint IdentityNow
IMPORTANT
Since these are third-party products, Microsoft does not provide support for the deployment, configuration, troubleshooting,
best practices, etc. issues and questions regarding these identity providers. For support and questions regarding these
identity providers, contact the supported third-parties directly.
These third-party identity providers were tested for interoperability with Microsoft cloud services using WS-Federation and
WS-Trust protocols only. Testing did not include using the SAML protocol.

Azure Active Directory can authenticate users by federating with your on-premises Active-Directory or without an
on-premises federation server through the use of password sync.
The following is the scenario support matrix for this sign-on experience:
CLIENT SUPPORT EXCEPTIONS
Web-based clients such as Exchange Supported None

Web Access and SharePoint Online
Rich client applications such as Lync, Supported None

Office Subscription, CRM
Email-rich clients such as Outlook and Supported None

ActiveSync
Modern Applications using ADAL such Supported None

as Office 2016
For more information about using Azure Active Directory with AD FS see Active Directory Federation Services
(ADFS)
For more information about using Azure Active Directory with Password sync see Azure AD Connect.
Optimal IDM Virtual Identity Server Federation Services

Optimal IDM Virtual Identity Server Federation Services can authenticate users that reside in customers on-
premises Active Directories.
The following is the scenario support matrix this single sign-on experience:

Rich client applications such as Lync, Supported Integrated Windows Authentication

Email-rich clients such as Outlook and Supported For more information about client
ActiveSync access polices see Limiting Access to
Office 365 Services Based on the
Location of the Client.
PingFederate 6.11
PingFederate 6.11 implements the widely used WS Federation identity standard to provide a single sign-on and
attribute exchange framework.
The following is the scenario support matrix for this single sign-on experience:

Rich client applications such as Lync, Supported None (earlier versions must upgrade to
Office Subscription, CRM 6.11

ActiveSync
For the PingFederate instructions on how to configure this STS to provide the single sign-on experience to your
Active Directory users, download the pdf here.
PingFederate 7.2
PingFederate 7.2 implements the widely used WS Federation/WS-Trust identity standard to provide a single sign-
on and attribute exchange framework.



ActiveSync
Active Directory users, see here.
PingFederate 8.x
PingFederate 8.x implements the widely used WS Federation/WS-Trust identity standard to provide a single sign-



ActiveSync
Active Directory users, see here.
Centrify
Centrify helps provide a federated single sign-on experience for Office 365 without the requirement of hosting an
on-premises Federation server.


Email-rich clients such as Outlook and Supported Client Access Control is not supported
ActiveSync
For more information about Centrify, see here.|
IBM Tivoli Federated Identity Manager 6.2.2

IBM Tivoli Federated Identity Manager 6.2.2 with IBM Security Access Manager for Microsoft Applications 1.4
implements the widely used WS Federation/WS-Trust identity standard to provide a single sign-on and attribute
exchange framework.



ActiveSync
For more information about IBM Tivoli Federated Identity Manager, see IBM Security Access Manager for Microsoft
Applications.
SecureAuth IdP 7.2.0
SecureAuth IdP 7.2.0 implements the widely used WS Federation/WS-Trust identity standard to provide a single
sign-on experience and attribute exchange framework.



ActiveSync
For more information about SecureAuth, see SecureAuth IdP.
CA SiteMinder 12.52 SP1 Cumulative Release 4

CA SiteMinder Federation 12.52 implements the widely used WS Federation/WS-Trust identity standard to provide
a single sign-on and attribute exchange framework.



ActiveSync
For more information about CA SiteMinder, see CA SiteMinder Federation.
RadiantOne CFS 3.0

RadiantOne Cloud Federation Service (CFS) 3.0 implements the widely used WS Federation/WS-Trust identity
standard to provide a single sign-on and attribute exchange framework.



ActiveSync
For more information about RadiantOne CFS, see RadiantOne CFS.
Okta
Okta implements the widely used WS Federation/WS-Trust identity standard to provide a single sign-on and
attribute exchange framework.
Web-based clients such as Exchange Supported Integrated Windows Authentication

Web Access and SharePoint Online requires setup of additional web server
and Okta application.


ActiveSync
For more information about Okta, see Okta.
OneLogin
OneLogin as tested in May 2014 implements the widely used WS Federation/WS-Trust identity standard to
provide a single sign-on and attribute exchange framework.
Web-based clients such as Exchange Supported Integrated Windows Authentication



ActiveSync
For more information about OneLogin, see OneLogin.
NetIQ Access Manager 4.0.1

NetIQ Access Manager 4.0.1 implements the widely used WS Federation/WS-Trust identity standard to provide a
single sign-on and attribute exchange framework.
Web-based clients such as Exchange Supported *Kerberos Contracts supported

Rich client applications such as Lync, Supported Integrated Windows Authentication is

Office Subscription, CRM not supported

ActiveSync
*NetIQ support Kerberos authentication via configuration of a Kerberos Contract. For assistance with this
configuration, please contact NetIQ or view the setup guide. For more information about NetIQ Access Manager,
see NetIQ Access Manager.
BIG-IP with Access Policy Manager BIG-IP ver. 11.3x 11.6x

The BIG-IP with Access Policy Manager, (APM) BIG-IP ver. 11.3x 11.6x implements the widely used SAML identity
standard to provide a single sign-on experience and attribute exchange framework.

Rich client applications such as Lync, Not Supported Not Supported


ActiveSync
For more information about BIG-IP Access Policy Manager, see BIG-IP Access Policy Manager.
For the BIG-IP Access Policy Manager instructions on how to configure this STS to provide the single sign-on
experience to your Active Directory Users, download the pdf here.
VMware Workspace Portal version 2.1

VMware Workspace Portal version 2.1 implements the widely used WS Federation/WS-Trust identity standard to
Web-based clients such as Exchange Supported Integrated Windows Authentication is

Web Access and SharePoint Online not supported


ActiveSync
For more information about VMware Workspace Portal version 2.1, download the pdf here.
Sign&go 5.3
Sign&go 5.3 implements the widely used WS Federation/WS-Trust identity standard to provide a single sign-on
and attribute exchange framework.
Web-based clients such as Exchange Supported Kerberos Contracts supported



ActiveSync
Sign&go 5.3 supports Kerberos authentication via configuration of a Kerberos Contract. For assistance with this
configuration, please contact Ilex or view the setup guide here.
IceWall Federation Version 3.0

IceWall Federation Version 3.0 implements the widely used WS Federation/WS-Trust identity standard to provide a



ActiveSync
For more information about IceWall Federation, see here and here.
CA Secure Cloud
CA Secure Cloud implements the widely used WS Federation/WS-Trust identity standard to provide a single sign-



ActiveSync
For more information about CA Secure Cloud, see CA Secure Cloud.
Dell One Identity Cloud Access Manager v7.1

Dell One Identity Cloud Access Manager implements the widely used WS Federation/WS-Trust identity standard to



ActiveSync
For more information about Dell One Identity Cloud Access Manager, see Dell One Identity Cloud Access Manager.
For the instructions on how to configure this STS to provide the single sign-on experience to your Office 365
Users, see Configure Office 365 Users.
AuthAnvil Single Sign On 4.5

AuthAnvil Single Sign On 4.5 implements the widely used WS Federation/WS-Trust identity standard to provide a



ActiveSync
For more information, see AuthAnvil Single Sign On.
Sailpoint IdentityNow
Sailpoint IdentityNow implements the widely used WS Federation/WS-Trust identity standards to provide a single
sign-on and attribute exchange framework.



ActiveSync
For more information, see Sailpoint IdentityNow.

Azure AD Connect sync: Technical Concepts
This article is a summary of the topic Understanding architecture.

Azure AD Connect sync builds upon a solid metadirectory synchronization platform. The following sections
introduce the concepts for metadirectory synchronization. Building upon MIIS, ILM, and FIM, the Azure Active
Directory Sync Services provides the next platform for connecting to data sources, synchronizing data between
data sources, as well as the provisioning and deprovisioning of identities.
The following sections provide more details about the following aspects of the FIM Synchronization Service:
Connector
Attribute flow
Connector space
Metaverse
Provisioning
Connector
The code modules that are used to communicate with a connected directory are called connectors (formerly
known as management agents (MAs)).
These are installed on the computer running Azure AD Connect sync. The connectors provide the agentless ability
to converse by using remote system protocols instead of relying on the deployment of specialized agents. This
means decreased risk and deployment times, especially when dealing with critical applications and systems.
In the picture above, the connector is synonymous with the connector space but encompasses all communication
with the external system.
The connector is responsible for all import and export functionality to the system and frees developers from
needing to understand how to connect to each system natively when using declarative provisioning to customize
data transformations.
Imports and exports only occur when scheduled, allowing for further insulation from changes occurring within the
system, since changes do not automatically propagate to the connected data source. In addition, developers may
also create their own connectors for connecting to virtually any data source.
Attribute flow
The metaverse is the consolidated view of all joined identities from neighboring connector spaces. In the figure
above, attribute flow is depicted by lines with arrowheads for both inbound and outbound flow. Attribute flow is
the process of copying or transforming data from one system to another and all attribute flows (inbound or
outbound).
Attribute flow occurs between the connector space and the metaverse bi-directionally when synchronization (full
or delta) operations are scheduled to run.
Attribute flow only occurs when these synchronizations are run. Attribute flows are defined in Synchronization
Rules. These can be inbound (ISR in the picture above) or outbound (OSR in the picture above).
Connected system
Connected system (aka connected directory) is referring to the remote system Azure AD Connect sync has
connected to and reading and writing identity data to and from.
Connector space
Each connected data source is represented as a filtered subset of the objects and attributes in the connector space.
This allows the sync service to operate locally without the need to contact the remote system when synchronizing
the objects and restricts interaction to imports and exports only.
When the data source and the connector have the ability to provide a list of changes (a delta import), then the
operational efficiency increases dramatically as only changes since the last polling cycle are exchanged. The
connector space insulates the connected data source from changes propagating automatically by requiring that
the connector schedule imports and exports. This added insurance grants you peace of mind while testing,
previewing, or confirming the next update.
Metaverse
The metaverse is the consolidated view of all joined identities from neighboring connector spaces.
As identities are linked together and authority is assigned for various attributes through import flow mappings,
the central metaverse object begins to aggregate information from multiple systems. From this object attribute
flow, mappings carry information to outbound systems.
Objects are created when an authoritative system projects them into the metaverse. As soon as all connections are
removed, the metaverse object is deleted.
Objects in the metaverse cannot be edited directly. All data in the object must be contributed through attribute
flow. The metaverse maintains persistent connectors with each connector space. These connectors do not require
reevaluation for each synchronization run. This means that Azure AD Connect sync does not have to locate the
matching remote object each time. This avoids the need for costly agents to prevent changes to attributes that
would normally be responsible for correlating the objects.
When discovering new data sources that may have preexisting objects that need to be managed, Azure AD
Connect sync uses a process called a join rule to evaluate potential candidates with which to establish a link. Once
the link is established, this evaluation does not reoccur and normal attribute flow can occur between the remote
connected data source and the metaverse.
Provisioning
When an authoritative source projects a new object into the metaverse a new connector space object can be
created in another Connector representing a downstream connected data source.
This inherently establishes a link, and attribute flow can proceed bi-directionally.
Whenever a rule determines that a new connector space object needs to be created, it is called provisioning.
However, because this operation only takes place within the connector space, it does not carry over into the
connected data source until an export is performed.
Azure AD Connect sync service features
The synchronization feature of Azure AD Connect has two components:

The on-premises component named Azure AD Connect sync, also called sync engine.
The service residing in Azure AD also known as Azure AD Connect sync service
This topic explains how the following features of the Azure AD Connect sync service work and how you can
configure them using Windows PowerShell.
These settings are configured by the Azure Active Directory Module for Windows PowerShell. Download and
install it separately from Azure AD Connect. The cmdlets documented in this topic were introduced in the 2016
March release (build 9031.1). If you do not have the cmdlets documented in this topic or they do not produce the
same result, then make sure you run the latest version.
To see the configuration in your Azure AD directory, run Get-MsolDirSyncFeatures .
Many of these settings can only be changed by Azure AD Connect.

The following settings can be configured by Set-MsolDirSyncFeature :
DIRSYNCFEATURE COMMENT
DuplicateProxyAddressResiliency Allows an attribute to be quarantined when it is a duplicate of

DuplicateUPNResiliency another object rather than failing the entire object during
export.
EnableSoftMatchOnUpn Allows objects to join on userPrincipalName in addition to

primary SMTP address.
SynchronizeUpnForManagedUsers Allows the sync engine to update the userPrincipalName

attribute for managed/licensed (non-federated) users.
After you have enabled a feature, it cannot be disabled again.
NOTE
From August 24, 2016 the feature Duplicate attribute resiliency is enabled by default for new Azure AD directories. This
feature will also be rolled out and enabled on directories created before this date. You will receive an email notification when
your directory is about to get this feature enabled.
The following settings are configured by Azure AD Connect and cannot be modified by Set-MsolDirSyncFeature :
DIRSYNCFEATURE COMMENT
DeviceWriteback Azure AD Connect: Enabling device writeback
DirectoryExtensions Azure AD Connect sync: Directory extensions
PasswordSync Implementing password synchronization with Azure AD

Connect sync
UnifiedGroupWriteback Preview: Group writeback
UserWriteback Not currently supported.
Duplicate attribute resiliency

Instead of failing to provision objects with duplicate UPNs / proxyAddresses, the duplicated attribute is
quarantined and a temporary value is assigned. When the conflict is resolved, the temporary UPN is changed to
the proper value automatically. This behavior can be enabled for UPN and proxyAddress separately. For more
details, see Identity synchronization and duplicate attribute resiliency.
UserPrincipalName soft match

When this feature is enabled, soft-match is enabled for UPN in addition to the primary SMTP address, which is
always enabled. Soft-match is used to match existing cloud users in Azure AD with on-premises users.
If you need to match on-premises AD accounts with existing accounts created in the cloud and you are not using
Exchange Online, then this feature is useful. In this scenario, you generally dont have a reason to set the SMTP
attribute in the cloud.
This feature is on by default for newly created Azure AD directories. You can see if this feature is enabled for you
by running:
Get-MsolDirSyncFeatures -Feature EnableSoftMatchOnUpn
If this feature is not enabled for your Azure AD directory, then you can enable it by running:
Set-MsolDirSyncFeature -Feature EnableSoftMatchOnUpn -Enable $true
Synchronize userPrincipalName updates

Historically, updates to the UserPrincipalName attribute using the sync service from on-premises has been
blocked, unless both of these conditions are true:
The user is managed (non-federated).
The user has not been assigned a license.
For more details, see User names in Office 365, Azure, or Intune don't match the on-premises UPN or alternate
login ID.
Enabling this feature allows the sync engine to update the userPrincipalName when it is changed on-premises and
you use password sync. If you use federation, this feature is not supported.
This feature is on by default for newly created Azure AD directories. You can see if this feature is enabled for you
by running:
Get-MsolDirSyncFeatures -Feature SynchronizeUpnForManagedUsers
If this feature is not enabled for your Azure AD directory, then you can enable it by running:
Set-MsolDirSyncFeature -Feature SynchronizeUpnForManagedUsers -Enable $true
After enabling this feature, existing userPrincipalName values will remain as-is. On next change of the
userPrincipalName attribute on-premises, the normal delta sync on users will update the UPN.
See also
Azure AD Connect sync
Integrating your on-premises identities with Azure Active Directory.
Monitor your on-premises identity infrastructure and
synchronization services in the cloud
Azure AD Connect Health helps you monitor and gain insight into your on-premises identity infrastructure and the
synchronization services. It enables you to maintain a reliable connection to Office 365 and Microsoft Online
Services by providing monitoring capabilities for your key identity components such as AD FS Servers, Azure AD
Connect servers (aka Sync Engine), Active Directory Domain Controllers etc. It also makes the key data points
about these components easily accessible, making it easy to get usage and other important insights to take
informed decisions.
The information is presented to you in the Azure AD Connect Health Portal. Using the Azure AD Connect Health
portal you can view alerts, performance monitoring, usage analytics and much more. Azure AD Connect Health
enables the single lens of health for your key identity components, all at one place.
Future updates to Azure AD Connect Health will include additional monitoring and insight into additional identity
components. Thus providing you a single dash board through the lens of identity, enabling you to have an even
more robust, healthy, and integrated environment that your users can take advantage of to increase their ability to
get things done.
Why use Azure AD Connect Health

Integrating your on-premises directories with Azure AD makes your users more productive by providing a
common identity for accessing both cloud and on-premises resources. However, with this integration comes the
challenges of ensuring that this environment is healthy so that users can reliably access resources both on-
premises and in cloud from any device. Azure AD Connect Health provides an easy cloud-based approach to
monitor and gain insights into your on-premises identity infrastructure that is used to access Office 365 or other
Azure AD applications. It is as simple as installing an agent on each of your on-premises identity servers.
Azure AD Connect Health for AD FS

Azure AD Connect Health for AD FS supports AD FS 2.0 on Windows Server 2008 R2, AD FS in Windows Server
2012 and Windows Server 2012R2. It also supports monitoring the AD FS Proxy or Web Application Proxy servers
that provide authentication support for extranet access. With an easy and low-cost installation of the health agent,
Azure AD Connect Health for AD FS provides the following set of key capabilities:
Monitoring with alerts to know when AD FS and AD FS Proxy servers are not healthy
Email notifications for critical alerts
View trends in performance data, useful for capacity planning of AD FS
Usage analytics for AD FS logins with different pivot (apps, users, network location etc.) useful in understand
how AD FS is getting utilized.
Reports for AD FS such as Top 50 users with bad Username/Password attempts with last IP address
The following video provides an overview of Azure AD Connect Health for AD FS
Azure AD Connect Health for Sync

Azure AD Connect Health for Sync monitors and provides information on the synchronizations that occur between
your on-premises Active Directory and Azure Active Directory. Azure AD Connect Health for Sync provides the
following set of key capabilities:
Monitoring with alerts to know when Azure AD Connect servers aka the Sync Engine is not healthy
Email notifications for critical alerts
Sync operational insights including latency charts for Sync Operations and trends in different operations such
as adds, updates, deletes.
Quick glance information about sync properties, last successful export to Azure AD
Reports about object level synchronization errors (does not require Azure AD Premium)
The following video provides an overview of Azure AD Connect Health for sync
Azure AD Connect Health for AD DS (preview)

Azure AD Connect Health for AD DS provides monitoring for Domain Controllers installed on Windows Server
2008 R2, Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016. An easy and low-cost
health agent installation, enables you to monitor your on-premises AD DS environment straight from the cloud.
Azure AD Connect Health for AD DS provides the following set of key capabilities:
Monitoring alerts to detect when domain controllers are unhealthy, along with email notifications for critical
alerts.
Domain Controllers dashboard, which provides a quick view into the health and operational status of your
domain controllers.
Replication Status dashboard with latest replication information, along with links to troubleshooting guides
when errors are detected.
Quick anywhere access to performance data graphs of popular performance counters, necessary for
troubleshooting and monitoring purposes.
The following video provides an overview of Azure AD Connect Health for AD DS
Get started with Azure AD Connect Health

It is very easy to get started with Azure AD Connect Health. Follow the steps below:
1. Get Azure AD Premium or start a trial
2. Download and Install Azure AD Connect Health agents on your identity servers.
3. View Azure AD Connect Health dashboard at https://aka.ms/aadconnecthealth
NOTE
Remember that before you see any data in your Azure AD Connect Health Dashboard, you will need to install the Azure AD
Connect Health Agents on your targeted servers.
Download and Install Azure AD Connect Health Agent

Make sure you satisfy the requirements for Azure AD Connect Health
Get started using Azure AD Connect Health for AD FS
Download Azure AD Connect Health Agent for AD FS.
See the Installation Instructions
Get started using Azure AD Connect Health for sync
Download and install the latest version of Azure AD Connect. The health agent for sync will be installed
as part of the Azure AD Connect installation (version 1.0.9125.0 or higher).
Get started using Azure AD Connect Health for AD DS
Download Azure AD Connect Health Agent for AD DS.
See the Installation Instructions
Azure AD Connect Health Portal

The Azure AD Connect Health portal allows you to view alerts, performance monitoring, and usage analytics.
https://aka.ms/aadconnecthealth takes you to the main blade of Azure AD Connect Health. You can think of a blade
as a window. On The main blade you see Quick Start, Services within Azure AD Connect Health and additional
configuration options. Below the screenshot is a brief explanation of each of these. After you've deployed the
agents, the health service automatically identifies for the services Azure AD Connect Health is monitoring.
Quick Start by selecting this you will open the Quick Start blade. Here you will be able to download the
Azure AD Connect Health agent by choosing Get Tools, access documentation, and provide feedback.
Active Directory Federation Services this represents all of the AD FS services that Azure AD Connect
Health is currently monitoring. By selecting one of the instances, a blade will open with information about that
services instance. This information includes an overview, properties, alerts, monitoring, and usage analytics.
Read more about the capabilities here.
Azure Active Directory Connect (Sync) this represents your Azure AD Connect servers that Azure AD
Connect Health is currently monitoring. By selecting the entry, a blade will open with information about your
Azure AD Connect servers. Read more about the capabilities here.
Active Directory Domain Services this represents all of the AD DS forests that Azure AD Connect Health is
currently monitoring. By selecting one of the forests, a blade will open with information about that forest. This
information includes an overview of essential information, Domain Controllers dashboard, Replication Status
dashboard, alerts and monitoring. Read more about the capabilities here.
Configure this allows you to turn the following on or off:
1. Auto update to automatically update the Azure AD Connect Health agent to the latest version - This
means that you will be automatically updated to the latest version of the Azure AD Connect Health Agent
when they become available. This is enabled by default.
2. Allow Microsoft access to your Azure AD directorys health data for troubleshooting purposes only - This
means that if this is enabled, Microsoft will be able to see the same data that you are seeing. This can
help with troubleshooting and assistance with issues. This is disabled by default.
Related links
Azure AD Connect Health Agent Installation
Azure AD Connect Health Operations
Using Azure AD Connect Health with AD FS
Using Azure AD Connect Health for Sync
Using Azure AD Connect Health with AD DS
Azure AD Connect Health FAQ
Azure AD Connect Health Version History
Frequently asked questions for Azure Active
Directory Connect
General installation
Q: Will installation work if the Azure AD Global Admin has 2FA enabled?
With the builds from February 2016, this is supported.
Q: Is there a way to install Azure AD Connect unattended?
It is only supported to install Azure AD Connect using the installation wizard. An unattended and silent installation
is not supported.
Q: I have a forest where one domain cannot be contacted. How do I install Azure AD Connect?
With the builds from February 2016, this is supported.
Q: Does the AD DS health agent work on server core?
Yes. After installing the agent, you can complete the registration process using the following PowerShell
commandlet:
Register-AzureADConnectHealthADDSAgent -Credentials $cred
Network
Q: I have a firewall, network device, or something else that limits the maximum time connections can
stay open on my network. How long should my client side timeout threshold be when using Azure AD
Connect?
All networking software, physical devices, or anything else that limits the maximum time connections can remain
open should use a threshold of at least 5 minutes (300 seconds) for connectivity between the server where the
Azure AD Connect client is installed and Azure Active Directory. This also applies to all previously released
Microsoft Identity synchronization tools.
Q: Are SLDs (Single Label Domains) supported?
No, Azure AD Connect does not support on-premises forests/domains using SLDs.
Q: Are "dotted" NetBios named supported?
No, Azure AD Connect does not support on-premises forests/domains where the NetBios name contains a period
"." in the name.
Federation
Q: What do I do if I receive an email that asking me to renew my Office 365 certificate
Use the guidance that is outlined in the renew certificates topic on how to renew the certificate.
Q: I have "Automatically update relying party" set for O365 relying party. Do I have to take any action
when my token signing certificate automatically rolls over?
Use the guidance that is outlined in the article renew certificates.
Environment
Q: Is it supported to rename the server after Azure AD Connect has been installed?
No. Changing the server name will cause the sync engine to not be able to connect to the SQL database and the
service will not be able to start.
Identity data
Q: The UPN (userPrincipalName) attribute in Azure AD does not match the on-prem UPN - why?
See these articles:
User names in Office 365, Azure, or Intune don't match the on-premises UPN or alternate login ID
Changes aren't synced by the Azure Active Directory Sync tool after you change the UPN of a user account to
use a different federated domain
You can also configure Azure AD to allow the sync engine to update the userPrincipalName as described in Azure
AD Connect sync service features.
Q: Is it supported to soft match on-premises AD Group/Contact objects with existing Azure AD
Group/Contact objects?
No, this is currently not supported.
Q: Is it supported to manually set ImmutableId attribute on existing Azure AD Group/Contact objects to
hard match it to on-premises AD Group/Contact objects?
No, this is currently not supported.
Custom configuration
Q: Where are the PowerShell cmdlets for Azure AD Connect documented?
With the exception of the cmdlets documented on this site, other PowerShell cmdlets found in Azure AD Connect
are not supported for customer use.
Q: Can I use "Server export/server import" found in Synchronization Service Manager to move
configuration between servers?
No. This option will not retrieve all configuration settings and should not be used. You should instead use the
wizard to create the base configuration on the second server and use the sync rule editor to generate PowerShell
scripts to move any custom rule between servers. See Move custom configuration from active to staging server.
Troubleshooting
Q: How can I get help with Azure AD Connect?
Search the Microsoft Knowledge Base (KB)
Search the Microsoft Knowledge Base (KB) for technical solutions to common break-fix issues about Support for
Azure AD Connect.
Microsoft Azure Active Directory Forums
You can search and browse for technical questions and answers from the community or ask your own question
by clicking here.
Azure AD Connect customer support
Use this link to get support through the Azure portal.
Upgrade Windows Azure Active Directory Sync
(DirSync) and Azure Active Directory Sync (Azure
AD Sync)
Azure AD Connect is the best way to connect your on-premises directory with Azure AD and Office 365. This is a
great time to upgrade to Azure AD Connect from Windows Azure Active Directory Sync (DirSync) or Azure AD Sync
as these tools are now deprecated and will reach end of support on April 13, 2017.
The two identity synchronization tools that are deprecated were offered for single forest customers (DirSync) and
for multi-forest and other advanced customers (Azure AD Sync). These older tools have been replaced with a single
solution that is available for all scenarios: Azure AD Connect. It offers new functionality, feature enhancements, and
support for new scenarios. To be able to continue to synchronize your on-premises identity data to Azure AD and
Office 365, we strongly recommend that you upgrade to Azure AD Connect.
The last release of DirSync was released in July 2014 and the last release of Azure AD Sync was released in May
2015.
What is Azure AD Connect

Azure AD Connect is the successor to DirSync and Azure AD Sync. It combines all scenarios these two supported.
You can read more about it in Integrating your on-premises identities with Azure Active Directory.
Deprecation schedule
DATE COMMENT
April 13, 2016 Windows Azure Active Directory Sync (DirSync) and
Microsoft Azure Active Directory Sync (Azure AD Sync) are
announced as deprecated.
April 13, 2017 Support ends. Customers will no longer be able to open a
support case without upgrading to Azure AD Connect first.
How to transition to Azure AD Connect

If you are running DirSync, there are two ways you can upgrade: In-place upgrade and parallel deployment. An in-
place upgrade is recommended for most customers and if you have a recent operating system and less than
50,000 objects. In other cases, it is recommended to do a parallel deployment where your DirSync configuration is
moved to a new server running Azure AD Connect.
If you use Azure AD Sync, then an in-place upgrade is recommended. If you want to, it is possible to install a new
Azure AD Connect server in parallel and do a swing migration from your Azure AD Sync server to Azure AD
Connect.
SOLUTION SCENARIO
Upgrade from DirSync If you have an existing DirSync server already running.
SOLUTION SCENARIO
Upgrade from Azure AD Sync If you are moving from Azure AD Sync.
If you want to see how to do an in-place upgrade from DirSync to Azure AD Connect, then see this Channel 9 video:
FAQ
Q: I have received an email notification from the Azure Team and/or a message from the Office 365
message center, but I am using Connect.
The notification was also sent to customers using Azure AD Connect with a build number 1.0.*.0 (using a pre-1.1
release). Microsoft recommends customers to stay current with Azure AD Connect releases. The automatic upgrade
feature introduced in 1.1 makes it easy to always have a recent version of Azure AD Connect installed.
Q: Will DirSync/Azure AD Sync stop working on April 13, 2017?
No. The date for when these products are no longer able to communicate with Azure AD will be announced at a
later date. You will be able to find that information in this topic when available.
Q: Which DirSync versions can I upgrade from?
It is supported to upgrade from any DirSync release currently being used.
Q: What about the Azure AD Connector for FIM/MIM?
The Azure AD Connector for FIM/MIM has not been announced as deprecated. It is at feature freeze; no new
functionality is added and it receives no bug fixes. Microsoft recommends customers using it to plan to move from
it to Azure AD Connect. It is strongly recommended to not start any new deployments using it. This Connector will
be announced deprecated in the future.

ADConnect

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ADConnect

Uploaded by

Copyright:

Available Formats

Table of Contents

Why use Azure AD Connect

Install Azure AD Connect

Express settings If you have a single forest AD then this is the

Download Azure AD Connect Download Azure AD Connect

Install using Express settings Express installation of Azure AD Connect

Install using Customized settings Custom installation of Azure AD Connect

Upgrade from DirSync Upgrade from Azure AD sync tool (DirSync)

After installation Verify the installation and assign licenses

Learn more about Install Azure AD Connect

Supported topologies Topologies for Azure AD Connect

Design concepts Azure AD Connect design concepts

Operational planning Azure AD Connect sync: Operational tasks and

User sign-in options Azure AD Connect User sign-in options

Configure sync features

Configure filtering Azure AD Connect sync: Configure filtering

Password synchronization Azure AD Connect sync: Implement password

Password writeback Getting started with password management

Device writeback Enabling device writeback in Azure AD Connect

Prevent accidental deletes Azure AD Connect sync: Prevent accidental deletes

Automatic upgrade Azure AD Connect: Automatic upgrade

Customize Azure AD Connect sync

All Azure AD Connect sync articles Azure AD Connect sync

Technical concepts Azure AD Connect sync: Technical Concepts

Declarative provisioning Azure AD Connect Sync: Understanding Declarative

Configure federation features

All AD FS articles Azure AD Connect and federation

Manage AD FS farm AD FS management and customizaton with Azure AD

More information and references

Version history Version history

Non-ADFS compatibility list for Azure AD Azure AD federation compatibility list

Attributes synchronized Attributes synchronized

Monitoring using Azure AD Connect Health Azure AD Connect Health

Frequently Asked Questions Azure AD Connect FAQ

Azure AD Connect sync topics

Azure AD Connect sync fundamentals

Understanding Declarative Provisioning Describes the configuration model called declarative

Features and scenarios

Scheduler Describes the built-in scheduler, which is importing,

Implement password synchronization Describes how password synchronization works, how to

Device writeback Describes how device writeback works in Azure AD Connect.

More information and references

Functions Reference Lists all functions available in declarative provisioning.

Sync engine identity objects

Sync engine identity management process

Source, The source object

CONTAINS, NOTCONTAINS A string compare that evaluates if value can be found

STARTSWITH, NOTSTARTSWITH A string compare that evaluates if value is in the beginning of

ISMEMBEROF, ISNOTMEMBEROF The value should contain a DN to a group in the connector

Language definitions and Identifiers

The complete list of functions can be found in the function reference.

PARAMETER NAME COMMENT

Domain.Netbios Netbios format of the domain currently being imported, for

Domain.FQDN FQDN format of the domain currently being imported, for

Domain.LDAP LDAP format of the domain currently being imported, for

Forest.Netbios Netbios format of the forest name currently being imported,

Forest.FQDN FQDN format of the forest name currently being imported,

Out-of-box rules from on-premises to Azure AD

ForeignSecurityPrincipal out-of-box rules

Understanding the out-of-box rules scenario

Azure AD Connect - federation topics

Azure AD Connect user sign-in options

AD FS installation using Azure AD Connect

Pre-requisites Pre-requisites for a successful AD FS installation via Azure AD