davidenco

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?

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>

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.

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, 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?

Please count me in. Thanks.

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?

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.

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.

Excellent, glad it's not just me.

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.

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.

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.

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?

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?

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.

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.

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.

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!

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?

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.

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?

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

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?