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

Update errors after subscription change

Prior to Sophos Anti-virus 10.3 I had four software subscriptions. Subscriptions and bootstraps were as follows:

Recommended - S000 (v9.7)

Endpoint v10 - S002 (v10.0)

Endpoint v10.2 - S003 (v10.2)

The automatic update from 10.2 to 10.3 display "Software not available" on the parent SUM as well as three child SUMs. Sophos support told me to acknowledge alerts and run an update on parent SUM.

Next I was adivsed to create a new subscription, Recommended1 - S005 (v10.3), and remove the older subscriptions. I made all of the necessary changes under the update managers and to the updating policies. Things seemed to be ok at this point.

A few days later I decided to put the software subsciption back to only one which was Recommended. So I changed the version on Recommended subscription to Recommended (10.3) from 9.7 Extended Maintenance Recommended and I deleted the Recommended1 subscription. I made all of the necessary changes to the parent SUM, child SUMs, and updating policies.

Once I did that almost 70% of our endpoints were displaying update errors mainly RMSNT and the bootstrap location pointed back to S000 (v9.7). I assume all of the updates/binaries for 10.3 replaced all of the old stuff.

Sent SDU logs from parent SUM and some endpoints to Sophos support. Support has been great up to this particular incident.

I took it upon myself to add the Recommended1 software subscription which created S008 (v10.3) bootstrap location, made necessary changes to parent and child SUMs and watched the error count decline.

I'm still seeing the following errors on clients.

ERROR: Could not find a source for updated packages (00000071)

Failed to install RMSNT: Package authentication failed (00000067)

Failed to install SAVXP: A previous version could not be uninstalled (00000067)

Failed to install Sophos AutoUpdate: The MSI has failed (00000067)

Updating failed because no update source has been specified (0000006e)

Download of Sophos AutoUpdate failed from server sophosupdates/CIDs/S008/SAVSCFXP/ (0000006b)

Download of SAVXP failed from server sophosupdates/CIDs/S003/SAVSCFXP/ (0000006b)

Download of RMSNT failed from server /CIDs/S008/SAVSCFXP/ (0000006b)

Download of SAVXP failed from server Sophos (0000006b)

Failed to install Sophos AutoUpdate: Error code 80070001

This thread was automatically locked due to age.

Parents

0 QC over 11 years ago

Hello dluneau,
kudos for the additional information which sheds some light on the problem.
To begin with, updating and management (RMS) are different things. In particular the addresses in mrinit.conf are not related to updating at all. The only connection is that mrinit.conf is contained in a CID and thus the update location might determine the mrinit.conf used by the client.
Why might (note this applies specifically to the Windows product)? mrinit.conf is created by the management server and put into the SAVSCFXP root folder of each CID as well as into the SUMInstallSet share. Any additional SUM will use the same mrinit.conf. In order to set up message relays you have to configure the distribution point (CID) the relay and its clients (in terms of RMS) update from by putting a customized mrinit.conf into the \rms subfolder. If you install a client from such a customized CID it will take the mrinit.conf from there. If you configure a CID used by already installed clients they will (usually) update RMS accordingly (but save the initial/original configuration). The same will happen if you re-direct the clients to a configured update location (unless location roaming is set in which case they will not reconfigure RMS). If a client is redirected to an unconfigured CID (or the configuration is removed) it will usually fall back to the original settings.
As your SUMs should apparently also act as message relays for the clients updating from their CIDs please make sure that the \rms subfolders contain the appropriate mrinit.conf and that you have correctly implemented the changes using ConfigCID.exe. Note that there is no mechanism that automatically adds a custom configuration to a newly created CID/subscription, also if the CID is deleted and recreated the changes are lost and have to be reapplied. Additionally it is a good idea to re-run ConfigCID.exe after a major version change
.
Christian
:44899
Cancel
Vote Up 0 Vote Down

Cancel

Reply

0 QC over 11 years ago

Hello dluneau,
kudos for the additional information which sheds some light on the problem.
To begin with, updating and management (RMS) are different things. In particular the addresses in mrinit.conf are not related to updating at all. The only connection is that mrinit.conf is contained in a CID and thus the update location might determine the mrinit.conf used by the client.
Why might (note this applies specifically to the Windows product)? mrinit.conf is created by the management server and put into the SAVSCFXP root folder of each CID as well as into the SUMInstallSet share. Any additional SUM will use the same mrinit.conf. In order to set up message relays you have to configure the distribution point (CID) the relay and its clients (in terms of RMS) update from by putting a customized mrinit.conf into the \rms subfolder. If you install a client from such a customized CID it will take the mrinit.conf from there. If you configure a CID used by already installed clients they will (usually) update RMS accordingly (but save the initial/original configuration). The same will happen if you re-direct the clients to a configured update location (unless location roaming is set in which case they will not reconfigure RMS). If a client is redirected to an unconfigured CID (or the configuration is removed) it will usually fall back to the original settings.
As your SUMs should apparently also act as message relays for the clients updating from their CIDs please make sure that the \rms subfolders contain the appropriate mrinit.conf and that you have correctly implemented the changes using ConfigCID.exe. Note that there is no mechanism that automatically adds a custom configuration to a newly created CID/subscription, also if the CID is deleted and recreated the changes are lost and have to be reapplied. Additionally it is a good idea to re-run ConfigCID.exe after a major version change
.
Christian
:44899
Cancel
Vote Up 0 Vote Down

Cancel

Children

No Data