Campbell IT
-
Posts
73 -
Joined
Posts posted by Campbell IT
-
-
15 hours ago, Marcos said:
If I remember correctly, the whole communication protocol was changed in v7.3 so without rebooting the machine after the upgrade may cause protection to stop working. Please keep in mind that v7.3 will lose full support this month:
https://support-eol.eset.com/en/policy_business/product_tables.html
Terrific. Honestly, the constant upgrades are getting tiresome. It's almost a full time job to keep up with ESET upgrades.
-
We have about 20 Windows 2012 R2 servers that are running version 7.0 that need to be upgraded to 7.3 before the upcoming EOL date. Scheduling downtime for these servers is a challenge. If we push the upgrades to these servers without rebooting, what are the consequences of delaying the reboot? Will they be totally unprotected until the reboot? Any other issues we should be concerned about? Thanks.
-
12 hours ago, MartinK said:
I would definitely recommend to create two separate dynamic groups/templates and stack them - it would be more transparent.
Regarding second part, which should include only devices where no user from specific list of logged in, I think something like this:
should work. "Negative" design should make it work even in case there are multiple logged-in users reported, but this would have to be tested...I don't seem to be able to stack dynamic groups. Can you elaborate, or post a link to a KB explaining this?
-
I'm trying to get a dynamic group configured that includes all desktops in a certain subnet, but excludes a handful of logged in users, namely members of our IT team. What I am trying to accomplish is to get these desktops into a group so that we can apply a weekly reboot task to them as our users never want to reboot, preventing us from pushing updates.
So far, I can get all of the desktops in the subnet included in the group, but I cannot seem to exclude myself (or other IT team members).
Any help is appreciated.
-
14 minutes ago, Marcos said:
EFSW 7.0-7.2 will reach EOL in June 2022 according to https://support.eset.com/en/kb3592
Yes, I understand. That's why I am trying to upgrade to at least 7.3, but I have not been successful. Is there any solution?
-
We have a few legacy servers that can't be migrated to a newer OS and cannot be decommissioned yet. One such server is Microsoft Windows Server 2008 Standard Service Pack 2 64 bit with all Windows updates which is currently running 7.2.12004.2. I cannot install 7.3.12002.0 on it. The installer gives me a message about an incompatible OS. Any ideas how I can protect this server?
Thank you.
-
On 3/5/2021 at 9:34 AM, Marcos said:
You can ignore it for now since we have managed to find a temporary solution for affected products and systems. Yet we strongly recommend upgrading to the latest version as soon as possible since we won't be able to guarantee that Microsoft will trust the certificate for long enough. The notifications are going to be updated accordingly soon.
That would explain why I see changes this morning in the console. I had about 25 machines left to upgrade to get rid of this message and this morning, on most of them, the alert is gone.
-
It's out now. I was in the process of updating all of our workstations to 7.3.2044 and now all of a sudden this morning, 7.3 has been replaced by 8.0. I sure wish ESET would let us choose which version we want to install when we click the "Update ESET Products" button. At least leave the latest version and one version prior to that. I think we're all smart enough to know the difference and can make that decision for ourselves. I had to create an installation task to finish my rollout instead of being able to click the update button.
-
9 hours ago, Marcos said:
We haven't released automatic program updates for Endpoint yet; ESMC 7.2 will be a prerequisite.
Well, you have a bug then, because we have had several machines that I did not upgrade manually, but they upgraded on their own. I discovered this because I noticed there was an alert on a machine. The alert was that the machine needed to reboot to complete an upgrade. I had not upgraded the machine manually and I am the only one who administers the ESET server. I asked the user to reboot and after they did, the version was upgraded to 7.2.2055. This was while we were on ESMC 7.1.
-
14 hours ago, ShaneDT said:
Campbell IT I don't know that you're understanding what your problem is. If your computers are upgraded to 7.3, they are not shutting down due to upgrading, they are shutting down due to a bug in this version that triggers a shut down after a scheduled scan. You need to go into your policy settings and turn off the scheduled scans.
And as far as I'm aware the 'Program Update' policy does not and has never worked? I've never been able to get any of my endpoints to automatically update the EES software. Always have to deploy it manually from the server.
Well, I have 3 machines that until late last week, were on 7.2.2055 that are now on 7.3.2032. One of these machines is my workstation. All 3 of them had ZERO shutdowns after our weekly scan until yesterday when I was sitting in front my computer and watched it with my own two eyes as a prompt came up telling me it was going to shut down after the scan. I was able to cancel it, but the other two machines shut down as I was testing to see what would happen and I did not intervene.
I get that there is a bug in 7.3.2032.
So tell me how upgrading to 7.3.2032 did not cause the issue?
-
6 minutes ago, Topher said:
In your policy, navigate to Update>Settings>Updates>Program Component Update....Update mode should be set to Never Update
Thanks. It was set properly, but not forced.
-
I just experienced this on my machine. Fortunately, I was in the office today, so I was able to stop it from rebooting. My big concern is that we have had a few computers automatically upgrade themselves without any intervention on our part. Is there a way I can prevent any other machines from automatically upgrading? I currently have 3 machines on 7.3 and would like to keep it that way until this issue is fixed. I have a lot of people working remotely and not much manpower available to turn machines back on.
-
24 minutes ago, MartinK said:
It should be possible to send me a PM with attached logs.
I got a message that I could not send a PM to you. It doesn't matter, though. I was successful with my upgrade after I stopped the EraServerSvc service. Now I get to re-learn how to deploy the Agent.
-
13 minutes ago, MartinK said:
Strange. If you are interested of what is the reason for slow shutdown, I can possible check trace.log from ESMC Server from time when service shutdown was attempted. We are mostlyk seeing this to happen when task are executed or in case ESMC is under higher load, in terms of network connections and received data.
How do I send the log to you? It has hostname and IP address info in it, which I do not want to make public.
-
3 minutes ago, MartinK said:
Yes, manually stopping should help. Any chance you are executing some ESMC task in regular intervals? For example long running AD synchronization tasks might interrupt or block shutdown sequence.
The clients are checking in every 5 minutes. AD synchronization only occurs once a day.
-
I reviewed the logs myself and found these entries:
Error 1921. Service 'ESET Security Management Center Server' (EraServerSvc) could not be stopped. Verify that you have sufficient privileges to stop system services.
Info 1920. Service 'ESET Security Management Center Server' (EraServerSvc) failed to start. Verify that you have sufficient privileges to start system services.
I do have sufficient privileges. Should I manually stop the service before I attempt the upgrade?
-
It failed a the ESMC upgrade. I tried to send you a PM with the logs attached, but it said you can't receive messages. How do I securely upload logs to you?
-
I attempted to upgrade our ESMC 7.1 server to 7.2 by downloading the installer, running it on the server and choosing "Upgrade All Components". It upgraded SQL Express OK, then it took quite a while on the next step and then failed with a 1603 and 1708 error. Prior tests of this process on a snaphshot copy of our server worked flawlessly.
Any help is appreciated.
-
On 5/6/2020 at 11:42 PM, MichalJ said:
Hello @Marcelinho, you are most probably meaning installation of the latest product version. If your computers have still connection to the management server, even if they are working remotely agents are able to communicate, after you set a task to "install latest version of software", computers will connect to ESET Repository to download the latest application version.
For the future, we are working on micro PCU auto-update, meaning you will be able to set your clients to automatically download latest product version upon availability, and install it, where at the end only a prompt for reboot will be displayed for your end users. This is however not yet enabled, and should be enabled with the upcoming product release.
Please have an option to block automatic upgrades as you have described above. While it sounds good in principle, unless reboots are forced, you could end up with computers that have pending reboots for weeks. We struggle with getting our users to log off, let alone reboot. Plus, if there is an issue with an upgrade in our environment, we would need to be able to prevent the upgrade from happening on more computers. Thanks.
-
I had several machines detect HTML/ScrInject.B and for weeks, the detections would show up as unresolved. I finally got some time where the user would let me work on the system for a couple of hours and the only way I could find to actually get the detections to resolve was to run an in-depth scan with cleaning. It baffles me because these detections were reported after a smart scan. If there is some other easy (albeit, not intuitive) way do resolve detections, I would love to hear it.
Thanks.
-
I have found after working with ESMC 7.x for some time that the only way to permanently resolve detections is to run an In-depth scan with cleaning after a detection has occurred. Is there a way to configure ESMC so that when a desktop reports s detection, an in-depth scan with cleaning is scheduled automatically?
-
No, I installed ESMC 7 fresh some time ago and upgraded to 7.1.717.0 in the last few months.
-
9 hours ago, Marcos said:
Deleting files from quarantine does not resolve detections. Files can be kept in quarantine unless they take up a lot of disk space which usually doesn't happen; malware is typically quite small with the size even below 1 MB. In quarantine objects are kept in a safe encrypted form to prevent execution.
How do I know what detections have been resolved and no longer need my attention? I have set the filter to the Preset filter "All unresolved threats" and it shows all threats back to Oct 2019, even those that have a check in the column "Resolved". If they are resolved and I set the ESET Preset filter "All unresolved threats", why is it showing me resolved threats? It is very difficult to tell what computers need to be examined more closely.
Also, what does ESET consider as an action taken? Because that filter also shows detections back to Oct 2019 if I select "All threats without action taken".
Is this a browser issue? I am using FIrefox 75.0
-
Never mind. Now I see there is another tab. Everything was so easy in 5.x. Even after 18 months + of using 7.x, I still get stumped. It really needs to be redesigned and streamlined.
Disable "Your operating system is out of date" notification
in ESET PROTECT On-prem (Remote Management)
Posted
Absolutely! Most IT Admins know their environment well enough to know which machines are not up to date. I want my ESET product to tell me when there is a problem with ESET.