Uncategorized

Conference season is upon us…

Conference season is upon us and it’s gearing up to be a great way to close out the year – join me at the 2009 Microsoft SharePoint Conference in Las Vegas at the Mandalay Bay Convention Center October 19th through October 22nd, 2009 or for those locally and can’t make the conference join me at the 2009 Pass Community Summit with Burzin Patel November 2nd through November 5th, 2009 at the Washington State Convention and Trade Center in Seattle.  For those enrolled in the November Office SharePoint Server 2007 Microsoft Certified Masters rotation, congratulations and you’ll be seeing more of me ;-), and some time in between hosting a Windows 7 Launch Party!  Finally there may be something in between as well as a Spring 2010 SoCal trip.


Topics


Performance Tuning Microsoft SharePoint Products and Technologies (SQL Layer)


Business Continuity Management (HA/DR)


Windows 7


and more…

Standard
Uncategorized

STSADM -o preparetomove Implications on Search Redundancy

I was just reading Todd’s post on preparemove, and he does a good job of covering the changes in profile synchronization and related GUID reset/reassignment introduced by the application of the Infrastructure Update. There is one significant problem this change mitigates, specifically for those looking for a level of search redundancy through a dual-crawl architecture. In most scenarios where a dual-crawl architecture is implemented, an Office SharePoint Server Search instance in the primary datacenters crawls its localized content, and a separate, unique Office SharePoint Server Search instance in the secondary datacenter crawls the content in the primary datacenter. Prior to the Infrastructure Update, this architecture offered little benefit in that when transitioning service to the secondary datacenter, the content would have to be re-crawled, which resulted in little value; however, now that the GUID associated with each individual site collection does not get reset/reassigned when the content databases are moved across Web applications, transitioning the content databases to the secondary datacenter does not require a re-crawl. While the solution still does not provide high-availability for Office SharePoint Server Search, it does open the possibility to effective redundancy.

Standard
Uncategorized

High-Availability and Disaster Recovery with Microsoft SQL Server 2005 Database Mirroring and Microsoft SQL Server 2005 Log Shipping for Microsoft SharePoint Products and Technologies

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.

General Assumptions

Microsoft SQL Server 2005 Database Mirroring is installed and configured in high-safety mode with a witness server (synchronous).

Mirroring w Witness

The illustration above depicts Microsoft SQL Server 2005 Database Mirroring in high-safety mode with a witness server.  SQL01p is the principal server, SQL02m is the mirror server, and SQL01w is the witness server in the Microsoft SQL Server 2005 Database Mirroring session.

Configure the Principal/Primary Server

Configure Microsoft SQL Server 2005 Log Shipping on the principal Microsoft SQL Server 2005 server using either the Microsoft SQL Server Management Studio or Transact-SQL for each database to be mirrored using either a backup share on a separate host server or local folder.

See notes on Log Shipping with Microsoft SharePoint Products and Technologies.

When the Microsoft SQL Server 2005 Log Shipping configuration has been applied on the Microsoft SQL Server 2005 Database Mirroring principal server, failover the databases to the Microsoft SQL Server 2005 Database Mirroring mirror server.

Configure the Mirror/Primary Server

Configure Microsoft SQL Server 2005 Log Shipping on the mirror Microsoft SQL Server 2005 server using Transact-SQL, Microsoft SQL Server Management Studio cannot be used to configure the mirror server where participating in a shared Microsoft SQL Server 2005 Log Shipping session.

When the Microsoft SQL Server 2005 Log Shipping configuration has been applied on the Microsoft SQL Server 2005 Database Mirroring mirror server, failover the databases to the Microsoft SQL Server 2005 Database Mirroring principal server.

NOTE When configuring Microsoft SQL Server 2005 Log Shipping on the mirror/primary server you will receive an error indicating a transactional log backup could not be generated because the database is in either NORECOVERY mode or STANDBY mode.  The error is expected due to the state of the databases and can be ignored.

Log Shipping

The illustration above depicts both the principal and mirror configured as log shipping primary; however, in this scenario only the principal generates log backups.  In the event failover occurs within the Microsoft SQL Server 2005 Database Mirroring session, the new principal (previously mirror) will begin generating log backups at the log backup destination used by the original principal.

When the configuration of Microsoft SQL Server 2005 Log Shipping has been completed on the Microsoft SQL Server 2005 Database Mirroring pair, the log backup job will on the principal server will generate log backups on the backup share that will be applied by the primary server, the log backup job on the mirror server will continue to execute though will not generate logs until failover occurs within the Microsoft SQL Server 2005 Database Mirroring session.

Resources

Microsoft SQL Server 2005 Database Mirroring

Microsoft SQL Server 2000/2005 Log Shipping

Standard
Uncategorized

Notes on SQL Server 2000/2005 Log Shipping with SharePoint Products and Technologies

As Microsoft SharePoint Products and Technologies becomes more business critical for organizations, data protection and redundancy become primary objectives in any sizepaperclip deployment. Disaster recovery and redundancy can be achieved using any of a collection of available technologies to include SQL Server 2005 Database Mirroring for redundancy and hardware or software-based replication solutions for disaster recovery or geographic replication.


One of the most seamless methods available to a SharePoint deployment for geographic replication is SQL Server 2000/2005 Log Shipping.  SQL Server 2000/2005 Log Shipping provides a mechanism by which you can increase the availability of SQL Server databases by automatically copying and restoring transaction logs associated with those databases to a standby server that can be within the same datacenter as the host server or a separate geographic location.


This article discusses the limitations and constraints associated with SQL Server 2000/2005 Log Shipping with SharePoint Products and Technologies.  To learn more about SQL Server 2000/2005 Log Shipping see the SQL Server 2000/2005 Books Online.


SQL Server 2000 Books Online:  http://msdn2.microsoft.com/en-us/library/aa256841.aspx


SQL Server 2005 Books Online:  http://msdn2.microsoft.com/en-us/library/ms130214.aspx


Limitations and Constraints (SharePoint Products and Technologies)


Configuration Database (Windows SharePoint Services 3.0/Microsoft Office SharePoint Server 2007)


The configuration database and SharePoint 3.0 Central Administration content database are inter-dependent, therefore cannot be log shipped separately or at all for that matter due to hard-coded information about the servers (dbo.Objects), server roles, services provisioned on each of those servers, and other information specific to the host server farm. In a SQL Server 2000/2005 Log Shipping scenario you should consider configuring your standby server farm with a new configuration database and SharePoint 3.0 Central Administration database. Web parts, custom code/applications. and configuration settings should be reapplied to the standby server farm due to their dependencies on the configuration database in addition to the consideration that WFE-based components, including applications/customizations, GAC assemblies, etc. are not addressed in a log shipping scenario and require reapplication on the standby server farm.


Search (Windows SharePoint Services 3.0/Microsoft Office SharePoint Server 2007)


The search database cannot be log shipped to the standby server farm due to synchronization dependencies on the Shared Services Provider and search index; failover to the standby server farm will require a re-crawl of your content to provide the search experience previously available on the primary server farm.  (See also notes specific to Content Databases – Search).


NOTE To mitigate the impact on recovering search, consider the using the native backup and restore in Windows SharePoint Services 3.0/Microsoft Office SharePoint Server 2007 to backup search components, e.g. index to be restored on the destination server farm, while this will still require a re-crawl of your SharePoint content, your external, non-SharePoint content will remain intact.  Also consider applications such as SSPC (http://blah.winsmarts.com/2006-11-Solving_an_interesting_deployment_scenario_in_SharePoint_2007.aspx) to backup and restore managed and crawled properties.


Shared Services Provider Database (Microsoft Office SharePoint Server 2007)


The Shared Services Provider database can be log shipped to a standby server farm; however, must be manually reconnected to the destination server farm and reassigned a  server provisioned with the index role in that farm.  The Shared Services Provider database can be restored using the SharePoint Administration Tool (STSADM) restoressp operation, see http://technet.microsoft.com/en-us/library/cc262163.aspx.


NOTE The restoressp operation only applies to Microsoft Office SharePoint Server 2007 and requires an index server to execute successfully.


Content Databases (Windows SharePoint Services 3.0)


Windows SharePoint Services 3.0 content databases can be attached to the standby farm where they will reside in *read-only mode, this will allow the content to be available for viewing and where desired crawled by the localized Windows SharePoint Services 3.0 or Microsoft Office SharePoint Server 2007 Search services.  *IMPORTANT Applies only when the database load state is configured in standby mode, the recommended database load state is no recovery mode and users should be terminated in the database.  Read operations can potentially generate an exclusive lock on the destination database causing log shipping to become out of sync.


NOTE See http://support.microsoft.com/kb/894631 for important notes on Windows SharePoint Services 3.0 content databases configured as read-only.


People


People information will not be available in the standby server farm where the Shared Services Provider database is log shipped until the Shared Services Provider database is restored, an indexer assigned, and the associated people operations run; however, you may opt to discard the Shared Services Database, create a new Shared Services Provider on the standby server farm and enable operations to include Directory Services import, Audience Compilation, etc., this minimizes downtime in the event of failover since the operations will have already been configured and running as scheduled.


Notes specific to Content Databases


Search


In Microsoft Office SharePoint Server 2007 you will need to create a new Shared Service Provider on the standby farm to enable crawling of log shipped Windows SharePoint Services 3.0 content databases where the primary server farm is online; otherwise, you may optionally crawl the content post-failover where log shipping the Shared Services Provider database and the database has been reattached and assigned an indexer.  If you prefer to backup and restore the search components to the standby server farm from the primary server farm you will need to re-crawl the Windows SharePoint Services 3.0 content databases; however, any external content previously crawled, e.g. file shares, HTTP, etc. will not need to be re-crawled.


Site Collection Availability


Site collections created in the primary server farm will not be available for browsing in the destination server farm until the destination server farm site map has been updated with the corresponding entries, the site map table (dbo.SiteMap) stores a list of site collection URLs, associated identifiers including database identifiers, and upgrade information in addition to information about the site collection, for example, whether or not it is a host header-based site collection or path-based site collection..  You can refresh the site map by either detaching and re-attaching the Windows SharePoint Services 3.0 content databases through the SharePoint 3.0 Central Administration user interface, the SharePoint Administration Tool (STSADM) addcontentdb and deletecontentdb operations (http://technet.microsoft.com/en-us/library/cc262486.aspx), or optionally script the operation to run periodically through the Object Model using the SPContentDatabaseCollection Delete and Add methods.  See http://support.microsoft.com/kb/894631 for important notes on Windows SharePoint Services 3.0 content databases configured as read-only.


Profile and Membership Synchronization


When moving Windows SharePoint Services 3.0 content databases in Microsoft Office SharePoint Server 2007 you must prepare the content databases to be attached to the destination server by setting up the profile and membership synchronization service to prevent the synchronization service from failing and losing user privacy settings for those sites after the sites are moved.  The profile and membership synchronization service synchronizes user profile data down to the user information lists for all site collections to ensure consistent user data across the environment. The service also synchronizes site membership data back to the user profiles that store all of the sites where the user is a member. This site membership data is displayed on the user’s My Site.  For more information see http://technet.microsoft.com/en-us/library/cc262122.aspx.


image


The illustration above depicts a typical SQL Server 2000/2005 Log Shipping example where a (or) collection of Windows SharePoint Services 3.0 content databases are log shipped to a standby server and attached to the standby server farm as read-only.  The Shared Services Provider database denoted in red is offline until failover is complete and the Shared Services Provider database attached to the standby server (See Shared Services Provider Database (Microsoft Office SharePoint Server 2007) above), in this scenario, the content in the destination server farm cannot be crawled until the Shared Services Provider is  provisioned through restoring the database and assigning an Indexer in the standby server farm.  In some scenarios you may wish to create a new Shared Service Provider in the standby server farm to enable crawling of content and people and profile operations on the destination server farm while the host server farm is online.  Databases denoted in blue are those databases that cannot be log shipped to the standby server farm and should therefore be newly created on the standby server farm.


Next time – Implementing SQL Server 2000/2005 Log Shipping with SharePoint Products and Technologies


Resources


Understanding Log Shipping


Log Shipping in SQL Server 2000


Using SQL Server Database Mirroring with Office SharePoint Server and Windows SharePoint Services


How to enable Log Shipping (SQL Server Management Studio)


How to enable Log Shipping (T-SQL)


Database Maintenance for Microsoft SharePoint Products and Technologies

Standard