We'd love to hear about it! Click here to go to the product suggestion community
If like us you are on Windows 2008R2 and others could have the same issue our SEC stopped working as we couldn't install new clients this week they couldn't connect to the share for \SophosUpdates on the server it was all down to this.
Basically our user that was created for the share was in the admin group and the latest patches broke this. So either remove that user from the admin group or do the registry fix.
our useryou mean the account used in the Updating policies? Please note that its password stored in iconn.cfg is, although obfuscated, reversible. Users have read access and with a little effort they could extract the password. Therefore this account should never have any rights other than required to access the share, let alone administrative rights.
In reply to QC:
we aren't a AD house so just run a script on the client pc that connects to the server\sophosupdate and installs the software from there, so anyone in a similar situation if the user on the Sophos Server is in an Admin group it might break after the latest windoze updates.
Then every time the pc's log into Windoze we check all of them to ensure they have a sophos directory, if not we run the script again to reinstall it to ensure all our pc's have sophos on them.
In reply to StephanieGelder:
we are also (mainly) not an AD site. Of course whoever runs the script (if it's not SYSTEM) must be a local admin - but a different user (the one from the updating policy or some other) can be used to connect to the share. I can't say why this user should have admin rights. BTW: We are using packages created with the deployment packager. No clear text passowrds, no need to connect to the share - this is left to AutoUpdate.