Microsoft Sharepoint: WSS Internals

Best Practice: Maintain common master page for each Webapp

2010-03-14T12:42:00.004-04:00

Using master page for defining the common look and feel, header, footer and basic structure of the page across the whole web application is a great concept from asp.net, also used in SharePoint.

We also have different types of sites in SharePoint, which need different look and feel and structure, basing on the type of site. So, SharePoint supports a way to upload a different master page for each site collection. But, it becomes tough for maintenance to maintain the common elements of the master page, if a different master page is uploaded for each site collection.

Hence, to get away from this disadvantage, there are two solution approaches.

1. Maintain a common master page for all the site collections in the webapp(with out uploading a specific master page for each site collection).

2. Take a note of common master pages maintained across site collections and push the master pages for maintenance changes, using custom/thirdparty tools from a central location.

I would suggest to prefer option 1. if possible. The advantage with this approach is, common master page for each webapp can be added into the 12 hive(features folder as custom feature) and all the site collections in that web app can use the specific master page in 12 hive. So, now, all the site collections in the whole farm are using the master pages in 12 hive and so for maintenance changes, all master pages exist in 12 hive and can be replaced with out needing to use custom/thirdpart tools and master page maintenance is more streamlined and easier.

Best Practice: Site configuration in Site Definitions

2010-03-08T20:54:00.007-05:00

Site configurations can be done through two approaches in a site definition.

1. Add the required site configurations in onet.xml.

2. Write the required site configurations in a DLL and include that dll in a feature and call the DLL to execute the code through feature stapling option.

Once the site definition is installed in PROD and site collections are created, onet.xml can not be modified, according to MS. Hence, if new versions of site definition is to be released, a new site definition has to be installed, if site configuraitons are done through onet.xml.

If the DLL approach is followed, a new/modified DLL can be installed for releasing a new version of Site definition. Hence this approach is more friendly for version maintenance.

Best Practice: Use solution files (*.wsp) for migrating code components to SP Farm Web Front Ends

2010-03-08T20:36:00.004-05:00

Using Solutions (*.wsp files) is the suggested best practice by Microsoft for installing SharePoint components (Site Definitions, Features, Resource Files etc) to the SharePoint Farm Web Front End Servers. The advantages in this approach are

1. All the required files for installion are combined to a single cab file with extension WSP.

2. Central Admin supports feature installation through the GUI. This will install all the required files to all the web front end servers of the farm. Hence, admins can manage the installation/un-installation of solutions using the GUI itself.

3. For scalability purpose, when a new WFE server is added to the Farm, SP Central Admin automatically takes care of adding the components to the new server if the components are installed through the solution files.

Site Definitions and Site Templates - More differences

2009-09-21T21:19:00.017-04:00

Both Site Templates and Site Definitions can be used to create new site collection(s)/site(s). They can be understood as

Site Definition: Site definition is stored on the SharePoint Web Front End Server’s file system in the 12 Hive folder. It consists of files like onet.xml, default.aspx, resources files etc.

Site Template: Site Templates are stored in the database (accessible as *.stp file from site templates gallery through front end) and are created by using an existing site, with or with out its specific content as a model.

The following are the differences between Site definitions and Site templates.

	Description	Site Template	Site Definition
1.	Storage	Database	12 Hive
2.	Easy to create	Yes	No
3.	Needs server access to install	No	Yes
4.	Available for publishing sites(when Office SharePoint Server Publishing Feature is activated)	No	Yes
5.	Provisioning Event Availble (to execute code)	No	Yes
6.	Can be changed after sites are created (Resource files can be changed)	Yes	No
7.	Create new content types (MS Best practice)	No	Yes
8.	Activate Feature during creation	No	Yes
9.	Performance	Low	High
10.	High level of customization (introducing new file types, view styles, Modifying edit menu etc)	No	Yes
11.	Sites/site collections refer to these files from the central location and hence when changed later at the central location will be reflected in all sites/site collections	None	Resource Files (Master pages, layout pages, css and javascript files)
12.	Can be restricted for availability to a specific web app	No	Yes

Important Topics in Learning Sharepoint

2008-02-21T21:13:00.002-05:00

01. Introducing MOSS Server
02. Structure and Hierarchy of Sites
03. Customizing sites: Look and Feel, Navigation etc
04. WSS V3 Object Model Fundamentals
05. Developing Features
06. Events
07. Developing custom webparts
08. Site definitions
09. Workflow
10. Authentication and Authorization

Explaining with real world scenarious, Labs and a project.

Feature: Adding custom navigation item to Site Actions menu

2007-08-15T17:40:00.000-04:00

The code/configuration of Features is present in the 12 Hive folder of the Web server that hosts sharepoint. To be precise, all the features are present in 12Hive\Template\Features folder of the web server.

The following are the major steps in creating a simple custom feature

1. Create a folder for the custom feature in 12Hive\Template\Features with the name of the feature
2. Create a feature.xml with the properties of feature like Id, Title, Description, Scope, Hidden and Location of ElementManifest defined in it.
3. Create a xml file that defines the ElementManifest (details like GroupID, Location, Action etc)
4. Register this feature in the Sharepoint database by using the STSADM command.

On following the above steps, a feature is successfully installed into Sharepoint and will be ready to use by the users.

Let's develop a simple feature with the steps below.

Feature purpose: To add a new menu item to the "Site Actions" drop down, that directly navigates to the "Manage Features" screen of the site.

Steps to create the Feature:

Step 1. Create a folder named "ManageFeaturesShortcut" in 12Hive\Template\Features folder of the web server.

Step 2. Create a file named "feature.xml" in the folder created in step 1., with the following contents:

Step 3. Create a file named "elements.xml" in the same folder as feature.xml, with the following contents:

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<CustomAction Id="SiteActionsToolbar"
GroupId="SiteActions"
Location="Microsoft.SharePoint.StandardMenu"
Sequence="100"
Title="Manage Features"
Description="Manage Features of this site">
<UrlAction Url="_layouts/ManageFeatures.aspx"/>
</CustomAction>
</Elements>

Step 4. Run the below STSADM command to install the feature and run IISRESET to start using the feature.

@SET STSADM="c:\program files\common files\microsoft shared\web server extensions\12\bin\stsadm.exe"

%STSADM% -o installfeature -filename ManageFeaturesShortcut\feature.xml -force

IISRESET

ECHO Finished

PAUSE

Sharepoint Development Environment

2007-08-10T18:50:00.000-04:00

As developers, we want the development environment to facilitate us to write code, compile and debug code and all these our local PC.

Development environment is relatively straight forward to setup for client-server (windows) apps. So, we got used to do all the above mentioned facilities in an easy fashion through the Visual Studio IDE.

Things started changing with the web applications (browser based). We know it is difficult to setup debugging for ASP/ASP.Net applications due to the complexity of having COM/.Net code running on the server and JS code running on the client.

Recall that when we are doing the Sharepoint development, we are not building an application (using a programming language), but are modifying/working with a Microsoft Product which can be WSS/MOSS. So, difficulty can be expected to write a code that sits somewhere in that product and work seamlessly with it.

So with Sharepoint, the picture changed much more. The developers are expected to sit on a Windows 2K3 Server OS with MOSS/WSS, Visual Studio and atleast a SQL server express edition installed all on the developers machine.

The reason being, when we are doing sharepoint development in the Visual studio, we need to add reference to the WSS object model which is in Microsoft.Sharepoint.dll. This dll comes only with WSS. So, WSS has to be there on the machine that has visual studio. WSS can only be installed on a server OS. So, all these requirements.

Since there are lot of softwares to be setup, development environment creation/maintenance can be simplified by using Virtual PC (Virtual PC contains the server OS, visual studio, WSS etc) while the developer desktop can be a normal OS desktop.

More info about development can also be had at

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

http://dotnetaddict.dotnetdevelopersjournal.com/sharepoint_dev_environment.htm

Adding Webparts to pages

2007-08-10T05:58:00.000-04:00

Adding/Customizing/removing webparts to sharepoint pages is one of the most attractive feature of sharepoint.

Webparts can be added to a sharepoint page by going to "Site Actions ==> Edit page ==> Add a Web part".

If you do not see the webpart in the above list try the following.

1. Go to the top level site of the site collection.
2. Go to "Site Actions ==> Site Settings ==> Modify all site settings ==> Galleries ==> Web parts".
3. In the web part gallery, click on the "New" option in the top left corner page menu and populate the gallery with the required web parts.

Be also aware of the version of your sharepoint (WSS or MOSS and their version number) installation and with which version does the webpart is installed through sharepoint.

Understanding Site Definition and a Site Template

2007-08-06T15:38:00.000-04:00

A Site Definition is a component in sharepoint, that is used to provision sites. This component defines what further components a site contains, when it is created out of this site definition. These further components can be pages, web parts in pages, document libraries etc.

The Site definition consists of atleast one file named ONET.xml and any further set of files, basing on requirement. These files are stored in 12 HIVE of the web server file system at "12-Hive\Template\SiteTemplates". When the user is trying to create a new site, all the existing and accessible site definitions are provided to him, from which he can choose a one of his choice.

Once a site has been created out of a Site Definition, there is a permanent reference to the site definition from the site and this can not be removed. So, as along as the site needs to be functional, the site definition needs to be present in the sharepoint.

For creating a custom site definition, involvement of a developer is required to create the files like ONET.xml and ship them to the web server. From the end user point of view, sharepoint gave those users a similar facility called Site Template. A Site Template can be created out of a sharepoint site and that Site Template can be used to create similar sites using that Site Template.

We have to take a note that Site Templates is only available for team sites in Sharepoint and a Site Template can be created for any team site in the following steps.

1. Browse to any team site for which you would like to create a Site Template of.
2. Go to "Site Actions ==> Site Settings ==> Modify All Site Settings ==> Save As Template".
3. This option would allow us to create a .STP file for this site. So, create a file named Temp.stp.
4. Now, when we try to create a new site, along with the list of other site templates, we also get the option to choose the newly created site template Temp.stp and so choosing this will create a site out of this Site Template. The .STP file is stored in the "Site Templates" gallery of the site collection and is available for creating sites in that site collection.

This explains the broad differences we have between a Site Definition and a Site Template.

Customizing Navigation: Moving Top Nav to the Quick Launch Area

2007-08-04T00:34:00.000-04:00

The Top Nav is defined in the master page. The top level design of master page has 4 HTML table rows. By default, Top Nav is present in the3rd row and Quick launch in the 4th.

Just cut the Top Nav control


=================================
<asp:contentplaceholder id="PlaceHolderHorizontalNav" runat="server">
-----------
</asp:contentplaceholder>
=================================

from the 3rd row and put it in the 4th row along with the quick launch which is


=================================
<asp:contentplaceholder id="PlaceHolderLeftNavBarDataSource" runat="server">
.......................
</asp:contentplaceholder>
=================================

You can either remove the quick launch control if you don't need or hideit (with HTML attributes).

Change the value of Orientation from Horizontal to Vertical for 'SharePoint:AspMenu
ID="TopNavigationMenu"'.

Customizing Navigation: Adding a Tree view to Left side navigation

2007-08-03T23:43:00.000-04:00

For any sharepoint site, Tree view can be used for the left navigation, by going to "Site Actions ==> Site Settings ==> Modify All Site Settings ==> Look and Feel ==> Tree view" and checking the "Enable Tree view".

The following Tree view properties can be changed by going into the master page.

1. ExpandImageURL
2. CollapseImageURL
3. NoExpandImageURL

The above properties are for setting the images for the tree view.

The following properties can be changed to SPHierarchyDataSourceControl, which is the source data source for tree view navigation.

1. IncludeDiscussionFolders
2. ShowDocLibChildren (whether to show document libraries or not in navigation)
3. ShowFolderChildren (whether to show folders or not in navigation)
4. ShowListChildren (whether to show lists in the navigation or not)
5. ShowWebChildren (whether to show sub sites in the navigation)

Customizing Navigation: Adding fly-outs to quick launch

2007-07-29T12:03:00.000-04:00

Quick launch is the navigation control that shows up in the left hand side of the sharepoint pages and is defined in the default.master page.

Some of it's customization can happen by going to "Site Actions ==> Site settings ==> Modify all site settings ==> Look and Feel ==> Navigation ==> Navigation Editing and Sorting ==> Current Navigation".

Few of it's properties can be changed by opening the control code in the master page. The properties of our interest are

1. StaticDisplayLevels
2. MaximumDynamicDisplayLevels

By default, StaticDisplayLevels is set to "2" and "MaximumDynamicDisplayLevels" is set to "0" for Quick Launch. That is the reason why, by default, we see only two levels in Quick Launch and no fly-outs.

To get fly-outs, set the MaximumDynamicDisplayLevels to a value greater than "0" and that will display fly-outs.

These properties also exist for the global navigation control and work the same way. By default, these values are set as StaticDisplayLevels to "2" and "MaximumDynamicDisplayLevels" to "1". So, this explains why we can see one level of fly-outs for the global navigation.

Re-branding Sharepoint Sites

2007-07-24T22:42:00.000-04:00

Re-branding of Sharepoint sites can be done by customizing
1. Master page
2. Navigation
3. CSS Style sheet changes

Master page

The Header, Footer and Navigation components, which are required for all pages, are commonly present in the master page. Default.master is the master page that comes with sharepoint and is used as the default master page for all the site pages in the team sites. The concepts of customizing master page can be understood by understanding the structure and changes that can be done to default.master. The same concepts can be applied to all the master pages.

The default.master page, on the top level, consists of HTML table element, which defines the structure of the page. The table element has 4 rows.

Row 1 = Global breadcrumb, Welcome ,....

Row 2 = Site Title, Search interface,....

Row 3 = Global Navigation, Site actions,....

Row 4 Col 1 = Quick Launch(left navigation component)

Row 4 Col 2 = Page Content

If we need a common footer, we can add a row below the 4th row to the above table, defining the footer and it's content.

We can move around the components like Global breadcrumb, Search interface etc to the custom look and feel that we need.

Navigation

Navigation is supported using the following components. They are

1. Global Navigation

2. Quick launch

3. Tree view

4. Global breadcrumb

5. Local breadcrumb

These navigation components have properties that can be changed through

1. Site administrative pages

(for example like showing/not showing the pages in the quick launch view)

2. Customizing Master page

(Flyouts can be enabled for quick launch by setting the property ShowDynamicLevels to more than 1)

CSS Files

The default styling of content is defined in css files at 12 Hive\TEMPLATE\LAYOUTS\1033\STYLES. These styles can be changed by overriding the styles through

1. Attaching cutsom styles for the master pages

2. Adding the custom styles directly in the master page by changing the master page

Pages in WSS

2007-07-21T14:40:00.000-04:00

Any website is a set of multiple pages. The same is the concept with sharepoint sites. So, let's understand more about sharepoint pages.

There are two types of pages in sharepoint. They are

1. Application pages

2. Content pages

"Site settings" page is an example of an application page. All administrative functions in sharepoint are implemented using pages of this type. These pages are stored in 12 Hive and are not customizable.

All the user facing pages are content pages and are customizable. Users can add their own webparts in webpart zones. Each content page is built from an existing page layout (web part zones are defined in these page layouts). Common look and feel for all pages is given by a common master page. The actual content of pages (like web parts added by a user and its properties) are present in the content database of the web application.

The following is the summary of understanding about pages.

Content page = Master page + Page layout + Content in content database

Application page = Master page + page in 12 Hive

Structure and Hierarchy of Sites

2007-07-14T13:17:00.000-04:00

Sharepoint's main purpose is to create sites and use them for multiple purposes.

So, what is a sharepoint site? A WSS Site is an entity that contains content in the form of pages, lists and document libraries and also administrative functions to manage the content.

The development, configuration and maintenance of sites can be made easy by grouping sites that are required for similar purpose. This grouping is attained in Sharepoint world in the form of Site collection. So, a Site collection is a container of WSS sites. It contains one top level site and that top level site can contain a hierarchy of sub-sites.

An IIS Web site that has been specially configured to run WSS sites is known as a Web application. A web application has to be created before creating a site collection. Later, more site collections can be added to that web application.

One single installation of WSS or MOSS is called a Farm. Basing on the infrastructure design, the whole Farm can be present on one server or can be distributed to multiple servers and it can contain one or more Web applications.

The entire Farms configuration information is stored in a separate sql datbase called Configuration database while the content of each web application is stored in it's own Content database. But, if a web application is quite large, it is possible to use multiple content databases for a single web application also. Each installation of WSS/MOSS also creates and configures a web application named WSS 3.0 Central Administration application which contains the administrative functionality like creating web applications, site collections, managing them and lots of other functions.

The above explanation describes the structure and hierarchy of sharepoint sites. Given below is a sample sharepoint Farm.

What is the purpose of Sharepoint Server?

2007-07-14T01:34:00.000-04:00

Now a days, website is required for anything/everything. A lot of people have their personal websites, a company has a web site, lot of movies have their own website, each product has a seperate website, city is having a website, restaurant is having a website and the list goes on and on....

In the IT world there are websites for projects, meetings, people, departments... the list is lengthy and difficult to complete.

OK. You have a website, now what? The company has news to share to it's employees, the project has a project plan, deadlines and party dates[ :-) hope these are not uncommon....], documentation, test plans, results, bugs list, tasks and their status ..... and now people want to discuss about these. Everyone knows having the requirements in a personal email is a big source of problem.

Microsoft sharepoint server comes into picture in helping us create sites and let people collaborate for all the above needs. This is the basic functionality of this server.

It also has options to host applications(custom)/part of applications(like showing the company headcount report to the VP of Global Resource Management department) and allow for personalization of the pages too by individuals.

So, Sharepoint has a long list of advantages. Also, WSS which stands for Windows Sharepoint Services comes free with Win2K3 server. Though, this has limited functionality compared to MOSS, you are getting a lot of stuff free of cost from Microsoft. So, it makes sense to host any of your web applications in WSS site as the basic infrastructre like authentication, Site structure, Site Navigation etc becomes very much available with out any development effort.

Does this mean that applications developed directly from ASP.NET technology will get reduced and more and more of the web applications will be now done through Sharepoint/WSS? I believe so.