1,804 articles and 14,381 comments as of Tuesday, December 28th, 2010

In SharePoint 2003 the concept of Ghosting and Unghosting described what happened to your files when they were modified or customized. With SharePoint 2007 that terminology and the process by which customizations are handled has changed drastically. Instead SharePoint 2007 and WSS 3.0 are built on top of ASP.NET 2.0 and use the Virtual Page Parser. Thus, the process has changed and so has the name. With the next version of SharePoint right around the corner it’s probably a good idea to use the newer naming convention of Uncustomized/Customized and understand what it’s all about…

SharePoint is really a collection of capabilities. At its heart, it is a Portal that exposes information customized for a particular user. It has extended functionality to quickly build features inside this portal to enable Enterprise Content Management and Enterprise Search. It has ventured into Social Computing and Collaboration by creating shared work spaces, supporting blogs and wikis and allowing people search. With the inclusion of PerformancePoint in its licensing, it also becomes a strong Business Intelligence offering, though it will require expanded knowledge of that capability to implement. It starts to break down when pushed to work as a Business Process Management Suite or Application framework.

You have now connected a SharePoint filter to a single workbook that contains multiple worksheets with multiple pivot tables and are driving all of the pivot table filters with one single filter from the SharePoint Dashboard.

Often as a SharePoint consultant, you are faced with the situation where you can see plainly that a client who is new to SharePoint, is a high risk of condemning their organisation to a path that will end in tears.

In my previous articles on color-coded calendars, the colors have been calculated based on a Choice field. But what if you need more functionality to, say, require approval for certain calendar entries like Personal Vacation.

I have doubts about the version history when renaming and moving files in ShP. In my last post I made observations of version history being changed when renaming a folder and moving a document. Below are new observations of changed version history when renaming a document. Is this acceptable?

Long time reader, Magnus Rygge, has a problem: “We feel very insecure of how we should treat our documentation to keep it reliable for back tracking and knowing what was changed, by who and when.” Here’s his complete problem statement. Hopefully, you can give him some help and guidelines.