Update-M365DSCDependencies: ... does not support PowerShell Core

[fasteiner]

Description of the issue

When running the update Dependencies command in PowerShell Core this happens:
14:22:46 WARNING: The dependency {Az.Accounts} does not support PowerShell Core. Please run Update-M365DSCDependencies in Windows PowerShell.
14:22:46 WARNING: The dependency {Az.ResourceGraph} does not support PowerShell Core. Please run Update-M365DSCDependencies in Windows PowerShell.
14:22:46 WARNING: The dependency {Az.Resources} does not support PowerShell Core. Please run Update-M365DSCDependencies in Windows PowerShell.
14:22:46 WARNING: The dependency {Az.SecurityInsights} does not support PowerShell Core. Please run Update-M365DSCDependencies in Windows PowerShell.
14:22:46 WARNING: The dependency {ExchangeOnlineManagement} does not support PowerShell Core. Please run Update-M365DSCDependencies in Windows PowerShell.
14:22:48 WARNING: The dependency {Microsoft.PowerApps.Administration.PowerShell} does not support PowerShell Core. Please run Update-M365DSCDependencies in Windows PowerShell.
14:22:48 WARNING: The dependency {MicrosoftTeams} does not support PowerShell Core. Please run Update-M365DSCDependencies in Windows PowerShell.

All of this modules are PowerShell Core compatible, therefore you must have a mistake in your dependencies.

Also, this requires me to install the module as administrator, which is not favorable and also I wonder why the Scope switch is being ignored again?

I'll try downgrading now, but this needs to be fixed!

Microsoft 365 DSC Version

1.24.1113.1

Which workloads are affected

other

The DSC configuration

n/a

Verbose logs showing the problem

n/a

Environment Information + PowerShell Version

OsName               : Microsoft Windows Server 2019 Standard
OsOperatingSystemSKU : StandardServerEdition
OsArchitecture       : 64-bit
WindowsVersion       : 1809
WindowsBuildLabEx    : 17763.1.amd64fre.rs5_release.180914-1434
OsLanguage           : en-US
OsMuiLanguages       : {en-US}

PS C:\Users\svsteiner>
PS C:\Users\svsteiner> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.4.6
PSEdition                      Core
GitCommitId                    7.4.6
OS                             Microsoft Windows 10.0.17763
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[fasteiner]

last working version: 1.24.626.1

[FabienTschanz]

@fasteiner This is not a problem but expected behavior. Microsoft365DSC only supports the use case where the PowerShell modules are installed under C:\Program Files\WindowsPowerShell\Modules... path. This is due to internal restrictions in using the Cmdlets, but you can still use PowerShell 7 without problems. The only thing you have to take into consideration is to update the modules from inside Windows PowerShell (running as an administrator).

We do understand that this might not be beneficial for all, but it's the only supported way to use Microsoft365DSC.

[fasteiner]

@FabienTschanz Up to version 1.24.626.1, this module was fully supported in PowerShell Core, which aligned well with our automation environment. However, with its integration into our PowerShell 7-only workflows, we are now faced with the challenge of transitioning away from this module due to the decision to discontinue support for PowerShell Core.

This decision is perplexing, given that the module had already achieved full compatibility with PowerShell 7. Moving backward in compatibility undermines advancements and forces us to sunset this module in favor of developing our own implementation—a decision that is both time-consuming and resource-intensive.

We encourage reconsideration of this approach to ensure continuity and compatibility for users who rely on modern PowerShell environments.

[FabienTschanz]

@fasteiner As a fellow engineer, I fully understand your situation. I personally am also not happy with that, so I'll take it up on myself and check what we from the community can do to make it fully compatible with PowerShell Core. But this will take time since I'm only working on this module in my own free time as a contributor and not a fully-fledged member.

One thing I would like to mention here: I was the one who updated the module to "only" allow installation of the required modules within Windows PowerShell. This is because of some dependencies and statements that Microsoft365DSC requires the modules to be installed in the Windows PowerShell module directory. Why that is, and what this requirement is still a hard dependency, is something I'm not aware of. I will take a look and start my preparations.

One question at last: Running Update-M365DSCDependencies in Windows PowerShell installs all the modules there, and then they are also available inside of PowerShell Core because PowerShell Core considers modules from the Windows PowerShell. For now, isn't it possible for you to simply run the update command in Windows PowerShell and afterwards switch to PowerShell Core?

[fasteiner]

@FabienTschanz
that's nice to hear!

Ok, but the module worked before that requirement was introduced (at least in PowerShell 7), would it make sense to revert back to the state where this was not required to be installed in Windows PowerShell?

regarding your question:

I tried that unfortunately, running in PowerShell Core still was not possible:

Therefore, I switched to an older version.

[FabienTschanz]

@fasteiner Backwards compatibility is essential for modules this big. It's not easy to introduce something new without breaking things in a completely different location. The best example is PnP.PowerShell, the current module version requires PowerShell 5.1 and does not work with PowerShell 7, however if we were to update to a newer version, we would kill support for PowerShell 5.1 and require e.g. 7.2. That has to be done with a breaking change release and is not feasible unless we introduce new major functions... Currently, that's not in sight.

What I think could work: If we are running in PowerShell Core and no modules are present, we can install them in the current environment (except of PnP.PowerShell which requires it to be installed in PowerShell 5.1). I'm not sure how that would be handled by PowerShell Core if the modules are both present in 5.1 and Core, that's something that we need to take a look at.

Edit: What's the output of Get-Module XYZ -ListAvailable when run in PowerShell Core, XYZ to be replaced with the modules that need updating? Were they all installed within PowerShell 5.1?

[FabienTschanz]

@fasteiner With the latest release, you'll only have to install the PnP.PowerShell module in version 1.12.0 in the Windows PowerShell context. The other modules can be installed in PowerShell Core (using Update-M365DSCDependencies or Update-M365DSCModule).