Dependencies on beta MS graph about microsoft365dsc HOT 5 OPEN

Looks like dependencies will at least be updated soonish but yeah, mixing and matching is problematic. if you for example use the Microsoft.Graph.Sites Module module in 2.16 and run the Uninstall-M365DSCOutdatedDependencies it will kill dependencies for the module since it relies on the Microsoft.Graph.Authentication being the same version (2.16) where as M365DSC uses 2.15.

from microsoft365dsc.

Looks like dependencies will at least be updated soonish but yeah, mixing and matching is problematic. if you for example use the Microsoft.Graph.Sites Module module in 2.16 and run the Uninstall-M365DSCOutdatedDependencies it will kill dependencies for the module since it relies on the Microsoft.Graph.Authentication being the same version (2.16) where as M365DSC uses 2.15.

Yeah, it should work on the newer releases as we do have other scripts running which are dependent on latest graph versions. And as a result, the scripts breaks.

from microsoft365dsc.

@NikCharlebois @ykuijs @andikrueger can you please assist here.

from microsoft365dsc.

Hi @jagatjb, some of the settings that we want to manage are not (yet) available in the v1.0 version of the Graph API, but are in the Beta version. That is why we are using the Beta modules. As soon as the settings are also available in the released API, we can switch to the normal version of the modules. However that is something we currently do not automatically detect. So if you see there are scenarios where the Beta module can be replaced by the v1 version, please let us know.

Regarding your second question:
We have seen instances in the past where different versions of the modules were causing conflicts. That is why we have created two cmdlets:

1. Update-M365DSCDependencies: This installs all the correct version of all required modules.
2. Uninstall-M365DSCOutdatedDependencies: This removes all versions of the required modules, with the exception of the required version.

So if you run the first cmdlet, v2.15 will be installed but v2.16 will be left untouched. As soon as you run the second cmdlet, the v2.16 will be deleted, making sure v2.15 is the only installed version.

from microsoft365dsc.

Hi @jagatjb, some of the settings that we want to manage are not (yet) available in the v1.0 version of the Graph API, but are in the Beta version. That is why we are using the Beta modules. As soon as the settings are also available in the released API, we can switch to the normal version of the modules. However that is something we currently do not automatically detect. So if you see there are scenarios where the Beta module can be replaced by the v1 version, please let us know.

Regarding your second question: We have seen instances in the past where different versions of the modules were causing conflicts. That is why we have created two cmdlets:

1. Update-M365DSCDependencies: This installs all the correct version of all required modules.
2. Uninstall-M365DSCOutdatedDependencies: This removes all versions of the required modules, with the exception of the required version.

So if you run the first cmdlet, v2.15 will be installed but v2.16 will be left untouched. As soon as you run the second cmdlet, the v2.16 will be deleted, making sure v2.15 is the only installed version.

Thanks a lot for your input here. I have another question regarding this.

Lets say I already have v2.16 installed in my server and it is being used to run some scripts. Now I install the M365 DSC module which has the dependency of v2.15. In this case, the v2.15 will get installed and then the M365 DSC module cmdlets will not run as there is a conflict which can be managed by Uninstall-M365DSCOutdatedDependencies. Since v2.16 is the latest one, don't you think it should detect and use the latest graph module instead of installing the previous version of graph, ie. v2.15 ?

So in such cases, the other scripts which are already using v2.16 should be left untouched.

from microsoft365dsc.