The easiest and quickest method is by changing the DNS record.
So if the machines currently connect to a alias or even a current server name simply create a dns alias or a new alias to repoint the machines to the new server. As long as the serial number is the same they will communicate and register.
Also be best if you are keeping your current database to ensure agents modules, policies, and all data remain.
An alternate method could be achieved through using the fast path policies and configure machines under specific policies to connect to the new EMSS server. Although I have not really tried this for agent migration, so you may want to test first. The DNS changes above have always been the advisable method, they provide reliability, and flexibility should you need to make further changes or server moves.
Some of our server in the DMZ's connect via IP address, not alias name, I want to change these endpoints to point to new alias name with an edited hosts file. Can this be done on the endpoints easily?
Okay understood, you have a couple of options.
The first option below would be the real solution and not a workaround, it would change the server that the agent communicates to.
The other option not listed as you would be well aware would be a reinstallation of those clients pointing to the new DNS alias.
1. Create a custom package with a reg key export that includes only that server value.
- Disable agent hardening via the agent policy and deploy the reg key change.
- Include a restart of the patch agent service after the change.
- NOTE: Make sure the server value, and port information is correct or you risk orphaning the agent.
2. Another method is using the Fast Path setting in the agent policy set. This would allow a policy based change so no need for registry changes or package deployment.
- If you are already using the Fast Path policy you cannot control when/if the agent picks up and uses this information.
- The endpoint would still be pointed to the original server and may still attempt to communicate to that server.
- The old server name not existing would not cause any issues. May trigger network alarms or monitoring if being done at that level of depth.
3. A final option depending on the fate of the old server name.
- Create a second alias from the OLDSERVERAME = NEWSERVERNAME
- This would leverage your existing DNS controlled communication.
- Leaves legacy configuration in the environment and may not be desirable.
1 of 1 people found this helpful
To keep this thread current from some offline discussion.
Although what I have provided is correct for the patch agent, it should be noted that the lmagent should also be repointed using the following steps.
This should of course be tested with the agent version you are running to ensure it works as expected.
The advantage to this change is it is the only one needed and will have a impact on both the patch agent and the lmagent.
This file contains a server host parameter which will re-point the lmagent and the patch agent to the new server name.
This file is hardened and will either need to be replaced or simply have the new host value entered into the file.
The solution I devised for this keeping with the same theme is using a custom package to perform the work.
Here is an example using FART.exe which is a Find And Replace Text open source application for searching criteria inside a file and replacing it.
C:\Windows\system32>fart.exe -i "C:\ProgramData\HEAT Software\EMSSAgent\data\per
sist\live\uplink.xml" patchlink02 patchlink
Here I am updating the value from patchlink02 to patch link
So you can create a custom package with this being performed on the command line. This will update the file and at the end of the batch script you can restart the lmagent and patch agent which will pickup the changes. You may wish to test this out but I have tested this and it is working as expected.