Dave McVie
MCSE, Microsoft Product Support Services
November 1998
Summary: Provides information on installing Microsoft SQL Server 7.0. (10 printed pages). Covers:
Why a New Setup Program?
What If I Encounter an Error in the New Setup?
Process Overview
Running Setup
Scripting
Windows 95/98 Limitations
Additional Tools
Remote Installation
Frequently Asked Questions
If your installation fails and you are unable to determine the cause, you should look for and save the sqlstp.log file in the Windows directory and the cnfgsvr.out file in the Mssql\Install\ directory, along with any other files that are left under your target program directory location (for example, C:\Mssql7). Of particular interest is the cnfgsvr.out file and any error logs in the Mssql7\Log directory. If the Setup application fails, it will roll back changes to the file system, including removing any copied files, and also remove changes to the registry.
This section provides you with all the facts you need to know to install SQL Server 7.0, such as the minimum system requirements for your server computer. This section also provides a high-level overview of the setup process.
Upon inserting the SQL Server 7.0 CD into your computer, you will be presented with the main SQL Server 7.0 installation screen. If this screen is not presented, browse the CD and double-click the autorun.exe file. This application presents you with options to read the release notes, browse Books Online, connect to the Microsoft SQL Server Web site, or install the product and prerequisites. Prerequisites for the appropriate platform should be installed prior to installing SQL Server 7.0.
After all of the prerequisites are installed, you are ready to continue with the SQL Server 7.0 installation. After the SQL Server 7.0 Setup begins, it will check to see if the Open Database Connectivity (ODBC) files are available for updating. If any application or service is using the ODBC drivers, a dialog box will be presented showing the services or applications that should be stopped before Setup continues. A retry option is presented to help determine if the ODBC files are "unlocked." If Setup is run in the "Maintenance mode," this check is not reformed.
Users are prompted to select one of three setup installation options: Typical, Minimum, or Custom. A Typical setup installs the SQL Server binary files to the Mssql7 directory. The Typical option installs the data devices in the Mssql7\Data directory, and uses Named Pipes and Sockets listening on port 1433. To change these default settings, you must select the Custom installation option. If SQL Server Setup detects that SQL Server 6.x is installed on the computer, the Upgrade option is presented on the dialog boxes that appear. The following lists show what components are or are not installed with each installation option:
After the components have been selected, the Setup program has enough information to continue. Setup informs the user it has sufficient information and starts the process. The file copy process moves all required files to the selected installation path and to the Windows directories. Next, Setup attempts to stop the MSSQL and the SQL Executive service if a previous version is installed (6.0 or 6.5). A failure to stop these services is not considered a fatal error, and Setup continues. Distributed Transaction Coordinator (DTC) is handled by the DTC package; it has its own Setup routine to stop the service and install components.
The next step is to install the packages that are needed for additional support components. These consist of: Microsoft Data Access Components (MDAC), Microsoft Management Console (MMC), MSDTC, HTML Help viewer, DLT Tape driver, and the Monarch full text search engine. The selection of packages is based on the platform Setup is running on and the selections made by the user. Each package self-registers itself with the operating system and with SQL Server Setup. The appropriate entries for SQL Server, SQL Agent, and SQL Server-related components are also added.
After the registry values have been modified, the system path is updated to include the new Mssql7 entry and the SQL Server service is started. When the SQL Server service is running, Setup then runs cnfgsvr.exe to set up the initial SQL Server configurations. If a character set or sort order other than the default was selected during the Setup choices, system tables are updated with the new code page, sort order, and unicode collation. The SQL server is stopped at this time and then restarted with a trace flag to reindex all system tables.
After all of the preceding steps have occurred, the following will be done:
During Setup, the following informational files are generated to help locate any problems that may occur. Should you encounter any difficulties during Setup, save these files and review them for possible causes:
One of the most significant changes from moving to an InstallShield-based Setup has to do with unattended installations and uninstallations. Unfortunately, conversion or support of existing .ini files in the new Setup is not provided. For each existing .ini file, a new .iss file must be created, as described in this section.
To invoke an unattended installation, you must first generate an InstallShield .iss file. Start SQL Server Setup with the k=Rc switch and proceed through the dialog boxes to install SQL Server as normal. Doing this causes Setup to record your dialog box choices in a file named setup.iss, which is located in your Windows directory — this will not install SQL Server on the local computer. After this process is completed, the file can be moved or copied to another location for use on other servers. For subsequent automated installations, start Setup and specify a previously generated .iss file as input by using the -f1 setup command-line option. The syntax for this command is:
setupsql.exe -f1 <full path to iss file> -SMS -s
If the -SMS switch is not specified, the underlying InstallShield setup process, sqlstp.exe, starts a process to perform the Setup and will immediately return control back to the user. The -s switch causes Setup to run in a silent mode.
To start an unattended uninstallation, run isuninst.exe with the -y switch to suppress confirmation of the uninstallation. The -a switch will suppress the dialog box that asks if you want to remove shared files, and the -f switch points UnInstallShield at the uninstallation script file that was generated during the initial Setup. The file "isuninst.isu" is created during Setup and is found in the MSSQL7 directory. Lastly, specify the SQL Server uninstall .dll file name (sqlsun.dll). This .dll file contains specific SQL Server actions that are taken during the uninstallation. An example of the syntax for the uninstall command is:
isuninst.exe –f <path to the isu file>\uninst.isu -cc:\mssql7\sqlsun.dll -y –a
Note When you attempted to uninstall SQL Server in earlier versions of SQL Server, Setup would attempt to stop a list of applications if they were running. This was not always successful and resulted in nondeterministic behavior. Setup now stops any of the SQL Server services that are running, but also reports back to the user if any of the SQL Server 7.0 applications are running and could not be stopped. The user must stop these applications or services before running the uninstallation process, either manually or by using a tool such as the Windows NT KILL command or Net Stop.
The following example shows the commands used to generate the setup.iss file:
Setupsql –r "creates the initial iss file"
Copy c:\winnt\setup.iss to c:\myinstalls\sample.iss
Setupsql -f1 c:\myinstalls\sample.iss -SMS –s "uses the iss file for an unattended install"
Check for required restart as indicated in the sqlstp.log and restart if necessary. Run any verifications that are required.
The following example shows the commands needed to uninstall SQL Server 7.0:
Terminate any running SQL Server executables (e.g. sqlmanager.exe)isuninst.exe –f c:\mssql7\uninst.isu -cc:\mssql7\sqlsun.dll -y –a
When you run the unattended installation, an error may be returned. The errors you might receive are designated by error code numbers. The following is a list of possible error code numbers and their explanations.
The most common error code is -12, because a user will use an .iss file that is generated when an unexpected dialog box appears (because of a condition of the system).
If the -f2 option is not used to specify the path for this output file, it will be placed in the Windows root directory.
| 0 | Success |
| -1 | General error |
| -2 | Invalid mode |
| -3 | Required data not found in the setup.iss file |
| -4 | Not enough memory available |
| -5 | File does not exist |
| -6 | Cannot write to the response file |
| -7 | Unable to write to the log file |
| -8 | Invalid path to the InstallShield Silent response file |
| -9 | Not a valid list type (string or number) |
| -10 | Data type is invalid |
| -11 | Unknown error during setup |
| -12 | Dialogs are out of order |
| -51 | Cannot create the specified folder |
| -52 | Cannot access the specified file or folder |
| -53 | Invalid option selected |
Because of system limitations of the platform and performance issues, Windows 95/98 installations do not have the following capabilities:
The following additional tools are also available. These tools are available on all platforms, unless otherwise noted.
Regrebld.exe is run automatically when Setup completes the initial installation. This creates an image of all the Mssql7 registry entries with file names of Mssql7*.rbk. Running regrebld -Restore will place the registry key images into the registry. If the keys already exist, they will be overwritten. If changes are made to the SQL Server installation, backups of the registry keys are not automatically updated. In this case, you will need to rerun regrebld.exe manually to update the information. You may want to consider rerunning regrebld.exe after adding additional network support or changing the security options. The following shows the syntax of the Regrebld command, along with the valid arguments it can take:
F:\mssql7\BINN>regrebld /?
Microsoft SQL Server Registry Rebuild App accepts the following command-line arguments:
-Backup <Directory to put backup files (Defaults to same directory as regrebld.exe)>
If the backup files already exist this will fail
-Restore <Directory location of backup files (Defaults to same directory as regrebld.exe)>
-ShortcutsOnly 1 <can only be used in Restore mode>
No command-line arguments indicate to do a full Registry Rebuild with backup, re-creating shortcuts, and verifying state of services on Windows NT. When verifying state of services Registry Rebuild should always be run from the SQL Server BINN directory.
The source directory in the following dialog box refers to the location of the original SQL Server files (that is, the distribution CD or network share point).
This utility can be located by clicking the Start button, pointing to Programs, pointing to Microsoft SQL Server—Switch, and then clicking SQL Server 7.0. This utility is included to offer systems in transition from SQL Server 6.x to 7.0 the capability to move between SQL Server versions 6.x and 7.0. The utility does not allow both versions of SQL Server to be run simultaneously, and it is only intended to be used during the migration phase, not in daily production. The utility copies the current registry value to either the MSSQLSERV6.x or 7.0 registry key and then moves the desired version information (6.x or 7.0) to the MSSQLServer entry. Additionally, it changes the PATH statement to reflect the Mssql or Mssql7 directory.
Remote Setup is supported on Windows NT-to-Windows NT computers only; both computers must be of the same processor type. Remote Setup is not supported on a clustered Windows NT Server. Remote Setup can only be used for a new installation. Upgrades, maintenance mode, or build-to-build upgrades are not supported.
Remote Setup will only install the same version of SQL Server 7.0 on the remote computer as the one that is being run on the source computer. For example, if you are running the SQL Server 7.0 standard edition on a Windows NT Server computer and attempt to remotely install SQL Server 7.0 standard version to a Windows NT Workstation computer, the setup will fail because Windows NT Workstation only supports the client installation of the standard SQL Server 7.0 edition (Windows NT Workstation does support the desktop version of SQL Server 7.0). Use the same version of SQL Server on the local computer as the one you will be installing on remote computers.
The user account specified must be an administrator on the remote computer and have read access to the universal naming convention (UNC) path that is specified for the source files. The "logon as service" right is granted to this account on the remote computer during the remote setup process.
The "remsetup.exe" copies the generated setup.iss file to \\targetmachine\admin$, and then runs the Service Control Manager to create a remote service, therefore account supplied must be an administrator on the remote computer because it is creating a service and copying files to admin$ share.
After the user has input all of the setup information, Setup records this information in an .iss file. On the local computer, Setup then launches remsetup.exe and exits. Remsetup.exe installs the remote service, copies all files to the admin$ share, and runs an unattended installation on the remote computer.
How do I start an unattended setup?
To start an unattended installation, you must first generate an .iss file. You can create this file by starting SQL Server Setup with the -r option and then going through Setup, interactively making the selections you want. After the installation completes successfully, you will have a setup.iss file in your Windows directory. You can copy or move this file to another location if you want. On subsequent installations, you can start Setup and specify a previously generated .iss file as input by using the -f1 setup command-line option. For detailed information on scripting, see the "Scripting" section earlier in this document.
How do I uninstall SQL Server 7.0?
With SQL Server 7.0, you now have three ways to uninstall the program:
How do I start an unattended uninstallation?
One of the results of a successful installation is the generation of an uninstallation script file, called uninst.isu that is located in the directory you installed the program files to. To start an unattended uninstallation, you must start the UnInstallShield executable file named isuninst.exe, and direct it to your uninstallation script file. For detailed information on how to do this, see the "Scripting" section earlier in this document.
Why do I lose my dialog box selections? Whenever I type information into a dialog box, click "Back" and then click "Next" again, the information that I typed in the dialog box is lost. Why does this happen?
This is the result of InstallShield dialog boxes. Unfortunately, at this time there is no workaround other than to simply retype the original text again.
What do I need to do if I have an unsuccessful installation?
If your installation fails and you are unable to determine the cause, look for and save the sqlstp.log file in the Windows directory, as well as any other files that are left under your target program directory location (for example, C:\Mssql7). Of particular interest are the cnfgsvr.out file and any error logs in the Mssql7\Log directory.
How do I rebuild the registry? How do I rebuild the master database? How do I reconfigure my server network protocols?
Rebuild Registry, Rebuild Master, and Configure Network Protocols have all been removed from the SQL Server Setup code. However, the same functionality will be granted through new utilities.
Why do I have to exit the SQL Server Service Manager before I uninstall the program? In earlier versions of SQL Server, Setup stopped SQL Server Service Manager when it initiated an uninstallation. Now I get an error message informing me that I need to exit this application. Why is this and why can't Setup close this application for me?
In earlier versions of SQL Server, Setup would attempt to shut down these services, without being able to completely guarantee success. This was changed so that the applications must be closed manually.
Why aren't some directories deleted when the product is uninstalled? Why does the final uninstall report always report that it cannot remove folders?
UnInstallShield only removes what it installs. In general, this is the correct behavior. However, some files, such as tempdb, are created outside the bounds of the InstallShield installation. When the InstallShield uninstaller runs, it tries to delete the folders that it created (Mssql7, Binn, Data, and Log) and finds that these folders are not empty. However, the .dll that is run after UnInstallShield is complete (sqlsun.dll) removes files, such as tempdb, and these folders.
Note If error logs, trace files, or user data remain in these directories, they will not be removed.