FRiC
-
Posts
83 -
Joined
-
Last visited
Posts posted by FRiC
-
-
I had the same experience. Upgrading to 11.0.2044 by selecting computers to upgrade, and selecting Restart when needed.
The install finishes but clients don't reboot, as if Restart when needed was not selected. I didn't check if there was a countdown screen though.
This is both Windows 10 and 11, latest CU.
Edit: I'm using Endpoint Security.
-
Just upgraded to ESET PROTECT on-prem 11, and the single Windows 7 computer in my domain retained the versions as previously: ESET Endpoint Security 9.1.2063.0, and ESET Management Agent 10.1.1292.0.
Other computers are already on EES 11.0.2032.0 and Agent got upgraded to 11.0.503.0.
Hope this helps.
-
12 hours ago, LesRMed said:
I updates several of my computers on Friday from the Computers screen by clicking the ones I was ready to update and then selecting Update installed ESET products. I assume it would be the same as from the dashboard like you're doing, but I saw no problems. All computers updated and restarted within a couple of minutes.
Thanks, I think it was a general Internet issue. The normal update also goes on forever. If this continues I'll have to check which server/route the updates are taking.
-
From the ESET PROTECT Dashboard I click on Update installed ESET products in the Component version status panel, then select clients from there, and whether to reboot or not after the update is finished, and a software install task is created.
There are two tasks in my screen shot, one is to reboot and one not. They've been running all day today and thankfully are almost done now.
-
Sorry, forgot to mention we're using PROTECT On-Premises. Yeah, normally I just click on Update installed ESET products and it automatically creates a task. Well, I've been at this the whole day and it's taking anywhere between 1 to 8 hours for the task finish and reboot the computer. Some are still running right now.
-
Hi, whenever a new ESET version is released we always manually create upgrade tasks so we can control the upgrades. It usually takes a few minutes for the task to finish and for the clients to reboot, but this time it's taking literally hours and hours for the task to finish. Is there something special about this upgrade, or it's just some random slow Internet issue? Thanks.
ESET Endpoint Security and a mix of Windows 10 and 11 Pro. Latest CU.
-
We were having issues with printer sharing which seemed to be fixed by using the pre-release channel, but when it automatically upgraded to 1.0.2050 the problem came back. Still working with the users to track the issue down.
Our non-pre-release channel systems still have not gotten the newer firewall module.
-
48 minutes ago, jeffshead said:
I just tried again. Mine is still inbound only. Maybe there is an update caching issue somewhere. Is there a module version that I can check?
I tried enabling pre-release and it works for me. I notice the firwall module is now 1439 7/18/2023. Previously it was 1438.2 7/13/2023.
-
For me, users are having issues printing to shared USB printers. Symptom is that the client machine shows the print job spooling for a long time but eventually (5-10 minutes) does print out. Workaround is to turn off printer spooling on the host machine. Not even sure if this is related to ESET 10.1 yet but we've had no other changes this week.
-
Yeah it's happened twice this month, I have scheduled scans set at noon so it shouldn't try to start another scan, and it doesn't happen every time either.
Thanks, I'll raise a support ticket.
-
I forgot to write that this is ESET Endpoint Security 10.0.2045.0 running on Windows 10 Pro, latest update.
-
I've been having a small issue recently. I have scheduled scans for every Tuesday and Friday at noon and it's been running fine, but once a while as the image shows, it completes, but another entry says Scan did not run.
On the computer itself ESET also says scan is completed, but the icon is still spinning and the tooltip says "Scan is running...".
Is this a known issue or am I missing something obvious? Thanks in advance for any help or insights.
-
5 hours ago, Marcos said:
A reboot is not required, the application status should change to green automatically although not immediately.
Thanks Marcos, yeah after a while everything was back to normal. Unfortunately later in the day I'm showing 20+ EPNS unreachable again.
-
Do you actually have to reboot? Previously I was showing 40+ computers with the issue, now everything is back to normal on the management console and in the application, but I notice the tray icon is still showing the orange exclamation mark.
-
Couple hours ago I had 24 (out of 149) with this issue, according to the management console. Right now it's up to 45.
Hopefully can be resolved soon.
-
Just installed Feb 2023 patches on servers with issues previously. No problems now. Thanks. 😍
-
I see that 9.0.12017.0 is released and states "IMPROVED: Protected antimalware service will not time out any longer during boot when Windows updates keep the file-system busy".
Thanks for getting this out so quickly, but should I install it and reboot the servers before next Patch Tuesday comes around, or can I do both at the same time to save one reboot?
-
5 hours ago, winstonsmith84 said:
Marcos mentioned low hardware specs probably being a culprit and it seems like dual core CPUs can't get Eset started because of these updates.
For me it was old servers (Xeon E3-1225V5 4C with hard drives) vs. new servers (Xeon Silver 4215R 8C16T SSD). Fails on the old servers, and fine on the new servers. Doesn't matter how many cores or memory are assigned to the VM's. If speed is involved it could be the hard drives.
It only takes a few seconds to restart the service or reboot, but it'll be nice if this is resolved.
-
Well, the four servers I tested on (from Reddit thread above) are indeed older servers (E3-1225 V5 with 16 GB) so yeah, no way to speed them up. But since this is the first time this has happened so I hope it's only for this time. On my newer servers the updates worked fine.
- Trooper and Peter Randziak
-
2
-
12 hours ago, LesRMed said:
But the users still get a popup telling them to restart (you can only delay it so long). And from what I understand from other threads, protection is not active until the restart. I agree with @TvM, It would be a nice feature if we could push the update manually, in the way the automatic update works.
If you don't select the "Allow restart when needed" checkbox there's no popup. But I was under the impression that protection is still enabled, only new features will be enabled after restart. Will have to test more. But yes, I too agree we should be allowed to push out the update with the update feature and not having to do it manually.
P.S. And yeah, right now my users are not affected by pop-ups, restart issues, etc. because I push out the update after hours.
-
4 hours ago, TvM said:
It would be a nice feature if we could push the update manually, in the way the automatic update works.
So select a group of endpoints to be updated next time there is a restart.
You can already do that. I find it easiest to click on the product version bar in the dashboard and choose which endpoints to update, and whether they should automatically restart or not.
-
On 6/19/2022 at 12:34 PM, Nightowl said:
Are we good now to try the v9?, I have several servers that need to be upgraded but I was afraid since I was reading here
It's all working well for me now. (9.0.12013.0)
-
20 hours ago, SCI said:
Thanks for the info. We have a lot of servers, so manually doing an uninstall and clean install on each will take too long. Making the issue more complex is that these are Azure VMs, so all we really have are boot diagnostic screenshots to see what's going on. Going the safe mode approach really isn't an option. I guess we'll have to wait until the next build is released.
Yeah, I don't have that many servers and they're all on-premises. Last night a lot of my servers rebooted automatically due to a pending .NET update (oops!), and fortunately they all came back, even the dc's. Don't know if it's a fluke or if the issue was fixed by an engine update.
-
11 hours ago, SCI said:
Any update on this issue?
I tried exluding *.mui which didn't work, and it seems to be for a different product any way. For me it's random which servers (not just dc) it affects, and also rebooting many many times sometimes bring the server back. Servers that didn't get affected the first time may also not boot the next time.
Since a new ESET installs don't require reboots, what I ended up with was removing ESET in safe mode using the uninstaller tool, then clean install. Will see what happens next Patch Tuesday.
Unistall Agent with command line
in ESET PROTECT On-prem (Remote Management)
Posted
And if a password is set, you should use the /qb switch to add the password.
MsiExec.exe /qn /norestart /X{GUID} /qb password="your_password"