Compare-M365DSCConfigurations and functions that call it have a serious problem about microsoft365dsc HOT 5 CLOSED

Yes, that will also work, please go ahead with the PR since I'm currently busy adding other workarounds to my DevOps pipelines, which by the way is taking around 1h to install the modules and dependencies, last year I had to change Install-Module to Save-Module and it took about 5min, now it's also taking 1h for Save-Module...

from microsoft365dsc.

@ricmestre I don't have a setup for GitHub pipelines, but the issue with the configuration being reported as a complete drift because the naming is a simple GUID should be adressable by prefixing the name with e.g. Export-<GUID>. Visual Studio Code gives me an error when the configuration name does not start with a letter: The configuration name '757e980d-07a0-4393-9ed0-8efd06b772e0' is not valid. Standard names may only contain letters (a-z, A-Z), numbers (0-9), period (.), hyphen (-) and underscore (_). The name may not be null or empty, and should start with a letter.

The second issue you mentioned with the missing types could be related to missing administrative privileges on the target machine. I debugged the ConvertTo-DscObject which calls ConvertFrom-CIMInstanceToHashtable, and that function requires administrative privileges to call Invoke-DscResource to register the CIM type if it does not exist. No idea why it didn't work but suddenly started working again...

And the third one with the Az and Graph modules should be resolved with Az 2.12.0 if I'm not mistaken. Nevertheless, I will have a look at the creation of the Blueprint and check if we can change that to something better, matching the criteria for the parser to have a configuration starting with a letter instead of a number.

from microsoft365dsc.

I'm using Azure DevOps pipelines and they always run with administrative rights and it always worked before, in fact the only way to keep it working with latest M365DSC version is to have a manifest with M365DSC dependencies with a downgraded DSCParser to v1 with which I have no problems with.

The configurations are generated automatically by M365DSC via Assert-M365DSCBlueprint so basically you don't have control over what name to use for the configuration, but even if using GUIDs for the exports it was working with DSCParser v1 without issues, with v2 I get that problem.

I'm aware that the issue between Az and Graph should be resolved with Az 12.0.0, that will be released this week if I'm not mistaken, but their teams don't seem to collaborate when to release and so this problem keeps happening over and over because the modules then use different dlls. Usually I'm able to go around the problem by either instructing the pipeline to either run on a lower or higher Az version, in this case the only workaround I found was to, along with downgrading DSCParser in the manifest, to also downgrade Graph to v2.17.0.

from microsoft365dsc.

The problem selecting a GUID for the configuration name starts here, you might get lucky and the filename of the export is a GUID that starts with a letter and so it's fine, but might start with a number and you're in trouble. Maybe we need to add a check if the filename starts with a number to append a prefix like "M365TenantConfig" which happens a few lines afterwards on L359.

from microsoft365dsc.

@ricmestre Don't think we have to go that far. Simply calling Export-M365DSCConfiguration -FileName XYZ inside Assert-M365DSCBlueprint with a name that does not start with a number should be enough, as it should be known that a configuration must start with a letter.

Updating the references for $TempExportName and $TempBluePrintName should be enough. If you want, I can provide a pull request in a couple of minutes that addresses that, as I've already verified that it does what it's supposed to do.

from microsoft365dsc.