Windows SharePoint Services 3.0 Security Updates Version(s) Explained

I was recently asked by one of our Premier Field Engineers in Charlotte, NC about the versioning information displayed in SharePoint 3.0 Central Administration after installing recent Windows SharePoint Services 3.0 security updates and decided it would be beneficial to expand the audience for others seeking an answer to this question.


Question:


In relation to the October patches for MOSS/WSS – should the database version show up correctly in CA? or is it expected that it would should up like this:


In CA – Operations -> Servers in Farm
All FE’s and App’s show up as 12.0.0.6039
But the cluster running the WSS Database shows 12.0.0.4518?


I checked a content DB and the versions table shows 12.0.0.6039…


Answer


Although WSS shows as build 12.0.0.6040 you will see it display 12.0.0.6039 in Site Settings since the EULA changed in 6040 which did not make any binary changes from 12.0.0.6039 to 12.0.0.6040.    Your Windows SharePoint Services Database in the Central Administration user interface will reflect the RTM build version 12.0.0.4518 since a binary change does not occur on the backend.

Windows Server 2008 and Microsoft Office SharePoint Server 2007 – So happy together…

I’ve spent the last couple of weeks using SharePoint Products and Technologies with Windows Server 2008 (WS08), specifically running Microsoft Office SharePoint Server 2007 (MOSS) on Windows Server 2008 IIS 7.0 and Microsoft Office SharePoint Server 2007 SP1 in addition to check-in scenarios such as provisioning WS08 with WSS 3.0, introducing MOSS 2007, and ultimately SP1…I anticipated an improvement in performance, but the new implementation of the TCP/IP protocol suite AKA Next Generation TCP/IP stack exceeded my expectations considering the Web front-ends I used were in our Singapore Data Center – a full 226ms of latency from Redmond.  I was most impressed by the ease of use with WS08 and the simplicity and effortless install and configuration of both WSS and MOSS despite IPv6 and their subsequent introduction to a production hosting farm as Web front-end servers.  They easily picked up configuration items from the configuration database and solution deployment was flawless.  Network Load Balancing was the next challenge, but again with little effort I was able to introduce the WS08 nodes into the load balancing rotation with Windows Server 2003 (WS03) machines…subscribe today – I’ll have more on this topic as time progresses.


Windows Server 2008 Resources


Windows Server 2008 Homepage


http://www.microsoft.com/windowsserver2008/default.mspx


Release Candidate Evaluation Software


Windows Server 2008 Release Candidate Evaluation Software


IIS 7.0 in Windows Server 2008


IIS 7.0 in Windows Server 2008

Hybrid Upgrade Approach added to TechNet

I was reviewing the Microsoft Office SharePoint Server TechNet article Determine upgrade approach and realized an article I have been working internally over the past few weeks has been published and introduced to the three existing upgrade approaches of in-place, gradual, and database migration. The upgrade approach itself is described/labeled as a hybrid upgrade approach which combines both the gradual and database migration approaches permitting administrators to preview a subset of site collections prior to upgrading the remainder of the environment (for those who have attended my TechReady, etc. presentations, the approach is familiar). While a complex approach, it offers the ability to provide production upgrade previews without the cost of implementing additional hosting hardware. Read more…

KB934525 Troubleshooting “Cannot start service SPAdmin on computer ‘.’.”

I’ve come across a handful of posts regarding KB934525 for Windows SharePoint Services and failure to start the Windows SharePoint Services Administration service.  I’ve attached some basic troubleshooting steps that may provide resolution to issues where psconfig fails with Cannot start service SPAdmin on computer ‘.’.  For those who have installed the KB and have experienced issues where the service has failed to start, Option 4 is the recommended solution. 


UPDATE Oct. 15, 2007 18:50 If you are unable to successfully initialize and complete the SharePoint Products and Technologies Configuration Wizard (psconfig) after following the steps in Option 4 below, consider Options 1 through 3; otherwise, uninstall WSS from the server, reinstall WSS, extract the contents of the KB using the steps provided in Option 3 below and install from the extracted STS.msp and following the remaining steps in Option 4 to start SPAdmin and complete configuration.


UPDATE Oct. 16, 2007 13:15 I received information indicating you may also experience the attached error in your server farm to which Option # 4 resolves:


The schema version (3.0.149.0) of the database WSS_Content_<databasename> on <databaseserver><instance> is not consistent with the expected database schema version (3.0.151.0) on <database>.  Connections to this database from this server have been blocked to avoid data loss.  Upgrade the web front end or the content database to ensure that these versions match.


UPDATE Oct. 23, 2007 14:52


See below on steps to resolve The database WSS_Content on HOMEMicrosoft##SSEE is not accessible to missing Windows Internal Database signatures.


Option # 1 



  • Start the Windows SharePoint Services Administration service using the Services applet (Start, Run, Services.msc) and run SharePoint Products and Technologies Configuration Wizard.

Option # 2 



  • Start the SPAdmin service under the context of a local administrator on the server where the SPAdmin service failed to start when running the SharePoint Products and Technologies Configuration Wizard (psconfig.exe) and run SharePoint Products and Technologies Configuration Wizard.

net start spadmin

Option # 3 



Extract wssv3-kb934525-fullfile-x86-glb.exe and run the installation by executing C:tempSTS.msp (see below).

<drive>:wssv3-kb934525-fullfile-x86-glb.exe /extract:c:temp.

Option # 4 



  • On the machine where psconfig failed to start the SPAdmin service run:

%commonprogramfiles%Microsoft SharedWeb Server Extensions12BINpsconfig -cmd upgrade -inplace b2b -wait -force

Modify the service timeout values in the Registry:


HKLMSYSTEMCurrentControlSetControl add/modify DWORD value ServicesPipeTimeout to 60000 (60 seconds)

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControl add/modify STRING value WaitToKillServiceTimeout to 120000 (120 seconds)

Restart the server machine.


UPDATE Oct. 23, 2007 14:52


A solution is available to administrators of SharePoint Products and Technologies deployments experiencing the following application event after introducing WSS October public update KB934525.






























Event Type: Error
Event Source: Windows SharePoint Services 3
Event Category: Topology
Event ID: 6800
Date: 10/17/2007
Time: 8:09:40 PM
User: NA
Computer: HOME
Description: The database WSS_Content on HOMEMicrosoft##SSEE is not accessible to missing Windows Internal Database signatures.

1.  Run the following STSADM operations to stop and start the SPWebService:


stsadm -o provisionservice -action stop -servicetype spwebservice -servicename “”

stsadm -o provisionservice -action start -servicetype spwebservice -servicename “”

2.  Instantiate the upgrade by executing psconfig.exe or psconfigui.exe.


The cause of this issue is the SPWebService instance failed to finish provisioning. The status of that service is marked as provisioning. However, it has done enough provisioning work so that the user sites are working and/or during upgrade, the upgrade code skipped any web service instances that are not online, upgrading the administration sites; however, skipping the user sites.

Please don’t put that in my GAC…

I have had the opportunity over the past two weeks to speak with several customers in regards to SharePoint Products and Technologies as a platform, geographically disperse architectural considerations, but one question stood out that was shared by each of these customers – “How do you [Microsoft] manage customizations in your SharePoint deployments?”.  Before beginning to answer the question, I immediately realized how both widespread and common customization on this iteration of SharePoint is when compared to its predecessors.  In the past commentary was directed at whether or not to consider customization as opposed to having the anticipation of future customizations on the platform – so I was pleased to see that customers are recognizing the platforms’ extensibility and ability to go beyond the out of the box experience


Customization is something we both encourage and plan for inside of Microsoft, but to be successful at managing what customizations we would consider as a candidate for deployment we first had to establish a clear set of ground rules in the form of a customization policy.  Our customization policy defines for would be developers what we will allow for introduction into any of our server farms and also acts as an guide to identify and encourage development best practices.


The most important aspect of considering a customization for deployment is gaining an understanding of that proposed customization.  When approached with a customization request, we will initially ask for both a functional and technical specification.  The functional specification is intended to provide insight into what the customization is, what the developer is trying to achieve, and for what purpose the customization will serve, for example, to fill a gap in the product or extend an existing feature set.  The technical specification is used to provide a definition of how the developer proposes to implement the customization, what calls they intend to make, and a description of the general underlying architecture of the customization.  Using this information we can evaluate their statements, make recommendations on alternative ways to achieve the same goal whether those be through fewer calls to the OM, customization best practices as defined in our customization policies, or if similar functionality can be found out of the box.


Now we’ve addressed two of the most important initial aspects of any platform development and customization, we’ve established a clear set of rules to follow and have engaged on the overall proposal and its associated requirements.


 


So what do we consider best practices and safe development?


As much as I would like to address every situation and aspect of safe developing on SharePoint Products and Technologies, there are too many considerations to be captured here.  As a general resource, I encourage reviewing a public iteration of our customization policy here (http://go.microsoft.com/fwlink/?linkid=92311&clcid=0x409).  I would consider one of our primary goals as limiting the number of calls to the OM to as few as possible – while as rich as the OM is, we cannot afford every developer the resources to make frequent and/or unnecessary calls to the OM.  From an end-user/consumer perspective at Microsoft we openly permit the use of WYSIWYG editors, for example, Microsoft Office SharePoint Designer 2007 since the penalty for unghosted pages is significantly less than that in Windows SharePoint Services 2.0 due to improvements in the .NET 2.0 runtime.


One of the most common customizations we’ve found both in previous versions and the current product is the desire to brand the user interface for a customized look and feel.  In Windows SharePoint Services 2.0 our end-users/consumers were limited to the use of Microsoft Office FrontPage 2003 since our customization policy prevented the implementation of site templates and definitions due to the uncertainties and challenges when presented with an upgrade.  Although our policy has not changed in that aspect, with Windows SharePoint Services 3.0 we have introduced alternative solutions that we can recommend to substitute for the use of site templates and definitions such as Master Pages.  While Master Pages present an excellent vehicle for customization of the user interface, there remains a risk that we may rethink or alter our policies concerning the use of Microsoft Office SharePoint Designer 2007 limiting the implementation of Master Pages by our end-users/consumers.  To mitigate that risk we encourage wrapping Master Pages into a deployable Feature that can be implemented at the site collection level through the use of a Feature receiver to remove the requirement of application through Microsoft Office SharePoint Designer 2007 (see sample code).


About Master Pages


Master Pages provide the look, feel, and standard behaviors for all of the pages in a site.  See also http://msdn2.microsoft.com/en-us/library/ms443795.aspx.

    public class FeatureReciever : SPFeatureReceiver
{
public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
using (SPWeb oWebsiteRoot = (SPWeb)properties.Feature.Parent)
{
string MasterPageFile = string.Empty;
MasterPageFile = properties.Feature.Properties[“MasterName”].Value;
if ((MasterPageFile != null) && (MasterPageFile != string.Empty))
{
using (SPSite oSiteCollection = oWebsiteRoot.Site)
{
SPList oList = Site.GetCatalog(SPListTemplateType.MasterPageCatalog);
SPQuery oQuery = new SPQuery();
oQuery.Query = “<Where><Eq><FieldRef Name=”FileLeafRef” />”
+ “<Value Type=”File”>” + MasterPageFile + “</Value>”
+ “</Eq></Where>”;
SPListItemCollection collListItems = oList.GetItems(oQuery);
if (collListItems.Count > 0)
{
string Url = string.Empty;
// Get the server-relative URL of the root Web site in the Site Collection.
Url = Site.ServerRelativeUrl.ToString();
if (!Url.Equals(“/”)) Url += “/”;
MasterPageFile = Url + collListItems[0].Url.ToString();
// Set the URL of the master page used for the Web site to the custom master page.
oWebsiteRoot.MasterUrl = MasterPageFile;
oWebsiteRoot.CustomMasterUrl = MasterPageFile;
oWebsiteRoot.Update();
}
}
}
}
}
}

This code snippet is provided under the Microsoft Permissive License.


The next and by far most critical step in introducing a customization into a server farm is testing.  We implement a variety of areas and scenarios beginning with smoke test.  The smoke test defines whether or not the code is “good” enough to be submitted to testing, this should be determined during the initial engagements with the prospective developer and based on the agreements and conclusions after final review of the functional and technical specifications and is a core component of design validation.

Build verification testing is the process of determining whether or not the code does what it is intended to do or has been developed to do and is closely aligned with design validation.  Additional testing to be considered is API testing depending on the nature and intent of the customization, resource testing to evaluate impact on memory, processor, and disk – you can generally use the performance measurements of the target environment prior to implementation as a baseline, and additional comprehensive tests consisting of interoperability/integration testing, performance and capacity testing, privacy/security testing, reliability testing, scalability testing, stress testing (may also include volume testing), localization testing, robustness testing and usability testing.  These tests when combined will provide important details on the impact of the customization in your server farm; whether it exposes a negative result on performance, expectations under low-resources, unavailable resources, and high-latency conditions,  scale limitations, whether or not strings are localized and that code pages are mapped properly and any international settings in the application do not break functionality, if portions of the code or prone to crash, save failure, or introduce data corruption, etc.

It is important to work with the developer to make the aspects of test areas known and what are the boundaries and limitations and what constitutes acceptance criteria.  This in turn encourages the developer to focus on many aspects of the code outside of the just implementing and planning for core functionality.

During the process of testing it is a best practice to define what what dependencies there are both internal and external and develop contingency plans to include procedures for bug reporting and sustained support of the customization.  While many customizations do not fall into many of the test area categories, making them core to the customization process minimizes the risk a customization may impose of the platform and provides a clear and concise mitigation plan in the event you are faced with the unexpected.


 


Resources


Windows SharePoint Services Developer Center


Windows SharePoint Services 3.0 SDK


Microsoft Office SharePoint Server 2007 Developer Portal


What’s new for developers in Microsoft Office SharePoint Server 2007


Microsoft Office SharePoint Server 2007 SDK