Deploying clients to remote offices with slow link

Hello Uncle_Ben,

as far as I know it works as follows: After running CRT (if specified) the first (and only) component installed by setup.exe is AutoUpdate. Once this is done AutoUpdate performs a "regular" update from the location configured, detects that "other" components are not yet installed and downloads and installs them. The location defaults to the location of setup.exe but can be specified using the -updp switch or SAUConf.xml in the \sau subdirectory. 

In order to perform the install from the local server you should not specify -updp. Using the -G <path> switch the computers should appear in the correct group and receive their Updating Policy which points to the central server. <path> is case sensitive (is the group a top level group named TEMP?) and needs to include the management server (is it SOPHOS1?).

While regular updates are rather small you have to watch out for version changes. Therefore you might want to subscribe to a fixed version (and uncheck the "automatically upgrade" box just in case). You have to check for newer versions periodically (at least every three months) and if a version upgrade is required decide on when and how to upgrade the clients.

If you search this forum for slow link you'll find a very long thread (Distributing over slow links) which discusses problems, pros and cons of alternatives. Personally I'd try setting up a secondary (child) SUM in the remote office. John Reynolds mentioned updates over http with a caching proxy in the remote office in this post.

HTH

Christian

Thanks QC! Your advise enlighten me and give me some insight. When I just using below parameters:

\\172.18.10.1\sophosupdate\CIDs\S000\SAVSCFXP\setup.exe -mng yes -crt R -G \SOPHOS1\TEMP

I found that the installation is fast (I uninstall it first) but the updating is failed. I could see that the updating primary path is pointing to the local link, and then it changed to the HQ link after a moment. However, it seems that the updating is still failed.... if I click on update now, it connecting to the HQ server and takes 2 hours to update like before.....

Do I missed anything? The first update seems cannot be performed......please help~~~

p.s. The grouping works now!

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

. 

Em.... I can't found any log files.... I tried to have '-mng Yes' and take out '-G' parameters with the similar error that just point the SUM to the local path now but with same error can't be updated. I have told you that I tried to make the source be thin, so I just copied the folder for 2000 & xp, any other like x64 I have ignored and that are not included in the source folder... I am not sure whether this is the cause, I will copy the folders under /sophosupdate (warehouse, CIDs, aspnet_client) to the site and redo the installation batch file again... let's it will be fixed or not~

Em.... I can't found any log files....

For the initial install they should be in the TEMP directory of the user who started setup.exe (WINDOWS\Temp in case it was SYSTEM). For automatic updates the ALUpdate logs are in %ProgramFiles%\Sophos\AutoUpdate\logs (%ProgramData% for newer OS), all others are in the system temp directory.

so I just copied the folder for 2000 ...

No wonder updating failed. You might have noticed the files with extension .upd (especially cidsync.upd). These are the catalogs which are used to verify the contents and consistency of the CID. You only need the SAVSCFXP folder (guess you can leave out the nac sub-folders but you need the complete sau, savxp and rms).

Christian

Thanks QC !!

Finally it works as expected with the whole SAVSCFXP folder on the local network as source. I use :

\\172.18.10.1\sophosupdate\CIDs\S000\SAVSCFXP\setu p.exe -mng yes -crt R -G \SOPHOS1\TEMP

The installation will now use the local source for the first time installation and updating. With the -G parameter the client is pointed to the correct group and applied with the related policies.

I know this post has been closed a while, but it just helped me solve [at least part of] an issue I have been having. However, executing a command line like the one above, my install only partially completed, with an error that it could not contact the server. Only after mod'ing the iconn.cfg file to allow local edit to update properties and specifying a domain account and password would the client connect and finish the install.

I had file sharing on (also tried off) and had share permissions and security permissions set to allow everyone "read" access.

Any help would be appreciated to learn how to not need a uid and pwd on my command line.

Solved is not "closed" and it can be helpful to have comments or other aspects on a thread.

Now the original "solution" assumes that the client receives a valid updating policy (including the required credentials) from the management server. Otherwise it will either use a sauconf.xml from the CID or a command line argument to setup.exe. Look at what's in the iconn.cfg (or the update location in the GUI) after the initial install. Note that the credentials you used to access the share re not transferred to the config file (as they are not available). Running setup.exe without switches opens the install GUI which asks for credentials and saves them in the config.

HTH

Christian

Christian, Thanks! I do not want to specify a user/pwd combination on the commandline based on the environment here at my client. Question: How does the client get a policy from the server before the whole install is complete?

I noticed that when I editted the username and password, a file iconnlocal.cfg was created with the username and an encrypted password in it. Tried to overlay the iconn.cfg file in SophosUpdate but install throws a "does not match manifest" error.

All I need is a way to give a CD to primarily disconnected users that runs a complete install creating a managed client.

Thinking about it though, if a user is "disconnected", how can the endpoint even register with the Enterprise Console? Or, will it see the EC information and keep trying to register until it is successful?

Thanks again!!!!

I do not want to specify a user/pwd combination on the commandline

As you noted, the credentials are stored in iconn.cfg and while they are not in plain text the "obfuscation" is of course reversible. But in the general case this is sufficiently safe. You can use obfuscated credentials on the command line (using ObfuscationUtil.exe). Please see here for building a CD installer.  

If a client is not in a location where it can reach the management server it will nevertheless setup RMS (mrinit.conf contains the necessary information) and keep trying (and eventually successfully register given it joins you network at some time in the future).

Christian