Forum Discussion
Entra OU sync vs group filtering
Hello,
Currently, we are utilising Microsoft 365 Business Standard with a free Entra ID, but we also have a trial version of M365 Business Premium that I would like to test for a couple of users and computers running Microsoft Windows.
For testing purposes, I would like to synchronise those users and devices from on-premise Active Directory to the Entra ID using Entra Connect Sync. I am contemplating which option I should choose:
The users (and devices) I want to synchronize are located in a specific Organizational Unit (OU) in Active Directory, but the users also have accounts in Entra ID and mailboxes in Exchange Online.
I know that Entra Connect Sync is not destructive, but I am unsure whether to choose "Sync all domains and OUs" during installation and then use filtering to select the security group to which the test users (and devices) belong or would it be better to directly choose only the specific OU containing the users and skip filtering? In the future, I plan to synchronize all users.
An additional question: if I choose only one OU, will it not clear the others, existing Entra ID users who are not members of the on-premise OU?
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
9 Replies
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
