Config update fail between RAS 4.0 and NOD32 4.2

[warswe 0]

Dear all,

 

I'm migrating to a new version of ESET Remote Admin Server. At the same time, I'm moving to a new infrastructure environment to take this activity internally (from an external hosted partner).

The new infrastructure is ready to receive clients connection. My job now is to migrate a few hundreds of clients, to point to the new Remote Admin Server. 

 

I've created a Configuration Task to update the clients's Remote Admin URL and Ports number, but the task fails to apply. I tried the same through a Policy Change, but same behavior.

 

My clients are all running NOD32 version 4.2.67.10, my old RAS is running 4.0.138.0

 

 

Are you aware of any known issue between those components version?

 

What would be my other alternatives if I can't do this by a config change which is the recommended way?

Deploying a script to update the registry settings requires to disable Self-defense, therefore rebooting the computers, so not my favorite option.

 

If anyone has already encountered this issue, I would gladly hear any feedback.

Thanks in advance!

 

 

[Arakasi 549]

Hello warswe,

 

Here is what i suspect is happening and hopefully i can get you on the same page as me.

Please correct me if i misinterpretted your post.

 

1. An external hosting provider was using ERA to provide managed services for your endpoints.

2. You have now installed ERA on your own servers and wish to take control of the endpoints.

 

This is how it works AFAIK. The policy change (which is my best recommend for managing your endpoints) occurs when the endpoints "check in" to the ERA server.

If currently they have a different server for "checking in" your policy will never get deployed because they are checking in with another ERA currently.

 

What you may have to do is request that the 3rd party managed services company deploy a policy that points them back to your ERA, then your own policy will start to be absorbed by your endpoints.

 

Here is what i would do and recommended based off how i have understood ESET to respond.

Your endpoints are currently running version 4. The latest is now 5.

I propose that in order to keep from having to reach out to your third party again, you can deploy the new latest and greatest version 5, and within the msi you can set the update settings and new reporting server together using the configuration editor within. So when the push install of your clients is finished, they are updated with new settings. This uses xml.

Manage by policy after the fact.

 

Let me know if im on the right track with your scenario, would be glad to help.

Edited May 6, 2014 by Arakasi

[Marcos 5,071]

What you may have to do is request that the 3rd party managed services company deploy a policy that points them back to your ERA, then your own policy will start to be absorbed by your endpoints.

 

Exactly. Since the clients are running an old v. 4.2, perhaps the best course of action would be to create a new installation package with the latest version of ESET Endpoint Antivirus / Security 5.0.2228 and push it to the clients with a correct ERAS configuration.

[warswe 0]

Hello warswe,

 

Here is what i suspect is happening and hopefully i can get you on the same page as me.

Please correct me if i misinterpretted your post.

 

1. An external hosting provider was using ERA to provide managed services for your endpoints.

2. You have now installed ERA on your own servers and wish to take control of the endpoints.

 

This is how it works AFAIK. The policy change (which is my best recommend for managing your endpoints) occurs when the endpoints "check in" to the ERA server.

If currently they have a different server for "checking in" your policy will never get deployed because they are checking in with another ERA currently.

 

What you may have to do is request that the 3rd party managed services company deploy a policy that points them back to your ERA, then your own policy will start to be absorbed by your endpoints.

 

Here is what i would do and recommended based off how i have understood ESET to respond.

Your endpoints are currently running version 4. The latest is now 5.

I propose that in order to keep from having to reach out to your third party again, you can deploy the new latest and greatest version 5, and within the msi you can set the update settings and new reporting server together using the configuration editor within. So when the push install of your clients is finished, they are updated with new settings. This uses xml.

Manage by policy after the fact.

 

Let me know if im on the right track with your scenario, would be glad to help.

 

 

Hi Arakasi, Hi Marcos,

 

Thanks for your quick replies, really appreciate it!

 

 

Let me clarify your questions:

1: The external hosting provider only provide the infrastructure. We have full access to the "old" RAS server and fully manage it.

2: Correct, the "new" RAS installation is hosted directly in our own infrastructure and we would like to redirect all clients to this new RA.

 

So I did create a Configuration Change and Policy Update (tried both scenarios) from the "old" RAS, the change was supposed to update the URL on each clients, to point to the "new" RAS who would welcome these new clients.

I tried various combinations, (for example created the policy / config change from the "new" RAS, exported and imported on the "old" RAS, but although successfully pushed to the clients, nothing get ever changed and clients keep pointing to the "old" RAS.

 

This is why I though about a potential incompatibility between the versions of "old" RAS and the clients.

 

I'm not against deploying a newer version of the clients, but our clients are spread out around the world and not really fully managed within an entity (such as a domain). It's therefore not so straight forward to push a new MSI package to all those clients, although it could eventually be a scenario (if we can perform a version 4 uninstallation, + new installation of version 5 and configuration, all this in a single MSI package).

[Arakasi 549]

Hello again,

To answer you last statement, you wouldn't need to perform an uninstall. Just 1 push install with the correct msi. Eset will upgrade or remove the old drivers and directories on its own in a single msi, using the appropriate xml from Config edit.

 

I want to ensure we are talking about the correct way to make the change.

In your scenario, i don't figure you need to make any config changes or maybe i am not sure what you are referring to by "Created a Config Change". The Config editor is only for creating an xml to be embedded with an MSI push install.

 

On the old RAS, working with 1 client for test. It should be as easy as Opening the Policy Manager instead, adding your update mirror URL and port and saving the policy, then right click on one client and choose the Set policy to the policy you have just made the update change on. Wait 10 minutes then look in new ERA for client.

 

Just to bring up the basics, can you confirm the clients can ping and telnet etc to the new RAS ? Firewall ports n such are configured on the clients and on the new RAS?

Here is a quick KB that you can run through the basics quick too. hxxp://kb.eset.com/esetkb/index?page=content&id=SOLN2716

 

Hope we can discover your problem.

[warswe 0]

Thanks again for your reply Arakasi.

 

I've been using an inaccurate vocabulary. By Config Change I meant Configuration Task. I've tried using this feature to change the config, as well as the Policy Manager, none of them have been successful.

Other clients that I've manually redirected are connecting fine, so the infrastructure (firewall, network, DNS and so on) is perfectly fine.

 

I guess my only available option now is to push a new msi package that has the config of the new RAS.

 

Appreciated your help, thanks a lot

[Arakasi 549]

Here is a neat trick that may help as well.

 

You can go to a working client. Export the configuration.

Setup > Import and export settings.

 

IT will save an xml file.

 

Rename the xml to cfg.xml

 

Manually download the ESET MSI.

 

Drop the msi and the cfg.xml into the same directories on the problematic client locally, then run the msi. ( ESET will pull the settings from the xml )

Test after installation if everything is working locally.

 

If you exported the xml from a working client, the new one should retain the same settings if instructions are followed.

 

Good luck.