silnocus

Whoops, accidentally responded in that thread as well, but that worked. Thanks.

Huh. So far so good after doing that. Thanks.

So I upgraded from 6.4 to 6.5, and in accordance with the guidance on it I've been waiting on the database to upgrade. I haven't restarted the server or any of the services since I did the upgrade. The server won't let me log in, it just throws a response parsing error every time, which from what I've read on the forums seems to be normal during the upgrade. However, this has been happening for nearly a full week now. Is there any guidance on how long a database upgrade will take based on the size of the database? Should it ever take this long?

I've been trying to figure out the source of this for a few days now, but haven't made any progress beyond "they stop when I stop EraServerSvc." Here's what these events look like: An account failed to log on. Subject: Security ID: S-1-0-0 Account Name: - Account Domain: - Logon ID: 0x0 Logon Type: 3 Account For Which Logon Failed: Security ID: S-1-0-0 Account Name: Account Domain: Failure Information: Failure Reason: An Error occured during Logon. Status: 0xC000006D Sub Status: 0x80090325 Process Information: Caller Process ID: 0x0 Caller Process Name: - Network Information: Workstation Name: - Source Network Address: - Source Port: - Detailed Authentication Information: Logon Process: Schannel Authentication Package: Schannel Transited Services: - Package Name (NTLM only): - Key Length: 0 This event is generated when a logon request fails. It is generated on the computer where access was attempted. The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe. The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network). The Process Information fields indicate which account and process on the system requested the logon. The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases. The authentication information fields provide detailed information about this specific logon request. - Transited services indicate which intermediate services have participated in this logon request. - Package name indicates which sub-protocol was used among the NTLM protocols. - Key length indicates the length of the generated session key. This will be 0 if no session key was requested. There are about 6 of these per second while the service is running. They stop immediately when I stop the service. Searching for the status and substatus codes doesn't seem to give me any relevant information, at least as far as I can tell. Does anyone have any ideas what part of the RA service might be causing these?

We're getting many thousands of these errors in the event logs on our RA server, running the latest version of the server (6.4.295.0) on Windows Server 2012 R2. An account failed to log on. Subject: Security ID: S-1-0-0 Account Name: - Account Domain: - Logon ID: 0x0 Logon Type: 3 Account For Which Logon Failed: Security ID: S-1-0-0 Account Name: Account Domain: Failure Information: Failure Reason: An Error occured during Logon. Status: 0xC000006D Sub Status: 0x80090325 Process Information: Caller Process ID: 0x0 Caller Process Name: - Network Information: Workstation Name: - Source Network Address: - Source Port: - Detailed Authentication Information: Logon Process: Schannel Authentication Package: Schannel Transited Services: - Package Name (NTLM only): - Key Length: 0 This event is generated when a logon request fails. It is generated on the computer where access was attempted. The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe. The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network). The Process Information fields indicate which account and process on the system requested the logon. The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases. The authentication information fields provide detailed information about this specific logon request. - Transited services indicate which intermediate services have participated in this logon request. - Package name indicates which sub-protocol was used among the NTLM protocols. - Key length indicates the length of the generated session key. This will be 0 if no session key was requested. I'm hitting a wall on where these could be coming from. The event log entry itself isn't very useful. Is there any process that any ESET product uses that uses the SID from this event? I've done a little testing and the errors stop when I stop the ESET Remote Administrator Service, as well.

Thank you. Any kind of workaround/fix would be acceptable at the moment, since our mail server is bearing the brunt of this issue.

Any updates? This is beginning to become a real problem because of the sheer volume of emails our clients are creating.

It's Endpoint Security 6.3.2016.0, and Configuration module is 1277.6 (20160413)

I've checked on a few computers that are physically nearby, that were also generating the emails in question, and yes, it looks like the policy is applied. Their settings under email notifications are greyed out and match the settings in the policy exactly.

I've attached a screenshot of the relevant policy settings, obviously with obfuscated identifying information. As you can see, I have the minimum verbosity setting at "Critical." Yet I continue to get Error level messages from my endpoints. This policy is currently applied to the "All" group, and all of its other settings are demonstrably taking effect because I was able to change the recipient address and the interval and it updated all of our endpoints accordingly. I've even tried changing the minimum verbosity to a lower level then re-raising it to critical, but to no effect.

I've just upgraded all of our client PCs with the newest RA agent, and I have "Minimum verbosity for notifications" set to "Critical" but they are all sending "Error" level messages at a near constant rate. I had to redirect all of the emails to my personal inbox so as to not flood our helpdesk with unnecessary tickets. The error messages being sent by email are for "Failed to create rule" for the personal firewall module of endpoint security, which is undoubtedly being caused by our firewall policy's rules which have items whose path is either 64-bit or 32-bit dependent, and I have both versions in the same policy for simplicity's sake. Is there any fix for this? Either to make the agents heed the minimum verbosity policy, or if there is a way to simplify firewall rules while keeping everything in the same firewall policy, as creating a second policy would require entirely too much time given our mixed-architecture environment. Thank you.

Applying Hotfix KB2664888 has worked on every computer we've tried it on so far. I'm going to go ahead and call it a win. Thanks for all your help!

Installing the hotfix is important. Replacing network.dll is just a workaround to prevent the bug in Windows Filtering Platform from manifesting, however, the bug will still be there and certain network-aware applications that utilize WFP may trigger the very same issue. Apparently so, it's happened again a few times. Strangely enough, we've found that just opening Computer Management and connecting to the offending computer with it seems to immediately resolve the issue, so we've found a temporary fix for our particular situation. Regardless we've begun installing the appropriate hotfix on the computers displaying the issue. I'll post back here in a few days with results. Thanks for your help.

There are dumps, but they are empty, showing 0 KB, nothing when opened in Notepad++. Would you still like me to upload them? I've applied Part I of that KB article to the ERA Server (replacing the network.dll). If the issue continues until tomorrow morning, I'll try Part II (installing the hotfix).

We've been having an intermittent issue with ESET Endpoint Security on our client machines located within the domain, in that ekrn.exe will hang when a user tries to log in (usually first thing in the morning) causing the computer to get stuck at the Windows 7 "Welcome" loading screen. With some luck, we can get them logged in after a time, sometimes by simply waiting, sometimes by force-restarting the computer. The computers this happens to don't all do it every day, although some of them do. We've tried reinstalling Endpoint Security on these PCs, but to no avail. I've attached a "Report.wer" (renamed to .txt) from Windows Error Reporting, which, as far as I can tell, is the same error that shows up on every computer that does this. The Event Log shows nothing particularly helpful other than that "ESET Service" failed to start. This has been occurring since we started using this product, about 2 months ago. I've run out of ideas, and would really appreciate any help, or if this is a known issue with a fix, some direction. Thank you. Report.txt