DevOPS for Office 365

Unless you’ve been living under a rock for the past 6 months, you’ve all heard me talk about the Office365DSC project that the team and I have been working on lately. The idea behind this project is to allow System Administrators to define their Office 365 Tenants’ configuration as code. By exposing all of their settings (e.g. SharePoint Search Managed Properties, Teams Channels, Exchange Online Mailboxes, OneDrive settings, etc.) as code, organizations can now integrate their Office 365 environments with their DevOPS practices. What we are trying to promote with this project is that we want to make sure changes to Office 365 Tenants are done in a consistent and managed fashion.

Let’s explain this further by taking a typical scenario where your organization wants to add a new Search Managed property to their Office 365 Tenants. The System Admin would receive the request, and go in their Source Control tool to add to the existing Office365DSC configuration script the few lines of code that represent that new Managed Property. When they save the changes, automated processes would take care of compiling the Office365DSC script and would execute a remote configuration process that will go and automatically create that new managed property on the tenant. This reduces the risk of deployment errors, and ensures that this configuration script in our source control is always the “Source of Truth”, meaning that what is defined in it, is sure to be exactly how the Office 365 tenant is configured.

Now let us take the example where you have multiple tenants, say Dev, QA and Production. The automated deployment process would first start by deploying the change to the Dev tenant, and then assign a review task to the accountable team. Upon reviewing the change and approving it, the change would then be promoted to QA, and another approval task would be sent. Then whenever the change is approved in QA, it will then be promoted to Production. All of this completely automated.

In this article, I will describe the recommended process for organizations to put this automated process in place using Azure DevOPS. If you want the 5 minutes video overview, you can watch the showcase video Integrating Office365DSC with DevOPS Pipelines.

Azure DevOPS Repos

As demoed in the above video, we will start with an empty configuration skeleton. If you wish to start with a configuration that represents the actual configuration of an existing tenant, then I recommend you look into the native ReverseDSC features that are baked-in Office365DSC. Please refer to my Getting Started with Office365DSC article to leanr more about ReverseDSC for Office 365, or watch this short video Extract Full-Fidelity SharePoint Online Configuration with Office365DSC.

Back to our scenario, the following lines of code are what we will be starting with in our case. Now, very important, for the purpose of the demo, I am passing plaintext credentials in my configuration script (even worst I am hardcoding the password in the actual configuration). Do not attempt this at home! This is strictly to keep my demo as simple as possible to demonstrate the capabilities.

Configuration O365
{
    Import-DscResource -ModuleName Office365DSC
    $password = ConvertTo-SecureString 'MySecretPassword' -AsPlainText -Force
    $GlobalAdmin = New-Object System.Management.Automation.PSCredential ('MyGlobalAdmin@office365dsc.onmicrosoft.com', $password)
    
    Node localhost
    {
        # Add code changes
    }
}

$ConfigData = @{
    AllNodes = @(
        @{
            NodeName                    = "localhost"
            PsDSCAllowPlaintextPassword = $true
        }
    )
}

O365 -ConfigurationData $ConfigData
Start-DscConfiguration O365 -Wait -Verbose -Force

This configuration is stored in my Azure DevOPS project’s Repos as O365.ps1. The following screen capture shows the content of my Repos for this demo.

The second file (other than the Readme.md) in my Repos, which is named Deploy.ps1, is located under the Release. Is is a PowerShell script that will be executed on my DevOPS build Agent and which will take care of downloading the Office365DSC module onto the Agent and will then execute the Office 365 configuration remotely against your tenant. The script in itself if farily straight forward:

winrm quickconfig -force # Configure the Agent to run DSC configurations
Install-Module Office365DSC -Force -AllowPrerelease # Install the Office365DSC module
&"D:\a\r1\a\_Showcase-CI\DSC\O365.ps1" # Execute the DSC Configuration script from the built artefacts

Builds Pipelines

Now that we have our files created and available in our Repos, the next step is to define a Build Definition. While we will not be “compiling” anything during our Build phase, we still need to have our files available as Artefacts for our Release definitions. Our Build Definition will consist of two very small steps:

1. Copy all the files from our Repos into the Artefacts folder
2. Publish the Artefacts, making them available for our Releases Pipelines to consume

The first phase will involve a Copy Files step configured as follow:

The second phase consists of a Publish Build Artefacts step, which takes on the following values:

The last step is to define automatics triggers for our Build Definition which will allow for a build to be automatically triggers each time a new change is commited to our Repo. To do so, navigate to the Triggers tab and make sure you check the box beside the Enable continuous integration option.

Releases Pipelines

The last step in our DevOPS process is actually execute our Tenants’s configuration. This will be done through an Azure DevOPS Releases Pipeline. Our Release Definition is even simpler than our build definition and it only involves a single step, which is to execute the Deploy.ps1 script from our Release folder.

The Release step is simply a PowerShell step configured to run our script as follow:

Just like we did for our Build Definition, we want to automate a new Release everytime a successful Build occured. To do this, we need to define a Release Trigger. Simply navigate to the Release Definition Overview page and click on the Continuous deployment trigger icon (ligthning icon beside the Artefacts) to get to the Release Trigger panel:

From that screen, simply enable the trigger and save your Release Definition.

DevOPS in Action

Our DevOPS pipelines and processes are now all in place. The only thing remaining is to go and modify our O365.ps1 configuration script to add, modify or remove components or our Office 365 Tenants. In our case, we will be creating a new SharePoint Online Site Collection, along with a new Teams and its associate channel. We will be inserting the following lines of PowerShell code in our file right after the line # Add code changes:

#region SharePoint Online
        SPOSite DevOPS
        {
            Url                = "https://office365dsc.sharepoint.com/sites/DevOPS"
            Title              = "DevOPS"
            Owner              = "admin@Office365DSC.onmicrosoft.com"
            StorageQuota       = 100
            CentralAdminUrl    = "https://office365dsc-admin.sharepoint.com"
            GlobalAdminAccount = $GlobalAdmin
            Ensure             = "Present"
        }
        #endregion

        #region Teams
        TeamsTeam DevOPS
        {
            DisplayName        = "DevOPS Demo"
            Description        = "This is me demoing the Teams Resource"
            GlobalAdminAccount = $GlobalAdmin
            Ensure             = "Present"
        }

        TeamsChannel DSCChannel
        {
            TeamName           = "DevOPS Demo"
            DisplayName        = "DSC Discussions"
            GlobalAdminAccount = $GlobalAdmin
            Ensure             = "Present"
        }
        #endregion

Add the code to the file and commit the changes back to your Repos. A new Build should automatically be triggered.

Once the build completes, a new Release will also be triggered:

After the Release completes, you should be able to navigate to your Office 365 tenant to verify that the changes have been properly applied!