Worst case – loss of SharePoint environment without proper backups

In scenarios where proper backups were not done, restoring a SharePoint server is much more problematic. Because SharePoint does not run in a vacuum, proper planning must account for three components: SQL, IIS, and Active Directory.

SQL-specific issues will be covered later in this chapter. In regards to server restoration, remember that if a SQL alias was not used, SQL may not perform as expected when renamed. Although most connections to a SQL Server are socket or named pipe-based, a rename can cause some aberrant behavior if not properly planned. In addition to this issue, permissions at the instance and database level also merit inspection.

IIS maintains configuration in the Metabase. Its location and tools for management changed between IIS 6.0 (server 2003) and IIS 7.0 (server 2008). In the early versions of IIS, the web server's configuration was stored in an XML file.

Under the current versions of IIS, the configuration is saved in the application's host.config or web.config files. Previously, backup and restoration of this data was integrated into the IIS Manager utility. The command line tool appcmd is used for disaster protection of the configuration.

The AppCmd.exe file is located in the %systemroot%\system32\inetsrv\ directory. This is not the path so it will not start automatically; you need to use the full path to the executable when executing commands, that is, %systemroot%\system32\inetsrv\AppCmd.exe list sites or you can manually add the inetsrv directory to the path on your machine so that you can access the AppCmd.exe file directly from any location. Data in the Metabase is specific to the current web applications and settings and may be lost if simply moving a site to a different server.

Active Directory is another service that touches SharePoint in several ways. The primary concern is ensuring that the computer account for the SharePoint server has the correct memberships in Active Directory. The various service accounts and permission groups for SharePoint are also held in Active Directory. If the identity of the server was maintained, then Active Directory will not need to change when the server is restored. Otherwise, remapping the old identity to the new one may be necessary.

Disaster protection of a SharePoint server is a layered approach. The outer ring of software protection is the operating system. Protection and restoration of the operating system is the first and a critical step in restoring a SharePoint server. The most important goal in server restoration is maintaining the identity of the server, even in cases where both the software and hardware are destroyed. The second step is to identify the factor that shapes and, in many cases, dictates a restoration strategy. A proper DR plan will allow rapid restoration of the server, sometimes with several options available.