SWIS URI Connection is wrong

never mind. Answered here Re: SWIS Query Issue after server move

https://thwack.solarwinds.com/message/327609#327619

I'm glad you found your answer. Your question motivated me to promote this to a wiki page: https://github.com/solarwinds/OrionSDK/wiki/Uris#system-identifier

I believe I may have come across an issue with this retention of the system identifier. Please correct me if I am wrong, or give me a correction to this issue to rename the system identifier.

I have replicated the database for another "DR" Orion instance. The original server is still running with the original database. The replicated database, as has been stated here, has uris referencing the original Orion instance. I went to do a mass delete of devices via powershell API in the DR instance. This appeared to successfully remove the devices from the DR instance. Although, it appears to have removed interfaces from the referenced swis uri nodeIDs in the original instance. I suspect that the calls to remove children of the nodes may have been through API/swis as well and actually called to the original server's instance since it is still referred to in the swis uri and still exists. This is the only explanation I can find for the mysterious removal of interfaces from the original orion instance.

Please let me know how to rename the system identifier in the replicated database for our DR instance.

I believe I may have come across an issue with this retention of the system identifier. Please correct me if I am wrong, or give me a correction to this issue to rename the system identifier.

I have replicated the database for another "DR" Orion instance. The original server is still running with the original database. The replicated database, as has been stated here, has uris referencing the original Orion instance. I went to do a mass delete of devices via powershell API in the DR instance. This appeared to successfully remove the devices from the DR instance. Although, it appears to have removed interfaces from the referenced swis uri nodeIDs in the original instance. I suspect that the calls to remove children of the nodes may have been through API/swis as well and actually called to the original server's instance since it is still referred to in the swis uri and still exists. This is the only explanation I can find for the mysterious removal of interfaces from the original orion instance.

Please let me know how to rename the system identifier in the replicated database for our DR instance.

I suggest reading through the documentation at Migrate SolarWinds Orion products to a new server with a new IP or hostname .  The hostname appears in several places in the Orion database.  Until all of those references get updated, your SWIS URIs in the replicated environment may end up sending you back to the original host.  It's hard to know without seeing your script, but I would guess that the calls to remove interfaces were executed against the original environment because of those old URIs.

I was able to validate that when removing a device on the replicated db system with the system identifier of the original system using powershell it does remove the interface of the node with the same nodeid referenced in the uri on the original system. This is problematic for node management when using a replicated database and the original system is still operational. Please let me know how to change the system identifier of the replicated database to the new orion sysname.

I believe that Step 8 of Task 2 in Migrate SolarWinds Orion products to a new server with a new IP or hostname provides the steps for updating the system identifier.

I have followed the suggested changes in that article but the swis system identifier still remains the old system name causing cross talk between the systems.