Tuesday, January 29, 2008

SharePoint V3: When To/When Not To Use Content Types

Content types allow you to structure documents and list items in a SharePoint portal. They give the functional ability to define and enforce uniformity throughout a portal. There is no question that content types greatly enrich SharePoint as a content management product. However, in determining when to use content types in a portal, there are several considerations.

Is there a knowledge management champion who can coordinate the effort of unifying a business unit or entire company?

Executive Sponsorship/Authority
Do the resources who have the desire to standardize content also have the authority within a department (or broader scope) to make descisions and execute changes (or the backing of an executive sponsor)?

Is there a sense of unity amongst business units or are they segmented?
Are the business units of the organization integrated in their nomenclature (or even individuals within a business unit)?
How easy is it to communicate ideas accross business units or within a buisness unit?

Resources Allowed for Design
Does the organization have the people and intellectual bandwidth, and focus to figure out how to categorize document and list types, provide name for content types, determine format of each content type?

Is there a system of checks and balances, perhaps a design committee, in place for change management to ensure that pros and cons have been properly weighed prior to making design changes?

Organizational Adoption
Will the producers and consumers of the content accept a consistent structure for their content, or will they shy away or complain about it?
Will the users understand the content if it is categorized?

Are the content producers and their supporting power users familiar with SharePoint enough, and trusted enough by peers to create content types, associate templates, and add the content types to libraries?

...these represent some of the overarching ideas that come into play when trying to determine when to use content types.

Here are some of the technical considerations:

Site Structure
Does the portal design include one site collection or many?
Do the content types span accross site collections?
Content types work well within a site collection. But, when your content types span several site collections then it becomes a little tedious keeping the content type definitions in synch with each other.

Since templates and site exports (.cmp) can rely on content types, which means you need to set up the content types on multiple site collections.

Orphaned Data
Custom List or Document Library W/Multiple Content Types + DataSheet View + Unique Columns on View = Users can apply values to metadata columns that don't actually exist for a content type, and the metadata actually gets stored (no hard damage, just not clean)

Benefits of Content Types
* Allows you to name types of content
* Makes consistent metadata structure for each type of content
* Allows you to associate a unique document template
* New button shows the name of the content type instead of generic New Document or New Item
* Allows you to define parent/child relationships, allowing you to create a logical tree structure for taxonomy design
* Allows you to easily provision a new custom list or document library, the columns are already defined in the content type, just add the content type
* IE Script Error (mentioned above)
* Orphaned Data (mentioned above)
* No easy way to synchronize accross site collections (can use PowerShell to export/import)
* No security gains, not able to secure content types, still done at item or library level

Site Columns Without Content Types
* Great middle of the road, save time by predefining columns in a site collection, but avoid some of the technical issues with content types
* Limits you to one document template per library (back to the generic new button)
* Limits you in that all items or documents in a list or library now must have the same columns as each other

Wednesday, January 16, 2008

SharePoint V3: Move Web Application's Virtual Directory Location


You do not like the location of a MOSS web application's virtual directory. For example, maybe it was originally configured in a default location (e.g. C:\Inetpub\WWWRoot\WSS\VirtualDirectories\). Whatever the case, you would like to move a MOSS web application's virtual directory to a new location.


* Backup the source web application and associated site collections (e.g. SQL backup, stsadm site collection backup)
* Create a new web application
Central Admin > Application Management > Create or Extend Web Application
* In the "Create New Web Application" screen, configure the IIS Web Site path to point to the desired location (e.g. D:\VirtualDirectories\)
* Give the new web application a temporary URL (e.g. http://server:port).
* Migrate the content database of the source web application, or restore the site collections of the source web application to the new web application
* Remove the IIS host headers from the source web application, give the source web application a temporary URL (e.g. http://server:port).
* Remove the External URL and alternate access mappings of the source web application.
* Configure IIS host headers on the new web application.
* Configure External URL and alternate access mappings on new web application.
* Delete the source web application.

At this point the web application is restored and has the desired virtual directory file location.

Friday, January 11, 2008

SharePoint V3: Error: Creating Web Application Error


Central Admin > Application Management > Create a Web Application

Error: The path specified cannot be used at this time. (Exception from HRESULT: 0x80070094)

Start > Run > iisreset /noforce

SharePoint V3: Content Type Cons

Ok, so I have spent the last week recreating a SharePoint business application and corresponding Records Center because there still isn't a post SP1 hotfix for the MOSS2007/ContentTypes/Office 2003 compatibility issue.

One thing I did learn in this process is that if you are trying to work around this issue, then removing content types from your libraries is not the way to go. If you disable content types from your document libraries, you will still get the IE script error. You actually have to create new document libraries and leave content types disabled. This means adding site columns directly to the libraries. It also means recreating all the views.

I guess the silver lining to going no content types is at least you are able to template your libraries again. I'm beginning to shift my opinion about content types. They still sound great in a whiteboard design session, but in my recent experiences, they are more trouble than they are worth.

Content Types Cons:
* Cause document libraries to be incompatible with Office 2003
* In a sense, invalidate (or at least limit) document library templates in a multi site collection environment because templates taken are dependant on Content Type which are tied to site collection
* Allow datasheet view users to apply meta data to metadata columns that don't exist
* Are not securable (as sites, web parts, items are)

Monday, January 07, 2008

Links: CodePlex SPSReport

CodePlex SPSReport Releases

Quick Instructions
* Download SPSReport
* Install
* Run
* Select your version of SharePoint
* Select option 4 to capture all events

Links: Microsoft Process Monitor

Microsoft TechNet Process Monitor v1.26 http://www.microsoft.com/technet/sysinternals/processesandthreads/processmonitor.mspx

Sunday, January 06, 2008

SharePoint V3: Preparing for MOSS 2007 Service Pack 1

As I am about to begin testing MOSS 2007 SP1 in some environments ahead of production deployment, I began to ask myself some questions so that I could be more prepared:

Q. What version number is WSS 3.0 SP1 and MOSS 2007 SP1?

Q. Are there any known issues with MOSS 2007 SP1?

KBAlertz.com: After you install the 2007 Office System Servers SP1 or Windows SharePoint Services 3.0 SP1 on a server that has the Foxit PDF IFilter installed, .pdf document types are not indexed

KBAlertz.com: Error message when you try to install 2007 Office System Servers Service Pack 1 (SP1) on a computer that also has Project Server 2007 installed

KBAlertz.com: After you install SharePoint Server 2007 Service Pack 1, the maximum disk space that is used on a query server or on an index server increases to 2.85 times the physical size of the index

Links: SharePoint V3: Performance, Configuring Caching

Microsoft TechNet: Additional performance and capacity planning factors (Office SharePoint Server)

Microsoft Office Online: Configure object cache settings

MSDN: Object Caching

Thursday, January 03, 2008

Links: Microsoft Network Monitor

Download Microsoft Network Monitor 3.1

Microsoft Help and Support: How to use Network Monitor to capture network traffic

Microsoft Help and Support: How to capture network traffic with Network Monitor

Blog Archive