[MUSIC PLAYING] Hi, I'm Becky Cross. Thank you for joining me today where I want to talk to you about five trends from Microsoft to help you out with some of your cross-tenant coexistence challenges.
First of all, we'll do a quick overview of what some of these common challenges are. They fall into three buckets normally. We've got collaboration, where your users in different environments want to meet together, be able to chat with each other, be able to share files with each other, and collaborate in live time on those same files.
We also have a lot of branding challenges with mergers and acquisitions, especially when two companies want to look like one. And how do you address that? How do you get your users so that they can all send out emails as the same domain when Microsoft doesn't let you have a domain in more than one tenant at a time? So that's a big challenge that we see out there with mergers and acquisitions.
Additionally, we've got consolidation challenges. This is what happens where maybe you've had coexistence for a long period of time and you're finally ready to actually make that final consolidation, make that final move. And that means moving your users, your groups, your devices, and of course, all of their content that goes along with that. This is a really big undertaking.
And so we're always looking for ways to try and automate how to address each of these challenges. You can see here that there are manual ways to do this. You can just create an extra user. Manually create a group and populate it with the right members.
That's OK for a one off situation. But most of the time, when you're running a business, you're not going to just have these one off situations. So what's the next logical step? Scripting. So you create a batch file. You create a PowerShell script. And you tell it to always look for brand new mailboxes in one environment. And as soon as it sees one, go ahead and create a contact in another environment. And now, you have a GAL sync.
You can set that to run daily, you can set it to run hourly, whatever works well for you. This is actually really good for handling some of those more basic situations, like a GAL sync.
But in reality, mergers and acquisitions are more than just a GAL sync. It's, again, that consolidation, that coexistence period. And they are so much more than just a contact object. This is where third party tools can come into play.
So there are some great tools out there that have entire portfolios that can handle your mail, your OneDrive, your Teams, your identities, your devices. So if you have all of that involved in your M&A, then you should probably look at what third party tools can, again, help to automate some of these activities so that you're not spending your entire day having to do it.
Of course, the drawback with a third party tool is it's not free. So we're always going to look for ways to maybe find something for free or maybe cheaper from Microsoft. So any time Microsoft can give us something that's native within their environment and not have to go outside to a third party tool where you add that extra little bit of complexity, that's a big win for us.
And historically, Microsoft has done a great job of this with on prem environments. AD to AD. You've got Forest Trust, you can just share things. It's pretty basic and it's just natural the way that you can share with each other and collaborate with each other. Same thing for on prem exchange. You could share domains between two completely separate on prem exchange environments.
So that's what we're looking for. Now that we all move out to our tenants, we want those same solutions out for cross-tenant collaboration. So that's what we're going to look at today is what is Microsoft starting to bring to the table to have some of the same functionality in tenant to tenant collaboration?
So I'm going to talk about five features. These are sometimes in preview, could be public, could be private preview still, could be GA. Some of these things go in and out of preview. So depending on when you watch this, this might be out into GA at this point, or it might have moved back into a private preview. It changes all the time. And I'll make sure to give you the roadmap ID so you can track some of these topics yourselves.
We're going to look at some collaboration items, which include the B2B Direct Connect and how it relates with the new Teams shared channels. We're going to look at two branding considerations. One is the Send From Email Alias functionality, and that's within a single tenant.
And then, we're also going to look at the biggest, most exciting offering, to me, which is Native Domain Sharing Across Tenants, which is in private preview, but it's supposed to go public in November. Now, it was supposed to go public back in July. That didn't happen. So again, these dates, they can always change. We'll see where they come.
And then, the last one is for consolidation. There is a service offering from Microsoft and it's called Active Directory Synchronization as a Service. So I'll just touch on it real quick here at the end. Make sure you they're aware of it and see if it can maybe help you out with some of your activities.
So let's start with collaboration. Today, what you're used to, if you have a Fabrikam user in one tenant and you want to grant them access to resources in the Contoso tenant, how do you address this? One common way is just give them their own separate account in Contoso. It's its own username, it's its own password. They don't have to have any relationship to each other. They don't even have to have the same type of username.
And if you do this, then the Contoso admins fully control that account. They can control the security, the permissions, how recently the password is going to expire, and the complexity. Or you can set up a Directory Sync to be able to sync those passwords, sync those attributes. So that's one option is just have a separate account.
And that was really common in AD to AD collaboration. As we are using more and more tenant resources, we're starting to see guest accounts much more frequently. And this is where we have our current B2B collaboration. So instead of creating a separate account in Contoso for our user, we're just going to give them a guest account in Contoso. It is linked to that Fabrikam account.
So when they authenticate, they're still authenticating against Fabrikam. And Fabrikam is controlling all of their password policies, their expiration, all of those settings. So that's what we're used to today.
What Microsoft has added into Preview is what's called B2B Direct Connect. So what this does is it gives us that cross forest trust kind of feel. That relationship directly between environments to say, I don't want to create another user. I don't want to have to create a guest account. I just have a resource in Contoso, and I just want to give access to that Fabrikam user directly, just like you do across a forest.
So the B2B Direct Connect is in preview, but right now, it's mostly being used for the Teams shared channels, which is actually GA right now. And so some of you might already be using those. But it's good to understand how these relate underneath the hood.
So what is a shared channel? With Teams, you're used to public channels and private channels. And now, we have a third type of channel called a shared channel. You don't necessarily even have to share it externally. You can still internally create a shared channel and just share it with other internal users in your environment.
But if you choose to, you can now also share with external users and external Teams in that other environment. And the way that it works is using this new B2B Direct Connect technology.
So let's take a look at what it takes to actually configure all of these shared channels and be able to utilize them because you probably don't want to use them with every other tenant in the world. You probably want a little bit of control over the security, who can get into your tenant, and which other tenants your users can access.
So the first thing you'll want to look at are your cross-tenant access settings. So the default policy for the B2B Direct Connect is blocked. So what you're saying there is, I don't want my users sharing any channels, and even if they do, I'm not allowing any outbound users to come in and access those.
There's also the block outbound. So even if an external person tries to add one of my users to a shared channel, I don't want them accessing it. I want full control over everything that my users are touching and who is touching my tenant resources.
So that's your default policy. Block it all. Now, on the flip side, you could have an open policy and say, yep, if someone shares with my users, let them at it. And if my users want to share their channels, I will let anyone come in as long as their tenant also allows their users to go out and come into my tenant. So there is that open all any any.
But probably, what you're going to want to use are the per tenant policies. So if you only want to work with Contoso, even for a small group. Maybe you're just working on a single project that's only going to last maybe six months, you could create a per tenant policy just for Contoso. And you can actually scope it down to just specific users and groups in either direction and still have your default policy that says, block everything else. Block all the outbound. Block all the inbound except for what I put in this one tenant policy.
There are some additional services that are required for some of the configuration if you really want to control by user or group who can come in. It does require a premium Azure subscription. So just remember to take a look at that if that's something that you think you might want to do.
When you configure that inbound access, you also have a few other options. You can choose to trust other tenants claims. So if you require your users to have MFA, you can decide, do I trust the MFA check that Contoso did in their environment? These are all just basic checks. As you set up these policies, look at what your options are and figure out what works best for your environment.
You will also be in the Teams Admin Center configuring policies there, including determining which of your users are allowed to create shared channels, and who can actually share with those external users once they're created, and which of your users you want to allow to participate in other tenant's shared channels. So pop into your Teams Admin Center and just take a look at those settings.
So you've set it all up. You've said, I want to allow access between myself and Contoso. I've determined which users are allowed to do this. So what does this look like? How does it work?
First, your user is going to create that shared channel. So they create it and they can choose, who do I want to share with? I can share with an individual, internal or external. I can also share with a team. And this is really cool, again, internal or external. Because now, if I'm going to work with this marketing team in a completely different environment, I don't want them to have to email me every time they add a new member to their team. And then, I have to grant access to my shared channel to that brand new person, or I have to remove someone.
Instead, if I invite that team as a member, as that team membership changes in that other environment, those same people automatically gain and lose access to that shared channel that I gave them access to. So it's really handy for that management style.
You can choose whether to share with the parent team. You don't have to. Again, just a checkbox, it's up to you. And when you go to manage the shared channel, once you've added all of these members, you can elevate your internal people to be owners. You cannot elevate external people to be channel owners. So just keep that in mind.
And remember that the shared channel is part of an overall team. And so the owner of the overall team does still have control to delete that shared channel, if they so choose. So make sure you let them know that you created it.
Now, from an end user perspective, they've had a channel shared with them. What does that look like? They'll get notified. And when they go to access it, it's going to show up directly in their team's client. So instead of what they're used to where they have to go up, switch organization, now they lost sight of their current chats and their current Teams and channels in their environment just to go see yours, that doesn't happen anymore.
Now, they're still working in their Teams client, and they just see that brand new shared channel along with all of their other channels. So they click on it and the very first time they access it, it will ask them to grant consent. The consent is just consent to display their name, their picture, their contact information, all the basics that you're used to seeing for your Team members.
That's only on the first time. And now that they've granted consent, again, it just shows that right in their client. And it'll have a little icon next to it so they can easily identify that it is not an internal channel, it's actually an external channel from another tenant.
So is this something that you think will work for you? Like I said, the biggest benefit is really for the end user, I think, to keep them from having to switch organizations in their Teams. It can cause some ease with. Management it can also cause some complexities with management. So I think those will all balance out.
It's really just going to depend on your needs within your organization and who you need to collaborate with. There is definitely still a need for guest accounts. This B2B direct access does not remove that need. You'll still have guest users from maybe a Google environment. Direct Connect doesn't work for that, right? It's only for Azure to Azure. So you still have that need.
And also, this Direct Connect is just for those Teams shared channels right now. So you probably still have guest users to get access to SharePoint resources and other things in your environment that don't yet support this Direct Connect. So you'll figure out, where does a guest account make the most sense, ad where does the Direct Connect direct access make the most sense for you.
The other thing is when it comes to your migrations. Let's say you start sharing channels. You're collaborating with this other tenant. And then, you decide that you actually want to fully consolidate into that tenant. Well, how do you match those members? Right now, we're used to a one to one match. A source account matches a target account.
Well, in this case, we didn't actually create a separate account. We just gave that direct access. So it's going to be really important to know when you come up to a T2T migration whether or not you have shared channels and who those external member to make sure you can account for them during your migration.
There might be some manual effort involved. Hopefully, any migration tools that are out there are going to be looking at this closely and building in ways to help automate that membership transfer once you start using your Team shared channels. And of course, if you have those, make sure you notify those external users because they might lose their access, especially if you move that team to a new tenant that does not have that open policy with Contoso like your tenant did. Then even if you try and add them as a member, they won't be able to get in.
So let's switch gears just a little bit. We're going to talk about branding. And when we say branding, we're not talking about updating logos on your website and your marketing materials. We're talking about your email address. What is your identity when you send out to the outside world?
We'll start internal, within a single tenant. Let's say you've gotten fabrikamglobal.com as part of an old acquisition, or you're starting to segment your departments a little bit more within your tenant. So you are giving your users brand new aliases.
They now have their Fabrikam alias, but they also have this Fabrikam global alias. And as you probably know, you can set up as many aliases as you want on a mailbox. But when these users send out to the outside world, it's always going to look like it came from whatever you have set as their primary SMTP address.
So that's what we're used to today. We know that that's the case. They can still receive mail sent to any of those aliases, but they're always going to look like that primary SMTP when they send out. And if they do want to look like something else, you can create a separate mailbox, like this feedback mailbox here, and give them send as rights to it.
And now, they can send us that mailbox and look like that other account and have that separate display name. But that's not really the easiest process. It doesn't make the most sense if it's really just a single user who needs to have multiple aliases that they would like to send from.
So what is Microsoft introducing? Send from Alias. So Send from Alias, once you turn this on in your tenant, your users get to choose from their given aliases who they want to look like when they send out. So they could look like Fabrikam or they could look like Fabrikam Global. They might need to send to some people as one type and other people as another type. It's up to them.
Of course, they can still receive messages to those same aliases. And what's really great is you can organize your inbox replies to say, you know what, if someone's replying to a message at Fabrikam Global, mark it as important, mark it to follow-up, file it in a certain folder. And if they send it to Fabrikam, just put it in my inbox.
So this Send from Alias is going to be really nice. We did have similar functionality on prem. There are some other mail environments that already allow this. And so it's great that Microsoft is finally bringing this in to Exchange Online.
Now, features and limitations. Some of the cool features, previous used aliases are displayed. So just like when your users send a new message and they get that little recipient list of here's who you've emailed recently and they don't have to try and remember their email address. Same thing will be true for these Send from Aliases. It'll show them which ones they've used recently so they can just easily select them.
They can also control which ones they want to send from. Which ones do they want to see in that list? If they have 20 aliases on their mailbox, maybe they only want to send from two. Instead of having to scroll through that huge list every time, they can choose and say, only show me these two or only show me these three. Don't show me the rest because that's just clutter.
As I mentioned, inbox rules can be very handy. And this is disabled by default. But it's really easy to turn on with a basic PowerShell command. Some limitations. This is currently GA for Outlook Web Access and for mobile devices.
It is currently in public preview for Outlook for Windows. It was GA at one point. It went back into public preview. Probably by the time you watch this, it'll be back in GA again. We'll see. We'll see where they land. However, Outlook for Mac is not yet supported. So I think that one is down the road just a little bit, but I imagine that they will get that out there.
As I mentioned, display name. If you want a different display name, you have to have a different mailbox. It does not change based on your email address that you send from. So that's just something to keep in mind when you determine is this something that will work for you.
And the other thing to keep in mind is that if your users are sending to, maybe, applications, or if you have some journaling solutions set up and those are expecting the Send from email alias to be a certain type. If it's expecting fabrikam.com and it comes from fabrikamglobal.com, it might not work. It might not journal the way you expected.
The application might not accept that incoming message because they'll say, I don't have an entry in my application for Fabrikam Global. Please try again. So just keep those kinds of limitations in mind if you start deploying this out to your users.
Now, what about cross-tenant? So now, we're going to split back into two environments. I now have a Fabrikam user in my Fabrikam tenant, but they want to look like contoso.com. That's not in my tenant. And it's over in the Contoso and Microsoft says, that's the only place it can be. You cannot put that email domain in two places at once.
This is where an email rewrite service comes into play. So there are many third party tools out there that can provide this functionality. There are some great papers out there that go into detail on how to really get it set up. But at a high level, you're going to have an account in each tenant. You're going to perform a matching on those accounts, whether it's with a spreadsheet or dynamically within the tool.
Then within that email rewrite service tool, you will choose which of those users should have this email rewrite enabled. And once you do that, then when they send emails out to the outside world, those get intercepted by this service and it just modifies the message. And it says, just kidding, this actually came from Contoso and you didn't know any different. And then, that person can reply to that message from Contoso and it will make its way back into that Fabrikam user's mailbox.
So it's really handy. It's really slick. But it is still spoofing. This is a third party. It's not native. And so you have to control those spoofing controls with your SPF records and your DKIM entires to try and make sure that this isn't going to land in junk email and quarantine because that's not a good user experience.
Also this is only going to rewrite when it's going outbound. So this Fabrikam user sends to an internal person and an external person. Well, now he looks like someone different to each recipient. So that's not a good user experience, either.
So this is where we've been looking for something native. This is, can I just please use contoso.com in Fabrikam if they give me permission? Well, yes, let's do that. So we had this in exchange on prem. We are finally getting it an exchange online. So this is huge.
It has been in private preview very under lock and key. Not many people have had a chance to test it. So there's not a lot of information out there. And as they bring it live, which is currently slated for November of this year, we'll see. When they bring it live, it'll probably have even more features. I'm very excited to see it.
But at a high level, what is this native domain sharing? What it is is the Contoso tenant says Fabrikam, you can use contoso.com. They can pick and choose any domains to let Fabrikam use. And so then, now, when Fabrikam creates a mailbox, they can just assign email@example.com. Congratulations. That's your email address.
So now when that user sends emails out to the world, no third party relay service needed. They are truly sending as contoso.com. If they send to an internal person or an external person, they look exactly the same. So this is great. It's much more natural mail flow when you have this native domain sharing.
So a configuration, again, at a very high level, is one tenant will be the true owner of that domain. So in our case, Contoso's tenant is the owner of contoso.com. It's added as an accepted domain, just like we're used to today. But then they say, I'm going to allow domain sharing for this domain with Fabrikam.
So now, Fabrikam tenant also adds it as an accepted domain, but it's an internal relay. So you'll see that's that little difference between how these accepted domains show up for who's the true owner of that domain.
And then, we've got these inbound connectors. And that is where you can help determine which of the domains are you sharing externally with other tenants and with which tenants. So that's the configuration at a glance.
Features and limitations. Like I said, since it's been in private preview, there's not a lot out there that you can see. But it's an obvious one that no third party tools. If this comes out free, that would be great. Maybe Microsoft will charge, maybe they won't. Very excited to see.
But still, even if it costs money, it's native. You don't have to do that extra SPF records and DKIM entries to control all of that spoofing. It'll just be natively set as a primary SMTP.
There will be ways to get reports of, am I sharing this domain with any users? Who is using them and in which tenants? So there will be PowerShell commands so you can capture those reports and do some analysis, especially if you're planning for migrations. You need to know what's out there.
Limitations. There are some out there. They're going to change over time. They announced some last week. They've announced some a few months ago. So I'm not going to go in deeply, but the biggest one I do want to call out is that the UPN is still going to be Fabrikam. You cannot do domain sharing for a user principle name. So you still will have a unique identity. It's just for your primary SMTP address. So keep that in mind.
And also think about if this is best for your scenario. It is great for two tenants who just want to coexist forever. Maybe you have no migration or consolidation plans at all. You just want to be able to share this domain and look like the same email domain across multiple tenants. That is going to be perfect for this.
And it's supposed to be able to work fairly seamlessly with the native mail migration that Microsoft also recently is bringing from public preview to GA. They will integrate and be able to move those email addresses automatically as part of that.
Whereas, if you're using a third party tool for your email migrations, those are mailbox copies. And you cannot have a mailbox in each tenant with the same primary SMTP. It's just not allowed. And so it can add some complications to your T2T migrations, where now you do your mail migration, now you have to change some email addresses on one side and then change them on the other side. So it just adds some extra tasks.
Hopefully, third party migration tools that do mailbox copies like this will be able to add some automation in there so that you aren't having to run a bunch of scripts to flip those addresses as part of your move.
Also for domain moves, it's going to be really important, like I said, to know what objects are using this domain because it will no longer just be your internal users. And so there could be others affected by this. So those will be some things to consider. And there are some blogs out there that you can read as a deep dive to get a little bit more info on this feature.
And the last topic that I wanted to talk about real quick is consolidation. You may or may not know that Microsoft has an AD Synchronization as a service offering. When you're doing a consolidation, or even just a long term coexistence and you're looking for a DirSync product, originally, we had MIM. And then, they started adding graph connectors because, of course, more and more people are having Azure AD as one of the options where they need to sync to or from.
But that was getting kind of outdated. And so what Microsoft came out with is this new AD Sync as a service. And it can sync between AD and Azure and mix and match between them. You only pay for what you use. So if you're only syncing 50 objects, that's all it costs, which is great.
And if you decide to do a migration later, you can upgrade that service to their ADMS service. Since it is a managed service offering, you just tell Microsoft what you want them to do. They get it configured, they test it with you, you make sure it's working in the way that you want, and then they run it. It is a hosted offering from them. And so set it and forget it.
However, it's not free. It is a service and it does require Microsoft Enterprise Services. So keep that in mind if you're considering it. And also, because they are the ones managing it, if you have a lot of complexity or things are constantly changing or you're always wanting to add additional environments with your DirSync, you might be better suited still to a different DirSync tool that you might be using today that you control and that you can change on the fly, change the scope, disable it, enable it whenever you want.
But just remember that this service is out there. So when you're taking a look at what's going to work best for you, just include it in your checklist, compare the cost, compare the features. Maybe it works for you. Maybe you can use a different tool.
So as I mentioned before, a lot of these have been going in and out of preview. So I did list here the Microsoft roadmap IDs for each of these. So you can go out and find the status at any time because, again, these are going to change. This is what they are today.
So take a look. And hopefully, you found something in here that is new and exciting for you that you want to go and test and get your hands on. And so stick around. If you have any questions, I would love to answer them in our live Q&A that's coming up next.