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

    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

    :27397
Reply
  • 0

    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

    :27397
Children
No Data