UPDATE: This article applies as well for the upgrade from any SCSP release to SDCSS 6.0 (aka Symantec Data Center: Security Server)
IMPORTANT: If SDCSS is configured for load balancing/failover, please read the below KB before upgrading:
SCSP/SDCS:SA upgrade of manager fails after upgrade.
- Descriptive steps
IMPORTANT: It is strongly recommended to first backup the SCSP database from within MSSQL. For more details, please check the Microsoft Library at msdn.microsoft.com/en-us/library/ms187048.aspx
- Firstly, it is required to upgrade the management server,
- Secondly, upgrade the management console,
- And finally, the Agents.
Note: Upgrading the agent is optional; all agent from version 5.0.0 can be used with the latest version of the management server and console. However, if you upgrade the agent to the latest version, then you must also upgrade the management server and console.
About the minimum agent version numbers
The minimum agent version number that appears in the Symantec Critical System Protection console reflects the oldest version of the agent that supports that policy. The policy is supported on all newer versions of the agent as well.
Note: Solaris x86 5.2 RU7 and older agents cannot communicate at all with the 5.2 RU8 management server. You must first upgrade all Solaris x86 agents to 5.2 RU8 before you upgrade your management server to 5.2 RU8.
This issue affects only the Solaris x86 agents; there is no issue with Solaris SPARC agents or agents on any other operating system.
The upgrade of SCSP is quite easy and fast
1. The upgrade of the management server:
a. Double click the server.exe file from the installation folder or CD
b. During the management server upgrade, you are asked for the password to the scspdba account. If you chose the Evaluation installation when you initially installed the management server, the scspdba password is the same as the sa account password that you specified during the installation. Enter that same password during the upgrade. If you chose the Production installation, you entered the password for this account (the Database Owner account) during the initial installation of the management server. Enter that same password during the upgrade.
If you do not remember the scspdba password, you should change it in the database using SQL Server tools. This account is used strictly for upgrading the software; it is not used operationally by the management server. So changing the password in the database is safe—there is no corresponding change needed for the management server.
If you changed the name of the database owner account during a Production installation, you should enter that account name during the upgrade as well. You should not use the sa account during the upgrade.
c. Click Finish to complete the upgrade of the management server.
Note: The upgrade does not require the restart of the system.
2. The upgrade of the management console:
a. Double click the console.exe file from the installation folder or CD
b. During the management console upgrade, you are asked to confirm the upgrade as shown below:
c. Click Finish to complete the upgrade of the management console.
Note: The upgrade does not require the restart of the system.
3. The upgrade of Agents
a. Windows Agent
i. Double click the agent.exe file from the installation folder or CD
ii. Click Next,
iii. Click Next again to confirm the upgrade of the Agent.
IMPORTANT: If the prevention (IPS) feature is enable on the Agent, a restart of the server will be required once the upgrade is completed. If the prevention (IPS) feature is disabled, it will not be required to restart the server once the upgrade is completed.
Note: To check if IPS is enabled on an Agent:
1. From the CSP Console, go to Prevention View
2. Select Assets to display the list of Agent
3. An Agent with (feature disabled) means that IPS is not enabled
b. UNIX Agent
i. Run in a Terminal the Agent binary file from the installation folder or CD
ii. Once the License agreement confirmed, the installation will detect the current installed version as shown below:
iii. Press ENTER to continue
Note: No restart is required for UNIX CSP Agent once the upgrade is completed.
Q: Is there anything I should do first after an upgrade?
A: One of the first things you should do post-upgrade is to import the latest policy packs. From the Import tab on Detection and Prevention, import the latest policy packs, which are located in the packs folder on the release image. For fresh installations, this step is unnecessary, as the installation routine creates the database with the same policy packs contained in the packs folder.
Consider updating your existing policies with the policies from the newly imported packs. Unless you update your existing policies, or create new policies, you will not be taking advantage the new pack.
Q: What is the most common failure point when installing/upgrading the SCSP manager?
A: If you receive an error regarding problems connecting to the database, check to ensure that you are using the proper user account as well as connecting to the right SQL instance. Confirm that that scspdba account and password is valid independently with SQL server.
Q: Are older versions of agents supported if I upgrade the SCSP server?
A: Yes. It is fully expected that a customer will need to support a mixed set of deployed agents across multiple revision levels. In general, an SCSP server does support some older versions of agents. The SCSP Platform/Feature matrix describes the compatibility between specific agent and manager versions.
Q: Is it possible to “roll back” the SCSP management server and keep the same SQL instance without losing any data?
A: No, there is no “downgrade” mechanism whereby the SQL database will not lose data. Prior to upgrading, you will perform a full backup of the database and save all certs. Once you upgrade, any new activity will be posted into the database.
If at some later point you want to revert to the older version of SCSP:
1. Completely uninstall the console, server and database.
2. Reinstall the older server release (which will create a fresh database in your SQL instance)
3. Restore the saved database over the freshly created empty database (thus returning your data to the point prior to the upgrade).
4. 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).