Open clajes opened 7 months ago
Could you share a bit of your pipeline? Running
install-module Microsoft365dsc Update-M365DSCDependencies
should do it. Would be interesting to see why this does not succeed within your pipeline.
I bet it's a mix of not uninstalling the already existing modules of what's in the container. A lot of times you'll find a problem with the current version of the Az modules which you have to downgrade or you'll have several problems, usually I solve those by downgrading the Azure tasks to a version that works with that specific version of MSGraph.
Could you share a bit of your pipeline? Running
install-module Microsoft365dsc Update-M365DSCDependencies
should do it. Would be interesting to see why this does not succeed within your pipeline.
I agree, I have had it working only using the two commands you show, but suddenly it stopped working and only by debugging, I found that explicit installing the extra module helped. The stage that gives errors is the one where I export CA policies as shown below
stage: ExportCAPolicies jobs:
steps:
task: AzureKeyVault@2 inputs: azureSubscription: 'M365DSCConnection' KeyVaultName: 'CJM365DSCKeyVault' SecretsFilter: '*' RunAsPreJob: false
checkout: Self persistCredentials: true
task: PowerShell@2 inputs: targetType: 'filePath' filePath: 'exportcapolicies.ps1' arguments: -m365dsccacert $(m365dsccacert) -m365dscsigningcert $(m365dscsigningcert) -accesstoken $(System.AccessToken)
it is the exportcapolicies.ps1' powershell script that has the two command with install/update modules and it fails when exporting CA policies using Export-M365DSCConfiguration -mode full -CertificateThumbprint $m365configcertThumbprint -ApplicationId $AppID -TenantId $TenantID -Components @("AADConditionalAccessPolicy") -path $exportfolder
I bet it's a mix of not uninstalling the already existing modules of what's in the container. A lot of times you'll find a problem with the current version of the Az modules which you have to downgrade or you'll have several problems, usually I solve those by downgrading the Azure tasks to a version that works with that specific version of MSGraph.
Thanks, but in this case, I don't know exactly what is installed in the container related to PowerShell and Graph and hence unsure about what to uninstall, and it was working fine, and suddenly something changed.
Could you run
Get-Module -ListAvailable
in an empty pipeline. We have seen similar issues in the past in Automation Accounts and Pipeline. Begin of this year there were some updates of the added modules.
Could you run
Get-Module -ListAvailable
in an empty pipeline. We have seen similar issues in the past in Automation Accounts and Pipeline. Begin of this year there were some updates of the added modules.
Thanks for your suggestion. I managed to get it to work by first uninstalling all microsoft.graph based modules doing the following in my script
$modules = Get-Module -ListAvailable | Where-Object { $_.Name -like "Microsoft.graph*" } foreach ($module in $modules) { Write-Host "Uninstalling $($module.Name)" Uninstall-Module -Name $module.Name -Force }
Install-Module -Name Microsoft365Dsc -force -AllowClobber Update-m365dscdependencies Import-Module Microsoft365Dsc
and now it works with the standard two Micosoft365DSC module commands. However it does increase the execution time for the pipeline a lot, so not optimal.
Absolutely agree on the runtime. It is not ideal. I used to include a stable version of M365DSC and its dependencies in my repository and just copy them over into the pipeline. This will solve the install time issue, but not the compatibility issue of other module's version being present.
@ykuijs Is there any option available to fix the versions for dependencies within our code somehow - like loading the modules with a defined version (dependencies.psd1) into the runspace?
Have you tried running the Uninstall-M365DSCOutdatedDependencies cmdlet? That should remove all dependencies that aren't specifically listed as required.
One of the issues here is the Module Autoloading of PowerShell. That should always use the most recent version of a module, but I have seen strange behavior where PS loaded a different version than expected. That is why we added the Uninstall cmdlet, to make sure just the required version is present.
Have you tried running the Uninstall-M365DSCOutdatedDependencies cmdlet? That should remove all dependencies that aren't specifically listed as required.
One of the issues here is the Module Autoloading of PowerShell. That should always use the most recent version of a module, but I have seen strange behavior where PS loaded a different version than expected. That is why we added the Uninstall cmdlet, to make sure just the required version is present.
Thanks a lot, that helped. It worked and reduced time to export as opposed to uninstalling all microsoft.graph related modules.
Description of the issue
I am using latest Microsoft365dsc module and experience that I get some errors, when I use
Export-M365DSCConfiguration -mode full -CertificateThumbprint $m365configcertThumbprint -ApplicationId $AppID -TenantId $TenantID -Components @("AADConditionalAccessPolicy") -path $exportfolder
I debugged it and found that installing some extra modules in the pipeline script helped as shown below. Previously that has not been needed. I typically only install the Microsoft365Dsc module and update dependencies. For now, I have the following to get it working.
Install-Module -Name Microsoft365Dsc -force -AllowClobber install-module microsoft.graph.identity.SignIns -force install-module Microsoft.Graph.Identity.DirectoryManagement -force install-module Microsoft.Graph.Beta.Identity.DirectoryManagement -force install-module Microsoft.Graph.Beta.Identity.SignIns -force install-module Microsoft.Graph.Identity.Governance -force install-module Microsoft.Graph.Beta.Identity.Governance -force Update-m365dscdependencies
Microsoft 365 DSC Version
1.24.228.1
Which workloads are affected
Azure Active Directory
The DSC configuration
Verbose logs showing the problem
Environment Information + PowerShell Version
No response