@Blacksuit
This is one messy setup with some real hurdles, but here's some thoughts on the specific mail problem you've outlined.
First, some assumptions I've made from what you've written (in case I've misinterpreted anything):
Company A
- Has existing on-premise Active Directory
- Has existing on-premise Exchange (not hybrid)
- Does not have an Azure tenant (meaning no AAD Connect)
Company B
- Azure AD-native (meaning no on-premise Active Directory and therefore no AAD Connect)
- Exchange Online native
On-premise Active Directory
This is the one that doesn't make a lot of sense given your statement about the legal separation requirements.
The recommended solution in such a scenario is to have separate forests for each company with either a one- or two-way trust between them (I can't recommend one over the other as there's not enough information in the question to really say.)
The only real purpose I can see for "importing" (it's really re-creating if things are truly separate) Company B's users into Company A's Active Directory is to allow them to log onto computers joined to Company A's on-premise Active Directory. If there's more specific requirements, it might pay to share them as being left to assume creates significant margin for error.
What two separate forests provides is roughly the recommended amount of administrative separation between the companies (though sharing computers clearly undermines this, as does the trust configuration between forests, but it would seem you'd have to accept these limitations) while allowing staff from Company B to log onto and use Company A's client machines.
You also get implicit e-mail domain name separation since the forests and domains will (unless someone makes a mistake) have separate namespaces.
The one issue that's going to hit users whether you take this model or an alternative (such as living in the same forest but adding Company B's namespace as an additional UPN suffix - which I'm not going to speak to here at this stage as that's an even worse model than what I've just put forward) is that they will have two passwords to manage: one for their on-premise forest and the second for Office 365/Azure - and this is probably their main one from what you've described.
There's a lot more that could be fleshed out for just this Active Directory requirement but doing so requires further assumptions and trying to cover all the options available just isn't feasible.
On-premise Exchange versus Exchange Online only
If the assumptions about neither company being hybrid are correct, then really, the two mail environments shouldn't be mixing at all, meaning there are no routing issues or mail domain namespace conflicts to deal with.
From a Company B user experience perspective, they just start Outlook and connect to Exchange Online. Because you don't have single sign-on in this scenario, they'll be asked for their password but that's expected as part of this backwards-facing model. You'd likely also have some DNS work to do to deliver Outlook autoconfiguration but this isn't hard as it's just duplicating the existing external records with the same names and values (though it does incur an additional administration area and potential point of failure.)
With in both Exchange environments for Company A and Company B, nothing should exist for the opposing company. So, no accepted domains, no connectors - nothing. It's a straight Internet routing scenario.
Other stuff
For example things like file servers, printers (only if they require securing via ACL's) and what not.
If this stuff is also to be shared, you might even want to go one step further and create a third forest to act as a resource forest. But I've already said a lot based purely on assumptions and I don't want to spend more time fleshing this one out other than to say it's one way you can better promote legal separation requirements.
Exceptions
I've had to make a number of assumptions in order to be able to say anything at all but you do give away some suggestions that you have set up some kind of infrastructure cohabitation rather than the recommended administrative separation from above.
If you can provide further clarity around the assumptions above, that will help a lot. For example, if you have already done some importing of Company B's users into Company A's Active Directory forest (not a good approach but it sounds like this may have happened already) then that points us back in the direction of adding additional routable UPN suffixes - which I alluded to earlier.
Even in this scenario, this doesn't require the cohabitation of on-premise Exchange. And if Company B is indeed Azure-native then you don't want to make things more complicated by trying to set them up as hybrid Exchange anyway.
That said, if you are looking to allow Company B's users to make use of Company A's on-premise Exchange environment then this gets a great deal more complicated and impacts both companies.
My advice purely based on the legal separation comment is keep everything separate as described above. Doing this means you have no reason to script anything to do with contacts or mail-related attributes. But again, this is also based on the assumption that neither company is hybrid already.
Once you start sharing mail environments and forests/domains, you really aren't delivering against legal separation at all.
Summary
You can achieve office cohabitation where Company A owns everything and Company B just comes in to log onto Company's computers.
This does not and should not result in Company B's users being created in Company A's domain (or even forest, ideally). By virtue of this, you should not need to be scripting anything at all to do with e-mail attributes. This is only necessary if you have folded Company B's users into Company A's Active Directory and Exchange environments.
If this is what's been done then you would need to explore adding a new Active Directory routable UPN suffix for Company B into Company A's forest. Even in this scenario, the mail environments should remain entirely separate and Company B's on-premise Active Directory accounts should not be Mailbox- or MailUser-Enabled at all. Keep things entirely separate and let Internet routing do its thing.
If Company B's users have been folded into Company A's Exchange (on-premise) then this isn't a good end result and I'm leaving that in the "too hard" basket for now.
Cheers,
Lain
