Update errors after subscription change

Hello dluneau,

I have not tried to follow all your changes in detail, there's quite a lot of them :smileyvery-happy:

Software not available

This one is somewhat misleading if you are not familiar with it. It looks like a serious error - but actually it is one that is most of the time automatically corrected, as you have seen the full text tells you so, by subscribing you to the current recommended version. Thus it is an informational message but nevertheless important so you have to acknowledge it.

As to the remaining errors

The messages about CIDs with subscription counters other than S000 should eventually disappear - please check whether the clients comply with the policy.

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

This is often a transient error - I have a few clients which regularly display this error and then update fine again. One possible cause is an active VPN connection which temporarily block "other" network access.

Download of SAVXP failed from server Sophos (0000006b)

The client first failed to download SAVXP from the CID, tried the Secondary (Sophos) and while it could contact the server it encountered some error. Again I expect this to be a transient condition - please check its SAV version. 

Failed to install RMSNT: Package authentication failed (00000067)

I have seen some of these and eventually they disappeared. If it were a general problem (as described in Endpoints fail to update after adding XML configuration or custom files to the update location (CID) Authentication failed error 00000067) then you would see it on all the clients. Nevertheless, running ConfigCID.exe for the CID will do no harm and you might want to try it if you have some clients which constantly show this error.

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

This indicates an empty policy. Might be a glitch on the client (cause by the "version switching"). Please check the client's Update Details, if you don't see an update location view the updating history in View Computer Details for errors like Failed to install Sophos AutoUpdate.

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

Failed to install Sophos AutoUpdate: Error code 80070001

There's a not exactly quick but definitely dirty method (which won't be available in the future) I've used in several cases like this one. If the client has partially upgraded (e.g. SAV is already 10.3.1) try to "downgrade" it to a previous version with a different version of the failing component (in case of AU you'd need v10.0). If the downgrade is successful (wait for a) reboot and then try the upgrade again. Worked on more than occasion. Otherwise you'd have to inspect the logs for the reason of the error.

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

Likely some item required for the uninstall is missing (but check the logs first). Please see Re: Can't Uninstall Sophos Endpoint 9.5 for a possible solution.

I hope at least some of this helps. Again, please note that some of the errors might be transient or temporary and while the percentage of "error-clients" might be more or less constant the errors persist perhaps only on some of them.

Christian

When I view mrinit.conf on some clients, the MRParentAddress and ParentRouterAddress are pointing to parent SUM. 

On other workstations the MRParentAddress points to parent SUM and ParentRouterAddress points to the correct child SUM where it should be getting updates from.

Lastly, some workstationsare getting updates from the correct SUM (according to update log) however, the mrinit.conf shows the MRParentAddress is correct but ParentRouterAddress is pointing  to our second child SUM (incorrect).

What should the mrinit.conf look like as far as MRParentAddress and ParentRouterAddress?

I assume it should be MRParentAddress(points to our Parent SUM) and ParentRouterAddress (points to child SUM pushed by updating policy).

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

Thank you for the reply and explanation. I checked the mrinit.conf on all SUMs.  Location roaming is not enabled.

Any additional SUM will use the same mrinit.conf

ParentSUM

MRParentAddress"="x.x.x.96

ParentRouterAddress"="x.x.x.96

ChildSUM1 (for academic endpoints)

MRParentAddress"="x.x.x.96

ParentRouterAddress"="x.x.x.116

ChildSUM2 (for staff endpoints)

MRParentAddress"="x.x.x.96

ParentRouterAddress"="x.x.x.117

WebSUM (for home use clients - not managed)

Uses sameas parentSUM

ParentSUM Distribution details

Update to: \\ParentSUM\SophosUpdate

ChildSUM1 Distribution details

Update to: \\ChildSUM1\SophosUpdate

ChildSUM2 Distribution details

Update to: \\ChildSUM2\SophosUpdate

WebSUM Distribution details

Update to: \\WebSUM\SophosUpdate

So if I am understanding all of this correctly, a custom mrinit.conf was setup, on our childSUMs, from initial deployment.

I have never checked the mrinit.conf on any workstation until now so I'm not sure what the correct address should be for ParentRouterAddress.  All of the client installer packages I have created, that are used have originated from the ParentSUM\CID\SXXX.  Each package has

setup.exe -crt R -mng yes -updp childsum1/.../SAVSCFXP  -s -ni (installed on academic pcs)

setup.exe -crt R -mng yes -updp childsum2/.../SAVSCFXP  -s -ni (installed on staff pcs)

setup.exe -crt R -mng no -updp websum/.../SAVSCFXP  -s -ni (installed on home pcs)

Hello dluneau,

you should get your CIDs straight :smileyhappy:. You can find details in this forum as well as the article I'll refer to but first a summary and another explanation:

The mrinit.conf to be used by a relay (not that it might be also a SUM but this is not required) and the clients it serves must be put into the \rms subfolder of the applicable CID(s) - please see Enterprise Console: configuring message relay computers. Ideally you should either run the installer from the applicable CID, use Protect Computers with this CID, or create the package from this CID (BTW: with which method do you create these packages?) but, as mentioned, installing with a "general" package and then applying the appropriate update policy usually works as well.

When an endpoint (meaning any computer where RMS is installed) processes mrinit.conf it basically interprets it as follows:

• if one of its "addresses" (name, FQDN, IP ...) matches one of the (values in)  MRParentAddresses it considers itself the management server
• if one of its addresses matches one of the ParentRouterAddresses it considers itself a message relay, accepting connection from other endpoints and forwarding the messages to the MRParentAddress (note that this is not necessarily the management server, you can chain several MRs) and v.v.
• if it doesn't find a match it uses ParentRouterAddress to forward to/accept from

HTH

Christian

Thanks for the info. 

BTW: with which method do you create these packages?

I used winrar to create the packages.