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.
So, what’s a rapidly greying IT Manager to do?
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.
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.
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.
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.
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.
Microsoft Architect
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie | Duration | Description |
---|---|---|
cookielawinfo-checbox-analytics | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics". |
cookielawinfo-checbox-functional | 11 months | The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional". |
cookielawinfo-checbox-others | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other. |
cookielawinfo-checkbox-necessary | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary". |
cookielawinfo-checkbox-performance | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance". |
viewed_cookie_policy | 11 months | The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data. |
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Other uncategorized cookies are those that are being analyzed and have not been classified into a category as yet.