Step-by-Step SharePoint Disaster Recovery

Install the original OS version on your new server, and don’t be tempted to upgrade the OS at this point. It’s technically possible but adds another level of complexity to your recovery effort. Keep all other settings (e.g., server name, IP address) the same, if possible.

Add the MOSS.Admin account to the local administrators group on the new server. Make sure this account also has logon permissions to your SQL Server system and is a member of the Sysadmin server role.

Remove the previous computer account from AD, join the new server to the domain, and reboot.

Install IIS.

Install the same .NET Framework version that you had on the previous server. At a minimum, this would be version 3.0. If you don’t know, install the latest version, which is version 3.5 SP1, as of this writing.

Install MOSS. Start by logging on as your administrative account (MOSS.Admin). Run the MOSS setup program from your installation media. As with all SharePoint installations, the recommendation is to use the Advanced and then Complete options. These options give you the most flexibility, letting you have this SharePoint server run any roles needed (e.g., Web Application, search) You can install a slipstreamed version provided it isn’t newer than the build you had previously.

Before creating the farm, install all updates to match your previous build version. When doing this, make sure you apply the individual WSS update first and the MOSS update second. For example, to get to build 6318, install in this sequence: WSS SP1, MOSS SP1, WSS Infrastructure Update, MOSS Infrastructure Update. After each update, the SharePoint Products and Technologies Configuration Wizard will start. When it does, simply cancel it.

Once you've applied the updates, you’re ready to create the server farm. Start by launching the SharePoint Products and Technologies Configuration Wizard, which you can access in the Microsoft Office Server group on the Start menu. When prompted, create a new server farm. Next, specify the name of your SQL Server system and the name of your SharePoint config database. If you're using the same database name that you used in your old farm, you must delete the old database first. For the username, enter the name of your server farm account (MOSS.Farm). Click Next, then enter the desired port for the Central Administration Web application and set the proper form of authentication (i.e., NTLM or Kerberos). When you see the summary screen, review it and click Next to create the farm.

Start the Search service. After the farm is created, the Central Administration web site should automatically appear. If the system prompts you to log on, use your MOSS.Admin credentials. To start the search service, first go to the Operations tab and choose Services on server. In the list of services, click Start next to Office SharePoint Server Search. In the resulting dialog box, select both check boxes at the top to make the server an index and query server. For the Farm Search Service Account, enter the appropriate account (e.g. MOSS.Search).

Start any additional services that are in use, such as Excel Calculation Services. For MOSS, you might not need the WSS Search service because it’s used only to index the Help collection.

Re-create each of your Web applications. You’ll need to do this for your SSP Web application, your MySites Web application (if applicable), and each additional Web application that your farm was using. For each one, follow these steps: Go to the Application Management tab, choose Create or extend Web application, then select Create a new Web application. Enter the port and host header. In most cases, you can keep the path as the default. If this web application was using SSL, specify that here. Enter the application pool credentials. In most cases, each web application should use a separate application pool with unique credentials. For example, for the SSP web application, you would use a logon such as MOSS.SSPAppPool. Finally, and most important, enter the name of your SQL Server system and one of the content databases used for this web application. SharePoint will recreate this website in IIS, register it in the new config database, and link it to your existing content database. If you previously extended any of your Web applications (e.g., configured an intranet for extranet access), you should reapply this now.

Associate remaining content databases with your web applications. This step is necessary only if you have multiple content databases for your web applications. Go to the Application Management tab, access Content databases, and select Add a content database. Ensure that you've selected the correct web application at the top, then specify each additional database name.

Restore your SSP. In navigation menu on the left inside Central Administration, click Shared Services Administration, then Restore SSP. For SSP Name, enter in the name of your SSP such as SharedServices1. For Web application, select the Web application that you just created for your SSP. If you were using a separate Web application for My Sites, clear the use existing location check box. If you get warnings here, just acknowledge them and then select the Web application used for My Sites. Next, enter in the SSP Service Credentials (e.g. MOSS.SSPService). Enter in the name of the SSP Database and then the name of the Search Database. Finally, set the desired folder for the index file location. This should be on a drive letter that has plenty of space, so the C: default is not usually a good choice.

Reset IIS. The easiest way to do so is to click Start, Run, and type iisreset.

Reinstall any third-party applications or SharePoint Solutions. These can include custom IFilters (e.g., to index PDF files), custom web parts, and so on. For more information about SharePoint Solutions, see the "Solutions Overview" at msdn.microsoft.com/en-us/library/aa543214.aspx.

Apply any additional configurations. This is the most problematic area because SharePoint changes might occur in a number of ways. Here are some common areas where you might need to make modifications: alternate access mappings (AAM), web.config changes to your web applications, code deployed to bin folders or global assembly cache, IIS settings (e.g., reloading and binding your SSL certificate), changes to 12 Root (e.g., Features or Site Definitions), web application policy settings, and incoming/outgoing email—in general, anything on the Operations tab in Central Administration.

Issue a full crawl of all your content sources, which will recreate SharePoint’s search index. Because your index files were lost on the old server, you must re-crawl. Within your newly restored SSP, click Search settings, then Content sources and crawl schedules. For each content source, select Start Full Crawl from the context menu. Depending on the amount of content, the full crawl can take from minutes to days to complete.

Last, but definitely not least, fully test your SharePoint websites to validate your work. Errors could range from minor web-part problems on pages to full sites not displaying at all. The cause of errors is most likely configuration settings or missing files.