Add repair feature of ConfigMgr 1810

[g4m3c4ck]

I came here needing this exact same thing. It is possible others have ran into the same issues as me.

For us, sometimes the installer source path is no longer present on the system. In our imaging process our CCMCache gets removed when preparing the ConfigMgr client, thus orphaning the MSI source.

Wouldn’t be a big deal if ConfigMgr’s Windows Source Management worked properly with PSADT.
This update cycle sets the “HKLM\Software\Classes\Installer\Products[Package_GUID]\SourceList\URL\1” location to the base content source path and does not include the “Files” subfolder in the PSADT.

So when a repair is ran it does not know the correct fallback URL of source .MSI and prompts the user for the path.

This is really a ConfigMgr shortcoming when using script installer technology and kind of a problem generated by using the PSADT.

Others have eluded to this issue in these posts.

Adding Sourcelist for MSI Repair

Sometimes instead uninstalling MSI, a simple repair would be the best. When distributing your application the sources will become unavailable once the local cache will become empty. So the repair will not work. A solution would be to make the MSI available somewhere. But how making the MSI “knowing” the sources are available somewhere? In the registry, go to HKCR\installer\Products<product code of the product>\sourcelist\net You will notice where the Windows Installer will look to find the…

MSI SourceList using ConfigMgr DP

Hi Everyone, MSIs are not able to repair when the MSI file(s) are located under the Files sub-folder when using ConfigMgr DP as alternate repair source. The reason is because the content source in ConfigMgr is set to the root folder of the PowerShell Application Deployment folder structure which has the MSI file under the Files. When ConfigMgr is set to be a fallback source for MSI deployments, a URL path the DP content source is added to the source list for MSI resiliency. the repair does no…

ConfigMgr will update the URL subkey if the MSI product code is added under Windows Source Management for the Application Deployment Type. But on the client machine this gets set to “http://DistributionPoint.domain.com/sms_dp_smspkg$/ContentId” which as I said before is the base content location. But in PSADT scripts the .MSI is located in the “Files” subfolder.

In my tests adding this sub folder to the end of the URL fixes the broken source and repairs can then be ran.

One solution would be to change the PSADT script to look for the MSI in the root folder. This would fix the issue with running repair and ConfigMgr could fix the source list. But I am sure this could present additional issues.

Another temp solution would be to copy the .MSI into the root subfolder as well. But this is really not desirable either.

If the PSADT had new deployment type of repair the issue would only be partially addressed.

In order to run a repair the following syntax is needed:
msiexec /af {ProductCode}

The following syntax will still prompt for missing source files if the Net and Url subkeys do not contain the Msi.
msiexec /af “FilePathToMsi”

So the missing installer source path still needs to be fixed. Fixing this path could be scripted in a new “repair” DeploymentType in the PSADT.
But the Product Code would have to be defined in the ConfigMgr Deployment type and the Windows Source List Update cycle would need a previous run on the client. Then the PSADT would need to find the URL subkey and add “Files” to it.

You effectively have a broken install source until a repair is executed from software center.
This means future installs and uninstalls of the MSI will fail until this has executed.

I would like other peoples input including the developers on this scenario.