Windows 7 Schedule Task Fail

Hi,

It sounds like you've done everything correctly.

http://www.sophos.com/en-us/support/knowledgebase/1462/1750/116755.aspx

is the main 'landing' article, which links off depending on environment.

Info for Domain env for 5.0:

http://www.sophos.com/en-us/support/knowledgebase/111180.aspx

Info for Workgroup env for 5.0

http://www.sophos.com/en-us/support/knowledgebase/29728.aspx

Based on what you describe, I would think EnableTaskScheduler2 and UAC off on the client in combination should do it.  I can only assume the key is in the right place and working

Worth checking that the command line that gets generated is OK, I.e. the client can resolve the SophosUpdate share based on the server address used..  

If you execute the dormant task it works?

Is there anything in the options of the task that would prevent it running on these machines?

Can you export the task to XML and show it here?

The only thing to say is, that SEC 5.1 is out very soon which has some changes in this area.  I suspect that will help so something for the near future to try as well.

Regards,

Jak

Hi jak,

Thanks for your response.

The client can successfully resolve to the client Sophosupdate share.

The dormant task works great if you run it manually and I cant see any options that would stop the scheduler from running the task.

Please find the xml code for the task:

<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.1" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
  <RegistrationInfo>
    <Author>sophos</Author>
  </RegistrationInfo>
  <Triggers />
  <Principals>
    <Principal id="Author">
      <UserId>shs\sophos</UserId>
      <LogonType>InteractiveTokenOrPassword</LogonType>
      <RunLevel>HighestAvailable</RunLevel>
    </Principal>
  </Principals>
  <Settings>
    <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
    <StopIfGoingOnBatteries>false</StopIfGoingOnBatteries>
    <IdleSettings>
      <Duration>PT600S</Duration>
      <WaitTimeout>PT3600S</WaitTimeout>
      <StopOnIdleEnd>false</StopOnIdleEnd>
      <RestartOnIdle>false</RestartOnIdle>
    </IdleSettings>
    <Enabled>true</Enabled>
    <Hidden>false</Hidden>
    <RunOnlyIfIdle>false</RunOnlyIfIdle>
    <WakeToRun>false</WakeToRun>
    <ExecutionTimeLimit>PT259200S</ExecutionTimeLimit>
    <Priority>5</Priority>
  </Settings>
  <Actions Context="Author">
    <Exec>
      <Command>\\UPDATE\SophosUpdate\CIDs\S000\ESXP\setup.exe</Command>
      <Arguments>-ouser "BwifJF33gL2xd2pgHZDwp++lDVUexKsKS4l0g2cATHP9edx0S4E8iO32XNYGl/JcRxg=" -opwd "BwgCiGrhXA5GjqIcptN76d2ELlQLaclALMdjhvU/Am0uxg==" -mng yes -s -xp "\\UPDATE\SophosUpdate\CIDs\S000\ESXP" -crt R</Arguments>
    </Exec>
  </Actions>
</Task>

Thanks again,

Dean

Based on the XML, I'm not convinced the registry key is being used.  So it's still using the verison 1 interface.  This would explain the symptoms.

Can you check that the key is correct, as you're 64-bit it should be under:

HKLM\Software\Wow6432Node\Sophos\EE \

DWORD

EnableTaskScheduler2

Value 1

Once added restart the Sophos management service.  You could even check with Process Monitor the key is being read.

Then check the task XML export on the client again after another reprotect.

Regards,

Jak

Hi,

We have the key in the following location:

HKEY_LOCAL_MACHINE > SOFTWARE > Wow6432Node > Sophos > EE

EnableTaskScheduler2 = Value as '1'

We were told by Sophos support to change the DWORD to QWORD for 64bit systems. However, it hasnt worked as either WORD.

Will have a look at the Process monitor to see if we can see anything.

Thanks,

Dean

Hello Dean,

did you try to protect a fresh PC (i.e. one where deployment has never been attempted) when this key was set? Dunno how SEC creates/updates this task (and whether it attempts to delete a possibly existing one) - but if a tasks already exists as v1 it might not get "upgraded".

Christian

Hi all,

After some investigation it looks like that we can only successfully deploy Sophos when we are already logged onto the end stations as 'administrator', (that account only = not admin which is a copy and member of domain admin). Strange. If the station is logged off or on as someone else then the deployment will fail with the following errors:

- failed to uninstall 3rd party software

- cannot find specified path

Any suggestions,

Thanks

Hi,

Can you locate the file "avremove.log",  it'll be in the temp dir of the user which ran it.  E.g. %temp%. 

Maybe "Sophos ES setup.log ", would also be worth looking at.

I assume there is some other AV/Security product on these machines SAV is trying to remove first?  

Regards,

Jak

Hi Jak,

Thanks for pointing me towards these logs, they have been quite useful. It looks like its an rights issue when trying to copy the msi from the Sophos Server to the local machine. See logs below:

Failed Machine: (logged Off)

23/05/2012,10:21:45,Information,Verified that contents of CID C:\Users\admin\AppData\Local\Temp\sophosa match the manifest file,
23/05/2012,10:21:45,Information,Searching for third-party security software.,
23/05/2012,10:21:46,Information,Return Code 10 from third-party security software removal tool.,
23/05/2012,10:21:46,Information,Removal Tool Completed: No third-party security software found.,
23/05/2012,10:21:46,Information,Requesting Windows Installer 2.0.0.0,
23/05/2012,10:21:46,Information,Successfully loaded Microsoft Software Installer library.,
23/05/2012,10:21:46,Information,Installing RMS configuration...,
23/05/2012,10:21:47,ERROR,Access is denied.,

Successful Machine: (logged On)

22/05/2012,16:18:26,Information,Verified that contents of CID C:\Users\ADMINI~1\AppData\Local\Temp\sophosa match the manifest file,
22/05/2012,16:18:27,Information,Searching for third-party security software.,
22/05/2012,16:19:05,Information,Return Code 12 from third-party security software removal tool.,
22/05/2012,16:19:05,Information,Third-party security software removed successfully. A restart is required after Sophos software has been installed.,
22/05/2012,16:19:05,Information,Requesting Windows Installer 2.0.0.0,
22/05/2012,16:19:05,Information,Successfully loaded Microsoft Software Installer library.,
22/05/2012,16:19:05,Information,Installing RMS configuration...,
22/05/2012,16:19:05,Information,Beginning installation of C:\Users\ADMINI~1\AppData\Local\Temp\sophosa\Sophos AutoUpdate.msi with command line BOOTSTRAP=noupdate REBOOT=ReallySuppress SOPHOS_TP_TOKEN=1 TRANSFORMS=1033.mst UPDATELOCATION="\\UPDATE\SophosUpdate\CIDs\S000\ESXP" UPDATEUSER="SHS\Sophosupdate" UPDATEPASSWORD="***" RMSACTION=7,
22/05/2012,16:19:06,Information,Action start 16:19:06: INSTALL.,

Not sure what rights need to be changed.

Thanks

Hello Dean,

note the different paths for the %TEMP% directory - dunno what's causing this (what's the path if a user other than administrator is logged on, BTW?). Though I'd expect the path to be in the installing user's directory - or a temporary one.

Christian

Hi all,

Looks like we've solved the problem with this issue. Looks like it was a UAC problem, we thought UAC had been disabled via group policy but this was not true. To completely disable UAC for the Sophos deployment we added the following in GPO:

- User Account Control: Behaviour of the elevation prompt for administrators for admin approval mode = Elevate without prompt

- User Account Control: Detect application installations and prompt for elevation = Disabled

- User Account Control: Run all administrators in admin approval mode = Disabled (Its worked after adding this one!!!)

Stupid UAC!

Thanks for all your help and suggestions

Dean