Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 36 replies
  • Subscribers 1 subscriber
  • Views 105104 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

Mac OS - pre-configuring Autoupdate

QC

We have quite a number of Macs (not surprising at a university) but no official Mac support. Nevertheless we offer Sophos for Macs (in a downloadable .zip archive).  

When Sophos is installed on a Mac on our network it connects to the management server from where it gets the update policy (the CIDs contain the correct mrinit.conf for RMS to work). Of course this does not work if the Mac is used at home. For windows PCs putting sauconf.xml placed in the appropriate directory does the trick. There are some articles in the knowledgebase but usually a Mac is required with which you can configure the CID (if I understand correctly). I believe no magic is actually involved and the configuration is stored somewhere in a .plist file (XML format). I suspect that the catalogues are involved and configcid.exe does not support a CID for OSX.

Or is there a "simple" way to pre-configure autoupdate (even if it's unsupported)? sau.plist looks suspicous  :smileywink:

Christian

:518


This thread was automatically locked due to age.
  • 0
    Remote users is a big problem, but it's not the only problem.
     
    Even with a set mrinit and a sec on the dmz, remote clients can take up to 30 or 40 minted to get the updating details policies applied. That's 30 or 40 minutes without protection!
     
    Autoupdate setting need to be able to be applied in the installer. com.sau.plist trick no longer works
     
    Also you are assuming there is a perfect environment, machines communicating correctly and AD sync putting machines in the correct folder!
     
    Machines that are not advertising themselves with their Active Directory bound names but with screwed up netbios names go to the unassigned and get no policies.
     
    So you then have to go down the override route.
     
     
    So even after a script that will set this the problem ( which had taken me 2 days to write) is when the client machine is told to get a new version of the anti-virus software the override file gets overwritten and your back to square 1 again!
     
    Another work around that helps is the grouppath.plist to point machines to a predefined folder instead of unassigned so that at least they will get some policies applied if you have policies applied to that folder.
     
     
    The Dream
     
    1. updating details in to the installers on the shares (must not get overwritten by Sophos when polls with their servers when SUM runs)
     
    2. Sophos global batch file amended so that when SUM updates it doesn't strip out my group.plist every single time in the installers! Yes I have copied it in step 2 of the kb.
     
    3.  To be able to include overrides in the installer on the share and NOT get overwritten on the end client machine if already exists when the av update or atleast to say ignore to agent.config and don't overwrite it!
     
    Eg
     
    A.9.0.11 with overrides set
     
    B.Machines gets policy to have 9.1.7
     
    C.9.1.7 installs and wipes out the overrides on the machine!
     
    4. All these setting must be able to be applied and uploaded to our em account. When a client machines contacts It secondary location of Sophos, and updates its AV, then the settings don't get wiped out again!
     
    Sophos really need to start doing their on site user sessions again at Abingdon!
     
    Appreciate all you are doing to make things easier but it's very frustrating exposing thus over and over again to tech support on the phone ( oh no not Bill again) rather than to engineers like yourselves.
     
    It's also very frustrating not being able to speak with you face to face or on the phone and having to go by this forum in hope that the "Dream" may one day be a reality.
    :53811
  • 0
    kimpton wrote:
    Remote users is a big problem, but it's not the only problem.
     
    Even with a set mrinit and a sec on the dmz, remote clients can take up to 30 or 40 minted to get the updating details policies applied. That's 30 or 40 minutes without protection!

    This isn't strictly true. The endpoint enables its protection as soon as its installed, but of course its only as up-to-date as your cached installer is. Using stale installers is definitely an issue.

    We are pushing a lot of changes for the way that the CID works in version 9.2.2 and aiming to get that into the Preview line for on-premise customers next week. Some of the changes that will interest you:

    1. SEC/SUM will now know about the extra configuration files in the CID used by 9.2+ and not delete them
    2. the on-premise managed installer supports pre-configuration of AutoUpdate (just like the standalone installer)
    3. both installers allow pre-configuration of the on-access scanner settings
    4. updates to both installers for compatibility with Yosemite's Gatekeeper

    Not sure its going to achieve your dream yet, but we are getting closer.

    Also worth pointing out that my team is not in Abingdon, we are located in Vancouver, BC, Canada. You are welcome to visit anytime you are in the city! That same offer applies to anyone else on this list, and we've definitely had one or two people take us up on the offer over the last couple of years.

    :53813
  • 0

    great, thanks for the info Bob

    :53819
  • 0

    HI 

    Any info on the command line arguments etc for the 9.2.2 app and how i can configure and push out silently?

    Thanks

    Tim

    :54187
  • 0

    Hi Tim,

    If you run the tools without any arguments you get an informational listing with supported options. Here is what I got:

    CreateOnAccessPreconfig [-option {value} ...]

        the following options can be specified:

            '-AutoLaunch'         on-access scanning (YES = on, NO = off)

            '-InArchives'         archive scanning (YES = on, NO = off)

            '-NetworkVolumes'     network volume scanning (YES = on, NO = off)

            '-ExcludedItem'       file or directory path to exclude

            '-EnableDisinfect'    automatic cleanup (YES = on, NO = off)

            '-NonDisinfectAction  action if automatic disinfect fails (N = none, D = delete, M = move)

            '-NonDisinfectFolder  destination directory for moved threats

    CreateUpdatePreconfig [-option {value} ...]

        the following options can be specified:

            '-PrimaryServerUserName'        primary server user name

            '-PrimaryServerPassword'        primary server password

            '-PrimaryServerType'            primary server type : 0=Sophos, 1=Company Webserver, 2=Network Volume

            '-PrimaryServerURL'             primary server location

            '-SecondaryServerUserName'      secondary server user name

            '-SecondaryServerPassword'      secondary server password

            '-SecondaryServerType'          secondary server type : 0=Sophos, 1=Company Webserver, 2=Network Volume

            '-SecondaryServerURL'           secondary server location

            '-PrimaryServerProxy'           primary proxy type 0=system, 1=user defined, 2=none

            '-PrimaryServerProxyURL'        primary proxy URL

            '-PrimaryServerProxyPort'       primary proxy port

            '-PrimaryServerProxyUserName'   primary proxy user name

            '-PrimaryServerProxyPassword'   primary proxy password

            '-SecondaryServerProxy'         secondary proxy type 0=system, 1=user defined, 2=none

            '-SecondaryServerProxyURL'      secondary proxy URL

            '-SecondaryServerProxyPort'     secondary proxy port

            '-SecondaryServerProxyUserName' secondary proxy user name

            '-SecondaryServerProxyPassword' secondary proxy password

    The updates for KBAs are in the pipeline.

    Note that there is a problem with the CreateUpdatePreconfig tool when specifying PrimaryServerProxy or SecondaryServerProxy keys (these keys were added in this release for that tool) and I don't recommend using them yet. Other options are fine. If you really, really need those keys there is a workaround that requires editing the pre-configuration plist file (change the type from string to integer).

    Hope that preliminary information is enough until the KBAs are ready.

    :54189
  • 0

    Hi Bob,

    Thanks for the useful info. :)

    Of course (and forgive me if I overlooked this somewhere) I need to deploy this silently. As it stands now, my normal deployment tool will install any Apple Package format installer silently, but I have to call the Sophos installer via script, which is launching the GUI Sophos install for the currently logged in user. Is there a silent flag?

    :54229
  • 0
    Meat wrote:

    Hi Bob,

    Thanks for the useful info. :)

    Of course (and forgive me if I overlooked this somewhere) I need to deploy this silently. As it stands now, my normal deployment tool will install any Apple Package format installer silently, but I have to call the Sophos installer via script, which is launching the GUI Sophos install for the currently logged in user. Is there a silent flag?

    You probably want to have a look at KBA 14179: http://www.sophos.com/en-us/support/knowledgebase/14179.aspx

    Hope that helps, let me know if you find the article clear enough. Its an article with lots of poor ratings but not a lot of constructive feedback about what needs improvement.

    :54231
  • 0

    Works a treat! Thanks Bob.

    Added "cd /path/to/installer/directory" into my script and it works fine! 

    I will do some additional testing with a removal prior to install, as it is somewhat hit or miss if I install over the existing software (as one "might" expect. :) )

    If using a competent deployment tool with scripted installation, we can ignore the notes about being prompted for credentials, as the script should be run as root by default. 

    The instructions on the KBA 14179 are clear and informative. 

    Thanks again!

    :54239
  • 0

    I had previously built an Apple Installer package which contains a pre-configured copy of the Sophos Installer.app and a script which runs the InstallationDeployer tool. This was for version 9.0.x. This installer package can be either manually run, or deployed via ARD or Munki or insert-your-favourite-tool-here.

    By the way, the Sophos KB article on pre-configuring Sophos Installer.app appears to be out of date as it still describes the behavior of SAV 9.0.x and 9.2.2 at least acts slightly different. The main difference being that the updateconfig.plist is no longer contained within the Sophos Installer.app itself but is now placed in a folder outside this application.

    I have now updated my installer package to include SAV 9.2.2 instead so as to be Yosemite compatible and it seems to work as desired in that it runs silently and does install it and the resulting install does have the pre-configured credentials to auto-update directly from Sophos. I have to directly update from Sophos because they killed of Sophos Update Manager and we have no Windows server to run Sophos Enterprise Console on and Sophos stubbornly refuse to port Enterprise Console to Linux/Unix or OS X.

    So far the only issue I am finding is a minor one but annoying to me nethertheless.

    After automatically installing SAV 9.2.2 as part of my DeployStudio / Munki build process I am finding that when I first login to a freshly minted Yosemite Mac I get a dialog box appearing from Keychain Migrator asking for the password for the Sophos keychain. I of course have no idea what that password would be as it is used and created by Sophos. I therefore have to click cancel and then the login proceeds and completes normally. Sophos seems to run ok after this and the message does not seem to reoccur on subsequent logins.

    Anyone else seeing this?

    :54259
  • 0
    jelockwood wrote:

    I have now updated my installer package to include SAV 9.2.2 instead so as to be Yosemite compatible and it seems to work as desired in that it runs silently and does install it and the resulting install does have the pre-configured credentials to auto-update directly from Sophos. I have to directly update from Sophos because they killed of Sophos Update Manager and we have no Windows server to run Sophos Enterprise Console on and Sophos stubbornly refuse to port Enterprise Console to Linux/Unix or OS X.

    Updating from Sophos is typically more successful and reliable than what most folks can set up on their own. I would always encourage you to do it that way. This method of updating is also "friendly" (aka "works") with all HTTP cache products, whether its a commercial product like our web gateway or the open source Squid proxy.

    jelockwood wrote:

    After automatically installing SAV 9.2.2 as part of my DeployStudio / Munki build process I am finding that when I first login to a freshly minted Yosemite Mac I get a dialog box appearing from Keychain Migrator asking for the password for the Sophos keychain. I of course have no idea what that password would be as it is used and created by Sophos. I therefore have to click cancel and then the login proceeds and completes normally. Sophos seems to run ok after this and the message does not seem to reoccur on subsequent logins.

    Anyone else seeing this?

    I'm keen to hear more about this, its weird and unexpected. Definitely never seen it myself nor have we had it happen in our testing, but I can't say we would necessarily have the same endpoint configuration as you'd be running. Anything non-standard in your deployments that we should be trying?

    :54267