MeshCentral icon indicating copy to clipboard operation
MeshCentral copied to clipboard

Feature request regarding updating agents

Open demkr opened this issue 1 year ago • 13 comments

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.

demkr avatar Nov 08 '24 10:11 demkr

you can already change the msh file remotely https://github.com/Ylianst/MeshCentral/issues/5845#issuecomment-2033262310 this might help you

si458 avatar Nov 08 '24 10:11 si458

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.

demkr avatar Nov 08 '24 13:11 demkr

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

si458 avatar Nov 08 '24 14:11 si458

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

si458 avatar Nov 08 '24 16:11 si458

Have a read here maybe you find it helpful.

smartekIT avatar Nov 09 '24 07:11 smartekIT

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

demkr avatar Nov 09 '24 12:11 demkr

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

si458 avatar Nov 09 '24 12:11 si458

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

demkr avatar Nov 09 '24 12:11 demkr

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 avatar Nov 09 '24 14:11 smartekIT

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

smartekIT avatar Nov 09 '24 14:11 smartekIT

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

demkr avatar Nov 10 '24 10:11 demkr

@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

si458 avatar Nov 10 '24 11:11 si458

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

github-actions[bot] avatar Jun 07 '25 03:06 github-actions[bot]

is there any fix for this ? a'm still encountering this duplications of different devices but skipmaccheck is already been deployed to each on

Tech-Werkz avatar Jul 15 '25 15:07 Tech-Werkz

@Tech-Werkz sounds stupid but are 110% the skipmaccheck=1 is set inside of the .msh file? also you dont say how you have installed the agents on the machine or run them also what OS you are having this issues on

si458 avatar Jul 15 '25 15:07 si458

@Tech-Werkz sounds stupid but are 110% the skipmaccheck=1 is set inside of the .msh file? also you dont say how you have installed the agents on the machine or run them also what OS you are having this issues on

i reconfigured na config.json to add skipmaccheck on the next installation of agent then for the existing device who have no config of skipmaccheck i just run group action command using console command msh and check and it was successfully added upon checking on each msh files of device

i am encountering this issues on windows devices Windows 10 Pro

my server is working on a windows also

Tech-Werkz avatar Jul 15 '25 22:07 Tech-Werkz

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

github-actions[bot] avatar Sep 14 '25 03:09 github-actions[bot]

still encountering this issue but not frequent not like the no skipmaccheck not configured

Tech-Werkz avatar Sep 14 '25 03:09 Tech-Werkz

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

github-actions[bot] avatar Nov 14 '25 03:11 github-actions[bot]

This issue has been automatically closed due to inactivity. If you believe this is still relevant, please feel free to reopen it.

github-actions[bot] avatar Nov 22 '25 03:11 github-actions[bot]