How to Implement Microsoft Forefront Server for SharePoint

Introduction

Microsoft Forefront Server Security for SharePoint Services is a tool that will help network administrators prevent vulnerabilities that can occur within SharePoint workspaces. SharePoint workspaces are areas on the network where users can create, edit, and save fi les and folders. If these storage locations on the network are used in a malicious manner, an enterprise can be vulnerable.

SharePoint Services, replacing the less robust and discontinued SharePoint Team Services, is a relatively recent addition to Microsoft’s line of products. SharePoint Services has become increasingly popular among companies where employees need to collaborate on documents and spreadsheets. The explosion in popularity of Share Point Services means that additional security mechanisms need to be in place in order to prevent the network from becoming vulnerable.

The Microsoft Forefront Server Security allows network administrators to centrally manage the security of the SharePoint servers. Administrators using Forefront Server Security can conduct filtering, scanning, and job scheduling of SharePoint repositories from a central management console. Reports can give the network engineer using Forefront Server Security Administrator an indication of how end users are utilizing the SharePoint workspaces. If end users are improperly utilizing SharePoint Services, additional filters can be added. Using Forefront Server Security can help network administrators deal with vulnerabilities related to SharePoint Services.

Implementing Microsoft Forefront Server for SharePoint

Microsoft’s SharePoint server provides a collaboration environment that allows people to share documents and contacts, and it provides a single place for project management. While antivirus software on the server can scan fi les for viruses, Forefront Security for SharePoint allows for a higher level of integration, including real-time scanning and the ability to use up to five scanning engines at once for maximum protection. Implementation of Forefront Security for SharePoint can be broken into two components: installation and configuration. The installation of Forefront must be planned ahead of time to ensure all of the requirements are met. If they are not, both hardware and software upgrades may be required. A thorough implementation plan will allow you to determine if upgrades are needed. Once installed, you must configure Forefront properly in order to provide the security and protection planned for during the design phase. The ability to customize Forefront to fit different corporate models is a key strength that allows every installation to be optimized to fi t goals decided during the design phase.

 

Install and Configure Forefront Security for SharePoint

Microsoft has made the installation of Forefront Security for SharePoint quick and straightforward, allowing you to begin configuration as quickly as possible. Once you have the installation media, it is only a matter of minutes to install Forefront. While the installation itself is straight forward, don’t be fooled into thinking you don’t need to plan. The decision to do a local installation or remote installation will require the installer to have account information readily available with the proper access to the target server.

ForeFront Security for SharePoint Requirements

Before we start the installation, let’s take a look at the minimum server requirements to install Forefront Security for SharePoint. It is also important to make sure that the software requirements for Forefront security have been met. If they have not, you will be notified upon installation with a dialog box and the installation will stop.

■ Processor: Dual-processor computer rated at 2.5 GHz or higher

■ Operating System: Microsoft Windows Server (Standard, Enterprise, Datacenter, or Web Edition) with Service Pack 1

■ Hard Disk: 550MB of available disk space

■ SharePoint Requirement: Microsoft Office SharePoint Server 2007 or Microsoft Windows SharePoint Services, version 3

■ Microsoft Windows Workflow Foundation Runtime Components

■ Microsoft .NET Framework

■ Internet Information Services 6 in worker process isolation mode

■ NTFS fi le system

■ MAPI client such as Microsoft Outlook

Installation

Forefront Security for SharePoint has the option to install on the local server or on a remote server. To initiate either installation, you will need to log on to the server with an account that has administrative rights. For an installation on a remote server, the local account you use to log in needs to have administrative rights on the remote server. This is usually accomplished by using a domain account that is the administrators group of both computers. Because the installation registers services on the target server, it requires administrative access.

A great new feature of Forefront for SharePoint is the ability to use Hot Upgrade technology. This allows installations of Windows SharePoint Services without interrupting existing SharePoint service because a restart of the Windows SharePoint Services is not needed.

Forefront installs two main components that service the requests from the Forefront administrator and control all of the back-end functionality. The FSCController is installed as a service and coordinates all scanning activities within Forefront Security for SharePoint Server. The FSSPController is also an installed service, which communicates between Forefront and the SharePoint SQL server database.

1. To begin installation, insert the Forefront Security for SharePoint CD

or download the installation fi le from the Microsoft Download Center.

2. At the initial Welcome screen, select Next.

3. At the License Agreement screen, read the agreement and if you accept the terms, click Yes to continue.

4. At the Customer Information screen, enter the User Name and Company Name for the installation and click Next. Both are needed for the Next button to be active.

5. At the Installation Location screen, you will select the type of installation you wish to perform, Local or Remote, and then click Next.

6. This step is only for Remote Installations. If you are completing a local install, go to step 7. At the Remote Server Information screen, enter the target Server Name that you want to install Forefront Security for SharePoint on and the Share Directory. The default Share Directory is C$.

7. At the Installation Type screen, you can select Client—Admin Console Only or Full Installation. To install the Forefront Security for SharePoint application on the server, you will need to select Full Installation. The Client—Admin Console Only installation type only installs the administrator console to manage the server remotely.

8. At the Engines screen, you will see eight antivirus scan engines that Forefront Security can use to protect the server. Microsoft Antimalware Engine is selected by default and cannot be changed, allowing for you to select between the remaining seven scan engines. A maximum of five engines can be used, so you will be able to select four of the seven available to you. Just remember that each antivirus engine you select will require more memory to be dedicated to Forefront. If you have a server without the minimum amount of memory, you may want to select fewer antivirus engines. The installation automatically selects

four engines randomly which you can keep or change. Once you have determined which antivirus engines you will enable, click Next. You can find out more about the scan engines by going to the following the Web sites:

1. AhnLab Antivirus Scan Engine http://global.ahnlab.com

2. CA Vet http://www.ca.com

3. Authentium Command Antivirus http://www.authentium.com/command

4. Kapersky Antivirus Technology http://www.kaspersky.com

5. Norman Virus Control http://www.norman.com

6. Sophos Virus Detection http://www.sophos.com

7. VirusBuster Antivirus http://www.virusbuster.hu

9. At the Engine Updates Required screen, click Next. Forefront Security for SharePoint Server will automatically search and update the virus definitions hourly starting five minutes after the service is started. This is necessary to ensure the antivirus engines are up to date, protecting the server from the latest threats.

10. At the Choose Destination Location screen, select the destination folder for the installation. The default installation folder is C:Program FilesMicrosoft Forefront SecuritySharePoint, which should be suitable for most installations. If you decide to change the installation folder path, remember that Forefront

Security for SharePoint does not support an install path length over 170 characters. Once you have entered the new location for the installation or accepted the default, click Next.

11. At the Select Program Folder screen, click Next.

12. At the SharePoint Database Account Information screen, you will need to enter the account used for SharePoint database access. This account needs to be a member of the SharePoint server’s local administrators group as well as the database server’s local administrators group if the database was installed on a separate server. The format for entering the username is DomainUserAccount or MachinenameUserAccount.

13. At the Start Copying Files screen, you should review your settings to ensure that everything is correct prior to the installation. If you want to change a setting, use the Back button to go back to that screen and enter the new information. If you are ready to continue with the installation, click Next.

14. Forefront Security for SharePoint is now going to install on your SharePoint server. This process can take a few minutes, during which time you will see a

few command screens pop up as part of the installation.

15. Once installed, you will have the option to view the README fi le and click Finish. The installation is complete and you can now move on to configuring Forefront.

Five Steps to Rebuild Exchange client access server

Most of the documentation  backing up Exchange Server 2007 and Exchange 2010 states that it isn’t necessary to back up your client access server (CAS). This makes sense because all of a client access server’s configuration information is stored in Active Directory. That said, you should still know how to rebuild a failed server.

If your CAS fails due to an irreparable hardware problem; follow these steps to repair it:

Reset the client access server’s computer account within the Active Directory Users and Computers console. Do not delete the account.

Install Windows on the new server and then install the same OS version as the failed server.

Rename the server to match the name the CAS used and join the server to your domain.

Depending on the version of Exchange Server and service pack you were running, insert the corresponding installation media into the server and run the following command:

Setup.com /M:RecoverServer

After the command runs, Setup will install the Exchange binaries and use the information stored in Active Directory to rebuild your CAS.

Note: This technique can also be used to rebuild any other Exchange Server roles, except for the edge transport server.

These steps work well to rebuild a failed client access server; however, there is a major caveat. This method only works if the server is running a standard configuration, which is unlikely since many organizations personalize their Outlook Web Access interface.

Using these steps will rebuild the CAS to a functional state, but any OWA customizations will be lost. This happens because Setup copies the Exchange binaries from the installation media, not your customized files.

Rebuilding a CAS and recovering OWA customizations
You have two options for recovering OWA customizations after rebuilding your client access server:

Perform a full server backup, then restore the entire server.

Make a backup of your customizations, then rebuild your CAS using the five step outline above. After that, you can restore your OWA customizations from backup.

In my environment, I only back up OWA customizations. In the event of a failure, my infrastructure is configured such that Exchange Setup rebuilds the CAS and then I manually restore customizations.

Although configuration information stored in Active Directory may change slightly, binaries on the server itself probably won’t change unless you install a patch or perform additional customizations.

Considering the static nature of a CAS, it’s tempting to make a full server backup and then store your backup in a fireproof vault. The only problem is that a full backup will quickly become outdated.

Windows periodically resets the password associated with Active Directory accounts, which gives your backup a limited shelf life. Depending on the version of Windows your CAS is running, the backup may only be relevant for 60 days. This happens because the password breaks synchronization with the password stored in the backup.

You can also reset the computer account password to use your backup, but it’s easier to back up only customizations. That way, you don’t have to worry about your backup becoming outdated — as long as you make a new backup with each additional customization.

How to create a flash drive version of Windows

My laptop’s DVD-ROM drive recently gave up. Discs wouldn’t read or even spin up from it, and its laser kept making a wheen-wheen noise whenever the computer booted. I attached an internal DVD-ROM drive by way of a USB-to-SATA bridge. That worked for a while – but then it too quit.

This was aggravating because, after several software installs and changes to the system, I needed to mop down the computer and reinstall Windows 7. Without an optical drive, this would be a chore, so instead I created a bootable flash drive version of the Windows 7 installation media.

The process isn’t as tough as it may seem. To get started, you need the following items:

• A flash drive of at least 4 GB.
• A running installation of Windows 7 to which you have administrator access.
• A copy of the Windows 7 installation media.
• If your copy of Windows 7’s install media is in the form of an .ISO file, you’ll need a copy of the free, open source 7-ZIP archive utility.

That’s it –now just follow these steps to create the flash drive:

1. Go to an available Windows 7 system.
2. Mount the flash drive, and make sure Windows recognizes it as a device. If this is the first time you’ve used the drive in that particular installation of Windows, it may take a moment to be recognized.
3. Open an elevated command prompt, and type diskpart to launch the DISKPART utility. This is the command-line, disk-partitioning tool created to replace fdisk from previous versions of Windows (and DOS before it).
4. In diskpart, type list disk to obtain a numbered list of all the currently mounted disks in the system. The flash drive you plugged in will not have any special identifiers other than its size, so pay close attention. (It typically registers as the last drive in the list, but that’s not a universal rule.)
5. Type select disk # — with # as the number of the flash drive. For example, if your flash drive showed up as Disk 4, you’d type select Disk 4.
6. Type clean to remove any existing partition information from the disk. This is important because there may be partition information left over that might prevent the drive from working properly as a boot drive.
7. Type create partition primary to create a new, primary partition on the disk.
8. Type active to mark the current partition as bootable. This is extremely important. If the partition isn’t marked as bootable, no computer will recognize the drive as a bootable medium in the first place.
9. Type exit to leave diskpart.
10. Unmount the drive (right-click in Explorer and select “Eject”), unplug the drive, and then plug it back in. This step is optional, but it seems to help clear the system of any lingering incorrect information about the drive.
11. Right-click on the drive icon in Explorer and select Format. Use the following options: NTFS for the file system and 4096 bytes as the allocation unit size. Check the “Quick Format” option. If you’re not too sure about the quality of the drive, you can uncheck “Quick Format,” but the format process will take much longer. A volume label is not required, but it can be useful. (I just use “Win7.”)
12. Click Start to format the drive.
13. When the format operation is finished, insert your Windows 7 installation media. If you’re using an .ISO, use 7-ZIP to open the .ISO as if it were an archive, and copy the contents of the .ISO to a folder.
14. Copy the entire contents of the installation disk — exactly as-is — to the flash drive. This may take several minutes; refresh your coffee in the meantime.

15.       When the copy operation is finished, unmount the drive.

The resulting flash drive should boot on any system. If it doesn’t work, the drive you’re using may not support booting, or it has been configured to mount as a different kind of storage device than one recognized as a boot device.

Once booted, the installation process should proceed normally. Just make sure not to use the flash drive itself as a target for the install.(From what I’ve seen, Windows should prevent you from doing this anyway.) One convenient byproduct of having your Windows install media on a flash drive is that you can add other programs to the drive — like the Malicious Software Removal Tool — which you can run from the Windows PE (rescue environment). Plus, unlike a custom DVD-R, you can add or remove software from the drive without having to reburn it.

It may also be possible to use this technique on a boot or install processes to stall.

Also note that the exact method by which you enable USB booting varies widely between systems. With some of them, the boot device can be selected by pressing F12 at startup; with others, it needs to be set manually in BIOS beforehand.

Slipstream Installations in SQL Server 2008

With the release of SQL Server 2008 SP1, Microsoft provides the capability to create Slipstream installations of SQL Server 2008. Slipstreaming is a method of integrating a SQL Server 2008 update with the original installation media so that the original media and update are installed at the same time. This capability can be a huge timesaver over having to manually run a service pack and possible cumulative update installations after running a full SQL Server install, especially if you have to repeat the installation in multiple environments. Slipstreaming is supported in the following scenarios:

• Installing the original media and a service pack
• Installing the original media, a service pack, and a cumulative update to the service pack

Note Slipstreaming a cumulative update for SQL Server 2008 with the original media but without a service pack is not supported because slipstreaming wasn’t supported until SQL Server 2008 SP1 was released. Also, a Slipstream installation cannot be performed to update a SQL Server 2008 instance to SQL Server 2008 R2.

If you are doing a single install of SQL Server 2008 and at the same time want to apply SP1 and possibly a cumulative update as well, you can run the Slipstream installation by performing the following steps:

1.

If they are not installed already on the target machine, install the required prerequisites for the SQL Server 2008 Installer (.NET Framework 3.5 SP1 and Windows Installer 4.5). You can install them manually from the SQL Server install disk (the installers are located in the Drive_Letter:platformredistWindows Installer folder). Alternatively, after you extract the service pack files, run the sqlsupport.msi file from within the folder where the service pack files have been extracted. For example, if you extracted the Service pack to the C:sql2k8xp1 folder on an X86 platform, this file would be found in the C:SQL2K8SP1x86setup1033 folder.

Note To confirm whether the setup support files are installed, search for the Microsoft SQL Server 2008 Setup Support Files entry in the Programs and Features Control Panel (or the Add or Remove Programs Control Panel in operating systems prior to Windows Vista or Windows Server 2008).

Note On the IA-64 platform, the .NET Framework 3.5 is not supported. The .NET Framework 2.0 SP2 is required instead. The .NET Framework 2.0 SP2 is located in the Drive_Letter:ia64redist2.0NetFx20SP2_ia64.exe folder on the source media.

2. If not done already, download the Service Pack (PCU) package that matches your system architecture and, if desired, the cumulative update (CU) package you want to install. 3.

For each package you want to include in the Slipstream installation, extract the contents to a folder on the local drive by running a command similar to the following at the command prompt from within the folder where you downloaded the package(s):

   Name_of_the_PCU_or_CU_package.exe /x:Root_of_path_to_extract_to<PCU | CU>

4.

Now things get a bit tricky. Because Slipstream support is introduced with SP1, the setup.exe program that shipped with the original SQL Server 2008 installation media doesn’t support the /PCUSource or /CUSource options that allow you to specify the locations of the service pack and cumulative updates to be slipstreamed. Instead, you need to run the SQL Server 2008 Setup program for Service Pack 1 and specify the action as INSTALL, and the file paths for the original media, as well as service pack and cumulative update files. These are specified using the /ACTION, /MEDIASource, /PCUSource, and /CUSourceD: drive with SP1 extracted to the C:SQLServer2008SP1 folder: parameters. The following example shows how to run a slipstream install of SQL Server 2008 from the install CD in the

C:SQLServer2008SP1>setup.exe /PCUSource=C:SQLServer2008SP1 /ACTION=INSTALL

 /MEDIASOURCE=D:

This command runs the SQL Server installation in the normal GUI mode, requiring you to specify and confirm all settings. If you want, you can also choose to run the install in a limited interface or automated mode, as described previously in this chapter in the section describing how to use a configuration file. However, the first time you run a Slipstream installation, you should at least use an interface that allows you to view the Ready to Install page before running the installation so that you can verify whether the desired Slipstream installation is being performed. If the setup utility is running a Slipstream installation, it is indicated in the Action field, as shown in Figure 1.

Figure 1. Verifying a Slipstream installation on the Ready to Install page.

Sysprep in Windows Vista and Windows Server 2008

I thought I’d document how to setup the new Sysprep process equivalent on Windows 2008 since the old setupmgr tool for making sysprep.inf’s doesn’t exist anymore (and neither does the sysprep.inf file itself).

The first step is acquiring the Windows Automated Installation Kit (WAIK) from somewhere. You can get this package in ISO file format from Microsoft’s website at http://www.microsoft.com/downloads/details.aspx?FamilyID=94bb6e34-d890-4932-81a5-5b50c657de08&DisplayLang=en. The download is about an 800MB install on a Windows Server 2003 SP2 x86 machine.

The tool of choice for building your Sysprep configuration is the Windows System Image Manager (WSIM). When you start it you’ll get a blank screen like this:

The first step is to catalog the image file. You can do this from Tools>Create Catalog, selecting your install.wim and then what image(s) to catalog. I’m setting up Windows Server 2008 Enterprise so I selected the appropriate option. The final three choices are the server core variants:

Note: You’ll also need to copy the install.wim from your installation media DVD sources folder to the hard drive as the tool won’t work with it if it doesn’t have write access to the WIM file.

All of the settings you will want to setup in your unattend.xml file are in the tree under Windows Image. The documentation for all the settings can be found at http://technet2.microsoft.com/WindowsVista/en/library/69eee519-55a6-440d-ab94-56330ef57e291033.mspx. This link shows a mapping table between the sysprep.inf file and the new unattend.xml format.

All of the various settings can be applied during different passes of the setup process which sysprep will trigger. You can read about these passes here. I built a simple unattend file just for sysprep’ing my base image which includes settings in the generalize, specialize, and oobeSystem passes. All of the settings I chose are outlined below.

My answer file tree:

Disabling the initial configuration dialog:

Disabling auto-starting the server manager application:

Setting my product key, timezone settings, and my name:

Configuring the screen resolution and color depth – 1280×960 is what works in VMWare full screen mode with the tabs across the top:

Configuring setup not to show me the EULA again:

Configuring setup to install a default local administrator account password:

One of the things I discovered doing this is that unlike Sysprep from Windows 2000 – 2003, the unattend.xml file isn’t deleted at the conclusion of the Sysprep process. When down-level Sysprep completes, it deletes the c:sysprep folder. In order to replicate this functionality, you can put a command in to delete the unattend.xml file in the SetupComplete.cmd batch file (which must be located in c:windowssetupscripts) which gets called at the end of Sysprep. Reference this link for more info.

I put a simple one line command in my SetupComplete.cmd file:

del /Q /F c:windowssystem32sysprepunattend.xml

In order to run Sysprep you’ll need to use a new command. The old Sysprep user interface that was there in Windows 2000 – Windows Server 2003 doesn’t really exist anymore. All of the Sysprep command line switches are documented at http://technet2.microsoft.com/WindowsVista/en/library/72cc64e2-a0f3-4516-84fc-097577127fc91033.mspx.

sysprep /generalize /oobe /shutdown /unattend:sysprep.xml

So far this process is working fine for me with Windows Server 2008 Enterprise x86 full installs. I haven’t tried it with server core yet, but if it’s different I’ll post something about that.

Sysprep in Windows Server 2008 R2 and Windows 7

Note: This post discusses Sysprep as it pertains to Windows 7 and Windows Server 2008 R2. If you’re working with a different version of Windows, check out these posts:

• Windows Vista and Windows Server 2008

The first step is acquiring the Windows Automated Installation Kit (WAIK) and installing it on a machine. It will run fine on a Windows Vista or Windows Server 2008 machine. You can get it from Microsoft’s website at http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=696dd665-9f76-4177-a811-39c26d3b3b34.

The tool of choice is the Windows System Image Manager (WSIM). When you start it you’ll get a blank screen like this:

The first step is to open the image file for the Windows SKU you want to build a sysprep file for by going to File>Select Windows Image:

Note: You may need to first create a catalog file before completing the preceding step. In order to do this, you’ll first need to copy the install.wim from your installation media DVD sources folder to the hard drive as the tool won’t work with it if it doesn’t have write access to the WIM file. You can then go to Tools>Create Catalog and create the catalog file.

All of the settings you will want to setup in your unattend.xml file are in the tree under Windows Image. The documentation for all the settings can be found in the Unattended Windows Setup Reference CHM file which ships with the WAIK. This link http://technet.microsoft.com/en-us/library/cc749272(WS.10).aspx shows a mapping table between the sysprep.inf file and the new unattend.xml format. This link is for Windows Vista but it still applies.

All of the various settings can be applied during different passes of the setup process which sysprep will trigger. You can read about these passes here. I built a simple unattend file just for sysprep’ing my base image which includes settings in the generalize, specialize, and oobeSystem passes. All of the settings I chose are outlined below.

My answer file tree:

Disabling the initial configuration dialog:

Disabling Server Manager from loading at first run:

Setting the Internet Explorer homepage to “about:blank”, turning off the IE8 Accelerators, and disabling the first run wizard:

Setting Google as my default Search Provider in Internet Explorer:

Note: To do this, you should right click on SearchScopes and Insert New Scope.

There are two versions of Internet Explorer on a 64-bit machine – the 64-bit IE and the 32-bit one. You’ll need to set the settings for them independently. Duplicate the above IE configuration in the wow64_Microsoft-Windows-IE-InternetExplorer_neutral component:

Setting my product key, timezone settings, and my name:

Configuring localization settings – if you want something other than US English, look under Input Locales in the index of the Unattended Windows Setup Reference CHM file referenced earlier:

Configuring the screen resolution and color depth – 1280×960 is what works for me in VMWare full screen mode with the tabs across the top:

Configuring setup not to show me the EULA again:

Configuring setup to install a default local administrator account password:

One of the things that’s unlike Sysprep from Windows 2000 – Windows Server 2003 is that the unattend.xml file isn’t deleted at the conclusion of the Sysprep process. The down level Sysprep deletes the c:sysprep folder when it finishes. In order to replicate this functionality, you can put a command in to delete the unattend.xml file in the SetupComplete.cmd batch file (which must be located in c:windowssetupscripts) which gets called at the end of Sysprep.

I put a simple one line command in my SetupComplete.cmd file:

del /Q /F c:windowssystem32sysprepunattend.xml

In order to run Sysprep you’ll need a new command. The old Sysprep UI that was there in Windows 2000 – 2003 doesn’t really exist anymore. All of the Sysprep command line switches are documented at http://technet.microsoft.com/en-us/library/dd744330(WS.10).aspx.

sysprep /generalize /oobe /shutdown /unattend:unattend.xml

Installing SQL Server 2008 on a Windows Server 2008 Cluster-Part4

To continue this series on Installing SQL Server 2008 on a Windows Server 2008 Cluster, we will look at adding a node in a SQL Server 2008 failover cluster.

• Part 1 we completed the installation of the Application Server role in both of the servers that we will be using as part of our cluster.
• Part 2 walked you through the installation of the Failover Cluster Feature, validating the servers that will be a part of the cluster, and creating the cluster.
• Part 3 completed with a working SQL Server 2008 failover cluster running on a single node.
• In this tip, we will proceed to add a node in a SQL Server 2008 failover cluster and apply the latest cumulative updates.

Adding a node on a SQL Server 2008 Failover Cluster

Now that you have a working failover cluster, we will make it highly available by adding nodes. The number of nodes you can add in a failover cluster depends on the editions of SQL Server that you will use. A Standard Edition of SQL Server 2008 can support up to two (2) nodes in a failover cluster while the Enterprise Edition supports up to sixteen (16) nodes, which is practically the limit for the Enterprise Edition for Windows Server 2008. As most of the steps in this process are similar to the one when you were installing the failover cluster, I’ve skipped most of the screenshots.

To add a node on a SQL Server 2008 failover cluster:

1. Run setup.exe from the installation media to launch SQL Server Installation Center
2. Click on the Installation link on the left-hand side. Click the Add node to a SQL Server failover cluster link. This will run the SQL Server 2008 Setup wizard.
   There are a couple of glitches when you get to this point. One of them is a popup error with an error message “failed to retrieve data for this request” while in this step. I’ve seen a Microsoft Connect item on this but refers to CTP6 so I was thinking it has already been resolved. After a few searches and questions asked, SQL Server MVP Geoff Hiten advised that prior to adding another node in the cluster, any cumulative update should be pre-applied to the node before the main installation as the cluster install of the RTM version has some bugs. This creates a patched install script for the RTM installer to use. The fix started with cumulative update 1 so, technically, you can apply any cumulative update. Sounds weird, but it works. You still have to apply the patch after the installation.
3. In the Setup Support Rules dialog box, validate that the checks return successful results and click OK.
4. In the Product Key dialog box, enter the product key that came with your installation media and click Next.
   Again, a few glitches on this step. This might seem unusual as you are only being asked about the Product Key. There is also a Microsoft Connect item for this which basically asks you to run the setup.exe in command prompt. There is a popup error with an error message “The current SKU is invalid” while in this step. This usually happens when you use a media with a supplied product key, like the one that comes with an MSDN subscription. What worked for me was to copy the installation media on a local disk, locate the file DefaultSetup.ini file from the installation files and delete it or move it to different location. If you opt to delete the file, make sure you note down the product key written on this file as you will need to manually key this in during the installation process. This forum post will give you quite a few options to solve this issue
5. In the License Terms dialog box, click the I accept the license terms check box and click Next.
6. In the Setup Support Rules dialog box, click Install. Validate that the checks return successful results. Again, make sure to fix any errors returned by this check before proceeding with the installation.
7. In the Cluster Node Configuration dialog box, validate that the information for the existing SQL Server 2008 cluster is correct.
8. In the Service Accounts dialog box, verify that the information is the same as what you have used to configure the first node.
9. In the Error and Usage Reporting dialog box, click Next
10. In the Add Node Rules dialog box, verify that all checks are successful and click Next
11. In the Ready to Add Node dialog box, verify that all configurations are correct and click Install
12. In the Complete dialog box, click Close. This concludes adding a node to a SQL Server 2008 Failover Cluster

You can validate your cluster installation by expanding the Services and Applications node and check the cluster name of your SQL Server instance.  You can now see an option to move the service to another node, in this case, the node you’ve just added in your failover cluster

Applying patches on a SQL Server 2008 cluster

Part of the tasks of a DBA is to apply patches on the database engine and a SQL Server 2008 failover cluster is no exception. In fact, it is not as straight-forward as applying patches and service packs on a stand-alone server. It is important to note that when applying patches or service packs to a SQL Server failover cluster, you should apply them first on the passive node. After completing the installation on the passive node, failover the SQL Server 2008 cluster resource to this node making it the active node. Once the SQL Server service and all other dependencies are up, you can, then, apply the patches on the new passive node. The latest available patch for SQL Server 2008 is cumulative update 4 and is available for request from Microsoft.  For more information, check out this Microsoft KB article. You will have to request for the patch from Microsoft as it is not available from the Microsoft Download Center. The screenshots below show cumulative update 3 (version 10.0.1600.22) but the process is basically the same. Also, note that even though you may have already applied the cumulative update due to the bug mentioned above for adding a node in a failover cluster, you still have to apply the patch on both nodes

To apply patches on a SQL Server 2008 failover cluster node:

1. Run SQLServer2008-KB960484-x86.exe (this would depend on the cumulative update that you want to apply) from the hotfix package you have requested from Microsoft
2. In the Welcome dialog box, validate that the checks return successful results.
3. In the License Terms dialog box, click the I accept the license terms check box and click Next
4. In the Select Features dialog box, validate the SQL Server 2008 components by clicking on the check box.  The Upgrade Status field will tell you whether or not the patch has already been applied. Click Next
5. In the Ready to Update dialog box, verify that all configurations are correct and click Patch
6. In the Update Progress dialog box, validate that the installation was successful.
7. In the Complete dialog box, click Close. This concludes patching the passive node of a SQL Server 2008 Failover Cluster

After successfully installing the patch on the passive node, move the SQL Server 2008 cluster resource to this node so it will become the new active node. Make sure that all the SQL Server 2008 cluster dependencies are online prior to applying the patch on the other node.  Repeat the process outlined above to the new passive node. A more comprehensive approach for applying a SQL Server 2008 patch to a failover cluster instance is defined in this Microsoft KB article

Congratulations! You now have a working two-node SQL Server 2008 failover cluster running on Windows Server 2008.

Installing SQL Server 2008 on a Windows Server 2008 Cluster – Part3

To continue this series on Installing SQL Server 2008 on a Windows Server 2008 Cluster, we will look at installing SQL Server 2008 in a failover cluster. In Part 1, we have completed the installation of the Application Server role in both of the servers that we will be using as part of our cluster. Part 2 walked you through the installation of the Failover Cluster Feature, validating the servers that will be a part of the cluster, and creating the cluster. In this tip, we will proceed to install SQL Server 2008 in a clustered Windows Server 2008 environment.

Installing and Configuring MSDTC

The Microsoft Distributed Transaction Coordinator (MSDTC) is a transaction manager that permits client applications to include several different data sources in one transaction and which then coordinates committing the distributed transaction across all the servers that are enlisted in the transaction. A lot of people ask why we need to install MSDTC prior to installing SQL Server. If you are using distributed transactions or running SQL Server on a cluster, this is definitely a must. SQL Server uses the MSDTC service for distributed queries and two-phase commit transactions, as well as for some replication functionality.

Configuring MS DTC in Windows Server 2003 clusters as defined in this Microsoft KB article is not pretty straight-forward. Windows Server 2008 made it simpler by providing a more straightforward process with fewer steps and less configuration.

To install and configure MSDTC:

1. Open the Failover Cluster Management console on any of the cluster node.
2. Under the cluster name, right-click on Server and Applications and select Configure a Service or Application. This will run the High Availability Wizard
3. In the Service or Application dialog box, select Distributed Transaction Coordinator (DTC) and click Next.
4. In the Client Access Point dialog box, enter the name and IP address of the clustered MSDTC. This should be a different IP addresses and host name from the one that the Windows Server 2008 cluster is already using. Click Next.
5. In the Select Storage dialog box, select the disk subsystem that will be used by MSDTC. These disk subsystems have to be defined as available storage in your cluster. In the example below, I have used the disk volume F: and left the disk volume E: for SQL Server later in the installation process. Click Next
6. In the Confirmation dialog box, validate the configuration you have selected for MSDTC and click Next
7. In the Summary dialog box, click Close. This completes the installation of MSDTC on the cluster.

You can validate your installation of MSDTC by expanding the Services and Applications node and check the cluster name of MSDTC.  Make sure that all of the dependency resources are online

Installing SQL Server 2008 on a Windows Server 2008 cluster

You’ve gone this far, don’t stop now. Only after we have managed to prepare everything can we proceed to install SQL Server 2008 on this cluster. Since we’ve already installed .NET Framework 3.5 with Service Pack 1 and Windows Installer 4.5 from Part 1, we no longer have to worry about them as they both are prerequisites whether you are doing a single server or a cluster installation. There are two options to install SQL Server 2008 on a cluster. The first one is by using the Integrated failover cluster install with Add Node option and the second one is the Advanced/Enterprise installation option. The process outlined below will take into account the first option.

To install SQL Server 2008:

1. Run setup.exe from the installation media to launch SQL Server Installation Center. Click on the Installation link on the left-hand side
2. Click the New SQL Server failover cluster installation link. This will run the SQL Server 2008 Setup wizard
3. In the Setup Support Rules dialog box, validate that the checks return successful results and click Next.
4. In the Product Key dialog box, enter the product key that came with your installation media and click Next.
5. In the License Terms dialog box, click the I accept the license terms check box and click Next. You probably haven’t read one of these, but if you feel inclined go for it.
6. In the Setup Support Rules dialog box, click Install. Validate that the checks return successful results. If the checks returned a few warnings, make sure you fix them before proceeding with the installation. An example of this is the Network binding order. The public network cards should be first on both nodes. Also, you can disable NETBIOS and DNS registration on the network cards to avoid network overhead. Be sure to check your binding order as well.  For more details on the network binding order warning, see Microsoft KB 955963.For the Windows Firewall, make sure that you open the appropriate port number on which SQL Server will communicate. You can do this after the installation. Alternatively, you can disable Windows Firewall during the installation and enable it later with the proper configuration. Click Next to proceed.

   

7. In the Feature Selection dialog box, select only the components that you want installed. For the Shared feature directory, you can keep the default path if you have sufficient disk space on your C: drive or anywhere that is a local disk as this will be used by the SQL Server installation process later on. The directory for the clustered database engine will be different. Click Next.
8. In the Instance Configuration dialog box, enter the SQL Server Network Name. This is the name that will be available on the network for the clients. This will vary depending on your selection of whether it is a default or named instance. In this example, default instance is selected.A couple of things need highlighting in this section. By default, the instance name is used as the Instance ID. This is used to identify installation directories and registry keys for your instance of SQL Server and is helpful when you want to run multiple instances in a cluster. This is the case for default instances and named instances. For a default instance, the instance name and instance ID would be MSSQLSERVER. To use a non-default instance ID, you should select the Instance ID box and specify a value.

   The section on Detected SQL Server instances and features on this computer would make sense if there are other SQL Server instances running on your server.

   

9. In the Disk Space Requirements dialog box, check that you have enough space on your local disks to install the SQL Server 2008 binaries and click Next.
10. In the Cluster Resource Group dialog box, check the resources available on your Windows Server 2008 cluster. This will tell you that a new Resource Group will be created on your cluster for SQL Server. To specify the SQL Server cluster resource group name, you can either use the drop-down box to specify an existing group to use or type the name of a new group to create it. Click Next.
11. In the Cluster Disk Selection dialog box, select the available disk groups that are on the cluster for SQL Server 2008 to use. In this example, two clustered disk groups – APPS and APPS2 – have been selected to be used by SQL Server 2008. I will be using one disk resource for the system databases while the other one for the user databases. Click Next.
12. In the Cluster Network Configuration dialog box, enter the IP address and subnet mask that your SQL Server 2008 cluster will use. Deselect the checkbox under the DHCP column as you will be using static IP addresses. If you have not disabled your IPv6 adapters and protocols, it would be better to uncheck the row for IPv6
    
13. In the Cluster Security Policy dialog box, accept the default value of Use service SIDs (recommended). In Windows Server 2003, we specify domain groups for all SQL Server services but in Windows Server 2008, this is the recommended option. For more information on using service SIDs for SQL Server 2008, check out this MSDN article
14. In the Server Configuration dialog box, enter the credentials that you will use for your SQL Server service accounts in the Service Accounts tab. In the Collation tab, select the appropriate collation to be used by SQL Server. Note that the startup type is set to manual for all cluster-aware services and cannot be changed during the installation process. Click Next.
15. In the Database Engine Configuration dialog box, select the appropriate Authentication Mode. If you want to add the currently logged on user to be a part of the SQL Server administrators group, click the Add Current User button.

    On the Data Directories tab, enter the path where your system and user database files will be created. This will default to the first shared disk in the cluster so in case you want to change it to the other shared disks to be used by SQL Server 2008, modify accordingly. If you intend to use the new FILESTREAM feature, click the FILESTREAM tab and set the appropriate configurations. Click Next

    

16. In the Error and Usage Reporting dialog box, click Next.
17. In the Cluster Installation Rules dialog box, verify that all checks are successful and click Next.
18. In the Ready to Install dialog box, verify that all configurations are correct. Click Next.
19. In the Complete dialog box, click Close. This concludes the installation of a SQL Server 2008 Failover Cluster

At the completion of a successful installation and configuration of the node, you now have a fully functional failover cluster instance. To validate, open the Failover Cluster Management console, and click on SQL Server (MSSQLSERVER) under Services and Applications. Make sure that all dependencies are online

Although we do have a fully functioning SQL Server 2008 failover cluster, it does not have high-availability at this point in time because there is only one node in the failover cluster. We still have to add the second node to the SQL Server 2008 cluster. In the last part of this series, we will add the second node in the failover cluster and install the latest cumulative update