Many companies are adopting DevOps practices and want to apply these practices to their Microsoft 365 tenants. If you don't adopt DevOps for Microsoft 365, you might encounter some common problems:
- Misconfiguration
- Challenges with tracking configuration changes
- No approval process for tenant modifications
You can use the solution described in this article to automate changes to Microsoft 365 tenant configurations by using Azure DevOps and Microsoft365DSC. Microsoft365DSC is a PowerShell Desired State Configuration (DSC) module. You can use it to configure and manage Microsoft 365 tenants in a true DevOps style: configuration as code.
The solution described here tracks changes made by service administrators and adds an approval process to deployments to Microsoft 365 tenants. It can help you prevent untracked changes to Microsoft 365 tenants. It also helps to prevent configuration drift between multiple Microsoft 365 tenants.
Potential use cases
This solution can help you manage Microsoft 365 tenant configuration in a controlled and automated way, using DevOps tools and practices, across:
- Development, test, acceptance, and production environments.
- Multiple customer tenants, as in a managed-service provider scenario.
Architecture
Download a Visio file of this architecture.
- Admin 1 adds, updates, or deletes an entry in Admin 1's fork of the Microsoft 365 config file.
- Admin 1 commits and syncs the changes to Admin 1's forked repository.
- Admin 1 creates a pull request (PR) to merge the changes to the main repository.
- The build pipeline runs on the PR.
- Admins review code and merge the PR.
- The merged PR triggers a pipeline to compile Managed Object Format (MOF) files. The pipeline calls Azure Key Vault to retrieve credentials that are used in the MOFs.
- An Azure PowerShell task in a multistage pipeline uses the compiled MOF files to deploy configuration changes via Microsoft365DSC.
- Admins validate changes in a staged Microsoft 365 tenant.
- Admins get notification from the approval process in Azure DevOps for the production Microsoft 365 tenant. Admins approve or reject the changes.
Components
- Azure Pipelines enables continuous integration (CI) and continuous delivery (CD) to test and build your code and ship it to any target.
- Azure Key Vault improves the security of storage for tokens, passwords, certificates, API keys, and other secrets. It also provides tightly controlled access to these secrets.
- Microsoft365DSC provides automation for the deployment, configuration, and monitoring of Microsoft 365 tenants via PowerShell DSC.
- Windows PowerShell DSC is a management platform in PowerShell. You can use it to manage your development infrastructure by using a configuration-as-code model.
Alternatives
As a next step, you can use DSC in Azure Automation to store configurations in a central location and add reporting of compliance with the desired state.
This architecture uses Key Vault to store Azure App Service certificates or user credentials that are used for authentication to the Microsoft 365 tenant. Key Vault provides scalability. As an alternative, you can use pipeline variables to reduce the complexity of the solution.
Considerations
Most people starting out with PowerShell DSC find that it takes a while to learn it. It helps if you have a solid understanding of PowerShell and experience with creating scripts.
Operations
Some operations teams consider Azure DevOps to be a tool for developers. But these teams can benefit from using Azure DevOps. Operations teams can:
- Store their scripts in a repository and add source control and versioning.
- Automate deployments of scripts.
- Use boards to track tasks, projects, and more.
Using a configuration-as-code model isn't a one-time task. It's a shift in your way of working and a fundamental change for all team members. You no longer make changes manually. Instead, everything is implemented in scripts and deployed automatically. All team members need to have the skills to make this change.
Scalability
You can use this solution when you're working with multiple environments, multiple workloads, and/or multiple teams. You can configure the validation process so that experts need to approve each workload. You can also extend the solution to deploy to multiple tenants, for a dev/test/acceptance/production scenario and/or for multiple organizations.
To increase scalability even further, you can use an aggregated-configuration data solution like Datum.
Security
Most Microsoft365DSC resources support authentication via user name and password. But we don't recommend that type of authentication because Microsoft best practices recommend multifactor authentication. Application credentials is the preferred method, where supported by the Microsoft 365 resources. For example, SharePoint Online, Azure Active Directory (Azure AD), and other resources support application credentials.
If you build a Microsoft365DSC solution on Azure DevOps, you can also take advantage of the security in Azure Pipelines and an approval process to safeguard deployment to your production tenant.
DevOps
You can run this solution in Azure DevOps Server. You could create a similar solution in GitHub by using GitHub Actions.
Pricing
For Azure DevOps pricing information, see Pricing for Azure DevOps. If you incorporate Key Vault into your solution, you can find pricing information here.
You can also use the Azure pricing calculator to estimate costs.