Troubleshooting Contentinfo.tar Hash Mismatch Errors in Configuration Manager

Table of Contents

When managing software distribution in Microsoft Configuration Manager, leveraging cloud-based distribution points (DPs) offers significant advantages in terms of scalability and reach, especially for internet-based clients. However, administrators may encounter issues during content download, one of which is a hash mismatch error specifically related to the Contentinfo.tar file. This issue prevents clients from successfully obtaining the required content, leading to failures in software deployments, updates, or application installations. Understanding the underlying cause and implementing the correct resolution is crucial for maintaining a healthy and functional content distribution infrastructure within Configuration Manager. This article details the symptoms of this particular hash mismatch problem and provides a step-by-step guide to resolve it.

Understanding the Configuration Manager Content Distribution Process¶

Before diving into the specifics of the hash mismatch error, it is important to understand how Configuration Manager handles content. When you distribute content, such as an application, software update, or package, to a distribution point, the Configuration Manager site server processes this content. The content is broken down into smaller chunks, and a hash is calculated for each chunk and for the content package as a whole. This hashing process ensures content integrity during transfer and storage.

The metadata associated with the content, including information about the chunks and their hashes, is packaged into a file called Contentinfo.tar. This file is essential for clients. When a client attempts to download content from a distribution point, it first downloads the Contentinfo.tar file. This file tells the client what chunks make up the content and what the expected hash of each chunk (and the overall content) should be. The client uses this information to download the content chunks and then verifies the integrity of the downloaded data by comparing the calculated hash of the downloaded content against the hash provided in the Contentinfo.tar file.

Distribution points store the actual content chunks and the associated Contentinfo.tar file. For cloud distribution points, this content is stored in Azure storage. The Configuration Manager site server responsible for sending content to the cloud DP uses the Package Transfer Manager component to upload the necessary files, including Contentinfo.tar, to the cloud storage location.

The Role of BranchCache and Content Hashing¶

BranchCache is a feature in Windows that can help optimize network bandwidth when clients access content from remote servers. When integrated with Configuration Manager, BranchCache allows clients within the same network segment to share cached content chunks, reducing the need for every client to download the same data directly from the distribution point. This works by clients downloading content chunks and then making them available to other BranchCache-enabled clients on the local network. The identification and verification of these chunks rely heavily on hashing.

Configuration Manager can leverage BranchCache hashing when creating content information. However, for BranchCache to function correctly and for content hashes to be consistent across different servers or sites that might be interacting with the same content or distribution points, a consistent BranchCache key is required. This key is used in the process of calculating the hashes for the content chunks when BranchCache is involved. If different servers involved in content distribution, particularly primary sites in a hierarchy, are using different BranchCache keys, it can lead to inconsistencies in the calculated hashes for the same content.

In the context of cloud distribution points in a multi-primary site hierarchy, the issue arises because each primary site might independently calculate the hash for the Contentinfo.tar file when preparing content for upload to its assigned cloud DP. If the BranchCache key is not synchronized across these primary sites, the hash calculated by one primary site for the Contentinfo.tar associated with a particular content item may differ from the hash calculated by another primary site for the exact same content item. When a client attempts to download the Contentinfo.tar from a cloud DP, and the client’s expected hash (perhaps based on information from its assigned primary site or the CAS) doesn’t match the hash of the Contentinfo.tar stored on the cloud DP (uploaded by potentially another primary site with a different key), a hash mismatch error occurs.

Symptoms of Contentinfo.tar Hash Mismatch¶

The primary symptom of this issue is the failure of clients to download content from cloud distribution points. Clients attempting to access software or updates hosted on these cloud DPs will report download errors. Upon examining the client logs, specifically the ContentTransferManager.log file, you will find entries indicating a hash verification failure for the Contentinfo.tar file.

A typical error message logged in ContentTransferManager.log on the client might look like this:

CCTMJob::_ProcessContentInfo - failed to verify hash (algorithm ID = 32780, provider type = 24). Actual value - <value1>, Computed value - <value2>

In this error message:
- CCTMJob::_ProcessContentInfo indicates that the failure occurred while processing the content information file (Contentinfo.tar).
- failed to verify hash explicitly states that the hash check failed.
- algorithm ID and provider type specify the cryptographic algorithm used for hashing (e.g., SHA-256).
- Actual value - <value1> shows the hash value that the client calculated from the downloaded Contentinfo.tar file (or the hash value embedded within the file itself, depending on the specific verification step being performed).
- Computed value - <value2> shows the hash value that the client expected the Contentinfo.tar file to have. This expected value typically comes from the Configuration Manager client policy, which ultimately originates from the site database.

The crucial point here is that <value1> and <value2> are different, indicating that the file downloaded by the client (Contentinfo.tar from the cloud DP) is not what the client expected based on the hash information it received. This discrepancy arises because the Contentinfo.tar file uploaded to the cloud DP had a hash calculated using a different BranchCache key than the key implicitly or explicitly expected by the client or another site in the hierarchy.

This issue is particularly prevalent in Configuration Manager hierarchies with multiple primary sites where:
- Multiple cloud DPs are used and potentially managed or uploaded to by different primary sites.
- The Distribution Point role might not be installed on the primary site servers themselves, or if it is, the specific BranchCache option on the DP role might not be enabled (which doesn’t mean BranchCache isn’t active system-wide).
- The BranchCache feature is installed and enabled on the primary site servers at the operating system level, and also potentially enabled on client machines through group policy or client settings.

The problem stems from the fact that the operating system’s BranchCache feature, when active on the primary site server, might influence the hashing process during content staging or packaging for upload, using a locally defined BranchCache key that hasn’t been synchronized across the hierarchy.

Cause of the Hash Mismatch¶

As detailed above, the root cause is the inconsistency of the BranchCache key across the primary site servers in the Configuration Manager hierarchy. In a hierarchy with a Central Administration Site (CAS) and multiple primary sites, the CAS holds the authoritative data for the hierarchy, including certain global properties. While content is managed and distributed at the primary site level, aspects that can influence hierarchy-wide consistency, like the BranchCache key used for content hashing, ideally need to be uniform.

When BranchCache is enabled at the OS level on primary site servers, and content is processed (packaged and prepared for upload to DPs, including cloud DPs), the hashing process might incorporate the system’s active BranchCache key. If primary site A has one BranchCache key and primary site B has a different one, the Contentinfo.tar generated and uploaded by site A to a cloud DP might have a different hash than the Contentinfo.tar generated and uploaded by site B for the exact same content to another (or even the same, if configured) cloud DP.

Clients receive policy information, including expected content hashes, from their assigned site (typically a primary site). When a client attempts to download Contentinfo.tar from a cloud DP that received the file from a primary site with a different BranchCache key, the client’s hash verification fails because the downloaded file’s hash doesn’t match the hash the client was expecting based on its policy or local calculation using its own potentially different key.

The SC_Properties table in the Configuration Manager database stores various global site control properties. The BranchCacheKey property, as the name suggests, holds the value of the BranchCache key that Configuration Manager intends to use or is aware of for maintaining consistency. However, the operating system’s active BranchCache key, configured via netsh, is what the system actually uses, and this can deviate from the value stored in the ConfigMgr database if not explicitly set and synchronized. The resolution involves ensuring the operating system’s BranchCache key on all relevant primary sites matches the value stored in the central database, which should be the consistent value for the hierarchy.

Resolution Steps¶

To resolve the Contentinfo.tar hash mismatch error caused by inconsistent BranchCache keys across primary sites, you need to perform the following steps. These steps ensure that all primary sites use the same BranchCache key when processing content, leading to consistent hash calculations and correctly generated Contentinfo.tar files for cloud distribution points.

Step 1: Retrieve the Consistent BranchCache Key from the CAS Database¶

The Central Administration Site (CAS) database typically holds the most consistent representation of hierarchy-wide settings. You need to query the CAS database to find the BranchCacheKey value that should be used across all primary sites.

1. Connect to the SQL Server instance hosting the CAS database using SQL Server Management Studio (SSMS).
2. Open a new query window.

3. Execute the following SQL query against your CAS database (usually named CM_CAS or similar):

   SELECT * FROM SC_Properties WHERE Name = 'BranchCacheKey'
   

4. The query result will show rows from the SC_Properties table. Look for the row where the Name column is 'BranchCacheKey'. The Value column in this row contains the desired BranchCache key passphrase. Note this value down carefully. It will likely be a string of characters.

This SQL query retrieves the BranchCache key value that is globally defined or stored within the Configuration Manager database for the hierarchy. This is the value you will enforce on your primary site servers.

Step 2: Set the BranchCache Key on Each Primary Site Server¶

Once you have the consistent BranchCache key passphrase from the CAS database, you must configure the operating system’s BranchCache settings on each primary site server to use this specific key. This is done using the netsh command-line utility.

1. Log in to each primary site server in your Configuration Manager hierarchy.
2. Open a Command Prompt or PowerShell window with administrative privileges.

3. Execute the following command, replacing <value> with the BranchCache key passphrase you obtained from the CAS database in Step 1:

   netsh branchcache set key passphrase="<value>"
   

   Important: Ensure you enclose the passphrase in double quotes (") if it contains spaces or special characters.

4. Press Enter to execute the command. The command should report success.

5. Repeat this command on every primary site server involved in content distribution, especially those managing cloud distribution points.

This command sets the system-wide BranchCache key. By setting the same key on all primary sites, you ensure that any process leveraging the OS BranchCache feature for hashing will produce consistent hash values across these servers when dealing with the same content.

Step 3: Redistribute Content to Cloud Distribution Points¶

After ensuring that all primary site servers are using the same BranchCache key, you must redistribute the affected content to the cloud distribution points. Simply updating the content will often not be sufficient because the Contentinfo.tar file might not be regenerated with the new key. Redistributing forces Configuration Manager to re-process the content package, recalculate the hashes using the newly configured, consistent BranchCache key, generate a new Contentinfo.tar file, and upload the content (including the new Contentinfo.tar) to the cloud DP.

1. Open the Configuration Manager console.
2. Navigate to the workspace containing the content you need to redistribute (e.g., Software Library > Application Management > Applications, Software Library > Software Updates > Deployment Packages, Software Library > Packages).
3. Select the specific application, deployment package, or package that was failing to download from the cloud DPs due to the hash mismatch. You might need to do this for multiple content items if the issue affected more than one.
4. In the ribbon or the right-click context menu, select the option to Redistribute the content.
5. In the Redistribute Content wizard, select the specific cloud distribution points where the hash mismatch occurred.
6. Complete the wizard to initiate the redistribution process.

Monitor the content status in the Configuration Manager console under the Monitoring workspace, specifically Distribution Status > Content Status. Wait for the content to successfully redistribute to the selected cloud DPs. This process can take time depending on the size of the content and the speed of the connection to the cloud storage. Once the content is successfully redistributed, clients attempting to download the content from these cloud DPs should now be able to download and verify the Contentinfo.tar file successfully, as it was generated using the correct, consistent BranchCache key.

Diagram: Illustrating the Inconsistency¶

Here’s a simplified diagram using Mermaid syntax to illustrate how inconsistent BranchCache keys can lead to issues in a multi-primary hierarchy with cloud DPs.

```mermaid
graph LR
CAS[Central Administration Site] → PS1{Primary Site 1};
CAS → PS2{Primary Site 2};

PS1 --> CDPA(Cloud DP A);
PS2 --> CDPB(Cloud DP B); % Can also point to CDPA

subgraph Primary Site 1 Context
    BCKey1(BranchCache Key 1)
    ContentGen1(Content Processing)
    Upload1(Upload to Cloud DP A)
end

subgraph Primary Site 2 Context
    BCKey2(BranchCache Key 2)
    ContentGen2(Content Processing)
    Upload2(Upload to Cloud DP B) % Or CDPA
end

subgraph Cloud DP Storage
    ContentInfoA[Contentinfo.tar on CDPA]
    ContentInfoB[Contentinfo.tar on CDPB]
end

subgraph Client Context
    Client[Client Machine];
    ExpectedHash(Expected Hash from Policy)
    DownloadedInfo(Download Contentinfo.tar)
    VerifyHash(Verify Hash)
end

PS1 -- Uses BCKey1 --> ContentGen1;
ContentGen1 -- Generates Contentinfo.tar (Hash1) --> Upload1;
Upload1 --> CDPA;

PS2 -- Uses BCKey2 (Key1 != Key2) --> ContentGen2;
ContentGen2 -- Generates Contentinfo.tar (Hash2) --> Upload2; % Hash1 != Hash2 for same content
Upload2 --> CDPB; % Or overwrites on CDPA

Client -- Requests Content --> CDPA;
CDPA --> DownloadedInfo; % Gets Contentinfo.tar (HashX)

Client -- Gets Policy --> PS1; % Or other site/CAS
PS1 -- Provides Policy --> ExpectedHash; % HashY (Based on Key1 or consistent Key)

DownloadedInfo -- Has Hash X --> VerifyHash;
ExpectedHash -- Provides Hash Y --> VerifyHash;

VerifyHash -- Compare X and Y --> Mismatch[Hash Mismatch Error!];

style BCKey1 fill:#f9f,stroke:#333,stroke-width:2px
style BCKey2 fill:#f9f,stroke:#333,stroke-width:2px
style Mismatch fill:#f99,stroke:#333,stroke-width:2px
style CDPA fill:#ccf,stroke:#333,stroke-width:2px
style CDPB fill:#ccf,stroke:#333,stroke-width:2px

`` This diagram illustrates that when Primary Site 1 usesBCKey1to process content and uploadContentinfo.tarto Cloud DP A, the resulting hash will be different if Primary Site 2 usesBCKey2(whereKey1 != Key2) to process the *same* content and upload it to Cloud DP B (or even Cloud DP A). A client receiving policy based onBCKey1(or a consistent key from the CAS) will expectHash Y, but downloading from a DP that received the file based onBCKey2will result in a file withHash X, leading to the mismatch. The resolution ensuresBCKey1andBCKey2are the same, soHash1andHash2` are identical for the same content.

Additional Considerations¶

After applying the resolution steps, keep the following in mind:

• Time for Redistribution: Redistributing large content items, especially to cloud DPs, can take a significant amount of time depending on your network speed and the capabilities of your Azure subscription. Monitor the process carefully in the console.
• Client Policy Update: Clients need to receive updated policy after the content has been successfully redistributed. Although clients periodically check for policy updates, you can manually trigger a Machine Policy Retrieval & Evaluation Cycle and a User Policy Retrieval & Evaluation Cycle from the Configuration Manager client control panel or using client notification actions from the console to expedite the process.
• Monitoring Client Downloads: After policy updates, test content download on a few affected clients to confirm that the hash mismatch errors are no longer occurring and downloads complete successfully.
• Firewall and Network: Ensure no firewall rules or network restrictions between the primary site servers and Azure storage are impeding the redistribution process. Also, verify client connectivity to the cloud DP endpoint.
• Cloud DP Status: Check the status of your cloud distribution points in the Configuration Manager console to ensure they are healthy and operational.

By ensuring a consistent BranchCache key is used across all primary sites when processing content destined for cloud distribution points, you eliminate the source of the hash inconsistency in the Contentinfo.tar file, allowing clients to successfully validate and download content. This specific issue highlights the importance of hierarchy-wide consistency in Configuration Manager, especially when leveraging features like BranchCache and cloud-based services.

Experiencing and resolving issues like the Contentinfo.tar hash mismatch deepens understanding of Configuration Manager’s internal workings, particularly its content library and distribution mechanisms. This knowledge is invaluable for maintaining a robust and reliable endpoint management infrastructure.

Do you have questions about this troubleshooting process or perhaps alternative scenarios where you’ve encountered hash mismatch errors? Feel free to share your experiences and insights in the comments below.