On-boarding secondary school into MAT tenancy

[CyBeRkId2002]

Good afternoon folks... pretty technical question I am looking for some guidance / best practice around - particularly those who work in larger MATs including secondaries

 

We have a central MAT tenancy that currently hosts one secondary school and all of our primaries which we have migrated over during the past 6-9 months. All of this works great - better than anticipated even - and support calls and recurring day-to-day issues are rapidly disappearing. I am now beginning the work of investigating how this could work with secondaries, and how larger schools are carrying out the onboarding process of more complex IT environments. Things that make this tricky and are different to our primaries:

 

• The two secondaries in mind are not really ready to go fully Intune for device management yet. This is due to both technical barriers (one school not having the required hardware / TPMs to do this in a manner I would deem secure) and practical / time barriers
  
• Both schools are currently using MS Azure Sync (one with the trust tenancy, the other currently with their own)
  
• Neither school are fully invested in OneDrive / Sharepoint at this point in time so a hybrid approach is likely needed initially with access to internal shares etc.
  
• A cloud printing solution would have to be identified (I don't think my scripts would cut it on the scale that would be needed for a secondary)
  

 

My primary focus is to move to a central tenancy for ease of administration, better oversight on compliance and - most importantly - to improve collaboration. These are all of the reasons we went down this route in the first place and what I deem as the priority! Centralised device management is definitely part of the long-term goal but I think if we wait for that we will potentially be holding up the collaborative benefits longer than necessary.

 

As such the plan as I see it has been to:

 

• Ensure AD is tidy in the school being on-boarded and that certain attributes are filled as necessary
  
• VPN link the schools and create an AD forest trust
  
• Azure AD Sync from the Trust school from both schools AD
  
• Agree a switch-over date and migrate necessary data (Exchange / OneDrive / Teams) at this point in time (potentially engaging a third-party to manage this)
  

 

I just thought, as a sanity check, to put the feelers out to other schools and see how you have managed this technical barrier and whether we are heading down the right road? The only other options I see are:

 

• Dont AzureAD sync the new school and instead create the users manually / using a third-party tool. This would allow us to do a staggered migration (which I get the impression they would prefer) but would lose the simplicity of SSO. I definitely think this is a headache waiting to happen!
  
• Push forwards with a move to Intune - agree a realistic deadline to have all testing complete and carry out the tenancy move and device migration at the same time
  
• ???
  
• 
  

 

Looking for any pointers from anyone who has been through this process and how you have managed it.

[chaplic]

I've been through this a few times, not with schools but the closest example was a household name firm who decided to consolidate their various firms in a single O365 tenant for pretty much the same reasons as you give. I argued hard to focus on the O365 collab end and not to be overly precious about AD at least at first.

 

I think you are along the right lines. Tenant to tenant migration is painful but the payoff is worth it.

 

But note, you CAN sync the same AD account to two O365 tenants (it's always been possible but its now supported). This opens up staggered migrations as a route.

 

Do you need to bother with the forest trusts if you are trying to nudge people towards cloud?

 

At some point down the line, if you want, consolidate to a single domain and reattach the new AD account to the existing O365 account.

[CyBeRkId2002]

Thanks very much for the response - at least useful to know we aren't heading in a completely wrong direction. Also really helpful to know that we can sync to two tenencies. This should help no end.

 

The only thing I wanted to clarify - with regards the forest trust - is this not necessary for the Azure AD Sync client to sync two different domains? Is it a simple matter of the server being able to see both AD's, and entering appropriate credentials for both independently? If so then we will definitely skip the trust part, I just thought it was needed for some reason.

[CyBeRkId2002]

Also for the staggered migration would it be as simple as:

 

• Add new domain to the trust tenancy
  
• Setup Azure AD sync to sync to new tenancy
  
• Migrate individual email boxes as appropriate
  
• Change users domain suffix and email in AD
  
• 
  

 

It almost seems TOO easy

 

I suppose then the only complication if doing staggered is when to move sharepoint sites / teams as I see this being a nightmare in the medium-term if we move a handful of users at a time. At least it opens up the options of moving Students in a batch and Staff in a batch and planning around this.

[chaplic]

The domains you sync up dont need to trust each other, you are prompted for a service account per forest.

 

I should probably throw in the couple of gotchas that mean its not too easy

 

You can't have the same domain in two tenants, so you'll end up sync errors.

 

 

Let's say schoolA is the domain we want to sync to MatO365, and schoolA is currently also syncing to SchoolAO365

 

Pick a couple of AD attribubtues for schoolA, I would pick wwwHomepage for UPN and carLicense for proxyAddress. In wwwHomepage put the new user login name (e.g. [email protected]) and in carlLicense put proxyAddresses e.g

SMTP:[email protected]

smtp:[email protected]

 

 

 

The outcome of this is the same AD account will sync to both tenants with different email addresses and login names, hopefully we dont have ADFS in play as that will need modified to team (good reason for PHS).

 

In AzureAD Connect that reaches into SchoolA and syncs to MatO365 you have to write a custom rule that takes the wwwHomepage value from AD and maps it to UPN in O365 and carLicense to proxyAddresses

 

When you migrate someone, you basically setup email forwarding (probably as part of a migration tooling) and when complete retire domain from old tenant and add to new, then unwind the carlicense and wwwhomepage config.

 

 

You can build all this in a test lab (with two O365 forests) and you should. Free developer O365 accounts come in handy here.

[CyBeRkId2002]

ah, ok.

 

What I thought would happen is:

 

• setup new Azure AD sync
  
• Sync tries to sync [email protected] - knows domain isn't registered so possibly throws up some errors but gives them [email protected]
  
• Add @Mat.org to school AD and change this over for users in batches
  
• Sync runs and changes [email protected] to [email protected]
  
• 
  

 

Are you saying that actually what happens is it will simply fail to create the accounts full-stop as it knows the domain is registered to another MS tenancy - hence the workaround? If so thanks for the info - really useful to know!

[chaplic]

Blimey, that's got me thinking..I think assuming you dont mind the unpretty username and dont want to use federated auth (ADFS) and you can license the accounts in the target tenant and you don't currently have proxyAddresses populated (thus just use the UPN for email address) I think that should work, though I've got a little voice in the back of my head saying there might be a gotcha;)

[HereIGoAgain2601]

We have had something of a similar experience recently. All of our 8 secondary schools were using a single office 365 tenant on one domain - but still had 8 separate ADs. They were using RM unify to sync passwords between the ADs and 0365 - definitely don’t recommend that one. Anyway we have just moved away to Azure AD Connect Cloud - slightly different than normal AD connect. It does password sync and SSO into 365, although it isn’t as reliable as the full Azure AD connect when it comes to SSO.

 

Our experience is that if the domain hasn’t been set right on AD (ie it is sent to ad.internal) it will sync to 0365 but give them the default @onmicrosoft logon. Obviously you can’t change this on 365 as it’s a synced user but can add the right UPN suffix to each AD and this will sync correctly into the Tennant.

 

It’s working well enough as a temporary solution - some of our schools aren’t ready for full intune so we are going to roll out a Trust wide AD this summer. Which I know is a bit backwards but it’s where we are for now - plan is to get everyone ready for full Intune by 2025.