Remove Subordinate Server

Administrators can remove a server from the enterprise. This sometimes is necessary due to store closings or changes in the corporate hierarchy. Leaving the enterprise will remove records from the POA and local machine. Later, the machine can rejoin the same POA, if desired. This enables retailers to adapt to changing circumstances while maintaining the integrity of the replication hierarchy. Before leaving the enterprise, be sure to disconnect the Prism server's connection(s). If the Prism server is still connected, it will continue to try to communicate with the other side of the connection.
In the Prism enterprise hierarchy, a single root authority sits at the top of the enterprise. Below the root authority may be one or more child point of authority servers and store servers. The root authority or child POA servers can remove servers that sit below them in the hierarchy. A store server cannot remove a POA from the enterprise. Special care must be taken when removing a subordinate server that is offline.
Leaving Rules and Notes
When leaving the enterprise:

• Unless otherwise noted, all the data from the enterprise remains on both sides of the separation.
• The Controller records for the opposite side of the separation are archived.
• The Remote Connection records connecting each side are deleted.
• Special care must be taken to delete message queues (see following section)

RabbitMQ Queue Cleanup Required before Removing Server
Before removing a subordinate server from the enterprise via the Web Tech Toolkit (TTK), verify the following RabbitMQ queues are empty:
The subordinate's server's message queues at the POA.
The POA's message queues at the subordinate.
Notes:
Deletion of the Day2Day and management queues from the RabbitMQ console for the subordinate may take up to 60 seconds (possibly longer). Under certain circumstances the queues may not be deleted:

• RabbitMQ actions may prevent the queues from being deleted.
• In some cases, a deleted queue may be re-created because of another process.
• The replication producer may be loading the queue with messages, preventing the deletion.

Do not start/stop RabbitMQ or any other services during the deletion. Starting/stopping RabbitMQ or other services could permanently prevent the queues from being deleted.
Remove Server
At the down server's POA, log into Web TTK, select the server and select Remove Subordinate Server from [POA name] from the menu.
If the server will not re-join the enterprise, no further action is needed.
In the example below, there are two servers, a root authority server labeled RA and a child POA server named POA1. The parent (named RA) is removing the subordinate server (named POA1).
 
A confirmation is displayed. Click OK.
 
Correct Method for Removed Subordinate Servers to Rejoin Enterprise
At the removed system, log into TTK, it will show the former enterprise tree (since the system has no knowledge it has been removed from the enterprise)
At the removed system, log into the subordinate server's former POA (this is required for the next step).
 
At the removed system, select the menu icon associated with the server (the removed subordinate server) and select Remove [server].
 
Now the enterprise tree will correctly reflect that this system is not attached to an enterprise.
 
At the POA which this server will re-join, follow the "Add Former Server" process.
When a user attempts to rejoin a previous subordinate server, if that server is still not disconnected from its previous POA, then the system will produce a red-toast message stating that the server must first leave its existing POA and to restart the process.