Brian Wilson

Check out our new team blog for MCS SharePoint Guru's in the UK!

Brian Wilson — Tue, 06 Jan 2009 21:03:00 GMT

We have just launched the Microsoft UK SharePoint team blog!

With many people contributing to the blog, we hope you will find great content being posted regularly. The focus will be on informative, useful articles based on all things SharePoint covering the full spectrum of development, infrastructure, architecture and best practices. This is going to be an amazing blog!

Other team member's are moving their blogs entirely are:

James Kemp's Collaboration Blog
Martin Kearn' A Marvellous Point
Nigel Bridport's Share Points
Graham Tyler's The Goldfish bowl
Rob Finney's To The Point
Paul Holdaway's Spare Thought
Paul Robinson's SharePoint Treats
Other 'SharePoint guys' that do not currently have a blog

So what is going to happen to my blog?

I plan to keep it going, but make it more personal, which I will detail in a subsequent post. I will contribute to both blogs, in the same way that the official SharePoint product blog works. Joel Oleson, Lawrence Liu, Arpan Shah, Paul Andrew all successfully maintained personal blogs, while still contributing to a team blog. This is what I hope to achieve.

We have already posted an article on UK SharePoint Team called "SharePoint Farm Communications .... Ports, Proxies and Protocols" which talks about inter-farm communications, firewall ports etc within SharePoint. This is a summary of a presentation that was recently given at TechEd 2008 in Barcelona by Martin Kearn.

So sign up to the UK SharePoint Team blog at http://blogs.msdn.com/uksharepoint and enjoy! :)

Office SharePoint Server 2007 : Search : Configuring NTFS permissions for NTFS file share/ folders (that don't inherit permissions) for the search default content access account (xCacls)

Brian Wilson — Thu, 17 Jul 2008 12:26:00 GMT

Here is a step by step guide (I had to write it up anyway J ) to configuring permissions for the search default content access account for NTFS folders that have many folders and files that don’t inherit permissions on your network.

1. Download XcAcls.exe (cAcls is depreciated and does not support batch files)

This command-line tool allows you to set all file system security options that are accessible in Windows Explorer. XcAcls does this by displaying and modifying the access control lists (ACLs) of files. XcAcls is especially useful in unattended installations of Microsoft Windows 2000 Professional or Server. By using this tool, you can set the initial access rights for folders in which the operating system resides.

http://www.microsoft.com/downloads/details.aspx?familyid=7a3e2241-d7d0-42b6-b86e-6eda88726c01&displaylang=en

2. Install tool using setup program

3. Configure environment variable so that you can call xcAcls from any folder in command prompt

· Navigate to the install location: e.g. “C:\Program Files\Resource Kit” and copy this path into your clipboard.

· Open up your machine’s environmental variables (Right Click my Computer, Properties )

· Open the Path variable and append the install location to the path. Be sure to add a trailing semi colon.

· Hit Ok 3 times.

4. Add the default search access account using the xCacls utility.

a. Fire up a command prompt. Ensure that it is running under user privileges that have access rights to the folder structure you want to change.

· To fire up a command prompt in a specific user context : “runas /user Domain\username”. E.g. “runas /user CORPDOMAIN\networkfileshareadminaccount”

b. Execute the following command : xcacls C:\FOLDERSTRUCTURE\BASEFOLDER /T /E /C /G YOURDOMAIN\SEARCHCONTENTACCESSACOUNT:R /Y

For the exact meaning of each parameter:

· /T recursively walks through the current folder and all of its subfolders, applying the chosen access rights to the matching files or folders.

· /E edits the ACL instead of replacing it. For example, only the administrator will have access to the Test.dat file if you run the XCACLS test.dat /G Administrator:F command. All ACEs applied earlier are lost.

· /C causes Xcacls.exe to continue if an "access denied" error message occurs. If /C is not specified, Xcacls.exe stops on this error.

· /G user:perm;spec grants a user access to the matching file or folder.

o R Read

o C Change (write)

o F Full Control

o P Change Permissions (special access)

o Take Ownership (special access)

o X EXecute (special access)

o E REad (Special access)

o W Write (Special access)

o D Delete (Special access)

· /Y disables confirmation when replacing user access rights. By default, CACLS asks for confirmation. Because of this feature, when CACLS is used in a batch routine, the routine stops responding until the right answer is entered. The /Y option was introduced to avoid this confirmation, so that Xcacls.exe can be used in batch mode.

Result : All folder and files below and including the parent folder (e.g. basefolder) will be have the specified account added to their security settings. This includes files and folders that are set to not inherit permissions from their parent.

Please don’t forget to test first on isolated folder structure first.

Branding Office SharePoint Server 2007

Brian Wilson — Sun, 13 Jul 2008 21:54:00 GMT

Branding

What is branding? Branding is how you apply an organization's identity to an existing software application through customization of a portal site.

Business Drivers

Establish corporate identity and ownership

With the portal site home page becoming the primary interface between employees, customers and their Web, you should assure that it reflects and reinforces the organization's identity. Portal site users should understand intuitively that they are using an enterprise resource. Users should feel that they are interacting with the organization's portal site rather than a standard software application.

Reinforce enterprise standards

Your organization’s Web site represents your organization just as officially as your Annual Report. A number of organizations have made significant investments in the development of standards to guide the creation of their Web sites. These standards include logos and images, colors, fonts, page layouts, and navigational models. Because a portal site is at the center of an organization's intranet, it must adopt such standards. Standards should promote a common look and feel throughout the organization's Webs to make it easier for users to navigate and find the information they need to do their jobs.

For ease of use

A corporate intranet and Internet site is commonly made up of many different sites, created by diverse parts of the organization using a variety of tools. Any branding effort must ensure the greatest possible consistency with existing sites. You should always place higher priority on usability than on look and feel. A solution's look and feel refers to the visual, attractive elements of its interface; usability, however, is about making it easy for end users to interact with and use the interface.

To create a sense of place

Corporate intranets and Internets can be made up of many loosely connected sites, so any branding effort should communicate a clear "sense of place" to your users so they can understand where they are within the portal site quickly. Common approaches to solving this problem include elements such as breadcrumbs, navigation tress, and page titles.

Branding Standards

Branding of a portal site is the application of an organization's identity to an existing software application through customization of the portal site. It is an important requirement for any portal implementation and it has a significant impact on the end user experience. You typically brand a portal site to meet your organization's intranet and Internet standards and guidelines. By definition no two implementations are the same, making it important to understand both the capabilities of the chosen portal platform and the specific organization requirements.

Following are some common branding requirements (or standards) described by organizations in their intranet and Internet design guidelines.

Color and Style

Applying color and style are the most fundamental elements of branding. You should consider any organization requirements in this area to be essential and probably governed by very strict guidelines. Apply these elements of a brand completely and consistently throughout any solution.

Banner or "Brand Box"

The most common branding requirement is developing a page "banner," also known as a "brand-box" or page "header." This element is common to all pages and most organizations will already have a design in place.

Navigation

Organizations have various requirements for site navigation, typically including one or more horizontal and vertical menus. The location of these menus varies; in particular, you can place the horizontal menu along the very top of the page or immediately below the banner. Menu style also varies; some organizations prefer a "fly out" style, others a collapsible style, and still others their own custom design.

Page Layout

Organizations often have one or more standard screen layouts. These are page designs that define where to position elements such as navigation, banner, footer, and body on a page. You must accommodate any number of these page designs within the portal site design, promoting consistency throughout the intranet and in turn making it easier for people to use.

Features and Functionality

Different organizations refer to certain product features in different ways. For example, some customers refer to items added to the portal site as "News," while others prefer to call these items "Announcements." Accommodating these vocabularies can have a significant impact on overall ease of use. In addition, some organizations want to emphasize some product features over others, making some more obvious or discoverable. These same features may not be relevant to other organizations who may want to hide them altogether. Finally, you must take care to ensure full support for accessibility standards, screen resolutions, and different types of browser.

How SharePoint Renders a Page

Imagine that you have a fictional Web site called foo.com and this is Welcome page for the site.

The Welcome page for the site has been requested by the user.

The table at the bottom of the slide represents the Web page and its content, for example Title or Image. In SharePoint this page is represented as an item in a SharePoint library with a content type that defines what fields are available in the page.

When the request comes in to Welcome.aspx the page has a column defining the view. While the page defines the content it does not own the presentation of the content. For presentation the page must look up its associated page layout. The page layout is another server side .aspx that lives in the database and it defines the view or presentation of the content, for example where the title goes or where the image goes. The Page layout executes controls that render the title, the body, the description from page fields in the page item.

The Page layout doesn’t fully own presentation of content. It must also use a Master Page that defines the common shared look and feel across the site, for example the logo and the positioning of the logo or the presence and position of the search box at the top. Any element that appears across your site will be stored in the Master Page which is also a server side .aspx in the database.

One of the important points in this page rendering process is that data is separate from view. This enables you to make changes easily across your sites.

For example, what if you have a site with 1000 article pages and Corporate Communications decides to replace the image or to change the placement of the image from left to right? You only need to update one page layout and the required change will be reflected in all 1000 article pages. Or what if Corporate Communications decides to update the look of your logo and to change the corporate colors? Again all you need to do is make these changes on the Master Page and these changes will be reflected throughout your site.

The second important point is that since these pages are part of a SharePoint library they inherit all the SharePoint library features. The page model takes advantage of all underlying SharePoint support capabilities, including versioning, check-in and check-out, and workflows.

Site Structure and Page Model

Let’s do a quick review of what it means to have a Web site using this page model.

l Sites are a collection of Webs

Ø The Webs are arranged in a hierarchy

Ø Hierarchy controls navigation and security

l Each Web has a document library for Pages

l Page Layouts, Master Pages are stored in the root Web
Master Page Gallery

l CSS files stored in the root Web Style Library

In the previous module we learned how the site structure is a hierarchy of SharePoint Webs. We also learned that Webs are container objects that can contain libraries or other Webs and that each Web has a library called pages where the page items mentioned in the previous slide are stored. This represents the content of the site but what about the presentation?

All the elements that define how the content of your site will appear are stored in the root Web highlighted here in blue. These elements include Page Layouts, Master Pages, and CSS stylesheets which we’ll look at in greater detail in this module. These elements are stored in a Master Page Gallery which is a document library in the root site of the site collection and are shared across the Web site. The Master Page Gallery stores all the chrome master and page layouts used to control branding and authoring. This document library supports views, versioning, check in, check out, and workflows as does any other SharePoint list.

Together, this hierarchy of Webs with their libraries and the items in their libraries using the common SharePoint elements define the Web site and its Web pages.

Branding SharePoint 2007

Office SharePoint Server 2007 enables branding by separating content from display through the use of Master Pages, Pages Layouts and CSS styles. Branding is controlled in one place and applied top-down in your Web site and you can restrict authors to create pages that comply with your branding through the use of Page Layouts and control restrictions.

Master pages provide the look and feel and standard behavior that you want for all of the pages in your site. Page layouts contain field controls that allow content to be edited and rendered for display. They also reference a master page and host field controls that bind to fields on the master page list item. Together with content pages, they produce output that combines the layout of the master page with content from the content page.

Because Windows SharePoint Services is built on top of Microsoft ASP.NET 2.0, it supports master pages for defining elements that are common to all pages. You can specify all of the shared elements of your site in the master page or pages, and add content page-specific elements to content pages. Using master pages gives you a single-location ability for change. You can make design changes in one place and propagate the changes to all pages that use the master page.

CSS styles can be used to define and change the look and feel of items on the page.

Summary

l SharePoint separates content from display

l Master Pages provide the look and feel

Ø ASP.NET 2.0 Master Pages control look and feel of the Web site

l Page Layouts provide the template for rendering

Ø Reference a master page for global navigation and chrome

l CSS styles

Ø Alternate CSS setting allows for CSS overrides independent of master page used

Master Pages

Remember that in the page rendering process we looked at earlier, the Page layout executes controls that render the title, the body, the description from page fields in the page item, but the Page layout doesn’t full own the presentation of content. The Page Layout must also use a Master Page that defines the common shared look and feel across the site. We mentioned Master Pages earlier in the day and used some of the functionality of Master Pages especially in the Navigation module. Now we’re going to cover Master pages in greater depth, and we’ll look at the Page Layout template later in this module.

Master pages are a feature of ASP.NET 2.0. When a user requests a content page, it is merged with a master page to produce output that combines the layout of the master page with the content from the content page. All content pages share the same page structure—the global breadcrumb, site title area, top navigation, page title area, and left navigation bar. This shared page structure is contained in the master page called default.master, which is used by all content pages.

In addition to static text and controls that appear on all pages, a master page also includes one or more System.Web.UI.WebControls.ContentPlaceHolder controls, which define regions where replaceable content can appear. In turn, the replaceable content is defined in content pages.

Imagine, for example, that you want every page in an application to use the same layout along with a standard header and navigation menu. In that case, you can create one Master Page with the desired layout and base all the pages in the application on the Master Page. By creating a single Master Page, you avoid performing the work of duplicating the common content for each page. Also, if you decide to change the layout of all the pages in the future, you need to modify only the single Master Page.

You create a Master Page by creating a page with a .master extension. A Master Page can contain almost anything that you can include in a normal ASP.NET page. What makes a Master Page special is the fact that it can contain one or more <asp:ContentPlaceHolder> controls. The <asp:ContentPlaceHolder> controls indicate regions of replaceable content in the Master Page.

You can base any ASP.NET page on a master page template simply by adding a directive to the page (for example: <%@ Page Master=”SiteLayout.Master” %>). The ASP.NET page can then optionally override any of the <asp:ContentPlaceHolder> regions declared within the Master Page. At runtime a single merged page will then be sent down to calling browser clients.

Customizing a SharePoint Master Page

There are supported scenarios for customizing master pages:

Copy the default.master file that is installed with Windows SharePoint Services to another file and make your changes to your renamed file. This option is considered a Best Practice since you may want to use the default.master file later.
Edit the default.master page in Microsoft Office SharePoint Designer 2007 where you can edit master pages, view master pages, create content pages, and view content pages with the master pages marked as masters and read-only.
Follow the MSDN guidance:

· How to: Create a Minimal Master Page - http://msdn2.microsoft.com/en-us/library/aa660698.aspx

· Page Layouts and Master Pages: http://msdn2.microsoft.com/en-us/library/ms543497.aspx

· http://www.heathersolomon.com/blog/

When a new site is created, it uses the default master page that is located in the file system. If a master page is customized using Office SharePoint Designer, Windows SharePoint Services stores a modified version of the master page in the content database.

Page Layouts

l Page layouts provide the template for rendering

Ø Reference a master page for global navigation and chrome

Ø Can have many layouts per content type

l Define what can be authored in the page:

Ø Field controls

Ø Web Parts

Ø Web Part zones

l Define how much control the author has over page content’s look and feel

Ø Turning on restrictions on field controls

Ø Wrapping controls in CSS classes

As we said earlier the Page Layout selected for a content page calls the appropriate Master Page. Now we will discuss the Page Layout in greater detail.

A page layout is a template that is used in conjunction with a master page to control the look, feel, and content of a page. Each page layout has an associated content type that determines the kind of content that can be stored on pages based on that page layout. Microsoft Office SharePoint Server 2007 provides three default publishing content types: Page, Article Page, and Welcome Page.

Imagine, for example, that you have 1000 article pages with an image on the right and that Corporate Communications has decided the image should now appear on the left. In that case, you need to modify only the single Page Layout. You can modify the Page Layout with the desired layout and all the article pages with that layout will reflect the new layout standard.

All page layouts reference a master page that is based on the SPWeb.CustomMasterUrl of the SPWeb class. If multiple Master Pages are available, the page layout determines which Master Page is called for the particular page. All page layouts host controls called field controls that bind to fields on the master page list item. You can use the default controls or build custom ones. Field controls allow content to be edited and rendered for display, just as placeholder controls in MCMS 2002 do.

Page layouts can be used by all page instances that are based on that page layout. Page instances based on the same page layout in different sites can use different master pages.

Page layouts are stored in the Master Page and Page Layout Gallery, a document library that is created when you install Office SharePoint Server 2007. By default, Office SharePoint Server 2007 creates a master page gallery for every site; however, you can only create new pages with the page layouts stored in the master page gallery of the top-level site in the site collection.

As with any type of document stored in a SharePoint library, you can use versioning, check-in and check-out, workflow, and other features on page layouts. These features are available from within the master page gallery. The master page gallery is secured to limit the rights of most users, except those users with designer or higher permission rights.

CSS Styles

l Customized CSS only applies to current Web

l To apply to all Webs in Microsoft^® Office SharePoint^® Server 2007

Ø Make independent CSS file just with style overrides

Ø Reference it in custom.master and/or default.master (after CssLink control)

Ø Choose site setting to push down masters to all subwebs

Graphic Design Requirements

Consider what graphics and graphic design you require for your site:

· Will your site require banner images of specific sizes?

· Will your site require highly customized images that define the very look and feel of the site? For example, these may be curves that are positioned and lined up with other custom images via html to represent a corporate brand or look and feel.

· Do you have graphics development and creative site design skills required?

· Do you require high optimization of your images (to minimise total page download size) for internet /extranet site scenarios?

Sites that are highly visible (intranet home page) or sites that provide a specific service are good candidates for highly crafted User Interface design.

Examples of these are:

· Corporate

o Corporate Portal Theme

o Corporate Site Theme(s)

· Point Solution (Business Driver Sites)

o Library

o Search Centre

o Press Centre

o Research Centre

o Company Division

o Etc

Interaction Level

Some sites in your organisation may require a high degree of interactivity and as a result may require use of the following rich / interactive media:

· Video

o Video Streaming

o Web Casts

o Interactive Media Manager

· Audio

o Audio Streaming

o Pod Casts

· AJAX

· Silverlight

· Adobe Flash

· SoapBox / YouTube integration

· Virtual Earth / Google Maps

For each of the above, consider:

· Load on your environment

· Return on Investment (ROI) and Total Cost of Ownership (TCO)

· Level of complexity required to maintain and grow.

· Reliability of external services

· Maturity of technologies (against future potential of the same technology).

· Skill set required to develop.

· Skill set required that you need to retain to maintain and progress solution

Navigation

Exterior navigation refers to the navigation elements across a set of sites collections and sites. Examples include: Site and Page Navigation, Breadcrumbs.

Interior navigation refers to navigation elements placed within a site, such as the Table of Content Webpart, Content by Query Webpart, Links Webpart. This may take the form of aggregated links from sub sites to a list of links.

Exterior Navigation

In Office SharePoint Server 2007 the site structure is a hierarchy of SharePoint Webs which controls navigation. Webs are container objects that can contain other objects, such as lists, libraries or other Webs. The Webs are arranged in a hierarchy and this hierarchy controls the navigation and security. Each Web has a library for Pages which represent the content of the site.

Portals are a collection of Windows Server System Webs

The Webs are arranged in a hierarchy
Hierarchy controls navigation and security

Each Web has a document library for Pages
Page layouts are stored in the root web Master Page Gallery
CSS, XSLT are stored in the root web Style Library

The goal of navigation in Office SharePoint Server 2007 is to generate dynamic page navigation from the structure of the site. The hierarchy of sites and pages defined in the left-hand side of this slide defines the different levels as they appear to the user displayed here on the right. In the next module we’ll see how these are actually Master Page controls. Pages are dynamically added to navigation and static Authored links to external or internal resources can also be added.

In the example below you see some of the controls typically displayed on a page: a top navigation bar with a highlighted breadcrumb and a menu with fly outs. The goal of navigation is ease of use and transparency so when you create a new subsite in this hierarchy—for example under Investors—the new subsite will automatically appear on the page as part of the navigational structure. In this example, it appears in the fly out. Pages are also dynamically added. And you can display Authored links to any resource within your Internet or any rendered http:// link.

Behind the cover, Microsoft Office SharePoint Server 2007 takes advantage of Microsoft ASP.NET 2.0 pluggable navigation—the Site Map Provider model—to make it easy to build effective menus and navigation. Essentially the provider extracts the hierarchy from the site map and then data sources plug into the hierarchy at any level to display the navigation and controls.

You use a site map to describe the logical structure of your site. You can then manage page navigation by modifying the site map as pages are added or removed, instead of modifying hyperlinks in all of your Web pages. The ASP.NET controls display navigation menus on your Web pages and these navigation menus are based on the site map.

In Office SharePoint Server 2007, you can replace the default navigation provider with your own. You can also configure multiple navigation providers for a site. You can even configure your navigation provider to create a navigational structure targeted to audience type, so that you can provide different audiences with custom navigation.

Interior Navigation

Several controls for interior navigation:

For rolling up pages in a particular subsection of the site, SharePoint Server provides the Table of Contents control. This control allows authors to create and style a hierarchical view of pages.

· Provides a “site map” view of a site

· Uses data from the navigation sitemap provider

Content by Query

It is often useful to generate a list of links to a series of pages through the site, based on a fixed set of criteria. For example, it might be useful to display a list of the five most recently published press releases about a particular product on the overview page for that product. To accomplish this SharePoint Server provides the Content By Query control. This control allows users to easily define queries that return links to pages that match certain criteria and then style the results.

· Links to content based on a query

· For example, display latest 5 KB articles for SharePoint Server

Summary Links

For selecting links through the site, and from external sites, the Summary Links control enables you to create summaries that include a link, description, and an image, and to set a display style for the summary. Summary links can be organized into groups and sorted using drag and drop.

· Authored links to content

· Same visual styles as Content by Query

Web Parts in Office SharePoint Server 2007

Brian Wilson — Sun, 13 Jul 2008 21:41:00 GMT

Web Parts

When adding functionality to existing and new sites, it is important to be able to decide between “use Out of the Box”, buy 3^rd Party Web Parts, use Community Web Parts, or custom develop the webpart from scratch or by taking community Web Parts in house.

Overview

· Use and configure Out of the Box Web Parts à Realise value from existing investment.

· Buy 3^rd Party SharePoint Solutions depending on support model and code access/ functionality request availability.

· Use Community Web Parts with restrictions

· Develop your own Web Parts

Deciding between Third Party versus Custom Web Part development

· When deciding whether to buy a 3^rd Party web part or custom develop a Web Part , weigh up following criteria:

o cost of buying the webpart

o support model available

o Web Part provider company

§ Availability (Email only; telephonic; 24 hour?; on site)

§ Location

§ Time Zone

§ Can this company understand your native language?

§ Source Code License?

§ Feature Request framework in place: Can a customer request and pay for new functionality required for the Web Part?

o Complexity of the webpart

o Do you have access to the source code? (Even if under license)

o Keep in mind future changes you may require to the webpart when buying.

Deciding whether to use Community Web Parts

· As a rule of thumb, the answer should always be NO until explicit permission is given for each webpart by your change control governance board.

· Community Web Parts are awesome, but pose a risk to your environment that needs to be managed.

· There are a bunch of high value, FREE Web Parts available for download from sites such as CodePlex, and SharePoint blogs. Most of them provide the source code to allow you to take the Web Part in house.

· Don’t rule them out completely, always seek to reuse IP, rather than build complex functionality from scratch.

· Analyse performance, security, code of community webparts. Don’t simply trust that they will work.

· Test, test, test in test environment before releasing into your Production environment.

· Assess, assess, assess impact on performance in production

Third Party / Community developed Web Part Sources

Disclaimer:

1. This is not a comprehensive list of web parts available. It is intended to be a starting point that should be expanded and maintained as you learn about new web parts from 3^rd Parties and Community Sources.

2. It is not an endorsement of any particular product over another product in the market. It merely represents my subjective experience and exposure to these products. Therefore, you should always aim to perform a diligent search for Web Parts and their competing solutions.

Sites

Mark Kruger, MVP has a fantastic list of 3^rd Party Web Parts:

http://www.sharepointblogs.com/mkruger/archive/2007/06/26/free-sharepoint-web-parts-3rd-party.aspx Some of these were developed for WSS 2.0 and some for WSS 3.0. WSS 2.0 can still be used and deployed in WSS 3.0 however ensure you test and check that the functionality works in your environment.

Ian Morrish http://www.wssdemo.com/default.aspxThis is a fantastic site that has tons of demos for you to view and links to SharePoint resources on the web.

Bamboo Solutions: http://store.bamboosolutions.com/

CorasWorks: http://www.corasworks.net/Products/

CodePlex: http://www.CodePlex.Com CodePlex is Microsoft's open source project hosting web site. Start a new project, join an existing one, or download software created by the community.

SharePointPedia: http://www.SharePointPedia.Com This site contains links to tons of SharePoint resources, including web parts. SharePointPedia.com is a web site where people discover and share useful content about SharePoint and SharePoint related products and technologies.

Web Parts

SharePoint Forums Web Part: http://www.codeplex.com/SPFORUMS.
Community Kit for SharePoint : http://www.codeplex.com/CKS.
RSS FeedReader: http://www.codeplex.com/FeedReader
WCM Web Parts: http://www.codeplex.com/SPWCMWebParts
Navigation Web Parts: http://www.codeplex.com/sharepointnavigation

Develop your own Web Parts

Web Parts in Windows SharePoint Services provide developers with a way to create user interface elements that support both customization and personalization. A site owner or a site member with the appropriate permissions can customize Web Part Pages using a browser or Microsoft Office SharePoint Designer 2007 by adding, reconfiguring, and removing Web Parts.

The term customization implies that changes are seen by all site members. Individual users can further personalize Web Part Pages by adding, reconfiguring, and removing Web Parts. The term personalization implies that these changes will be seen only by the user that made them. Developing custom Web Parts provides an easy and powerful way to extend Windows SharePoint Services sites.

Because the Windows SharePoint Services Web Part infrastructure is now built on top of the ASP.NET 2.0 Web Parts control set, you can reuse your knowledge of ASP.NET programming to create quick and robust custom Web Parts.

Following are some ways in which you can use custom Web Parts:

· Creating custom properties you can display and modify in the user interface.

· Improving performance and scalability. A compiled custom Web Part runs faster than a script.

· Implementing proprietary code without disclosing the source code.

· Securing and controlling access to content within the Web Part. Built-in Web Parts allow any users with appropriate permissions to change content and alter Web Part functionality. With a custom Web Part, you can determine the content or properties to display to users, regardless of their permissions.

· Making your Web Part connectable, allowing Web Parts to provide or access data from other connectable Web Parts.

· Interacting with the object models that are exposed in Windows SharePoint Services. For example, you can create a custom Web Part to save documents to a Windows SharePoint Services document library.

· Controlling the cache for the Web Part by using built-in cache tools. For example, you can use these tools to specify when to read, write, or invalidate the Web Part cache.

· Benefiting from a rich development environment with debugging features that are provided by tools such as Microsoft Visual Studio 2005.

· Creating a base class for other Web Parts to extend. For example, to create a collection of Web Parts with similar features and functionality, create a custom base class from which multiple Web Parts can inherit. This reduces the overall cost of developing and testing subsequent Web Parts.

· Controlling the implementation of the Web Part. For example, you can write a custom server-side Web Part that connects to a back-end database, or you can create a Web Part that is compatible with a broader range of Web browsers.

Deciding whether to create ASP.NET Web Parts versus SharePoint Web Parts

When you are creating Web Parts for Windows SharePoint Services, you have the option of creating Web Parts that inherit from System.Web.UI.WebControls.WebParts.WebPart (recommended) or the Windows SharePoint Services WebPart class.

(The Windows SharePoint Services WebPart class was available in Windows SharePoint Services 2.0, and was part of a Web Part infrastructure that was designed specifically for SharePoint sites.)

Now that Windows SharePoint Services fully supports the Microsoft ASP.NET 2.0 Web Part infrastructure, you should design Web Parts that inherit from the ASP.NET 2.0 System.Web.UI.WebControls.WebParts.WebPart base class whenever possible. Web Parts such as these are known as ASP.NET Web Parts, and can be used in Windows SharePoint Services applications whether Windows SharePoint Services is involved or not, making them highly reusable.

Note: If you are creating your Web Part specifically for a SharePoint site, and it will consume the Windows SharePoint Services object model, you can derive from the ASP.NET System.Web.UI.WebControls.WebParts.WebPart base class and add a reference to the SharePoint object model in your project.

For more information about creating ASP.NET Web Parts, see Web Parts Control Set Overview in the ASP.NET documentation.

When to Derive from the Windows SharePoint Services WebPart Class

In a very few cases, you may have to create Web Parts that support Windows SharePoint Services features that are not available in the ASP.NET Web Part infrastructure. In these cases, you can create a class that inherits from the Windows SharePoint Services WebPart base class. Web Parts such as these are known as SharePoint Web Parts and can only be used in SharePoint sites.

Note: The Windows SharePoint Services 3.0 Web Part functionality is essentially unchanged from Windows SharePoint Services 2.0.

Following is the list of features provided exclusively by the Windows SharePoint Services WebPart class:

· Cross page connections

· Connections between Web Parts that are outside of a Web Part zone

· Client-side connections (Web Part Page Services Component)

· A data caching infrastructure that allows caching to the content database

Another reason you may consider deriving from the SharePoint WebPart class is related to creating new versions of your Web Parts. If your original Web Part derived from the SharePoint WebPart class, and you want to upgrade instances of that Web Part to a new version, then the new version of the Web Part should also derive from the SharePoint WebPart class.

Features in Office SharePoint Server 2007

Brian Wilson — Sun, 13 Jul 2008 21:35:00 GMT

Features

Feature framework is an innovation to enhance modular provisioning. It works by grouping logical elements into scenario-driven “features”.

l Features can be add to and reused across site definitions

l New features can be activated in existing site to add functionality

l Features scoped at web, site ,web application and farm.

l Features need to be installed before they can be activated, via stsadm.exe or custom code using SharePoint API

l Once installed, a user can activate or deactivated feature in context of site or site collection

Features are composed of XML files and .aspx files

l XML in CAML

l Features have ID, name, scope

l Features are composed of elements

l Generate GUID using Visual Studio 2005

Feature Dependencies

Features can be designed with dependencies: Allows one feature to assume another feature is present Example: Feature B might depend on feature A.

l B should be written with activation dependency on A

l Activating B forces A to be activated as well

l Deactivating B results in deactivation of A

Features can be defined as hidden; this will hide the feature from users in administration pages, however it can still be activated via dependencies

Features and Site Definitions

Features add modularity to site definitions: Site definitions can include feature references, e.g. Lists, document libraries, content types, etc.

Activating Features via the UI

Feature elements can add commands to WSS 3.0 UI:

l Extensible to site settings, action actions, menus, ECB, etc.

l Performed using SiteActions menu elements with Url Action

l ECB menu associated by list type, content type or file type

Feature Site Template Associations a.k.a. Feature Stapling

l Enables you to include a specific feature as part of a site definition when you provision sites through the site definition

l Preserves original out of the box definitions

l Keeps customer environment in a supported state

l Makes it easier to manage customizations in customer environments

l Reduces development and deployment time

Examples of where SharePoint can be extended using Features (based on scope):

Farm Elements

l Item Custom Actions

l Site Settings Links

l Admin Custom Actions

Web Application elements

l Item Custom Actions

l Site Settings Links

l Admin Custom Actions

Site Elements

l Site Settings Links

l Site Web Part Definitions

l Workflow Definitions

l Site Content types

l Site columns

l Files [provisioned to root web]

l List Instances [provisioned to rootweb]

Web Elements

l List Definitions + Forms + Views

l List Instances

l List Item Events

l Item Custom Actions

l Web Admin Custom Actions

l Files

Field Definitions in SharePoint Server 2007

Brian Wilson — Sun, 13 Jul 2008 21:30:00 GMT

Fields

A column template is a collection of well-known instances of particular fields—in other words, a shared field definition. A shared field includes settings for that field, such as the set of choices for a choice field, or whether rich text is supported for a text field.

An example of a shared field would be "Specification Status," which has standard choices such as "One Page," "Draft," "Reviewed," and "Inspected." Each team in a deployment can reuse this custom property definition on their site.

Shared fields are a provisioning concept referred to by content types, such that if you provision a site collection with two separate content types that use the same shared field, the provisioning script for those content types instantiates the exact same field, and each field instance shares the same unique identifier.

Possible scopes:

· Farm: No

· Web Application: No

· Site Collection: Yes

· Web Site: No

For general information about column templates and how they function within Windows SharePoint Services, see Introduction to Columns. For information about the file format used in column templates, see Content Type and Column Template Definition Files.

· Fields: http://msdn2.microsoft.com/en-us/library/ms426306.aspx

· Introduction to Columns - http://msdn2.microsoft.com/en-us/library/ms450825.aspx

· Column Definition Schema Overview - http://msdn2.microsoft.com/en-us/library/ms459922.aspx

· Field and Field References - http://msdn2.microsoft.com/en-us/library/aa543680.aspx

· FldTypes.xml - http://msdn2.microsoft.com/en-us/library/ms469928.aspx

· Updating Site Columns - http://msdn2.microsoft.com/en-us/library/ms466937.aspx

· SharePoint 2007 Features – Creating Site Columns and Content Types - http://sharethispoint.com/archive/2006/07/17/11.aspx

List Definitions versus List Templates and deciding on the correct customization approach

Brian Wilson — Sun, 13 Jul 2008 21:18:00 GMT

List Definitions

A list template Feature includes a Schema.xml file that serves as the base file for a list definition. The List element is the root element of a Schema.xml file, which contains default view definitions, definitions for special fields used in the list, the toolbar definition for list views, content type declarations, and other metadata for the list.

A list definition includes a Feature.xml Files file, an element manifest file (see List Template Files), and a Schema.xml file within a Feature folder (\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES). For an example that shows how to create a custom list definition, see how to: Create a Custom List Definition: http://msdn2.microsoft.com/en-us/library/ms466023.aspx

Lists can be created or modified programmatically through the object model (for example, members of the SPList and SPListCollection classes), through the Lists Web service (methods of the Lists class), and through Remote Procedure Call (RPC) protocol (see Microsoft Windows SharePoint Services RPC Methods).

Introduction to Lists: http://office.microsoft.com/en-us/sharepointtechnology/HA100242741033.aspx?pid=CH101787241033

List Schema: http://msdn2.microsoft.com/en-us/library/aa543477.aspx

Major Schema Definition Files: http://msdn2.microsoft.com/en-us/library/ms479188.aspx

List Templates

A list template is something the end user can create by using the web interface to configure the list. This list can then be saved as a list template. This list template is stored as an *.STP file in the list templates gallery of the Site Collection. This *.STP file is stored in the content database the Site Collection resides.

This file contains all the customizations made to the original List Definition, such as CAML and XML that describes the lists. The customizations require the same list definition to be installed on the server that was used to configure the list templates.

It is not as performant as a pure list definition as list definitions are cached on start of IIS on the web front ends while list templates are stored in the Content Database, They need to be fetched from the content database and merged with the list definition code at runtime to render the list.

Deciding Between List Definitions and List Templates

Custom list definitions hold the following advantages over list templates:

· Data is stored directly on the Web servers, so performance is typically better.

· A higher level of list customization is possible through direct editing of a Schema.xml file.

· Certain kinds of customization to lists require use of site and list definitions.

List definition disadvantages include the following:

· Customization of list definition requires more effort than configuring list templates.

· Editing a list definition after it has been deployed is difficult.

· Doing anything other than adding code can break existing sites.

· Customizing list definitions requires access to the file system of the front-end Web server.

List templates hold the following advantages over customization of list definitions:

· List templates are easy to create.

· Almost anything that can be done in the user interface can be preserved in the template.

· List templates can be modified without affecting existing sites that have been created from the templates.

· List templates are easy to deploy.

List template disadvantages include the following:

· List templates are not created in a development environment.

· List templates are less efficient in large-scale environments.

· If the List definition on which the list template is based does not exist on the front-end server or servers, the list template does not work.

Site Definitions versus Site Templates and deciding on the correct customization approach

Brian Wilson — Sun, 13 Jul 2008 21:02:00 GMT

Site Definitions

l A site definition is the core definition of what a site is in SharePoint.

l A site definition is installed on file system of web front ends, located at ..\12\Template\SiteTemplates. This directory is language-neutral.

l A site definition consists of .aspx pages and .xml files with Collaborative Application Mark-up Language (CAML).

l A major benefit is that the Page and List definition is read locally from the file system, not from Content Database.

l A site definition Page and List definition are cached at IIS process startup

l Customizations made to site definition are stored in content database, not on the file system. This can be performed via SharePoint Designer, or when custom site templates are saved.

l are developer created

l Localization: WSS 3.0 supports full site template localization (based on ASP.Net 2.0 via XML files and .ASPX files pulling strings from RESX files. Therefore solutions can be shipped “language packs” of resource files.

l “Global Template” defines commonality across site definitions; it gets called before any other template. It works by injecting common provisioning content into all new sites. ONET.XML file defines base types, galleries, mobile redirects

· Site Definitions and Configurations - http://msdn2.microsoft.com/en-us/library/aa978512.aspx

· CAML - http://msdn2.microsoft.com/en-us/library/ms462365.aspx

Site Template

A site template (*.stp file) is created through the user interface or through implementation of the object model. It is a package containing a set of differences and changes from a base site definition.

The site template package is stored as a CAB-based file that can be downloaded or uploaded to site collections by users with the appropriate rights. As before, site templates offer a measure of portability to SharePoint Applications.

It is not as performant as a pure site definition as site definitions are cached on start of IIS on the web front ends while site templates are stored and hence need to be fetched from the content database and merged with the site definition code at runtime to render the site.

Also note that if you plan to transfer a site template to separate farm, that the farms have the same versions installed of SharePoint installed. (hotfixes,etc.) This is due to the dependence site templates have on the original base site definition they were created from.

Deciding Between Site Definitions and Custom Site Templates

See : http://msdn2.microsoft.com/en-us/library/aa979683.aspx

When choosing whether to create a site template or a site definition, first consider the following issues:

· Are the changes you need to make simple or complex? If, for example, you need to make only minor changes in the look of certain pages and add a few fields in particular lists, you should create a custom site template. However, if you need to create new content types, add new Web Part definitions, and significantly restructure sites, you should create a custom site definition.

· Can you deploy changes to the front-end Web server? If you do not have access to the file system of the computers running Windows SharePoint Services, you have no choice but to create a custom site template.

Custom site definitions hold the following advantages over custom templates:

· Data is stored directly on the Web servers, so performance is typically better.

· A higher level of list customization is possible through direct editing of a Schema.xml file.

· Certain kinds of customization to sites or lists require use of site definitions, such as introducing new file types, defining view styles, or modifying the Edit menu.

Site definition disadvantages include the following:

· Customization of site definition requires more effort than creating custom templates.

· Editing a site definition after it has been deployed is difficult.

· Doing anything other than adding code can break existing sites.

· Users cannot apply a SharePoint theme through a site definition.

· Users cannot create two lists of the same type with different default content.

· Customizing site definitions requires access to the file system of the front-end Web server.

Custom templates hold the following advantages over customization of site definitions:

· Custom templates are easy to create.

· Almost anything that can be done in the user interface can be preserved in the template.

· Custom templates can be modified without affecting existing sites that have been created from the templates.

· Custom templates are easy to deploy.

Custom template disadvantages include the following:

· Custom templates are not created in a development environment.

· Custom templates are less efficient in large-scale environments.

· If the site definition on which the custom template is based does not exist on the front-end server or servers, the custom template does not work.

How to install multiple language packs for Office SharePoint Server 2007

Brian Wilson — Sat, 12 Jul 2008 18:32:00 GMT

Hi,

Here are the instructions to provide support for multiple languages in your SharePoint farm.

1) Pre-requisite: Install additional language file support

1. On your front-end Web server, click Start, point to Settings and then Control Panel, and then click Regional and Language Options.

2. In the Regional and Language Options dialog box, on the Languages tab, in the Supplemental Language Support section, select one or both of the following checkboxes:

o Install files for complex script and right-to-left languages

o Install files for East Asian languages

3. Click OK in the dialog box that alerts you that additional disk space is required for the files.

4. Click OK to install the additional language files.

5. When prompted, insert your Windows Server 2003 product disc or provide the location of your Windows Server 2003 installation files.

6. When prompted to restart your computer, click Yes.

2) Install each Language Pack in the following order:

For each language:

WSS Language pack (SharePointLanguagePack.exe) http://www.microsoft.com/downloads/details.aspx?FamilyId=36EE1BF0-652C-4E38-B247-F29B3EEFA048&displaylang=en (Use the change language drop down to choose different language’s language pack download)
WSS Language pack SP1 (SharePoint.exe) http://www.microsoft.com/downloads/details.aspx?familyid=EF93E453-75F1-45DF-8C6F-4565E8549C2A&displaylang=en (Use the change language drop down to choose different language’s language pack download)
MOSS Language pack ( extract *.IMG file) http://www.microsoft.com/downloads/details.aspx?FamilyId=2447426B-8689-4768-BFF0-CBB511599A45&displaylang=en (Use the change language drop down to choose different language’s language pack download)
MOSS Language pack SP1 (officelp2007sp1-kb936982-fullfile-it-it.exe) http://www.microsoft.com/downloads/details.aspx?familyid=1F5C7D10-B4F9-482D-B0E5-9547A7F508E5&displaylang=en (Use the change language drop down to choose different language’s language pack download)

3) Available languages

· Arabic العربية

· Bulgarian/български

· Catalan/Català

· Chinese (Taiwan)/中文 (繁體)

· Czech/èeština

· Danish/dansk

· German/Deutsch

· Greek/Ελληνικά

· English

· Finnish/suomi

· French/Français

· Hebrew עברית

· Hungarian/Magyar változat

· Italian/Italiano

· Japanese/日本語

· Korean/한국어

· Dutch/Nederlands

· Norwegian/norsk

· Polish/Polski

· Portuguese/Português (Brasil)

· Romanian/Română

· Russian/русский

· Croatian/Hrvatski

· Slovak/Slovenčina

· Swedish/svenska

· Thai/ไทย

· Turkish/Türkçe

· Ukrainian/Українська

· Slovenian/slovenščina

· Estonian/Eesti

· Latvian/latviski

· Lithuanian/Lietuvių k.

· Hindi/हिंदी

· Chinese (PRC)/中文(简体)

· Portuguese/Português

· Serbian/srpski

· Spanish/Español

· Kazakh/Қазақ үлгісі

4) Notes:

· Install all your language packs at the start, as once you create your site collections you cannot then add sub sites in languages you install later.

· The language packs are architecture specific so you’ll need either x64 or x86.

· The installers use the same ‘update’ architecture as SharePoint, therefore you can extract the Service Packs into the \Updates folder so you only install two and not four.

· Install the WSS and WSS (SP1) followed by MOSS and MOSS (SP1) packs.

· Ensure that the packs complete the configuration wizard. It may ask you restart your machine.

· Do the English (or your native language) first to learn the screens and prompts. You won’t understand what some of the prompts mean. Use http://babelfish.yahoo.com to translate them.

· The IMG file needs to be extracted. You can “mount” this image file using Daemon Tools utility (free and good) http://www.daemon-tools.cc/dtcc/download.php?mode=ViewCategory&catid=5

· For more information, have a look at the great guidance on TechNet - Deploy Language Packs : http://technet.microsoft.com/en-us/library/cc262108(TechNet.10).aspx

· Test any update in your test environment before updating any production system.

Understanding the Microsoft Office SharePoint Server 2007 containment hierarchy to design efficient information architectures

Brian Wilson — Sat, 23 Feb 2008 21:16:00 GMT

One of the SharePoint product manager’s (I think it was Joel Oleson) mentioned at a conference: “If you create a bad database design, don’t blame SQL Server when it performs poorly. The same applies to SharePoint.”

Coming from a developer background, the importance of getting of database design right was drilled into me, hence why this quote clicked straight away for me. SharePoint is no different; if you don’t understand the containment hierarchy of SharePoint your environment may not scale or perform as well as you expect it to.

Defining the information architecture for your SharePoint environment and ultimately for your business is a fine art. Some would say a black art! J It marries your business information schema, designed typically by your information architect or intranet portal specialist, to SharePoint’s containment hierarchy and the site structure that under pins your portal infrastructure.

The sections below provide you an overview of important containment elements that make up your information architecture in SharePoint.

SharePoint Containment Hierarchy
The containment hierarchy within SharePoint will govern how you store information, your portal’s performance, extensibility and the general management and control you have over the growth of the usage of the SharePoint infrastructure.

Farm
The farm is the collection of servers, services, databases, and other hardware infrastructure that make up the SharePoint implementation.

Servers
Servers of your farm provide the physical infrastructure for your SharePoint web applications. Various servers perform various roles within your environment such as:

Web Front End: These servers host traffic respond to request to pages from users of the portal. Typically 1 to 8 servers are used at this layer of the topology depending the load on the environment.
Application Servers: Index Server, Query Server, Excel Calculation Services, Forms Services add specific services to the SharePoint environment.
SQL Server: Typically SQL Server 2005 is used as the backend database for SharePoint. Almost everything in SharePoint is stored at the database level.

Application Pool
The next layer down is the Application Pool level. Application pools are hosted and managed by Internet Information Services on Windows Server.

IIS application pools are typically implemented to achieve process isolation between content. Application Pools provide a way for multiple sites to run on the same server computer but still have their own worker processes and identity. This mitigates an exploit on one site that provides an opportunity for an attacker to inject code onto the server to attack other sites.

Web Applications
A web application is an IIS Web site that is created and used by SharePoint Products and Technologies. Each Web application is represented by a different Web site in IIS. You assign each Web application a unique domain name, which helps to prevent cross site scripting attacks.

Recommendations:

· Use sparingly (few is better) as they consume a lot of memory.

· Required Web Applications:

o Central Admin Web Application (This one can be disabled when not in use.)

o SSP Admin Web Application

o 1-N Content Web Applications

· The most common reasons for using more web applications are :

o Namespace (assuming you are using isolated app pool)

§ E.g. Division of data into separate memory footprint for department that needs to be ultra secure.

o Customization levels (assuming you are using isolated app pool)

§ E.g. 2 SSPs are being used to isolate search content or BDC data.

o Separate anonymous content from authenticated content.

o Isolate users

o Enforce permissions: Enable you to use to policies for web applications feature.

o Optimize performance: Grouping applications that have similar data characteristics result in better performance.

o Optimize manageability: Manage different site limits, expiration and recycle bin at the web application level. You can negotiate different SLA for each Web Application. (E.g. My Sites = low priority versus Critical Content Web App.)

· By default every web application is installed on every Web Front End web server

· Web applications can share Application Pools

· Certain features, such as site self creation, and presence, can only be configured at the web application level

· Avoid more than 99 Web Applications per farm. This includes the number of Web applications on child farms consuming resources on this SSP.

Databases

Why have we included databases in your information architecture? The reason is that each Site Collections in SharePoint can only exist in one content database and cannot be split over multiple content databases. This has a direct impact on the performance of your information architecture as your portal grows in size and usage. If you place all sites in one site collection, or all site collections in one content database, your content database that hosts the site collections will take more and more strain as your portal environment grows over time.

The core databases of SharePoint are the following:

· Configuration database

· Administration database

· Shared Service Provider database(s)

· Search database(s)

· 1 – many content databases

Therefore the ability to load balance your site collections over multiple content databases, and if necessary, over multiple SQL instances, is especially useful in scenarios where you expect increased growth in the size of the total content stored and the number of users hitting your portal.

This doesn’t mean that every site should be a site collection, but rather that, for large solutions, you don’t store everything in one site collection.

Content Database Sizing

The numbers discussed in the points below are based on information from TechNet - Plan for Software boundaries -http://technet2.microsoft.com/Office/en-us/library/6a13cd9f-4b44-40d6-85aa-c70a8e5c34fe1033.mspx?mfr=true and previous experiences.

· Establish target sizes for content databases with appropriate size warning thresholds.

· Associate site collections to specific content databases. This approach enables you to place one or more site collections in a dedicated database that can be managed independently from the rest.

· Avoid more than 50 000 Site Collections per content database. (According to Technet article.) I would

· Maximum Content Databases per Web application: 100

· Number Site Collections per Content Database – Recommendation à 250 to Max (5000): Although the capacity guidelines document says 50 000, it is recommended to limit the number of sites in a database so that the content database doesn’t grow to an unmanageable size. OOB settings = 9000 site warning notification and 15000 site threshold. (don’t forget to update this setting).

· The size of the each Site Collection can be controlled via policy at the web application level

· To estimate how many site collections per content database, use the following formula:

· Estimated database size / avg. Site Collection Size = No of Site Collections. E.g.

1. Database size (50 GIG) / Avg. Site Collection Size (500mb) = 100 Site Collections

2. Database size (250 GIG) / Avg. Site Collection Size (500mb) = 500 Site Collections

· Content Database Size per Database Instance– Recommendation à 50-100 GIG: It’s all about your SLA. If something goes down, how long can you be offline for? Backup and Restore take time in two ways:

· Backup: The larger the database the longer the backup.

· Restore: The larger the database the longer the restore process.

· Databases per SQL Instance

· On 32 bit systems main bottlenecks are memory (failed uploads and ultimately failed page loads would occur if the available MTL space became lower than page size. Limit the number of content databases hosted on a SQL instance based on average and peak utilization of each database.

· On 64 bit systems no limitations due to increased amount of RAM and processor horsepower available.

· Total Databases per SQL instance : Main Considerations at the database layer are the following

· SQL Connections available (Memory)

· Network Bandwidth available

· Contentions with your backup solution

· Disk I/O depending on type of disk in use. E.g. larger disks or SATA disks could be problematic.

Site Collections

A site collection, which is hosted in a web application, is a set of Web sites that has the same owner and shares administration settings. Each site collection contains a top-level Web site and can contain one or more subsites. A site collection usually has a shared navigation structure.

Site collections bridge logical architecture and information architecture. The design goals for site collections in the model are to satisfy requirements for URL design and to create logical divisions of content.

Site collection sites provide features to manage itself and the subsites contained beneath it.

General Recommendations

• Content types do not span site collections

• Quota’s only apply at the site collection level

• Roll up ownership and quota’s to the site collection level

• While a site collection can support up to 250,000 subwebs (sites), it only support 2000 subwebs (sites) per tier (parent site). This is due to the fact that the interface for enumerating subsites of a given Web site does not perform well as the number of subsites surpasses 2,000.

• Best Bets are configured at the site collection level

• OOB Webparts typically rollup to the site collection level and do not span across site collections. E.g. Recent Documents Webpart.

• Master pages and site look and feel apply only within the site collection.

• Use Managed Paths to specify that only one or more than one site collection can exist for a specified path. (Managed Paths allow you to do perform two important tasks, namely, indicate which pieces of the URL namespace are controlled by Microsoft Windows SharePoint Services and specify paths to use for Self-Service Site Creation. e.g. /sites/)

• Avoid more than 50 000 Site Collections per Web Application.

• For more information on planning for software boundaries of SharePoint, see TechNet - Plan for Software boundaries- http://technet2.microsoft.com/Office/en-us/library/6a13cd9f-4b44-40d6-85aa-c70a8e5c34fe1033.mspx?mfr=true

Benefits of storing content in the same site collection

The sites in a site collection are usually interrelated by purpose. To maximize your solution's usability, store all related data and content within a single site collection. Benefits of doing this include:

Content types and columns managed in a site collection can be shared across all sites in the site collection. Conversely, there is no automatic mechanism for propagating content types and column definitions across multiple site collections.
Information management policies managed in the site collection can be made available to content in all sites in the site collection.
Office SharePoint Server 2007 automatically updates links to renamed or moved files within a site collection to reflect their new names or locations. Conversely, links to documents in other site collections are not updated.
If the site collection is on a server running Windows SharePoint Services 3.0, searching can only be done over the content in that site collection. If the site collection is on a server running Office SharePoint Server 2007, content can be searched across multiple site collections. As Reuters are planning on using Office SharePoint Server 2007, they will be able to use all of the search functionality SharePoint has to offer.
Some views in Office SharePoint Server 2007 list documents from multiple sites within a single site collection (for example, a view enumerating all tasks assigned to a user across a site collection). Also, developers can create cross-site database queries within a site collection, but cross-site queries are not supported across multiple site collections.
Content quotas and other quotas can only be managed at the site-collection level.

Limits on storing content in the same site collection

Keep the following limits in mind when planning how to allocate your content across one or more site collections:

Creating too many subsites of any site in a site collection might affect performance and usability. Limit the number of subsites of any site to 2,000 at most. See TechNet - Plan for Software Boundaries - http://technet2.microsoft.com/Office/en-us/library/6a13cd9f-4b44-40d6-85aa-c70a8e5c34fe1033.mspx?mfr=true
All sites in a site collection share the same back-end resources. In particular, all content in a site collection must be stored in the same content database. Because of this, the performance of database operations — such as backing up and restoring content — will depend on the amount of content across the entire site collection, the size of the database, the speed of the servers hosting the database, and other factors. Depending on the amount of content and the configuration of the database, you might need to segment a site collection into multiple site collections to meet service-level agreements for backing up and restoring, throughput, or other requirements. It is beyond the scope of this article to provide prescriptive guidance about managing the size and performance of databases. For more information about capacity planning, see “Plan for performance and capacity (Office SharePoint Server)” http://technet2.microsoft.com/Office/en-us/library/8dd52916-f77d-4444-b593-1f7d6f330e5f1033.mspx
Particularly, keep extremely active sites in separate site collections. For example, a knowledge base site on the Internet that allows anonymous browsing could generate a lot of database activity. If other sites use the same database, their performance could be impacted. By putting the knowledge base site in a separate site collection with its own database, you can free up resources for other sites that no longer have to compete with it for database resources.

Sites

Various types of sites can be provisioned in SharePoint. Sites span from the highly structured, planned top level site down to the unstructured ad hoc collaboration team sites. Sites can contain sites underneath them, for example an HR site could contain 3 team sites. Sub sites do not contain all the features a Site Collection site contains. It is largely focused on looking after itself.

Examples of common out of the box site templates are:

• Wikis Site

• Blogs Site

• Team Site

• Blank Site

Lists

What is a list in SharePoint? The simple answer is almost everything in Office SharePoint Server 2007 is stored in a list. A more detailed answer is that Office SharePoint Server 2007 is built on top of a core set of collaboration services called Windows SharePoint Services 3.0 (WSS 3.0).

WSS 3.0 lists provides a core set of functionality including content management (Create, Read, Update, Delete), check-in / checkout, versioning, security, workflow, storage management, presentation management, the ability to perform advanced list customization and column configuration, along with many other features such as RSS or Office Integration depending on the type of list. To use a developer metaphor, think of a list as base functionality that can be implemented as derived in many ways in SharePoint. The storage layer for all lists in WSS 3.0 is SQL Server.

To expand on the security aspect, WSS supplies a role-based security model that maps groups of users to preconfigured sets of permissions that specify and limit the actions users can take on sites and site content. WSS 3.0 administrators can apply security settings from the Site Level to the List level all the way to the item level (an individual document in a library, for instance).

• The common lists are Document Libraries, Pages, Events, Images, Discussions, Surveys, etc…

• Lists per site: 2000 per web site: Performance degradation occurs after that.

• Number of documents per document library: 5 million. This is only available if you nest the documents in folders (maximum of 2000 per folder before list performance degrades.

• Warning: Consider the impact on the size and performance of the site collection. Just because it says you can store 5 million documents doesn’t mean you should!

• Size Impact: Average size of each file multiplied by the number of files you will need to store in a SINGLE content database. (The document library is hosted by a single site collection which in turn is hosted by a single content database).

• Performance Impact: Consider the impact on caching and sql query plan for the rest of your sites in your site collection. Splitting out authoring environments from reader environments improves the performance of the underlying databases due to an improved SQL Query Plan.

• Document File Size: 50MB (2GB Maximum): However note that library and file save performance degrades as larger files are used.

• Fields per list: 256 per list: Performance degradation occurs the greater the number field types are used.

• Columns per List: 2000 per document library / 4096 per list: Performance degradation occurs the greater the number columns are used.

• More data has to be retrieved from database.

• More data has to be presented to user.

• Heavy use of granular item level security degrades performance: Consider that SharePoint needs to retrieve each item level permission for a list to calculate what can be rendered in your view of the list. Therefore highly customized item level permissions will degrade the rendering performance of a list view.

An interesting whitepaper called “Working with Large Lists in Office SharePoint Server 2007” is available at: http://go.microsoft.com/fwlink/?LinkId=95450&clcid=0x409 . It provides guidelines for designing “performant” libraries.

See “Microsoft TechNet - Plan enterprise content storage” which discusses performance considerations for sites and lists: http://technet2.microsoft.com/Office/en-us/library/9994b57f-fef8-44e7-9bf9-ca620ce207341033.mspx?mfr=true

Using indexed columns to improve view performance

The performance of views degrades if the number of items displayed exceeds 2,000 items. A useful technique for limiting the number of items to display in a view is to index a column used in the view, and then to filter the view based on that column so that 2,000 or fewer items are displayed. (An indexed column is one that Office SharePoint Server 2007 maintains a record of to make view-related queries more efficient.)

For example, if it is unlikely that more than 2,000 items in a library will be modified in any seven-day period, you could index the Modified column in a library and then filter a view so that only items changed in the last seven days are displayed. (To do this, specify that the Modified column is less than Today-7.) As another example, if it is likely that each author will create less than 2,000 items, you could index the Created By column and then filter a view so that authors only see the documents they created. (To do this, specify that the Created By column is equal to Me.)

The following types of column types can be indexed and used to filter views:

•	Single line of text
•	Multiple lines of text
•	Number
•	Currency
•	Choice
•	Date and Time
•	Lookup
•	Yes/No
•	Person or Group
•	Calculated

Here are other considerations in creating views filtered by indexed columns:

•	Only one indexed column can be used in a view.
•	Do not create filters using "Or" to provide multiple criteria when using an indexed column to filter a view.
•	Using the Item Limit feature to modify a view does not improve the view's performance.

Items

Items such as files, calendar items, contacts, customers, images and custom list items in SharePoint use lists as storage containers.

MOSS SDK

Brian Wilson — Thu, 23 Aug 2007 13:35:00 GMT

(Posted for your and my reference :)

The latest MOSS SDK is available for download! Download it here: SharePoint Server 2007 SDK

It includes:

Documentation enhancements

Installation Improvements: It now allows you to install to the specified location (as opposed to the last hard drive it finds on your computer :) )

Offline Experience Improvements

New tools

Business Data Catalog Samples and Utilities

o Microsoft Business Data Catalog Definition Editor

o Sample Pluggable SSO Provider

o WSHelloWorld Web Service

o WSOrders Web Service

o Excel Services User Defined Function Sample

o WSOrders Custom Proxy Sample

o Amazon Web Service Sample

o AdventureWorks Metadata Samples

o SAP Sample

· Document Management and Content Processing Samples

o Comment Scrub Document Converter

o Term Replacement Document Inspector

· Search Samples

o Sample Protocol Handler

o Custom Content Source

· Records Management and Policy Samples

o De-Duplication Router

o Document Integrity Verifier

o Records Center Web Service Console Application

o Search, Collect, and Hold Tool

o Sample Custom Barcode Generator

o IRM Document Protector

· Workflow Samples

o Custom Workflow Report Query Generator

o Custom Workflow Report XLSX Injector

o Visual Studio Workflow Templates

o Enterprise Content Management Workflow Activities

o List Item Activities

o Hello World Sequential Workflow

o State Based Approval Workflow

o Modification Workflow

o Replication and Contact Selector Workflow

o Intersystem Purchase Order

o Confidential Approval Workflow

o Group Approval Workflow

o Approval Workflow Sample

o Multi-Stage Workflow

o Server-side Collect Signatures Workflow

You can browse the SDK online through the following links:

· Office SharePoint Server 2007 SDK

· Windows SharePoint Services 3.0 SDK

Event Handlers - Part 3: Register Event Handlers plus free Site Settings – Manage Event Handlers Add-on solution

Brian Wilson — Sun, 18 Mar 2007 21:31:00 GMT

This post is the third post of a 3 post series.

Post 1: Everything you need to know about MOSS Event Handlers

Post 2: Developer Solution Starter Kit (Building and deploying event handlers to MOSS)

Post 3: Registering Event Handlers plus Site Settings - Manage Event Handlers

In the first post, I discussed the benefits of using Event Handlers in Microsoft Office SharePoint Portal Server 2007 (MOSS).

In the second post, I discussed how to develop and deploy Event Handler solutions for Microsoft Office SharePoint Portal Server 2007 (MOSS).

In this post I will discuss the various mechanisms to attach (register) your event handler assembly to a site, list, or content type. The "Site Settings – Manage Event Handlers Add-on" solution is hosted on CodePlex. Here is the link:

Codeplex Project : http://www.codeplex.com/SPSCustomAdmin/

(If any of you are interested in getting involved, I am interested in building more Site Settings addons. Please email me at brwil at microsoft dot com if you would like to get involved in expanding this framework. I will discuss the ideas i have in more detail in a future blog post.)

Overview

So you have deployed the assembly to the farm, now what? How do I register an event in your assembly for a Site, List, or Content Type?

I will describe three ways to deploy your assembly’s events.

1) Manage EventReceivers via Code

2) Deploy event handlers using the Feature framework of MOSS 2007

3) A cool custom Site Settings Application I built to manage (view, add, edit and delete) event handlers.

Managing EventReceivers via Code

The site (SPWeb) object, the list (SPList) object and the Content Type (SPContentType) object expose a collection called EventReceivers based on the SPEventReceiverDefinitionCollection class.

This collection maintains a set of SPEventReceiverDefinition objects (events) attached to a site, list or content type.

Adding Event Handlers (SPEventReceiverDefinition)

This class provides an “Add” method to attach a new SPEventReceiverDefinition (We created and deployed these to MOSS in Post 1 and 2.) The Add method asks for three bits of information:

· SPEventReceiverType: This tells SharePoint the type of event receiver we are adding to the EventReceiver collection.

· Assembly name: The name of the assembly. E.g. “Litwarehandlers, Version 1.0.0.0, Culture=neutral, PublicKeyToken=a6ab42c509981682”

· Class name: The name of the class. E.g. “Litwarehandlers.SiteHandlerClass”

(An easy way to get this information is to use our trusty old friend, Lutz Roeder’s Reflector application. Simply reflect the class and copy and paste the information you need.)

Once attached, the site, list or content type will now start picking up these events and executing your assemblies code.

Modifying Sequence Numbers

Another important property you may want to set for each event you attach is the Sequence Number. The sequence number determines the order your event assemblies’ fire. This is especially important when you have created multiple assemblies that are all attached to the same Site, List or Content Type event.

To modify the Sequence Number, you need to retrieve the SPEventReceiverDefinition object from the EventReceivers collection.

· Site: site.EventReceivers

· List: list.EventReceivers

· Content Type: site.ContentTypes[content type name].EventReceivers

A suggested best practice (and only my opinion), do not use sequence numbers below 10000 as SharePoint uses event handlers extensively to run SharePoint Workflows, etc. These event handlers use Sequence Numbers, starting at 1000.

Deleting Event Handlers (SPEventReceiverDefinitions)

When removing definitions, here is what you have to do:

Site:

· Attach to the site (SPWeb)

· Lookup the SPEventReceiverDefinition object in the site.EventReceivers collection.

· Use the delete method of the SPEventReceiverDefinition object to remove it from the collection.

· Call the site.Update() method.

List:

· Attach to the site (SPWeb)

· Retrieve the list : (site.Lists[GUID or listname])

· Lookup the SPEventReceiverDefinition object in the list.EventReceivers collection.

· Use the delete method of the SPEventReceiverDefinition object to remove it from the collection.

· Call the list.Update() method.

Content Types:

· Attach to the site (SPWeb)

· Retrieve the SPContentType (site.ContentTypes[SPContentTypeId])

· Retrieve the SPEventReceiverDefinition object : (SPContentType.EventReceivers[GUID])

· Use the delete method of the SPEventReceiverDefinition object to remove it from the collection.

· Call the SPContentType.Update() method.

Managing assemblies using Features

It is possible to create a feature that deploys your event handler to the assembly.

MSDN has an example on how to achieve this: http://msdn2.microsoft.com/en-us/library/ms453149.aspx

See screenshot of the xml you need to write to deploy an event via the features framework:

Limitations:

· It is difficult to see what event handlers are installed and the sequence they are firing for a site, list or content type. To modify, requires rebuilding the feature with the correct settings.

· Using a feature, “hardcodes” the event handler to an individual list or Content Type. Each time you want to use the SAME event handler, you are forced to write another feature to register it.

In my opinion, wrapping functionality as a feature is cool, but is overkill for registering event handlers. This is my reason for building a view, add, edit and remove application via Site Settings. See below! J

Managing EventReceivers using Site Settings application assemblies

Features

The Manage Event Handler site settings application provides you with the ability to view all events that have been associated to a site, any list of that site, and all Content Types for that site.

You can add event handlers, edit the sequence numbers and delete events registrations. Once the feature is activated, it is accessible from the Site Settings of any site

Feature – Event Handler Screenshot

Site Settings Event Handlers Screenshot

Manage Event Handlers" style="WIDTH: 916px; HEIGHT: 844px" height=844 alt="Site Settings > Manage Event Handlers" src="http://blogs.msdn.com/photos/brian_wilson/images/1909625/original.aspx" width=916 mce_src="http://blogs.msdn.com/photos/brian_wilson/images/1909625/original.aspx">

View Event Hhandlers Screenshot:

Add Event handlers Screenshot:

Edit Event handlers Screenshot:

Delete Event handlers Screenshot

Firstly, download the solution deployment code and wsp file from CodePlex here, and install in your SharePoint environment. (If you pick up any issues or have feature requests, please let me know so that I can add these to future releases.)

How to install

1. Follow the steps in my previous post in the "Deploying your assembly to staging and production" section. It provides step by step instructions on how to install a wsp file.

2. Navigate to any site and open Site Settings.

3. Open “Site Features” under the Site Administration column.

4. Activate the new feature called “Manage Event Handlers”. This enables event handler management application for this site.

5. Navigate back to Site Settings. A new option is now available under the “Site Administration column” called “Manage Event Handlers”. Select this option.

Notes

I have removed the ability to edit or delete native SharePoint generated event associations as this may affect the stability of SharePoint Out-Of-The-Box functionality. Only YOUR events can be managed.

Content Types (and their associated event handlers) can only be managed via the root site of the site collection.

In case you are wondering how to go about building your own site settings applications I have posted the code on CodePlex. I am planning on building an additional site settings administration application to manage and configure site properties.

Summary

If you have any questions, add a comment and time permitting, I will try to respond as soon as possible.