Microsoft always tries to make its software installation as simple as possible, and the installation of SQL Server 2000 is no exception. You boot setupsql.exe from the X86 / SETUP folder of the installation disc, fill in some details in the installation dialog, and within a few minutes, the installation will continue to execute without user intervention. You can even successfully install SQL Server 2000 without understanding what choices mean - just click "Next" in most installation dialogs. However, I strongly recommend that you should not be touched so much; pay attention to each option and make sure you fully understand the impact of each of your choices. Some poor decisions, such as erroneous sort rules, may be difficult to be repaired; other, such as accepting the default authentication mode, may have created security vulnerabilities.
Let us look at some of the focus on standard installation, including instance configuration, security, sort rules, and network libraries. Then let us explore unattended and remote installation advanced options.
Example
When you start installation, you often perform standard installations (compared to remote or unmanned installation). You call the setupsql.exe program to launch the installation wizard. At the beginning of the two dialogs - Welcome and the machine name -, you need to choose your instance configuration. SQL Server 2000 supports instances of multiple SQL Server installed on a machine. The installer displays two dialogs to give you an option to install instances.
First, the installation selection dialog displays lets you choose whether to install a new instance or upgrade an existing installation. If you choose to install a new instance, you will see the Instance Name Dialog box. You can indicate an instance name or select the default to install a default instance - if the default instance is not installed on the machine.
When doing the choice of installing instances, you need to consider a few things. If there is no default instance on the machine, you plan to use SQL Server 2000 and 7.0 on the same machine, so that you didn't install SQL Server 2000 as the default instance. SQL Server 7.0 does not support naming instances, so it must be a default instance. In addition to uninstalling and reinstalling SQL Server, you cannot change the name instance to the default instance or the opposite. You can't change the instance after installing. However, you can install SQL Server 7.0 after installing SQL Server 2000 - if you haven't installed a default instance.
If a SQL Server 7.0 installation already exists, you can upgrade it - select the upgrade path in the installation selection dialog and describe the default instance you want to upgrade in the latter dialog. However, SQL Server 2000 will become a default instance, SQL Server 7.0 will not exist on this machine. To reserve two versions, install SQL Server 2000 as a naming instance.
Once you have installed SQL Server 2000, you can use backup and recovery, separation, and connection, data conversion services, or copying the database to the SQL Server 7.0's database to SQL Server 2000. Note that when you upgrade a previous version to SQL Server 2000, no matter what kind of way you choose, you cannot refer to a copy of the database, so each installation must maintain its own database copy.
Another consideration involving SQL Server 7.0 features a feature called "Version Switch", which makes SQL Server 7.0 coexist with SQL Server 6.5 with the same machine. However, only one installation can be active, the other is stationary. When you call the version control, it activates the stationary installation and stops the activity of the activity. If the machine includes a SQL Server 6.5 installation - it does not coexist with the form of version control and SQL Server 7.0, the installer requires you to choose one of two options: Upgrade the default instance of SQL Server 6.5 to SQL Server 2000 and in two A version control is maintained in a version; upgrade to the named instance of SQL Server 2000. Unlike the SQL Server 7.0 upgrade - it covers the current installation, 6.5 installation is kept in the computer - no matter what path you upgrade to 2000. If both 7.0 and 6.5 are installed and in the form of "Version Control", you don't want to upgrade existing installations, you can safely install 2000 named instances on the same machine and on the same machine Use all three versions. However, only one version can run in version control, and all named instances can run at the same time.
After explaining your instance option, we come to the Installation Type dialog.
Custom installation
In the Installation Type dialog box, the installation wizard requires you to choose from 3 installation types: typical, minimum, and custom. If you choose a typical or minimum, SQL Server uses the default option for component and sub-components, sort rules, and network libraries. Because typical installation potentially cause tricky problems, I strongly recommend that you always choose custom - even if you think it is default to meet your installation needs. Some previously mentioned options - especially sorting rules - If it is discovered after installation, it is very difficult to change. Custom installation allows you to check those options again.
Safety
In the installation process, you will explain and securely relevant information in 2 dialogs: service account and verification mode. In the Service Account dialog box, you fill in the service account details for SQL Server and SQL Server Agent services. Each service uses the account that is described in the dialog box to be transferred in the operating system, and runs in the security context of this account in the operating system. For example: When you back up to a disk device, SQL Server checks if you log in to SQL Server has the appropriate "Backup Database" permission. However, create a backup file device and write, SQL Server must create a file in disk or network sharing, this operation uses the security context of the SQL Server service account.
Similarly, SQL Server Agent services run the process in SQL Server, operating system, or network under the security context of SQL Server Agent service account. Although an account that does not have administrative privileges can start SQL Server service, it is a good idea to add SQL Server service account to the local administrator group. Otherwise, you need to give additional permissions to the account, but also you need to authorize the appropriate network privileges.
And if you try to launch the SQL Server Agent on a service account that does not have administrator privileges, it can't be started. And if the SQL Server Agent executes operations on the network, such as copying or multi-server work, you should use a domain account with appropriate permissions on other machines. For example, in a single domain multi-server environment containing 3 SQL Server machines, a primary server controls automatic activity on the target server. Because both parties (primary servers and target servers) need to communicate with each other, you need to make sure that the SQL Server Agent service account on the primary server has the appropriate permissions on the target server, and vice versa. The easiest way to configure such an environment is to create a domain account so that it is a member of the local administrator group on all servers and invokes all SQL Server Agent services through this account. In the Authentication Mode dialog, you can choose whether you only allow Windows authentication logging (Windows Authentication Mode) or both Windows and SQL Server log in (mix mode). You can also specify a password for SA (System Administrator) SQL Server. Windows Authentication Mode is the default and most commonly recommended security mode. However, for safety, I suggest you choose a mixed mode and provide a password for the SA account. After the installation is complete and processed, the verification mode is changed to Windows authentication mode. If you choose Windows Authentication Mode as a security mode of your server, the installation process creates SA login as invalid and there is no password (because SQL Server authentication mode is invalid). You can change the password after installation - I strongly recommend that you do this - but you will choose a Windows authentication mode in the beginning, because you may forget to change your password or use empty password, think that SA has expired.
No matter what model you choose, the installer creates a Windows authentication for the Builtin / Administrators group, which is mapped to the administrators group of the local machine. The creation of this login means members of all local administrators groups, including domain group administrators, are members of your SQL Server's system administrator (SYSADMIN) role. Unlimited permissions given to network and local administrators are not always a good idea, because this introduces security risks, so that you may decide to remove Builtin / Administrators from SQL Server's sysadmin roles. Or you might remove these automatic created logins from SQL Server to create a login for the DBA member group - not a network administrator.
If you decide to follow these suggestions, this is enough: First, create a login for the DBA member group as Sysadmin, then delete the Builtin / Administrators login. If your server is authentication mode, Windows and you can delete all Sysadmin qualifications before you have a login for DBA. You will find that you are locked in SQL Server, you can't perform administrative tasks - such as: Creating new Login. If you fall into this trap, you can still change the SQL Server authentication mode to a mixed mode by changing the registry hkey_local_machine / software / instance name / mssqlserver / loginmode's key value to 2. After the modification is good, restart the SQL Server service.
Although the login mode of SQL Server can be controlled by the registry, it also has a disadvantage. Anyone only has permission to edit registry key values, including network and local administrators, can change the authentication mode of SQL Server. If you use Windows Authentication Mode to install SQL Server, sa is invalid but still has a blank password. If you then change the SQL Server authentication mode to the mixing mode (this makes sa logins), anyone can log in as SA. So, absolutely make sure you change the SA password or select a mixed mode during the installation process and provide a password for SA. Sorting rules
Next, you need to select the sort rule settings. Sort Rules in SQL Server 2000 sets the uniqueness of managed and language-related behavior, object names, and columns, and Sorting Rules. In the Sort Rules Settings dialog box, you will choose the sorting rules and choose one between the SQL Server sort rules and Windows sort rules. If you need backward compatibility with previous SQL Server versions, select SQL Server Sort Rules - For example, if you intend to use replication between an earlier version of SQL Server and SQL Server 2000. Otherwise, select Windows Sort Rules. SQL Server 2000 sort rule settings, whether it is Windows or SQL Server, combined with 3 independent settings in previous versions: character sets, sorting order, and Unicode rules. In addition to integrating the old three settings, SQL Server 2000 also provides more powerful flexibility than previous versions.
The sort rules selected when you install SQL Server 2000 determine the sort rule settings for the system database. To set the rule setting for the system database after installation, you need scripting all your system objects (such as: login, message, work) and run RebuildM.exe, which rebesses all system databases with new sort rules. However, you don't have to export all the data in the user database and then import them after running Rebuildm.exe - just like you in SQL Server 7.0. You only need to reconnect the user database to SQL Server. You can configure your user database with a sort rule (this is a template system database), or even a database that is different from the server settings or resumes a database. You can modify the default sort rules for the user database later. For a specific list, you can specify a sorting rule that is different from the default database sorting rules; you can even modify the column sequence rules later - if the index is created if the column is created.
Although SQL Server 2000 SQL Server 2000 is flexible in sorting rules, don't underestimate your choice for installation. As I said earlier, the server's sort rules apply to all system databases and determine the sorting rules recorded in all objects (such as login names, database names) in the system database. Further, Tempdb's sorting rules are also the server sorting rules you have selected during the installation process. When you create a temporary table, the list is column using Tempdb's sorting rules - unless you specify the collate database by definition in each column.
Network library
After you explain the sorting rule setting, you came to the Network Bank dialog. The network library is a protocol for client applications to communicate with SQL Server. Both clients and SQL Server must have at least one matching network library, which can be communicated by both. In the Network Bank dialog box, you set up SQL Server will be used to communicate with the client.
In SQL Server 6.5, only named pipes and multi-protocols ... Xu WINDOWS authentication; all other network libraries only allow SQL Server authentication. In this way, for SQL Server 6.5, you select a network library when you want to support the login type. Further, only multi-protocols allow data encryption, so if you SQL Server 6.5 support data encryption, you have to choose this network library. In SQL Server 7.0, all network libraries support Windows authentication, you are more flexible in this sense, but multi-protocols are still uniquely allowed data encrypted networks. In SQL Server 2000, you can enforce encryption by using SQL Server Network Tools and SQL Server Client Network Tools (SSL), which, in this way, encryption factors are no longer Decide the choice of the network library. Similarly, in SQL Server 2000, multi-protocols do not support named instance (server name / instance name), in which multi-protocol is not a good choice when you use a named instance. The most common network library in SQL Server 2000 is probably a TCP / IP socket. It provides good performance, allowing Windows authentication, and you can force SSL encryption when you need.
Most users who use SQL Server Early Version know that the default TCP port of SQL Server is port 1433. When using the default port, the client connection does not require a port number in addition to the server name or IP address. However, SQL Server 2000 supports multiple instances, which cannot use the same port number. So when you install a naming instance, the installer suggests 0 as the port number. The port number is 0 means that when SQL Server starts the first startup, it dynamically selects an idle port number and keeps it permanently or by manually modify it later. Then how the client connection continues to find SQL Server without specifying the port number by providing the server name / IP address instance name but specifies the port number? A client request on the SQL Server 2000 listening to the client request on the port 1433, and then matches the instance name in the request and the port number of the request and the instance match, and then the request is redirected to the appropriate instance.
Unattended and remote installation
Now our standard installation has been completed, let us discuss unattended installation. The setupsql.exe program allows you to record the next answer file, which includes all your answers to the various installation options in the installer dialog. Later, you can run a installation by calling the setupsql.exe command for the response file as the parameter. This type of installation that does not require any user intervention is called unattended installation.
To prepare a reply file, start the installer first, select Advanced options in the Installation Selection dialog box, select "Record unattended .iss file" in the dialog box. The installer will guide you to complete the regular installation dialog, where you can fill in all the options you want to log. When you are finished, the installer creates a file called setup.iss under the / Winnt folder.
To start an unattended installation, run the setupsql.exe program, use -s as a parameter that performs quiet installation, the -fl parameter specifies a response file. For example, to start a quiet, unattended installation - do not inform you after the installation is complete, you can use the following command:
If you want to get notifications when the installation is complete, do the following setupsql.exe programs from the command line, or write it into a batch file:
START / WAIT
START / WAIT D: /X86/Setup/setupsql.exe -s -fl c: /winnt/setup.iss
Net Start MSSQL $ INST1
OSQL / E / I "C: /Data/scripts/createAppdb.sql"
If you don't use the start / wait option, control from the beginning of the installation to the second command of the batch file, and this NET Start command tries to start a service that is not there.
Troubleshooting an unattended installation is more careful than the troubleshooting of the standard installation. Standard installation is often informing you by displaying a dialog box containing error messages (and accompanied by a loud warning sound) when the installer encounters a problem. Unattended installation is simply endless, and there is no notification of interaction.
To learn how to troubleshoot unmanned installations, let us see a group I have encountered. Suppose you have completed the installation of another product on the server, then you try to perform an unattended installation of SQL Server. The installer detected that the server has not restarted after the previous installation, so there is no information prompt. If you keep the task manager window open, you will notice that the setupsql.exe program is inactive, so SQL Server is not installed. You should also check the log file. Once the installation is successful, the / winnt / setup.log file should display 0 as an error code; however, in the scenarius I have described, he is likely to show -1, which means a basic error. You should also look at the error message.
When the execution of unattended installation, another error I have encountered many times is "dialog box order disorder". I will realize the presence of this problem shortly after I call the installer - That is to open the Task Manager and see that although setupsql.exe is running, it is called and release the process like normal unattended installation. At the same time, the installer is usually not created in the folder created under / program files / microsoft sql servers. The setupsql.exe program does not occupy the CPU or I / O resource, just disappeared after about 10 minutes. Setup.log file Displays a -12 error code and the SQLSTP.log file shows no error - in fact, it seems to have not been completed. SQLSTP contains incomplete considerations, just a message - Begin Action: DialogShow
In addition to fully installation, you can also perform unattended installation of SQL Server 2000 service packages. To apply the service package to the default instance, call the setupsql.exe program from the installation directory of the service pack, indicating that the answer file is SQL2kdef.iss in the root directory of the service package installation directory. For example: If the service package installation file is under C: / SQL2KSQ2, perform the following command: start / wait c: /sql2ksp2/x86/setup/setupsql.exe -s -fl c: /sql2ksp2/sql2kdef.iss
To apply the service package to a named instance, use the SQL2KNM.iss answer file, but first modify the following two lines in the file to correspond to the correct name:
InstanceName = instance_name = INSTANCE_NAME
NMPPIPENAME = //. / Pipe / MSSQL $ Instance_name / SQL / Query
Another advanced option - Remote installation - allows you to install SQL Server 2000 on a remote computer. You can manually record the next setup.iss file from a local computer, copy it on the remote computer, activate the setupsql.exe program and the setup.iss file on the remote computer. However, you can save yourself - use the computer name dialog in the computer name dialog box to indicate the computer name you want to install by running the setupsql.exe program on the local computer. When you click Next, the Remote Install Information dialog will appear.
First you have to provide account details (user, password, field), to the UNC path of the target folder and the UNC path of the source installation file. Next, the installer will guide you through the General Installation dialog and record the setup.iss file based on your selection. Next, the program replicates the setup.iss file to the target computer / Winnt folder, and then use the copy setup.iss file to activate Setupsql.exe.
If you open the Task Manager on the target computer, you will see the setupsql.exe process call and release other processes during the installation process. On the local computer, the installer displays the remote installation and notify you when you are finished.
Last words
Although the basic installation is simple, you still need to pay close attention to the installation options you choose and fully understand them. Good installation selection provides a solid foundation for running and managing SQL Server. And if you think that unattended installation and remote installation are complex, I hope this article will help you deepen them.
