Device Control Not Working

I should also mention that I have registered a support call for this with SOPHOS (2714063) who advised running their diagnostic tool. Did this but the tool created files so large that all the free space on my server hard drive was filled and the diagnostic software failed. Haven't had any assistance since last week, pretty poor response, and not for the first time.

David

Hello David,

in the Sophos Anti-Virus Install Log_yymmdd_hhmmss.txt from %Windir%\TEMP (note that only the last four are kept so you'd have to reprotect a client to get the full log) there should be a line like: INSTALLDIR="C:\Program Files\Sophos\Sophos Anti-Virus\" ... DEVICECONTROL=1. Check if the Sophos Device Control Service is present on the client. There should also be a folder named C:\Documents and Settings\All Users\Application Data\Sophos\Sophos Device Control - if it's not then search the install log for errors.

In the agent log in C:\Documents and Settings\All Users\Application Data\Sophos\Remote Management System\3\Agent\Logs you'll see what SAV tells the agent (and eventually SEC)  on a line starting with [timestamp XXXX I] SAV state observer received a status:. The line should contain the string dev:deviceControlStatus.

I have seen and still see cases where this is missing even though the service is running. Most of the time it works again after one of the next reboots (or after reprotecting the client). It is known for quite some time and I've already  reported it with previous versions (apparently the root cause has not yet been identified). Thanks for the case ID, I'll also contact support [Edit: submitted as #2721426] 

Christian 

Christian,

Thanks for your reply. I think I know what the problem is.

Client machines are taking updates from \\MYSERVER\SophosUpdate\CIDs\S000\ESXP which contains no Device Control information. The update source for clients should be \\MYSERVER\SophosUpdate\CIDs\S000\SAVSCFXP.

I renamed the ESXP folder to ESXP.old and reprotected clients. They all updated from SAVSCFXP and I was able to activate device control :-)

However, when the SUM runs and downloads it only pulls down the ESXP data and the clients all revert to that. So back to our original problem.

The issue lies with our subcription. I recently renewed our license for updates and I think maybe someone at SOPHOS has not configured our updates. Could be wrong.

Until the server is updating the correct share data then it seems it cannot be rectified. Sophos Tech Support are looking into this. Lauren has been a big help so far in identifying the issue.

Regards

David

Resolved!!

Turned out it was a problem with the backend of the license at Sophos, which has now been corrected by them.

Clients now updating with device control active......at last.

Regards

David

The mentioned case is still progressing and might get escalated.

While this - esoteric - problem is not obvious, its cause is still in the dark and it affects only a small number of the clients at a time it nevertheless looks serious. And while I've first noticed it with 9.0 either no one else did or didn't deem it important enough to engage Support.

First a short summary of the symptoms and why I think it should be considered important:

In the console a small percentage of clients (all of them XP SP3) has one or both of Data and Device control blank (i.e. neither active or inactive). This doesn't fall into one of the predefined clients with problems categories (similar to clients where the SAV component has not (yet)  been reported after install). Thus you usually only notice when you select the corresponding tab and perhaps sort by the scanning or policy column.

For some reason the Agent fails at startup to communicate with the component and considers it absent (but doesn't consider this an error). No (DevC or DatC) state is reported to SEC and no policy can be applied. Although the required services are running on the client they are using the (factory) default policy - and in effect with Device or/and Data Control disabled - until the next reboot. 

It turned out that restarting the Agent remedies the incorrect state. Of course if the client is outside your network you can't initiate the restart. Thus it is possible that (admittedly only some of) your "outside" clients are partially unprotected - an very undesirable state. Worse - no one would notice at all (except perhaps the user who suddenly can plug in a device or transfer some sensitive document - but would they tell?).

Now the plea:

If your time permits - could you check if you find some connected clients showing this state? As it doesn't occur very often and rarely twice in a row the affected clients vary from day to day (of course depending on whether they are rebooted daily). I'm especially interested if any Win7 machines show this behaviour. I have not yet observed it with them but as they are not grouped together it's hard to spot them.

Thanks in advance

Christian