Suppress Popups on End-Client for AV Update 'Errors'

Hello jdobiash,

the Exploit Protection needs to be updated
I get the yellow overlay that disappears after a short while (same as with the other Restart required messages). The updating log contains Message: Restart required for Exploit Prevention updates to take effect, also the message in the console is Restart required for Sophos Exploit Prevention updates to take effect (all emphasis mine).

Is EXP indeed already installed?

Christian

Yes, EXP is already installed on all of the computers.   The "Restart Required" message also shows up in both the console and client logs as well, but it's that one "Error" that keeps messing things up.

So looking at the logs a little deeper, it gets more interesting.  

Prior to 10/1/2018 4:08:28am (Pacific), no errors or request for restart

On 10/1/2018 4:08:28am, Message: Restart required for Exploit Prevention updates to take effect

This stays this way (without the ERROR but with it saying a restart is required) until 10/2/2018 6:08:20am, which at this point it starts also adding the error and pop-up. 

It looks like another EXP update attempts to install, at which point it can't install it because the machine needs to be restarted prior.    Up until then, it said "Installation of Sophos HitmanPro Alert Skipped", but this time it says "Installing Product Sophos HitmanPro Alert", followed by the "ERROR" from my first message.  

After that, the pop-up comes up for the user when logging in, even though the regular AV components are still updating properly.

Hello jdobiash,

apparently a pending install blocks a subsequent download (of a newer version). Why would someone want to delay the installation for several weeks?

Christian

QC, I appreciate your responses, but I'm not sure what you mean by 'several weeks'.  The updates literarily were about 24 hours apart from each other.   I'm probably just going to open a ticket (though I don't feel I'll probably get a satisfactory response based on my experiences with Sophos Support as of late) and see if there is anything that can be done to either suppress the 'error' message or change the updating logic so it doesn't occur in the first place.  Thanks for your time.

Hello jdobiash,

sorry, my bad. Somehow misread your reply and was under the impression the previous update hasn't been done. Carried away by some other problem ... but that's not an excuse.

Haven't observed that it more or less immediately turns into an error, delayed the reboot for days several times. Nevertheless I think it "shouldn't happen" unless, perhaps, the CID is changed ...

Christian

No worries.  My main concern is that apparently Sophos is now expecting us to reboot 500+ machines on a near weekly basis to make these issues not appear.   Normally our computers only get rebooted monthly when Windows Updates are applied.   It was never a problem before Exploit Protection was added.  If the computer needed to restart to update the AV components, it would just sit there and quietly continue to work (with protections still enabled and it would also get definition updates) until such time that the reboot occurred.  But now, when EXP gets updated, it causes the entire updating process to 'error' out (once another update happens, which can be a soon as 24 hours later apparently).   Ideally I'd like it to function just like the AV side does, and sit there quietly until the reboot happens. 

It's not OS specific, as it happens on Windows 7, 8 and 10.

Anyway, thanks again for the input.

Hello jdobiash,

so ... first it said skipped, later it was Installing but this eventually failed. Guess the ALUpdate log doesn't have more details but for the Installing there should be an associated log in %windir%\Temp\. Why did AutoUpdate no longer skip the install attempt - is there anything in the ALUpdate logs? Is there perhaps some hint in the HitmanPro logs in Temp?

Christian

It only 'Skips' when there is nothing to install.  Once there is something to install, it tries to install it.  The reason EXP fails when installing is because there was already a pending reboot due to the previous install (which occurred the day prior).   There aren't any actual issues with the installation of the product, it simply can't install because it needs a reboot first.  The problem is that it reports it as an error, rather than just quietly finishing, like it does when SAV encounters this same situation.     I'll probably open up a ticket and see if they can do anything about it, but I'm not going to hold my breath.  Thx!

Hello jdobiash,

yes, skip means nothing new nothing to do. When an update is available it should, as said, result in a 0x000000c1 - restart required for updates to take effect. Haven't seen that this changes to the mentioned error after some time. Received the last EXP update (3.7.6.756) around 1:40 p.m. UTC+2 (so roughly the same time as you) and there was no other EXP update.

Checking %windir%\Temp\ I see that subsequently there were three updates of hmpalert.bf (probably kinda supplemental definitions), the first on 10/2 around 3pm. These updates also trigger an install albeit a minor one that doesn't require a subsequent reboot. I'm pretty sure this is what triggered the error as the install log contains Executing step: Validate that HMPA is not pending reboot.
Found a relevant log:
a 2017-12-15 14:39:52.211 [5412:4932] - Beginning install
a 2017-12-15 14:39:52.212 [5412:4932] - Executing step: Validate it is NextGen endpoint
a 2017-12-15 14:39:52.212 [5412:4932] - Executing step: Validate the user is an admin
a 2017-12-15 14:39:52.212 [5412:4932] - Executing step: Validate that HMPA is not pending reboot
w 2017-12-15 14:39:52.212 [5412:4932] - Validation failed
a 2017-12-15 14:39:52.212 [5412:4932] - Reboot required by execute step: Validate that HMPA is not pending reboot
w 2017-12-15 14:39:52.212 [5412:4932] - Failed step: Validate that HMPA is not pending reboot, rolling back previous steps
a 2017-12-15 14:39:52.212 [5412:4932] - Rolling back step: Validate the user is an admin
a 2017-12-15 14:39:52.213 [5412:4932] - Rolling back step: Validate it is NextGen endpoint
w 2017-12-15 14:39:52.213 [5412:4932] - Failed composite step
e 2017-12-15 14:39:52.213 [5412:4932] - A reboot is required before the installation can proceed

As far as I can see a .bf update might follow within several hours, often the next or next but one day, sometimes more.

Christian

Hello jdobiash,

yes, skip means nothing new nothing to do. When an update is available it should, as said, result in a 0x000000c1 - restart required for updates to take effect. Haven't seen that this changes to the mentioned error after some time. Received the last EXP update (3.7.6.756) around 1:40 p.m. UTC+2 (so roughly the same time as you) and there was no other EXP update.

Checking %windir%\Temp\ I see that subsequently there were three updates of hmpalert.bf (probably kinda supplemental definitions), the first on 10/2 around 3pm. These updates also trigger an install albeit a minor one that doesn't require a subsequent reboot. I'm pretty sure this is what triggered the error as the install log contains Executing step: Validate that HMPA is not pending reboot.
Found a relevant log:
a 2017-12-15 14:39:52.211 [5412:4932] - Beginning install
a 2017-12-15 14:39:52.212 [5412:4932] - Executing step: Validate it is NextGen endpoint
a 2017-12-15 14:39:52.212 [5412:4932] - Executing step: Validate the user is an admin
a 2017-12-15 14:39:52.212 [5412:4932] - Executing step: Validate that HMPA is not pending reboot
w 2017-12-15 14:39:52.212 [5412:4932] - Validation failed
a 2017-12-15 14:39:52.212 [5412:4932] - Reboot required by execute step: Validate that HMPA is not pending reboot
w 2017-12-15 14:39:52.212 [5412:4932] - Failed step: Validate that HMPA is not pending reboot, rolling back previous steps
a 2017-12-15 14:39:52.212 [5412:4932] - Rolling back step: Validate the user is an admin
a 2017-12-15 14:39:52.213 [5412:4932] - Rolling back step: Validate it is NextGen endpoint
w 2017-12-15 14:39:52.213 [5412:4932] - Failed composite step
e 2017-12-15 14:39:52.213 [5412:4932] - A reboot is required before the installation can proceed

As far as I can see a .bf update might follow within several hours, often the next or next but one day, sometimes more.

Christian

I can confirm the same entries in my logs:

a 2018-10-05 17:16:15.527 [5328:2996] - Beginning install
a 2018-10-05 17:16:15.527 [5328:2996] - Executing step: Validate it is NextGen endpoint
a 2018-10-05 17:16:15.527 [5328:2996] - Executing step: Validate the user is an admin
a 2018-10-05 17:16:15.527 [5328:2996] - Executing step: Validate that HMPA is not pending reboot
w 2018-10-05 17:16:15.527 [5328:2996] - Validation failed
a 2018-10-05 17:16:15.527 [5328:2996] - Reboot required by execute step: Validate that HMPA is not pending reboot
w 2018-10-05 17:16:15.527 [5328:2996] - Failed step: Validate that HMPA is not pending reboot, rolling back previous steps
a 2018-10-05 17:16:15.527 [5328:2996] - Rolling back step: Validate the user is an admin
a 2018-10-05 17:16:15.527 [5328:2996] - Rolling back step: Validate it is NextGen endpoint
w 2018-10-05 17:16:15.527 [5328:2996] - Failed composite step
e 2018-10-05 17:16:15.527 [5328:2996] - A reboot is required before the installation can proceed

So how come your machines aren't getting the 'Error' in the main log while mine are?

Main Update log (alc.log):

Time: 10/5/2018 10:16:15
Message: ERROR: The computer must be restarted before product Sophos HitmanPro Alert can be installed
Module: ALUpdate
Process ID: 5328
Thread ID: 2996

It's this 'Error' that's causing the Pop-Up and message to the users.    When the AV components require a restart, they DON'T prompt the user with any sort of pop-up, they just sit there and wait for the next restart.  This is what I want the EXP updating process to do.

Hello jdobiash,

my log is from December. Likely the error popped up but I can't verify (and I definitely don't remember).
It is as far as I can see by design that a pending reboot because of a software update turns into an error when there is a subsequent definition update for HitmanPro.Alert. I assume this is deliberate and not an oversight so you'd likely have to make a good case for this to be changed.

Christian