SQL Server 2000 Administration in 15 Minutes a Week: Advanced Installations

Friday May 17th 2002 by Michael Aubert

Michael Aubert's third article in the SQL Server 2000 Administration in 15 Minutes a Week series covers more advanced issues when installing SQL Server, including performing an unattended installation, remote installations, types of clusters, and service accounts.

Welcome to the third article in my series SQL Administration in 15 Minutes a week. Up to this point we have gone over the requirements for installing SQL Server and we have performed a basic installation. This week I will show you more advanced issues when installing SQL Server. The topics for this article include:

- Performing an Unattended Installation
- Remote Installations
- Types of Clusters
- Service Accounts

Performing an Unattended Installation

If you have ever deployed Windows 2000 in an environment with hundreds of systems you know about the benefits of performing Unattended Installations. Using a setup file, containing the installation parameters, you can automate the installation of Windows 2000. This same capability to automate an installation of Windows 2000 is available for SQL Server 2000. Using an Unattended Installation you can install the components needed for SQL Server, the Client Tools, or Connectivity Only. However, you can't use an Unattended Installation to perform tasks such as setting up Failover Clustering or Change the Optional Components that are already installed.

SQL Server uses a batch file (.BAT used to begin the installation) and an Installation Setup Initialization file (.ISS that contains the information needed during the installation) to perform the Unattended Installation. Both the Batch and the Installation Setup file can be edited with a simple text editor such as Notepad. SQL Server even provides you with sample Batch and Installation files that can be edited and used as needed. The example files can be located on the root directory of your SQL Server 2000 CD.

There are three ways to create an Installation Setup Initialization file:

- Use the file created after installing SQL Server 2000
- Use the SQL Server 2000 Setup program
- Create a file by hand or edit an existing file

The first way to create an .ISS file is to perform a normal installation of SQL Server 2000. Each time you install SQL Server 2000, setup automatically creates a setup.iss file located in the <SQL Program Files Directory>\Install folder. You can copy this file and then use it to install SQL Server on another system, back up the file in case you need to reinstall SQL Server, or use the file as a beginning template that can be edited by hand.

The second option available is to use the SQL Server Setup program to create an Installation Setup Initialization file for you without actually installing SQL Server. The process is very similar to installing SQL Server 2000, except the final stages of adding registry keys and copying files are skipped. To create your own .ISS file, start the SQL Server 2000 installation as you normally would on the local computer. When you are prompted to select an Installation Option choose "Advanced Options."

Once you have selected "Advanced Options" click Next.

The Advanced Options screen can be used to perform several different tasks:

- Record Unattended .ISS file: Allows you to record an Installation Setup file that can be used to perform an unattended Installation of SQL Server. We will take a closer look at this option shortly.

- Registry Rebuild: Allows you to recover your SQL Server installation if your registry becomes corrupted. You will need to provide setup with the installation options you chose when you originally installed SQL Server.

- Maintain a Virtual Server for Failover Clustering: Allows you to maintain your SQL Server 2000 clusters including adding and removing nodes from a cluster. Note that this option is grayed out because the computer I used does not have clustering enabled.

Select Record Unattended .ISS file" and click Next.

From this point on the setup process will proceed as normal. However, once you reach what would be the final step of a normal installation, copying files to your hard disk, setup will exit without installing SQL Server. You can then locate the .ISS file SQL Server 2000 setup has created in the SystemRoot (ex: C:\WINNT) folder on your hard drive. The file will be named setup.iss.

Page 2: More on Unattended Installations

 » See All Articles by Columnist Michael Aubert

The third way to create an Installation Setup Initialization file is manually. You can start with a blank file and create the file line by line (if you're feeling very industrious), or you can use one of the previous two methods to create a file that you can then edit.

Editing an .ISS file can be accomplished by opening the file from Notepad:

Click to Enlarge

Review the following link to learn about the different sections of the Installation Setup Initialization file (this is important for the exam): http://msdn.microsoft.com/library/en-us/instsql/in_runsetup_6nz9.asp

Once you have created your custom Installation Setup Initialization file you need a way to initiate the installation. You can initiate the installation by entering the appropriate commands at the command prompt or by creating a batch file to start the installation.

Beginning an unattended installation from the command prompt is not a big deal if you only have a few systems, located locally, that you need to install SQL Server on. Imagine if you needed to install the client tools on hundreds of workstations. To simplify that daunting task we can use a batch file and SMS (Systems Management Server - http://msdn.microsoft.com/library/en-us/instsql/in_runsetup_43eb.asp) to install SQL Server 2000 without having to visit every computer. You can also use a batch file if the task of installing SQL server will be done by someone who has very little knowledge of the network or SQL Server. For more information on batch files look at the examples provided with SQL Server.

No matter which way you choose to start the Unattended Installation, both methods run setupsql.exe located in the \x86\setup directory of your SQL Server CD (ex: D:\x86\setup\setupsql.exe). You can then use command-line parameters to specify how setup should run.

The table below shows you the command line parameters available with setupsql.exe:




Run setup in silent mode with no user interface

-f1 <file>

Specifies an Installation Setup Initialization file ex: -f1 setup.iss


Returns control back to the command line only after setup has completed. You use this parameter in a batch file in conjunction with the "start /wait" command

Remote Installations

Performing an installation of SQL Server 2000 on a remote system is a lot like performing a local installation of SQL Server. SQL Server Setup accomplishes a Remote Installation by creating a setup.iss file from the information you provide, copying the setup file and other files to the \admin$, directory and then starting a service on the remote server to begin an Unattended Installation on the remote system.

Due to the fact a Remote Installation is just an Unattended Installation that is started on a remote system for you, Unattended Installations have the same restrictions Remote Installations have. This means you can't use a Remote Installation to setup Failover Clustering, Remove SQL Server, or Change the Optional Components that are already installed.

To begin a Remote Installation of SQL Server 2000, run the SQL Server Setup as you normally would. When you are prompted to select the computer you would like to install SQL Server on, select "Remote Computer" and then enter the name of the system you would like SQL Server (or the client tools) to be installed on. You can also click the Browse button to see a list of available systems.

After you have selected the system you would like to install SQL Server on, click Next.

Not a lot of options on the next screen:

Select "Create a new instance of SQL Server, or install Client Tools" and click Next

The next Setup screen is unique to the Remote Installation. This screen prompts for the account and path information that will be used to install the SQL Server. The account you choose should have Administrative privileges on the remote system. An important thing to note is the account you enter on this screen is only used during the installation and has nothing to do with the Services or Logon accounts of SQL Server.

The Target Path you enter should be given in the Universal Naming Convention form. In this example I am installing the files on the "C" drive of SQL2. The Setup Source Files textbox specifies the location of the SQL Setup files. In this example the files are located on the server named CDSRV and are located in the SQL_ENT share.

Enter the appropriate information and click Next.

From this point on the Remote Installation will prompt you for the Installation Type, Service Accounts, Authentication mode, Collation, etc. (just like a basic installation). Once Setup has all the information it needs, it will then begin an Unattended Installation on the remote system automatically.

Page 3: Types of Clusters

 » See All Articles by Columnist Michael Aubert

Types of Clusters

Windows 2000 Advanced Server and Datacenter Server both provide Cluster Services including Network Load Balancing and Fault Tolerance. SQL Server 2000 is a fully "cluster aware" application that takes full advantage of the Fault Tolerant services that are provided by Windows. However, SQL Server 2000 can't take advantage of Network Load Balancing (or NLB). Network Load Balancing is designed for services such as ISS, HTTP, FTP, etc.

Each server in a Fault Tolerant Cluster is referred to as a node. Each node in the cluster must have access to a shared SCSI bus. Although each node's operating system is located on the individual servers, the shared applications (SQL Server in this case) are located on the SCSI bus that is accessible by all the nodes in the cluster.

To determine when a node has failed, nodes frequently send out what are called "heartbeat messages" to each other over the network. In the event that heartbeat messages are no longer detected from a specific node, the other servers in the cluster treat the node as failed and transfer the services from the failed node to another node. The actual process of detecting a failed node and transferring the services is a little more complicated, but I could write a whole other article on just that topic (and I may do just that, especially if anyone is interested).

There are two types of nodes in a Fault Tolerant Cluster:

- Primary Node: One per cluster
- Backup Node: One per cluster using Advanced Server or up to three if using Datacenter Server

The Primary Node is the system that does all the "work" in the cluster. The primary also controls the drives on the SCSI bus that contain the shared application. Unlike the Primary Node, Backup Nodes are only standbys who check to see if the Primary Node is still active. Backup Nodes have physical access to the SCSI bus, but do not access the drives unless they become the Primary Node.

The configuration of one primary doing all the work with one or more standbys is known as an Active/Passive configuration. If you are running large mission critical applications that can't afford any downtime or loss of performance, this is the configuration for you. However, to use an Active/Passive configuration on a large system is very expensive.

If you don't like the idea of having one server doing nothing most of the time or you can't afford all the servers you would need, you can use an Active/Active configuration. An Active/Active configuration is more like an Active/Passive and Passive/Active put together. In this configuration each server in the cluster acts like a Primary Node controlling part of the shared SCSI bus and also acts like a Backup Node. Using multiple instances of SQL Server you can then create a load-balancing effect (but not true load balancing). The downside to an Active/Active configuration is that in the event that one node fails, the backup node must perform the work of both nodes. This can result in degradation of performance especially if you don't have the hardware needed to support both applications on one server.

I have just scratched the surface on clustering. Clustering is a neat topic and if you would like to learn more have a look at the following links:


Page 4: Service Accounts

 » See All Articles by Columnist Michael Aubert

Service Accounts

The last topic we are going to cover in this article is how to change the service accounts SQL Server 2000 uses. If you remember from my last article, during the installation of SQL Server we are prompted to choose what accounts we would like SQL Server to use. If you ever need to change the accounts used, the process is fairly simple.

To access the Services console in Windows 2000, open Control Panel and select Administrative Tools.

Click to Enlarge

Open Services to launch the Services console.

When you scroll down the list of services you should see MSSQLServer and SQLServerAgent if your SQL Server is installed as a Default Instance. If you have one or more Named Instances installed, the name of the services are MSSQL$InsName and SQLAgent$InsName (where InsName is the instance's name) respectively.

Once you have located the appropriate service, you can double click to view the properties for that service.

On the General tab you can stop, start, pause, and resume the service. Setting the Startup type allows you to specify if the service should start when Windows starts (Automatic), should only start if the service is required or if you start it by hand (Manual), or if the service should never run even if required (Disabled). You can also give this service a description -- handy if you have many named instances installed.

The last screen we are going to look at in the Services section is the Log On tab. From here you can select the account the Service will use. You can select to use the Local System account or you can use another account (ex: a Domain account). Clicking the Browse button lets you see a list of available users to select from.

That will finish it up for this week and will also complete our look at SQL Server 2000 Installation topics. Next week we will take a look at the Enterprise Manager. As always, if you have any technical questions please post them on the SQL message board.Please send any non-technical questions, comments, and feedback to my email. I hope you are finding this series to be a useful one, and I'm looking forward to your feedback.


» See All Articles by Columnist Michael Aubert

Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved