Install-M365DevBranch failing - path too long

[martincaddick]

ver 1.23.405.1

With default temp location (incl 14 character username in my case) the unzip fails as the path is too long for MSFT_IntuneDeviceConfigurationHealthMonitoringConfigurationPolicyWindows10.schema.mof.

Changing to C:\TEMP allows the Install-M365DevBranch to work correctly

[NikCharlebois]

We will need to look at another approach. Some of these Intune resources' names are a mouthful and there are chances of having some that could be even longer than the one above in the future (let's hope not).

[ykuijs]

I see two possible options:

• Use the system temp (C:\Windows\Temp), which is a little shorted
• Create a temporary folder in the C-root (like C:\M365Dev), use that and clean it up when we are done

In the past I have seen that unpacking Zip files unpacks the file to a temporary folder and then move the files. Since moving files on the same drive moves the permissions along with it, this can cause the files to keep the permissions from the temporary folder and not inherit from the target folder. That can result in the resource not to work, so directly unpacking to the target folder is not an option.

[NikCharlebois]

What would you folks think of dropping support of handling the dev branch via code? I am thinking of simply dropping the Install-M365DevBranch cmdlet all together and let folks download and extract the branch from GitHub. There are multiple concerns with trying to install this in an automated fashion and quite frankly I am not a big fan of having to help troubleshoot this. Also, we have weekly releases so in most cases customers are not installing the dev branch and simply waiting for the weekly release to go out. Thoughts?

[martincaddick]

I agree with the weekly releases, most people would just wait. I know I have on most occasions. A readme or howto would cover a lot. Just a few lines explaining how to clone the Dev branch and then run the updates for dependencies would probably be all we need.

[andikrueger]

I do not see any added value in installing the dev branch. It is easy to clone a repository or create a zip download.

I would remove/deprecate the cmdLet - may print out a link to some page within the M365DSC website, which will outline how to download a zip or clone the reop.

[martincaddick]

How would this effect DRG? Just more doco?

[andikrueger]

Just to get some more context about your DRG usage: how do you use DRG within the Dev branch?

If I use/would use DRG to create a new resource, I would do so within my cloned repository within a new feature branch.

[martincaddick]

Tried it once and haven't gone back to it yet but I was thinking that maybe a good use case is to run it regularly for any resources that haven't been updated in 6 months. Should it then catch changes that MS are making with the underlying cmdlets? Was just looking a couple of hours ago at MSFT_EXOAntiPhishPolicy.psm1 $result and comparing with Get-AntiPhishPolicy.

1. Should they kinda match, and
2. Should DRG pick up the any differences?

[GeldHades27355]

Just ran in to this with V1.24.313 release. Trying to install M365DSC I get the same error. No wonder, as one of the target paths is:

C:\Users\m365dscadmin.SERVER2022\Documents\PowerShell\Modules\Microsoft365DSC\1.24.313.1\DSCResources\MSFT_IntuneDeviceConfigurationDefenderForEndpointOnboardingPolicyWindows10\MSFT_IntuneDeviceConfigurationDefenderForEndpointOnboardingPolicyWindows10.schema.mof

🤯

That is 262 characters, and therefore a path that worked. But according to the error, at least one resource fails to install due to path length.

Same goes for 1.24.605.1.

I'll try to install to a shorter path - but this shouldn't be happening in the first place IMHO.