Open demkr opened 2 weeks ago
you can already change the msh file remotely https://github.com/Ylianst/MeshCentral/issues/5845#issuecomment-2033262310 this might help you
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 ok that's a weird one? I will have to see what's going on when I get chance next week
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 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.
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
@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.
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.
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 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:
In conclusion: To fill all the mentioned fields in msh file and registry, I found the procedure to be as follows:
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 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
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.