Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 1 subscriber
  • Views 3074 views
  • Users 0 members are here
Options
Suggested
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

endpoint on different subnet. Installs but will not update.

joea

I have the update server on the main lan subnet and a laptop on a subnet, thru a router. I can browse to the update/install location and run setup, which installs sophos av.   However, update fails.  Cannot find update location.

mrinit.conf shows the explicit IP of the update server. 

Why can update not find it?   I can see the router dropping netbios calls on the subnet.   But why should update need that, when it knows where the update server is?

:39009


This thread was automatically locked due to age.
Parents
  • 0

    Hello joea,

    first of all some clarification: mrinit.conf is for the RMS component, i.e. communication with the management server. It has nothing to do with updating - indeed the install of RMS is not required for AutoUpdate/SAV to work. The update location is either a share (UNC path) or a web folder.

    During manual (interactive) install using the GUI the update location is set to the location of setup.exe. As you've successfully accessed the share to run setup.exe it should in principle work - unless you did not specify the correct credentials. (or none at all) - but anyway the behaviour is the same regardless of the (sub)net the client is in.

    When installing from the share it works similar to Protect computers: AU is installed first which then accesses the update location, downloads the other components and installs them. If the credentials were incorrect/missing it will fail already at this step - you'll notice that the GUI is rather sparse and only the items belonging to update will be active.  

    I can see the router dropping netbios calls on the subnet

    As said, updating does use a UNC path (and indirectly the ports/protocols the API provides - usually 445 is tried first, then legacy NetBIOS). As it worked for running setup.exe it should also work for updating. Thus my first guess would be incorrect credentials (if the install did not complete). If the install was successful and everything worked (including RMS) then it could be the updating policy the client received from the console - if it specifies an update location inaccessible from the subnet (e.g. a non-routable IP or a name which can't be resolved on the subnet) subsequent  updating will fail.

    Hope this helps to resolve the issue.

    Christian     

    :39023
Reply
  • 0

    Hello joea,

    first of all some clarification: mrinit.conf is for the RMS component, i.e. communication with the management server. It has nothing to do with updating - indeed the install of RMS is not required for AutoUpdate/SAV to work. The update location is either a share (UNC path) or a web folder.

    During manual (interactive) install using the GUI the update location is set to the location of setup.exe. As you've successfully accessed the share to run setup.exe it should in principle work - unless you did not specify the correct credentials. (or none at all) - but anyway the behaviour is the same regardless of the (sub)net the client is in.

    When installing from the share it works similar to Protect computers: AU is installed first which then accesses the update location, downloads the other components and installs them. If the credentials were incorrect/missing it will fail already at this step - you'll notice that the GUI is rather sparse and only the items belonging to update will be active.  

    I can see the router dropping netbios calls on the subnet

    As said, updating does use a UNC path (and indirectly the ports/protocols the API provides - usually 445 is tried first, then legacy NetBIOS). As it worked for running setup.exe it should also work for updating. Thus my first guess would be incorrect credentials (if the install did not complete). If the install was successful and everything worked (including RMS) then it could be the updating policy the client received from the console - if it specifies an update location inaccessible from the subnet (e.g. a non-routable IP or a name which can't be resolved on the subnet) subsequent  updating will fail.

    Hope this helps to resolve the issue.

    Christian     

    :39023
Children
No Data