Thank you for posting your question.
Could you send a screenshot of Manage > Products? Do you see items greyed out in that?
Negative: they are not greyed out (see screenshot below):
Additionally, I tried the following:
- Removed SUP role from the 2nd SUP.
- Re-published all patches that were already published via Ivanti Patch for SCCM.
- Manually ran the ADR.
- Confirmed PatchDownloader.log was correctly showing the contentsource of the main SUP.
- SUG (Software Update Group) and its respective Deployment Package and deployments were successfully updated.
- Re-added the SUP role to the 2nd SUP.
- ADR ran and fails again. PatchDownloader.log switches back contentsource to 2nd SUP, resulting in failure (404).
Since I have the publishing+ADR configured to run nightly, I noticed the following this morning:
Red square: a patch published by ivanti, SCCM trying to download it from the 2nd SUP.
Green square: a patch published by ivanti, SCCM successfully downloads it from the Main SUP.
Both during the same publishing and ADR execution.
Any ideas on what determines the countentsource for a patch published by Ivanti?
According to a SCCM MVP, the contentsource attribute comes from the metadata of the published patched:
Is there a way I can force Ivanti Patch for SCCM to always assign the main SUP as the contentsource in the metadata for all published updates?
I would think it force it automatically always, since the main SUP is the one I configured in Ivanti Patch for SCCM:
We checked and it doesnt look like we actually assign the SUP in the metadata. The WSUS assigned in the setup is the one we connect to and make API calls to handle the publication process.