Follow these steps to install Microsoft SQL Server:
1. Launch the installation. Click OK to have the SQL Server 2008 R2 setup enable the Microsoft .NET Framework, as shown in Figure 1.
Figure 1. Run the Microsoft SQL Server 2008 R2 Setup.
2. Select New Installation or Add Features to an Existing Installation, as shown in Figure 2.
Figure 2. Select New Installation.
3. After the installer verifies that your server meets the requirements (see Figure 3), click OK.
Figure 3. The Installer verifies the prerequisites.
4. Accept the licensing terms, as shown in Figure 4, and click Next.
Click the check box if you want to help Microsoft further develop SQL
by sending usage data. In most production environments, this option is
not selected.
Figure 4. License terms.
5. Select the SQL features. The only features you need are the Database Engine Services and the Management Tools, as shown in Figure 5. After selecting the features, click Next.
Figure 5. Select Database Engine Services and Management Tools.
It is quite common to run into a
deployment in which the SQL Server instance is already up and running,
but the management tool has not been installed. Because the 2008
Management Tools are no longer available as a separate download, it is
possible to use SQL Express Management Studio 2005. An even better
solution is to have a ThinApp version of SQL Express Management Studio
2005 as part of your toolkit.
6. Set the SQL named instance (see Figure 6). Although using the default instance is fine, it is better if you provide a specific instance name and then click Next.
Figure 6. Name the SQL Instance.
7. Specify the SQL administrators (see Figure 7). After adding the appropriate SQL administrators, select Data Directories. Select Mixed Mode
(SQL Server authentication and Windows authentication) if you intend to
run all databases from one location. Although the vCenter database uses
Windows authentication, the Event Database does not.
Figure 7. Select Mixed Mode.
8. Update the default locations for the databases and logs, as shown in Figure 8.
Even if you are running the Windows Database Server as a VM, it is a
good idea to separate the database and the logs on separate partitions.
Separating the database and logs on separate partitions ensures that
you can still manage the SQL Server in the event you run out of
capacity on the volumes. If the SQL Server is virtual, you can separate
different Virtual Machine Disks (VMDKs) on different storage tiers to
more finely control IO.
Figure 8. Separate the database logs from the OS partition.