[Config update fail between RAS 4.0 and NOD32 4.2]

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

[Config update fail between RAS 4.0 and NOD32 4.2]

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).

[Config update fail between RAS 4.0 and NOD32 4.2]

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!