Bill Baer /bɛːr/

In recent months there has been a great deal of discussion and debate on disaster recovery and high availability with Microsoft SharePoint Products and Technologies and with the recent releases of both Microsoft SQL Server 2008 and Windows Server 2008 there are open opportunities to leverage components available natively to these technologies and compliment a SharePoint Products and Technologies disaster recovery design. One of the most significant challenges has been overcoming latency penalties applied through distance between the active and passive datacenters, particularly with Microsoft SQL Server Log Shipping since we’re dealing with SMB and a synchronous process.

The question of Microsoft SQL Server 2005 Database Mirroring (DBM) continues to be a topic of discussion in implementation with Microsoft SharePoint Products and Technologies, attached is a set of key notes and considerations to take into account when implementing DBM. Before implementing DBM with Microsoft SharePoint Products and Technologies, you must first understand that many applications are not natively aware of a Microsoft SQL Server 2005 Database Mirroring architecture in most cases.

This topic has frequented my Inbox over the past months, planning a My Site personal site deployment for 100,000+ users. In this post we’ll examine the issues and potential solutions. First it is important to understand that while a My Site personal site is a site collection in basic form, it’s instantiation via a browser request or managed code results in significantly greater overhead than a traditional collaboration-type site collection. The majority of overhead is presented through the numerous data building operations that occur both on the private and public pages associated with the template, private.

I’ve discussed on several occasions Microsoft SQL Server 2005 Database Mirroring with Microsoft SharePoint Products and Technologies as a method by which database mirroring can provide intra-datacenter high-availability; however, am frequently asked how Microsoft SQL Server 2005 Database Mirroring can provide protection from datacenter failure. While possible, you generally do not want to geographically distribute your principal and mirror instances due to potential problems with maintaining synchronicity and bandwidth/latency constraints instead maintaining and intra-datacenter session to provide local fault tolerance; however, you can implement Microsoft SQL Server 2005 Log Shipping in conjunction with Microsoft SQL Server 2005 Database Mirroring to provide a standby copy of your databases in the remote datacenter.

The SharePoint Capacity Planning Tool has been made available for download on TechNet. To learn more about the benefits and applications of the SharePoint Capacity Planning Tool see my beta release announcement at Announcing the Beta Release of the SharePoint Capacity Planning Tool or visit the resource links below: Resources Description and more Information Download

After several months of work and very little sleep in between we are pleased to announce general availability of the SharePoint Capacity Planning Tool (Beta). The SharePoint Capacity Planning Tool (Beta) provides a wealth of helpful information when planning a SharePoint Products and Technologies deployment; helping administrators, consultants, and IT Pros determine the potential required hardware investment(s) and topologies to support and meet requirements for availability and performance or even the affect of introducing additonal offices with their own unique bandwidth and latency constraints.

This will be the first of a series focusing on those areas of storage that are commonly overlooked when planning storage for Microsoft SharePoint Products and Technologies. In this post we’ll look at the native Recycle Bin in Microsoft Office SharePoint Server 2007 and Windows SharePoint Services 3.0 to understand its fundamental aspects and impacts on storage. The Recycle Bin enables end-users to easily recover content deleted within a site collection and is configured in two separate and unique stages referred to as the 1st and 2nd stage each with its own configuration properties.

Should I cluster or mirror? A few short months ago, the answer to that question would have been easy, now with the increasing popularity of database mirroring to achieve redundancy and geographic replication the answer is split…while each solution provides its own unique benefits, those benefits can be distributed across the answer to what are trying to achieve? Database mirroring replays transaction log records on a standby server and as a result can failover more rapidly in most cases than a traditional SQL cluster with no loss of committed data; however, as a relatively new solution available to SharePoint Products and Technologies database mirroring has the highest operational costs when considering the learning curve required for the server support staff and database administrators.

TechReady5 concluded on Friday and I’m finally returning to work after several customer sessions that immediately followed and one question was shared between the two - what do you recommend or what are you using to monitor performance and how do you determine load and stress when architecting a SharePoint Products and Technologies infrastructure? The answer is, there are a variety of tools to stress test your Microsoft SharePoint Products and Technologies deployment; let’s cover some them:

Database mirroring is increasing in popularity and becoming an integral part of high availability and disaster recovery solutions within the SharePoint Products and Technologies arena. I’ve spent much of the last few months building labs, testing scenarios, impacts on platforms whether it be WSS or MOSS. This post is the third and final on my series [SQL Server 2005 Database Mirroring and Windows SharePoint Services/Microsoft Office SharePoint Server 2007]. We know with asynchronous mirroring we can automatically manage SQL Server 2005 failover by introducing the witness role in our server farms, the most challenging question to answer is how to manage web front-end failover.

One of the most common questions making its way to my Inbox as of recently is how to determine the required requests per second (RPS) to support a SharePoint Products and Technologies deployment. While many IT Pros opt to use the recommend values associated with RPS and Internet Information Services (IIS) the transactions are considerably different between a light-weight .NET application or common IIS Web site. To establish a general requirement for requests per second for a SharePoint Products and Technologies deployment you will need answers to the following questions:

Site collection sizing is an important consideration in an overall capacity planning and governance solution. This article details the considerations when planning for capacity and determining how site collections should be sized. SharePoint Administration Tool (STSADM) The SharePoint administration tool, STSADM is most commonly used by SharePoint Products and Technologies administrators to backup and restore site collections or perform a variety of administrative tasks. Typically as the site collection size grows, the ability to use STSADM to backup and restore the site collection diminishes.

This is the second part of a multi-part series on using SQL Server 2005 Database Mirroring with SharePoint Products and Technologies. This post will cover the basic configuration parameters required to enable the mirroring of content, configuration, and search databases. Part 3 of this series will cover SharePoint Products and Technologies failover automation scripts and considerations. Basic SQL Server 2005 Database Mirroring Implementation for SharePoint Products and Technologies The most common implementation of SQL Server 2005 Database Mirroring includes all databases being installed on a single mirror partnership and the implementation of a witness (polling) server that provides automatic database failover between the principal and mirror servers when necessary.

With the introduction of Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007 the desire to reduce the number of content databases supporting a Web application has become a growing requirement to leverage both technologies such as SQL Server 2005 Database Mirroring, log shipping, and reduce the operational requirements to manage a high-volume of content databases. As a general rule, reducing the number of content databases will most often result in overall larger content databases hosting more site collections.

This will be the first of a multi-part series covering SQL Server 2005 Database Mirroring and Windows SharePoint Services 3.0/Microsoft Office SharePoint Server 2007. This post will cover an introduction to SQL Server 2005 Database Mirroring, an overview, and the basics to include considerations and integration with SharePoint Products and Technologies. Part 2 will cover implementing SQL Server 2005 Database Mirroring with SharePoint Products and Technologies using NTLM authentication and dedicated (DAS) storage and failover examples.

One of the most critical components of Microsoft Office SharePoint Server 2007 to many businesses is search and often is a key component of business processes. To ensure consistent and recoverable content is available to end-users, it becomes necessary to periodically backup the search components in the event of a catastrophic failure or issues requiring the rebuilding of the search component. Since re-crawling all content sources may not be practical or efficient in many cases, Microsoft Office SharePoint Server 2007 has streamlined the search component backup and restore process.