"Database population failed” when configuring the Symantec Critical System Protection (SCSP) Server to use a custom port to communicate with the SQL DB

Article:TECH194274  |  Created: 2012-08-01  |  Updated: 2012-10-29  |  Article URL http://www.symantec.com/docs/TECH194274
Article Type
Technical Solution




During a new SCSP 5.2 RU8 MP4 installation, a database population failure occurs when configuring the SCSP server to use a custom TCP port to communicate with the SQL DB Server. 



 "Database population failed” error is encountered during the SCSP Server install.


Microsoft does not allow an SA login with hostname/default instance name. For e.g. MyMachineName/MSSQLSERVER.

One needs to specify only hostname and the password. However, if just the hostname is entered the install dialog with go through but will gernerate an error during the install ahead.


Fixed in: 5.2.9 MP1 (estimated availability in December)

Workaround: Hard code instance name as MSSQLSERVER in dbtableloader.txt during install extract time by pausing the install.
Steps to implement workaround:
1. Before starting the install, log into the SQL Server Managament Studio and delete:  
    a. the SCSPDB
    b. the accounts [i.e. SCSP_OPS…etc.]
2. Ensure that the SQL Browser Service is running
3. Start the installation and as soon as the JRE starts getting extracted, pause the installation and go to the tempdir/ search for dbtableloader.txt and msde_params.bat and replace the instance name with MSSQLSERVER
4. Resume the installation
5. Go to tomcat /conf/server.xml files and update the instance name with MSSQLSERVER

NOTE: Do not use a % in the password. This is not currently supported.

Supplemental Materials


There are 2 ports involved in MS SQL, (1) the discovery port [1434] and (2) the actual instance service port [1433 by default].
• Changing the service port of the SCSP instance from 1433 to something else is fine. Other customers have changed the service port successfully as this is the port that it makes sense for customers to want to change.
• Changing the discovery port has been known to cause issues. Since MS SQL uses this well-known port [1434] to request information about specific MS SQL instances [including what port an instance is listening on], it is not recommend to change this port. 
• Changing the discovery port to something else has not been fully tested with in QA. As a result, we feel that the current problems this customer is encountering with SCSP are related to known issues surrounding installation/upgrade of SCSP when it is unable to communicate through port 1434 and get a response. 
Please see the following KB articles that talk about the ports required for the SCSP Server to communicate with the MS SQL instance:
The statement below was taken from the TECH112893 - Frequently asked questions about Symantec Critical System Protection 5.0:
“Communication from the Management Server to the Microsoft SQL Server requires that your firewall permit traffic on UDP port 1434 and on the TCP port that is used by the Symantec Critical System Protection instance. The Management Server uses UDP port 1434 to query the Microsoft SQL Server for the TCP port that is used by the Symantec Critical System Protection instance. After the Microsoft SQL Server provides the TCP instance port number, the Management Server uses that port to connect to the instance.” 
For more information about Microsoft SQL Server ports, read How to configure an instance of SQL Server to listen on a specific TCP port or a dynamic port, Article Number 823938
This article discusses that we do allow customers to customize the service port [1433]of the SCSP instance, as long as the SCSP Server can talk to the MS SQL discovery port [UDP 1434] which cannot be modified. Again this is needed so that SCSP will be able to look up the SCSP DB instance and find the correct port for the instance.

Article URL http://www.symantec.com/docs/TECH194274

Terms of use for this information are found in Legal Notices