InTrust server services themselves will be fine assuming it can still communicate with the back end databases on the SQL server – if SQL is also installed on the local server the ramifications of renaming a SQL server are better directed to Microsoft. It may not be advisable.
The problem will be the InTrust Agents which are deployed since they are registered to the old InTrust server name and will not be aware of the new server name / IP address. In other words, Agents will temporarily not be connecting properly.
So a few things will happen:
1. Ensure all Repository and Database objects in the InTrust Manager have their settings verified before/after the re-name to ensure they are valid. In other words, make sure gathering is not trying to store data to UNC path directed to the old InTrust server name, etc.
2. If the InTrust service account has enough permission (Domain Admin rights) to deploy Agents then they will automatically begin registration with the new server seamlessly as gathering jobs are executed and real-time code is updated on Agents. These Agents will show connected / registered in the InTrust Manager Agent list.
3. Other Agents which cannot be recovered automatically as in #2 above due to lack of permissions or network limitations (firewall for example) these Agents will need to be registered to the new InTrust server manually via the command line as they were originally. After some time following the rename, these Agents will show in the InTrust Manager Agent List as “Lost” status as they have not communicated with the InTrust server in 10+minutes
© 2024 Quest Software Inc. ALL RIGHTS RESERVED. Terms of Use Privacy Cookie Preference Center