M365DSC Prerequisites - Install module as Admin in Machine scope

[Kierow]

Hello guys,

Firstly, thanks for the good job you do every single day on M365DSC! It's a very powerful product.

I'm opening this issue because I'm trying to get some clarifications/explanations.

For the context, we were using M365DSC version 1.23.1206 in order to make configuration exports (and reports) from our tenants. The M365DSC module and its dependencies were stored in the WindowsPowershell module location of the service account, the certificate used was stored in the personal certificate store of the service account and the scripts were run through scheduled tasks using this service account.

Recently, we have updated M365DSC to its last version and it seems that now, one of the prerequisites of M365DSC is to install the module in the machine scope. At least, it seems required for some resources (not for all...), but this was not the case before.

For example, when generating an HTML report for the AADAuthenticationMethodPolicy resource, I have seen that it's necessary to have the Microsoft365DSC module in the machine scope (exemple: C:\Program Files\WindowsPowerShell\Modules), otherwise Get-CimClass in DSCParser fails with the following error: The PowerShell DSC resource MSFT_XXX from module <Microsoft365DSC,XXXX> does not exist at the PowerShell module path nor is it registered as a WMI DSC resource --> we have this error if the Microsoft365 module is in C:\Users\ServiceAccount\Documents\WindowsPowerShell\Modules for example.

Is that normal/new?
Do you have other examples where it's required to have the Microsoft365DSC module in the machine scope?

---

Another question. Our server (where M365DSC runs) is used to run several scripts PowerShell scripts. Before, as we had the M365DSC module and its dependencies in the user profile of the service account, it was not an issue to update the M365DSC module and its dependencies.
But now, if it's a prerequisite to store the M365DSC module and it's dependencies in the machine scope, it means that update the modules will impact all the scripts that use these modules. Moreover, if someone update the modules in the machine scope, it will impact M365DSC...

How would you manage a such constraint? How would you perform the M365DSC updates?

Thanks in advance for your answers and keep up the great work! 👍

[FabienTschanz]

@Kierow According to the installation guide, only installing Microsoft365DSC in machine scope is supported. I know that's unfortunate, but necessary. I don't know if that's something new, but since I'm working on it for probably the last year or so, it has been that way.

It's also recommended to use the Microsoft365DSC stuff on a separate server instance or worker machine so that there are no dependencies to other things running on the same worker. I'm not sure who wrote that, but I got that advice from one of the other contributors here as well (I believe it was @andikrueger).