This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Satellite Replication Problem (XML length problem)

Hi,

we are running ZCM/ZPM 17.4.1: The satellite content replication is working fine in general, however right now I encountered a problem with a single patch:

APSB20-48 Adobe Acrobat Reader DC (Continuous) 2020.012.20041 (20.12.20041.1044) for Windows (See Notes)-634109278

Maybe there are more, but this one I have to take care of:

The corresponding satellite is external (finally we made it:)) and is showing up replication errors once in a while - Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host. (CDP.UnexpectedError).

Now, while checking the content I found the mentioned ZPM-Bundle seems to be the cause, somehow the XML header length seems to be too long (max 255).

As a workaround I tried to include the bundle into satellite replication manually (using the context page of the server) and got a similar message about a problem. However it was downloading after zac cvc. Right now it is working fine... much more bandwidth will be saved now (Cumulative OS Patches don't have the issue, but this one has more than 230MB too)

Hopefully it won't break anything else: I'll check other (internal) satellites.

 

Any ideas about where I could check for the reason(s) ?

 

Thanks in advance

Dirk

Parents
  • 0

    Could you post more of the zmd-messages.log(in debug) from the satellite server? (taking out anything that's perhaps sensitive and should be kept internal, IPs, hostnames)

    Depending on where/when it's failing, sometimes there's a file attempting to be download unsuccessfully and if so, you can grab the URL from the log, and plug into a browser and sometimes that will give more information (Firewall/Security issue or give a 404/403 error, etc) 

Reply
  • 0

    Could you post more of the zmd-messages.log(in debug) from the satellite server? (taking out anything that's perhaps sensitive and should be kept internal, IPs, hostnames)

    Depending on where/when it's failing, sometimes there's a file attempting to be download unsuccessfully and if so, you can grab the URL from the log, and plug into a browser and sometimes that will give more information (Firewall/Security issue or give a 404/403 error, etc) 

Children
  • 0 in reply to 

    Hi & Thanks for  the suggestion to take a deeper look into the log:

    I'm afraid I don't need to post those errors, they are related to clients that disconnect from network (while CDP is trying to send).

    I forgot about the big number of clients, so of course those errors will happen more often than usual.

    That's good news about the logged errors, I can ignore/delete those messages.... (so the topic is now just about ZMP satellite replication...)

    Too bad my problem about patches not reaching the satellites is still there

    And I don't have any good idea where to start, I don't even know who's responsible for making them available to the satellites.

    Any suggestions?

     

    Thanks, Dirk

  • 0 in reply to 

    It's me again:

    As said before - there's a general problem with replication of ZPM content to satellites (other bundle replications work well):

     

    I do not have any idea where to start because of some general questions:

    What processes are responsible for that kind of distribution? When does it happen?

    Regarding ZPM content the satellites contents looks somewhat "random"

     

    Thx again & Best Regards

    Dirk