Back to blog

Launching our Office 365 management solution

Jun 28, 2018 by Greg Jones

One fateful day in Lisbon last year, Mike Weaver (another Quadrotech product owner) and I became responsible for the creation of a new Office 365 tenant to tenant migration tool. We were going to deliver it within an amazingly short (translation: nearly impossible) timeframe. Finally, Cloud Commander was launched just before Ignite last year. Mike and I were both excited and proud of what was accomplished. A weight lifted off our shoulders.

It was around that time when I was asked to do it all again, this time alone, for an Office 365 management tool. Here’s a glimpse at the growing pains of architecting the second solution, Autopilot.

Role-based access control and organizational unit-based standardization

The project started off simply. We looked at the challenges that customers encounter following a migration to Office 365. Then, we asked ourselves how we could help solve those challenges.

The immediate task seemed straightforward. Global Admins were doing things that you really shouldn’t need that much privilege to do. For example, many organizations rely on a very small, highly skilled group to do tasks (like granting access to resources or updating profile information) that could be handled by less experienced employees. We wondered what would happen if we gave GA access to those less experienced employees and, thus, freed up the skilled employees. So, we set out to create a solution with a least privilege model that provides role-based access control (RBAC).

Easy enough, right? Well, it would be if Office 365 had organizational units (OUs) we could use to group users for delegation. It does not. So, we decided to create that functionality within our tool. We’d have “Virtual OUs” we could use for delegation.

A screen shot of Autopilot's virtual OUs, our Office 365 management solutionj

Here’s how it looks to add a user to a Virtual OU in Autopilot.

Thanks to Virtual OUs in the new tool, we can group users and delegate administration. What else we could we provide? How about standardization based on OUs? For example, when Bob moves from the United States OU to the Germany OU, I really want his country code to be updated automatically. Similarly, when Sally changes roles and moves from the Marketing team to Sales, I want Sally to automatically get access to the Sales Shared Mailbox. So, we made this happen, too.

Architecting the Office 365 management platform

We needed a platform that could make this functionality possible. With the mass exodus from on-premises to the cloud, it was really a no-brainer that we’d create a SaaS solution.

Next, we needed to decide where we’d host it. In our datacenter, Google, AWS, Azure? Well, we settled on Azure with Service Fabric for resiliency and reliability of the application.

Now we had the platform and the ideas, but we still had to figure out how to make any changes actually get applied. Of course, there is both a frontend and backend answer to this. The front end needs to have a familiar feel. It needs to be easy to use and understand. Since users are familiar with Office 365, we decided to use the Office UI Fabric. But, the team didn’t just use a framework, they built out an amazing blade architecture that’s sharp and responsive.

On the backend, we needed to figure out how changes requested by a user would get implemented in other applications (Office 365, Exchange, etc.). With Office 365, we do it using the Graph API, as well as Office 365 PowerShell. In fact, we have an agent for both.

We also needed an auditable way to control who does what within the platform. For this, in our core, we verify and log all the actions that a delegated administrator does, and sends the requested commands to our agents.

It’s more complex than it sounds

This is a simplified view of Office 365 management. In reality, some users are going to need Active Directory syncing with Azure Active Directory, Exchange hybrid, not to mention SharePoint and Skype sitting somewhere in there too. It’s actually a pretty complex problem to fix. Because of this, we created the on-premises agent.

Remember the concept of Virtual OUs? We determined that we could import all the local Active Directory OUs as well, since organizations have spent a lot of time refining those over the last (nearly) two decades. Why start from scratch? We show both local OUs and Virtual OUs in the same interface.

Yes, we can manage both local and cloud with API or PowerShell. This is huge because with PowerShell and Graph, almost any administrative task is doable and thus a potential feature. This architecture is great. It permits flexibility and quick feature creation in this DevOps world.