[ESMC claims all PCs are running outdated software?]

On 8/28/2018 at 2:45 PM, Cousin Vinny said:

Is ESMC reporting that these outdated machines have the 6.5 Agent still installed?

If that's the case, there are just two registry keys that need to be deleted that the v7 agent installation fails to remove.

"HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\07F21F149AF55F34494F355BE44BEE4C"
"HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{41F12F70-5FA9-43F5-94F4-53B54EB4EEC4}"

My apologies, I assumed the keys you mentioned were the ones I had already deleted, so now there are a total of 4 separate keys that the Agent installer fails to remove.

I have removed these additional keys and the problem has been resolved.

I trust (and hope) ESET has identified why this is occurring and will address in the next Agent release?

[XmonSmtpAgent: Failed to process ON END OF HEADERS event]

Since installing ESMX v7, the following events are being logged into the Event Log on a regular basis. Any ideas why?

Log Name:      Application
Source:        ESET Reporting Service
Date:          29/08/2018 09:14:18
Event ID:      0
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      L1VS02XS.reades.local
Description:
XmonSmtpAgent: Failed to process ON END OF HEADERS event. System.NullReferenceException: Object reference not set to an instance of an object.
   at XmonAgent.XmonSmtpReceiveAgent.GetIpFromReceivedHdr(String& sOIp, IMailScannerServices& cMailScannerServices, EndOfHeadersEventArgs& args)
   at XmonAgent.XmonSmtpReceiveAgent.OnEndOfHeaderHandlerSpf(ReceiveMessageEventSource source, EndOfHeadersEventArgs args)
Event Xml:
<Event xmlns="hxxp://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="ESET Reporting Service" />
    <EventID Qualifiers="0">0</EventID>
    <Level>2</Level>
    <Task>0</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2018-08-29T08:14:18.000000000Z" />
    <EventRecordID>6537662</EventRecordID>
    <Channel>Application</Channel>
    <Computer>L1VS02XS.reades.local</Computer>
    <Security />
  </System>
  <EventData>
    <Data>XmonSmtpAgent: Failed to process ON END OF HEADERS event. System.NullReferenceException: Object reference not set to an instance of an object.
   at XmonAgent.XmonSmtpReceiveAgent.GetIpFromReceivedHdr(String& sOIp, IMailScannerServices& cMailScannerServices, EndOfHeadersEventArgs& args)
   at XmonAgent.XmonSmtpReceiveAgent.OnEndOfHeaderHandlerSpf(ReceiveMessageEventSource source, EndOfHeadersEventArgs args)</Data>
  </EventData>
</Event>

 

[ESMC claims all PCs are running outdated software?]

The PC that the Agent resides on has been restarted numerous times since ESMC was installed and the Agent was upgraded.

ESMC claims all our servers are also running the v6 Agent, but they're not and they have been restarted recently too.

[ESMC claims all PCs are running outdated software?]

[ESMC claims all PCs are running outdated software?]

Those registry keys have already been removed. I had to do that manually to my PC to remote the old Agent 6.5 entry from "Features and Programs". Since the entries were removed (over a month ago) the PC has been rebooted, as has the ESMC appliance.

[ESMC claims all PCs are running outdated software?]

ESMC claims all PCs are running outdated software, in particular the ESET Remote Administrator 6.5. One of the PCs mentioned is my workstation, but according to APPWIZ.CPL, the only ESET products installed is Endpoint Antivirus and the Agent, both version 7.

Some PCs may well be running version 6.5 but I need to know which PCs specifically, otherwise I will have to manually go through each PC which is a waste of time.

Why is ESMC saying this and what can I do to only show the affected PCs?

[ESMC (ERA7), EDTD, EEI, Endpoint v.7 Early access signup]

Please count me in. Thanks.

[ESLC cache cleared on reboot?]

When I reboot my ESLC appliance, the stats are reset to zero. Does this mean the cache is being cleared when the appliance is rebooted?

[Shared Cache SSH Access?]

I have installed the OVA file on to XenServer, which works fine by the way. The only gripe is the tools are not included.

On that note, why does ESET not have any appliances for XenServer? Both ERA and ESLC works on XenServer, and with ERA I have already installed the XenTools via SSH.

[Shared Cache SSH Access?]

I am running ESLC 1.2.5 but I cannot find a way to access the shell to install the virtualization tools. Any help would be appreciated, thanks.

[Is EMSX greylisting the wrong domain?]

Excellent, glad it's not just me.

[Is EMSX greylisting the wrong domain?]

I have cleared the whitelist for the purpose of this test. I don't have any examples from hotmail.com just yet, so will use a domain I do have.

Domain "russellrussell.co.uk" with IP "195.245.230.132" and HELO domain "mail1.bemta25.messagelabs.com" has been whitelisted.

Initial log entry said action was "rejected" and time remaining "10". At this point the domain was whitelisted and upon opening the advanced options and looking at the whitelist, the domain was listed and in bold with a + next to it and IP range "195.245.230.0 - 195.245.231.255" appears under that domain.

Repeated attempt from same HELO, IP address and email address resulted in the action "rejected (not verified yet)" and time remaining still "10".

After 10 minutes, the email has now been received, but should never have been greylisted in the first place in accordance with the whitelist.

[Is EMSX greylisting the wrong domain?]

You're missing my point. I am whitelisting hotmail.com but still seeing log entries for emails from hotmail.com being greylisted. It's not until I whitelist the HELO domain (outlook.com) that the emails from hotmail.com are then no longer greylisted.

Emails that originate from a domain that matches the HELO domain that are whitelisted are not greylisted. This issue only applies to emails whose email domain and HELO domain does not match, such as cloud-based providers.

It would be better if ESMX automatically whitelisted known email providers, just like cPanel does.

[Future changes to ESET PROTECT (formerly ESET Security Management Center / ESET Remote Administrator)]

6 hours ago, MichalJ said:

@Rémi Primary reason was optimization of dev/QA costs, where MySQL is platform agnostic, so can run on both Windows & Linux systems. MariaDB is only for Linux. We have received few such questions, however it never went "too high" into the priorities list, in order to be done. We have however such item in the backlog for the future releases.

Your information source is wrong. I administer an environment of both Windows and Linux servers, all running MariaDB since version 10.0! MariaDB is a drop-in replacement, and runs on Windows and Linux.

[EMSX - Whitelisted domains are ignored - Bug?]

In my greylisting whitelist, I have whitelisted the likes of Google, Outlook and so on. When we receive email from any of these domains, they are not greylisted. This is the expected behaviour.

When I use the "add domain to greylisting whitelist" option via the greylisting log, an entry is added to the events log file saying "Domains were successfully imported" and it's after this entry that every domain on the whitelist is no longer whitelisted. Now, any email from any of the whitelisted domains is being greylisted and the whitelist is being ignored.

To resolve this issue, all I have to do is go to the "Domain to IP whitelist" within the Advanced Setup / Greylisting Settings and click OK without making any changes. No log entry is added to say the domains have been imported; however now every domain on the whitelist is actually whitelisted and these domains are no longer greylisted.

Is this something you're aware of?

[Is EMSX greylisting the wrong domain?]

Windows Server 2012 R2
Exchange Server 2013 CU20
EMSX 6.5.10057.0

In EMSX, emails from Hotmail are being greylisted, so I am right-clicking the log entry and using the "Add domain to greylisting whitelist" option to add "hotmail.com" to the greylisting whitelist.

Despite adding the domain to the whitelist, emails from Hotmail are still being greylisted.

I notice the HELO domain is "outlook.com", so I have manually added this to the whitelist and now all emails from "hotmail.com" are no longer greylisted, but neither are any email address that use "outlook.com", such as "hotmail.co.uk".

It seems EMSX may be whitelisting the wrong domain, but then what domain is it using in the greylisting process to begin with? The email address or the HELO domain?

[VerifyFileContentSignature: Failed to validate PGP signature: Error while parsing]

As suggested by technical support and assuming you're using the Linux version, try deleting the contents of the cache folder (/var/cache/httpd/proxy) and restarting the ERAServer service. I did this and it worked for me.

[Problem pushing out updated EES from ERA6]

Just spoke to support again and they checked the global mailing list and found that there is a known issue with the repository at present and suggested deleting the contents of the cache folder (/var/cache/httpd/proxy) and restarting the ERAServer service. It worked for me.

[VerifyFileContentSignature: Failed to validate PGP signature: Error while parsing]

Exact same message for me! ESET told me yesterday there is a problem with the repository but no idea why it's not fixed yet.

[Problem pushing out updated EES from ERA6]

I'm surprised you're not advising customers that this is occurring due to a problem with your own repository. I spoke to technical support yesterday who confirmed there is a problem with the repository. In my case, when I try to deploy Endpoint Antivirus on to a Windows 10 PC, the agent is actually trying to download and install the Mac version!

Where are things up to in terms of resolving the repository problem? It's been nearly 24 hours since the problem was confirmed by ESET but it's still not working!

[XmonSmtpAgent: Failed to create greylisting engine]

I have done some digging and found that the message “This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms” is related to a local security option which was enabled on the server; something that is usually disabled by default. By disabling the option and rebooting, Greylisting just started working by itself and therefore the issue is now resolved.

The option is found in:

Administrative Tools > Local Security Policy > Local Policies > Security Options > "System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing."

Not sure why enabling this option should cause Greylisting to fail though?

[XmonSmtpAgent: Failed to create greylisting engine]

I am running Exchange 2013 CU20 with EMSX 6.5.10055.0.

Since 10:09 today, Windows Event Log has been recording weird events and the Greylisting log in EMSX has not changed, so I suspect Greylisting is no longer working. It looks like every time an email comes in and triggers Greylisting, the entry appears in Windows Event Log, so I am not sure what is happening to those emails either. Potentially emails are being lost here.

The log entry is as follows:

XmonSmtpAgent: Failed to create greylisting engine. System.TypeInitializationException: The type initializer for 'XmonAgent.XmonGreylistingEngine' threw an exception. ---> System.InvalidOperationException: This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms.
   at System.Security.Cryptography.SHA256Managed..ctor()
   at XmonAgent.XmonGreylistingEngine..cctor()
   --- End of inner exception stack trace ---
   at XmonAgent.XmonGreylistingEngine.GreylistingStatistics.Reset()
   at XmonAgent.XmonGreylistingEngine..ctor(UInt32 nDataHashMapSize, UInt32 nDataHashMapItemListSize)
   at XmonAgent.XmonSmtpAgentFactory.CreateAgent(SmtpServer server)

I have tried disabling transport protection, Greylisting and each of the modules in EMSX and re-enabling one-by-one but to no avail. The server has also been rebooted, but again no difference. A support ticket has been logged with technical support but so far nothing, so I thought I'd post here.

Any help would be greatly appreciated.

[ERA VA - Missing ODBC driver]

This doesn't work for me. After restarting mysql and eraserver services, the trace.log records this:

2018-05-10 15:40:26 Error: Service [Thread 7f297e4df740]: LoadAll: Group record is missing guard

Reverting to the ODBC 5.3 driver resolves the issue.

Any ideas?

[Spoofed Email Address]

Thanks filips, I have opted for the first rule suggestion.

[SPF & Greylisting - How do they work in ESET software?]

I have SPF checking and Greylisting enabled in Mail Security for Exchange Server 6.5.

The documentation says SPF checking has 3 states; Pass, Fail or Not Available.

I have enabled the option to bypass Greylisting if SPF passes but am I right in thinking that if an email does not pass SPF checking that Mail Security will perform Greylisting instead?