homonyms management

[pkunzipper]

Good morning,
using your module I have several problems in managing homonyms in a source tenant that contains about 6 thousand users, to be synchronized as contacts in the destination tenant.

Specifically, EntraID gives the possibility of using the same display name for users who have the same name and surname, but who will have a different UPN and Mail. ExchangeOnline, on the other hand, does not allow the creation of contacts with the same DisplayName and therefore your module "sees" only one contact by removing or updating it without managing any homonyms.

eg, those are the user on my source tenant:

Mario Rossi - User - Administration - mario.rossi@mytenant.com - mrossi@mytenat.com
Mario Rossi - User - Operations - mario.rossi2@mytenant.com - mrossi2@mytenant.com

and should be created in thys way on my destination tenant:

Mario Rossi - Contact - mario.rossi@mytenant.com - mrossi@mytenat.com
Mario Rossi2 - Contact - mario.rossi2@mytenant.com - mrossi2@mytenant.com

I therefore propose my availability to collaborate together to implement this management as well.

kind regards.

[PrzemyslawKlys]

Interesting, will look into it, but you're giving very specific example and solution, where it may not be as straightforward

[PrzemyslawKlys]

@pkunzipper I opened PR #44 to address homonym collisions during org-contact creation.

What it changes:

• generates a unique internal Exchange Name for new contacts from the SMTP local-part
• adds -2, -3, etc. if that internal name is already taken
• keeps DisplayName unchanged, so it targets the creation conflict without renaming visible GAL entries by default

If you get a chance, could you let me know whether that would solve your scenario, or whether you also need the visible DisplayName itself to be made unique?

[PrzemyslawKlys]

Follow-up: PR #44 now covers both parts.

It already made the internal Exchange Name unique for homonyms, and I have now also added opt-in visible display-name deduplication via -EnsureUniqueDisplayName.
That means you can keep the first Mario Rossi as-is and have later duplicates become Mario Rossi2, Mario Rossi3, and so on when you want that behavior.

I also updated the README and Sync-O365Contact documentation so both the default internal-name fix and the optional visible-name behavior are documented.