MSP asking for getting started advice: Anyone willing to spend some time 1:1? (PAID, if it helps!) about microsoft365dsc HOT 5 OPEN

This is very much just some random thoughts after using this tool for a few months but I'll give you a stab anyway. I much prefer to have this conversation in the open so that others may contribute/benefit.

Export configs from our master tenant contain numerous GUIDs from the source. How should we handle them?

We have removed all the GUIDs from our exports, for example, objectIDs. We then ran the DSC on a new tenant to see what works and doesn't. We're still fairly early on in this process, but its quite doable. We are taking tenants with existing configuration. We are finding its giving us an opertunity to clean up configuration inconsistencies, for example conditional access policies that are assigned direct to user GUIDs rather than groups.

Exports contain resources for which neither source nor target tenants are licensed (ALL our tenants are M365BP). How should we handle unlicensed resources before deployment?

We've come across this with assigned licenses to groups. This has worked in our case, the groups are not erroring because the license doesn't exist in the target tenant. There may be other issues that we haven't come across, we've spent all the time on EntraID so far.

Our target / client tenants will all follow an identical (!) blueprint/baseline. Any suggestions how we should connect/authenticate/push/pull with hundreds of tenants? Will that scale with Azure DevOps pipelines?

We're not using the blueprint feature right now, and use Azure Devops to push configuration to tenants. Bear in mind when you use Azure Devops to push you probably won't get the scheduled drift report especially on agents that get recycled.

In terms of authentication we use application with certificate as it seems the most widely supported authentication type across the different resources, and allows administrators to approve the API permissions we request. We have a Devops pipeline that runs under a service principal which has access to get the application certificate from a Key Vault.

It seems M365DSC does not check for dependencies yet (?), at least not for certain things. Example: create a CA policy containing ToU. Branding. Or, Entra users must be created before groups can be created. Do you have recommendations on how to deal with these dependencies?

We're handling the deployment using configurations per component. For example a configuration for groups, a configuration for conditional access policies etc. We have written a script to control the order of deployment, and that can be controlled by a data file which can be added to over time. I've seen mention in these issues of the DSC DependsOn functionality, which is another way of doing this.

from microsoft365dsc.

Awesome feedback, thanks. 👍 I agree - happy to have this conversation for the benefit of everyone. That's why I tried kicking it off here.

We have removed all the GUIDs from our exports, for example, objectIDs. We then ran the DSC on a new tenant to see what works and doesn't. We're still fairly early on in this process, but its quite doable. We are taking tenants with existing configuration. We are finding its giving us an opertunity to clean up configuration inconsistencies, for example conditional access policies that are assigned direct to user GUIDs rather than groups.

So it's safe to assume that resources created without an ID handed over will get new GUIDs?
Conversely, If we leave the GUIDs in, will new resources always receive the GUID we pass?
(I can imagine support scenarios where having well-known GUIDs is helpful)

Our target / client tenants will all follow an identical (!) blueprint/baseline. Any suggestions how we should connect/authenticate/push/pull with hundreds of tenants? Will that scale with Azure DevOps pipelines?

We're not using the blueprint feature right now, and use Azure Devops to push configuration to tenants. Bear in mind when you use Azure Devops to push you probably won't get the scheduled drift report especially on agents that get recycled.

Yeah - we thought of that caveat too. But we're willing to retrieve existing configs and manually/locally compare for drift. Be we don't expect much drift anyways. Our customers don't have their own admins - they have us. So chances of configs changing are very very low.

In terms of authentication we use application with certificate as it seems the most widely supported authentication type across the different resources, and allows administrators to approve the API permissions we request. We have a Devops pipeline that runs under a service principal which has access to get the application certificate from a Key Vault.

Cool, we were thinking the same.
So you use one pipeline to deploy to multiple tenants? Or an individual pipeline for each tenant?
The Youtube tutorial seems to map a cert thumbprint via Key Vault to a pipeline, but I don't think that scales to dozens or hundreds of tenants/pipelines, does it?

It seems M365DSC does not check for dependencies yet (?), at least not for certain things. Example: create a CA policy containing ToU. Branding. Or, Entra users must be created before groups can be created. Do you have recommendations on how to deal with these dependencies?

We're handling the deployment using configurations per component. For example a configuration for groups, a configuration for conditional access policies etc. We have written a script to control the order of deployment, and that can be controlled by a data file which can be added to over time. I've seen mention in these issues of the DSC DependsOn functionality, which is another way of doing this.
Thinking that here, too. Probably best to use some human logic to control dependencies for now.

from microsoft365dsc.

So it's safe to assume that resources created without an ID handed over will get new GUIDs? Conversely, If we leave the GUIDs in, will new resources always receive the GUID we pass? (I can imagine support scenarios where having well-known GUIDs is helpful)

In most cases where an ObjectID field is present that will be taken by the tool as an assertion to look up the resource by the ID and fail if its not present. If that field is missing then the resource is looked up by name and if required a new one will be created. As you haven't provided a specific example I can't get specific but we're trying to remove the use of any guids in the configuration wherever possible. Its worth playing round with this to identify where you will need to use guids in your specific configurations. Remember I'm also still working only on EntraID.

We're willing to retrieve existing configs and manually/locally compare for drift. Be we don't expect much drift anyways. Our customers don't have their own admins - they have us. So chances of configs changing are very very low.

Our scripts currently do a configuration export and then runs the compare cmdlet which generates a delta report so we can see what has been changed on a PR. We have had some really good feedback from the community on potentially improving this, see issue #4488.

So you use one pipeline to deploy to multiple tenants? Or an individual pipeline for each tenant? The Youtube tutorial seems to map a cert thumbprint via Key Vault to a pipeline, but I don't think that scales to dozens or hundreds of tenants/pipelines, does it?

We're doing it like the Youtube tutorial. We have only a few tenants and currently do that using pipeline stages and variables.

from microsoft365dsc.

Adding some $0.02 from a previous life living in an MSP world and wider convos with MS around some of the points above:

1. First and foremost not trying to push you away from M365DSC have you looked at M365 Lighthouse which is meant to allow MSPs to apply configuration across multiple tenants. Never used it in anger but may be an easier on ramp for standardised config across multiple customers
2. The Whitepaper around using AzureDevOps supports the concept of having multiple dev/preprod/prod tenants to manage configuration but the extension of the code and devops pipeline doesnt fully extend to implementing that capability. The Datafiles concept does allow you to define multiple tenants and extending the module included in the sample files of the whitepaper allows you to build DSC configuration for more than one tenant and apply using DevOps pipelines
3. Some things should NOT exist in DSC - whilst you could have a foreach ($AADUser in $ConfigurationData.NonNodeData.AzureAD.AADUser) { this could grow to a large state file and lead to problems when you come to apply config or run across multiple tenants/customers. Think about what core things you want to apply to all or some customers and build the relevant baselines into the M365Config module in the Whitepaper samples and then look at some foreach logic where you need to scale out
4. Consider the use of PowerShell variables in your Datafiles for each tenant so that when the DSC resources are compiled you can substitute in the variable into the standardised policy this should enable you to be more efficient in the view to running same config across multiple tenants with certain changes
5. Scaling considerations are not addressed in the Whitepaper but @William-Francillette does call out some considerations in his blog around scaling DSC related resources. I haven't experimented with whether its possible to use self-hosted pipelines to do this but have been playing with how to automate the deployment of M365 whitepaper resources to support multiple tenants. Managed Identity sounds like the nirvana for resources in the "home" tenant where you run M365DSC from but not sure that would logically scale across multiple customer tenants. Similarly having to deploy a pipeline agent in each customer's Azure subscription doesn't make sense either if they are smaller customers as they wont see the cost / value for this

If you do decide to go the DSC route would love to see some real world patterns and examples on how it can run, my MSP days are behind me but the logic for how it could be used more dynamically looks great

from microsoft365dsc.

Adding some $0.02 from a previous life living in an MSP world and wider convos with MS around some of the points above:

1. First and foremost not trying to push you away from M365DSC have you looked at M365 Lighthouse which is meant to allow MSPs to apply configuration across multiple tenants. Never used it in anger but may be an easier on ramp for standardised config across multiple customers

Yeah, we did. M365 Lighthouse seems woefully inadequate in almost every which way imagineable. That's why we're looking at M365DSC. Some examples:

1. Seems to cover Intune policies only. Worse: Very limited as to custom CSPs, Settings Catalog and App management.
2. No obvious way to configure EXO, SPO, Teams, M365 app policies, Purview or Defender.
   Our baseline contains over 800 settings that we apply to each new tenant in order to max out M365 Business Premium. Lighthouse doesn't even come close to that. Given how long it's been around and the IMHO rudimentary state it is in, I don't feel confident MSFT will continue developing it. Especially since it's free. (I worked at MSFT, I sort of get how they work)

2. The Whitepaper around using AzureDevOps supports the concept of having multiple dev/preprod/prod tenants to manage configuration but the extension of the code and devops pipeline doesnt fully extend to implementing that capability. The Datafiles concept does allow you to define multiple tenants and extending the module included in the sample files of the whitepaper allows you to build DSC configuration for more than one tenant and apply using DevOps pipelines
3. Some things should NOT exist in DSC - whilst you could have a foreach ($AADUser in $ConfigurationData.NonNodeData.AzureAD.AADUser) { this could grow to a large state file and lead to problems when you come to apply config or run across multiple tenants/customers. Think about what core things you want to apply to all or some customers and build the relevant baselines into the M365Config module in the Whitepaper samples and then look at some foreach logic where you need to scale out
4. Consider the use of PowerShell variables in your Datafiles for each tenant so that when the DSC resources are compiled you can substitute in the variable into the standardised policy this should enable you to be more efficient in the view to running same config across multiple tenants with certain changes
5. Scaling considerations are not addressed in the Whitepaper but @William-Francillette does call out some considerations in his blog around scaling DSC related resources. I haven't experimented with whether its possible to use self-hosted pipelines to do this but have been playing with how to automate the deployment of M365 whitepaper resources to support multiple tenants. Managed Identity sounds like the nirvana for resources in the "home" tenant where you run M365DSC from but not sure that would logically scale across multiple customer tenants. Similarly having to deploy a pipeline agent in each customer's Azure subscription doesn't make sense either if they are smaller customers as they wont see the cost / value for this

Just found that DSC/DevOps Whitepaper folks have mentioned. Easy to overlook on the site IMHO. 😉 Will take a closer look at it. Thanks!

If you do decide to go the DSC route would love to see some real world patterns and examples on how it can run, my MSP days are behind me but the logic for how it could be used more dynamically looks great
tbh. We wouldn't mind BUYING a solution that is more user friendly - as we'll need to keep a support team ready and onboarding them will be easier if they don't need to learn M365 and DSC sausage making with PowerShell first. But we couldn't find a product/solution that is suitable for us yet. Either WAY too expensive or severely limited functionality or high complexity or all combined. So right now, this seems the least evil for us. 🤣

from microsoft365dsc.