Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request regarding updating agents #6512

Open
demkr opened this issue Nov 8, 2024 · 12 comments
Open

Feature request regarding updating agents #6512

demkr opened this issue Nov 8, 2024 · 12 comments

Comments

@demkr
Copy link

demkr commented Nov 8, 2024

Currently I have many different device groups that I use to categorize clients and add specific privileges to users. Therefore, I have different agent installations for each device group so that during agent installation the client is automatically added to the appropriate group. But still there is human factor present and it happened lot of time, that wrong agent was installed on host and therefore host was not visible under correct device group. But nevertheless, we could manually move that host to correct group.

But some hosts, under certain circumstances (which I haven't been able to figure out yet), and after a while, they were automatically moved to the original group. I noticed that under the msh file, even if I move a host to another group, there is still a MeshName field where the original group name is listed. Maybe that was the reason why the hosts were moved to the original group after a while. As I said, it was only for some hosts, not all, so I don't think it's a MeshCentral bug or anything. Maybe something weird happened with this host's connectivity and that's why the msh file was taken literally. This was resolved after update agent with correct exe file, where MeshName field was changed.

So is it possible to achieve that if I run the agentupdate command from the host console, that the msh file (MeshName field) will also be updated according to the device group the host is in.

@si458
Copy link
Collaborator

si458 commented Nov 8, 2024

you can already change the msh file remotely
#5845 (comment)
this might help you

@demkr
Copy link
Author

demkr commented Nov 8, 2024

Thanks for this command. It is useful and is definitely an alternative to editing the msh file remotely. I just think that this could be done using agentupdate or maybe during automatic agent updates (which could also be done after changes to devices, groups or even installation files - digital signature of files).

But still. I tried with one client and it did not change the MeshName value even after running the service restart command. However, the change in the MeshName field appeared after I ran the agentupdate command.

@si458
Copy link
Collaborator

si458 commented Nov 8, 2024

@demkr ok that's a weird one?
I will have to see what's going on when I get chance next week

@si458
Copy link
Collaborator

si458 commented Nov 8, 2024

updating the meshname isnt enough, you need to also update the meshid,
but im not sure what the meshid should be,
i think its a hex of the meshid you would need to verify

@smartekIT
Copy link
Contributor

Have a read here maybe you find it helpful.

@demkr
Copy link
Author

demkr commented Nov 9, 2024

@si458 MeshID is hex id of Device Group that tells agent to which Device Group it belongs to. MeshName is probably just Human readable notifocation. When I set MeshName and ran agentupdate, MeshName did changed, but MeshID was still from Device Group, that mesh agent was installed from. On one host I tried to set only MeshID and hope that MeshName will changed accordingly, but nor MeshNAme nor MeshID changed event after run service restart and agentupdate.
So I can confirm that only updating both fields, everything is updated correctly.

@si458
Copy link
Collaborator

si458 commented Nov 9, 2024

You have to change both of them at the same time, before you do a restart of the service, but the could be a bug with the msh set as I only created/tested it with new values not existing ones
It could also be the meshid is embedded in the exe so even tho you change it, it gets overwritten when you restart the service

@demkr
Copy link
Author

demkr commented Nov 9, 2024

@smartekIT I did checked that and it give me solution how to forcefully update all agents at once. That will solve my problem updating all agent executables to signed version after I digitally signed them. But it still not updating msh file regarding Device Group that host is added to.

@smartekIT
Copy link
Contributor

You have to change both of them at the same time, before you do a restart of the service, but the could be a bug with the msh set as I only created/tested it with new values not existing ones It could also be the meshid is embedded in the exe so even tho you change it, it gets overwritten when you restart the service

The meshID along with meshName is already written in the registry, so when you change in the file you have to also alter that in the registry as well, otherwise the same values keeps coming back. the registry location is:
HKEY_LOCAL_MACHINE\SOFTWARE\Open Source\Mesh Agent
correct me if I'm wrong, and I believe this is why when you update nothing change but when you force full reinstall it takes the new values as the re-install will overwrite these registry keys in addition to files changed.

@smartekIT
Copy link
Contributor

mashName is the device group name.
meshID is the hex value of the group meshID, you can manually install agent belong to that group on another machine to see what meshName and meshID it has then you could use that in powershell script like:

$file = "$env:SystemDrive\Program Files\MeshAgent\meshagent.msh"
$content = (Get-Content -Path $file -ReadCount 0).Replace('MeshName=OLD_Name','MeshName=New_Name')
$content = (Get-Content -Path $file -ReadCount 0).Replace('MeshID=OLD_ID','MeshID=New_ID')
Set-Content -Path $file -Value $content -Encoding UTF-8
net stop meshagent
net start meshagent
exit

@demkr
Copy link
Author

demkr commented Nov 10, 2024

@smartekIT I dropped all device groups with hex and non-hex values ​​(MeshID) along with MeshName using the meshctrl command. I tested on multiple hosts with different tests and the results were as follows:

  1. Changed MeshName and MeshID (in that order) using the msh set command and restarted the service. Result: only the registry value HKEY_LOCAL_MACHINE\Software\Open Source\RemoteAgent /v MeshId was changed to the correct MeshID value (not hex). Both fields under the msh file were still intact.
  2. Then I ran (after step 1 and without changing anything) agentupdate. The result was that only the MeshID was changed (and the registry key remained changed as well), but the MeshName was still old. I had to set MeshNAme again and run agentupdate to change that as well.
  3. Then I set MeshName and MeshID (in that order) and ran agent update. The result was that MeshID and registry key were changed but MeshName remained the same old one. I had to set MeshName again and run agentupdate to change this value in msh file.
  4. Then I set MeshID and MeshName (in that order) and run agentupdate. Then MeshNAME was updated but MeshID (also registry value) remained the same.

In conclusion: To fill all the mentioned fields in msh file and registry, I found the procedure to be as follows:

  • first set MeshName and run agentupdate. After that set MeshID and restart service

We have a deployment solution that completely reinstalls the agent and updates msh and registry value, but some of users may not have one. That why I think it would be nice to have such functionality that could be based on host or device group (for all hosts within that group) with click on the update button.

@si458
Copy link
Collaborator

si458 commented Nov 10, 2024

@demkr thanks for testing and providing ur finding.

The might be a bug with the msh set command as im sure the was another post someone made which had the same findings but for a different value, where that value wasn't being set correctly

I'm a little tied up at the moment due to family/personal reasons so I will try have a look during the week when I can

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants