Eset Remote Administrator Agent 6 for image

[phil2627 0]

Hoping someone could help as support has not responded to my support request.  I built an image and included Remote Administrator Agent in the Windows 7 image.  I imaged 24 computers and logged into the Remote Administrator console expecting to see 24 computers.  However, I only saw the image computer.  Is there a GUID that has to be deleted before uploading a base image ?  Or should the Agent be installed post image ?  Any help would be appreciated. 

 

 

   Thanks

[Marcos 5,069]

Hello,

when cloning an image, please continue as follows:

 

1, install the agent and Endpoint

2, let the agent connect to ERAS

3, create an image of the disk (the computer must not connect to ERAS again)

4, create a "Reset cloned agent" task on ERAS for the agent (refer to ERA6 User Guide hxxp://download.eset.com/manuals/eset_era_6_userguide_enu.pdf, chapter 6.1.3.2.6 Reset Cloned Agent). This will reset SID of the agent that identifies unique computers.

5, image other computers using the prepared image.

[phil2627 0]

Thank you for the prompt response.  I appreciate it.

[dlaporte 14]

I chose to leave out the Agent/Endpoint in my image..

This way you have no issues with licensing or older versions..

 

This forum is guiding me as to how to do the agent/eset endpoint via GPO and using dynamic grouping.

https://forum.eset.com/topic/4220-era6-auto-deploy-to-new-computer-when-found-in-ad-ou/?hl=%2Bactive+%2Bdirectory

[cpetry 4]

This logic couldn't have been built in?  If an agent connects and a duplicate is detected it couldn't just reset it's own SID?

 

Is there any harm in setting up an automated task to do this on all systems once in awhile?  

[cpetry 4]

Also, I'm re-reading your instructions a few times and am not clear on something.  After you image the system, you disconnect it from the network, and THEN you run a task on the ERAS for resetting a cloned agent?  So id the SID reset on the server itself since the computer is no longer connecting to the ERAS?

 

If that's the case, can't you just delete the system to be cloned from the ERAS and let the newly imaged systems connect as they are deployed?  If the computer with the agent isn't allowed to connect again (your step 3), how is that task supposed to run against the agent?  Unless that task isn't actually run against the agent and it's run against ERAS?

[MartinK 378]

Simple example, You have AGENT "A" installed in your image, that is no longer connecting to ERA. After that you create "Reset cloned agent" task and assign it to this "A". If you clone this image, resulting clones will be reporting to ERA as "A" and therefore they will receive mentioned reset task, and they change to B,C,D.

In case you let your base image with AGENT "A" to connect to server, it will reset itself, and your image will no longer contain "A" but instead "K" -> all other cloned machines will be also "K" and therefore they won't be executing task created for "A". Of course you may modify task to work also for "K" but will again reset base image to some random "Z" ...

[cpetry 4]

Oh boy.. The rest of the IT staff is going to love that.  You guys took a play from McAfee.

 

That's exactly what I thought the process was going to be like.  So we are going to have to keep a very controlled image creation process with this agent in play.  

[cpetry 4]

If the server cleanup task is run and this client is removed from the ERAS will this task still run when "A" that no longer even exists in the ERAS connects?

[MartinK 378]

If the server cleanup task is run and this client is removed from the ERAS will this task still run when "A" that no longer even exists in the ERAS connects?

 

Yes, you are right and it won't work. Actually previous example was not practical, but was showing what will go wrong.

 

My favorite procedure for this scenario (cloning live image) is:

• Install AGENT on base image and let it normally connect to ERA
• Create special static group for base image computer(s) (i.e. "Base images")
• Create dynamic group template "Non base image", that will never be matched by base image(s): for example add condition on MAC address or other identifier distinguishing your base images
• Create dynamic group "Clones" under static group "Base images" containing only base images using dynamic group template from previous step. Group should be empty if everything is configured properly.
• Attach reset cloned agent task to this dynamic group

Now when you clone base image, it will match condition of dynamic group because used identifier will be different and thus it will run reset task -> this will happen almost immediately after AGENT startup, most probably prior to any attempts to connect to SERVER because dynamic groups are autonomous once received by AGENT.

[cpetry 4]

I really hate ERA 6.X.  I'm not even kidding.  This release has been one of the biggest steps back I've seen any company take in years.  It's like McAfee bought ESET and forced their ill will upon them.

 

Other ways ESET could have done this (yes, I just thought all of these up randomly just now):

 

1) SID is the systems MAC or a hash of the MAC.

 

2) SID is the systems hostname or a hash of the hostname.

 

3) You could even have a registry flag you can set to delay the generation of the SID on the system you install the agent on for the "next reboot" (like sysprep for Windows). 

 

I don't understand why ESET thought the process of the agent generating it's own static SID upon installation was such a good idea.  The only purpose of this SID should be to identify a unique agent connecting to the system.

 

I'm just glad we haven't settled on a corporate image product yet.  I had to email our IT staff across the world and tell them to not use the new version in an image if they have chosen to use an image at their site until we can figure this out.  Needless to say not one of them were happy about how the newer version of ESET behaves.  For now I told them to remove ESET 5.X from their image if they are using one at their site, and to install ESET 6.X by hand on new systems until further notice.

 

So now, with the procedure you've given me, I now have a total of three different procedures all given to me by different ESET employees. 

 

I'm going to follow up with that sales director at ESET and let him know this new SID process the agent uses is awful and is causing an undue hardship on us.  Management over there needs to be made aware why this process is awful for bigger corporations.

[MartinK 378]

I think main reason for behavior change since 5.x are issues related to steps 1. and 2. you listed. Both parameters can change in time (are HW, network dependent). Step 3. would be possible, but it does not solves cloning of live image.

 

Seems you are using system images quiet a lot, would be for you proper solution if we can provide single executable file that will install ESET security product + ERA Agent, activates them and pre-configures them as you wish? Is is possible to run executable after image is deployed so that each clone gets unique instance?

[cpetry 4]

I've never had an issue with ERA 5.X and things changing over time.  There aren't many AV applications that generate a unique ID.  Basically the agent just has to tell the server who it is.  I find it hard to believe there's no way to do that without generating some static SID during installation.  Windows generates a hash for hardware changes.  It doesn't get triggered with small upgrades.  So there has to be a way to base the SID on something solid that wouldn't tie the customer down to this crazy cloning process.

 

"The motherboard and CPU, hard drive, network card, graphics card, and RAM. Changing a single component or even two components may be fine, but changing several components may upset Windows."

 

I already have rip and replace.  It was given to me due to us having other issues getting the software on systems.  I'm still left having to manually remove / install File Security for our servers.  They didn't have rip and replace for File Security.  That and there's a bug in ERA right now that prevents upgrades of File Security.  I've tried, it fails.

 

It really seems we are going to have to buy imaging software that can run post-deployment tasks just for ESET.  No other software we have requires a post-installation task due to a unique ID of any kind. 

 

I'll just have to put SmartDeploy in the budget and account that cost towards the cost of ownership for running ESET. 

[cpetry 4]

Also, I don't understand why you couldn't have just used the hostname. Yes, it can change; so what? The worst that would happen is you have the client connect to ERAS with the new hostname and the old one just sits in the console waiting for cleanup or manual deletion. I can also say from managing a network that's approaching 2,000 nodes that renaming a system isn't something that's done often. Servers are never renamed for obvious reasons. I don't even see workstations get renamed.

All you're doing with this static SID is causing extra work for your customers.

[cpetry 4]

Or you can do this this way:

 

1) When the agent connects to the ERAS with a duplicate SID the ERAS generates and assigns a new SID to that agent.

2) The agent could use a "version number" for the client, like active directory, or DNS does to identify what system is "newer" so the older client doesn't get the new SID.

          2a) The version number can be assigned before the SID by ERAS, this way the ERAS never assigns the same version number, or, the version number can be generated locally by the agent in addition to the SID, and it can use something like the date/system time.

 

My problem with this duplicate SID issue is the cloned agents won't show up in the console.  So there's no way I can tell if someone made a mistake and deployed a cloned agent.  I could have 100 cloned agents reporting to my ERAS and only one client will show up.  So, if there was a section in ERAS to even show duplicate/cloned agents, where you can easily just reset them after the fact this would be fine as well.  I wouldn't mind much if I could include the agent in my images even if I had to go into ERAS, go to a special section/tab, select the cloned/duplicate/invalid systems, and reset them there.

 

The point is there are ways around this.  I just feel like ESET has put no effort into it.  You did what McAfee did with their agent.

Edited May 13, 2016 by cpetry

[j.schulz 0]

Hi,

 

after reading all this is someone here who can simply tell us how da hell we can reset the agent by hand?

Dear ESET friends what have you thougth while doing this?

 

Where is the SID stored on a local computer? Tell us howto manually reset the agent! Is it so hard to share this information?

 

 

Regards X23

[j.schulz 0]

Hi,

 

I really hate ERA 6.X.  I'm not even kidding.  This release has been one of the biggest steps back I've seen any company take in years.  It's like McAfee bought ESET and forced their ill will upon them.

 

Other ways ESET could have done this (yes, I just thought all of these up randomly just now):

 

1) SID is the systems MAC or a hash of the MAC.

 

2) SID is the systems hostname or a hash of the hostname.

 

3) You could even have a registry flag you can set to delay the generation of the SID on the system you install the agent on for the "next reboot" (like sysprep for Windows). 

 

I don't understand why ESET thought the process of the agent generating it's own static SID upon installation was such a good idea.  The only purpose of this SID should be to identify a unique agent connecting to the system.

 

I'm just glad we haven't settled on a corporate image product yet.  I had to email our IT staff across the world and tell them to not use the new version in an image if they have chosen to use an image at their site until we can figure this out.  Needless to say not one of them were happy about how the newer version of ESET behaves.  For now I told them to remove ESET 5.X from their image if they are using one at their site, and to install ESET 6.X by hand on new systems until further notice.

 

So now, with the procedure you've given me, I now have a total of three different procedures all given to me by different ESET employees. 

 

I'm going to follow up with that sales director at ESET and let him know this new SID process the agent uses is awful and is causing an undue hardship on us.  Management over there needs to be made aware why this process is awful for bigger corporations.

 

man you are so right, i figure out that exact same problems and i started to hate eset, we came from trend micro and what i have to deal with eset is really a shame.

 

 

Regards X23

[karlisi 26]

Also, I don't understand why you couldn't have just used the hostname. Yes, it can change; so what? The worst that would happen is you have the client connect to ERAS with the new hostname and the old one just sits in the console waiting for cleanup or manual deletion.

This will be OK in homogenous network. My network consists of about 30 very small distributed networks, about 850 workstations, with duplicate hostnames, dynamic addresses on Internet side and other mess. For me identification by MAC is the best solution, I was very happy when ESET introduced this in ERAS v.5.

[RyanTsai 3]

Hi,

 

after reading all this is someone here who can simply tell us how da hell we can reset the agent by hand?

Dear ESET friends what have you thougth while doing this?

 

Where is the SID stored on a local computer? Tell us howto manually reset the agent! Is it so hard to share this information?

 

 

Regards X23

 

As far as I know, the SID for Agent is store in 2 places:

 

1. C:\ProgramData\ESET\RemoteAdministrator\Agent\EraAgentApplicationData\Data\data.db (a SQLite database)

in key_value_table there's a key called local_peer_uuid

 

2. Registry:

HKLM\Software\ESET\RemoteAdministrator\Agent\CurrentVersion\Info\ProductInstanceID

 

These IDs are just randomly generated standard format UUIDs. If you can change these 2 values to a different UUID, it's gonna show up as different clients in ERA. Reset Cloned Agent resets this value too. However I don't know if there are any side effects. Even if there aren't any, another question is how to in-corporate this into the base image so that it generates new UUID on first start-up before loading the service on first boot.  

Edited July 11, 2016 by RyanTsai

[j.schulz 0]

Hi,

 

nice information that you found out, i am also looking for i nice and quick way to make the agent unique one thing would be installing it post else the eset guys could tell us how they generate the uuid and what the command lines are to trigger the binarys to create/update the db and registry? the db itself is owned by system we can gain access with psexec but instead of doing this on a hackish way eset could help us a little more please.

 

 

Regards Jens

Edited July 28, 2016 by j.schulz

[j.schulz 0]

Hi,

 

generating new uuid is easy by commandline, changing the values in data.db is easy with sqlite3.exe (cmdline) but the data folder is protected by system account, with psexec we can be system to copy the file and or changing permission but i don't want to break security, changing uuid in registry is also easy but all this needs to be tight into a working script.

 

 

Regards Jens

[Miami 4]

Hi,

 

generating new uuid is easy by commandline, changing the values in data.db is easy with sqlite3.exe (cmdline) but the data folder is protected by system account, with psexec we can be system to copy the file and or changing permission but i don't want to break security, changing uuid in registry is also easy but all this needs to be tight into a working script.

 

 

Regards Jens

Wouldn't be easier to do advised solution with static/dynamic group?  You set it just once and don't need to think about. On the other side ... in more structured environments and the fact that computer can belong only to one static group, this could get more complex.

[Danny Batenburg 1]

There is actually an MSI parameter to pre-define the UUID of an agent when it is being installed (P_CMD_PRODUCT_GUID=""). You could have a simple startup-script to generate a hash of the machine-name, format it into the GUID the ERA/Agent expects it to be, and pass it on during installation. 

 

You could add this script to the startup procedure of your actual machines (Not Golden Master/Image!) so that when the machine is booted from the GM, the agent is installed using a UUID based on the machine name. 

[j.schulz 0]

Hi,

 

there is actually another solution from another guy from this forum, he made a binary that will change the uuid in data.db and registry.

I will not understand why eset is not giving us the option to reset uuid by commandline (with admin rights) or to set the agent in a state where it

gets a new uuid after the next boot, all this would be something really useful for sysprepping but in the end the user is making it's own solution to something eset gives no care.

 

 

Regards Jens

[j.schulz 0]

Hi,

 

i tried the util and it works like expected, i will talk to ryan if he want to release it to public.

 

 

Regards Jens