Apr 05 2022 08:41 PM
Apr 05 2022 08:41 PM
I am setting up a co-lo for 2 companies in 1 office space. These companies are sister companies but infrastructure has been separated for legal reasons but we are converting into a hybrid office environment where Company A works 2 days at the office, then Company B comes in 2 other days to work in the office.
Company B network will be the primary on-site and Company A will be cloud-based. I want to import users from Company A into Company B but instead of having Company B's email addresses I want to call out their email address so any emails will route to their Exchange Server. However, I am running into issues doing this....
If I set their email address as Email address removed in any of the following attributes email address, ProxyAddress, or mail it fails to route the email to their Exchange server. I ran a message trace on Company A and Company B to track down the email but it does not show on Company A's message trace. On Company B, the message trace says it was delivered. What I found was that Company B's domain assumes it is an internal route even though that domain normaclature does not exist.
How can I call out the companyb\user email as Email address removed? There has to be a way to make this possible. I have a script setup to email users when their passwords are about to expire or MFA passcodes, etc. that creating a mail contact will not be the answer...
Apr 07 2022 04:59 AM
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):
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.
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.
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.
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.
Apr 14 2022 07:33 PM
My apologies for the delayed response, been hectic at work with our consolidation. Let me help give more insight as to the current setup.
Existing On-Prem AD
O365, no Exchange On-Prem
O365, no Exchange On-Prem
no On-Prem AD, all in Azure
I have a two-trust between both companies. We have Company B's users imported in Company A's AD to be able to login and reduce IT Overhead given they are both small companies. I have moved Company B's workstations into Company A's AD but not their servers in the cloud.
I have setup a site to site VPN between both domains so users in Company B can still access their cloud resources. I do not want to add UPN suffix into the current AD environment as this will cause more headaches than what I care to have given this is a 1 man IT show. Besides if that was the case I would have to migrate SPO, O365, etc. which is a hard stop for me.
The main purpose of wanting to add Company B's email address to the users account on Company A domain is to route emails for self service passwords and alike.
Let me know if you need anything further clarified. I know it's a cluster but doing the best with what I got.
Apr 14 2022 08:48 PM
This is a really complex scenario. Not so much from the technical side but more because of the restrictions imposed by legal separation.
At a very high level:
I would not have moved Company B's workstations into Company A's forest - unless Company A's employees are going to log onto Company B's workstations.
Again, I'm reducing a complex requirement into some very basic bullet points but keeping them separate given they are legally separate entities is actually pretty important until such time as they merge and are the one legal identity.
Here's some Microsoft literature on the options.
Apr 15 2022 03:34 PM
Apr 15 2022 06:02 PM
I think you've misunderstood how UPN suffix routing works in Active Directory, and it's relationship to Exchange.
Also, knowing that Company A is also on Exchange Online and not Exchange Server (which is on-premise) helps.
I'm going to make what I expect is a safe assumption here: Company A is likely running AAD Connect for synchronising objects from on-premise Active Directory to Azure AD.
So, while my preferred option your scenario would be the Azure AD Domain Services model from above, you can "shoe horn" in other less desirable solutions. The thing is, these other options clearly run against the principles of legal separation, but I've mentioned that enough already and won't bang on about it again here.
What I would do - in line with what I suggested initially when I was guessing what the two company's looked like - is that you add Company B's domain name into Company A's forest as an additional UPN suffix.
What this does
The userPrincipalName can end with the new suffix, for example Email address removed.
What this does not do
This does not impact the server-side configuration of mail in any way, shape or form.
What you need to do with AAD Connect
Filter or scope out any accounts aligned to "@companyb.com" so that it ignores them entirely. You can do scoping using the AAD Connect configuration wizard easily enough. Filtering involves some more steps but offers more control over what it synchronised.
This gives you the easiest configuration to manage because you are not integrating Company B into Company A from a mail perspective at all.
The biggest downside to this approach you've taken with putting Company B's users into Company A's forest is that their passwords will not be in sync with their password from Azure/Office. The Azure AD DS trust model avoids this.
The Microsoft links from above explain more advanced models, such as the single on-prem forest to multiple Azure AD tenant model, but I'll leave it to you to read those links as there's a lot of cause-and-effect considerations for you to plan around.