Uncategorized

Governance Resources for SharePoint 2010

Governance relates to decisions that define expectations, manage access, and validate performance and investment performance defined by established processes and procedures.  The information here contains references to governance resources as related to SharePoint 2010, for additional information see also Governance Overview (SharePoint Server 2010).

Resources

Resource Center (Governance in SharePoint Server 2010)

The Governance Resource Center provides documentation, references, and solutions to help IT Professionals plan and prepare to govern SharePoint 2010 environments.  The Governance Resource Center aligns to three (3) specific areas:

  1. IT Governance
  2. Information Management
  3. Application Management

Resource Center (ALM Resource Center | SharePoint 2010)

The ALM Resource Center provides documentation, resources, references, and solutions to help Developers with the coordination of all aspects of software engineering.

Whitepaper (SharePoint 2010 Governance Planning)

The SharePoint 2010 Governance Planning whitepaper targets the business value of governance and provides guidance for the necessary governance planning and implementation of SharePoint Server 2010.

Whitepaper (Implementing Governance in SharePoint 2010)

This document focuses on the product and technology aspects of SharePoint governance – the technical implementation. It provides high-level guidance on the many configuration options SharePoint provides to enable you to manage the environment for the benefit of all.

Publication (Essential SharePoint 2010: Overview, Governance, and Planning (Addison-Wesley Microsoft Technology Series)

Essential SharePoint 2010 provides information derived from a business value perspective that documents and illustrates how to plan and implement SharePoint 2010-based solutions to maximize business results.

Tools and Utilities

Tool (SharePoint Site Recycle Bin)

Track, report, and protect deleted sites and site collections with the SharePoint Site Recycle Bin.

The SharePoint Site Recycle Bin is a Microsoft SharePoint Foundation 2010 solution package that when deployed to a Microsoft SharePoint Foundation 2010 or Microsoft SharePoint Server 2010 server farm enables administrators to create a snapshot of subscriptions, site collections and Webs as they are deleted through the SharePoint user interface, the SharePoint Administration Tool, the SharePoint 2010 Management Shell, SharePoint 2010 Central Administration, or SharePoint Designer.

Solutions

Active Directory Domain Services Markers

Active Directory Domain Services Markers can be used to prevent and report on SharePoint installations in your organization.

Quotas

Quotas are used to specify limits to the amount of storage that can be used by a site collection and establish resource limits on sandboxed solutions.

Locks

Locks are used to prevent users from from adding content to or accessing site collections.

Self-Service Site Creation

Self-Service Site Creation is used to allow or prevent  users from creating site collections on demand.

For a comprehensive list of governance features see also http://technet.microsoft.com/en-us/library/cc262287.aspx.

Standard
Uncategorized

Microsoft IT Site Delete Capture LE Version 1.0 Released

Microsoft IT Site Delete Capture LE version 1.0 has been released.


Microsoft Site Delete Capture LE version 1.0 is an Windows SharePoint Services 3.0 solution package that when deployed to a Windows SharePoint Services 3.0 or Microsoft Office SharePoint Server 2007 server farm enables administrators to create a snapshot of site collections and Webs when they are deleted through the SharePoint user interface, the SharePoint Administration Tool, or Microsoft Office SharePoint Designer 2007.

Microsoft IT Site Delete Capture LE 1.0 is a light-weight implementation of the Microsoft IT Site Delete Capture 1.0 offered as a Windows SharePoint Services 3.0 solution package. This build does not include e-mail notification logic and introduces deprecated application event logging.

Read more…

Standard
Uncategorized

Announcing the Beta Release of the SharePoint Asset Inventory Tool

In the past several weeks, I’ve traveled along the west coast and overseas discussing governance as it applies to SharePoint Products and Technologies and am delighted to announce the availability of the beta of the SharePoint Asset Inventory Tool.


The SharePoint Asset Inventory Tool is single reporting application that can be used to mitigate SharePoint Products and Technologies server proliferation by scanning the network for server machines with Windows SharePoint Services 3.0 and/or Microsoft Office SharePoint Server 2007 installed.  The SharePoint Asset Inventory Tool leverages SQL Server Reporting Services to generate detailed reports on the location, content, and usage of the SharePoint Products and Technologies and incorporates an open model to enable administrators and IT Pros to create and generate custom reports tailored to their environments and the information pertinent to them.


To learn more about the SharePoint Asset Inventory Tool visit http://go.microsoft.com/fwlink/?LinkID=103035 or download the beta release on Microsoft Connect at https://connect.microsoft.com/programdetails.aspx?ProgramDetailsID=1600.

Standard
Uncategorized

Dynamic Application of Master Pages in Microsoft Office SharePoint Server 2007

I’ve spent the past two months in various locations across the West coast speaking on governance in SharePoint Products and Technologies and one of the most common points of discussion is enabling a consistent look and feel across sites and Webs.  While most commonly this is achieved through employing a master page, many organizations either limit the distribution of Microsoft Office SharePoint Designer 2007 or do not use Microsoft Office SharePoint Designer 2007 in their organizations, while there are many articles across numerous blogs providing prescriptive guidance on master page development, Feature stapling, and other variations to support the implementation of master pages, I’ve yet to find a complete tutorial on implementing master pages using a combination of Feature stapling and a Feature Receiver.


NOTE Sample master pages can be downloaded from: http://www.microsoft.com/downloads/details.aspx?FamilyID=7c05ca44-869a-463b-84d7-57b053711a96&DisplayLang=enClick here to download sample master page resource files based on the Clarity master page included in the Windows SharePoint Services 3.0 Sample: Example Master Pages.  The Clarity master page in this download was modified to support installation as a Windows SharePoint Services 3.0 solution package.


Create the Solution Directory Structure


The directory structure is important to the solution when it is to be compiled using MAKECAB.exe later in this article, to simplify the compilation using MAKECAB.exe you should create a directory structure relative to the location on which the files will be installed on the Web server(s), the directories when the solution is added and deployed to the server farm are relative to %commonprogramfiles%Microsoft SharedWeb Server Extensions12 in this example.


+ Sample Master Page Solution


  + GAC Hosts the Feature Receiver called by the Feature


  +  TEMPLATES


    + FEATURES


      + Sample.MasterPage Hosts the master page feature scoped at the Site level and MasterPages subdirectory.


        + MasterPages Hosts the master page or master pages that will be used by the solution.


      + Sample.Stapler Hosts the stapling Feature that makes the master page(s) available to the Site and Web scopes.


      + Sample.Web.Master Hosts the master page feature scoped at the Web level.


    + LAYOUTS


      + <LocaleID>


        + Styles *Optional Hosts cascading stylesheets used by out of the box master pages and page layouts.


          + Sample *Optional Hosts cascading stylesheets used by the master page.


    + IMAGES


      + Sample *Optional Hosts images used by the master page.


Create the Master Page Feature (Scope = Site)


The master page feature contains both the files necessary to provision a Feature and the master page to be applied to newly created sites. The master page Feature directory should contain a directory to host the master page and two files, Feature.xml and ProvisionedFiles.xml.


Feature.xml


Feature.xml defines the base properties of the Feature and lists elements bound to it.


NOTE For more information see the Working with Features article on MSDN at http://msdn2.microsoft.com/en-us/library/ms460318.aspx.


Elements and Attributes


The <Feature> element defines the Feature and specifies the location of assemblies, files, dependencies, and additional properties supporting the Feature.  In Feature.xml the Title attribute specifies the name of the Feature as it appears in the SharePoint Products and Technologies user interface and is supported by the Description attribute which can be used to specify additional descriptive text to identify the Feature.  It is best to provide a clear description of the Feature, it’s purpose and scope in the Description attribute to easily identify the Feature in the SharePoint Products and Technologies user interface.  The Scope attribute specifies the scope at which the Feature applies itself, in this example, the scope is at the Site level.  The Hidden attribute specifies whether or not the Feature is visible in the SharePoint Products and Technologies user interface and the DefaultResourceFile specifies the default resource file used by the Feature.


The ElementManifests element specifies references to element manifests and element files that contain definitions for the Feature elements.


Example:


<!– _lcid=”1033″ _version=”12.0.4518″ _dal=”1″ –>
<!– _LocalBinding –>
<Feature  Id=”<GUID>”
          Title=”Sample Site Collection Master Page
          Description=”The sample master page provides an instant style ready to be applied to your SharePoint site.
          Version=”1.0.0.0
          Scope=”Site
          Hidden=”False
          DefaultResourceFile=”core
          xmlns=”
http://schemas.microsoft.com/sharepoint/>
    <ElementManifests>
        <ElementManifest Location=”ProvisionedFiles.xml/>
    </ElementManifests>
</Feature>


ProvisionedFiles.xml


ProvisionedFiles.xml defines the resources that are provisioned on the Web server as a component of the underlying associated Feature.


Example:


<!– _lcid=”1033″ _version=”12.0.4518″ _dal=”1″ –>
<!– _LocalBinding –>
<Elements xmlns=”
http://schemas.microsoft.com/sharepoint/>
<Module Name=”OSGMasterPagesUrl=”_catalogs/masterpagePath=”MasterPagesRootWebOnly=”TRUE“>
        <File Url=”Clarity.master” Type=”GhostableInLibrary”>
            <Property Name=”ContentTypeValue=”$Resources:cmscore,contenttype_masterpage_name;” />
            <Property Name=”PublishingPreviewImageValue=”/_layouts/images/clarity/clarity.gif/>
            <Property Name=”MasterPageDescriptionValue=”Clarity Master Page/>
        </File>
</Module>
</Elements>


In the example the preview image for the master page is stored in a subdirectory, clarity relative to %commonprogramfiles%Microsoft SharedWeb Server Extensions12BIN.  It is recommended to create resource directories to host supporting content to easily identify resources associated with the master page on the Web server file system.


Create the Master Page Feature (Scope = Web)


The master page feature contains both the files necessary to provision a Feature and the master page to be applied to newly created Webs. The master page Feature directory should contain two files, Feature.xml and ProvisionedFiles.xml.


Feature.xml


Example:


<!– _lcid=”1033″ _version=”12.0.4518″ _dal=”1″ –>
<!– _LocalBinding –>
<Feature  Id=”<GUID>”
          Title=”Sample Web Master Page
          Description=”The sample master page provides an instant style ready to be applied to your SharePoint site.”
          Version=”1.0.0.0
          ReceiverAssembly=”SampleReceiver, Version=1.0.0.0, Culture=neutral,PublicKeyToken=<PKT>
          ReceiverClass=”SampleReceiver.FeatureReciever
          Scope=”Web
          Hidden=”False
          DefaultResourceFile=”core
          xmlns=”
http://schemas.microsoft.com/sharepoint/>
    <ElementManifests>
        <ElementManifest Location=”ProvisionedFiles.xml/>
    </ElementManifests>
    <Properties>
      <Property Key=”MasterNameValue=”Clarity.master/>
    </Properties>
</Feature>


The Web master page Feature has two notable differences in comparison to the sites master page Feature, the ReceiverAssembly attribute and its dependencies and the <Properties> element that defines the master page to be applied when the custom code is called in the Feature Receiver specifies in the ReceiverAssembly attribute and dependant attributes.


The ReceiverAssembly attribute specifies the assembly name (instructions later in this article).  The Version and Culture attributes specify the assembly version and Culture.  The PublicKeyToken attribute specifies the Public Key Token for the assembly.  Once the assembly is compiled in Visual Studio you can use the Strong Naming utility SN.exe or optionally copy the assembly to your Global Assembly Cache to retrieve the Public Key Token.  NOTE Assemblies must be signed to support installation in the Global Assembly Cache.


ProvisionedFiles.xml


<!– _lcid=”1033″ _version=”12.0.4518″ _dal=”1″ –>
<!– _LocalBinding –>
<Elements xmlns=”
http://schemas.microsoft.com/sharepoint/></Elements>


Create the Master Page Stapling Feature


Feature.xml


Feature.xml defines the base properties of the Feature and lists elements bound to it.  NOTE For information on Feature.xml elements and attributes used in this solution, see Elements and Attributes in the Create the Master Page Feature section at the top of this article.


Example:


<!– _lcid=”1033″ _version=”12.0.4518″ _dal=”1″ –>
<!– _LocalBinding –>
<Feature  Id=”<GUID>”
          Title=”Sample Stapler
          Description=”Sample stapler feature.
          Version=”1.0.0.0
          Scope=”Farm
          Hidden=”False
          DefaultResourceFile=”core
          xmlns=”
http://schemas.microsoft.com/sharepoint/>
    <ElementManifests>
        <ElementManifest Location=”ElementsManifest.xml/>
    </ElementManifests>
</Feature>


The stapling Feature enables the association of a specific Feature with a site definition.  The stapling Feature directory should contain two files, Feature.xml (described above) and ElementManifest.xml.


ElementManifest.xml


ElementManifest.xml contains definitions for the Feature elements.


The <FeatureSiteTemplateAssociation> element specifies the site templates the Feature should be associated to.  In ElementManifest.xml the Id attribute specifies the globally unique identifier for the site template the Feature should be associated and the TemplateName attribute specifies the friendly name of the template associated with the globally unique identifier in the Id attribute.  In this example, the Feature is associated with an example collection of the out of the box site definitions for both sites and Webs, use additional Site Templates as needed by adding the identification values in the <Elements> element.


<!– _lcid=”1033″ _version=”12.0.4518″ _dal=”1″ –>
<!– _LocalBinding –>
<Elements xmlns=”
http://schemas.microsoft.com/sharepoint/>
  <!–Clarity.MasterPage Feature–> 
  <FeatureSiteTemplateAssociation Id=”<GUID>TemplateName=”STS#0” /> 
  <FeatureSiteTemplateAssociation Id=”<GUID>TemplateName=”STS#1” /> 
  <FeatureSiteTemplateAssociation Id=”<GUID>TemplateName=”STS#2” />


  <!–Clarity.Web.Master Feature–> 
  <FeatureSiteTemplateAssociation Id=”<GUID>TemplateName=”STS#0” />  
  <FeatureSiteTemplateAssociation Id=”<GUID>TemplateName=”STS#1” />
  <FeatureSiteTemplateAssociation Id=”<GUID>TemplateName=”STS#2” />
</Elements>


Create the Feature Receiver


The Feature Receiver provides the ability to respond to Feature events which permit trapping and responding to an event that fires when a Feature is installed in the Web farm, added to a Web application, or when a Feature is removed.  For additional information on Feature Events see http://msdn2.microsoft.com/en-us/library/ms469501.aspx or for additional information using Feature Receivers to modify master page properties and application on a SPWeb object see http://blogs.msdn.com/bgeoffro/archive/tags/branding/default.aspx.


The Feature Receiver is the core of the master page solution and enables a method by which an event is acted on when the Feature function or functions are called.  The Feature Receiver used in this example is called by the Clarity.Web.Master Feature.  Event handlers within the Feature Receiver class are fired when the Feature is installed, activated, uninstalled, and/or deactivated.  To instruct the SPWeb object to use the new Master Page you would supply the necessary code inside the FeatureActivated Event Handler.


Create the SharePoint Solution Package


The SharePoint solution package will contain the Feature resource files and receiver created in the steps above.  There are several applications available today specifically designed to create and compile SharePoint solution packages; however, most commonly the MAKECAB.exe application is used to create the solution package.  To download and learn more about MAKECAB.exe visit http://support.microsoft.com/kb/310618.  For solution packaging examples using MAKECAB.exe see Deploying ProClarity Viewer 6.3 for SharePoint and Understanding Solution Packages in Microsoft Office SharePoint Server 2007/Windows SharePoint Services 3.0.


Resources


Chris Johnson:  Feature Stapling in WSS v3 http://blogs.msdn.com/cjohnson/archive/2006/11/01/feature-stapling-in-wss-v3.aspx


Heather Solomon:  Create a Feature: Master Pages for Site Collections http://www.heathersolomon.com/blog/articles/servermstpageforsitecollect_feature.aspx


Andrew Connell:  Adding Master Pages to WSS v3 Site Collections via Features http://andrewconnell.com/blog/archive/2006/10/21/4954.aspx


Brett’s SharePoint Blog:  Branding http://blogs.msdn.com/bgeoffro/archive/tags/branding/default.aspx *Great Code Samples

Standard
Uncategorized

Free PacWest Sales Event – SharePoint Products and Technologies Governance

If you are in or plan to be in the Puget Sound area on November 8th, I encourage you to register for the PacWest Sales Event focused on governance in SharePoint Products and Technologies; presenters will include myself, Joel, Jim Adams, and others…for more information on registration, location, date, and details visit Joel’s blog at http://blogs.msdn.com/joelo/archive/2007/10/30/free-pac-west-sales-event-meeting-of-the-minds-governance-and-sharepoint-2007.aspx.

Standard
Uncategorized

Site Collection Sizing Considerations

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. Performance issues, including unscheduled recycling of an application pool result in failure of the site collection backup/restore and are often the result of resource contention when a large amount of data is backed up; the specifications as provided with SharePoint Portal Server 2003 were 2GB (http://support.microsoft.com/kb/889236). Though much improved in Microsoft Office SharePoint Server 2007/Windows SharePoint Services 3.0, the opportunity of resource contention exists nonetheless and as a result STSADM should be considered a supplemental tool to your overall backup and recovery solution.

Site collections should be sized in a manner permitting manipulation of their content and host. A site collection whose size is compatible with the limitations of STSADM allows SharePoint Products and Technologies administrators to manipulate the site collection including its movement across content databases or even database servers/server farms.

Fewer & Larger Site Collections

Many businesses may have a need to have fewer site collections to provide a better overall view in respect to their environment where a site collection of 0-15GB may not be suitable to host the amount of necessary content. Large site collections are often selected to take advantage of aggregation and specific workflow capabilities. In these situations to permit simple recovery and management, it is often a best practice to isolate those site collections in their own content database. This allows the SharePoint Products and Technologies administrator(s) to easily recover the site collection and/or content. A consideration before making a decision on fewer larger site collections is the potential performance implications if the site collection will host a large amount of content, either at its root level or within residing webs. Typically performance will become progressively worsened as the number of total objects exceeds 2,000. As a site collection grows to a point to where performance suffers, a SharePoint Products and Technologies administrator can use the STSADM export and import operations to manipulate the fastest growing webs into their own site collection, thereby reducing the overhead associated with maintaining it side-by-side with other webs within a site collection. As with the site collection recommendation, this web should reside in a dedicated content database; however, the move should occur when the web is still within the parameters of the SharePoint administration tool (STSADM).

Another consideration of enabling large site collections is the ability to delete a site collection/web both through the web user interface and the SharePoint administration tool. The SharePoint Products and Technologies delete process is most often an end-user request resulting from submission of the request to the web front-end computer through the user interface. The request arrives at the SQL database server at which point the stored procedure Proc_DeleteSite is executed. Proc_DeleteSite execution results in a batch transaction consisting of many nested transactions dependent on the number of items in the ownership chain. The batch transaction is executed against the lowest level of ownership and works upward on row by row basis. The SQL database server will instantiate a ‘deleted’ table in memory to host the requests, in the event the memory allocation for the operation is exceeded, the SQL database server will use TempDB to commit the transaction. Each nested transaction within the batch transaction is confirmed and then committed against each item in the ownership chain. An item in this case refers to a document, list item, etc. In the event a nested transaction fails; the batch transaction is rolled back to the outermost begin transaction requiring the SQL database server to instantiate an ‘insert’ table in memory to host the requests; as with the ‘deleted’ table mentioned above, in the event the memory allocation for the operation is exceeded, the SQL database server will use TempDB to commit the transaction. The results can cause SQL blocking in the event a large number of items must be removed in the ownership chain prior to completing the request and occasionally jobs within the enclosing transaction may not be successfully rolled back. Large site collections hosting a significant number of documents and/or list items are particularly susceptible to this issue as a result of the number of transactions occurring on the SQL database server.

Data change rate can also impact a large site collection in which SQL log growth for the site collection when isolated to an individual content database should be closely monitored and maintained. SQL log growth should also be closely monitored for a content database hosting a large site collection in the event database mirroring and/or log shipping are selected as a disaster recovery option for the server farm; greater churn rates can significantly impact the performance of these technologies.

An additional consideration in maintaining a large site collection is the maintenance of permissions and subsequent inheritance.

In the event a large site collection is selected to host content and serve an aggregation performance, a number of search scopes may need to be defined to support providing relative search results to the site collection consumers. An aggregation portal is the most recommended implementation in this scenario to avoid the requirement to navigate several Windows SharePoint Services site collections to retrieve content based upon search results or alert notifications.

Smaller Site Collections

Where the number of site collections is not a concern; site collections are beneficial in that they offer true ownership, storage, and usage analysis reporting which can drive governance and manageability and in addition provide insight into what areas of a business are growing at varying paces. Site collections where growth is limited to a maximum of 15GB provide both ease of management and overall sustainability in terms of resources the ability to manipulate the site collection. Maintaining an environment with many site collections can be achieved through a proper governance plan, leveraging Site Directory taxonomy and the Windows SharePoint Services search service. In the situation where aggregation is desired, Microsoft Office SharePoint Server 2007 can be leveraging establishing an aggregation portal making the results from all site collections hosted on a Web application to be available to the portal through the Office Server search service and properly defined scopes.

Recommendations


  1. Establish a single aggregation portal based on the available SharePoint Products and Technologies Enterprise site templates.
  2. Establish search scopes relative to content sources and business units enabling efficient consumer queries and accurate result sets.
  3. Establish a maximum site collection quota template supportive of the SharePoint administration tool (STSADM); 15GB is the recommendation based upon performance and scale results.
  4. Limit site collection creation to a unique security group to provide oversight and management of the environments content. This allows a group of users to offer content approval prior to the introduction of a site collection to the server farm.
  5. Make site collection templates unavailable through self-service site creation to reduce the number of site collection templates and maintain consistency within the server farm.
  6. Enable usage and advanced usage analysis to gauge the growth of site collections; fast-growing webs may be candidates to become stand-alone site collections. This is easily accomplished when the web is within the limitation of the SharePoint administration tool (STSADM) through the export and import operations.
  7. Establish and maintain a Site Directory taxonomy that is relative to regional, organizational, and business unit aspects at a minimum to provide a concise overview of the environment and ease locating content by taxonomy assignment.
  8. Establish a life cycle management plan using site confirm and usage reporting and/or an out of the box solution. Life cycle management can be tuned according to individual growth, retention, and data management planning.
  9. Establish site collections as document repositories to host content for associated site collections.

Resources

SharePoint Governance and Manageability

Standard
Uncategorized

I’m pleased to announce the availability of Microsoft IT Team Site Life Cycle Management Beta 1.0 for SharePoint Products and Technologies.

I’m pleased to announce the availability of Microsoft IT Team Site Life Cycle Management (MSIT TSLCM) Beta 1.0 for SharePoint Products and Technologies.


Microsoft IT Team Site Life Cycle Management is a custom solution that provides lifecycle management for Windows SharePoint Services site collections and webs through write locking, backing up and recovering site collections/webs and is based on the out-of-box Site Usage and Confirmation feature.


Microsoft IT Team Site Life Cycle Management Beta 1.0 will be a community driven effort and managed under CodePlex source control.  Discussion boards and bug management will be also provided by the CodePlex workspace.  I look forward to your feedback!


To learn more about Microsoft IT Team Site Life Cycle Management Beta 1.0 visit http://www.codeplex.com/governance.


The SharePoint Governance workspace is intended provide governance and manageability samples and tools designed to help IT Professionals management SharePoint Products and Technologies deployments.  Upcoming tools include an implementation of site/web lifecycle management based on the Site Delete and Confirmation feature, the Microsoft IT Site Delete Capture 1.0 feature, and additional out-of-the-box functionality.  A sample auditing configuration solution deployment package will be introduced in the September-October timeframe that provides guidance on auditing and the management of content types across site collections.

Standard