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

    :27405
Reply
  • 0

    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

    :27405
Children
No Data