Breakin’ up ain’t so hard: An Office 365 fable

Facing a company separation? It doesn’t need to be so hard.

It’s Monday.
Imagine yourself in your director’s office early one Monday morning. They’re never the best meetings, and today is no different. He’s talking about a company spin-off. He’s talking about project completion “in a couple of weeks.” He’s pointedly not talking resources or budget (which comes as absolutely no shock to you).

“Get these one hundred users off our Office 365 to somewhere, anywhere, I don’t care where. They’re gone, off our address book like they’re a separate entity,” he intones. That’s the sum total of your guidance. And as you’re walking out, you hear, “Oh, and they’ll still need access to all those terabytes of project files and design drawings. Any questions? No? Great. Off you pop then son, crack on.”

Time To ThinTagsk Things Through.
You slink back to your corner cube, grab the markers, smartly step-up to the team whiteboard, and start cogitating. No, it’s not a rude word, trust me on this.

You start to think through some familiar options.

1. You could setup a whole new Active Directory structure and a new Office 365 tenant and put the users into that infrastructure. Trouble is, that’s a whole lot of time-consuming work. There’s new VMs, new PCs, and new licenses—little of which you have the resources for. Above all, you’ll have to spend time working out how to map the users in this new forest to the files they had access to with their old credentials.
   Trouble here is—according to that wonderful guidance given by your director—you simply don’t have time for that. If you’d chosen to create a new domain within the existing forest, that still gives you the headache of new DCs and moving user accounts for which you have no time to properly plan and assign file access permissions.
2. You could add a new SMTP domain to your Office 365 tenant and just assign those new people a new UPN and SMTP address, so that almost nothing has changed.
   Problem here is, that doesn’t give you the required separation at the email address-book level. It’s also a troublesome option because you’ve been through the process of removing a domain from Office 365 before, and you’ve still got the scars to prove it.

So, what’s a rapidly greying IT Manager to do?

A Lightbulb Moment.

You decide to think a little bit outside the box. “What if I were able to separate these users into a fresh Office 365 tenant, but not touch their Active Directory until the long-term future of all the project files, financial systems, and other SaaS applications was known?”

Surely there’s a halfway house here that will not bind the hands of some other IT compatriot in the future.

Here’s what you come up with.

1. You’re going to setup a new Azure AD Connect server and a new Office 365 tenant. In that tenant, you’re going to register and apply the new domain that you’ve been told is necessary–and was fortunately available to you.
2. On your Active Directory, you’re going to add a new UPN for this new company and assign it to your newly created test accounts. Those accounts have been created in a new OU. That new OU is the ONLY one that syncs to the new tenant, so you’ll go into your old Azure AD Connect server and exclude the new OU from syncing to the old tenant.

These steps will allow you to maintain user access to the existing project and financial system resources, and also give the new company a fresh Office 365 environment with dedicated Teams and SharePoint sites. This enables you to add the requested access, as these users will need access to the old environment, users in the old environment will not be permitted access into the new one.

Your Environment: The Before

Before the addition, you had a single Azure AD Connect server synchronizing information to and from Office 365 to the specified OUs. There was only one Office 365 tenant under your control.

Your Environment: The After

After making the changes, your setup is only slightly more complicated. The original Azure AD Connect isn’t doing anything different; it didn’t synchronize all the OUs before and you’ve made sure it doesn’t do this new OU either. That keeps any accounts in that OU from making it into the Office 365 tenant in which you don’t want them.

The new Azure AD Connect only does the one OU that you created as part of this project, so it’s not a particularly complicated configuration. You have the new domain added into Active Directory as a UPN and the domain matching that UPN is the only one synchronizing to Azure Active Directory.

Some housekeeping still needs to take place. New internal processes need to be developed to regularly check that new OUs are not added into places where they may inadvertently synchronize to the wrong tenant. Obviously, keep a good eye on synchronization failures, or indeed errors—but you were doing that anyway in your original tenant, so remember to make sure the monitoring is now done against both.

Great. What About the Future?

As far as access to internal resources goes, you’re going to have to handle the issues users always have when something changes. Although their NetBIOS style logon didn’t change, they’re going to have to be shown how to use their UPN. However, that was on your project list anyway, so this thing just turned into a convenient pilot.

As far as Office 365 goes, you’ve done yourself a serious favor. By keeping the domain away from the old tenant (because you know there will eventually be a full separation at a point not too far distant) and you’ve positioned the new company to strike out on their own without too much trouble.

You know that when the time comes you can sever the Azure AD Connect linkage to your own Active Directory and quickly bring the accounts in that new tenant up as Cloud-Only accounts. From that point the new company can choose to stay like that or establish their own Active Directory and synchronize the cloud to AD via SMTP soft-matching—or whatever new solution Microsoft comes up with to make life even easier.

By this point you are more than pleased with what you’ve done, and rightly retire to the pub, because laurels won’t rest on themselves, you know.

We hope that you’ve enjoyed this little fable about a theoretical company separation. We at Anexinet work extensively with Office 365, and would love to help you and your company with your own Office 365 journey. If you’re interested in any areas of Office 365, please check out these blogs written by myself and my colleagues. Otherwise, please don’t hesitate to reach out.