Add repair feature of ConfigMgr 1810

[ABitBA]

It would be nice to get the repair feature supported in PSADT.

https://www.imab.dk/repairing-broken-applications-using-software-center-and-sccm-1810-system-center-configuration-manager/

“Deploy-Application.exe -DeploymentType repair”

Thank you for this great Tool.

[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.

[Francois]

Function AddSourceList {
<#
.SYNOPSIS
Ajoute un chemin au sourcelist d’un MSI
.DESCRIPTION
Ajoute un chemin au sourcelist d’un MSI
.Parameter
Str_MSIPathAndFile
Donner un chemin complet d’un MSI incluant le nom du fichier. Le
MSI doit se trouver dans le répertoire.
.EXAMPLE
AddSourcelist MSI
#>
[CmdletBinding()]
param(
[Parameter(Mandatory=$true)]
[string]$Str_MSIPathAndFile
)
Begin {
## Get the name of this function and write header
[string]${CmdletName} = $PSCmdlet.MyInvocation.MyCommand.Name
Write-FunctionHeaderOrFooter -CmdletName ${CmdletName} -CmdletBoundParameters $PSBoundParameters -Header
}
Process {

     Try {

         $MSIPath=split-path $Str_MSIPathAndFile
         $ProductCode= Get-MsiTableProperty -Path $Str_MSIPathAndFile
         #$productcode='{09AAAB09-6DBA-4DD9-9865-54597D3FBCA8}'
         #$MSIPath='E:\Temp\Logiciels\Antidote 8\msi\druide'

         $Com_WI = New-Object -ComObject WindowsInstaller.Installer

         $codeInvokeMethod = {
             $type = $this.gettype();
             $index = $args.count - 1;
             $methodargs = $args[1..$index]
             $type.invokeMember($args[0], [System.Reflection.BindingFlags]::InvokeMethod, $null, $this, $methodargs)
         }
         $Com_WI = $Com_WI | Add-Member -MemberType ScriptMethod -Value $codeInvokeMethod -Name InvokeMethod -PassThru

         Try {
            #2017-02-17 FR J'ai modifié cette section car dans certains cas le produit n'aura pas de product code ce qui empêche un repair et génère une erreur. Je teste donc la présence du product code avant quoi que ce soit
            #Et génère une inscription dans le log le cas échéant.
             If ($productcode.productcode -ne $null) {
                Write-log "Ajout du Sourcelist $($MSIPath) au MSI $($Str_MSIPathAndFile) Product code $($productcode.productcode)"
                $Com_WI.InvokeMethod('AddSource', "$($productcode.productcode)", '', "$($MSIPath)")
            }
            Else {Write-log "Le product code de $($Str_MSIPathAndFile) est absent. On ne peut pas ajouter un sourcelist.`
                                     Il faut valider si on peut faire une réparation." -Severity 2 -Source $deployAppScriptFriendlyName}
         }
         Catch {
             Write-Log -Message "Failed to resolve registry path [$regKey]. `n$(Resolve-Error)" -Severity 3 -Source ${CmdletName}
             Continue
         }
     }
     catch {
         Write-Log -Message "Failed to resolve registry path [$regKey]. `n$(Resolve-Error)" -Severity 3 -Source ${CmdletName}
         Continue
     }

 }
 End {
         Write-FunctionHeaderOrFooter -CmdletName ${CmdletName} -Footer
     }

}
#************************************************************************************************************
#endregion 2.0 AddSourceList
#************************************************************************************************************

[ABitBA]

Please do not mix the function of msi installation source management with the new 1810 feature.
The msi repair is very limited, no custom steps are possbile. With the new 1810 feature you can use msi and exe files and add your own custom steps to the repair step.

[g4m3c4ck]

Adding a section for repair to Deploy-Application.ps1 would be easy. I was trying to point out that it would not work all of the time if the sources are orphaned.

Adding this un-tested ElseIf code to should do the trick. I will try to test it later today.

ElseIf ($deploymentType -ieq 'Repair')
{
	##*===============================================
	##* PRE-REPAIR
	##*===============================================
	[string]$installPhase = 'Pre-Repair'

	## Show Progress Message (with the default message)
	Show-InstallationProgress

	## <Perform Pre-Repair tasks here>

	##*===============================================
	##* REPAIR
	##*===============================================
	[string]$installPhase = 'Repair'

	## Handle Zero-Config MSI Repairs
	If ($useDefaultMsi) {
		[hashtable]$ExecuteDefaultMSISplat =  @{ Action = 'Repair'; Path = $defaultMsiFile; }; If ($defaultMstFile) { $ExecuteDefaultMSISplat.Add('Transform', $defaultMstFile) }
		Execute-MSI @ExecuteDefaultMSISplat
	}
	# <Perform Repair tasks here>

	##*===============================================
	##* POST-REPAIR
	##*===============================================
	[string]$installPhase = 'Post-Repair'
	
	## <Perform Post-Repair tasks here>


}

[g4m3c4ck]

The code above did not work without some other minor changes.

Line 43 Needs to be changed to:

[ValidateSet('Install','Uninstall','Repair')]

And line 113 needs to be changed to:

If ($deploymentType -ine 'Uninstall' -and $deploymentType -ine 'Repair') {

With these changes -DeploymentType Repair will work with the PSADT.

[ABitBA]

Hi g4m3c4ck, thanks for the code. I thought something need to be changed in the code of the deploy-application.exe before the repair part will work. I will try it later and give you a feedback. thanks

[g4m3c4ck]

I would like to see it officially added to the project so I submitted the change with a working Deploy-Application.ps1 to an open issue on github here.

Issue: Create "Repair" Deployment Type