SharePoint 3.0 Central Administration URL on Multiple Web Front-end Servers

A coworker recently came to me asking how to change the SharePoint 3.0 Central Administration URL where two or more Web front-end servers host the Central Administration Web application, for example, where two WFEs are deployed, both will leverage the URL of the first server provisioned with the Central Administration Web application.  As many may have noticed, the path cannot be changed via the shortcut properties on the server, the reason is because the URL is Registry-based.  To change the SharePoint 3.0 Central Administration URL so that each server uses its locally provisioned Web application open the Registry editor and navigate to HKEY_LOCAL_MACHINESOFTWAREMicrosoftShared ToolsWeb Server Extensions12.0WSS.  Locate CentralAdministrationURL and edit the value to reflect the desired location.

Important This article contains information about how to modify the registry. Make sure to back up the registry before you modify it. Make sure that you know how to restore the registry if a problem occurs. For more information about how to back up, restore, and modify the registry, click the following article number to view the article in the Microsoft Knowledge Base:

256986 (http://support.microsoft.com/kb/256986/) Description of the Microsoft Windows registry

Solution Accelerator SharePoint Manageability Toolkit (Beta) Released

The Solution Accelerator SharePoint Manageability Toolkit (Beta) includes two new System Center Operations Manager 2007 Management Packs for Microsoft Office SharePoint Server and Windows SharePoint Services providing new features to include new tasks for Internet Information Services, Windows SharePoint Services 3.0 Search monitoring, discovery of Single Sign-on server(s), and additional Microsoft Office SharePoint Server 2007 performance data monitoring.


Register and download the Solution Accelerator SharePoint Manageability Toolkit (Beta)
https://connect.microsoft.com/programdetails.aspx?ProgramDetailsID=1601&wa=wsignin1.0


Learn more about the Solution Accelerator SharePoint Manageability Toolkit (Beta)
http://blogs.msdn.com/sharepoint/archive/2007/08/17/announcing-the-availability-of-the-sharepoint-manageability-toolkit-beta.aspx


Find more Management Packs
http://blogs.technet.com/wbaer/archive/2007/01/29/microsoft-office-sharepoint-server-2007-mp-for-mom-2005-released.aspx


Learn more about System Center Operations Manager 2007
http://www.microsoft.com/systemcenter/opsmgr/default.mspx

Scripting SharePoint with Powershell

C# has long been the developers preference when working with Microsoft SharePoint Products and Technologies; however, since the release of Microsoft Office SharePoint Server 2007/Windows SharePoint Server 3.0 Powershell has become more widely used to support the automation of common administrative tasks – though C# is and will long be integral in application development, Powershell provides both simplicity and flexibility for the automation of routine tasks.  For example, let’s assume an administrator would like to programmatically provision a Web application outside of the SharePoint administration tool and/or the SharePoint 3.0 Central Administration user interface.


In this example (C#) you can reference the Microsoft.SharePoint.Administration Namespace and call the SPWebApplicationBuilder class to create a new SPWebApplication object.


static void Main(string[] args)
{
    SPWebApplicationBuilder pWebApp = new SPWebApplicationBuilder(SPFarm.Local);
    int iPort = 80;
    pWebApp.Port = iPort;
    SPWebApplication WebApplication = pWebApp.Create();

    WebApplication.Provision();

    SPSite SiteCollection = WebApplication.Sites.Add(“/”, “contoso\wbaer”, “wbaer@contoso.com”);

    SiteCollection.Close();
}

Using Powershell, the underlying concept remains the same with reduction in overall code:


[system.reflection.assembly]::LoadWithPartialName(“Microsoft.Sharepoint”)
$webAppBuilder=new-object Microsoft.SharePoint.Administration.SPWebApplicationBuilder( [Microsoft.SharePoint.Administration.SPFarm]::Local)
$webAppBuilder.Port=80
$webApp=$webAppBuilder.Create()
$webApp.Provision()
$webApp.Sites.Add(“/”,”contosowbaer”,
wbaer@contoso.com)


This code snippet is provided under the Microsoft Permissive License.


While Powershell does not provide specific out-of-the-box functionality for Microsoft SharePoint Products and Technologies as you can see from the example code above, the scripting possibilities are open through native access to .NET objects.  If you read an article, for example, Powerful Command Line Administration for SharePoint in the January 2007 issue of TechNet Magazine you will immediately find areas where common administrative functions can be scripted with Powershell reducing the operational overhead associated with managing a Microsoft SharePoint Products and Technologies deployment.


So what exactly is Powershell?


Powershell is a command line shell and scripting language and as such provides the ability to accelerate automation through system administration utilities, consistent syntax, naming conventions, .NET and COM integration, etc.


Where can I learn more about Powershell?


Windows Powershell Home


Windows Powershell: Frequently Asked Questions


Windows Powershell Newsgroup


Windows Powershell Team Blog


Windows Powershell Quick Reference

A Quick Note on Blog Images…

As some of you may have noticed many of the images no longer render within a limited set of posts within my blog; rest assured I am working to resolve the issue as quickly as possible.  Prior to about June 2007 I used an ISA published Windows SharePoint Services 3.0 server farm running in Active Directory account creation mode offering host header-based site collections – by enabling Anonymous Access on a Document Library within my personal site collection I was able to both host and manage images consumed by this blog.  Unfortunately the server farm is scheduled to be decommissioned, at least partially at this point…the initial concept was to promote Windows SharePoint Services technologies, develop hosting knowledge from an administrative perspective, and provide actual user data and experiences for patch and upgrade testing in addition to providing a Windows SharePoint Services baseline for performance measurement and analysis.  There is a remote possibility that may site collection may be retained in which case images and other hosted collateral will once again become available or alternatively I will migrate “legacy” posts content to another host.  During the decommissioning phases of this server farm I will also be taking the opportunity to update the tags I currently am using to simplify navigation and make relevant content easier to locate.  In the interim, if there is a specific image that you would like to have made available, please submit a comment letting me know…

Cluster or mirror?

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.  While a database mirroring partnership can failover automatically through the implementation of a witness server (high availability/synchronous), there are no methods to enable automatic failover of SharePoint Products and Technologies introducing the added cost of developing a mechanism to manage the failover of the SharePoint service in the event the principal server is lost.  In many cases additional hardware will be required to support the witness server role in a mirroring partnership.  Also inherent of database mirroring is the requirement to duplicate storage across the principal and mirror servers; SharePoint Products and Technologies will consume only from one single physical server at a time unless databases are mirrored in a bidirectional manner.  To offset storage costs database mirroring can leverage traditional DAS storage and/or consume its storage from a SAN.


Clustering is the most common database architecture and as such is the least expensive in operational overhead.  Clustering enables running the same application on two or more servers providing a high availability solution if one of the servers fails.  Cluster software (Cluster Service) natively handles the failover process enabling SharePoint Products and Technologies to run uninterrupted on the second server.  Clustering when compared to mirroring offers greater processing power in addition to scalability since it does not carry the same two (2) physical server limitation as database mirroring and shares resources across each member node, reducing storage costs when compared to database mirroring; however, clustering comes with the requirement of shared storage and does not support the DAS storage options of database mirroring.  Geographic redundancy is limited with clustering since technology limits the distance by which two (2) servers can be separated, Fibre Channel for instance provides the greatest overall distancing, but is limited to a few miles.


Database mirroring and clustering both are capable of data replication, commonly through backing up the transaction logs from a database to a different server and applied there on a standby database (log shipping).  Before you consider log shipping in either a mirroring or clustered database architecture you should carefully review the latency between the publishing and subscribing servers.


There are many other considerations to understand prior to implementing either solution as part of your database architecture for SharePoint Products and Technologies that are not mentioned here that should be carefully reviewed and are complimented by an appropriate implementation plan.


In Microsoft IT we have a mixture, though unbalanced, distribution of SQL server clusters and mirror partnerships and by slowly introducing database mirroring in limited locations as one more option in our SharePoint Products and Technologies database architecture we allow allow more efficient growth and sustainability by not overburdening our operations staff with the support and maintenance learning curve and allow them to continue focusing on current deployments while gradually evolving our database mirroring architecture.


For additional information on SQL Server Database Mirroring with SharePoint Products and Technologies, see my three part series:


SQL Server 2005 Database Mirroring and Windows SharePoint Services 3.0/Microsoft Office SharePoint Server 2007 – Part 1 (Introduction, Overview, and basics)


SQL Server 2005 Database Mirroring and Windows SharePoint Services 3.0/Microsoft Office SharePoint Server 2007 – Part 2 (Configuration)


SQL Server 2005 Database Mirroring and Windows SharePoint Services 3.0/Microsoft Office SharePoint Server 2007 – Part 3 (Failover)


Additional Resources


Database Mirroring in SQL Server 2005


Inside Microsoft.com – Getting Started with Database Mirroring


Database Mirroring Best Practices and Performance Considerations


SQL Server 2005 Failover Clustering White Paper


Top Tips for SQL Server Clustering