Jump to content

JeremyS

ESET Staff
  • Posts

    9
  • Joined

  • Last visited

  • Days Won

    1

JeremyS last won the day on November 22 2014

JeremyS had the most liked content!

About JeremyS

  • Rank
    Newbie
    Newbie

Profile Information

  • Gender
    Not Telling
  • Location
    USA
  1. Hello Mahiralkhoir, I'm glad you discovered the name resolution issue; it is for that reason that we suggest you configure agents to use both ip address and name for clients to use to connect to the server with. Step 12 and onward from article: hxxp://support.eset.com/kb3701/covers how to add multiple addresses to use for agents connecting to the ERAS. Kind regards, ESET Customer Care
  2. Hello Dlaporte, You can sync the appliance Remote Administrator with Active Directory by way of the following KB: hxxp://support.eset.com/kb3665/. Be sure to write the AD servername, and the entire domain\username string in all capital letters. Those error messages don't reveal any clear cause or effect, on their own. What virtual environment are you hosting the appliance in? And at what version? Kind Regards, ESET Customer Care
  3. Hello Tobias, I submitted your request for inclusion of the ip address in the Console login failure entries, to our Market Requirement list. This list informs developer priorities for inclusion of new features in future builds. Kind Regards, ESET Customer Care
  4. Hello cmccord, -In the policy, navigate to Windows Server 4.5 -> File Security 4.5 for MS Windows Server -> General Settings -> Antivirus and Antispyware -> Exclusions -> Exclusions. If you click on Exclusions: 0 Entries you'll see the option to edit the list on the right pane. -From there, select "+Folder" and navigate to the highest level DPM Folder, wherever you have chosen to install it. Select "ok" to add it to the exclusion list, and note the *.* at the end of the folder path. This indicates that all subfolders are included in the exclusion. -ESET is rather legendary at detecting infected java scripts, and so my cautious recommendation is to submit archived copies of the detected files to samples@eset.com. In the subject line, include "Potential FP: JS/REdirector.NJU" and any other variant detections. In the body of the email include where the files are located and what purpose they serve. This will help the malware lab developers understand how vulnerable said files are to injection. To get the files out of quarantine and into an archive file, you can temporarily disable "Real-Time File System Protection" under the "Setup" section of File Security's main interface. -If you are able to, test older copies of the htm(l) files against File Security's scanner. If there is a difference even though you know that no major script changes were done within the files, I would begin to trust in the detections. Best Regards, Jeremy ESET Customer Care
  5. Hello Geosoft, The Remote Administrator Dashboard for Remote Administrator 5.x isn't configured to show a whole lot by default. You'll want to create custom report templates that reflect the sort of data you're looking for. A KB article on this can be found at: hxxp://kb.eset.com/esetkb/index?page=content&id=SOLN3037. Best regards, Jeremy
  6. Hello Jonathan, Would it be prudent to try updating ERAS to the current 5.2.22 build? You can create a sort of snapshot of the existing ERA data by backing up the C:\ProgramData\ESET\Remote Administration\Server folder. *Note that if you've configured the storage folders to save to nondefault directories, then you'll need to note the paths that those are stored at, back them up separately, and then restore to that path if need be. That said, if you stop the ESET Remote Administrator and RA HTTP services before running the ERA installer, you shouldn't have any issues with the upgrade. *Should you be prompted to reboot, ignore it and continue on with the installation. ERA installations never require a reboot in spite of Windows' occasionally claiming that. Upgrade the Console installations, re-login, and see if the issue persists. Alternatively, if this only happens with one client, you may want to see if anything about the default scheduled update task or else the update settings themselves are different from the other machines. If those are the same, then try ordering that client to clear its update cache and redownload the current update bundle. Best Regards, Jeremy
  7. Hello Digital, Unfortunately, we do not yet have an alternative deployment solution that matches a runtime-to-tunnel deployment option. For now you'll have to manually set up clients located in different networks. If you work for an ESET reseller, contact our sales department and inquire about becoming a Managed Service Provider. This will grant you access to a flexible license model and license management tools that will make it a lot easier to give each client of yours their own Remote Administrator Servers. From these, the clients can push installation packages out from within their respective LANS, going part-way towards the functionality that you're looking for. We are planning to release something like this feature in Remote Administrator 6, whereby a user installs a software management agent that connects over SSL back to the ERA server. The agent can collect system data, reach out to the server to look for configuration changes, and lastly to itself manage the install of one of our AV products. This includes downloading the installer from our server, then running it to completion with a desired configuration. Upon general release it should be deployable as a preconfigured installer for installation by less technical customers. I will have to inquire further as to the planned process for doing this. Best Regards, Jeremy
  8. Hi James, You can exclude Lync and Outlook from Protocol Filtering altogether, which should resolve any compatibility issues with either application. To do so, -Go into the Firewall section of the Desktop V5 policy tree. -Add the paths to Outlook.exe and Lync.exe as X'd entries within the Web Browsers section of Zone and Rule Setup. >This section of the Remote Administrator policy is the equivalent of the "ip addresses excluded from Protocol Filtering" section of the AV products' advanced configuration tree. >As an aside in case you were wondering, adding a checked entry to this list will make it so that ESET scans every packet sent and received by that application. By default, ESET scans an optimal sample of the packets. Checked entries correspond to adding executables to Web Access Protection's "active mode" list. Hi James, You can exclude Lync and Outlook from Protocol Filtering altogether, which should resolve any compatibility issues with either application. To do so, -Go into the Firewall section of the Desktop V5 policy tree. -Add the paths to Outlook.exe and Lync.exe as X'd entries within the Web Browsers section of Zone and Rule Setup. >This section of the Remote Administrator policy is the equivalent of the "ip addresses excluded from Protocol Filtering" section of the AV products' advanced configuration tree. >As an aside in case you were wondering, adding a checked entry to this list will make it so that ESET scans every packet sent and received by that application. By default, ESET scans an optimal sample of the packets. Checked entries correspond to adding executables to Web Access Protection's "active mode" list. Here is a link to a screenshot of the aforementioned settings: https://eset.sharefile.com/d/s8ab1792119e49bdb Q. What is the difference between the HTTPS Filtering Mode and the SSL Protocol Filtering? A. SSL Protocol filtering enables the scanning of packets belonging to any Layer 7 protocol making use of SSL encryption. HTTPS Filtering Mode toggles whether or not HTTPS traffic will be among the Layer 7 protocols scanned.
  9. Hello James, The settings that I recommend for best first-attempt SSL scanning compatibility are: -SSL protocol checking = always -Ask about certificate validity if the certificate cannot be verified using the Trusted Root Certification Authorities store= yes -Ask about certificate validity if the certificate is invalid or corrupt = yes -Add the root certificate to known broswers = yes -Apply created exceptions based on certificates = no -Block encrypted communication utilizing the obsolete protocol SSL v2 = no On a test machine that is temporarily unconnected to Remote Administrator, I'd try: -Adding the production site\software certificates to the "trusted certificates" section of the Certificate list submenu. -Testing a number of sites, and their subsites, that users need to access for work. -For a certificate that requires user interaction to go through ESET: >Try exporting the the authority certs located in the Windows Certificate Stores to the ESET Certificate list's "trusted" section. >See if you can access the given site without a prompt. If not, then you may need to import any needed site certs into ESET's certificate list within the relevant Remote Administrator policy. With the settings that I provided, most sites shouldn't give you any trouble. Self-signed intranet sites will give you problems, as those need importation into both the Windows Certificate Store as well as ESET's cert list. *Note that if the issue seems confined to versions of Firefox prior to 30.x, then update to the latest ESR or general release of Firefox to get that taken care of.
×
×
  • Create New...