We're experiencing extremely high volumes of error messages on our ZCM 2017 Update 1 Satellites. The problem seems similar to that described in TID 7021167, except that in our case the content never syncs because, well, it doesn't appear to exist. Example error message:
Failed to replicate content 119b7dcde6e977a71f622a316398146d
Additional Information:
Severity: Error
Date: January 19, 2018 3:52:25 AM
Source: /Devices/Servers/zcmswo sles-11-x86_64
Message ID: CDP.CdpContentFileError
Probable Cause URL: None
Related Objects: None

If I zman ogp 119b7dcde6e977a71f622a316398146d on a primary, I get error 22 (could not find object). If I browse to https://<a primary server URL>/zenworks-contentadmin?test=invoke&method=11&arg0=119b7dcde6 e977a71f622a316398146d I get a blank result. If I dir *119b7dcde6e977a71f622a316398146d* /s in the content-repo directory on a Windows primary I get "file not found".

Over the course of a day, one satellite will pile up nearly 100,000 error messages of this flavour, each with a unique GUID-that-doesn't-seem-to-point-anywhere. During the same day, the other satellite will record nearly 150,000 error mesages like this!

I have tried, at the satellite, the following:
zac cc
zac ref
zac cvc
zac cdp replicate

I tried removing the content role from the satellite, renaming the content directory in content-repo to content.old, restoring the content role to the satellite and allowing time for the content repository to be rebuilt. And after all was said and done, the flood of error messages had resumed, just as before. The TID says I can set a system variable to ignore the errors, but that would have the effect of masking any problems that might occur. I'm not keen on that. On the other hand, having hundreds of thousands of messages that don't seem to mean anything is in some respects quite similar in effect to having no logging, now that I reflect on it.

The satellites are running SLES, and they are set to replicate once per day, with the full 24 hours as the window to complete. There is no throttling via ZCC, although their bandwidth is constrained by the nature of their connection to our WAN. One has a 100 mbps connection and the other only 10. (I think.) Before anyone gets too hung up on worrying about the physical connection limitations, I hasten to point out that we have had these satellites up and running with ZCM 11 for several years and no problems. The excessive errors began exactly when we upgraded to ZCM 2017, and did not magically disappear when we installed Update 1. I don't believe hardware is to blame here.

It seems to me somehow the satellites have gotten corrupted or outdated information on the content they must replicate, and they are trying to replicate non-existent content.

If anyone has a suggestion as to how I can persuade the satellites they needn't look for this nonexistent content, or any other possible solutions to this issue, I would be most appreciative.