Troubleshooting Windows Installer Source List Update Failures in Configuration Manager

Table of Contents

This article addresses a specific issue encountered in Microsoft System Center 2012 Configuration Manager and later versions, where the Windows Installer source list fails to update correctly when clients communicate with distribution points (DPs) using HTTPS. This scenario can impact the ability of clients to perform repair operations or apply patches to applications deployed via Windows Installer (MSI) packages, as the system cannot locate the required installation source files. Understanding the underlying mechanism and potential workarounds is crucial for maintaining application health and patchability in environments utilizing secure HTTPS communication.

Configuration Manager relies on distribution points to deliver content, including application and package source files, to client computers. Clients typically download or access this content from a local DP. The communication channel between the client and the DP can be configured to use either HTTP or HTTPS. While HTTPS provides enhanced security by encrypting the communication channel, certain operations, like specific aspects of Windows Installer source list updates handled by Config Manager’s client agents, exhibit different behaviors or limitations when operating over HTTPS. This particular failure highlights one such limitation within the specific versions mentioned.

Symptom¶

When Configuration Manager clients are configured to communicate with their assigned distribution points exclusively over HTTPS, attempts to update the Windows Installer source list for deployed applications or packages may fail. This failure is not always immediately apparent to the end-user but is logged within the client’s Configuration Manager log files. The specific log file that captures this activity is SrcUpdateMgr.log.

Reviewing the SrcUpdateMgr.log file on an affected client reveals entries indicating the failure. Common error messages observed include lines similar to these:
* UpdateURLWithTransportSettings(): HTTP requested but client settings prohibit it.
* Failed source list update for product <product code>, error 87d00226
* DoUpdateSourceListAll task failed, error code 87d00226
* Source list update task failed, will be retried after 3600 seconds

The error code 87d00226 is a hexadecimal representation of a Configuration Manager specific error. This error code generally translates to CCM_E_NO_CUSTOM_TRANSMIT. This indicates that the client attempted a data transfer operation that was disallowed by its current configuration, specifically relating to transport settings. In this context, the client likely defaulted or attempted to use an HTTP-based mechanism for the source list update process, but its global or specific client settings mandated HTTPS, leading to the conflict and the logged error. The retry message indicates that the Configuration Manager client recognizes the failure and is scheduled to attempt the update again later, though it will continue to fail under the same conditions.

Cause¶

The root cause of this issue is that updating the Windows Installer source list via Configuration Manager clients communicating with distribution points using HTTPS is identified as an unsupported scenario by Microsoft. This classification implies that the mechanism used by the Config Manager client to manage and update the local Windows Installer source list on the client machine was not designed or tested to function correctly when the primary communication channel to the content location is secured solely by HTTPS in certain versions.

While HTTPS is fully supported for content download by the Distribution Manager component and client download jobs, the specific process handled by the Source Update Manager (SrcUpdateMgr) component seems to have limitations when relying on HTTPS for discovering or validating source locations directly from the DP’s web services. The underlying implementation details of how SrcUpdateMgr interacts with the DP’s IIS role services for this specific task might involve legacy components or specific protocols that do not translate seamlessly or are not permitted when strict HTTPS is enforced. This mismatch in design or implementation leads to the communication failure reflected in the logs and the inability to update the source list.

Understanding Windows Installer Source Lists¶

To fully grasp the impact of this failure, it’s important to understand what the Windows Installer source list is and why it’s important. When an application is installed using a Microsoft Installer (MSI) package, the Windows Installer engine records information about the installation, including the location of the original source files. This information is stored in the Windows registry, primarily under HKEY_CLASSES_ROOT\Installer\Products\<product code>\SourceList and also potentially under HKEY_CURRENT_USER\Software\Microsoft\Installer\Products\<product code>\SourceList.

The source list contains paths where the Windows Installer can expect to find the original .msi file and any related source files (.cab, .mst, etc.) if needed in the future. Why would it need these files later? Common scenarios include:
* Application Repair: If an application becomes corrupted, the user or system can initiate a repair operation. This often requires access to the original installation source to replace missing or damaged files.
* Applying Patches/Updates: Many software updates (MSPs) require the original installation source files to correctly apply changes to the installed application files and registry entries.
* Adding/Removing Features: If the original installation allowed selecting features, modifying the installed features later requires the source files.

If the Windows Installer cannot locate the source files at the locations listed in the registry, the repair, patch, or modify operation will fail. Configuration Manager attempts to proactively manage these source lists by updating them with the network location of the content on distribution points, ensuring that clients can find the source files when needed. When this update process fails due to the HTTPS issue, the client’s source list remains outdated or incorrect, leading to subsequent failures during maintenance operations on the installed application.

Workarounds¶

Since this is an unsupported scenario, there is no direct fix or hotfix to enable SrcUpdateMgr to function over HTTPS in this specific instance. Instead, workarounds are necessary to ensure clients can access application source files when required, bypassing the failed Configuration Manager source list update mechanism. Two primary methods are available:

Method 1: Utilize HTTP for Client-to-Distribution Point Communication¶

The most straightforward workaround, if feasible in your environment, is to configure clients and distribution points to communicate using HTTP instead of HTTPS.

How it works: By allowing HTTP communication, the Configuration Manager client’s SrcUpdateMgr component can likely use the transport method it was designed for when interacting with the DP’s web services for source list updates. This bypasses the specific HTTPS-related failure point.

Implementation:
1. Configure the Distribution Point: Ensure that the distribution point is configured to allow client connections over HTTP. This setting is managed within the DP properties in the Configuration Manager console.
2. Configure Client Communication: Adjust the client communication settings. This might involve modifying boundary groups to prefer or use DPs configured for HTTP, or ensuring the client’s general communication settings allow HTTP fallback if HTTPS fails or is not available for certain operations. In many environments, allowing HTTP for client-DP communication is standard, while client-Management Point communication might be over HTTPS.

Considerations:
* Security Implications: Using HTTP for client-DP communication means content is transferred in plaintext. While this might be acceptable within a secure internal network segment, it may violate security policies or compliance requirements in some organizations, particularly for communication across less trusted network zones.
* Mixed Environments: If your environment requires a mix of HTTP and HTTPS DPs or specific clients must use HTTPS for other reasons, this workaround might not be universally applicable without complex configurations.

This method is the simplest to implement from a Configuration Manager perspective but requires careful consideration of your network security posture and compliance requirements.

Method 2: Ensure Source Availability via Alternative Methods¶

This method involves bypassing the Configuration Manager client’s automatic source list update for the affected products and ensuring the Windows Installer source list on the client is populated with accessible locations through other means. This approach is more complex but allows you to maintain HTTPS communication between clients and DPs.

This method has two variations, one applicable to traditional packages and another primarily for applications or any MSI installation managed outside the Config Manager source list update process:

Workaround 2a: Enable Package Share for Traditional Packages¶

For content deployed as traditional Configuration Manager packages (not applications), you can configure the package to be shared directly from the distribution point’s content library via Server Message Block (SMB).

How it works: When you enable the “Copy the content in this package to a package share on distribution points” option, Configuration Manager creates an SMB share point directly within the content library path on the DP for that specific package’s content. The Windows Installer engine on the client is capable of accessing source files located on network shares (UNC paths). If the Windows Installer source list on the client points to this UNC path, it can retrieve the source files independently of the failed Config Manager HTTPS process.

Implementation:
1. Navigate to Software Library > Packages in the Configuration Manager console.
2. Right-click the affected package and select Properties.
3. Go to the Data Source tab.
4. Check the option Copy the content in this package to a package share on distribution points.
5. Click OK to apply the changes.
6. Update the content on the distribution points to ensure the share is created and accessible.

Considerations:
* SMB Access: Clients must have appropriate network permissions to access the SMB share created on the distribution point’s server. This might involve firewall rules or file share permission configurations.
* Traditional Packages Only: This option is specifically for packages. Applications, especially those deployed using the Application Model, do not have this direct “package share” option in the same way, as their content is primarily managed within the content library structure and accessed via web services (HTTP/HTTPS).
* Disk Space: Enabling this option creates a duplicate copy of the package content outside the single-instance content library on the DP, consuming additional disk space.

Workaround 2b: Manually Add Source Locations to the Registry¶

For applications (or packages where Workaround 2a isn’t suitable), you can directly modify the Windows Installer source list in the client’s registry to include the network location of the application source files. This location could be a standard file server share or potentially even the content path within the Configuration Manager content library if accessible via UNC.

How it works: This method bypasses Config Manager’s source update process entirely. By directly writing the UNC path of the source files into the registry keys that Windows Installer reads (SourceList\Net), you provide the Windows Installer engine with a valid location to look for the source files when needed for repair or patching.

Implementation:
1. Identify the Product Code: Determine the MSI product code for the installed application. This is a GUID specific to the MSI. You can find this in the registry under HKEY_CLASSES_ROOT\Installer\Products or by inspecting the MSI file properties.
2. Identify the Source Location: Determine the network path (UNC path, e.g., \\yourserver\share\application_source) where the application’s MSI and supporting files are reliably available to clients. This could be a dedicated file share or potentially a path within the Config Manager content library if SMB access is configured and permissible.
3. Update Registry Keys: Add the source location to the following registry keys on the client computer:
* HKEY_CLASSES_ROOT\Installer\Products\<product code>\SourceList\Net
* HKEY_CURRENT_USER\Software\Microsoft\Installer\Products\<product code>\SourceList\Net (Note: This key is per-user; updating HKEY_CLASSES_ROOT is usually sufficient for system-wide availability).

You would typically not perform this manual registry edit on every client. Instead, this process should be automated using Configuration Manager itself (as a script or application deployment). A script could:
* Detect the installed application and its product code.
* Construct the correct registry path.
* Write the network source location to the SourceList\Net key.

Example PowerShell Script Logic (Conceptual):

# Define the product code for the application (replace with actual GUID)
$ProductCode = "{YOUR-PRODUCT-GUID-HERE}"
# Define the network path to the source files
$SourcePath = "\\yourfileserver\shares\application_source"

# Reformat Product Code from {GUID} to GUID (no braces) and reversed for registry lookup
$RegProductCode = $ProductCode.Trim("{}").Split('-')
[Array]::Reverse($RegProductCode)
$RegProductCode = $RegProductCode -join ''

# Registry paths
$RegPathHKCR = "Registry::HKEY_CLASSES_ROOT\Installer\Products\$RegProductCode\SourceList\Net"
# $RegPathHKCU = "Registry::HKEY_CURRENT_USER\Software\Microsoft\Installer\Products\$RegProductCode\SourceList\Net" # Consider if necessary

# Check if the path exists and create if not
if (-not (Test-Path $RegPathHKCR)) {
    New-Item $RegPathHKCR -Force | Out-Null
}

# Add/Update the source location (e.g., under a key named '1' or 'LastUsedSource')
# Standard practice is often under '1' or other numerical indices if multiple sources exist
Set-ItemProperty -Path $RegPathHKCR -Name "1" -Value $SourcePath -Force
# Also set LastUsedSource
Set-ItemProperty -Path $RegPathHKCR -Name "LastUsedSource" -Value $SourcePath -Force

Write-Host "Updated source list for $ProductCode to $SourcePath"

# Consider adding logic for HKEY_CURRENT_USER if needed, perhaps for user-specific installs

This script can be deployed as a Configuration Manager script or as part of an application deployment’s post-installation steps.

Considerations:
* Complexity: Managing registry updates via scripts is more complex than simply checking a box in package properties.
* Source File Availability: The network share specified in the registry must be continuously available to clients. If the server is down or the share permissions change, Windows Installer will fail to find the source. This requires managing a separate file share infrastructure alongside Configuration Manager DPs.
* Product Code Management: You need a reliable way to determine the product code for each application requiring this workaround.
* Application Updates: When deploying a new version of the application (e.g., an upgrade via a new MSI), the product code might change, or the new installation might overwrite the source list keys. You would need to manage updating the registry entries again after such deployments.

Comparing Workarounds¶

Feature	Method 1: Use HTTP	Method 2a: Package Share (Packages)	Method 2b: Registry Update (Applications/MSI)
Requires HTTPS?	No (Uses HTTP)	Yes (DP-client still HTTPS)	Yes (DP-client still HTTPS)
Complexity	Low (Config Change)	Medium (Config Change, SMB)	High (Scripting, Registry, File Shares)
Applicability	All Packages/Apps	Traditional Packages Only	Applications / Any MSI install
Dependencies	HTTP allowed on DP/client	SMB access to DP share	SMB access to dedicated file share/ContentLib
Security Impact	Lower (HTTP)	Moderate (SMB share on DP)	Moderate (External file share)
Content Redundancy	None (uses DP)	Yes (copy on DP)	Yes (requires separate file share)
Maintenance	Low	Low (Config Mgr handles share)	High (Manual script updates, file share mgmt)

Choosing the appropriate workaround depends heavily on your environment’s security policies, infrastructure capabilities (SMB access, file servers), and the types of content you are deploying (packages vs. applications).

Further Troubleshooting Steps¶

Even after implementing a workaround, it’s essential to verify that clients can now successfully access the source files.
1. Test Application Repair: On an affected client, attempt to perform a repair of the application that previously failed source list update. This can often be done via “Programs and Features” in the Control Panel.
2. Test Patching: Attempt to apply a patch (MSP file) for the application.
3. Monitor Windows Installer Logs: Examine the Windows Installer logs (msiexec /l*v <logfile>) generated during the repair or patching attempt. These logs will provide detailed information about where Windows Installer looked for the source files and why it succeeded or failed.
4. Verify Network Access: If using a share (Workaround 2a or 2b), manually try to access the UNC path specified in the registry or the package share from the client machine using File Explorer (\\server\share).
5. Check Registry: On the client, verify that the SourceList\Net registry keys are correctly populated with the expected network path after implementing the chosen workaround.

Understanding the flow of control – whether Config Manager’s SrcUpdateMgr is attempting to update the list or if Windows Installer is using the list – is key to effective troubleshooting. The workarounds aim to ensure the latter (Windows Installer using the list) succeeds, even if the former (Config Manager updating the list over HTTPS) fails.

While adding videos or complex diagrams like Mermaid diagrams might not be directly applicable or easy to embed in this static text format without interactive rendering, visualizing the communication flow can help. Imagine a diagram showing: Client initiates source update -> Calls Config Manager Client Agent -> SrcUpdateMgr component -> Attempts to connect to DP’s web service -> Fails over HTTPS -> Logs error. Conversely, visualize: User initiates repair -> Windows Installer Engine -> Reads SourceList from Registry -> Attempts to access UNC path -> Success. The workarounds aim to ensure the second path is functional.

Conclusion¶

The failure of Windows Installer source list updates when Configuration Manager clients use HTTPS communication with distribution points is a known limitation in specific versions. While the behavior is identified as an unsupported scenario, practical workarounds exist to mitigate the impact. Organizations can either revert to using HTTP for client-DP communication where security policies permit, or implement alternative methods to ensure source file availability, such as enabling package shares for traditional packages or manually managing the Windows Installer source list registry entries via scripting for applications.

Careful consideration of the security implications, administrative overhead, and application types is necessary when selecting the most appropriate workaround for your environment. Implementing these solutions allows clients to perform essential maintenance operations like application repairs and patching, maintaining the health and security of deployed software even in an HTTPS-centric Configuration Manager environment.

Which workaround have you found most effective in your environment? Have you encountered other challenges with Config Manager client communication over HTTPS? Share your experiences and insights in the comments below.