SPDeploymentWizard Wiki & Documentation Rss Feed

Updated Wiki: Home

chrisobrien — Wed, 17 Apr 2013 14:34:12 GMT

Project Description

This tool is for moving content in *SharePoint 2007/2010/2013* - within an environment (or across similar envs). NOT an *upgrade* tool (e.g. 2010 to 2013).

The SharePoint Content Deployment Wizard provides the means to deploy the following content:

- site collections
- webs
- lists
- folders
- list items (including files/documents)

Content is exported using the Content Migration API as a .cmp file

The two screenshots which probably illustrate the concept of the tool best are:

Export selection screen:

Import settings screen:

N.B. The import operation overwrites your site data, always take a backup before importing.

As discussed above, this tool is NOT an upgrade tool. It can only be used to move/copy content within a SharePoint environment, or across multiple SharePoint environments which are at the same version. It cannot be used to move content from SP2007 to SP2010, or SP2010 to SP2013 etc

All versions of this tool work with SharePoint 2010 (and probably SP2013, but not tested) though you must edit a file (one time) to do this - see notes on version 2.8 page. Also note that v2.8 (or later) provides the best install experience on 2010

More details (taken from readme)

Usage notes

The tool must be installed locally on the server which hosts the site
Site URL - enter using format http://source.test.dev
Import web URL - enter using format http://target.com/targetweb
See 'permissions' note lower down

Import/Export characteristics

Since the Content Migration API is used, imports/exports have the following characteristics:

dependencies of selected content (e.g. referenced CSS files, master pages) are automatically included in the export - check 'Exclude dependencies of selected objects' to disable this
all required content types, columns etc. are automatically included in the export
in contrast to STSADM export, it is possible to retain GUIDs during deployment (where objects are not being reparented) - check 'Retain object IDs and locations' to enable this
no filesystem files (assemblies, SharePoint Solutions/Features etc.) are deployed - these must already be present on the target for the import to succeed)
the following content does not get captured by the Content Migration API - alerts, audit trail, change log history, recycle-bin items, workflow tasks/state

Reparenting

Reparenting of objects such as webs and lists is possible with the following usage on the import:

- enter the URL for the target web in the 'Import web URL' textbox
- ensure 'Retain object IDs and locations' is not checked

Permissions

The Content Migration API (PRIME) is used to package the content as a .cmp file, which can be copied to another
server for import. The application MUST be run from the SharePoint server(s), and MUST be run under the context
of an account which has appropriate SharePoint permissions - currently the way to specify an alternative user
to the currently-logged on user is by using the 'Run as..' feature in Windows 2003 (right-click on the .exe and
select 'Run as..').

See my blog post 'Introducing the SharePoint Content Deployment Wizard' for more screenshots and information - http://www.sharepointnutsandbolts.com/2007/12/introducing-sharepoint-content.html

Chris O'Brien
http://feeds.feedburner.com/ChrisObrien

Updated Wiki: Home

chrisobrien — Wed, 17 Apr 2013 14:19:14 GMT

Project Description

NOTE: This tool is NOT an upgrade tool. It can only be used to move/copy content within a SharePoint environment, or across multiple SharePoint environments which are at the same version.

All versions of this tool work with SharePoint 2010 (and probably SP2013, but not tested) though you must edit a file (one time) to do this - see notes on version 2.8 page. Also note that v2.8 (or later) provides the best install experience on 2010

The SharePoint Content Deployment Wizard is a tool for *SharePoint 2007/2010* which provides the means to deploy the following content:

- site collections
- webs
- lists
- folders
- list items (including files)

Content is exported using the Content Migration API as a .cmp file

The two screenshots which probably illustrate the concept of the tool best are:

Export selection screen:

Import settings screen:

N.B. The import operation overwrites your site data, always take a backup before importing.

More details (taken from readme)

Usage notes

The tool must be installed locally on the server which hosts the site
Site URL - enter using format http://source.test.dev
Import web URL - enter using format http://target.com/targetweb
See 'permissions' note lower down

Import/Export characteristics

Since the Content Migration API is used, imports/exports have the following characteristics:

dependencies of selected content (e.g. referenced CSS files, master pages) are automatically included in the export - check 'Exclude dependencies of selected objects' to disable this
all required content types, columns etc. are automatically included in the export
in contrast to STSADM export, it is possible to retain GUIDs during deployment (where objects are not being reparented) - check 'Retain object IDs and locations' to enable this
no filesystem files (assemblies, SharePoint Solutions/Features etc.) are deployed - these must already be present on the target for the import to succeed)
the following content does not get captured by the Content Migration API - alerts, audit trail, change log history, recycle-bin items, workflow tasks/state

Updated Wiki: Home

chrisobrien — Wed, 17 Apr 2013 14:18:40 GMT

Project Description

NOTE: This tool is NOT an upgrade tool. It can only be used to move/copy content within a SharePoint environment, or across multiple SharePoint environments which are at the same version.

All versions of this tool work with SharePoint 2010 (and probably SP2013, but not tested) though you must edit a file (one time) to do this - see notes on version 2.8 page (linked above). Also note that v2.8 (or later) provides the best install experience on 2010

The SharePoint Content Deployment Wizard is a tool for *SharePoint 2007/2010* which provides the means to deploy the following content:

- site collections
- webs
- lists
- folders
- list items (including files)

Content is exported using the Content Migration API as a .cmp file

The two screenshots which probably illustrate the concept of the tool best are:

Export selection screen:

Import settings screen:

N.B. The import operation overwrites your site data, always take a backup before importing.

More details (taken from readme)

Usage notes

The tool must be installed locally on the server which hosts the site
Site URL - enter using format http://source.test.dev
Import web URL - enter using format http://target.com/targetweb
See 'permissions' note lower down

Import/Export characteristics

Since the Content Migration API is used, imports/exports have the following characteristics:

dependencies of selected content (e.g. referenced CSS files, master pages) are automatically included in the export - check 'Exclude dependencies of selected objects' to disable this
all required content types, columns etc. are automatically included in the export
in contrast to STSADM export, it is possible to retain GUIDs during deployment (where objects are not being reparented) - check 'Retain object IDs and locations' to enable this
no filesystem files (assemblies, SharePoint Solutions/Features etc.) are deployed - these must already be present on the target for the import to succeed)
the following content does not get captured by the Content Migration API - alerts, audit trail, change log history, recycle-bin items, workflow tasks/state

Updated Wiki: Home

chrisobrien — Wed, 17 Apr 2013 14:17:20 GMT

Project Description

NOTE: This tool is NOT an upgrade tool. It can only be used to move/copy content within a SharePoint environment, or across multiple SharePoint environments at the same version.

All versions of this tool work with SharePoint 2010 (and probably SP2013, but not tested) though you must edit a file (one time) to do this - see notes on version 2.8 page (linked above). Also note that v2.8 (or later) provides the best install experience on 2010

The SharePoint Content Deployment Wizard is a tool for *SharePoint 2007/2010* which provides the means to deploy the following content:

- site collections
- webs
- lists
- folders
- list items (including files)

Content is exported using the Content Migration API as a .cmp file

The two screenshots which probably illustrate the concept of the tool best are:

Export selection screen:

Import settings screen:

N.B. The import operation overwrites your site data, always take a backup before importing.

More details (taken from readme)

Usage notes

The tool must be installed locally on the server which hosts the site
Site URL - enter using format http://source.test.dev
Import web URL - enter using format http://target.com/targetweb
See 'permissions' note lower down

Import/Export characteristics

Since the Content Migration API is used, imports/exports have the following characteristics:

dependencies of selected content (e.g. referenced CSS files, master pages) are automatically included in the export - check 'Exclude dependencies of selected objects' to disable this
all required content types, columns etc. are automatically included in the export
in contrast to STSADM export, it is possible to retain GUIDs during deployment (where objects are not being reparented) - check 'Retain object IDs and locations' to enable this
no filesystem files (assemblies, SharePoint Solutions/Features etc.) are deployed - these must already be present on the target for the import to succeed)
the following content does not get captured by the Content Migration API - alerts, audit trail, change log history, recycle-bin items, workflow tasks/state

Updated Wiki: Home

chrisobrien — Wed, 07 Apr 2010 22:03:01 GMT

Project Description

UPDATE: Release 2.8 beta released 07 April 2010 with source code - see Release 2.8 beta page for release notes. Note also that this has now become the default release - previous reviews and download stats can be found under older releases.

NOTE: All versions of this tool work with SharePoint 2010 though you must edit a file (one time) to do this - see notes on version 2.8 page (linked above). Also note that v2.8 (or later) provides the best install experience on 2010

The SharePoint Content Deployment Wizard is a tool for *SharePoint 2007/2010* which provides the means to deploy the following content:

- site collections
- webs
- lists
- folders
- list items (including files)

Content is exported using the Content Migration API as a .cmp file

The two screenshots which probably illustrate the concept of the tool best are:

Export selection screen:

Import settings screen:

N.B. The import operation overwrites your site data, always take a backup before importing.

More details (taken from readme)

Usage notes

The tool must be installed locally on the server which hosts the site
Site URL - enter using format http://source.test.dev
Import web URL - enter using format http://target.com/targetweb
See 'permissions' note lower down

Import/Export characteristics

Since the Content Migration API is used, imports/exports have the following characteristics:

dependencies of selected content (e.g. referenced CSS files, master pages) are automatically included in the export - check 'Exclude dependencies of selected objects' to disable this
all required content types, columns etc. are automatically included in the export
in contrast to STSADM export, it is possible to retain GUIDs during deployment (where objects are not being reparented) - check 'Retain object IDs and locations' to enable this
no filesystem files (assemblies, SharePoint Solutions/Features etc.) are deployed - these must already be present on the target for the import to succeed)
the following content does not get captured by the Content Migration API - alerts, audit trail, change log history, recycle-bin items, workflow tasks/state

Updated Wiki: Home

chrisobrien — Wed, 07 Apr 2010 21:56:55 GMT

Project Description

UPDATE: Release 2.8 beta released 07 April 2010 with source code - see Release 2.8 beta page for release notes. Note also that this has now become the default release - previous reviews and download stats can be found under older releases.

The SharePoint Content Deployment Wizard is a tool for SharePoint 2007 which provides the means to deploy the following content:

- site collections
- webs
- lists
- folders
- list items (including files)

Content is exported using the Content Migration API (PRIME) as a .cmp file (Content Migration Package) which can be copied to other servers for import. Unlike the out-of-the-box tools, the Wizard allows *granular* selection of content via a treeview.

The two screenshots which probably illustrate the concept of the tool best are:

Export selection screen:

Import settings screen:

N.B. The import operation overwrites your site data, always take a backup before importing.

More details (taken from readme)

Usage notes

The tool must be installed locally on the server which hosts the site
Site URL - enter using format http://source.test.dev
Import web URL - enter using format http://target.com/targetweb
See 'permissions' note lower down

Import/Export characteristics

Since the Content Migration API is used, imports/exports have the following characteristics:

dependencies of selected content (e.g. referenced CSS files, master pages) are automatically included in the export - check 'Exclude dependencies of selected objects' to disable this
all required content types, columns etc. are automatically included in the export
in contrast to STSADM export, it is possible to retain GUIDs during deployment (where objects are not being reparented) - check 'Retain object IDs and locations' to enable this
no filesystem files (assemblies, SharePoint Solutions/Features etc.) are deployed - these must already be present on the target for the import to succeed)
the following content does not get captured by the Content Migration API - alerts, audit trail, change log history, recycle-bin items, workflow tasks/state

Updated Wiki: Home

chrisobrien — Fri, 16 Oct 2009 01:46:48 GMT

Project Description

UPDATE: Release 2.7 beta released 16 October 2009 with source code - see Release 2.7 beta page for release notes. Note also that this has now become the default release - previous reviews and download stats can be found under the 1.1 release.

The SharePoint Content Deployment Wizard is a tool for SharePoint 2007 which provides the means to deploy the following content:

- site collections
- webs
- lists
- folders
- list items (including files)

Content is exported using the Content Migration API (PRIME) as a .cmp file (Content Migration Package) which can be copied to other servers for import. Unlike the out-of-the-box tools, the Wizard allows *granular* selection of content via a treeview.

The two screenshots which probably illustrate the concept of the tool best are:

Export selection screen:

Import settings screen:

N.B. The import operation overwrites your site data, always take a backup before importing.

More details (taken from readme)

Usage notes

The tool must be installed locally on the server which hosts the site
Site URL - enter using format http://source.test.dev
Import web URL - enter using format http://target.com/targetweb
See 'permissions' note lower down

Import/Export characteristics

Since the Content Migration API is used, imports/exports have the following characteristics:

dependencies of selected content (e.g. referenced CSS files, master pages) are automatically included in the export - check 'Exclude dependencies of selected objects' to disable this
all required content types, columns etc. are automatically included in the export
in contrast to STSADM export, it is possible to retain GUIDs during deployment (where objects are not being reparented) - check 'Retain object IDs and locations' to enable this
no filesystem files (assemblies, SharePoint Solutions/Features etc.) are deployed - these must already be present on the target for the import to succeed)
the following content does not get captured by the Content Migration API - alerts, audit trail, change log history, recycle-bin items, workflow tasks/state

Updated Wiki: Home

chrisobrien — Sat, 29 Aug 2009 19:27:11 GMT

Project Description

UPDATE: Release 2.6 beta released 29 August 2009 with source code - see Release 2.6 beta page for release notes. Note also that this has now become the default release - previous reviews and download stats can be found under the 1.1 release.

The SharePoint Content Deployment Wizard is a tool for SharePoint 2007 which provides the means to deploy the following content:

- site collections
- webs
- lists
- folders
- list items (including files)

Content is exported using the Content Migration API (PRIME) as a .cmp file (Content Migration Package) which can be copied to other servers for import. Unlike the out-of-the-box tools, the Wizard allows *granular* selection of content via a treeview.

The two screenshots which probably illustrate the concept of the tool best are:

Export selection screen:

Import settings screen:

N.B. The import operation overwrites your site data, always take a backup before importing.

More details (taken from readme)

Usage notes

The tool must be installed locally on the server which hosts the site
Site URL - enter using format http://source.test.dev
Import web URL - enter using format http://target.com/targetweb
See 'permissions' note lower down

Import/Export characteristics

Since the Content Migration API is used, imports/exports have the following characteristics:

dependencies of selected content (e.g. referenced CSS files, master pages) are automatically included in the export - check 'Exclude dependencies of selected objects' to disable this
all required content types, columns etc. are automatically included in the export
in contrast to STSADM export, it is possible to retain GUIDs during deployment (where objects are not being reparented) - check 'Retain object IDs and locations' to enable this
no filesystem files (assemblies, SharePoint Solutions/Features etc.) are deployed - these must already be present on the target for the import to succeed)
the following content does not get captured by the Content Migration API - alerts, audit trail, change log history, recycle-bin items, workflow tasks/state

Updated Wiki: Home

chrisobrien — Sun, 16 Aug 2009 17:49:01 GMT

Project Description

UPDATE: Release 2.5 beta released 16 August 2009 with source code - see Release 2.5 beta page for release notes. Note also that this has now become the default release - previous reviews and download stats can be found under the 1.1 release.

The SharePoint Content Deployment Wizard is a tool for SharePoint 2007 which provides the means to deploy the following content:

- site collections
- webs
- lists
- folders
- list items (including files)

Content is exported using the Content Migration API (PRIME) as a .cmp file (Content Migration Package) which can be copied to other servers for import. Unlike the out-of-the-box tools, the Wizard allows *granular* selection of content via a treeview.

The two screenshots which probably illustrate the concept of the tool best are:

Export selection screen:

Import settings screen:

N.B. The import operation overwrites your site data, always take a backup before importing.

More details (taken from readme)

Usage notes

The tool must be installed locally on the server which hosts the site
Site URL - enter using format http://source.test.dev
Import web URL - enter using format http://target.com/targetweb
See 'permissions' note lower down

Import/Export characteristics

Since the Content Migration API is used, imports/exports have the following characteristics:

dependencies of selected content (e.g. referenced CSS files, master pages) are automatically included in the export - check 'Exclude dependencies of selected objects' to disable this
all required content types, columns etc. are automatically included in the export
in contrast to STSADM export, it is possible to retain GUIDs during deployment (where objects are not being reparented) - check 'Retain object IDs and locations' to enable this
no filesystem files (assemblies, SharePoint Solutions/Features etc.) are deployed - these must already be present on the target for the import to succeed)
the following content does not get captured by the Content Migration API - alerts, audit trail, change log history, recycle-bin items, workflow tasks/state

Updated Wiki: Home

chrisobrien — Sun, 29 Mar 2009 15:50:56 GMT

Project Description

UPDATE: Release 2.0 beta released 25 March 2009 with source code - see Release 2.0 beta page for release notes. This is not the default release since it's in beta, so you need to use this link to download this version.

The SharePoint Content Deployment Wizard is a tool for SharePoint 2007 which provides the means to deploy the following content:

- site collections
- webs
- lists
- folders
- list items (including files)

Content is exported using the Content Migration API (PRIME) as a .cmp file (Content Migration Package) which can be copied to other servers for import. Unlike the out-of-the-box tools, the Wizard allows *granular* selection of content via a treeview.

The two screenshots which probably illustrate the concept of the tool best are:

Export selection screen:

Import settings screen:

N.B. The import operation overwrites your site data, always take a backup before importing.

More details (taken from readme)

Usage notes

The tool must be installed locally on the server which hosts the site
Site URL - enter using format http://source.test.dev
Import web URL - enter using format http://target.com/targetweb
See 'permissions' note lower down

Import/Export characteristics

Since the Content Migration API is used, imports/exports have the following characteristics:

dependencies of selected content (e.g. referenced CSS files, master pages) are automatically included in the export - check 'Exclude dependencies of selected objects' to disable this
all required content types, columns etc. are automatically included in the export
in contrast to STSADM export, it is possible to retain GUIDs during deployment (where objects are not being reparented) - check 'Retain object IDs and locations' to enable this
no filesystem files (assemblies, SharePoint Solutions/Features etc.) are deployed - these must already be present on the target for the import to succeed)
the following content does not get captured by the Content Migration API - alerts, audit trail, change log history, recycle-bin items, workflow tasks/state

Updated Wiki: Home

chrisobrien — Sun, 29 Mar 2009 15:48:50 GMT

Project Description

UPDATE: Release 2.0 beta released 25 March 2009 with source code - see Release 2.0 beta page for release notes. This is not the default release since it's in beta, so you need to use the link above to download this version.

The SharePoint Content Deployment Wizard is a tool for SharePoint 2007 which provides the means to deploy the following content:

- site collections
- webs
- lists
- folders
- list items (including files)

Content is exported using the Content Migration API (PRIME) as a .cmp file (Content Migration Package) which can be copied to other servers for import. Unlike the out-of-the-box tools, the Wizard allows *granular* selection of content via a treeview.

The two screenshots which probably illustrate the concept of the tool best are:

Export selection screen:

Import settings screen:

N.B. The import operation overwrites your site data, always take a backup before importing.

More details (taken from readme)

Usage notes

The tool must be installed locally on the server which hosts the site
Site URL - enter using format http://source.test.dev
Import web URL - enter using format http://target.com/targetweb
See 'permissions' note lower down

Import/Export characteristics

Since the Content Migration API is used, imports/exports have the following characteristics:

dependencies of selected content (e.g. referenced CSS files, master pages) are automatically included in the export - check 'Exclude dependencies of selected objects' to disable this
all required content types, columns etc. are automatically included in the export
in contrast to STSADM export, it is possible to retain GUIDs during deployment (where objects are not being reparented) - check 'Retain object IDs and locations' to enable this
no filesystem files (assemblies, SharePoint Solutions/Features etc.) are deployed - these must already be present on the target for the import to succeed)
the following content does not get captured by the Content Migration API - alerts, audit trail, change log history, recycle-bin items, workflow tasks/state

Updated Wiki: Home

chrisobrien — Sun, 21 Sep 2008 23:38:49 GMT

Project Description

UPDATE: Release 1.1 version released 22 September 2008 with source code - see Release 1.1 page for release notes

The SharePoint Content Deployment Wizard is a tool for SharePoint 2007 which provides the means to deploy the following content:

- site collections
- webs
- lists
- folders
- list items (including files)

Content is exported using the Content Migration API (PRIME) as a .cmp file (Content Migration Package) which can be copied to other servers for import. Unlike the out-of-the-box tools, the Wizard allows *granular* selection of content via a treeview.

The two screenshots which probably illustrate the concept of the tool best are:

Export selection screen:

Import settings screen:

N.B. The import operation overwrites your site data, always take a backup before importing.

More details (taken from readme)

Usage notes

The tool must be installed locally on the server which hosts the site
Site URL - enter using format http://source.test.dev
Import web URL - enter using format http://target.com/targetweb
See 'permissions' note lower down

Import/Export characteristics

Since the Content Migration API is used, imports/exports have the following characteristics:

dependencies of selected content (e.g. referenced CSS files, master pages) are automatically included in the export - check 'Exclude dependencies of selected objects' to disable this
all required content types, columns etc. are automatically included in the export
in contrast to STSADM export, it is possible to retain GUIDs during deployment (where objects are not being reparented) - check 'Retain object IDs and locations' to enable this
no filesystem files (assemblies, SharePoint Solutions/Features etc.) are deployed - these must already be present on the target for the import to succeed)
the following content does not get captured by the Content Migration API - alerts, audit trail, change log history, recycle-bin items, workflow tasks/state

Updated Wiki: Home

jwanageladmin — Wed, 17 Sep 2008 21:03:54 GMT

Attention Project Owner,

We have been informed by CodePlex users that your project does not meet the CodePlex project hosting requirements. To be hosted on CodePlex, the source code to your project must be included. We have unpublished your project in order for you to post the source code. After doing so, you may republish your project.

Please contact us with any questions.

Thank you,
CodePlex Administration

Project Description

UPDATE: Release 1.0 version released 22 June 2008 - see Release 1.0 page for release notes

The SharePoint Content Deployment Wizard is a tool for SharePoint 2007 which provides the means to deploy the following content:

- site collections
- webs
- lists
- folders
- list items (including files)

Content is exported using the Content Migration API (PRIME) as a .cmp file (Content Migration Package) which can be copied to other servers for import. Unlike the out-of-the-box tools, the Wizard allows *granular* selection of content via a treeview.

The two screenshots which probably illustrate the concept of the tool best are:

Export selection screen:

Import settings screen:

N.B. The import operation overwrites your site data, always take a backup before importing.

More details (taken from readme)

Usage notes

The tool must be installed locally on the server which hosts the site
Site URL - enter using format http://source.test.dev
Import web URL - enter using format http://target.com/targetweb
See 'permissions' note lower down

Import/Export characteristics

Since the Content Migration API is used, imports/exports have the following characteristics:

dependencies of selected content (e.g. referenced CSS files, master pages) are automatically included in the export - check 'Exclude dependencies of selected objects' to disable this
all required content types, columns etc. are automatically included in the export
in contrast to STSADM export, it is possible to retain GUIDs during deployment (where objects are not being reparented) - check 'Retain object IDs and locations' to enable this
no filesystem files (assemblies, SharePoint Solutions/Features etc.) are deployed - these must already be present on the target for the import to succeed)
the following content does not get captured by the Content Migration API - alerts, audit trail, change log history, recycle-bin items, workflow tasks/state

Updated Wiki: Home

chrisobrien — Sun, 22 Jun 2008 19:39:23 GMT

Project Description

UPDATE: Release 1.0 version released 22 June 2008 - see Release 1.0 page for release notes

The SharePoint Content Deployment Wizard is a tool for SharePoint 2007 which provides the means to deploy the following content:

- site collections
- webs
- lists
- folders
- list items (including files)

Content is exported using the Content Migration API (PRIME) as a .cmp file (Content Migration Package) which can be copied to other servers for import. Unlike the out-of-the-box tools, the Wizard allows *granular* selection of content via a treeview.

The two screenshots which probably illustrate the concept of the tool best are:

Export selection screen:

Import settings screen:

N.B. The import operation overwrites your site data, always take a backup before importing.

More details (taken from readme)

Usage notes

The tool must be installed locally on the server which hosts the site
Site URL - enter using format http://source.test.dev
Import web URL - enter using format http://target.com/targetweb
See 'permissions' note lower down

Import/Export characteristics

Since the Content Migration API is used, imports/exports have the following characteristics:

dependencies of selected content (e.g. referenced CSS files, master pages) are automatically included in the export - check 'Exclude dependencies of selected objects' to disable this
all required content types, columns etc. are automatically included in the export
in contrast to STSADM export, it is possible to retain GUIDs during deployment (where objects are not being reparented) - check 'Retain object IDs and locations' to enable this
no filesystem files (assemblies, SharePoint Solutions/Features etc.) are deployed - these must already be present on the target for the import to succeed)
the following content does not get captured by the Content Migration API - alerts, audit trail, change log history, recycle-bin items, workflow tasks/state

Updated Wiki: Home

chrisobrien — Sun, 22 Jun 2008 19:30:51 GMT

The tool must be installed locally on the server which hosts the site
Site URL - enter using format http://source.test.dev
Import web URL - enter using format http://target.com/targetweb
See 'permissions' note lower down

Import/Export characteristics

Since the Content Migration API is used, imports/exports have the following characteristics:

dependencies of selected content (e.g. referenced CSS files, master pages) are automatically included in the export - check 'Exclude dependencies of selected objects' to disable this
all required content types, columns etc. are automatically included in the export
in contrast to STSADM export, it is possible to retain GUIDs during deployment (where objects are not being reparented) - check 'Retain object IDs and locations' to enable this
no filesystem files (assemblies, SharePoint Solutions/Features etc.) are deployed - these must already be present on the target for the import to succeed)
the following content does not get captured by the Content Migration API - alerts, audit trail, change log history, recycle-bin items, workflow tasks/state

Reparenting

Reparenting of objects such as webs and lists is possible with the following usage on the import:

- enter the URL for the target web in the 'Import web URL' textbox
- ensure 'Retain object IDs and locations' is not checked

Permissions

The Content Migration API (PRIME) is used to package the content as a .cmp file, which can be copied to another
server for import. The application MUST be run from the SharePoint server(s), and MUST be run under the context
of an account which has appropriate SharePoint permissions - currently the way to specify an alternative user
to the currently-logged on user is by using the 'Run as..' feature in Windows 2003 (right-click on the .exe and
select 'Run as..').

See my blog post 'Introducing the SharePoint Content Deployment Wizard' for more screenshots and information - http://sharepointnutsandbolts.blogspot.com/2007/12/introducing-sharepoint-content.html

Chris O'Brien
http://feeds.feedburner.com/ChrisObrien

UPDATED WIKI: Home

chrisobrien — Mon, 03 Mar 2008 15:26:27 GMT

Project Description

UPDATE: beta 2 version released 28 Feb 2008 - see beta 2 page for release notes

The SharePoint Content Deployment Wizard is a tool for SharePoint 2007 which provides the means to deploy the following content:

- site collections
- webs
- lists
- folders
- list items (including files)

Content is exported using the Content Migration API (PRIME) as a .cmp file (Content Migration Package) which can be copied to other servers for import. Unlike the out-of-the-box tools, the Wizard allows *granular* selection of content via a treeview.

The two screenshots which probably illustrate the concept of the tool best are:

Export selection screen:

Import settings screen:

N.B. In this beta version, not all possible deployment scenarios have been tested. Please take a backup before performing imports.

More details (taken from readme)

Usage notes

The tool must be installed locally on the server which hosts the site
Site URL - enter using format http://source.test.dev
Import web URL - enter using format http://target.com/targetweb
See 'permissions' note lower down

Import/Export characteristics

Since the Content Migration API is used, imports/exports have the following characteristics:

dependencies of selected content (e.g. referenced CSS files, master pages) are automatically included in the export - check 'Exclude dependencies of selected objects' to disable this
all required content types, columns etc. are automatically included in the export
in contrast to STSADM export, it is possible to retain GUIDs during deployment (where objects are not being reparented) - check 'Retain object IDs and locations' to enable this
no filesystem files (assemblies, SharePoint Solutions/Features etc.) are deployed - these must already be present on the target for the import to succeed)
the following content does not get captured by the Content Migration API - alerts, audit trail, change log history, recycle-bin items, workflow tasks/state

Reparenting

Reparenting of objects such as webs and lists is possible with the following usage on the import:

- enter the URL for the target web in the 'Import web URL' textbox
- ensure 'Retain object IDs and locations' is not checked

Permissions

The Content Migration API (PRIME) is used to package the content as a .cmp file, which can be copied to another
server for import. The application MUST be run from the SharePoint server(s), and MUST be run under the context
of an account which has appropriate SharePoint permissions - currently the way to specify an alternative user
to the currently-logged on user is by using the 'Run as..' feature in Windows 2003 (right-click on the .exe and
select 'Run as..').

See my blog post 'Introducing the SharePoint Content Deployment Wizard' for more screenshots and information - http://sharepointnutsandbolts.blogspot.com/2007/12/introducing-sharepoint-content.html

Chris O'Brien
http://feeds.feedburner.com/ChrisObrien

UPDATED WIKI: Home

chrisobrien — Mon, 03 Mar 2008 15:24:46 GMT

Project Description

+ UPDATE: beta 2 version released 28 Feb 2008 - see http://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=SPDeploymentWizard&ReleaseId=11148 for release notes +

The SharePoint Content Deployment Wizard is a tool for SharePoint 2007 which provides the means to deploy the following content:

- site collections
- webs
- lists
- folders
- list items (including files)

Content is exported using the Content Migration API (PRIME) as a .cmp file (Content Migration Package) which can be copied to other servers for import. Unlike the out-of-the-box tools, the Wizard allows *granular* selection of content via a treeview.

The two screenshots which probably illustrate the concept of the tool best are:

Export selection screen:

Import settings screen:

N.B. In this beta version, not all possible deployment scenarios have been tested. Please take a backup before performing imports.

More details (taken from readme)

Usage notes

The tool must be installed locally on the server which hosts the site
Site URL - enter using format http://source.test.dev
Import web URL - enter using format http://target.com/targetweb
See 'permissions' note lower down

Import/Export characteristics

Since the Content Migration API is used, imports/exports have the following characteristics:

dependencies of selected content (e.g. referenced CSS files, master pages) are automatically included in the export - check 'Exclude dependencies of selected objects' to disable this
all required content types, columns etc. are automatically included in the export
in contrast to STSADM export, it is possible to retain GUIDs during deployment (where objects are not being reparented) - check 'Retain object IDs and locations' to enable this
no filesystem files (assemblies, SharePoint Solutions/Features etc.) are deployed - these must already be present on the target for the import to succeed)
the following content does not get captured by the Content Migration API - alerts, audit trail, change log history, recycle-bin items, workflow tasks/state

Reparenting

Reparenting of objects such as webs and lists is possible with the following usage on the import:

- enter the URL for the target web in the 'Import web URL' textbox
- ensure 'Retain object IDs and locations' is not checked

Permissions

The Content Migration API (PRIME) is used to package the content as a .cmp file, which can be copied to another
server for import. The application MUST be run from the SharePoint server(s), and MUST be run under the context
of an account which has appropriate SharePoint permissions - currently the way to specify an alternative user
to the currently-logged on user is by using the 'Run as..' feature in Windows 2003 (right-click on the .exe and
select 'Run as..').

See my blog post 'Introducing the SharePoint Content Deployment Wizard' for more screenshots and information - http://sharepointnutsandbolts.blogspot.com/2007/12/introducing-sharepoint-content.html

Chris O'Brien
http://feeds.feedburner.com/ChrisObrien

UPDATED WIKI: Home

chrisobrien — Wed, 05 Dec 2007 15:51:53 GMT

Project Description
The SharePoint Content Deployment Wizard is a tool for SharePoint 2007 which provides the means to deploy the following content:

- site collections
- webs
- lists
- list items (including files)

Content is exporting using the Content Migration API (PRIME) as a .cmp file (Content Migration Package) which can be copied to other servers for import. Unlike the out-of-the-box tools, the Wizard allows *granular* selection of content via a treeview.

The two screenshots which probably illustrate the concept of the tool best are:

Export selection screen:

Import settings screen:

N.B. In this beta version, not all possible deployment scenarios have been tested. Please take a backup before performing imports.

More details (taken from readme)

Usage notes

The tool must be installed locally on the server which hosts the site
Site URL - enter using format http://source.test.dev
Import web URL - enter using format http://target.com/targetweb
See 'permissions' note lower down

Import/Export characteristics

Since the Content Migration API is used, imports/exports have the following characteristics:

dependencies of selected content (e.g. referenced CSS files, master pages) are automatically included in the export - check 'Exclude dependencies of selected objects' to disable this
all required content types, columns etc. are automatically included in the export
in contrast to STSADM export, it is possible to retain GUIDs during deployment (where objects are not being reparented) - check 'Retain object IDs and locations' to enable this
no filesystem files (assemblies, SharePoint Solutions/Features etc.) are deployed - these must already be present on the target for the import to succeed)
the following content does not get captured by the Content Migration API - alerts, audit trail, change log history, recycle-bin items, workflow tasks/state

Reparenting

Reparenting of objects such as webs and lists is possible with the following usage on the import:

- enter the URL for the target web in the 'Import web URL' textbox
- ensure 'Retain object IDs and locations' is not checked

Permissions

The Content Migration API (PRIME) is used to package the content as a .cmp file, which can be copied to another
server for import. The application MUST be run from the SharePoint server(s), and MUST be run under the context
of an account which has appropriate SharePoint permissions - currently the way to specify an alternative user
to the currently-logged on user is by using the 'Run as..' feature in Windows 2003 (right-click on the .exe and
select 'Run as..').

See my blog post 'Introducing the SharePoint Content Deployment Wizard' for more screenshots and information - http://sharepointnutsandbolts.blogspot.com/2007/12/introducing-sharepoint-content.html

Chris O'Brien
http://feeds.feedburner.com/ChrisObrien

UPDATED WIKI: Home

chrisobrien — Wed, 05 Dec 2007 15:50:46 GMT

The tool must be installed locally on the server which hosts the site
Site URL - enter using format http://source.test.dev
Import web URL - enter using format http://target.com/targetweb
See 'permissions' note lower down

Import/Export characteristics

Since the Content Migration API is used, imports/exports have the following characteristics:

dependencies of selected content (e.g. referenced CSS files, master pages) are automatically included in the export - check 'Exclude dependencies of selected objects' to disable this
all required content types, columns etc. are automatically included in the export
in contrast to STSADM export, it is possible to retain GUIDs during deployment (where objects are not being reparented) - check 'Retain object IDs and locations' to enable this
no filesystem files (assemblies, SharePoint Solutions/Features etc.) are deployed - these must already be present on the target for the import to succeed)
the following content does not get captured by the Content Migration API - alerts, audit trail, change log history, recycle-bin items, workflow tasks/state

Reparenting

Reparenting of objects such as webs and lists is possible with the following usage on the import:

- enter the URL for the target web in the 'Import web URL' textbox
- ensure 'Retain object IDs and locations' is not checked

Permissions

The Content Migration API (PRIME) is used to package the content as a .cmp file, which can be copied to another
server for import. The application MUST be run from the SharePoint server(s), and MUST be run under the context
of an account which has appropriate SharePoint permissions - currently the way to specify an alternative user
to the currently-logged on user is by using the 'Run as..' feature in Windows 2003 (right-click on the .exe and
select 'Run as..').

See my blog post 'Introducing the SharePoint Content Deployment Wizard' for more screenshots and information - http://sharepointnutsandbolts.blogspot.com/2007/12/introducing-sharepoint-content.html

Chris O'Brien

NEWS FEED

Part 2 : Blending publishing/collaboration functionality in SharePoint

Sunday, November 25, 2007 | From Chris O'Brien's blog

A couple of months ago I wrote an article on some of the issues around building sites which are not pure publishing or collaboration solutions, but which mix features of the two. I mentioned at the time that I would follow up on these issues and any others we came across at the end of the project, so here it is.

As a quick recap, we said that characteristics of a site which blends publishing/collab features could be:

site has completely bespoke look and feel/navigation

users will work with document libraries, discussions, calendars etc.

site templates or definitions are used to create several sites with the same content/functionality

custom workflow is used to support a business process (other than standard content publishing), perhaps with InfoPath forms

So let's cover some of the issues you may face in projects like this:

Look and feel of system pages

This refers to the fact that whilst pages you create will happily use your custom master page, any 'system' pages in the '_layouts' directory will not share this look and feel by default since they reference a separate master page, 'application.master', which is also stored on the filesystem in '_layouts'. Such pages are often seen due to the use of collaboration functionality in our site, examples being when a user uploads or edits metadata for a file, starts a workflow etc.

In fact this turned out to be less of an issue than I anticipated because:

a quick test showed that the use of a HTTP module to switch the master page of these pages works fine. Several people have documented this approach, and I note that Ted Pattison has provided a Codeplex feature for those who would prefer not to write their own code for this. (N.B. though not strictly supported, the idea behind the HTTP module approach is that it is better than modifying files installed with SharePoint such as 'application.master', and can be disabled with a switch if we need to fall back in line with official support.)
our client decided this was a low priority item, that we may or may not deal with further down the line

On this subject, I see that Microsoft have themselves released KB article How to customize application pages in the Layouts folder in SharePoint Server 2007 and in Windows SharePoint Services 3.0. Bizarrely, the proposed solutions are modifying the standard files but taking backups of the originals, or duplicating the 'layouts' virtual directory in IIS - the HTTP module idea is not mentioned. Without dwelling on this too much, this seems crazy to me and I'm not the only one. I still much prefer the HTTP module solution and will use this on my projects where it is required, though will be sure to regression test thoroughly.

Use of InfoPath with forms authentication

This is an interesting illustration of blending the two types of functionality - collaboration solutions may well use InfoPath for forms, but publishing sites typically use forms auth for a customized/branded login experience. Straight away we ran into problems using InfoPath with forms auth - essentially the link to create a new instance of an InfoPath form in a forms library would disappear (example link shown below [Windows auth enabled here]):

It took a while for me to track down that this is related to the 'Client Integration' switch in Central Admin. For a forms auth site, this gets set to 'off' by default, but defaults to 'on' for windows auth sites. Unfortunately, resolving the problem isn't as simple as flicking the switch back, since what the switch does is remove certain links and disable ActiveX controls which integrate with the browser for link-handling. With the switch enabled again, the InfoPath link reappears on the content type, but when a link to say, a Word document is followed, the browser now shows the basic prompt to download or save the file. This means the more sophisticated 'do you want to check out or open as read-only' prompt is lost and users must work with documents offline and upload to SharePoint at the end of editing, rather than being able to save back directly to the SharePoint repository. In other words, unacceptable to most for a SharePoint 2007 collaboration solution.

In the end I found others in the same position, but didn't find a solution in a short timeframe. Microsoft support tells me "they were unaware of any instances of of these two features working together in this way", so the disappointing conclusion is that these two bits of functionality don't play well together. Our client thus decided to accept windows authentication (our authentication store was always going to be AD rather than SQL anyhow). However, I'm actually convinced it would be possible to get this working given more time - I think the way forward would be to amend the site design to have a link to the InfoPath form in the standard content of a page rather than relying on SharePoint to supply the link. The information supplied in How to: Use Query Parameters to Invoke Browser-Enabled InfoPath Forms would be used here. I'm sure this must be possible and others have done it, I'd be interested to hear from anyone who has.

Overidden control not appearing on standard collaboration pages

Our client had requested some customizations to the search box, and going through our bug list towards the end of development, I realised that our customized version was present on pages we had created, but not existing list pages such as [MyList]/Forms/AllItems.aspx or similar. This seemed strange given that all pages were using our custom master and shared the same header! Digging deeper, this is caused by the fact that SharePoint uses a delegate control to load the search box .ascx file, and to properly override the control across the site, we needed to create a Feature to specify that our .ascx file should be used in preference to the standard control. If we had directly replaced the existing control on the filesystem this would not be required, but when adding custom files in order to avoid modifications to existing files, this extra piece is required. One to look out for when building sites of this nature.

Summary

I read some blogs/discussion threads earlier this week which suggest customizing SharePoint in this way is nigh on impossible, but our project (and surely many others) prove this isn't the case. As is often the case with such a functional platform, there's perhaps a greater chance of success if you understand the nuts and bolts of what SharePoint is doing, but extensive customizations to collaboration-focused sites are inherently possible!

Change a SharePoint site's URL

Sunday, November 11, 2007 | From Chris O'Brien's blog

Something you may find yourself tasked with at some point, is changing the URL of an existing SharePoint 2007 site. This is a fairly interesting scenario, and it's fair to say the relationship between SharePoint and IIS makes this more complex than for a standard .Net site. However, there are several possible solutions. The first things many of us would think of as potential approaches would probably be:

extending the web application onto another URL
using Alternate Access Mappings somehow

Depending on your site both could be valid methods, but as with anything SharePoint-related, there are different things to watch out for with the different approaches. As an example, extending the web application wasn't the right approach for our scenario for the following reasons:

the site shouldn't actually exist at the old URL, but a redirect was required
InfoPath forms don't seem to deal well with the 'extended web application' configuration. (Problem detail - on one URL everything will be fine, but if the two web applications use separate site collections, on the other you're likely to see security errors when opening forms. This is because the form templates are referenced in the other site collection - a document library can only have one URL to the document template, and publishing a form to a content type stores an absolute link in the content database.)

Additionally some quick tests with Alternate Access Mappings didn't seem to give the expected results for me, so I decided on another approach since I knew it would work and didn't have much time for experimentation. So this was my process:

Changing a site's URL by recreating the site (downtime required)

Stop old IIS site.
Create new web application in SharePoint, bind to new IP address in IIS.
Apply SSL certificate if appropriate.
Create new site collection for this web application using the blank site template.
Export content using the SharePoint's content migration API (I have a tool which does this, which will shortly be on Codeplex) ensuring all security data is exported. Alternatives to this step include STSADM -O BACKUP and STSADM-O EXPORT. *
Import content into the new site collection, ensuring to include security.
Amend any absolute URLs in .udcx data connection files used by InfoPath.
Republish any InfoPath forms to the new site.
Configure search:

Ensure new URL is a content source.
Update any crawl rules which use absolute URLs.
Update 'authoritative pages' as appropriate.
Start full crawl.
Update scopes.
Go to Site Settings > Site collection administration > Search scopes, add any custom scopes to search dropdown (if using standard search web parts).
Ensure search web parts use relative URLs/do not reference old site URLs.

If a redirect from old URL is required, create new IIS site to implement this:

Create new site in IIS and bind to old IP address.
On 'Home directory' tab, specify content should come from 'A redirection to a URL' and enter the URL.

Ensure DNS/firewalls are configured appropriately for new URL, remembering to allow appropriate time for DNS propagation.
Perform testing.

* N.B. Between the content migration API and STSADM export, I prefer the former since this allows control over whether object GUIDs are retained (more information in STSADM export, Content Deployment, Content Migration API, Features/Solutions - deployment options compared). STSADM backup/restore is discussed in next section.

Considerations to this approach

When using the content migration API or STSADM backup/restore, the following items are not included - alerts, workflows, recycle bin state or site collection properties. These must be migrated/recreated separately.
Regression testing is absolutely required since the site is effectively recreated

As a way to improve on the first consideration, another option would be STSADM backup/restore (though I've not tried this approach). Notably this method does collect data for the items which the other approaches exclude, however due to the nature of our site, none of these were significant problems.

So this method was successful, and hopefully this information allows folks to see some of the pros and cons without having to spend the time going through it themselves. However, I also note an approach based on Alternate Access Mappings suggested by Faraz Khan. Since this was only published in the few days before this article it was too late for my scenario, though I'd encourage you to take a look. Note that Faraz also points out considerations such as certain links not being updated to new URL without fix-ups, though this doesn't seem to be a major issue. It does echo my point about there being different things to watch out for with the different approaches, but both methods provide valid techniques for changing a SharePoint site's URL.

Master pages/page layouts deployed as Feature not updating

Thursday, November 01, 2007 | From Chris O'Brien's blog

Since Deploying master pages and page layouts as a Feature has been the most heavily commented article on this blog, and several of the posters seem to have run into the same problem, I wanted to write a quick post with some more information from my experiences on this.

So this is something of a non-standard post, feel free to tune out if it doesn't affect you ;-)

Anyway, I decided to do some more testing to see if either I'd got something wrong or if perhaps I was doing something differently to the people having problems. My test was basically to knock up a publishing site with a master page and page layout (associated with a custom content type as it often would be), then go through the update process. This is what I found:

making updates to the files (outside of the 12 folder) and then XCOPYing these to overwrite the files in the 12\TEMPLATE\features\MyFeature\ directory successfully updated the site. No need to deactivate/activate the Feature.
using a Solution package to deploy the files (when using Features this is generally what I do since I'm in a farm environment) - again this updated the site correctly when I upgrade the Solution (stsadm -o upgradesolution). This is to be expected since underneath the exact same thing is happening as in the previous test. (However, I also noticed occasionally the directory would complete disappear even after the solution upgrade had completed, or was there but still locked by another process, meaning the files could not be accessed even in Windows Explorer - this is slightly irritating but running the Solution upgrade again always succeeded.)
after causing the file to be customized (e.g. modifying or even just checking out with SPD), any subsequent updates to the files via the Feature/Solution did not appear on the site (though further updates in SPD are fine).

In short, this is all what I expected. Assuming the file has not been customized, anything which updates the copy on the filesystem will cause an update to the site. If it has been customized, updates on the filesystem will not (since the file has now been added to the content database, and the filesystem version is no longer used). If you've not come across this before, Considerations when using Features to deploy SharePoint files - ghosting/unghosting may help.

So, I'm guessing that if your master pages etc. are not updating when you overwrite the Feature files, it's because the files have become customized somehow. Unfortunately it's not so easy to tell for publishing files - for other files, SharePoint Designer provides a handy blue dot next to the file in it's Explorer view if the file is customized, but alas this doesn't happen for master pages/page layouts. The blue dot can be seen next to the AllItems.aspx file below (click to enlarge):

Unfortunately this also means reverting to the file on the filesystem is not straightforward either (we can't right-click the file in SPD and select 'Reset to site definition' as we can with other SharePoint files). So this can be a pain if you do want to keep your page layouts referenced from the filesystem (e.g. because performance is critical), but you've ended up in this state. It is possible to revert the files using the API though. I've not needed to do this myself, but the property to check is SPFile.CustomizedPageStatus and if this returns SPCustomizedPageStatus.Customized, then the SPFile.RevertContentStream() method can be used - this should cause SharePoint to henceforth use the version on the filesystem (though note you may lose some updates which had been made after the file was unghosted (customized) - you will need to re-apply these to the filesystem file after the reversion. And remember, don't use SPD for this or you'll be back where you started!)

So far, so (reasonably) straightforward.

However, one poster (deelpunt) had an interesting question about updating page layouts with web parts. As far as I can see, updating all page instances to have web parts in web part zones by updating the layouts will not be possible. This is because if web part zones are used, the web part is associated with the page instance rather than the page layout. Indeed, this can be the power of the architecture. It is possible to either:

have default web parts added to a zone when a page instance is created from a page layout. This can be done by deploying the page layout using a Feature, and using the AllUsersWebPart tag. This would not affect pages already created however.
add web parts to all the pages by adding them directly to the page markup in SPD, rather than in a zone. Of course, this then means the settings for the web part can only be modified by the page designer in SPD, rather than site users.
use the API to iterate through all pages in the site to add/modify webparts using SPFile.GetLimitedWebPartManager(). Needless to say, this is the kind of operation which requires a lot of care and planning in production!

As I've mentioned before, because of these issues the web part zone architecture is often not the best choice for scenarios such as WCM site development, since here we want our changes to apply across all pages which use the layout.

Hopefully this has been of some use. As always, leave a comment if you've had different experiences to those detailed here, I'd definitely be interested to hear.

[I also wanted to say sincere apologies to the commenters on the original post (and any others I've been slow in replying to) that it took a couple of weeks for me to come back. Something to do with my project going live and moving house at the same time, hopefully normal service now resumed ;-) ]

STSADM export, Content Deployment, Content Migration API, Features/Solutions - deployment options compared

Monday, October 29, 2007 | From Chris O'Brien's blog

Back in May I wrote a post titled SharePoint deployment options : Features or Content Deployment?, which discussed some thoughts on what was the "right" way to move assets from development to production (and perhaps environments in between) during the site development process in SharePoint. Having now worked on other projects and consciously used different deployment methods on each, I'm rapidly coming to the conclusion that the "right" way to do deployment varies according to circumstances. So I thought what might be useful is an analysis of the whole range of deployment options, with information which might help you decide more easily on how you will complete this crucial step of the process.

So let's run through the options and their characteristics. Note by the way, that none of the options use 'destructive synchronization', where all content is first deleted before import.

Using STSADM export/import

Description:

Uses STSADM commands to generate a file (export) which can then be transferred to the target for import. One of the simplest ways of moving content from one place to another, although unlikely to be suitable as a continuous deployment mechanism. Examples:

stsadm.exe -o export -url http://localhost -filename C:\Export.cab -includeusersecurity -versions 4 -overwrite

stsadm.exe -o import -url http://localhost/sites/newsite -filename C:\Export.cab -includeusersecurity

Good for:

Moving an entire site/web as a one off
Quick deployment tests
Reparenting webs (can be into a different site collection)

Considerations:

Content on target will be overwritten if already exists
Granularity down to web only
Object GUIDs are not preserved (so some things will need to be 'fixed up' e.g. anything that references a list by GUID - ListViewWebPart, using lists with InfoPath forms)
Not a backup/restore tool - although it's the option which is most like backup/restore, things like alerts, audit trail, recycle bin items, security state, workflow tasks/state are not exported
Not transactional

Using Content Deployment via Central Admin *

Description:

Configured via 'Content Deployment paths and jobs' in Central Admin ('/_admin/deployment.aspx'). A path defines the source/target and authentication details, specific jobs define exactly which content should be deployed and how often. Quick deploy functionality allows users with permissions to specify important content which should be deployed more regularly than existing job schedules configured by administrators (quick deploy items are deployed every 15 mins).

Good for:

Moving entire site collections/webs on a scheduled basis e.g. in an authoring/production or authoring/staging/production topology
Deploying only incremental changes, e-mail notifications of success/failures
Allowing site owners to have some control over content deployment via Quick Deploy
Automatically deploying dependencies of content selected for deployment, even if in different site (e.g. page layouts/content types/site columns/referenced images etc.)
Automatically transferring the deployment package to the target environment (via HTTP[S])
Not transactional

Considerations:

Content on target will be overwritten if already exists
Granularity down to web only
No differentiation between site content (e.g. pages/images) and site 'infrastructure' (e.g. master pages, page layouts)
Object GUIDs are preserved
Blank site template should be used for source and destination (see http://support.microsoft.com/kb/923592)
Also not a backup/restore tool (see above)

Using the content migration API *

Involves writing code which uses the content migration API (known as PRIME) to export then import content - the API is easy to use.

Good for:

Complete flexibility over deployment options
Granular control over what gets deployed (down to item level)
Ability to preserve object GUIDs (so that list GUIDs do not need to fixed-up)
Ability to select options for security, versioning and user roles

Considerations:

Blank site template should be used for source and destination (see http://support.microsoft.com/kb/923592)
Not transactional
Also not a backup/restore tool (see above)
Need development skills to write code

Using Features/Solutions

The focus of this blog for several articles. Involves defining XML configuration files which SharePoint uses to add artifacts in the correct way on the target. This can be significantly more complex than simply developing in SharePoint Designer but can allow for better management throughout a solution's lifecycle.

Good for:

Iterative development/deployment
Deployment of assemblies and filesystem files (none of the other methods deal with this)
Ability to deploy assemblies/filesystem files to all servers in a farm with Solution packages
Possibilities for continuous integration

Considerations:

Developer is responsible for evaluating and deploying dependencies (e.g. underlying content types).
Updates to content types, list definitions, site columns etc. deployed via a Feature must be done with the API - modifying original Feature files and then reprovisioning is not supported
Can be very time-consuming due to lack of assistance from current tools

* Some additional notes on using Content Deployment or content migration APIs:

- appropriate Features will automatically be activated on the target, but they must be present (i.e. installed) for content deployment to work (N.B. publishing feature should not be enabled on target for first deployment)

- using Content Deployment or content migration API with RetainObjectIdentity option should not be combined with STSADM -export/import, since the latter will allocate new IDs!

So clearly there can be a few aspects to consider in choosing how to go about deployment for your project. In many scenarios where Features/Solutions aren't the most appropriate option, I favor using the content migration API, mainly due to the flexibility which isn't provided in any of the other options. Of course it does mean writing code, but as I mentioned last time, I'll soon share the mini-app I wrote so you don't have to!

Some useful references:

Tyler Butler's Content Deployment overview

Stefan's series of articles on the content migration API

How to use Features to deploy master pages/page layouts, web parts, content types

Deployment using STSADM export or content migration API

Sunday, October 14, 2007 | From Chris O'Brien's blog

Having focused on deployment using Features for several articles, back in May I wrote an article titled SharePoint deployment options : Features or Content Deployment?, which explored some of the decisions around deployment strategies for SharePoint projects. There are a variety of methods which can be used to move SharePoint artifacts and content from one place to another, and I think it's fair to say there's still a certain amount of confusion around deployment for many SharePoint developers. I certainly wouldn't claim to have all the answers, but after delivering another project last week, it seems like a good time to go over some of the experiences and reflect on the different approaches.

Needless to say, as far as deployment strategies go in general, the best idea is to have one! I see many newsgroup posts from people approaching the end of the development phase asking how they should move their work to the live servers. The problem I find with leaving deployment until the end of the project, is that none of the approaches are completely straightforward (particularly depending on what your solution consists of), and so if your project is to be delivered on time, it's important to know what steps you might need to go through.

As a sidenote, let's clarify some potentially confusing terminology here:

Content Deployment - the "paths and jobs" functionality which can be used to move content, surfaced by screens in Central Admin
Content Migration API - the underlying API (sometimes referred to as PRIME) which actually is used for both STSADM export and Content Deployment (in slightly different ways), in addition to the 'Manage Content and Structure' tool and in migrations from CMS2002

This time round I had decided to use the content migration API to deploy our solution, and it worked well for our circumstances. This is a contrast to developing with Features which I've done in the past, and the main reasons for choosing this approach were:

no need for iterative deployment - although our overall project is phased, for this component we were able to develop the solution and then deploy everything from our development environment. (This approach will not work for subsequent deployments since content our client has generated on the live site would be overwritten on each deployment - more on this in an upcoming post.)
ability to retain object GUIDs - this simplified deployment significantly for our project, since if our lists were allocated new GUIDs on deployment (as happens with STSADM export/import), our components which referenced these lists (ListViewWebPart, InfoPath forms etc.) would not hook up properly on the deployment target. This would add a lot of "fix-up" steps to the deployment process if we were to use STSADM export.
no direct HTTP access from source Central Admin to target Central Admin - this is a prerequisite to use the Content Deployment functionality (paths and jobs) in Central Admin, but what we needed was a file we could copy to the live server. The content migration API provides this ability and also gives a compression option for large amounts of data.
automatic inclusion of database dependencies - as with STSADM export, (but not with Features), SharePoint will analyze and collect all dependencies such as fields, content types, master pages etc. for us.

The API is fairly simple to use and you may have seen Stefan's series of excellent articles on the subject - these serve as a good companion to the MSDN documentation.

It's important to remember that any non-database assets (e.g. user controls, assemblies etc.) need to be deployed manually to the target environment - these will not be included by use of something like STSADM export or the content migration API. In our case, since the live environment was a single server (and versioning would be handled by our main source control system), these were deployed by XCOPY since deployment using Solution packages did not offer any compelling advantages here.

Whilst we're talking about filesystem files, it's useful to be aware that if you see 404 errors on the target after performing (e.g.) an STSADM import, chances are you've forgotten to deploy something like a user control. The 404 is actually coming from the referenced file rather than the actual page, so don't assume something has gone wrong with the import - a check on 'View all site content' and the import log will probably confirm all the site pages are present!

Hopefully this has given some food for thought on an approach you may not have considered. I guess my main message here is that whilst STSADM export is extremely simple, it may not provide the complete answer to all your deployment challenges due to changing GUIDs. In upcoming posts I'll provide a more direct comparison of deployment strategies (extending my 'Features or content deployment' post), and also share my mini-app which provides a front-end onto the content migration API.

[P.S. Sincere apologies to people who left comments whilst I was on holiday which are still not published - I'll publish these and respond over the next few days.

C.]

Annual holiday

Wednesday, September 12, 2007 | From Chris O'Brien's blog

Just a note to regular readers to say it's time for my annual holiday, so no posts or replies to comments for 2 or 3 weeks. I'm off to San Francisco (which is where Suzanne is from), so it should be a nice break. I am taking a SharePoint virtual machine, but am under strict instructions the only times I'm allowed to use it are on the plane journeys! Fine by me actually.

More posts when I get back..

Blending publishing/collaboration functionality in SharePoint

Sunday, September 09, 2007 | From Chris O'Brien's blog

Most often when creating SharePoint solutions, the requirements often map fairly well to one of the out-of-the-box site definitions which can be used to create new sites. If we're creating heavily-branded internet/intranet sites (WCM sites), we'll probably start with the 'publishing site' template. If we are deploying SharePoint in a document management/collaboration scenario, we'll probably start with the 'team site' template, and so on. Where it gets interesting it when the project requirements effectively have a mix of this functionality. Characteristics of such a site might include:

site has completely bespoke look and feel/navigation
users will work with files stored in document libraries
site templates or definitions are used to create several sites with the same content/functionality
custom workflow is used to support a business process (other than standard content publishing), perhaps with InfoPath forms

Such requirements present a few challenges, and a current project of mine fits into this category. At a high level, one consideration is that site users will also use 'system' pages provided by SharePoint in many scenarios (e.g. working with document libraries/lists, workflow etc.) and this doesn't happen in most WCM sites. This can lead to situations where there is a disparity between the look and feel of the 'published view' of the website and the 'system' areas. I don't intend to provide answers to all the issues here, but I do want to discuss a few as some food for thought. I'll probably revisit this post at the end of the project and provide a better insight into the issues and solutions, but for now let's cover some high-level decisions:

Approach for master page development

Options for starting development here include:

Using a 'minimal master page' from MSDN or Heather Solomon
Modifying a copy of default.master (good starting point for customized team sites)
Modifying a copy of blueband.master (good starting point for WCM sites)

Partly this decision depends on where you are heading. Since the aim in my project is for formatting to be controlled by CSS rather than layout tables, starting with a minimal master page makes more sense (the shipped page layouts use tables). This is an interesting area since there's a lot of rework to be done to eliminate tables in a mixed publishing/collab site (and in fact it often won't be possible to eliminate them completely), and for me the benefit is debatable. Certainly all the 'system' pages which site users will be exposed to use layout tables, so I'm not sure how much is gained by only having some pages using CSS for layout.

Other things to consider here are the usual questions of how to factor responsibility of content items between the master page and page layouts, how to define content types etc., but these are standard decisions in WCM site development so I won't cover them here.

Use of Content Editor web parts vs publishing RichHtmlField controls

Most folks in WCM development know there is an overlap in functionality provided by the Content Editor web part and the RichHtmlField control in the Microsoft.SharePoint.Publishing.WebControls namespace, i.e. they can both be used to enter page content such as text/images. However it's important to consider the differences - the RichHtmlField control stores it's content in a column of the list item for the page, whereas the CEWP is a web part and thus stores content in the web part storage architecture. This is important, since if deployment to a different environment is in your project plan or ongoing architecture, things will likely be simpler if you use the field control, since this content will then travel with the page properly.

Additionally, there are some URL fix-up issues with using the CEWP across different environments, as documented in the HawaiianAir.com write up.

In summary, I'd recommend considering the CEWP as a means of entering content in non-publishing SharePoint sites only.

Use of collaboration web parts - in layouts or in WebPartZones?

In a similar vein, since we are mixing the collaboration features into our site we are likely to need to use certain web parts which we wouldn't in a straight WCM site. In our situation the ListViewWebPart is fairly key to some areas, and is used as a means of allowing users to work with different lists from one page. The first decision here is whether the page layouts should include web parts directly (by adding them in SharePoint Designer), or just web part zones to which the individual parts would be added later through the browser. In most WCM scenarios I prefer to add web parts directly to page layouts since they will not be customized/personalized by end users (the main usage scenario for web part zones), and when web part zones are used, again the web part config is not stored in the page which can make deployment more complex. Using the other approach of adding directly from SPD, config is stored in the actual HTML markup of the page and so travels with the page layout itself.

However! The ListViewWebPart has some quirks which means it isn't always possible to use directly from the page layout. Specifically, it is only possible to configure the part to consume a list from the current web, and in the case of a publishing page layout, this means the root web since this is where the master page gallery is stored. Since our lists are stored in a child web, this is problematic - the other solution of using a DataView also had issues. Additionally, the ListViewWebPart configuration stores values specific to it's location, meaning the config XML is not very portable (i.e. export web part definition, modify, use). I'd like to think it would be possible with time to work out exactly which IDs do need to be changed, but alas we don't have time on this project.

As a result, using the ListViewWebPart in a web part zone is actually the best solution in these circumstances as far as I can see. We'll have an extra few steps at deployment, but this will take less time than the alternatives it appears.

Look and feel of system pages

As mentioned earlier, for a mixed WCM/collaboration site there can be a disparity of the look and feel of the main pages of the site and the 'system' pages users will see, i.e. pages from the '_layouts' directory. Note this happens even if both the site and system master page is set to point at your custom master page, since these pages are set to use 'application.master' (also on the filesystem in '_layouts') which neither of these properties affect. Sure it would be possible to simply replace 'application.master' with your own version, but that's not an elegant solution and would probably be unsupported. Unfortunately it seems that the architecture doesn't provide an easy way to change the master page used by '_layouts' pages - you have to go a level deeper to explore ways of doing this. Many .Net 2.0 developers will know it's possible to switch a master page dynamically in .Net, and to be fair this is what SharePoint does with the maser pages stored in the master page gallery anyway. I'm not aware of a truly elegant solution to this problem, but this discussion on Serge van den Oever's blog presents a viable approach using this technique.

So those are some of the issues to consider. There are certainly others, including navigation, CSS customization of standard styles (to ensure collaboration web parts integrate well with your look and feel), and possibly the choice of authentication mechanism. I'll cover these and any others which arise in an upcoming post.

VSeWSS 1.1. CTP - a look at the nuts and bolts

Monday, September 03, 2007 | From Chris O'Brien's blog

Regular readers of this blog will know that I've been a reasonably keen advocate of Microsoft's Visual Studio Extensions for Windows SharePoint Services (VSeWSS) for certain SharePoint development tasks. If you read more than a couple of SharePoint blogs, you won't have avoided the news that MS have just released version 1.1 of this tool, as announced here by Alex Malek over on the SharePoint Designer blog. At the time of writing, this is a CTP (Community Technology Preview) meaning it is pre-beta, so bugs can be expected. So today I wanted to run through the changes, so folks who aren't familiar with the tool or haven't had a chance to take a look themselves can quickly get a sense of what's in there.

In essence, VSeWSS helps by simplifying the process of developing Features for SharePoint - this approach is generally regarded as the way to do SharePoint development in such a way that assets can be more easily deployed to other environments. In previous articles, I detailed how to create and deploy lists and how to create and deploy web parts with VSeWSS. For me, these are probably the scenarios where VSeWSS comes in the most useful, though there definitely are others depending on how you work. However, the most common gripe of developers who used the tool was that since VSeWSS 1.0 regenerated Feature files with each change, it wasn't possible to manually amend the files. This was often necessary to add things not directly supported by the tool, such as Feature receivers.

So let's run through the different areas where the tool has been improved.

WSP View

The big change with this release is that it is now possible to amend Feature files in the development process. Instead of hiding the generation of these files behind the scenes, the tool now makes these bona fide VS project items which can be edited before the Solution package is built. Certainly auto-generation of the final files still happens (that's the point) and there are some files lurking which are needed to support the tool, but VSeWSS now does a good job in presenting to you what you can modify through the WSP View (View > Other windows > WSP View). This is shown below for a project with some different artifacts:

Some nice things which can be done here are that entire Features can be deleted with a single click (all files will be removed), and the Feature activation order can be changed. Toolbar buttons are provided which modify the sequence of FeatureManifest elements in the manifest.xml file.

Feature file editing

So the WSP View provides the mask onto the editable files, but I wanted to drill into why this is useful. Some examples would be:

ability to add Feature receivers to a particular Feature
ability to rename properties of the Solution package, e.g. to bring VSeWSS-generated Solutions into line with a naming convention
ability to refactor Feature elements into a single Feature. This can be useful because by default the tool will create a new Feature each time you use Project > Add new item > Some SharePoint item (e.g. Content type). Often you will want several Feature elements to comprise a single Feature rather than split over several Features.

Event receivers

VSeWSS 1.1 also provides some enhancements around event receivers (handlers for events raised by lists). Version 1.0 also provided some support in this area, but the main scenario was adding a list/item receiver at the time the list was being created (i.e. "create list with receiver"). Version 1.1 now makes it easy to add an event receiver to an existing list, which simplifies those scenarios.

My favorite improvement in this area however, has to go to event receivers on content types. This effectively means that the event-handler code travels with the content type - so your code will run on all lists the content type is associated with. This is interesting as I had no idea this was possible in the WSS 3.0 platform! So I did some digging. I haven't yet done any testing of the results, but what VSeWSS does to support this is add some custom attributes to a standard list event receiver. For those interested, these are defined in the SPDevTools namespace in a file which is added to your project (out of the way in the Properties folder, alongside AssemblyInfo.cs) by the tool. I've not yet worked out exactly what picks up these flags in the Feature activation process, but it's clear that standard list event receivers are actually being used as the generated class derives from SPListEventReceiver. The image below (click to enlarge) highlights the new attribute being applied which supports all this:

Web parts

This was where I thought VSeWSS was a winner, and it's good to see the support for web part deployment has been extended further still. With 1.1, a default web part definition file (.webpart) is now generated for you to edit before deployment to add custom property settings. This is useful, since it means that developers can avoid the "deploy web part, add to page, configure, export web part" process which is otherwise required to obtain a configured definition.

Performance

One of the first things VSeWSS 1.0 users will notice is that a full IISReset is no longer performed on each deployment. This was something of a pain with version 1.0, since it meant the "edit, deploy, get feedback" cycle took longer than was necessary. So having been used to the IISResets, personally I was pretty pleased to see the message below in the Visual Studio status bar during the first deployment!

What could be better

So those are the good bits, and it's a great step in the right direction. However I'd still like to see the following:

fully-featured Solution Generator. I didn't have time to look at this in detail, but the download page specifies that certain items still aren't covered. This ties in with what I remember Alex Malek saying at this year's Tech Ed, that this still wouldn't be "full fidelity".
ability to easily add a Feature receiver to a Feature I'm working with. I just want right-click > Add Receiver - this should generate the class and add the attributes to the Feature definition with default values, or perhaps infer the generated type.
ability to easily refactor Feature elements in Features, since I often don't want the default of a Feature per element
no GUIDs in Feature names (though apparently this will be sorted by final release)
ability to deploy a _layouts file (again, this should be there in final release)

On a "bigger picture" note, I'm reminded of a common view in the SharePoint community which made complete sense when I heard it first from Ted Pattison. Unlike .Net, where Microsoft has gone to great lengths to ensure the tools are in sync with the platform (same team [Scott Guthrie], same timeframe for development phase, same ship date), a different thing is happening with SharePoint. Effectively the tools are 18 months behind the platform, so SharePoint development can be pretty painful at the moment - however, this shouldn't be taken as a reflection of the platform.

This release of VSeWSS should help though, and it'll be interesting to see what comes in the future.

The download link is http://www.microsoft.com/downloads/details.aspx?FamilyID=3e1dcccd-1cca-433a-bb4d-97b96bf7ab63&displaylang=en.

Adding custom help pages to SharePoint is complex!

Monday, August 27, 2007 | From Chris O'Brien's blog

Something I've been curious about for a while now is how to extend the SharePoint help system. A while back I wrote about how to modify 'system' pages in SharePoint by effectively adding new pages - the examples I used were:

a custom Recycle Bin page which displays only items deleted by the current user
a custom Central Admin page which has a message specific to my fictional organization's administrators

When implementing customizations like this, I thought it would be useful to be able to add custom help to accompany the new functionality. So today I set about digging around the SharePoint help system to see how to do this. Unfortunately my answer so far is that it's pretty difficult and I haven't figured out all the pieces! However, I thought I'd detail what I found in the hope that either it's still useful to somebody, or that someone who knows can perhaps leave a comment or link and complete the jigsaw.

So to be clear, I'm talking about how to add custom application help pages here - nothing to do with the 2 .chm files which are the WSS and MOSS SDK references. In site or central admin pages, the application help pages are linked to from help icon on the top bar:

As you'd expect, this icon (and the link behind it) is provided by the master page for the page. Clicking the link calls a JavaScript function called TopHelpButtonClick() in core.js to open the help window - on most pages a parameter of 'NavBarHelpHome' is passed, though notably pages which link to a page other than the default help page override this value. Since all pages in say, Central Admin share the same master page (and the JS call is in the master page, not the actual page) the code in core.js checks to see if the page itself has specified an override. Individual pages can therefore override the help location specified in the master page using a script block such as:

var navBarHelpOverrideKey = "OSSCentralAdmin";

</script>

Core.js will then build a link with this override parameter in rather than 'NavBarHelpHome', meaning that pages can easily link to a custom page rather than the default. In order to link to a custom help page, your page will need to override this value.

The value used here links to a value in a set of mapping files stored in C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\XML\HELP. In the case of the value shown above, we find that one of the mapping files, 'OssSearchAdmin_HelpKeymap.xml', contains the following:

<helpmap>
    <key>OSSCentralAdmin</key>
    <collectionId>MS.SEARCH.ADMIN.manifest</collectionId>
    <contextId>MS.SEARCH.ADMIN.OSSCentralAdmin</contextId>
</helpmap>

The set of mapping files in this directory all contain similar entries, i.e. a corresponding entry for each page which specifies an override to the default help page. Since these files don't appear to follow any naming convention, I'd venture that any XML file with the correct schema can be dropped in here and the help system will pick it up. When it comes to finding what these references point to, things get interesting! An initial search across the '12' directory using Visual Studio 'find in files' yields no results, but as with most of these things it's worth digging further. In the '\12\HCCab\1033\' directory are a set of .cab files which store the help files used in the SharePoint help system. In the example above, the 'MS.Search.Admin.HC.cab' file is the file which is referenced. Looking inside, we see a number of files, one of which is named 'MS.SEARCH.ADMIN.manifest.xml', which you'll notice is the value for the <collectionId> in the mapping above. The contents of one such .cab file look like:

So a quick recap of so far - we've found how to override the initial help page which is displayed, and how the key specified links to a set of help files packaged as a cab file in the 'HCCab\<localeId>' directory.

The manifest file is obviously key to how the index of the files in the .cab are linked. Incidentally, for those familiar with building SharePoint solution packages, the schema used here is completely unrelated to the 'manifest.xml' file used there. Looking at the contents of one of these manifest files, the first thing that strikes me is it looks like a system-generated file - for one thing there are many parent/child and link relationships which would be complex to document by hand. An extract looks like:

<?xml version="1.0"?>

<name>SearchCentralAdmin</name>

<id>MS.SEARCH.ADMIN.manifest</id>

<author>Microsoft</author>

<defaultHelpItem>MS.SEARCH.ADMIN.HA10175815</defaultHelpItem>

<rootCategory>MS.SEARCH.ADMIN.CH10176169</rootCategory>

<id>MS.SEARCH.ADMIN.HA10047848</id>

<parent sortOrder="4" primary="true">MS.SEARCH.ADMIN.CH10176336</parent>

</parents>

<item sortOrder="1">MS.SEARCH.ADMIN.HA10047848</item>

<item sortOrder="1">MS.SEARCH.ADMIN.ManageSearchService</item>

<item sortOrder="1">MS.SEARCH.ADMIN.SearchServerSettings</item>

</relatedItemsPointingToMe>

</helpItem>

<id>MS.SEARCH.ADMIN.HA10047852</id>

<parent sortOrder="6" primary="true">MS.SEARCH.ADMIN.CH10176338</parent>

</parents>

<item sortOrder="1">MS.SEARCH.ADMIN.LogSummary</item>

<item sortOrder="1">MS.SEARCH.ADMIN.LogViewer</item>

</relatedItemsPointingToMe>

</helpItem>

However, one thing which does check out is that the file referenced in the <defaultHelpItem> is indeed the page which is loaded initially when the help window opens. So that's something!

I can't help thinking though, that a help file generator has been used and it would probably be necessary to use the same approach to add custom help pages. When I started delving I mainly expected to find some .chm files generated by nDoc or Sandcastle somewhere, but it does seem like something I'm not familar with has been used. Robohelp perhaps?

If anybody can shed any light on this I'd be interested to hear. In the meantime, I note that others have found alternative ways around the problem, by passing a custom parameter and then modifying core.js to intercept this and open up a completely custom help window, rather than plugging into the existing help system as such. Ragav Jagannathan's post on his approach can be found here - http://ragavj.blogspot.com/2007/04/custom-help-window-can-be-opened-by.html. As Ragav rightly points out, customizing the core.js file is unsupported so you should probably think carefully before going down this route.

[Update - Nick Swan MSN'd me to point out that there is a document library in the Central Admin website which contains help files. Interestingly, it's the same set of files stored in the HCCab folder on the filesystem! It's difficult to tell from the IIS logs which set of files are actually pulled in, as they seem to be dynamically loaded through the '/_layouts/helpContent.aspx' and '/_layouts/help.aspx' pages. Interesting!]

Automatically setting custom permissions on new sites

Sunday, August 19, 2007 | From Chris O'Brien's blog

This is the third and final article in a series of three, where I demonstrate how how to perform custom processing in the site creation process. See 'Article series - custom permissions with a site definition' for the full run down on the article series. Specifically, I wanted to show how to use code to modify sites as they are created, in order to do things which aren't normally possible with site definitions/site templates. In the example I'm using, I'm setting custom permissions on the created sites. A scenario where this might be useful is if say, your organization is using SharePoint in a collaboration sense and users are creating sites themselves, but certain sites need to be secured so that access is restricted to specific users. Often end users might not understand the details of the SharePoint security model, so it would be nice if we could take care of this automatically for them.

The solution

In the last article 'Site definitions - custom code in the site creation process', I showed how it's possible to use a Feature receiver in conjunction with the site definition to do pretty much anything you might want to do as sites are created. Based on this approach, my solution is based around the following:

Custom list which stores the list of authorized users in the site collection's root web. This list stores a mapping of users to the permissions they should have in the created site.
Custom site definition, created by copying an existing definition as described in the SDK.
Feature which doesn't have any Feature elements defined, but is attached to a Feature receiver. A property is defined to pass in the name of the permissions list.
Feature receiver code which uses the object model to iterate the permission list and grant appropriate permissions to each user listed.

So let's break down each element of the solution. Note that all the code etc. is available for download and is linked to at the end of the article. First of all, we create a list which looks like this (click to enlarge):

Looking at the the edit view for the list (shown below), we see that the two key columns are:

'User' - Person or Group data type
'Permission level' - choice data type, with allowable values 'Owner', 'Contributor' and 'Viewer'

If we are creating sites which are restricted we would probably want to secure the list so that curious users cannot add themselves, and then gain access to any future restricted sites which are created.

So that's the list. The site definition in my example doesn't do anything special - it's just a copy of the 'BLANKINTERNET' definition to keep the example simple. However, 'Creating, deploying and updating custom site definitions' has more information on the kinds of customizations you can make with your site definitions.

The Feature is defined to reference the Feature receiver class we are creating. This ensures our custom code will run when the Feature is activated.

<Feature  Title="SiteProvisioning" Id="7C020FFF-FF42-4fe2-8A9B-9BCA0D5F8001" Description="" Version="1.0.0.0" Scope="Web" 
          Hidden="TRUE" DefaultResourceFile="core" 
          ReceiverAssembly="COB.Demos.SiteDefinition, Version=1.0.0.0, Culture=neutral, PublicKeyToken=cd9b418c14cff42e" 
          ReceiverClass="COB.Demos.ProjectXSiteDefinition.SiteProvisioning" xmlns="http://schemas.microsoft.com/sharepoint/">
  <Properties>
    <!-- could also retrieve list by GUID by passing in as property and amending code slightly -->
    <Property Key="PermissionsListName" Value="Project X Permissions" />
  </Properties>
</Feature>

The 'ReceiverAssembly' and 'ReceiverClass' attributes have the values which point to our Feature receiver class which contains our custom code. Note also we are passing in a value which can be retrieved in the code by using a Feature property. This can be used as a more flexible alternative to hardcoding values in the class - in this case we are using it pass in the name of the 'authorized users' list, meaning that this Feature can be reused across different requirements (which would use different lists). A minor tweak to the code and property will allow you to use the list GUID if you prefer, though note that list GUIDs will be different if the list is recreated in another SharePoint environment.

So that's all great but what ensures the Feature gets activated? Ah you've lost the thread since the last article haven't you?! The Feature is activated automatically when sites are created using the definition courtesy of this line in the WebFeatures section of the onet.xml file which specifies what the site definition consists of:

<Feature ID="7C020FFF-FF42-4fe2-8A9B-9BCA0D5F8001">

And so finally, onto the code which we have written in our Feature receiver class:

using System;
using Microsoft.SharePoint;
 
namespace COB.Demos.ProjectXSiteDefinition
{
    class SiteProvisioning : SPFeatureReceiver
    {
        public override void FeatureActivated(SPFeatureReceiverProperties properties)
        {
            SPWeb currentWeb = null;
            SPSite currentSite = null;
            object oParent = properties.Feature.Parent;
 
            // retrieve the permissions list by name..
            string sPermsListName = properties.Definition.Properties["PermissionsListName"].Value;
 
            // only perform processing if the site definition is being used to create a web within the expected site collection..
            if (properties.Feature.Parent is SPWeb)
            {
                currentWeb = (SPWeb)properties.Feature.Parent;
                currentSite = currentWeb.Site;
 
                SPList permsList = currentSite.RootWeb.Lists[sPermsListName];
 
                // ensure the web is set to use unique permissions, we won't copy existing permissions from parent site..
                if (!currentWeb.HasUniqueRoleAssignments)
                {
                    currentWeb.BreakRoleInheritance(false);
                }
 
                foreach (SPListItem perm in permsList.Items)
                {
                    string sPermLevel = (string)perm["Permission level"];
 
                    SPFieldUserValue userValue = (SPFieldUserValue)perm.Fields["User"].GetFieldValue(perm["User"].ToString());
                    SPUser user = userValue.User;
                    setPermission(currentWeb, user, sPermLevel);
                }
 
                currentWeb.Update();
            }
        }
 
        private void setPermission(SPWeb currentWeb, SPUser user, string sPermLevel)
        {
            SPGroup permissionsGroup = null;
 
            switch (sPermLevel)
            {
                case "Owner":
                    permissionsGroup = currentWeb.AssociatedOwnerGroup;
                    break;
                case "Visitor":
                    permissionsGroup = currentWeb.AssociatedVisitorGroup;
                    break;
                case "Member":
                    permissionsGroup = currentWeb.AssociatedMemberGroup;
                    break;
                default:
                    throw new NotImplementedException(string.Format("Group '{0}' not yet implemented.", sPermLevel));
                    break;
            }
 
            permissionsGroup.AddUser(user);
      }
 
        public override void FeatureDeactivating(SPFeatureReceiverProperties properties)
        {
        }
 
        public override void FeatureInstalled(SPFeatureReceiverProperties properties)
        {
        }
 
        public override void FeatureUninstalling(SPFeatureReceiverProperties properties)
        {
        }
    }
}

Stepping through the code, we first find the 'authorized users' list, tell SharePoint we don't want to inherit permissions for the web being created, and then iterate through the list adding each user to the appropriate security group for the web as we find them. Note the SPWeb object has properties to allow you to easily reference the 'Owners', 'Visitors' groups etc. - these will be named in the form '[My site name] Owners' so this avoids you having to do any nasty string concatenation here.

In terms of how where this class fits alongside the rest of the files, I just store it in the same VS project. In this example I'm not using VSeWSS to create the Solution, but as I mentioned last time this can make things much simpler. I'm choosing not to here because I wanted to pass the list name using a Feature property, and in the current version VSeWSS does not have the flexibility to support this. In any case, having the class in the same VS project means that when the project is compiled, the receiver assembly is built and is output to the same project's bin directory. My .ddf file which is passed to makecab.exe then adds this dll and all the other files to the Solution package (.wsp) which is built for deployment. You may choose to use a post-build type solution (MSBuild, post-build script etc.) to automatically deploy this to your local environment on every compile, either by straight XCOPY or using the STSADM commands - my 'Building and deploying SharePoint Solution packages' article has more information on this. So my overall project structure looks like this:

So for deployment this means everything is in one package - on deployment the assembly hits the GAC before the Feature activation process runs, meaning the Feature receiver code is in place and will execute successfully. Once deployed, the site definition is available for use and new sites can be created from it. If we go ahead and create a site, if we look at the different security groups we see the appropriate users have been added according the configuration data we stored in the 'authorized users' list.

Owners group:

Visitors group:

So that's it! We now have our solution which enables us to 'package up' custom permissions with a site definition. Clearly we could store the permissions mappings in some other store such as a database table or XML file, but all things being equal I'm a big advocate of using SharePoint lists to store such data. The user interface is provided for you, and security can be applied to ensure standard users are unaware of the list's presence.

All the files I used can be downloaded from http://sharepointchris.googlepages.com/sitedefinitionwithcustompermissions.

In terms of using the files, you can follow this process to use the technique:

create the authorized users list from the list template I supply - 'PermissionsListTemplate.stp'
add your users and permission mappings to the list
add your site definition files to the appropriate places in the VS project, and modify the onet.xml file etc. as necessary
if files have been added, amend the .ddf file to include these and rebuild the Solution package
deploy the package using STSADM (a .bat file is included in the zip) and create sites from the definition!

Hopefully this series has been some use. While the approach is certainly useful in my scenario of rolling out a site definition used to create automatically secured sites from, in general terms you can use the technique to do any custom processing you want in the site creation process. If there are any queries please leave a comment!

Site definitions - custom code in the site creation process

Sunday, August 12, 2007 | From Chris O'Brien's blog

This is the second article in a series of three, where I aim to show how to customize the site creation process (known as site provisioning) with your own API code. The full introduction and series contents can be found at http://sharepointnutsandbolts.blogspot.com/2007/07/article-series-custom-permissions-with.html. The example customization I'm using is as follows: any sites created with the definition should use a specific set of permissions, and not simply follow the default behavior of inheriting the parent site's permissions. Since this can't be done with a standard site definition (like many other things you might want to do), use of the API is required.

However, today the focus is less on the permission specifics of my example, and more on how generally to add your own code which runs in the site provisioning process. And the best thing is, it's actually very simple if you understand SharePoint Features.

There are many reasons why you might have cause to use the API in the site provisioning process. Essentially, if you can't find a way to do what you want using CAML schema in the onet.xml file, chances are you'll have to write code. Hence, it's almost easier to think of what you can do in the onet.xml file and reverse the list in order to work out scenarios which require code, but some examples which spring to mind anyhow are:

changing the custom master page of a site
creating a site column which gets it's data from a list (see my post on my Feature receiver which does this at Feature to create lookup fields on Codeplex)
adding custom unique permissions to a site (the example in this article series)
set a site property from any kind of dynamic lookup

In short, there are many scenarios.

Creating site definitions with VSeWSS

If you've ever created a site definition with Visual Studio Extensions for Windows SharePoint Services, you'll notice that the VS project it gives you contains a file called SiteProvisioning.cs. Inside is an event-handler method, where you can add your custom code which will execute when a site is created from the definition. The class looks like this:

namespace COB.Demos.SiteDefinition
{
    public partial class ProjectXSiteDefinition
    {
        /// <summary>
        ///  Define your own feature activation action code here
        /// </summary>
        public void OnActivated(SPFeatureReceiverProperties properties)
        {
            // my code here..
        }
    }
}
 

The plumbing behind all this is interesting. At first glance, the method signature looks like a Feature receiver, but it's actually not. However, examining the VS project (you'll need to build the project with F5 at least once to generate the files) reveals that VSeWSS has in fact created some Features in the background. These files can be found under the bin\Debug\solution folder in your VS project (hidden by default - you'll need to do a 'Show All Files' in Visual Studio Solution Explorer). If you do some more delving around to see exactly what VSeWSS is doing, you'll find the following:

2 hidden Features have been created - 1 deploys the 'default.aspx' file, the other has no 'elements' file but is hooked up to a Feature receiver - this is a class in an assembly named the same as your VS project. If you check the GAC, you will indeed find this assembly there.
a line similar to the following has been added to the onet.xml file under the 'WebFeatures' element:

<Feature ID="67b2507c-8822-41dc-b939-3d8f34b5ad13" />

Notably, this is the ID of the Feature which is hooked up to the Feature receiver.
Using Reflector on the assembly containing the Feature receiver shows that the main event-handler method performs some processing and then calls into the OnActivated method shown above, i.e. the place where VSeWSS provides for you to add your own code to execute when sites are created. This code is actually contained in the SiteProvisioning.Internal.cs file within the VS project. (If you're curious as to what on earth all the code in here is doing, the answer as far as I can tell is nothing when site definitions are created with the VSeWSS project template. However, this code is also found when Solution Generator is used to extract a site definition - in that case there are some fixups which need to be done, and this is the code which is used.)

So in summary, VSeWSS creates a hidden Feature is added to the 'WebFeatures' section of the onet.xml so that it is automatically activated when the definition is used to create a web*. The Feature is hooked up to a Feature receiver which calls the OnActivated method where your custom code lives.

*(Note that if the definition is used to create a site definition, the root web is also created automatically so the Feature would also be activated then. Also note the feature needs to be already installed in the farm for it to be activated in this way).

What we can derive from this is that there's no 'special place' in the site provisioning process to inject custom code, but it can be accomplished by use of a Feature receiver. So if you don't want to use VSeWSS to create site definitions, this is the technique to use to add your custom code to the site creation process.

In terms of what that code might look like, a 'Hello World' example could be:

public void OnActivated(SPFeatureReceiverProperties properties)
{
     SPWeb currentWeb = null;
     SPSite currentSite = null;
     object oParent = properties.Feature.Parent;
 
     if (properties.Feature.Parent is SPWeb)
     {
         currentWeb = (SPWeb)oParent;
         currentSite = currentWeb.Site;
     }
     else
     {
         currentSite = (SPSite)oParent;
         currentWeb = currentSite.RootWeb;
     }
 
     currentWeb.Title = "Set from provisioning code at " +  DateTime.Now.ToString();
     currentWeb.Update();
}

Hopefully this illustrates that it's quite simple to write code which sets properties on sites created from the definition. Generally the SPWeb object is the entry point, and any property which can be modified can be modified using the API. So, this is a pretty powerful technique which can be used in many scenarios.

If you have this type of requirement, I'd definitely recommend using VSeWSS to simplify the process. It's certainly possible to hook everything up manually and package it into a Solution, but the tool does save a large amount of hassle. However as usual with VSeWSS, the price of this is some flexibility. As my sample code in the final article will show, it's sometimes useful to pass data into Features by using Feature properties, and this unfortunately is not supported by VSeWSS. So in case it's useful, the following link provides a zip file containing a Solution/Feature which uses the above technique, without using VSeWSS:

http://sharepointchris.googlepages.com/customcodewithsitedefinitions

In the next and final article, I'll cover the specifics of using the API to modify site permissions as sites are created. As is hopefully clear, this is in conjunction with the technique detailed here so the net result is that the specific permissions are set 'automatically', courtesy of the Feature which is automatically activated against a site when it is created.

Creating, deploying and updating custom site definitions

Sunday, August 05, 2007 | From Chris O'Brien's blog

This is the first article in a series of three where we'll discuss custom site definitions, and in particular how to run your own custom code in the site creation process. This technique is useful if you need to make any customizations using the API beyond what can normally be accomplished with a site definition. In my series (for the full series contents, see my introduction at http://sharepointnutsandbolts.blogspot.com/2007/07/article-series-custom-permissions-with.html), I use the example of creating a site definition with specific security permissions 'attached' - so that when any sites are created using the definition, specific permissions are applied which are different to those of the parent site (this is unlike the default, which is for new sites to inherit the parent site's permissions). More background can be found in the introductory article linked to earlier.

In this article we'll start with the site definition basics - I'll also supply the set of files used in this article in a link at the end. Fundamentally, a custom site definition is a template from which new SharePoint sites can be created. Customizations can be packaged into the definition, so that they are present automatically in sites created from the template. Consider the following about site definitions:

they are created by copying an existing (e.g. out-of-the-box) site definition and adding customizations
XML files (in particular the onet.xml file) specify what a site definition consist of (i.e. .aspx pages, images, web parts, functionality [in the form of SharePoint Features])
they provide a similar functionality to site templates (.stp files) - for a discussion of the differences between site definitions and site templates see http://msdn2.microsoft.com/en-us/library/aa979683.aspx
site definitions can be deployed using a SharePoint Solution package (.wsp file), so that files do not need to be manually copied to each web server in a SharePoint farm

The process for creating site definitions is well-documented in the WSS 3.0 SDK at http://msdn2.microsoft.com/en-us/library/ms454677.aspx, so I actually won't cover it here but would encourage you to follow the link. However I will quickly run through some of the key elements in the onet.xml file to go over what can be done with site definitions. For an example, let's take an extract of the onet.xml file for a publishing (note for clarity this is an extract only - a full version is available at the link at the end of the article):

<Configuration ID="0" Name="BLANKINTERNET">
  <SiteFeatures>
    <Feature ID="A392DA98-270B-4e85-9769-04C0FDE267AA">
      <!-- PublishingPrerequisites -->
    </Feature>
    <Feature ID="7C637B23-06C4-472d-9A9A-7C175762C5C4">
      <!-- ViewFormPagesLockDown -->
    </Feature>
    <Feature ID="F6924D36-2FA8-4f0b-B16D-06B7250180FA">
      <!-- Office SharePoint Server Publishing -->
    </Feature>
  </SiteFeatures>
  <WebFeatures>
    <Feature ID="00BFEA71-4EA5-48D4-A4AD-305CF7030140" > </Feature>
    <Feature ID="22A9EF51-737B-4ff2-9346-694633FE4416">
      <!-- Publishing -->
      <Properties xmlns="http://schemas.microsoft.com/sharepoint/">
        <Property Key="ChromeMasterUrl" Value="~SiteCollection/_catalogs/masterpage/BlueBand.master"/>
        <Property Key="WelcomePageUrl" Value="$Resources:cmscore,List_Pages_UrlName;/default.aspx"/>
        <Property Key="PagesListUrl" Value=""/>
        <Property Key="AvailableWebTemplates" Value="*-ProjectX#0"/>
        <Property Key="AvailablePageLayouts" Value="ThreeColumnLayout.aspx"/>
        <Property Key="AlternateCssUrl" Value="" />
        <Property Key="SimplePublishing" Value="false" />
      </Properties>
    </Feature>
  </WebFeatures>
  <Modules>
    <Module Name="LoginPage" />
    <Module Name="Images" />
    <Module Name="Home" />
  </Modules>
</Configuration>

The Configuration element represents settings to be used with the selected definition, allowing groups of settings to be reused across definitions for flexibility
SiteFeatures /WebFeatures - specifies which Features should be automatically activated when the definition is used to create a site collection or child site respectively. This is key to our overall aim in this series of creating a site definition which applies custom unique permissions to sites created from it.
AvailableWebTemplates property of publishing feature - can be used to restrict which site definitions can be used to create child sites within sites created from this definition. This can be useful to prevent your content creators adding a team site onto your public-facing .com website for example. Here I'm specifying that only the 'ProjectX' definition with Configuration '0' can be used for child sites.
AvailablePageLayouts property of publishing feature - can be used to restrict which page layouts can be used within sites created from this definition. Again, this can be useful in controlling the look and feel of your website.
Modules - a module is a set of files to be automatically added when sites are created. Note it's also possible to specify which web parts should be added by default to a web part page by using the AllUsersWebPart element.

Deploying site definitions

What I really want to focus on however, is how site definitions can be packaged into a Solution to simplify deployment. This is typically most useful when deploying to multiple environments (e.g. test, staging, production) and/or deploying to a farm which consists of multiple SharePoint web servers. If you don't have this requirement, you may want to consider the simpler process of copying the XML files around manually, as detailed in the WSS SDK.

Before we start, let me highlight that Visual Studio Extensions for Windows SharePoint Services (VSeWSS) is a useful tool for creating and deploying custom site definitions, and I'd recommend looking into it for this requirement if you haven't already. However, I'm illustrating the 'manual' way here to hopefully provide an understanding of the nuts and bolts.

So, to package these files as a Solution manually, we follow the SDK instructions to get our customized onet.xml and webtemp*.xml files, but then place the files in a similar folder structure to the existing site definition files found under the 12 folder. I recommend creating a Visual Studio project as the best way to group these files (VSeWSS also follows this approach). This means you should end up with something looking like this:

Note we also have a .ddf file which is used with makecab.exe to build the Solution package - see my article on building and deploying Solution packages for details on the full process here. Effectively, we need to build the Solution by passing the .ddf file as a parameter to makecab.exe, and then run the STSADM -o addsolution and STSADM -o deploysolution commands to deploy to our target SharePoint site.

Once this is done, on the 'create site' screen we should see our new template appear:

Users can now use this definition to create sites which automatically have all the functionality and appearance we specified upfront. If we then need to deploy the definition to other environments, it's a simple case of copying the .wsp file there and running the STSADM commands. We are now well on our way to creating a site definition with custom permissions associated with it.

The set of files used in this article are at http://sharepointchris.googlepages.com/creatinganddeployingcustomsitedefinition

Updating existing site definitions

Finally, a quick note on updating definitions. Care needs to be taken here as often you will want to update files which are in use by sites already created with the definition - this can break things! Generally adding to a definition is OK, but modifying/deleting things can cause problems.

So a good technique is to copy the existing definition, add the updates and deploy for new sites to use, but also hide the earlier version so it cannot be used going forward. This is accomplished by removing the webtemp*.xml file from the TEMPLATE\\XML directory. Any sites already provisioned from the earlier version of the definition will continue to run fine, since you're leaving the actual definition (onet.xml etc.) intact over in TEMPLATE\SiteTemplates.

Remember also that new Features can be stapled to existing site definitions (affecting only new sites which are created, not existing ones), and this can be useful in avoiding having to update the site definition itself. See my article on Feature-stapling for more details.

So that's site definition basics. Next in the series - how to go beyond simple site definitions : add custom code which will execute when sites are created!

Article series - custom permissions with a site definition

Tuesday, July 31, 2007 | From Chris O'Brien's blog

This is an introductory article which gives the background to an interesting problem I've seen recently. Over the next 3 articles, I'll be looking at a solution to the problem and will discuss the following:

Site definition basics - how to create and deploy
Site provisioning - how to perform custom processing when sites are created using the definition
Unique permissions on created sites - how to ensure that certain users are automatically granted access to sites created using the definition, even when the parent site has different users/permissions

What I aim to show is how to deploy a site definition which has custom permissions 'attached' to it. By this I mean that any sites created with this template will acquire a set of custom permissions, without a user/admin having to configure them separately. What we're effectively doing is automatically putting a set of users into SharePoint site groups (at the time of site creation) - assuming the site was called 'HR', these would be:

HR owners
HR members
HR visitors

This can be extremely useful in certain scenarios when users are creating their own sites and workspaces in SharePoint, i.e. collaboration scenarios. One example might be a situation where say, the senior management of your organization (who are all fairly familiar with SharePoint of course ;-)) want to create sites for an important initiative they have. They want to do this on an ad-hoc basis without involving IT, but the sites must be restricted access such that only certain people can use them. Additionally, the requirements might be that some people have full control, but others can only read.

Since these security requirements are probably different to those of the parent site collection, the site must implement 'unique permissions'. This is key - if the site can share (and that's share, not inherit - think about the difference) the permissions of the parent site, then custom permissioning is not required. Otherwise if you are happy to set up the custom permissions manually each time a site is created, that can be done simply too without a solution like mine. SharePoint provides dialog screens for this during the site creation process, if you select 'Use unique permissions' in the Permissions section.

However, when it should happen automatically, you need to perform some custom processing during the site provisioning process, which is what I'm illustrating here. So with the background out of the way, the articles will consist of the following:

Article 1 - Site definition basics

Process for creating custom site definitions
How to deploy using a SharePoint Solution package (.wsp)

Article 2 - Custom code in the site provisioning process

When this is necessary
How to get your code to run at this time

Article 3 - how to implement unique permissions for sites created with the definition

Storing permissions data in a secured SharePoint list
Feature Receiver code to apply the permissions

Article 1 in the series should be published in a couple of days. See you then!

Building and deploying SharePoint Solution packages

Sunday, July 22, 2007 | From Chris O'Brien's blog

Following a comment left elsewhere on this blog, I thought I'd cover exactly what SharePoint Solution packages are, including how they are built and deployed to other SharePoint environments.

First of all, let's be clear on exactly what a Solution package is. Note I'm using 'Solution' with a capital S in this article to distinguish between what we are discussing here and the general idea of a technical solution built using SharePoint. A Solution is a package of SharePoint items for deployment - in physical terms it is a cabinet file (.cab) which is given the extension of .wsp to differentiate it from standard .cab files. Other articles on this blog cover the idea of using SharePoint Features to deploy functionality, so let's also be clear on the relationship between Features and Solutions. In general terms, some of the tasks which cannot be done with a Feature alone but can be done with a Solution include:

Deployment of certain files to the filesystem, e.g. an assembly for workflow or web parts, custom files which will reside in the ‘12’ folder
Deployment of web part definition files (.webpart)
Web.config modifications e.g. the ‘SafeControls’ entry required for a custom web part
Code Access Security config modifications e.g. those required for custom web parts not running from the GAC

In addition to being able to do these things, Solutions can also contain Features. The way I think of it is that the Solution wraps the Feature. In actual fact, I always recommend that even if they don't need to be (e.g. we're not doing anything in the list above), Features are always deployed as part of a Solution. The reason for this is that the Solution framework takes care of deploying all required files to all Web Front End (WFE) servers in a SharePoint farm. This alone is incredibly useful in working towards repeatable deployments, and ensures your WFEs stay synchronized.

How Solutions are specified

The key file used to specify what a Solution package consists of is the manifest.xml file. Going back to my earlier post on deploying web parts, the manifest.xml file for that scenario looks like this:

<Solution xmlns="http://schemas.microsoft.com/sharepoint/" SolutionId="122C0F04-78B7-4d42-9378-6F8B4F93ADD1">
  <FeatureManifests>
    <!-- note this is the location in the cab file! -->
    <FeatureManifest Location="COB.Demo.WebPartDeployment.WriteToFileWebPart\feature.xml" />
  </FeatureManifests>
  <Assemblies>
    <Assembly     Location="COB.Demo.WebPartDeployment.WriteToFileWebPart\COB.Demo.WebPartDeployment.WriteToFileWebPart.dll" 
        DeploymentTarget="GlobalAssemblyCache">
      <SafeControls>
        <SafeControl Assembly="COB.Demo.WebPartDeployment.WriteToFileWebPart, COB.Demo.WebPartDeployment, Version=1.0.0.0, Culture=neutral, PublicKeyToken=9f4da00116c38ec5" 
                    Namespace="COB.Demo.WebPartDeployment" 
                    Safe="True" 
                    TypeName="*" />
        </SafeControls>
    </Assembly>
  </Assemblies>
  <DwpFiles>
    <DwpFile 
     Location="COB.Demo.WebPartDeployment.WriteToFileWebPart\COB.Demo.WebPartDeployment.WriteToFileWebPart.webpart" 
      FileName="COB.Demo.WebPartDeployment.WriteToFileWebPart.webpart" />
  </DwpFiles>
</Solution>

This is assuming the web part is being deployed to the GAC - for this illustration this is a simpler scenario than deploying to the web application's bin directory, where Code Access Security (CAS) policy would also be required. Effectively, the manifest specifies that the Solution package consists of the following:

a Feature with a header file named 'feature.xml'
an assembly for deployment to the GAC named 'COB.Demo.WebPartDeployment.WriteToFileWebPart.dll'
an entry in the SafeControls section of the application's web.config file, specifying all types in the specified assembly should be treated as safe
a web part definition file named 'COB.Demo.WebPartDeployment.WriteToFileWebPart.webpart' - this will be deployed to the web part gallery on the site

Importantly, all these details in the manifest.xml file are only used by SharePoint when the generated Solution package is deployed. They are effectively the instructions which say "go and get this item from the .wsp file and put it here". The actual process for generating the .wsp file is another task.

Building Solution packages

There are 2 options for building the actual package - build it manually using makecab.exe, or use an automated solution - there are several community-developed tools/techniques available. Since it's always good practise to understand what's actually happening in such processes, we'll cover how to do it manually here.

The first step is to write a .ddf (Diamond Directive File). This is a set of instructions for makecab.exe on how to build the folder hierarchy inside the .cab file. For my web part example, my file looks like:

.OPTION Explicit
.Set CabinetNameTemplate="COB.Demo.WebPartDeployment.WriteToFileWebPart.wsp"  
.Set DiskDirectory1="Package"
;***
 
manifest.xml
 
;** this directory name is used for the folder name under 12\TEMPLATE\Features, so should
;** match up with what you want to call the feature!
.Set DestinationDir=COB.Demo.WebPartDeployment.WriteToFileWebPart
elements.xml
feature.xml
 
.Set DestinationDir=COB.Demo.WebPartDeployment.WriteToFileWebPart
WebPart\COB.Demo.WebPartDeployment.WriteToFileWebPart.webpart
WebPart\COB.Demo.WebPartDeployment.WriteToFileWebPart.dll
 
;***

This file tells makecab.exe to do the following:

create a .cab file named 'COB.Demo.WebPartDeployment.WriteToFileWebPart.wsp'
put the 'manfest.xml' file at the root of the hierarchy
put the 'elements.xml' and 'feature.xml' files in a subfolder called 'COB.Demo.WebPartDeployment.WriteToFileWebPart'
also put the 2 other files (with extensions .webpart and .dll) in this same subfolder, but that makecab.exe should look for these files in a subfolder on the main filesystem called 'WebPart'

This instructions file is then passed to makecab.exe with the following command-line command:

D:\SolutionDeployment\Development\COB.Demo.WebPartDeployment>"C:\Program Files\Microsoft Cabinet SDK\BIN\MAKECAB.EXE" /f COB.Demo.WebPartDeployment.ddf

Couple of things to note here. At the command prompt we have ensured the current directory is the directory where all our Solution files are kept. This ensures that our relative references in the .ddf file above can be resolved. We pass the /f parameter to indicate we are passing a directives file, and also pass the location of this file.

Assuming all the files/references are OK, this results in a .cab file with a .wsp extension which will be created in a subfolder under the current directory called 'Package' (the folder will be created for you if it doesn't exist). We now have a Solution package which can be deployed to another SharePoint server. But first let's take a peek inside - this can be done by temporarily renaming the extension to .cab. You should then see something like:

Deploying the Solution to other SharePoint servers

The final part is to actually deploy the Solution. First the .wsp file must be copied to the target server, and then we will use STSADM (SharePoint's command-line admin tool) to actually deploy the Solution. The following are the commands which used to perform the deployment:

stsadm -o addsolution -filename COB.Demo.WebPartDeployment.WriteToFileWebPart.wsp

stsadm -o deploysolution -name COB.Demo.WebPartDeployment.WriteToFileWebPart.wsp 
   -url http://myWebApplication -immediate -allowGacDeployment -allowCasPolicies -force

The first command simply adds the Solution package to SharePoint's Solution store in the config database, and the second one actually performs the deployment of the package to the specified web application. These areas are fairly well covered in the SDK at http://msdn2.microsoft.com/en-us/library/aa544500.aspx.

Rather than write these commands at the command-line each time you wish to deploy the package, chances are over time you'll package these commands up into STSADM scripts which do the work. As an example, the script I use for the webparts example looks like:

:begin
@echo off
 
set solutionName=COB.Demo.WebPartDeployment.WriteToFileWebPart
set url=http://myWebApplication
set featureName=COB.Demo.WebPartDeployment.WriteToFileWebPart
@set PATH=C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN;%PATH% 
 
echo --- Attempting to deactivate/retract existing solution...
 
stsadm -o deactivatefeature -name %featureName% -url %url% -force
stsadm -o retractsolution -name %solutionName%.wsp -url %url% -immediate
stsadm -o execadmsvcjobs 
stsadm -o deletesolution -name %solutionName%.wsp -override 
rem stsadm -o execadmsvcjobs 
 
echo --- Adding solution %solutionName% to solution store...
 
stsadm -o addsolution -filename %solutionName%.wsp
 
if errorlevel == 0 goto :deploySolution
 
echo ### Error adding solution %solutionName%
echo .
goto end
 
:deploySolution
echo --- Deploying solution %solutionName%...
 
stsadm -o deploysolution -name %solutionName%.wsp -url %url% -immediate -allowGacDeployment -allowCasPolicies -force
stsadm -o execadmsvcjobs 
 
if errorlevel == 0 goto :activateFeature
 
echo ### Error deploying solution %solutionName%
echo .
goto end
 
:activateFeature
 
echo --- Activating features in solution %solutionName%...
 
stsadm -o activatefeature -name %featureName% -url %url% -force 
 
if errorlevel == 0 goto :success
 
echo ### Error activating feature %featureName%
echo .
goto end
 
:success
echo Successfully deployed solution and activated feature(s)..
echo .
goto end
 
:end
pause

Following the script through, this basically does the work of safely upgrading the Solution (in case it has been deployed previously), and also activating the Feature within the Solution.

Automating Solution builds

Earlier, we mentioned the idea of automating the process of building and deploying Solutions. There are several community tools/ideas in this area, a couple of the ones I'm aware of are:

Andrew Connell's process for using MSBuild to generate Solution package - http://www.andrewconnell.com/blog/articles/UsingVisualStudioAndMsBuildToCreateWssSolutions.aspx
Vince Rothwell's solution for generating Solution package from pre-defined folder structure - http://www.codeplex.com/sptemplateland/

Both of these effectively use Visual Studio post-build events to automate the build of the .wsp package.

Additionally, Microsoft's Visual Studio Extensions for Windows SharePoint Services effectively performs the same tasks. Although there is some inflexibility in the current version, this add-on for VS means that the whole process is automated by hitting the F5 button. I'd recommend taking a look if you're not aware of this. My post on creating lists with VSeWSS gives an overview of using it for that specific scenario.

Using CustomAction to modify system pages

Wednesday, July 18, 2007 | From Chris O'Brien's blog

In the last post, I covered 2 examples of how to safely modify functionality in 'system' areas of SharePoint, such as Central Admin and the Site Settings area. The first example was a tweaked Recycle Bin (which listed only items deleted by the current user), and the second was a custom 'Create Site Collection' admin page. In both cases, the technique was to copy the original page which shipped with SharePoint, make the customization to the copy, and then redirect the link in SharePoint to use our new page. The customization is then fairly transparent to users - depending on your implementation, they could simply be clicking the same link in the same place in SharePoint, yet going to somewhere different which is offering your modified functionality.

This last part (of redirecting the link in SharePoint) is accomplished via a Feature which makes use of the CustomAction element. However, this idea of changing an existing link somewhere in SharePoint is not necessarily the type of customization you might regularly make. So it's useful to know the CustomAction element can also be used to add a link somewhere in SharePoint. This opens up many opportunities for customization, and this post aims to detail some of the options.

The CustomAction element is used like this:

<CustomAction Id="MyDeletedItems" 
              GroupId="SiteCollectionAdmin" 
              Location="Microsoft.SharePoint.SiteSettings" 
              Sequence="10" 
              Title="My recycle bin items" 
              Rights="ManageWeb,BrowseUserInfo">
  <UrlAction Url="_layouts/custom/MyRecycleBinItems.aspx" />
</CustomAction>

I covered most of the values in details in the previous post, but what I want to focus on here is the Location attribute - this essentially specifies where in SharePoint your link will be added to. Some of the common potential values are:

Microsoft.SharePoint.SiteSettings (as in the example XML above)
Microsoft.SharePoint.Administration.Operations
Microsoft.SharePoint.Administration.ApplicationManagement

If you've worked with SharePoint for a while you can probably work out where these values refer to - the first is the Site Settings area, whilst the last two are the 'Operations' and 'Application Management' pages in the Central Admin area respectively. When using a CustomAction to add links in these areas, you can also specify the group your link should appear in. This value refers to an existing 'category' of links within the Location, e.g. the locations listed above. Note that new groups can be created by using a CustomActionGroup element, but the GroupID value of a CustomAction must always specify a group which exists already. The following groups exist by default in the SiteSettings area:

UsersAndPermissions
Customization
QuickLaunch
Galleries
SiteAdministration
SiteCollectionAdmin

These correspond to the columns in the Site Settings area as shown below:

In the Central Admin pages, examples for the 'Operations' page are:

Topology
GlobalConfiguration
Security
BackupRestore
LoggingAndReporting
DataConfiguration
Upgrade

And for the 'Application Management' page:

WebApplicationConfiguration
SiteManagement
ApplicationSecurity
ExternalService
WorkflowManagement

By examining these pages, it's fairly simple to work out where the values refer to.

I mentioned earlier that new groups of links can be created using the CustomActionGroup element. An example of this would be:

<CustomActionGroup
    Id="CustomSiteSettingsGroup"
    Location="Microsoft.SharePoint.SiteSettings"
    Title="New custom group"
    Sequence="100"
    Description="My description" />

This will then create a new group of links on the page with your custom title - SharePoint will take care of the rendering such that your new group will wrap onto another row of groups. Of course if this isn't what you want you'll probably have an interesting time customizing this.

Using CustomAction elsewhere

So having covered how to add links into the admin areas, I'll wrap up by listing some other valid values for the 'Location' attribute. This hopefully illustrates some of the options you have for customizing SharePoint in this way:

Microsoft.SharePoint.ContentTypeTemplateSettings
Microsoft.SharePoint.ContentTypeSettings
Microsoft.SharePoint.Administration.ApplicationCreated
Office.Server.ServiceProvider.Administration (Shared Services/SSP links)
Microsoft.SharePoint.ListEdit.DocumentLibrary
Microsoft.SharePoint.Workflows
NewFormToolbar
DisplayFormToolbar
EditFormToolbar
Microsoft.SharePoint.StandardMenu (SiteActions menu)
Mcrosoft.SharePoint.Create (_layouts/create.aspx - the screen used to specify what you want to create on your site)
Microsoft.SharePoint.ListEdit (the screen used to edit the properties of a list item)
EditControlBlock (image below)

I've put the last few in bold and added a description as I think they're particularly interesting. Of course, if you have other customizations in mind one or two of the others might have caught your eye! In particular being able to add custom actions to the EditControlBlock is interesting:

Here, a special attribute called 'RegistrationType' can be added to the CustomAction element, allowing you to control exactly the circumstances where your action should appear. Valid options include 'List', 'ContentType', 'FileType' and 'ProgId'. Vince (aka TheKid) has some good examples of this over on his blog.

Hopefully this has given you some ideas on how you can add or amend the SharePoint UI in this way. Happy customizing!

Modifying 'system' pages in SharePoint safely - with sample code

Thursday, July 12, 2007 | From Chris O'Brien's blog

In a presentation I gave recently I talked about modifying admin screens within SharePoint. By this, I mean areas such as the site admin area and the central admin area:

Site admin:

Central admin:

Now, if your boss (or your users) asks you to add or change functionality in these areas, how would you handle that?

Well, you'd probably start off by looking to see how SharePoint implements 'system' pages like this. You'd then find they are just standard .aspx files in the 12\TEMPLATE\ADMIN folder on the filesystem. You'd also find that if you make a change to such a file, the changes are immediately reflected on the site - sure, some of the code is in a compiled assembly which is obfuscated (so Reflector doesn't help), but otherwise there's no mysterious abstractions, no caching, it's that simple. So changing the functionality or adding a link is a matter of changing the .aspx page right?

The problem with this approach is that modifying core files in this way is unsupported. This is because when a service pack or hotfix gets applied, your system will be in an inconsistent state and at best your changes will be overwritten. So a better way to implement such changes is to:

take a copy of the original file
modify the copy to include your customization
create a SharePoint Feature (wrapped in a Solution package [.wsp]) to deploy your customized page to the 12 hive, and also add/modify the link in SharePoint to point to your customized page

The end result of this is that you have deployed your change without modifying any of the original files, and are therefore entirely supported. Additionally, because Features can be activated and deactivated with the click of a button, if you want to revert to the original functionality that's all it takes.

Let's look at an example - I'll link to all the code used here at the end of the article. Imagine your users are asking you to change the Recycle Bin screen so that it only displays items the currently logged on user has deleted - perhaps there's a manual document clean up exercise happening. And let's also say that after the exercise is complete, the users would like to revert back to the original functionality. (Now remember, what I'm demonstrating here is the mechanism for making customizations like this, so whilst this particular change might be unlikely in your organization, you might have other customizations which would help your users.)

So, first we need to modify the functionality of the Recycle Bin page to add the filtering. As mentioned earlier, we don't want to amend the original page, so we take a copy and modify that. In my example, I'm adding a script block to the code in front (since I don't have access to Microsoft's source code for the code-behind) to effectively perform the filtering at the UI level, which is fine for this example. Once we've created the page we want to use, we're ready to create the Feature and Solution to add our page to SharePoint.

Let's start with the manifest.xml file for the solution - this is important because this is how we actually deploy our custom .aspx page to the appropriate place within the SharePoint files. (Remember all this is available for download, the link is at the end of the article.)

<Solution xmlns="http://schemas.microsoft.com/sharepoint/" SolutionId="AA7EF934-C993-4f91-8AF4-0FB1D45927FA">
  <FeatureManifests>
    <FeatureManifest Location="COB.Demos.MyRecycleBinItems\feature.xml" />
  </FeatureManifests>
  <TemplateFiles>
    <TemplateFile Location="LAYOUTS\Custom\MyRecycleBinItems.aspx" />
  </TemplateFiles>
</Solution>

Notice what we are doing here is specifying that our custom .aspx page should be deployed to a 'Custom' subfolder within the 'LAYOUTS' directory. This is a good idea because it keeps our files separate from the core SharePoint files.

Then we have a fairly standard feature.xml file specifying the Feature identification info:

<Feature xmlns="http://schemas.microsoft.com/sharepoint/" Id="29D8B365-6024-4b1a-84D2-FF789FE56355"

Title="COB.Demos.MyRecycleBinItems"

Description="Adds a custom page to the Site Settings area to show items in the Recycle Bin which were deleted by the current user."

Scope="Site" Hidden="FALSE"

Version="1.0.0.0">

</ElementManifests>

</Feature>

In this case we're specifying that our Feature is scoped at site collection-level, so we will modify all sites in the site collection.

Finally we have the our Elements file, which specifies what this Feature consists of. In this case, the key is the use of the CustomAction element - this can be used to add a link (i.e. an action) somewhere in SharePoint.

<HideCustomAction Id="HideDeletedItems"

HideActionId="DeletedItems"

GroupId="SiteCollectionAdmin"

Location="Microsoft.SharePoint.SiteSettings" />

<CustomAction Id="MyDeletedItems"

GroupId="SiteCollectionAdmin"

Location="Microsoft.SharePoint.SiteSettings"

Sequence="10"

Title="My recycle bin items"

Rights="ManageWeb,BrowseUserInfo">

</CustomAction>

</Elements>

Let's walk through this file in detail. The first thing you notice is that we're using a 'HideCustomAction' element. You guessed it, this is used to hide a link in the SharePoint UI. Since we are effectively replacing a link, we actually need to hide the original one and supply our replacement, and this is done by using these 2 elements together. We assign the ID ourselves (if we want to refer to this 'HideCustomAction' elsewhere, this is the value we'll use), but all the other attributes of this tag must correspond to those specified for this action in the Feature Microsoft created to add the link to SharePoint in the first place. So in case you've not come across this yet, much of the original functionality in SharePoint is actually implemented using Features too. The way to find these values is to search in the 12\Template\Features folder. For this particular action, the most reliable thing to search for is the URL of the page, since any 'CustomAction' tag specifies the URL. Since we can find that the URL for the original Recycle Bin page is '/_layouts/AdminRecycleBin.aspx', searching for this finds the file containing the details of the original link. These are then used for our 'HideCustomAction' tag.

Next we specify our 'CustomAction' tag, again using many of the same values since we are replacing an existing action rather than adding a new one. The values we change are for the link title and URL, to point to our replacement page. Note also you can declaratively specify what permissions levels are required to see this link.

Once these files are made into a Solution package, deploying the Solution and activating the Feature has the following effects:

The link on the site settings page has changed from the original (on the left) to our replacement (on the right):

A 'Custom' folder has been created in the '12\Layouts' directory and our custom .aspx page (MyRecycleBinItems.aspx) has been deployed to this folder. And of course, when a user clicks the link, the modified page has the functionality to only display items they have deleted:

The key thing of course, is that we've 'customized SharePoint functionality' without modifying any original SharePoint files - hence we are are 100% supported and can be confident our customizations won't cause any issues for service packs etc.

On the same lines, the sample stuff has a 2nd example - here we modify the 'Create Site Collection' page in Central Admin to display a guidance message to the SharePoint administrators. The idea is to encourage them to stop and think and perhaps consult the document containing the organization's policy on creating site collections:

Hopefully you might find this useful if you need to customize SharePoint in this way. The full set of files, plus the slides for the presentation I gave on this, are available at:

http://sharepointchris.googlepages.com/customizingsharepointsupportedway

In the next post, I'll be supplying some reference information which will help you make this type of modification in other areas of SharePoint. An important aspect of customizing SharePoint in this way is knowing exactly where and how the 'CustomAction' tag can be used, so that's what we'll look at.

'Customizing SharePoint the supported way' - slides and sample code now available

Sunday, July 08, 2007 | From Chris O'Brien's blog

The slides and code from my presentation at last week's UK SharePoint user group meeting are now available - the topic was 'Customizing SharePoint the supported way - from end user to admin interfaces'. The slides etc. will appear on the user group website at some point but I've also published them at:

http://sharepointchris.googlepages.com/customizingsharepointsupportedway

The areas covered are:

creating site definitions (and why it can be a good idea even for a WCM scenario with limited numbers of sites/webs being created)
how to modify the site admin and central admin areas of SharePoint, without modifying any of the shipped files. The examples I used (the sample code zip file contains all the code/Features for these) were:

- modifying the recycle bin to show only files deleted by the current user

- modifying the 'Create Site Collection' page in central admin to display a policy message to the farm administrators
using the DelegateControl to override the user controls used such as the 'My sites' link and the publishing console. (This assumes either default.master is being used or you have added the controls to your master page/page layout using <SharePoint:DelegateControl runat="server" ControlId="MyControlID" />). More details in my DelegateControl post.

Since the slide deck alone doesn't really convey the entire process, the next post will cover modifying the admin areas of SharePoint in detail. Included will be the list of areas where you can add/change links, and how to use a <CustomAction /> instruction within a Feature to do this.

If you need to make customizations to SharePoint functionality, the idea behind this technique is to make the changes without modifying the core files and thus putting your SharePoint installation in an unsupported state. This is very important if you need to make these kind of changes!

Considerations when using Features to deploy SharePoint files - ghosting/unghosting

Wednesday, July 04, 2007 | From Chris O'Brien's blog

In some of my earlier articles I talk about how to deploy various SharePoint artifacts as a Feature. In particular, 'Deploying master pages and page layouts as a Feature' discusses the idea of deploying these types of file (used in Publishing sites), but the concept applies to any file which will appear somewhere in a SharePoint list of some kind. In addition to the Master Page Gallery, other examples could include CSS/XSLT files being deployed to the Style Library, images to a picture library, and many other similar scenarios.

Occasionally people using this approach find that file updates can be difficult to apply. The process involves updating the Feature with the new version of the file, and then reinstalling and reactivating the Feature (typically the Feature version number will be incremented). In some cases the file updates successfully, in others it doesn't but there are no errors.

So what's going on?

The answer is that the file will not be updated (and therefore changes will not be seen in the browser for example) if that particular file has been 'unghosted' into the database.

<StartUnghostingExplanation>
[Without digressing too much, for anybody new to this concept it can be a confusing term which Microsoft are using less these days - the replacement term is 'customized' which is generally easier to understand. Depending on how they arrived in SharePoint, many files will initially only exist on the filesystem of the SharePoint front-end web servers. However, if such a file is customized e.g. it is checked out and edited (either through the UI, using SharePoint Designer etc.) SharePoint takes a copy of the file (now with modifications) and stores this in the content database instead of saving the changes back to the filesystem. This is the unghosting process. Whenever this file is requested in the future, the modified version from the database will be returned. This architecture allows SharePoint to scale to enterprise level, by only storing separate copies of files when absolutely necessary.]
<EndUnghostingExplanation>

When a file is provisioned in SharePoint using a Feature, SharePoint will copy the file to wherever your Feature specified, and will reference the file from this location. In many cases, this may actually be the 12\Template\Features directory. So in the case of master pages/page layouts etc. for example, when a web page is requested these resources will be retrieved from this location. Or at least, that's what happens if the file isn't customized.

If the file has been customized at some point, what happens when the Feature is updated is that the file on the filesystem is updated and reflects the changes, but SharePoint is now returning the copy in the database and so the update isn't reflected on the site!

So, if you want to use Features as your ongoing deployment strategy for your SharePoint document library (aka 'GhostableInLibrary') files, you should ensure the files can only be modified in this way. So files should not be modified either through the SharePoint UI or via SharePoint Designer. Typically, this won't be the case in the development environment but could be enforced for other environments. This means that unghosting is avoided, and SharePoint will continue to reference the copy on the filesystem.

Some other points of note:

Another advantage of this approach is that when a Solution is retracted, the files will also be removed.
Even a check-out/check-in operation without actual changes will cause SharePoint to see the file as customized, and will then be retrieved from the database rather than filesystem.
A file can be 'uncustomized' in SharePoint Designer by right-clicking on the file and selecting 'Revert to site definition'. However, this will obviously cause you to lose any changes you have made to the file from the original version!

So next time you are using a Feature and wondering why the file isn't being updated, consider if the file has been customized!

Extending the Content Query web part

Wednesday, June 27, 2007 | From Chris O'Brien's blog

Something I've been meaning to put on Codeplex for a few weeks now is an extended version of the Content Query web part. This particular web part is one which many SharePoint developers will use quite often for displaying lists of links etc. However, anybody who's ever worked with it will probably tell you they spent a good hour (or more) on the first time, wondering how the hell to get the control to display either:

custom columns on their list
custom columns on the content type that the page layout uses (in WCM scenarios)

Since this doesn't happen automatically, it becomes apparent you have to tell the control the names of your custom fields. You might expect this to be exposed (like many other things are) by the control properties, but unfortunately it's not that simple. There is a property (CommonViewFields), but the tool part doesn't provide a UI to enter a value. This means that the value can only be supplied by digging a little deeper and changing the definition of the CQWP using it's .webpart file.

This involves exporting the web part from a page which uses it, amending the CommonViewFields element in the XML, then re-importing the .webpart file to the Web Part gallery. This new definition can then be added to your page, and you'll then get the right results.

Hmm. Why is it not a property on the control again?!

So this was the extension I was going to implement. As it goes, Ishai Sagi has beat me to it and is supplying additional functionality to boot. The shot below shows that now all you have to do is enter your field names into the tool part:

Ishai writes about this at http://www.sharepoint-tips.com/2007/06/adding-custom-fields-to-enhanced.html. His 'Extended Content Query web part' can be downloaded from http://www.codeplex.com/ECQWP.

Definitely worth a look if you use CQWP regularly.

UK SharePoint user group - Customizing SharePoint the supported way

Monday, June 25, 2007 | From Chris O'Brien's blog

The UK SharePoint user group is meeting this Thursday (28th June) at the Microsoft campus in Reading. There are two sessions, one of which I'm presenting:

Customizing MOSS the supported way – from end-user to admin interfaces

One of the key concepts SharePoint developers should be aware of is that modifications to core shipped files are typically unsupported. This session looks at ways in which you can implement the kind of customizations your users may ask for, but without modifying the original files. Aspects covered include custom site definitions, modifying the site administration/central administration areas, and changing the user controls SharePoint uses with the DelegateControl architecture. The session is packed with demos, and also contains some quick tips on the best way to make other common customizations not shown in the detailed examples.

Speaker: Chris O'Brien

..and also:

Groove: A powerful tool for collaboration, that is now part of Office 07.

In this session, we review the basic functionality and then show, using the latest Microsoft templates (including issue tracking and document review), how Groove is not just a tool but a platform for delivering functionality. We'll also look at how Groove and SharePoint can both effectively work together.

Speaker: TBA

If you're in the area and would like to register, simply leave your name on the following thread over at the UK user group site:

http://suguk.org/forums/thread/3534.aspx

I'll be posting my slides and sample code after the event. The content on customizing the site admin/central admin areas will probably make it's way into separate posts for clarity.

NEWS FEED

UPDATED WIKI: Home

chrisobrien — Wed, 05 Dec 2007 15:49:21 GMT

The tool must be installed locally on the server which hosts the site
Site URL - enter using format http://source.test.dev
Import web URL - enter using format http://target.com/targetweb
See 'permissions' note lower down

Import/Export characteristics

Since the Content Migration API is used, imports/exports have the following characteristics:

dependencies of selected content (e.g. referenced CSS files, master pages) are automatically included in the export - check 'Exclude dependencies of selected objects' to disable this
all required content types, columns etc. are automatically included in the export
in contrast to STSADM export, it is possible to retain GUIDs during deployment (where objects are not being reparented) - check 'Retain object IDs and locations' to enable this
no filesystem files (assemblies, SharePoint Solutions/Features etc.) are deployed - these must already be present on the target for the import to succeed)
the following content does not get captured by the Content Migration API - alerts, audit trail, change log history, recycle-bin items, workflow tasks/state

Reparenting

Reparenting of objects such as webs and lists is possible with the following usage on the import:

- enter the URL for the target web in the 'Import web URL' textbox
- ensure 'Retain object IDs and locations' is not checked

Permissions

The Content Migration API (PRIME) is used to package the content as a .cmp file, which can be copied to another
server for import. The application MUST be run from the SharePoint server(s), and MUST be run under the context
of an account which has appropriate SharePoint permissions - currently the way to specify an alternative user
to the currently-logged on user is by using the 'Run as..' feature in Windows 2003 (right-click on the .exe and
select 'Run as..').

See my blog post 'Introducing the SharePoint Content Deployment Wizard' for more screenshots and information - http://sharepointnutsandbolts.blogspot.com/2007/12/introducing-sharepoint-content.html

Chris O'Brien

Error rendering macro: rss Expected parameter: url:[rss feed url]