ggathagan

Thank you both for your responses. I discovered the source of my problem, which is tied to somewhat vague documentation. In short, I had not placed the FQDN of my ERA appliance in the "Server Hostname" field of the Advanced section of the installer creation. A lot of the documentation appears to be written from the perspective of an Active Directory structure. As such, assumptions are made with regard to the need for FQDN. Where the vagueness occurs: That field in the installer is labeled: Server hostname (optional) When you say a field is optional, you should expect to be taken seriously. It would be clearer if the field label was a little more specific; along the lines of "ERA server hostname" or "ESET administration server hostname". It would also be clearer if the field noted that a FQDN would needed if Active Directory is not in use. Once I took a look at the logs in C:\ProgramData\ESET\RemoteAdministrator\Agent\EraAgentApplicationData\Logs, I realized what the agent was attempting to do and was able to resolve the issue. Related to your advice, kapela86: I did not realize that all of the group templates listed were templates. The Icon Legend does not list the icon used for the template groups. In fact, I can find no mention of that icon in any section of the ERA documentation. When creating the installer, there are only two groups that I was able to use for assignment: All and Lost & Found. Knowing what I now know, I can understand why I could not assign policies anywhere else. Again, a lack of specificity in the documentation is not helpful. The installer now behaves properly, passing on all of the particulars of the policies once the ERA is contacted. On a related note: Is there any way to rectify this issue for clients where ESET has already been installed? Thanks again for your help.

Aloha, Martin I set it manually on one computer, exported the registry entry that contains the relevant information, and have been running that reg file on each installation. I'll run an installation without adding the reg file and see if it eventually picks up the setting from the Remote Administrator. This particular registry setting is in the "Current User" portion of the registry, as opposed to "Local Machine". As such, it's a setting that has to be added to every user profile on the computer. I vaguely recall running into similar limitations with other applications when the registry settings are not stored in the local machine section of the registry. It's been quite a few years since that occurred, so my recollection is somewhat suspect.

I'm brand new to the ESET business world and am having some difficulty with custom policies. I'm using the ERA 6.5 VA. I copied two of the built-in policies and modified them to my preferences. One policy is for the admin agent, and the other is for the endpoint software. I modified both policies to supply my HTTP proxy server information. I also modified the endpoint policy as follows: Enable the detection of potentially unwanted and unsafe applications. Disable the startup splash screen and sounds Disable ESET messages regarding Windows Update. Password protected the Advanced Setup controls. When I create the installer, I fill in the checkbox that accepts the EULA, as well as selecting the two policies previously mentioned. When I run the installer, I am still required to agree to the EULA and am also required to make a choice about enabling the application detection. We don't use Active Directory, so it's an all-in-one installer. I tracked down Knowledge Base article 6097, which outlines the command syntax used for a silent installer process. That method is successful, but is not truly silent. Contrary to that article's assertions, the progress windows still appears while the installation is running. More troublesome, however, is that some of the configuration settings of the policies are not implemented in the installation The HTTP proxy server settings, the password protection of advanced setup, and my preference not to include Windows Updates in the ESET status messages, are passed on, which would argue that the installer is processing at least some of the custom configuration properly. Other settings, like disabling the splash screen and sounds, are not passed on. My questions: 1) Am I missing some part of the process when creating the policies and integrating them into the installer? 2) If not, what is the point of being able to integrate policies into the installer package if the policies are not fully implemented and agreement to the EULA is not passed on without resorting to command line arguments?