Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 1 subscriber
  • Views 5800 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

Initial install source help

RogueViper

I've been having trouble with using the 'protect' function in SEC. We have a synchronised laptop group based on an AD OU. When a laptop syncs over I go along and use the protect function; this pushes out the update client and the iconn.cfg file. At this point the install becomes stuck unless I manually copy over a working iconn file from another laptop to the config folder. 

It seems the iconn file is defined in the 'Initial install source'; for us it defines a UNC path as \\[Server IP]\SophosUpdate

The primary update source we use is web, so the source is http://[Server IP]/sophos with a secondary address set as \\[server name]\SophosUpdate plus the credentials for this share. 

Why won't the clients update using the initial install UNC path? The error we get in the update logs is - 

CIDUpdateLocation::SyncProduct: Failed to update product (Sophos AutoUpdate) from "\\[Server IP]\SophosUpdate\CIDs\S001\SAVSCFXP\", Error is :CIDSYNC_E_SRCNOTFOUND (Source not found.)

My initial thoughts were a permissions issue, but if I'm using my domain admin account details in the protect function and I can navigate to the initial install source in my own PC surely this isn't the issue?

Any help would be greatly appreciated.

Mike

:27393


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

    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

    :27679
Reply
  • 0

    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

    :27679
Children
No Data