Things to Consider When Moving the Symantec Critical System Protection (SCSP) Database and Management Server
First of all, moving the SCSP management server and scspdb database can be tricky. There is the potential for losing the database, which would require a complete reinstall of the manager and the re-registration of all of the agents as well as rebuilding and configuring policies. It is recommended that all precautions be exercised before attempting this, including backing up the scsp database. This activity should be done by a qualified DBA.
If the SCSP manager and database server need to be moved, there are a number of things that must first be considered:
1. Will the IP address of the database server and management server need to change?
a. If the IP addresses need to change because both servers are being moved to a new subnet, it is important to verify that there is a network route to the agents and to the database server.
b. Is there a host-based firewall running on the database server and management server? If so, make sure they have been configured to allow communication to and from the new host IP's. See the document below for ports:
c. If the IP addresses change, but the hostname was used during install, the server.xml file will still need to be modified to reflect the new IP address of the database server. The server.xml file is located by default in
c:\program files\symantec\critical system protection\server\tomcat\conf". There are two entries that must be changed. They begin with "
The paths that must be changed look like this: "url="jdbc:jtds:sqlserver://10.0.11.65/SCSPDB;instance=SCSP"".
2. Will the physical hosts for each server have to be replaced with a new host?
a. If the database or manager are being replaced with a new host, the steps are much more complex. It's important to have a copy of the database just in case and if the ip address of the manager is going to change, it will likely be easier
to install the new management server as a failover, then simply disable the old primary management server leaving the database server on the old host running. This will force the agents to fail-over to the new management server. After
communication between the new management server and the agents has been confirmed in the console, then it will be ok to move the database to the new database server. After that is complete, simply make the change in the server.xml
file to reflect the new database server IP address and restart the management server. See the following documents for specific steps:
If, after moving the database and management server, you are unable to log into the management console, check the windows services to make sure the management server service is running. If it isn't, check the windows application event log and look for "java -1" errors associated with the SISManager service. This, essentially, means that the manager service is unable to connect to the database. See below:
Java -1 Causes:
1. Loss of connection to the database or database instance isn't running.
- verify the SCSP database instance is running and try restarting it
- try disconnecting/reconnecting to the database instance.
- verify connection to the SCSP database instance using OSQL
- verify the database connection details in the server.xml file are correct (i.e., verify the ip address of the database server, etc)
2. Permissions changes made to the SCSPDB database users.
- scsp_ops must have both the "public" and "scsp_ops" roles checked
The java -1 error will generate a connection error in the sis-server.log that begins with the following: "
Server Initialization has failed!! java.lang.Exception: Failed to connect to database after trying 20 times, please start the database!!"
If you continue to experience issues bringing the SCSP management server back online, contact Symantec Technical Support for further assistance.
Imported Document Id
This is machine translated content
Login to Subscribe
Please login to set up your subscription.
Didn't find the article you were looking for? Try these resources.