Endpoint Security 6.x and virtual desktops

[obrandt 0]

Has anyone had any success with putting the ESET Agent and Endpoint Security 6.x product on a base VMware Hoizon image?

 

I've followed these steps from a KB article but nothing seems to work.

 

With ERA (ESET Remote Administrator) it can be automated this way:

1. Install ERA agent and connect it to the ERA server

2. Install your Endpoint software

3. Create your image for the VDIs

4. Create a task for the deployed machines called "Reset Cloned Agent"

5. Use a dynamic group for "Product not activated" an apply a "Product Activation" task to that folder to automatically activate

6. Each time new Endpoint connects to ERA, it will automatically receive a request to activate this machine, without any user intervention.

NOTE: The most important is step #4, because without doing this step the unique UUID agent numbers would be "fighting“ over it, ERA must know that it was an agent used for cloning (image / base virtual image etc.).

 

My understanding is you create your base image with the agent on and eset product on it.  Run through the process of deploying your virtual desktops using the image.  Then run the 'reset cloned agent' task against those new virtual desktops.  After that they should show up in the 'product not activated' default dynamic group.  At which point you activate them. 

 

'Reset cloned agent' task never even started.  I waited over 24 hours.  Am I missing something, doing something wrong?

 

Thanks,

Owen

[pburger01 0]

Has anyone had any success with putting the ESET Agent and Endpoint Security 6.x product on a base VMware Hoizon image?

 

I've followed these steps from a KB article but nothing seems to work.

 

With ERA (ESET Remote Administrator) it can be automated this way:

1. Install ERA agent and connect it to the ERA server

2. Install your Endpoint software

3. Create your image for the VDIs

4. Create a task for the deployed machines called "Reset Cloned Agent"

5. Use a dynamic group for "Product not activated" an apply a "Product Activation" task to that folder to automatically activate

6. Each time new Endpoint connects to ERA, it will automatically receive a request to activate this machine, without any user intervention.

NOTE: The most important is step #4, because without doing this step the unique UUID agent numbers would be "fighting“ over it, ERA must know that it was an agent used for cloning (image / base virtual image etc.).

 

My understanding is you create your base image with the agent on and eset product on it.  Run through the process of deploying your virtual desktops using the image.  Then run the 'reset cloned agent' task against those new virtual desktops.  After that they should show up in the 'product not activated' default dynamic group.  At which point you activate them. 

 

'Reset cloned agent' task never even started.  I waited over 24 hours.  Am I missing something, doing something wrong?

 

Thanks,

Owen

Owen, I have had limited success in deploying ESET to View Desktops. I had to DNS poison the master image so that when it tries to check in for a GUID it could not get one.

 

Gave it a DNS entry for our management server of 127.0.0.1 in the hosts file

Installed the ESET agent.

Installed the ESET AV client

Installed I turned off the agent service (did not disable or change the startup state in anyway)

Removed the DNS poison

and, with the ERA service still stopped. we turned off the image and prepped it for use.

 

This allowed for each server spun up off this image to receive a unique GUID. However it met with limited success and this method does not allow for updates to be performed on the master image without having to redo the entire DNS poisoning again method every time we need which includes uninstalling and reinstalling the agent. 

 

I am presently looking to find out what this cloned agent task actually does on each cloned host so I can replicate this process within a script that will then run on power-on for each desktop spun up. 

 

These are my assumptions:

1. The task replaces the GUID from the registry.
   1. Removing the current GUID will cause the agent to no longer start (I've tried).
2. The agent calls on a dll or other resoure file to perform other tasks
   1. These other tasks must including requesting a new GUID which is used to replace the one it removes from the registry, thus allowing the agent to restart.
   2. The agent must first retrieve this new GUID and insert it into the registry before restarting the service. 

 

I am looking for ways of checking what changes are actually made to the registry and any other components. If anyone wants to help with this process I would welcome the assistance. 

[mickeyshowers 0]

I have heard that ESET may announce vShield Endpoint compatibility soon...  That would make threads like this one go away.  I used a competitors product that way at my last company and it is SOOO much nicer to manage AV at the host instead of the endpoint!  Totally invaluable in a non-persistent environment.  

[IT_Support 0]

Hello,

 

We are trying also to deploy ESET 6.x on VMware Horizon 6.x. with non persistent machines linked clone mode.

 

Same problem for us... not working for the moment.

 

Is  there an official procedure for deploying ESET in this situation ?

 

Anyone is using successfully ESET Endpoint in VDI environment ?

 

Thanks in advance.

[Podrska2NORT 5]

You can check this: hxxp://www.eset.com/int/business/virtualization-security/vmware/