It's time to get things serious and talk about designing and managing your workload.
Microsoft 365 DSC allows you to monitor and manage your Microsoft 365 environment across Azure AD, Teams, SharePoint Online, Exchange Online, Microsoft Purview, Microsoft Intune and more.
It is the perfect tool to implement Configuration-as-Code and perform operations such as multi environment provisioning, policy backups, drift monitoring, and integrate it with your DevOps processes. You could for example provision other tenants without knowing all the delicacies and complexity of managing multiple APIs and modules.
I can briefly mention some of the benefits of the solution:
Wide scope: Azure AD, Teams, SharePoint Online, Exchange Online, Microsoft Purview, Microsoft Intune, Planner, ...
Large panel of policies available: 250+
Uniform platform
PowerShell based
DevOps Integration
Simplicity of deployment
Continuous development
In this blog, I share some suggestions to plan and design any type of environment. We will also walk through the steps to deploy your first M365DSC configuration.
Refer to my previous blogs to get an overview of DSC and Microsoft 365 DSC
Table of content
Plan and design decisions
Decision 1: Monitor or enforce?
The solution is build on Desired State Configuration (DSC), which means that we have to manage and configure the Local Configuration Manager (LCM) engine
The first decision we need to take is how the LCM should interact with our tenant:
a- Monitor my tenant by configuring the LCM configuration mode to ApplyAndMonitor (Read only approach)
b- Enforce a desired configuration by configuring the LCM configuration mode to ApplyAndAutoCorrect (Read-write approach)
 | The first run of your configuration will write to the tenant if the engine detect a drift, so make sure your exported configuration file is recent and an exact copy of your tenant |
To configure the LCM use Set-DSCLocalConfigurationManager cmdlet and the ConfigurationMode parameter.
Make sure to adjust the refresh time as needed by configuring the RefreshFrequencyMins.
Decision 2: Centralized or decentralized management?
This is an important decision and it will depend on how your nodes will be managed.
DSC can work as Push (decentralized) or Pull (centralized) mode.
For most people a push server will be the answer as it is simpler to deploy and maintained. The servers or nodes will be autonomous and will host their own configuration and push them to the Microsoft 365 environment.
For more control, you may want to opt for a pull server and take the advantage of storing your configuration files in a central place. The different nodes will pull their configuration from the pull server/cluster and update the Microsoft 365 tenant.
The configuration files can be stored in an SMB share or a web service. You may also want to consider provisioning high availability using failover clusters, DFSR, and/or Cluster Shared Volumes.
To configure the LCM engine mode use the Set-DSCLocalConfigurationManager cmdlet and the RefreshMode parameter.
Decision 3: Workload architecture.
You can only host a single LCM per machine which will run a single configuration.
Since the process is unique, we could end up with a lengthy configuration file, hard to manage or modify and prompt to error: it's never a good idea to have all your eggs in the same basket. Such config will be slow and would take hours or even days to complete depending on the environment' size.
We should split the workload across multiple compute resources and thus:
Improve manageability: you would only edit the relevant file.
Improve performance: you would run the different job simultaneously.
Improve scalability: you can easily scale in and out your deployment.
Reduce cost: as you would scale your workload based on the consumption.
Improve security: it will be easier to apply least privilege.
The workload can be split based on a single or a combination of criteria, such as:
Workload: Azure AD, Intune, SPO,...
Category: Security, Collaboration, Identity
OS Type: for example splitting Intune workload based on the OS platform: Windows, Android, iOS
Administrative unit: you may want to split the policies based on the targeted business unit.
Personas: You may want to create a profile for different personas in your environment: Admins, Standard users, guests,...
Severity: You may have a low, medium, or high severity baseline to apply
Tenants: You may be managing multiple tenants
Decision 4: Cloud vs On-Premises?
This is a decision that should follow your organization vision. Many companies today are migrating to the cloud which could help with reducing infrastructure overhead maintenance and cost, improve scalability and security.
Microsoft 365 DSC can run in any Windows physical, virtualized or containerised environment and be deployed in Infrastructure-as-a-Service (IaaS: Azure, AWS, GCP,..) or Platform-as-a-service (PaaS: Azure automation, Azure Kubernetes Service)
For new project, it is often easier to use the cloud as you don't need to invest on new hardware to start running your workload. It is also more flexible to upgrade or downgrade based on the current activity.
However if you have some spare resource in your datacenter, you may want to integrate it with the current workload.
Decision 5: VMs vs Containers?
To fulfil the potential growth needs and limit the cost of running the solution, you would need some flexibility to upgrade and downgrade the number of running nodes. In the background, DSC is using the Windows Management Instrumentation (WMI) and Windows Remote Management (WinRM) service which are both portable and commonly available in most Windows environment.
Your workload could run from 2 types of compute resource:
a - virtual machines
b - Windows containers
The first option is more traditional and would be the natural choice for most people. It will run in an Hyper-V or VMWare virtualized environment and can be highly available. It requires more resources which could increase the running cost and limit the number of running nodes. It is also harder to scale out and takes longer to provision and configure.
Docker and containers could be the solution for any type of environment: small, medium and large with a single or multiple tenants. Microsoft 365 DSC can run on Windows Docker containers and is the perfect solution to scale out your workload and run as many nodes as you need. Containers share the same kernel and thus are smaller in size and use less resources. You can provision additional containers within seconds and achieve your design in no time. On the other hand, it will require some additional skillset to run.
If your deployment has grown and become difficult to manage, you could start looking at an orchestrator such as Kubernetes (K8s) to manage your containers and worker nodes.
Decision 6: DevOps?
Integrating Microsoft 365 DSC with Azure DevOps or other DevOps tools will help you control who, how and where new resources are provisioned. It offers some rollback capabilities with versioning and improve the overall security.
Yorick Kuijs has put together a whitepaper describing how to create your first pipeline and configure your managed identity to retrieve all your credentials and automate your deployment securely.
The whitepaper is available here: Managing Microsoft 365 with Microsoft 365 DSC and Azure DevOps
Decision 7: Security!
Like someone very wise said: "with great power comes great responsibility" (I know it's very sketchy but always work 😁)
Our DSC workload will be highly privileged and thus need to be restricted as much as possible.
These are few considerations you should apply:
Use Certificate authentication and Service Principal (SP) if your workload is on-premises or IaaS
Do not store your service principal secret in clear text or in your DSC workload and store your certificate safely
Use Managed Identities when possible
Use Conditional Access policies to apply controls based on location and workload
Use Defender for Cloud Apps to monitor your Service Principals permissions
Use Defender for Cloud to monitor your Kubernetes and DevOps environments
Make sure to restrict who can create applications and grant permissions in Azure AD
Split your workload between multiple SPs and apply least privilege: don't add write if only monitoring configuration drifts or don't give all the possible permissions to your SPs because it's more convenient
Consider your worker node highly sensitive, restrict and monitor who access them
Decision 8: Logging and monitoring.
When it comes to monitoring configuration drift, Microsoft 365 DSC generates Windows events that can be ingested through the like of Log analytics/ Azure Monitor and integrated with Microsoft Sentinel for example. Use those tools to export and retain changes for overall visibility and transparency and creating the relevant alerts.
You could also use the built-in Custom Notification Endpoints and create your own Webhooks to publish chatbot in Teams for example. Watch Nik Charlebois's demo on custom notification endpoints on M365DSC YouTube channel:
How-to deploy my first configuration
Now, that we understand the extend of the solution and completed our planning, we can get our first configuration up running.
You should take a crawl, walk and run approach and make sure to test and monitor every resource you deploy.
Always start by exporting a resource using Export-M365DSCConfiguration.
This will help you create and developed the correct configuration as some resources includes embedded CIM Instances and can be tricky to get right the first time.
Those are the high level steps to create your first worker node:
1- Configure WinRM by running in an eleveted command prompt
winrm quickconfig2- Configure your LCM environment as relevant to your environment
Set-DSCLocalConfigurationManager `
-RefreshMode Push `
-ConfigurationMode ApplyAndMonitor `
-RefreshFrequencyMins 103- If using certificate authentication, make sure to add it to the Local Computer store as WinRM runs as System.
4- Export your resource
$params = @{
ApplicationId = "12345678-1234-1234-1234-123456789012"
TenantId = "mytenant.onmicrosoft.com"
CertificateThumbprint = "8ad9d5bcaa00dcb3947ac6b24f4494336bc12345"
}
$resources = @(
'AADConditionalAccessPolicy'
'AADNamedLocationPolicy'
)
Export-M365DSCConfiguration `
-CertificateThumbprint $params.CertificateThumbprint `
-TenantId $params.TenantId `
-ApplicationId $params.ApplicationId `
-Components $resources `
-path "C:\WorkingDir" 5- Compile and start your DSC configuration
cd "C:\WorkingDir"
.\M365TenantConfig.ps1
Start-DscConfiguration -Wait -Verbose -Force -Path .\M365TenantConfigConclusion
Microsoft365DSC is an amazing tool to manage your Microsoft 365 and take your environment to another level. It is free to use and can suit all type of deployments in simple or complex environment.
It will improve your overall security and automate many of your processes.
Don't hesitate to visit the official website, the YouTube channel and the GitHub repository.
Comments