VDI Environments - Recomposing Images

[LocknetSSmith 6]

I have recently completed a deployment to an org. which is 100% VDI and found out the hard way that using the Agent Deployment Server task is not the proper method to install the ERA Agents.

 

I was directed by ESET Support to utilize the Reset Cloned Agent client task in a proper deployment scenario, but that has left me with questions.

 

For the initial deployment, here is the process I've gathered from the information I was given:

 

1. Use the policy to increase the check-in interval of ERA Agents

2. Add the ERA Agent and ESET Client to the computer you are composing your image from

3. Allow the ERA Agent to check into the ERAS

4. Run the Reset Cloned Agent client task against the endpoint before it checks into the server again (hence the need to increase check in interval)

5. Image other computers using the prepared image.  They should now all check in as unique workstations

 

My first question - Is this an accurate process for the initial deployment?

 

My second question - this organization recomposes their images on a bi-monthly basis to add Windows updates and third party patches to their images.  For ongoing day to day administration, when you have all of your agents checking in, what is the process for recomposing images?  I could be off base here, but it seems to me that if a person were to follow the steps above, they would end up with a whole slew of duplicates showing the Web Console, and the old ones would all have to be deleted whenever you recomposed images? 

 

Or is there a process for post-recompose which would avoid this? 

 

Also, just a suggestion - Perhaps a good KB would be helpful here, that is specific for VDI environments!

[LocknetSSmith 6]

No takers huh?

[Ref02 0]

Same thing here.

[LocknetSSmith 6]

For what it's worth, here is what I'm going to try today.

 

Nothing we've tried will get these agents to show on all of the virtual machines during this, our brand new deployment, as far as adding the agent to the image.  It always only shows on the master image workstation, and even when we run the Reset Cloned Agent task against that computer, and then try to push the image, nothing checks in.

 

I have uninstalled everything as far as v6.x and had them remove the agent from the image, and redeployed the "agentless" image out to all systems.  I'm going to redeploy the ESET RA Server with a clean slate.  The only time I've gotten all of the individual VM's to check into the server was by running the Agent installation task against them while they were online (during the day).  I'm going to do this again so I can at least get the agent out there and get all of their VM's checking in.

 

Before the next recompose of the master images, going to try to run the reset cloned agent task against all the VM's, then have them recompose and re-deploy with their new image.  With a little luck, they'll all check back in.  If not, this customer will probably cancel their order with us!  So here is hoping. 

Edited August 3, 2015 by LocknetSSmith

[LocknetSSmith 6]

Just checking back.  Unfortunately nothing we have tried has gotten this to work beyond initial install.  I have even ripped out the entire ERAS system, rebooted the server, and reinstalled from complete scratch.  The agents go out, the reset cloned agent task is ran, but nothing ever checks back in after the images are recomposed.  If I delete machines from the Web Console and re-run the Sync Server task, I at least get back to the master image machines though.  

 

Gonna try Eset support once more.  I've been escalated twice though, so I'm not sure where else to go!

[Marcos 5,074]

There's no solution to this (yet) as a permanent storage is required to store information about UUID used for unique identification against ERAS.

[jraley 1]

We utilized a Pooled Desktops for the majority of our infrastructure. I am still running v5 on them because of this issue. 

[LocknetSSmith 6]

ESET Support provided a process slightly different from the one I identified above.  I'm going to try it out before posting though, as I want to make sure it works.  From what Marcos is saying, it may not?

[jraley 1]

LocknetSSmith, any luck with the new process?

[LocknetSSmith 6]

Having some success with this process: 

 

1. Install the agent on the master machine.
2. Create the image for deployment
3. Deploy the image
4. Run the Reset Cloned Agent task in ERA for all deployed machines.

[AStevens.SHG 7]

Oh good grief, this was one reason we moved to ESET was for v4/v5 and the ease of use on clients, they just checked in and were unique by name or mac, perfect for VDI.

 

Hoping 6.2 makes this easier, or newer versions of ERA 6 before we get to this stage.

[jraley 1]

If you are using non-persistent VDI, definitely do not use ESET v6. v5 works great on Pooled VDI. Their new licensing broke VDI implementation.

[rramellini 0]

Has this issue been resolved?  I am thinking of purchasing ESET for my VDI deployment based on all the positive reviews I have seen.

[Marcos 5,074]

Has this issue been resolved?  I am thinking of purchasing ESET for my VDI deployment based on all the positive reviews I have seen.

 

You can use ERA v5 with Endpoint v5 which will work fine with non-persistent VDI. A newer version of ERA v5 is going to be released soon.

[obrandt 0]

Having the same issues in our environment.  Except whenever I have run the 'reset cloned agent' task it never does anything.  I've run it at least 6 different times and it never works.  Agent deployments and security product deployments work fine.

Edited October 8, 2015 by obrandt

[LocknetSSmith 6]

We have still also been unable to get this to work.  I know I was told by ESET Support that the Reset Cloned Agent task is set to uninstall/reinstall the agent, and should be run after the master image is recomposed, and pushed out to all new systems.  We run the task, and the machines simply never check back in.

 

We're going to try again now that 6.2 is out. 

[ITBranchSupport 0]

I had run in to this same issue with our VDi environment.  Below is what I had done which is currently working for us.  

 

ERA 6.2

 

1. Install Agent / Client on Master image. 

2. Let it report to and appear in ERA Console

3. Create Reset Cloned Agent task and run against Master Image

4. At this point (at least for us) it just gets to a "Task Started"  and from the console point it appears to do nothing else. Without a lot of information, it appears to be an ongoing running task that needs to remain there.  

5. Close / seal up your Master image

6. Clone off images and they should report. 

[LocknetSSmith 6]

Can I ask - any of you who have been posted to this thread - do you use VMWare Horizon in your VDI environments?  (version 5.x)

[LocknetSSmith 6]

I felt I should circle back on this - the end result was that Eset v6.x is not compatible with VMWare Horizon.  The suggested course of action was to roll our customer back to v5.x which worked in their VDI environment and then to look at ESET Virtual Security when it comes out of beta.  

[eset_wes 0]

I just opened a support ticket on this issue yesterday.  ESET apparently still does not have an answer for this issue.  Very frustrating.  You would think that a security company would understand the benefits of non-persistent VDI implementations and built a product to support this type of environment.

Here are a list of the issues that need to be resolved in v6 concerning agents on VDI desktops:

• If a computer object is created in ERA (either through AD import or manually) and then an agent is deployed on that computer, ERA is smart enough to link the newly installed agent with the correct computer object. Recompose and refresh operations in VMware Horizon View need the ability to sync with existing (stale) computer objects the same way.
• When a linked clone VDI desktop recomposes or refreshes, it is going to check in to ERA with the SID of the agent installed on the master image.  ERA should be smart enough to detect that the FQDN of the agent does not match the name of the computer object in ERA and either automatically trigger the "reset cloned agent" task if a computer object with that computer name or FQDN does not yet exist, or update/replace the SID on the agent to link it with the existing computer object with the same computer name or FQDN.
• When a linked clone VDI desktop recomposes or refreshes, (and if a "reset linked clone" task is required), the new computer object should not be placed in the Lost & Found folder.  It should be placed back in the folder where the previous object was (based on the computer name or FQDN).
• When a linked clone VDI desktop recomposes or refreshes, (and if a "reset linked clone" task is required), I should not end up with a bunch of stale computer objects.
• When using linked clone pools in VMware Horizon View, there is an option to automatically refresh the desktop (revert back to the last snapshot used to create the desktop) every X days or even every time a user logs off.  This means that desktops could be refreshed at varying intervals.  ERA should be able to automatically fix the duplicated agent SIDs and fix the stale computer objects in real time.  I should not have to wait for scheduled "reset cloned agent" tasks to run before this mess is cleaned up.
• Just because a VDI desktop is recomposed or refreshed, I should not lose any reporting capabilities for the history of that desktop (since I'm using dedicated, non-persistent linked clone pools, the users are assigned to the same desktop each time they log in).  I should still be able to see scan history, threat history, etc. for the desktop that was just recomposed or refreshed.