Entra Connect after a long time offline

Hi Matt_MobiusNZ​,

There's a good deal that remains unknown based on your description, so I'll stick to making some generally-relevant observations no matter your scenario:

• If by "reanimate" you mean reuse a server that's numerous years old and has not been running synchronisation cycles in all that time, don't. Build a new server with the current release of Entra Connect;
• Entra Connect can (and should, based on what you've outlined) be installed in "staging mode", which is analogous to your requested "simulation mode":
  
  Microsoft Entra Connect Sync: Operational tasks and considerations - Microsoft Entra ID | Microsoft Learn;
• It's important that you use the same anchor anchor in the new configuration as the old;
• For the firm that has broken away, if they truly no longer exist in Active Directory, and there's no inadvertent matching (most likely to occur through soft-matching), then you have nothing to worry about. Entra Connect isn't a mystic art, so don't panic.

Entra Connect has three "phases" of operation: importing, synchronising and exporting. Staging mode uses the first two, but critically, doesn't perform exports - where exporting is the process of writing data back out to Azure AD (or back into Active Directory for that matter, but you're focusing on the former).

So, once you have performed a staging mode installation, Entra Connect will perform a full import and then a full synchronisation against Active Directory and Azure AD, after which you can see the results from within the synchronisation administration console. Specifically, there's two main areas you can check via:

• Under the Connectors panel, right-click on the Azure AD connector and choose Connector space search, as shown below; or
• Under the Metaverse search panel, perform a criteria-based search, then inspect the relevant "connector" objects shown in the Connectors tab within each search results' Properties page.

Either approach will give you some graphical methods of inspecting the projected changes, while staging mode ensures those changes are not pushed out anywhere.

There's also a number of scripting-based approaches to creating a CSV of the projected changes, but that can be complicated. I'll simply stick to mentioning that it's an option.

Note: Please remember that if you go ahead with this approach and do eventually end up disabling staging mode (meaning exporting begins to operate), any joined accounts will become mastered from Active Directory, not Azure AD.

Lastly, there's a number of means for establishing a join, spanning hard- and soft-matching methods. I'm not going to go into those as you can readily look them up but what is worth mentioning is that if the on-premise Active Directory immutableId source attribute's value does not match the existing (if there is one) Azure AD immutableId value, then while the objects (user accounts, most likely) will be joined, updates will not flow from Active Directory out to Azure AD (or vice verse, from Azure AD to AD) until the immutableId value is the same on both sides. I know nothing about your environment and you may not run into this issue, but given the amount of time that's elapsed since AAD Connect was last leveraged, it's a very real possibility you will see this - and why I listed choosing the same anchor as an important planning consideration.

Connector space search

Metaverse search

Cheers,

Lain