Initial install source help

HI,

The account used by the client comes from the updating policy assigned to the SEC group.  The "admin" account you enter in the protect wizard is used to create the scheduled task.  The account AutoUpdate uses to drag files from the share is the one in the updating policy.

So the updating policy that is linked to the group you are protecting, is the username and password ok for the accounts?

Also, if you look at the properties of the scheduled task that is created on the client, does the command look correct, interms of paths, i.e. can the client resolve the location and access it as the account in the policy?

Regards,

Jak

Hello Mike,

there should be at least a hint why the source hasn't been found in the preceding lines.

Protect should create a task running setup.exe with the required parameters (-updp for the initial path) which should customize the iconn.cfg so that AutoUpdate can complete the install. What's in the non-working iconn.cfg?

Christian 

Hello Jak,

The account AutoUpdate uses to drag files from the share is the one in the updating policy

I wasn't sure about this - but which one would it be? Assuming you have a policy with Primary only which is HTTP and of course you have to specify the Initial Install Location - it wouldn't make sense if the credentials on the share had to be the same as those for HTTP, would it? In addition this policy doesn't contain a UNC path at all - so clearly at this point AutoUpdate must use information from "somewhere else" if accessing the UNC path or already use the Primary (HTTP) location.

Must admit though that I never tried to figure out the exact sequence (what is installed when and from where) but RMS has to be installed from the Initial Install Source. Or perhaps I'm just in need of a vacation ... :smileyvery-happy:

Christian

Hi all,

Still struggling to understand why. Here are the different conn files:

Non-working one thats pushed out during Protect:

[PPI.WebConfig_Primary]
AllowLocalConfig = 0
AutoDialTimeout =
LocalPath =
DownloadGranularity =
ConnectionAddress = \\[Server IP]SophosUpdate\CIDs\S001\SAVSCFXP\
PortNumber =
ConnectionType = UNC

[PPI.ProxyConfig_Primary]
AllowLocalConfig = 0
ProxyPortNumber = 8080

[PPI.WebConfig_Secondary]
AllowLocalConfig = 0
AutoDialTimeout =
LocalPath =
DownloadGranularity =

[PPI.ProxyConfig_Secondary]
AllowLocalConfig = 0
ProxyPortNumber = 8080

Working one:

[PPI.WebConfig_Primary]
AllowLocalConfig = 0
AutoDialTimeout =
LocalPath =
DownloadGranularity =
ConnectionAddress = [Server IP]/sophos/CIDs/S001/SAVSCFXP/
ConnectionType = HTTP
UseSophos = 0
AutoDial = 0
BandwidthLimit = 0
PortNumber =

[PPI.ProxyConfig_Primary]
AllowLocalConfig = 0
ProxyPortNumber = 0
ProxyType = 0

[PPI.WebConfig_Secondary]
AllowLocalConfig = 0
AutoDialTimeout =
LocalPath =
DownloadGranularity =
UseSophos = 0
AutoDial = 0
BandwidthLimit = 0
ConnectionAddress = \\[Server name]\SophosUpdate\CIDs\S001\SAVSCFXP\
UserName = [Server name]\SophosUpdateMgr
UserPassword = EPGcxUIKFnhModHCh6*****=
ConnectionType = UNC

[PPI.ProxyConfig_Secondary]
AllowLocalConfig = 0
ProxyPortNumber = 0
ProxyType = 0

HI,

The initial install source must get the credentials from the primary update location as if I setup the following:

• primary location as: "http://1.com/1" with no username and password specified.
• the initial install source in the updating policy has: "\\server\sophosupdate"
• the secondary update location has a UNC, with a username and password.  

The task that gets created on the endpoint has the following switches.

-ouser "" -opwd "" -mng yes -s -xp "\\server\sophosupdate\CIDs\S000\SAVSCFXP" -crt R

I would check that the account specified in the primary update location allows you to get updates from the initial install location, and that the password is correct.  I would suggest re-typing it back into the updating policy linked to the group, just to be sure it is stored correctly.

Regards,

Jak

Thanks for all the replies,

The primary update server points to a web server, this doesn't require a username or password; at the moment these details are not filled in. If I enter a username and password will the web updating still work and in theory allow the initial install source of a UNC share to authenticate using the details I've entered in the primary update tab?

Mike

Hello Mike,

I'd suggest you just give it a try. Judging from the web server logs AutoUpdate first makes an unauthorized request and retries the request using the credentials when it sees 401. Also the web server usually wouldn't care. I'm curious whether this solves the problem.

Christian

Thought I'd give a quick update after doing some testing. 

By defining the UNC path username and password it syncs this during the initial install iconn file; however the password I enter in the console is completely different to the one that is pushed out in the iconn file. At this point the install hangs and retries per the update frequency. By manually changing the defined password in the iconn file to the one that works the install then completes, then pulls down the same update policy again with the wrong password (not a issue with anon http updates). 

Hello Mike and Jak (and all the others reading this),

took me some time to understand what could be going on (my operating environment is near the specified maximum ambient temperature and this obviously slows down the brain :smileywink:).

As we rarely use Protect computers I've not given it much thought. As said before, at this step the policy can not have been obtained from the management server but I ignored the fact that the console does know the policy to be applied for the particular client. I assumed that for the initial install the credentials set in the wizard are used to access the update location. It seems that it is "just" used for initially running setup.exe but when AutoUpdate is run it uses the credentials carried over from the policy - i.e. SEC indeed takes the credentials parameters it sets for the install task (-ouser/-opwd) from the policy. 

If this is really the case. this is nowhere stated (at least, I haven't found it) - though admittedly it works similarly to the installer GUI. Guess Protect Computers more or less assumes that you generally use it in an environment where the Primary location is UNC But then the "credentials pitfall" with Initial Install Source should be documented as it is explicitly stated it must be used when the Primary is HTTP. Nevertheless - I can't see the rationale. The CID AutoUpdate uses is the same as the one setup.exe is run from, so why not use the same credentials?

Just my 0.02 €

Christian