Hi guys, I'd like to get some feedback/ideas on how to best resolve this agent re-installation issue. Occassionally, we have a requirement to rebuild a server from scratch (for various reasons). The downside to this is that the end result is an agent in the OpsMgr console, but no agent installed on the machine (plus alarms obviously). Trying to perform a Repair on the agent does not work (as expected), so the only option we have available is to delete the agent from the console and push down a new agent. Manually installing the agent doesn't work either (as expected). The problem with using this approach is that we then lose all reporting history data that we've got stored in the OpsMgr DWH DB. So my question is - how can we re-install an agent without losing historial data stored in the OpsMgr Operational and Data Warehouse DBs? Any suggestions/ideas you have would be greatly appreciated. Thanks. Kristian

>Occassionally, we have a requirement to rebuild a server from scratch (for various reasons). Server's FQND remains the same?http://OpsMgr.ru/

Hey Kristian An interesting question, but as far as I know I dont see how it can be done. When an agent is installed on a server it has a GUID associated with the machine object in AD. In turn this object has an associatation with its SID in AD. So there is a 1 to 1 relationship between the actual server, its account and its agent. You are preforming a clean install of a server and renaming it to be the old one? or something like that.... If you want the server to come back they way it was before a failure then you need to restore the machine and its system state.... Paul Keely

Hi guys, Yes - we are rebuilding the server with the same FQDN. I understand the requirements of the GUIDs inside the OpsMgr DBs, and my question relates to exactly that - how can I ensure that this unique GUID gets assigned to the same machine? I realise that a restore is an option, but this would not be a simple or quick way to ensure that the OpsMgr Agent is working again. The same could be said if a server administrator uninstalled the OpsMgr Agent locally from the machine. We would end up with the agent in the console, but no agent on the machine. Ideally, it would be good if the 'Repair' option worked when trying to do this. i.e. Push out a new agent (assigning the GUID that is in the DB) if there's no agent already on the server. This would ensure no loss of historial data. Thanks, Kristian

AFAIK, OpsMgr do not use SIDs in GUID calculations. It uses object's key properies and managed type ids. Key property for Windows Computer is the 'PrincipalName'. Principal Name maps to FQDN. So, you can try (in lab environment first): 1. Reinstall OS on test server. With exactly same name as it was before. 2. Do not create the new computer account in AD. Just reset old account and use it for join 'new' server to domain. 3. Install agent manually. I hadn't time to test it. But I am think this should work. :)http://OpsMgr.ru/