:sparkles: fix ErrorActionPreference error during installation of Microsoft update on VHD based environment

[FH-Inway]

If a deployable package of a Microsoft update is installed on a VHD based T1 environment, an error containing the key word ErrorActionPreference may occur during the Sync Ax database step.

This issue exists since version 10.0.4. I think it is time to fix it :)

Recently, Microsoft acknowledged the issue and says it is caused because of a missing dependency in the runbook. See the following links for more information:

• https://www.yammer.com/dynamicsaxfeedbackprograms/threads/640290484641792
• https://www.yammer.com/dynamicsaxfeedbackprograms/threads/405123886243840

Microsoft proposes as a workaround to patch the script of the update package that causes the issue. This could be included in the Invoke-D365SDPInstall cmdlet.

[Splaxi]

The first link is in private group, that I'm not part of. The second gives me an idea - but I'm not quite sure how to solve it.

@FH-Inway - Do you have any ideas to share with us, so we can work out a solution for this?

[FH-Inway]

I copied the relevant part of the first link into the second link. We have implemented the first solution option mentioned there (patching the script to add a command that starts the required service) in our internal tooling. Did you have the same idea or do you want to try something else?

[Splaxi]

If we were to update/patch the script - how would you do it?

Have a standalone cmdlet for fixing the script? And run the install afterwards? This way we can backup the script and restore it, if needed.

[FH-Inway]

For our internal tooling, we kinda cheat and use patch. Our repository contains the patch file that patch needs to update the script.

Since patch does not seem to have a dedicated installer for Windows, we install UnxUtils, which contains it and many others (including diff, which is used to create the patch file).

The question is, do we want to take a dependency with the d365fo.tools (or at least the Invoke-D365SDPInstall cmdlet) on patch/UnxUtils? Or do we implement a PS version of patch? Or not bother with patch at all and just add the whole AutoDeployReportAndDBSync.ps1 to the d365fo.tools and replace the whole script?

As for when to do the patch: I was thinking about a switch parameter for Invoke-D365SDPInstall, e.g. -PatchScripts. The help for the parameter could then explain to the user what scripts are being patched and that they may need to install patch/UnxUtils to do it. A separate cmdlet could be used to undo the patch, or the help for the switch could explain how to do it with patch.

[Splaxi]

I would like to avoid more dependencies, if possible.

Looking at what we need to support, is that we might have several different versions / fixes for n-1 files. We could have some kind of mapping, that listed what files were connected to what issue.

This could then be extended over time, as things evolve - including being depreciated when we know for sure that the issue has been fixed permanently.

I envision the follow cmdlets:

• Get-D365SdpScriptFix
  • Lists all available fixes, including details and a link to a more in-depth explanation, hopefully directly to the different yammer threads / blog posts / wiki pages
• Backup-D365SdpScriptFix -Id X
  • X being the specific id that we have assigned to a given fix, so people can either do some pipeline / filtering, and then call this cmdlet
  • The backup will be stored with the Id as the folder name, to make it easier when we want to recover the files / restore them
• Invoke-D365SdpApplyFix -Id x
  • X being the specific id that we have assigned to a given fix, so people can either do some pipeline / filtering, and then call this cmdlet
• Restore-D365SdpScriptFix -Id X
  • X being the specific id that we have assigned to a given fix, so people can either do some pipeline / filtering, and then call this cmdlet
  • The cmdlet simply locates the backup, based on the folder name and id, and re-applies the files

How does that sound for you?

[FH-Inway]

Hm, I don't know, it sounds like quite some work, just to patch one script. Don't get me wrong, the reasoning for each cmdlet is sound. I just wonder if it is a bit overkill? Do you think there will be more scripts that we will have to manage like this? We should also take into account that we may have to manage different versions of the same script. The AutoDeployReportAndDBSync.ps1 script has been changed by MS at least once since I'm tracking this issue.

[Splaxi]

I know - I'm closer to saying that people need to fix it themselves and roll their own solution, than we having to extend the module to support something that is considered a bug or a broken state of the product itself.

You could blog about your findings, and share that with the world - then we could point towards that, whenever people having issues in that regard.

[FH-Inway]

Yeah, I was thinking along the same lines. Will update this with a link when I get the chance to write something up. Otherwise closed.