Forum Discussion
Entra OU sync vs group filtering
Hi, Eric.
There's no categorically right or wrong answer here, but since you've mentioned "testing", I'd recommend using the group filtering option.
You mentioned that AAD Connect is not destructive, and to some extent that is true. But it has to be noted that if through normal Active Directory administration, you scope someone out of synchronisation, they do get soft-deleted by AAD Connect, and under default conditions, that means they will be permanently deleted 30 days after the soft delete.
Once you're ready to exit your test phase, you can readily re-run the configuration wizard (or PowerShell, if you're comfortable with the command line) to no longer use group filtering.
Just make sure you're matching of the on-premise identities to the existing Azure AD identities is solid, or you might face some interesting outcomes if they end up mismatching. This is where group filtering can pay off, since it's harder to "accidentally" scope too many people in or out of synchronisation, and high importance identities - such as executives - can remain confidently immune from such accidents while you're testing.
There's nothing complicated about selecting the organisational units. Just select the ones (a tick will be displayed in their checkbox) you wish to make eligible for synchronisation in the tree. Any that you do not select - or later deselect - will not feature in the synchronisation (where deselection post synchronisation leads back to what I mentioned above about falling out of scope, soft- and permanent deletion).
Cheers,
Lain
Hi, Eric.
There's no categorically right or wrong answer here, but since you've mentioned "testing", I'd recommend using the group filtering option.
You mentioned that AAD Connect is not destructive, and to some extent that is true. But it has to be noted that if through normal Active Directory administration, you scope someone out of synchronisation, they do get soft-deleted by AAD Connect, and under default conditions, that means they will be permanently deleted 30 days after the soft delete.
Once you're ready to exit your test phase, you can readily re-run the configuration wizard (or PowerShell, if you're comfortable with the command line) to no longer use group filtering.
Just make sure you're matching of the on-premise identities to the existing Azure AD identities is solid, or you might face some interesting outcomes if they end up mismatching. This is where group filtering can pay off, since it's harder to "accidentally" scope too many people in or out of synchronisation, and high importance identities - such as executives - can remain confidently immune from such accidents while you're testing.
There's nothing complicated about selecting the organisational units. Just select the ones (a tick will be displayed in their checkbox) you wish to make eligible for synchronisation in the tree. Any that you do not select - or later deselect - will not feature in the synchronisation (where deselection post synchronisation leads back to what I mentioned above about falling out of scope, soft- and permanent deletion).
Cheers,
Lain
LainRobertson What are your thoughts on gradually synchronizing users to Entra ID by adding one OU at a time, for example: Sales OU today, Finance tomorrow? When returning to Entra Connect Sync, will the previously selected OUs remain visible, or does the process starts again from the beginning?
Once you exit your testing phase, the approach you've outlined is as fine as any - again, there's no right or wrong here, just what's suitable to you and your organisation.
Organisational units don't disappear from the selection tree in the configuration wizard. You can check and uncheck them as you see fit, though as I mentioned before, if you start with an organisational unit selected, then de-select it later on, the objects (user, computer and group objects) will fall out of scope, causing those objects to be soft-deleted and then permanently deleted (as mentioned earlier). So, you want to carefully plan around de-selecting organisational units.
But adding additional organisational units (i.e. putting a tick next to them) has no such issues and is quite safe - so long as your AD-to-Azure AD matching is robust.
If you happen to de-select an organisational unit, so long as you re-select it within the soft-delete period (30 days by default), everything will match up again and the soft-deleted objects (technically, this is just the user objects as computer and group objects synchronised from on-premise do not go through the soft deletion phase) will become visible once again.
If you start off using group filtering while testing and then proceed to remove group filtering, then as long as the objects contained within the filtering group remain in scope (i.e. are positioned in an organisational unit that is included for synchronisation), then they will not change at all.
Conversely, if you do not include the organisational unit(s) that contained the group members, then when you switch off group filtering, the members contained in organisational units not selected will fall out of scope and they will be soft-deleted from Azure (for users, that is; computers and groups will be permanently deleted).
Cheers,
Lain
- Thank you, Lain, for sharing your knowledge!
Generally, I would test each scenario, but I was concerned that synchronizing just one test OU during the initial configuration might result in the loss of all my existing Entra users, leaving only those assigned the test OU 🙂While explaining the repercussions of transitioning between in-scope and out-of-scope, I forgot to finish off with a statement about existing Azure AD users that are not matched to an on-premise account by AAD Connect.
The simple answer is that any existing Azure AD accounts that are not matched to an on-premise account will remain unchanged - they are not impacted by AAD Connect at all.
The only time you will have an impact is if AAD Connect joins an on-premise account to an Azure AD account at any stage.
Cheers,
Lain