variables.ps1 fails on detecting InstallationInfoDirectory on the new 10.0.39 VMs

[torbennehmer]

D365fo.tools fails on the newly released 10.0.39 VMs at least on the initial import when parsing variables.ps1, when detecting the installation info directory. The error originates from Line 94ff on variables.ps1.

$RegSplat = @{
    Path = "HKLM:\SOFTWARE\Microsoft\Dynamics\Deployment\"
    Name = "InstallationInfoDirectory"
}

$RegValue = $( if (Test-RegistryValue @RegSplat) { Join-Path (Get-ItemPropertyValue @RegSplat) "InstallationRecords" } else { "" } )
$Script:InstallationRecordsDir = $RegValue

On the 10.0.39 VM the registry key looks like this:

InstallationInfoDirectory : F:\Deployment
PSPath                    : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dynamics\Deployme
                            nt\
PSParentPath              : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dynamics
PSChildName               : Deployment
PSDrive                   : HKLM
PSProvider                : Microsoft.PowerShell.Core\Registry

Drive F: is not available on the HyperV VM, so the subsequent execution fails with an unavailable drive error, excerpt from the debug loading:

My older VM used some folder on C: for this.

Apparently, the process continues, if you load the module a second time in a new shell, the error vanishes, the stored configuration seems to somehow hide the error on subsequent module loadings after the first one immediately after installation. It also has the subsequent side effect, that it won't load a module depending on d365fo.tools for the first time only. Also, the error does not reappear after rebooting the machine.

When rebooting, you again need to try to import the module twice when used as a dependency, so the problem does persist over reboots, it does not fix itself in the configuration of d365fo.tools somehow.

I cannot say, if the information normally gathered from this folder is relevant or might interfere with d365fo.tools operations.

[FH-Inway]

@torbennehmer Thanks for reporting. Also hi :wave:, great to have you here :smile:

@DAXRunBase over on Yammer also noticed this issue (and others) and got feedback from Microsoft on at least this one that they are looking into it. Hopefully, Microsoft will release a new version of the 10.0.39 VHD were this and other issues are fixed.

In the mean time, a script similar to this from @oysbre's D365LocalDevtuning.ps1 (with some minor adjustments by me) can be used to fix the registry entry:

#set Dynamics Deployment folder in registry
if ((Get-ItemPropertyValue HKLM:\SOFTWARE\Microsoft\Dynamics\Deployment -Name InstallationInfoDirectory -ErrorAction SilentlyContinue) -ne "C:\Deployment"){
    Set-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\Dynamics\Deployment -Name InstallationInfoDirectory -Value "C:\Deployment" -Type String
}

In regards to the impact on d365fo.tools when this configuration value cannot be determined, here is a search result that shows all the cmdlets that are using the configuration value: https://github.com/search?q=repo%3Ad365collaborative%2Fd365fo.tools+InstallationRecordsDir+path%3A%2F%5Ed365fo.tools%5C%2Ffunctions%5C%2F%2F&type=code So it is mostly cmdlets for analyzing a runbook after a software deployable package installation (e.g. service update) and Get-D365InstalledService. So while not nice to have those failing, they are reading/analyzing stuff.

For now, I would propose waiting to see if Microsoft will provide a fixed VHD.

[torbennehmer]

Hi @FH-Inway thanks for the welcome, it's great that you're able to support this! Thanks for the pointers, it is indeed frightening, what quality non-standards we see these days from MS, at least partly. Maybe they rely on Copilot nowadays to create the images ... :-) Anyway, the workaround with the Reg Patch works as intended, thanks for the quick response.

[FH-Inway]

Last week, Microsoft release a new version of the 10.0.39 VHD image that has the correct registry setting for InstallationInfoDirectory. I tested it and d365fo.tools can be imported on that version without an issue.

According to Yammer, there still remain issues related to that, but at least this particular issue should be resolved. I will close the issue for now, but feel free to add further comments or create a new issue.