M365 Administration for Complex Environments

Can I do everything with one Microsoft tenant versus multiple tenants? It seems like it's been a battle for complex enterprises across the globe.

This is a challenging space because this gets at the heart of where a company is when you start talking about employees' files and their email and their storage and their collaboration.

And the folks who've been using multiple tenants to manage their different brands or their different regions. You'll be fascinated to see how many start to see if they can go to that utopia of a single tenant at the same time. 

Don't you wish it was easy to segment your tenants to delegate permissions to a group? 

A lot of companies feel like man if all the keys are in there, what about that from a cybersecurity perspective? Are we putting all of our eggs in one basket? 

This is a conversation that you need to have with consultants about your situation. But today we will put together some hypothetical situations of what people are trying to do, even this idea of slicing and dicing your tenant.

Multi-Tenant Versus Single Tenant and The Complexities

One was a multi-environment where there was a main tenant for the organization. And then the other two acquisition brands had their own tenants as well. 

And we added everybody in those other tenants as contact objects in Exchange as our workaround.

So it was a lot of guests. 

But we also ran into conflicts. 

1. Created a picker problem since the employees were added as contact objects in Exchange
2. Add guests to multiple tenants to help with collaboration
   

For these multi-tenant challenges, Microsoft does recommend a regional approach. And you can imagine especially with something like what they do with the cloud, where they've got multiple data centers that have residency requirements. You could have your tenant in Germany or in the UK and/or your America's tenant.

This does provide some advantages from a 

• OneDrive perspective where data residency is an issue 
• Azure where you can actually use one set of credentials across multiple tenants

And one thing I wanted to point out here is when we talk about the Microsoft 365 subscription, there's that aspect of managing devices, services, users, and groups, and that challenge of multiple administrators. 

One of the things I would caution people about is having way too many global administrators. Because once somebody's global admin, they've got access to everything.

Even Microsoft recommends no more than two to four global admins at most, for any size tenant or organization. 

This is more than just users and groups - there's the SharePoint environment, the Team's environment, Exchange environment.

What happens if a global admin leaves? 

From an exposure perspective, two different tenants are two different tenants. So if they hack one, it doesn't necessarily mean they get access to the other one based on how, how things are set up there when you're administering it, there are separate audit logs across the tenant.

But there are different kinds of security and operational challenges. 

It takes a lot of features to be able to get parody across multiple. There are multiple graphs on two environments and if your graph experience isn't good. That whole experience isn't good. Anything in that environment then there's the whole duplication and configuration.

Now you've got two different tenant configurations. How do you get consistency across the configuration? The applications that are being run there, the tenant-wide setting, and various duplications of what's happening in the services. That being said, it's also twice as much quota.

Now we're gonna have to create accounts for everybody in these different tenants. And while there is some aspect of Azure AD from an account perspective, it's still different environments and different settings and different policies and consistency are super tough. And so there are a lot of change management challenges that we have to deal with.

Microsoft 365 Administration Units

Here are some of the aspects of when administrative units came out and the perspectives.

Before administrative units, you had to go to a third party like CoreView to be able to do that.

And I like that idea of the custom scope, that idea that I may have some frontline workers and the frontline workers may be managed by somebody at the plant where there's a lot more turnover. Or multiple frontline workers are coming in and out and they know their workers. So when somebody walks right out the door, you know, they throw down their hard and they're out to reset their password, that they face.

It's important to understand that what we have now with administrative units, is focused on users and groups.

There are devices where we can manage computers especially when you go into Intune. 

There's this privileged access but the admin units primarily are focused on users and groups and to even assign them you've got to be a global admin to create admin units.

You've got your groups, administrators, your help desk administrators, whether it's resetting passwords or being able to be assigned to that license. 

Being able to say whether somebody has rights to be able to use PowerApps there's some neediness around what licenses people might need.

And passwords are number one. When you start talking about what is the support aspect of a tenant and what people might need to be able to delegate. 

Imagine you have three regional operations and multiple on-premise domains that are being synchronized. Your tenant is broken in - the Americas, EMEA, and APAC. 

So as an example, we could say this one is HR. So you can do your business units as an example. And because it's the new year, we have HR benefits people, and they're managing a lot of the licensing. So basically if there's a lot of turnovers, maybe we're getting ready for layoffs, or maybe we're doing a big hiring spree and HR needs to be able to go in there.

Now, this should look familiar. Here are our authentication groups, help desk licensing passwords, and user administration. So, we can pick one of these and we can see who's in here and who we want to add. 

But basically, the idea is you'd assign all the users to that so they can manage users and groups for that AU.

One of the key things to understand is administrative units. You can do those with Azure ad portal, PowerShell, and Graph, which might be a great way of being able to do assignments region based, based on attributes.

From Microsoft guidelines, the idea of starting to create administrative units based on some criteria like region or department and so on, and then prune those ones that are not being used. And then over time, your structure for those admin units can then be stabilized. 

When we're talking about complex environments, it's really important because you create an administrative unit and then you have to manually add users to it. Now, you could use a CSV file or you could use PowerShell to add members, but that's something that that's ongoing maintenance in terms of you have to continue.

We suggest doing some level of delegation, in your provisioning process, where you're adding somebody as a secondary admin as like a backup experience or adding, um, it more in the, and of being regionally, just these sites, these group mailboxes.

To wrap things up:  

1. Set up your administrative boundaries

2. Admin automation does require global admin rights

FAQ

What about the Exchange attributes now found in active users? 

I don't think it's going to give them access to the Exchange but what's available on those user objects, through graph power.

The operator has to use the M365 admin center, and there are only six roles that they can be assigned.