FAQ for Symantec Critical System Protection (SCSP): Management Server
|Article:HOWTO58928|||||Created: 2011-08-10|||||Updated: 2012-07-28|||||Article URL http://www.symantec.com/docs/HOWTO58928|
Q: How do I move the SCSP management server information to a different machine without requiring any changes to the agent settings?
- Copy the following files from the original or primary Management Server. You will be overriding the same files created on all the new Management Servers (thus utilizing the same connection info across all servers).
- C:\Program Files\Symantec\Critical System Protection\Server\tomcat\conf\server.xml (this config file has the database passwords, URL definitions, cert locations and cert passwords)
- C:\Program Files\Symantec\Critical System Protection\Server\*.ssl (these are the certificates created during the installation)
- Install the Management Server on the new AppServer system. Two important items:
- Install the server into the same directory path as you used for the first Management Server, e.g. C:\Program Files\Symantec\Critical System Protection\Server.
- Use the "Eval+MDSE" installation choice. You're going to discard the MSDE instance later.
- Replace the configuration files on the new Management Server with those you saved in Step 1 above:
- Stop the Management Server service: net stop sismanager
- Copy the server.xml and the *.ssl files you saved in Step 1 over the corresponding files on the new Management Server.
- Start the Management Server service: net start sismanager
- Validate that your new Management Server is operational and talking to your original Database.
- Connect your Console directly to the new Management Server (add the new server IP address or hostname to your console login list) to verify that it is working properly and communicating with the database
- You may (but don’t have to) uninstall the MSDE instance installed on the new Management Server since it is no longer needed.
- At this point, both your original and new Management Servers are operational, talking to the Database, and using the same SSL certificates. If your goal was to move your management server, you can turn off your original Management Server system (or disconnect it from the network). If your goal was to add another Management server for high-availability or load balancing purposes then you should configure your network accordingly (for example use DNS aliasing/round-robin, configure network load balancer, or redirect agents to now use the additional management server).
- If you are simply moving your Management server from one system to another. You will need to switch the hostname or IP of the new Management Server so the agents find it instead of the original Management Server system: o If the agents were installed using the Management Server host name, change your DNS to use the IP of the new Management Server for that hostname
- If the agents were installed using the Management Server IP, configure the new Management Server system to have the IP of the original Management Server system
- At this point, the agents will start talking to the new Management Server system. o Since you copied the certificates from the original Management Server to the new one, the agents don't need a cert change
- The OS on the agent systems may have DNS and/or ARP caching enabled, so they may continue trying to contact the original Management Server system for a while. But as those caches time out, the agents will get the new info and start talking to the new Management Server.
- The only restriction is that the new Management Server must be configured with all the same info you've configured on your agents about the Management Server. This includes the host name or IP (depending on which you configured in your agents), the port, and the SSL certificate. Of course you can “redirect” some or all agents to specifically point to the new management server address as discussed in an earlier section.
- Completely uninstall the console, server and database.
- Reinstall the older server release (which will create a fresh database in your SQL instance)
- Restore the saved database over the freshly created empty database (thus returning your data to the point prior to the upgrade).
- Re-install the older console release. At this point you are back to where you were before the upgrade. This is not the same as “downgrading” the database and retaining all activity that occurred while running in the “upgraded” mode. Note that if you have bulk logging enabled and the event files are being retained, you could load the events that occurred during the time of upgrade into your restored database (thus not losing event data).
- Port 4443: The default port for the console to connect to the management server. The console initiates connections to this port as the user performs actions in the GUI.
- Port 8081:The default port for the web-based Console. The Management Server listens on this port for requests on the web Console URL. This is also the default Tomcat administration port. Any browser can initiate a connection to the Management Server on this port to get the Tomcat admin GUI. The Admin page of the SCSP console has links to launch a browser to connect to this port. (These are the links under the "Server" heading on the Admin page.) But you can connect via any browser, without going via the console.
- Port 8006: The default Web server shutdown port. The Console does not connect to this port at all. It is used internally by Tomcat during shutdown of the service.
Article URL http://www.symantec.com/docs/HOWTO58928