MIM/FIM Full Sync of select objects only

As I detailed in my previous blog here, sometimes there is a need to perform a full synchronization of just a select set of objects in the MIM/FIM Synchronization Service. In my case, it was to all the Synchronization Rules which helped resolve my issue which required a selected Full Synchronization performed. For this customer’s FIM environment, I manually performed the Preview/Full Synchronization on 51 objects as I just needed it done. My colleague Darren Robinson suggested I look at scripting it using the ‘Lithnet PowerShell Module for FIM/MIM Synchronization Service’ located here. Up until this point, I hadn’t used this module in anger and I dearly wished I did as it would have saved plenty of time!

Ryan Newington has done a tremendous job with his modules released to the community to make our lives easier. He even enhanced the tool recently to make this particular task easier (note: make sure you grab the latest version, at least version v1.0.6351, as the script below will not work if you have an older version). The script I now regularly use on my customer’s large FIM environment after making changes to Synchronization Rules, where I mentioned in my previous blog we struggle for the opportunity to perform a Full Synchronization of the entire sync engine rule base, serves my purpose for Synchronization Rules, but you can easily modify the search criteria to perform a Full Synchronization of the objects you require. Here is the script and leave a comment if it has helped you.

FIM: An object with DN “CN=BLAH” already exists in management agent “BLAH MA”

If you treat the FIM Synchronization Service well and your configuration is good, it will reward you and the ‘magic’ will happen. At my customer site, the ‘magic’ stopped working and I was faced with an increasing number of synchronization errors being ‘An object with DN “CN=<blah>” already exists in management agent “<blah> MA” ‘. For users that were already provisioned correctly, the FIM Synchronization Service was attempting to re-provision a duplicate object in the destination directory but obviously the account already existed. Why was this occurring and how to resolve it? To be honest it stumped me for quite a while until I remembered I was faced with the same scenario a few years ago with yet another FIM Synchronization Service with many 100s of thousands of objects.

Before I start, I’ll preface that this blog assumes a very good working knowledge of the Microsoft Forefront Identity Manager product, now known as Microsoft Identity Manager. Let’s delve deeper.

We should all know that best practise when making changes to any part of the FIM Synchronization Service configuration, or new or updates to FIM Service Synchronization Rules, you should do a Full Synchronization cycle to ensure the changes and rules are all processed against the objects in the solution. When you are working on a large solution with 100s of thousands of objects, it is not always possible to do this Full Sync cycle at will and it needs to be typically scheduled as a change over a weekend, maybe even a long weekend! We had attempted a full synchronization cycle on this customer solution in the past and it took just on 2 days to complete. So when you don’t have the opportunity perform this cycle, you use your prior knowledge, expertise and judge if the solution can continue to function if a change has been made. In my case, a new attribute flow in a Synchronization Rule which was not critical to the existing objects in the solution. So I thought I could avoid a Full Sync cycle and everything appeared to be working as expected.

Over a few weeks, these sync errors started to occur as illustrated below and they were increasing until I got to around 40 errors and further troubleshooting action needed to be taken.

The customer had rules in the solution to detect when an existing user account was disabled and perform some functions in the FIM Service. If the user account was re-enabled, the ‘provisioning’ MPR was triggered as the user was back as a member in the ‘provision accounts’ Transition Set. Workflows assigned a handful of Synchronization Rules against the user as Expected Rule Entries (EREs), which had already applied to the user when it first came to existence and provisioned. These duplicate EREs when flowed from the FIM Service to the FIM Synchronization Service were throwing the errors.

Back in the test environment, the ‘magic’ was still working with no errors thrown. What normally happens in this situation is if you happen to assign a provisioning Sync Rule to a user account, but that user already had one previously successfully ‘applied’ (and was already provisioned), this duplicate ERE would be processed by the Sync Service and also marked as ‘Applied’. It was smart enough to know that the provisioning event was not required because an existing ERE had already been assigned. When the Sync Service flows the status of the duplicate ERE back to the FIM Service, the duplicate is deleted and world order is restored with this ‘magic’. Sorry I find no way of easily describing it without detailing my scenario, so I hope you are still following me. So why was it not working in production?

I’m not sure of the internal innards of the Sync Service, but what I have found is when a delta import change of a Synchronization Rule flows into the Sync Service and a ‘Delta Sync’ is processed on this change, it seems to have an adverse effect on the other Sync Rules. Sync Rules that have previously been working fine start behaving badly and to put it simply, the ‘magic’ breaks.

The fix is to obviously perform a Full Synchronization on the whole solution because a configuration item has changed. However, without having the easy opportunity to do this, I needed to perform a Preview/Full Synchronization on each Synchronization Rule in the solution as illustrated below. Although no obvious change is shown in the preview window, it seems like each Sync Rule is re-processed/reset into good working order and the ‘magic’ is restored.

After performing this change against all Sync Rule objects, all synchronization errors have been cleared and the ‘magic’ now works as expected. I didn’t find much in the forums or public domain about this scenario, so I hope this helps somebody in the future. I’m now working on getting the full synchronization cycle actioned! Let me know in the comments below if this has saved you.

Bulk create and update related configuration objects in FIM/MIM using the Lithnet Import-RMConfig cmdlet

Working on a FIM implementation for a customer, I needed to bulk create and update a number of related Sets and MPRs which granted permissions to users. I could have performed this task a number of ways:

  • Manually create and update all objects
  • Scripted in PowerShell using FIM Automation
  • Scripted using the Lithnet FIM/MIM Service PowerShell Module

I’ve been successfully using the Lithnet FIM/MIM Service PowerShell Module in a number of scripts to query and bulk create objects in the FIM Service which has greatly improved the quality and simplicity of my PowerShell scripts compared to using the FIM Automation module. What I hadn’t used to date was the ability in the Lithnet module to use the Configuration Management features within FIM, so I thought I’d set myself a challenge to come upto speed with this feature and determine if it was a quicker method than using FIM Automation. I knew it was going to be quicker using the Lithnet module but since I needed to do some research and testing compared to knowing how to tackle it using FIM Automation, I needed to be 100% convinced.

This blog assumes a very good working knowledge of the Microsoft Forefront Identity Manager product, now known as Microsoft Identity Manager. If you haven’t used the Lithnet module yet, what are you waiting for! Ryan Newington has developed and released to the community this PowerShell module which cuts the amount of scripting required to manage FIM configuration and objects within the FIM Service. Using the Configuration Management features was a perfect set of functions I needed for my scenario which I will now describe.

Scenario

For this customer, they had a delegated permissions model where each of their 13 agencies had administrators that were able to manage a fixed set of user attributes just for their own users. Users from other agencies were not visible within their view within the FIM Portal, and to support this model, each agency has linked FIM Set and MPR objects to give this delegated administration. My customer engagement was to update this existing FIM implementation to add custom telephone-based attributes against each user, and create a new phone object type. The existing permissions needed to be updated to include the new telephony attributes, and new permissions were required for the phone objects linked to each agency. This customer had 13 agencies and the beauty was the naming convention the FIM solution had for Sets and MPRs, with the names of the common objects being the same with only the agency name being different. For example, each agency administrator Set object was called ‘_Agency (<agency>) Administrators’. This was the same for MPRs, so my task was made easier as I just need to develop a templated XML configuration file which I could easily update per agency. Follow me so far?

What I liked about the Configuration Management feature was the ability to easily reference other objects without needing to separately query the FIM Service to return an ‘ObjectID’ which you can then supply to your configuration. The Lithnet module takes care of the referencing.

The Lithnet module is located here, and the quickest way to learn about this Configuration Management feature is to read the Lithnet documentation here, and as suggested watch the recording from FIM contributor Ike Ugochuku and download his sample XML configuration here which is a great starting point – here.

Required Actions

For my scenario, I needed to perform the following:

  • Create a Set object to group all phone objects for each agency
  • Create a permissions-granting MPR object giving each agency Modify permissions to one attribute for phone objects, a ‘visibility’ boolean attribute. You’ll notice in the XML configuration below, the Set created above is referenced, showing the power of this Lithnet module
  • Create a permissions-granting MPR object giving each agency Read permissions to all attributes for phone objects
  • Update an existing permissions-granted MPR object giving each agency Modify permissions to one attribute for user objects, against the ‘visibility’ attribute
  • Update an existing permissions-granted MPR object giving each agency Read permissions to the new phone related attributes for user objects
  • Update an existing permissions-granted MPR object removing the Modify permissions for user self-service which has been assigned in error some time ago

Using the -Preview switch against a configuration XML file (sample listed below) for the first agency, a preview can be tested before applying.

On a second agency with some of the updates already applied, I performed a preview. It shows all objects exist and which individual change would be applied.

As a test against the second agency, I changed resource operation from ‘Add Update’ to ‘Add’. When attempting the preview again, it showed it is creating the Sets even though they already exist. This is not ideal for verification, so I changed it back to ‘Add Update’ which I recommend using.

Removing ‘Preview’ and committing the change against the first agency shows what is changed and committed to FIM.

Validating the changes with a preview once applied to confirm all changes had been committed.

Although I could have been smarter to script the process for the remaining agencies, I did a search-and-replace of the agency name in the configuration XML file, saved it and re-ran the import.

Last step was to check the FIM Service requests to confirm they have been completed.

My sample XML configuration file for an agency change is located here.

Tips

Some simple recommended tips based on my use of this Configuration Management feature:

  • ID is a required tag even if you don’t use it as a reference within your XML configuration file
  • When creating FIM objects, use the XML tag ‘Add Update’ so that the Preview function can be used to validate the changes you have performed. If you leave it as ‘Add’, the Preview will simply report that the object ‘would’ be created if executed, rather than query and check that the objects exists and no update is required
  • Case sensitivity of the XML tags as mentioned by Ike in his video. I didn’t test changing the case as the sample XML configuration files were working configuration

So how long did it all take?

My goal was to make the changes into production against the 13 agencies after successfully testing the FIM configuration in a test environment. After watching Ike’s video and reading Ryan’s wiki, it took about 15 minutes to customise the sample XML files and update the configuration in the production FIM instance for all 13 agencies. A huge time saving. Other colleagues have started using this functionality both for speed of implementation and consistency in configuration, and my colleague Darren Robinson has also saved a great deal of effort as detailed in his blog here.

What scenarios have you performed with this functionality? Let us know in the comments below.

Azure AD Connect – Using AuthoritativeNull in a Sync Rule

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

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

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

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

  • userPrincipalName
  • proxyAddresses
  • mail

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

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

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

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

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

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

Set the cloned rule Precedence value to 104.

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

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

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

  • Start-ADSyncSyncCycle -PolicyType Initial

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

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

Active Directory – What are Linked Attributes?

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

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

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

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

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

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

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

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

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

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

Azure AD Connect – Multi-valued Directory Extensions

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

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

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

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

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

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

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

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

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

Azure AD Application SSO and Provisioning – Things to consider

I’ve had the opportunity to work on a couple of customer engagements recently integrating SaaS based cloud applications with Azure Active Directory, one being against a cloud-only Azure AD tenant and the other federated with on-premises Active Directory using ADFS. The Azure AD Application Gallery now has over 2,700 applications listed which provide a supported and easy process to integrate applications with Azure AD, although not every implementation is the same. Most of them have a prescribed tutorial on how to perform the integration (listed here), while some application vendors have their own guides.

This blog won’t describe what is Single Sign-On (SSO) or User Provisioning with Azure AD (which is detailed here), but rather to highlight some things to consider when you start planning your application integrations with Azure AD.

User provisioning into the application

Azure AD supports user provisioning and de-provisioning into some target SaaS applications based on changes made in Windows Server Active Directory and/or Azure AD. Organisations will generally either be managing user accounts in these SaaS applications manually, using scripts or some other automated method. Some notes about provisioning in Azure AD:

  • ‘Featured’ apps in the Azure AD Application Gallery support automatic provisioning and de-provisioning. A privileged service account with administrative permissions within the SaaS application is required to allow Azure AD the appropriate access
  • Some applications (i.e. like Lucidchart and Aha!) are able to perform the function of provisioning of new users on their own, which is managed directly by the application with no control from Azure AD. Some applications (i.e. like Lucidchart) will also automatically apply a license to the new user account, which makes the correct user assignment to the application important. Other applications (i.e. like Aha!) will automatically create the new accounts but not assign a license or provide access to any information. License assignment in this case would be a manual task by an administrator in the target SaaS application
  • All other applications that do not provide the capability for automatic provisioning require the user accounts to be present within the target application. User accounts will therefore need to be either manually created, scripted, or make use of another form of Identity Management. You need to ensure the method on how the application matches the user from Azure AD is known so that accurate matching can be performed. For example, the ‘UserPrincipleName’ value from the Azure AD user account matches the ‘NameID’ value within the application

Role mapping between Azure AD and the application

Access to applications can be assigned either directly against user accounts in Azure AD or by using groups. Using groups is recommended to ease administration with the simplest form using a single Security Group to allow users access to the application. Some applications like Splunk support the capability to assign user access based on roles which is performed using ‘Role Mapping’. This provides the capability to have a number of Security Groups represent different roles, and assigning users to these groups in Azure AD not only enables access to the application but also assigns the user’s role. Consider how you manage user memberships to these groups, how they are named so that they are easily identified for management, and how the application knows about the groups. Splunk for example requires groups to be created using the ‘Group Object Id’ of the Azure AD group and not it’s name, as shown in this example:

The Group Object Id for groups can be found by going to your Directory Page and then navigating to the group whose Object Id is to be retrieved.


User interface changes

Some applications have a modified interface when SSO is enabled, allowing users to select whether to login with userID/password credentials or a federated login. You need to consider end-user communications for any sudden changes to the application that users may face and let them know which option they should select. For example, the Aha! application changes from this:

to this when SSO is enabled:

Have a backout plan

In addition to the point above, some applications require an all-or-nothing approach when SSO is enabled. If you have not sufficiently planned and prepared, you may be locked out of the application as an administrator. If you have access to a test subscription of your application, test, test and test! If you only have your production subscription, I would suggest having an open dialog with the application support team in case you inadvertently lock yourself out of authenticating. For example, the New Relic application allows the SSO configuration to be made in advance which then requires only the account owner to enable it. Once enabled, all authentication is using SSO and you had better hoped the configuration is correct or else you’ll be asking support to backout the changes.

Applications such as ServiceNow have the ability to have multiple SSO providers where you can implement a phased approach for the enabling of SSO to users with the ultimate goal to make SSO authentication default. ServiceNow also has a ‘side door’ feature where you can by-pass external authentication and login with a local ServiceNow user (as detailed here).

Accessing applications

Users will be able to access applications configured for SSO with Azure AD using either of the following methods:

  • the Microsoft MyApps application panel (https://myapps.microsoft.com)
  • the Office 365 application launch portal
  • Service Provider Initiated Authentication, where authentication is initiated directly at the SaaS application

Most federated applications that support SAML 2.0 also support the ability for users to start at the application login page, and then be signed in through Azure AD either by automatic redirection or by clicking on a SSO link to sign in as shown in the Aha! images above. This is known as Service Provider Initiated Authentication, and most federated applications in the Azure AD Application Gallery support this capability. Some applications such as AWS do not support Service Provider Initiated Authentication and SSO does not work if users attempt to authenticate from the application’s login screen. The alternate methods to access the application via SSO need to be followed and communication for end-users to inform them on how to access these types of applications. For AWS, you can access the application using SSO from the MyApps application panel, with an alternate method by providing users with a ‘Single Sign-On URL’ which can be used as a direct, deep link to access the application (as detailed here).

Conclusion

Hopefully you can see that although it can seem quite simple to integrate an application with Azure AD, take the time to plan and test the integration of your applications.

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

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

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

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

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

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

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

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

The last two items will be detailed in future blogs.