Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 10 replies
  • Subscribers 1 subscriber
  • Views 3472 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

Deploying clients to remote offices with slow link

Uncle_Ben

Hi ALL,

We are deploying the sophos to the clients that are located in the remote offices and outlet with a slow link to HQ. I created another thread before saying that I change the Initial Install Source to a local server's folder but it's totally failed and I gave up. Next, I use the cmd line method to deploy the clients like this:

\\172.18.10.1\sophosupdate\CIDs\S000\SAVSCFXP\setup.exe -mng yes -crt R -updp \\172.18.20.1\SophosUpdate\CIDs\S000\SAVSCFXP -user 172.18.20.1\SophosUpdateMgr -pwd sophosupdate -G \SOPHOS1\TEMP -s

Local subnet: 172.18.10.0/24

Remote subnet: 172.18.20.0/24 (HQ)

Local PC to install Sophos: 172.18.10.60

Local server sharing the source for installation and first time update: 172.18.10.1

Remote server sharing the source for further updating: 172.18.20.1 (HQ)

With the above cmd line, I found some issues...  :smileysad:

[1] Once the client successfully installed the sophos endpoint, the update will pointing to the HQ server... that's good and as expected, but I thought the FIRST TIME update should using the one in the local source? The installation is smoothly and good, but the updating takes 2 hours....... it's no good for a slow link over IPSec VPN.

[2] The "-G" parameter is not function... even I tried to put the different groups... the result is, the new deployed client would just in "unassigned" group

My requirement is quite reasonable: Let the local PCs to install the sophos endpoint from the local shared folder (with all necessary update) and then pointing the update primary server to the remote one for any further updating.... as told by the Sophos guys, the regular update of definiation should be below 100kb... I set the periodically update for every 60 minutes~ I wonder why the first updating need to update so many files from the REMOTE server.... does there any way can do it as expected??

Any advise / suggestions are welcome and appreciated !! Many thanks !!!  :smileysurprised:

:4524


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

    So it's only partially solved. Now I know it's some effort but to sort it out I suggest that you try without the -mng and -G switches. This should install AutoUpdate and SAVXP. If SAVXP is not installed (check the logs) or updating fails (check whether the update location is really the local server) the no wonder it takes that long when pointed to the central server as it then installs from remote. If RMS is installed it registers with the server and gets the "final" updating policy - so this part obviously works.

    If initial install succeeds you should try again with the -mng switch but without the -G. As RMS is installed early it might be that there is a race condition and the update location is set to HQ before the download and install of SAVXP has been started.

    The client will appear in the Unassigned group. If you move it to the final group and subsequent updating takes forever then the CID you install from is probably backlevel. View updating log from the client's GUI will show you which components (AutoUpdate, SAVXP, RMS) are updated. If you look at the ALUpdate log in the \AutoUpdate\Logs directory  and search for Downloading file you'll see what gets fetched from the server.

    Christian

    . 

    :4546
Reply
  • 0

    So it's only partially solved. Now I know it's some effort but to sort it out I suggest that you try without the -mng and -G switches. This should install AutoUpdate and SAVXP. If SAVXP is not installed (check the logs) or updating fails (check whether the update location is really the local server) the no wonder it takes that long when pointed to the central server as it then installs from remote. If RMS is installed it registers with the server and gets the "final" updating policy - so this part obviously works.

    If initial install succeeds you should try again with the -mng switch but without the -G. As RMS is installed early it might be that there is a race condition and the update location is set to HQ before the download and install of SAVXP has been started.

    The client will appear in the Unassigned group. If you move it to the final group and subsequent updating takes forever then the CID you install from is probably backlevel. View updating log from the client's GUI will show you which components (AutoUpdate, SAVXP, RMS) are updated. If you look at the ALUpdate log in the \AutoUpdate\Logs directory  and search for Downloading file you'll see what gets fetched from the server.

    Christian

    . 

    :4546
Children
No Data