This is a TechSupport issue. My suggestion is to call TechSupport team.
However, I believe after deleting all things under "Server Aliases" and "Path Aliases", you problem should be solved.
Known Servers Table settings are stored in the registry: HKEY_LOCAL_MACHINE\SOFTWARE\PISystem\PI-SDK\1.0\ServerHandles
Check to see the problem server is not listed there. If it is, then just delete its registry key.
Also, you can do a KST Cleanup in PI SDK Utility (available starting PI SDK version 1.4.x)
Both replies were helpful, thank you. Deleting all of the "Server Aliases" seemed to particularly do the trick.
Hi Anna Perry!
I have removed one PI server from my collective and am trying to add it to KST as a stand-alone node. I have tried both your suggestions, but still no success. It keeps saying "The server or one of its members already exists in the Known Servers Table".
Another easy thing to try is to remove the old PI Collective from the KST to attempt to completely clean the registry. Note, the KST requires always at least one entry. To get around this, when you add a server use the name "dummy" or a name that is not a real machine name, and not not check "confirm". Remove the entry for the PI Server collective and add the servers back in. If you have multiple servers in the KST, only remove the servers that are involved with this issue. Just another item to try that has worked for me in the past.
You need to remove the Collective entry from the KST, perform KST cleanup and then re-add the Collective node and the Standalone server.
Dan gave you a nice suggestion in case you have only one entry in the KST list.
Here is a reference to the High Availability User Guide:
For example, if you remove a server from a collective and then want to connect to the server as an independent server, you
must remove the old collective and then add the independent server (and collective if you also want to connect to the newly configured collective).
I had allready done that! Also tried exporting, editing and importing KST, but none of these worked.
I finally found out the issue. My PI Servers were version 3.4.375. Later, I have upgraded my primary node to the latest version.
At this point, the secondary node stoped synchronizing. A secondary node runnig 3.4.375 cannot connect with 3.4.380!
So, when I removed the secondary node from the collective, it did not update its role.
The solution could be to upgrade the secondary node as well, reintegrate it to the collective and later remove it again, or simply rename the piserver.dat and picollective.dat files on that node and restart the PI Server.
Thank you for the contribution anyhow!!!
I think I have similar or related issue: I have a PI server call "Test1" and another called "Test2". I created a collective called "Test1" and dropped "Test1" server for upgrade while I promoted "Test2" to Primary. Everything was fine and seamless, users were not aware of the change. After upgrading "Test1" with same name and IP address, I tried to make it join the collective "Test1". The configuration failed saying "the server or its member already exists in the Known Server Table".
Anyone with a known solution or a work around? These server are production server, mission critical and in a corporate active directory environment.
Which steps have you already tried?
- What dou you see on your KST? (Try exporting it form PI SDK Utility)
- If you run "PI\adm\piconfig.exe < pisysdump.dif" what do you get?
- What version of the PI Server were you using prior to the upgrade, and what version have you upgraded it to?
Maybe the conflict is between the member name and the collective name that are the same. Can you rename the collective to "Test" and try and adding member "Test1" again?
After running PIConfig.exe, it shows TEST2 as Primary, TEST1 stand alone; not member of TEST1 collective. I upgraded from PI server 2012 to PI Data Archive Server 2015. The conflict is actually the conflict between the member name and the collective name that is the same. Is it possible to rename the collective? If yes, I can try it and join members to it (Test) but will it be possible to change the collective name back to Test1 since this is the name known by all the clients?
My suspicion is that TEST1 is not member of your Collective anymore but I don't like to go too much into speculations because you mentioned this installation is production and mission critical. For that reason I suggest that you contact Technical Support and ask for assistance - optimally in a remote session.
you can rename your PI Collective within the collective manager. You could later rename it to the original name, but since it is a production environment, maybe you don't want to have a disconnection period.
It might be easier to rename the member "Test1" to "Test3" for instance (renaming the machine itself) and then add it to the collective.
There is also the possibility of editing the pisys table via piconfig...
I eventually solved the problem by re-installing the Primary server using the backup taken before the upgrade. I copied files in the bin, adm, log and dat files to the new installation so that all the original collective configurations will be made available when the primary server comes alive. After re-starting the primary it recognized itself as the primary and also recognizes the secondary server which was not in sync. I dropped the secondary and re-initialized it.
Thanks for everyone's contributions. You are all great.