Policy application to static groups bug

[ShaneDT 13]

So I've just realised that policies applied to static groups somehow apply to other groups without reason?

 

By default the 'Remote Administrator Agent - HTTP Proxy Usage' is applied at the All static group level. I leave this unchanged for all internal LAN based computers and works fine.

 

For some customers I create a modified version of this policy which I apply to specific static groups with the Force flag enabled, specifying Servers to Connect To in the Edit Server List for remote computers and notebooks to be able to report back to the ERA server via the Internet. Again this works well.

 

But I've just realised this policy somehow gets applied to all computers on the network, as the status.html file is showing replication to the WAN IP from this policy. If I go into the Details / Configuration / Applied Policies on any of these computers, this modified policy is not listed. Yet the settings for this policy have been applied.

 

How is this possible and how can it be fixed!?!

 

Edit: This is the latest version ERA Server 6.3.136.0

Edited May 29, 2016 by ShaneDT

[ShaneDT 13]

Worse, once this server list has applied on the client Agent, there does not appear to be any way to remove or correct them other than uninstalling the agent and reinstalling it as per my findings in this thread;

https://forum.eset.com/topic/8533-how-to-update-era-host-server-address-on-remote-clients/

 

I've attempted to modify the policy specifying the Server List - no change on the client.

I've attempted to create a new policy, duplicating the default 'Remote Administrator Agent - HTTP Proxy Usage' with force flags enabled for the Eset proxy settings section of this policy and applied this directly to the Static Group with the local network PC's - no change on the client.

 

So to fix this I have to uninstall and reinstall the agent on every computer! Nice!

[ShaneDT 13]

I also created a new policy adding the local ERA server IP address in the Edit Server List with the Force flag enabled, and assigned this to the local network PC's static group - still no change on the client!

 

Edit: Actually this did finally work. Took 2 'connects' from the client to ERA server to reset this. All the above issues still apply. At least now I have a workaround.

Edited May 29, 2016 by ShaneDT

[MartinK 378]

I am almost sure there is no functionality problem in assigning policies. In case policy is not assigned to group where computer is located, it is not even sent to AGENT.

 

Is there any chance WAN ip configuration policy was applied to affected clients? It may have been for short time period? Or maybe one of global policies (assigned to all) was temporarily modified to use this WAN IP address and this setting was removed in the meantime?

 

I am asking, because there is one common misunderstanding: when you apply specific setting to client, and then remove policy that applied this setting, client will remain using value from last policy even if policy is no longer available or applied. Value will be changed only after any other or new policy applies mentioned setting. In your case it seems clients were in history configured to connect to WAN IP (maybe accidentally assigned policy?) and after policy was removed they remained using WAN IP until you crated new policy for LAN computers.

 

Regarding repair of this issues: even if you reconfigure AGENT to connect to invalid hostname/IP, they will be trying connect to connection parameters from history -> this will enable you to repair them using ERA by fixing policies. Fixed policy should be applied after first regular connection.

[ShaneDT 13]

No, in fact this policy was only created on Friday, all the PC's had been installed and configured a week earlier. So there is no way this policy ever applied to these PC's.

 

The agent for the servers was also installed over a week ago. Again no where at this point was the WAN IP configured. This was only configured and applied to a specific static group on Friday for remote notebooks. Somehow these settings made their way to all computers on the network.

 

I've also seen this on another customer network, also running the same version of ERA. This was my previous post about changing this for remote computers. For some reason their terminal server was trying to connect to the old WAN IP address, again even though this policy had never applied to this static group or server. At the time I put it down to the customer running the EraAgentInstaller that was meant for the notebooks on the server. Lucky I didn't call him out on it

Edited May 29, 2016 by ShaneDT

[MartinK 378]

Have you tried to export configuration from affected clients?

 

It is almost impossible to find out what is going on without diagnostic trace logs. Currently connection IP changes when you:

• manually repair AGENT installation and specify different hostname/IP
• repair AGENT using remote installation task or using live installer (beware of IP that is in live installer, it will be IP or hostname used by your ERA server during installation -> which may be outdated, even when you re-generated installer after IP changes!)
• create & assign policy with IP address/hostname

[ShaneDT 13]

How do you "export configuration from affected clients"?

 

Martin please understand I don't work for Eset or spend all my time working with your product. I run a very busy business supporting over a dozen very active customers with probably hundreds of different products. I don't have time nor should I need to know your product as well as you do. I appreciate that you and others are responding to my posts but providing instructions on how to do something or links on where to find information would be very helpful. I've already lost half my weekend to unexplainable problems with your product. Do I really have to spend another hour researching how to do what you've suggested?

 

I'm sure there are partners on here that know a lot more than I do, I'm only very new to the world of Eset. But I'm sure there are many partners and customers that would appreciate not assuming we know the product or troubleshooting processes as you do.

Edited May 29, 2016 by ShaneDT

[ShaneDT 13]

I am asking, because there is one common misunderstanding: when you apply specific setting to client, and then remove policy that applied this setting, client will remain using value from last policy even if policy is no longer available or applied. Value will be changed only after any other or new policy applies mentioned setting. In your case it seems clients were in history configured to connect to WAN IP (maybe accidentally assigned policy?) and after policy was removed they remained using WAN IP until you crated new policy for LAN computers.

 

So just on this point, how can you remove a server setting from the Edit Servers List when you can't configure this policy without a server address?

So removing the policy won't remove the setting, but you can't apply a new policy that sets it to blank either?

 

It would be good to have a 'Refresh Policies' option that forces the client agent and installed software to reset all settings based on the currently applied policies in ERA.

[MartinK 378]

By export configuration I was referring to possibility to request current configuration of AGENT from Webconsole in Client details -> Configuration -> Request Configuration

 

So just on this point, how can you remove a server setting from the Edit Servers List when you can't configure this policy without a server address?

 

I am not sure I understand your question - why would you want to have empty list of server to connect to? That would result in AGENT unable to connect to ERA server.

When applying list-based configuration parameter, there is nothing like merging/joining/subtracting lists -> if you have multiple policies assigned to AGENT with applied "Servers List", only one list will be applied from policy with higher priority (or based on "force").

 

Example: if you have two policies, one containing WAN ip in Servers list, and another policy containing only LAN ip, resulting configuration of AGENT will contain only one IP.

 

So removing the policy won't remove the setting, but you can't apply a new policy that sets it to blank either?

 

Yes you are right, current design does no allow you to reset configuration to defaults. In this case it is recommended to create policy which will apply default configuration parameters explicitly. In case you are trying to revert configuration to state it was after installation once overridden by policies.

[ShaneDT 13]

 

 

So just on this point, how can you remove a server setting from the Edit Servers List when you can't configure this policy without a server address?

 

I am not sure I understand your question - why would you want to have empty list of server to connect to? That would result in AGENT unable to connect to ERA server.

When applying list-based configuration parameter, there is nothing like merging/joining/subtracting lists -> if you have multiple policies assigned to AGENT with applied "Servers List", only one list will be applied from policy with higher priority (or based on "force").

 

Example: if you have two policies, one containing WAN ip in Servers list, and another policy containing only LAN ip, resulting configuration of AGENT will contain only one IP.

 

 

The default policy 'Remote Administrator Agent - HTTP Proxy Usage' does not have any servers listed in Edit Server List. The default policy only applies the ERA server as the Eset proxy server. So how do I return to this default state?

[MartinK 378]

 

 

 

So just on this point, how can you remove a server setting from the Edit Servers List when you can't configure this policy without a server address?

 

I am not sure I understand your question - why would you want to have empty list of server to connect to? That would result in AGENT unable to connect to ERA server.

When applying list-based configuration parameter, there is nothing like merging/joining/subtracting lists -> if you have multiple policies assigned to AGENT with applied "Servers List", only one list will be applied from policy with higher priority (or based on "force").

 

Example: if you have two policies, one containing WAN ip in Servers list, and another policy containing only LAN ip, resulting configuration of AGENT will contain only one IP.

 

 

The default policy 'Remote Administrator Agent - HTTP Proxy Usage' does not have any servers listed in Edit Server List. The default policy only applies the ERA server as the Eset proxy server. So how do I return to this default state?

 

 

You can simply create new policy (or edit existing), "apply" settings you want to be applied to all clients, for example add your IP to server list. Once configuration is ready, assign this policy to group "All". This will be settings applied in case there are no other policies overriding them.

[ShaneDT 13]

You can simply create new policy (or edit existing), "apply" settings you want to be applied to all clients, for example add your IP to server list. Once configuration is ready, assign this policy to group "All". This will be settings applied in case there are no other policies overriding them.

 

 

Hi Martin, yes so in this instance that's what I've now done, but I've applied the new policy directly to each static group with LAN based computers.

 

But my question was, when you first setup an ERA server, there are no policies with the 'Servers to Connect To / Edit Server List' configured. Also when you create an EraAgentInstaller. bat file, again the server_hostname field is optional. If left blank it doesn't specify the ERA server to connect to. So with a default installation there is no server specified to connect to. Yet when you deploy the agent locally from the ERA server or via EraAgentInstaller.bat, the client Agent does connect to the ERA server.

 

I agree though it's a moot point as I've created the additional policy to reset this to the correct server address. Just trying to understand how this works.

[MartinK 378]

But my question was, when you first setup an ERA server, there are no policies with the 'Servers to Connect To / Edit Server List' configured. Also when you create an EraAgentInstaller. bat file, again the server_hostname field is optional. If left blank it doesn't specify the ERA server to connect to. So with a default installation there is no server specified to connect to. Yet when you deploy the agent locally from the ERA server or via EraAgentInstaller.bat, the client Agent does connect to the ERA server.

 

In case you do not specify Server hostname during live installer creation wizard (or in remote installation task) -> IP/hostname stored in SERVER's DB will be injected. It has been detected during SERVER installation, therefore it may be outdated. You should see this when you open EraAgentInstaller.bat. It should not be blank as AGENT won't install without it.