PatrickL

rockshox, I can confirm that this an Eset server that the software needs access to. Those IP addresses are part of the Live Grid. They change intermittently and should be monitored if any other IP address resolves to an Eset machine and does not seem to be published. Patrick

Zurd, The purpose of this field is to help create a logon script for you to point to using Group Policy. In the manual (download at: hxxp://download.eset.com/manuals/eset_era_5_userguide_enu.pdf ) in section '4.2.3.1 Export ESET Installer to Folder / Logon Script' it gives a decent description. In the dialogue at ERA when on the Remote Install Tab, right click and select Export to Folder or Logon Script. The first line is Type - and should default to the correct seeint of ESET Security Products for Windows. The next line down is package and should be the package you want to build the installer for (einstaller.exe by default). In the next one down, listed as Folder, select the network location where you want tostore the einstaller.exe file that will be the core of the installation (it needs to be a location that all computers have access to. the next part is about selecting the preexisting startup script that you want to inject the ESET installation line into. In Share, you need to point to where the einstaller is located (easily referenced from the folder category in the first part). Next in the Script folder, you need to point to a folder that houses your prexisting scripts. You can use the Files dropdown to filter the contents that appear at the bottom once the fodler is selected. The idea is that you are going to inject the line to run the einstaller.exe into the existing startup script file. You can edit it to the right if you select the edit option at the bottom. Once all this is completed to your preference, you can select Export to Logon Script and it will inject the isntaller line into the selected Script file from the menu above it.

Rick, I appologize that you were unable to find your answers in the help file. The solution to your answer is in the text on the screen. Allowed senders is more commonly known as "whitelisting". You can add people who are sending mail or domains (as in your example with gmail). You can either add Person1@gmail.com or gmail.com (which you will want to include the .com to specify that domain exactly). The allowed domains is in refernce to textual entries in the mail itself. The most common would be viagra.com. This entry garners a lot of spam scoring points and for companies that work directly WITH viagra.com, this would be a problem. You would use that entry to exclude that domain from gathering spam points for the reference to that domain. This is covered more specifically in the manual in section 3.3.2.1.4 (easily found by CTRL+F and searching for "allowed senders") under filtering. Patrick

segFault, Thank you for the policies. I need a little more information from you to get a thorough udnerstanding of the process that these new installations are going through. One question and one file request (reply to me with the file via PM, please) Question - in your policy tree you sent me, I need to know which is the default policy for new clients. Its easiest to tell by looking at the policy list and seeing which has a black box to the left of the policy name. Please look at your policy tree and advise me which is the default policy. The file request is a copy of the XML from a client machine that is not reporting. You upgrade the client with the install policy you sent and it reports to the tree you sent then it falls off. I need you to grab a machine, upgrade it, confirm its not reporting and then remote to that machine and export the XML from it and send to me directly via PM, please. With these ttwo pieces of information, I hope to be able to confirm my suspicions. Patrick

segFault, Can you advise me if these clients are new installations that you are referencing in your example? If so, can you export the configuration for your isntallation as well as the configuration for your default policy in Remote Administrator and send them to me via a direct message? If these are not fresh installs, then please send me the scenario that these machines are in as well as just the policy configuration (steps also below). I am wondering if the clients are installing with a 0 interval and reporting before the update happens and then there is a typo in the policy (or a null value marked) that has the client not reporting in anymore after the initial checkin. Please send me a copy of the configuration from your install package as well as the policy from your Remote Adminstrator for me to analyze. Steps for package configuration: Open the remote administrator and go to the remote install tab and click Actions>Manage package. Click edit on the left side to edit the policy and click ok on the version confirmation. When the configuration editor opens, click File>Export marked to... and save it somewhere you can access and name it 'install.xml'. Steps for policy configuration: Open remote administrator and click on Tools>Policy manager. In the dialogue that opens, there will be a policy with a black box (by default it is called Server Policy). Please double click on that policy and in the configuration editor that opens, click File>Export marked to... and save it somewhere you can access and name it 'policy.xml'. Please send those to me via a direct message so I can review them and assist. Patrick

Michael, There is no upgrade process that leads to Eset File Security for Windows Server, so no. You will need to uninstall cleanly to allow the installation. We have a knowledgebase article that discusses how to unisntall in these instances. Please follow the steps in the article below (please note that this requires safe mode, so you will need to schedule a service window most likely): hxxp://kb.eset.com/esetkb/index?page=content&id=SOLN2289 Patrick

Joecoo1025, The count that is determined by the Eset Remote Administrator is determined from the number of clients listed. That list (based on your ntoes) is set to clear old connections every two weeks. By default, this is set to 6 months. If the clients are cleared due to inactivity, then theyw ont show in the count for the head server (or child server, if the settings reflect that). To resolve this, you will want to access the settings for each of the servers and ensure that the timeframe is set to a value that will allow you to keep clients in the list that may not have connected but will reconnect but AT THE SAME TIME make sure that clients that are not going to connect are dropped (or cleaned up). Again, 6 months is the default. To access these settings, open the remote administrator console and click on Tools>Server options. Click on the Avanced settings tab and next advanced settings button (the only button available). Expand out Remote Administrator>ERA Server>Settings>Server Maintenance>Time interval cleanup>Clients log cleanup and set the numeric value and the base value (6 and months will clean up machines that have not connected for 6 months) to the appropriate value for your scenario (the number discussed earlier in this message). Ensure that you have it uniform across all three servers to ensure that at any time your client count will match. Once all the machines check in again you will have a value on the machines that add up and make proper sense. Patrick

Cruz, I can certainly help you determine the issues and resolve them. I will need some information from you that will contain confidential information, so I recommend that you send me the data I am asking for via a PM instead of this forum, please. Please send me: 1. sample of mail that was sent to the user OUTSIDE the organization that seems to be from your organization (save it and attach it, pelase) 2. Please export tothe configuration for EMSX and zip it up and include that as a reply also 3. If you can also use your Mail Tracking tool in the Exchange console to track the messages by subject that you sent (the message from request #1) to confirm 100% that it DID leave your company and is not being spoofed from outside your organisation, that will help significantly also. Thanks in advance for gathering this data for me, Patrick

BCS-E, Currently, that functionality is not inplace. The notifications are geared to point you back tot he Remote Administrator for clarification, in this case. You can, however, create a seperate notificaiton that is based on event logs (same place that the status text comes from) and have it email you anytime a warning is logged there. You can include the point of %LOG_LIST_FULL% in the event log message bodya nd it will include the data from the error message log. Please feel free to PM me directly if I can help in any way to help resolve this further. Patrick

PaulWilliams, You will certainly have to uninstall the Endpoint ANtivirus to move over to Endpoint Security. You can do so locally using Start>All Programs>Eset>Eset Endpoint Security>Uninstall and you can also use the Eset Remote Administrator (as you asked above). To do this is essentially the same as the installation, with some minor changes and potential differences. Before you begin, if you use a password to protect the setup parameters we need to add that to the uninstall package. To test on a client machine, open the Eset software and press F5. If it prompts for a password, that is the password I am referencing. If it does not and goes strating to the advanced setup, then you have no password. If you do not have a password, proceed to the next paragraph. If you do have a password, please open the Eset Remote Administrator and go to the Remote Install tab and click on the drop down menu 'Actions' and select Manager packages. In the dialogue that opens, please drop down the top menu item to uninstall eset software. When you do, there will be a box on the bottom right with switches for the uninstall. You will need to add this phrase to the end: PASSWORD=(password we confirmed a few steps ago) ex. PASSWORD=abcd123 Save this and click close. Next, pick a test machine to sample from your clients list. Right click and select Remote Installation and in the submenu, select Windows push installation. Credential (as you normally would for a push install) and on the screen where you pick the package to install, drop the top menu down and select the uninstall eset menu option. Proceed as a normal install and this will allow you to uninstall the package from that test machine. Repeat the process (once confirmed) with the balance of the machines and then restart them and push install the new software. Patrick

Al, It would seem from your original post, that I wonder if the notification itself is setup correctly. The notification has to have an aciton to send an email to a spcified address (yes, specified per notificaiton). If that is not set up, then everything you mention is exactly what would happen. Can you please open the notification manager and click on the notification in question and either take a screenshot and PM that to me directly or look at the action line and see if it has email listed in it. If it does not, then please click on edit to the right of it and put a check in the box for email (if its greyed out, then the SMTP settings rae not in place in Tools>Server Options>Other Settings) and fill out the data (email address and subject line). Once complete, save it and test it. Let me know how it goes for you, please. Patrick

Proactive Services, The cleaning mode is the same for ECLS as it is for Eset software. Definitions to follow: none - In this mode, no automatic cleaning will occur. standard (default) - In this mode, the program will attempt to automatically clean or delete the infected files. strict - In this mode, the program will attempt to automatically clean or delete all infected files witout user intervention. rigorous - In this mode, it will simply delete the filw without attempting to clean - REGARDLESS of what file it is. delete - In this mode, it will simply delete the file without attempting to clean, but will not delete more sensitive files (for example, windows files necessary for functioning).

Farhan, I would need to see speific information to how you have your Eset set up. Can you please PM me directly and provide the following info: 1. Version of OS 2. Version of Eset Mail Security for Exchange 3. Export your policy and include as an attachement, please 4. Open your exchange and copy/paste the reply to these commands: get-transportagent get-transportpipeline

martinl, I believe that the self-defense driver is still intact. Please attempt the following action against the machine (safe mode uninstall using a tool) and advise success (or otherwise): hxxp://kb.eset.com/esetkb/index?page=content&id=soln2289 Patrick

Casasco, It would seem that we were unable to contact you. We will keep trying to reach you. We are very eager to assist in resolving this for you. Patrick

MartynKeigher, Within your clients that are Citrix/XenApp Servers, if the Remote Administrator reports the OS as such, then you can use the filter for OS in. If that does not work for you, then you might be onto the best solution using the custom field . Please reach out to me with a direct PM so that I can ask you specific questions that will allow us to potentially use the custom field in the policy under Kernel > Settings > Remote Administration in order to resolve the issues with determining the Parametric group creator/management aspect of our software.

Casasco, I would be happy to help resolve this for you. Keep in mind that each country has a direct contact information on their eset website. Select Eset.com and choose your country from the drop down menu in the top right and then the conact option will provide direct contact info. If you would like to work tor esolve this, please feel free to contact me directly using PM so I can get some information from you directly (specifically, export of your notifications, a copy of the client configuration as well as a compelte copy of the email that is being sent to you about the old notifications). If you prefer to talk to someone directly, you are welcome to use the contact webpage mentioned above. Patrick

JRV, I do appologize for the scenario that the third party vendor (reseller) has put you into. It is indeed awkward when someone outside a direct relationship causes the system to slow down. At the tail end of this, I will certainly have someone from my side contact the vendors and work to improve their processes to minimize the chances of this occuring again. I would like to put myself out there to assist in a slightly more direct fashion. If you would please PM me a message with the EAV usernames from both of your licenses, I can use that to determine where the mistake is occuring, correct it, and (if you provide me an email address) send it back to you revised as well as the steps to remove the current offending license files and replace them. At the end of the day, we are looking to ensure you a smooth transition from where you are now (not entirely working) to where you want to be (entirely working and secure).

HDM, I believe ths issue lies in the case sensitivity. I would use this as your switch inside ERA (I changed it a bit to allow for management of the restart and also to have a quiet install, per your notes). I ran this on a lcoal VM to confirm success. /qn REBOOT='ReallySuppress" REMOVE=Firewall,Antispam,eHttpServer /qn will have a quiet install REBOOT will have the software NOT restart upon completion of installation 9can change to force if you want to make the machine restart upon completion of installation REMOVE is extremely sensitive to case. I believe the S in spam being capital was ruining your install string. Patrick

JRV, The update action and the Remote Administration (communication with and consequently visibility in the clients tab of the Remote Administrator) are two seperate actions. You described making the necessary changes to the Update settings. Now you need to make similar changes to the Remote Administrator section with is located in the "Advanced Settings">Miscellaneous>Remote Administration. Please ensure the check-box is marked and that the primary servier is populated with the Remote Administrator console servername (no http or port number necessary in the server name field). Once you commit that by saving, it will report back to the console within the standard timeframe of 10 minutes. Please let me know if I can help further in regards to this issue. Patrick

Guest_Matrak_, The option to use command line to backup the database in the same format (.DMP file) is not available currently. Waht I would recommend is to either use PERL scripting to run the maintenace tool and back it up or use traditional scripting to copy the folder that has the raw MDB file and if an issue occurs, you can reinstall the same version of the Remote Administrator and drop the files into the same directory after rebuild and ESET will use the database (folder locations below): Server 2003, XP: C:\Documents and Settings\All Users\Application Data\ESET\ESET Remote Administrator\Server\ Server 2008, 2011, Windows 7: C:\ProgramData\ESET\ESET Remote Administrator\Server\ The only thing you would need to know is that this backup style will not work on any other version of the Remote Administrator. The installation for recovery would need to be the exact same build for this to work. If you want to upgrade, you will need to complete the actions you did above by opening the Maintenance tool and manually backing it up to a DMP file.

damitha, You have three options here to manage quarenting what Eset Mail Security for Exchange (EMSX) marks as spam. Option one is to allow us to mark it and posh it through where Outlook will redirect it (option 1). The second choice is to allow EMSX to quarentine it directly (Option 2). The third is to have EMSX mark it and Exchange will manage the mails quarentine (option 3). For option 1, I would direct you this article for step by step instructions on setting up the process: hxxp://kb.eset.com/esetkb/index?page=content&id=SOLN2429 For option 2, You have a bit of it already configured by telling it where to quarentine to (per your example, spamMailbox@domain.com). To do that, open the EMSX and go to the advanced settings. drill down to Server protection>Microsoft Exchange Server>Message Quarentine and in the top field (Common message quarentine) put in the mailbox you want it to go to. The default action if there is no mailbox there is to do No action (same screen, drop down at the bottom). For option 3, the manual addresses it particularlaly well (link on page hxxp://www.eset.com/us/download/business/detail/family/50/?installer=offline) on pg.16 (section 2.9). It sounds like you want option 2, but need only to tell it where to put the mail. Let me know (by replying to this thread or direct PM) if I can help further. Patrick

MrGrinch, the clients get their information on licensing from where they are updating. For example, if they are updating from the web, they will get their expiration dates from our servers. If they are reporting to the Remote Administrator for their virus definition updates then they will get their expiration information from there. Please start by confirming that the License Expired is under Status versus under Last status warning. Status is a current issue where as Last Status warning could be a past issue that has been resolved. If its the latter, you are welcome to highlight the clients with this information and right click and clear the information fields. Otherwise, the solution is to start by confirming where they report to and even using your policy in Remote Administrator to focus all the machines to the same update point. If you have them report to the Remote Administrator for updates, then I would next confirm that the license inside the Remote Administrator is valid by going to Tools>License Manager and looking at the expiration date. If its still a valid timeframe, then the next time the clients check in they will resolve. If they are updating from the internet and showing that they are expired, then there is either a licensing issue on our side or the license was renewed within the last 24-48 hours and needs time to replicate through our servers. If all this does not resolve your issue, please feel free to reach out to me directly with a private message with your contact info and I will call you at first chance. Patrick

LocknetSSmith, There is no formal way to resolve this as a PDF direct from Eset Remote Administrator. You can export the files (as you mentioned) and generate a PDF using third party applications. This will blend the files into a static PDF to allow you to push them out to the necessary recipients. you also have the option (other than the .html option used here) of exporting to a CSV format by choosing advanced options and selecting to export as a CSV from the available options. I have submitted to have this added as a requested enhancement for future builds. Patrick

Dana, When it comes to customization, there are quite a few options but there are also limitations. A great example is the variables. The variables help expand the data with variables that pull a static value. In your case, you are presenting the servername/clientnameTaht is the data that that variable pulls and it is not something you can customize. With the sending of the notification actions (question 2) they are set to repeat and will repeat on a scheduled timeframe without any adjustment to the time. Sadly, the two customizations you are asking for are not present or adjustable int he way you want them to be. They can send mass amounts of information, but not to the timeframe or way you would like.