WSS as Platform for Internet Web

INTRODUCTION

The article intends to highlight some of the drawbacks of using WSS as a platform for internet/extranet based web. The intent of the is not to do a complete feature comparison (although it highlights some of the required ones) but to enumerate some of the challenges and considerations with WSS platform. This should help managers in taking an informed decision.

It looks into WSS as a platform for Internet enabled web sites. Earlier version of Sharepoint, i.e. Sharepoint Portal Services simply lacked this ability because it allowed only for Active directory based authentication making it viable only for intranet environment.

Current version of Sharepoint has 2 variants named Microsoft Office Sharepoint Server (MOSS), which involves licensing cost, and WSS 3.0 which is shipped free with Windows Server R2 or can be downloaded for free.

Please note that WSS itself provides very limited capabilities and is applicable with limited set of requirements.

WSS vs. MOSS - Features

WSS 3.0 and MOSS uses the same Object Model. Application pool can be Created/Extended and can contain number of Site Collections each of which itself can have any number of subsites. Feature based deployment model is extensively used and a feature can be created that address some custom code for different events and then it can be activated to Site collection/Site/Subsite. For Site Definition, by default WSS allows template for blank, blog, wiki sites (you are free to create your own site templates).

WSS 3.0 provides for feature based solution deployment (for webparts, custom actions etc), basic branding support with hooks for customization, document management, search, some set of OOB webparts (like content query webpart, Html editor webpart), ability to hook custom authentication and role providers, and most importantly internet deployment with network load balancing based on Zones and non active directory based authentication. In terms of deployment, it may not have complete set of farm capabilities but it does allow for providing multiple servers for different services like indexing, load balancing etc. You can use either of Enterprise or Express Edition of SQL Server.

 

MOSS provides for all WSS features plus advanced content management, Enterprise search, Publishing, Site Content and Navigation, Business Data Catalogue, Infopath form Services, Excel Services, advanced Site and Content Localization/Globalization using Concept of Site Variations, User profiles management, lot of out of the box webparts, Single Sign On and many other features.

 

Is WSS enough for my needs?

What WSS doesn’t provide is a fairly long list but if you want to save heavily on the licensing cost and your requirement are limited then WSS may suffice your needs.

To illustrate this, let us start off with identification by area and side by side check what is provided OOB (or is customizable) and what is not supported.

Site Structure

Based on your intended site structure, you create an application pool containing Site Collections each of which containing any number of subsites. This is same as MOSS; the only difference being additional site templates provided OOB by MOSS. WSS will provide for only few templates like Blank Site, Blog and wiki Sites. MOSS provides Publishing template which you may want to drill to help in making decision.

For site structure you may want to ponder over whether to keep your sites under same site collection or different site collection.

Site Navigation

Here we have two things. One is the navigation data source (Navigation Provider) and other is the Control which can display the Navigation Menu (Typically Top Bar Navigation, Side Bar Navigation and Breadcrumb Navigation).

Navigation provider will traverse through the site collection/sites and will create a tree structure for the sites/pages encountered. Each node of the tree contains link to the site/page. This works as an in input to Control which control the rendering of the control which can take care of the security trimming.

Navigation Provider

If you check out the WSS Central Administrator or any other Site’s web.config file, you will be following Navigation providers

SPNavigationProvider

SPSiteMapProvider

SPContentMapProvider

SPXmlContentMapProvider

SPXmlAdminContentMapProvider

 

There are a few instances of the portal site map provider that are defined in the MOSS web.config:

PortalSiteMapProvider.CombinedNavSiteMapProvider: attached to the global or top navigation menus

PortalSiteMapProvider.CurrentNavSiteMapProvider: attached to the current, or "Quick Launch" navigation menus

PortalSiteMapProvider.CurrentNavSiteMapProviderNoEncode: attached to the breadcrumb navigation

PortalSiteMapProvider.GlobalNavSiteMapProvider: Get the map for the global navigation

PortalSiteMapProvider.WebSiteMapProvider: enumerates Web sites (SPWebs) in the site collection

 

One point worth mentioning here is that in WSS, none of the provider provides for pages which you created in the sites. So if you want to show some link to site pages in any of the navigation, you may not be able to do so out of the box. To solve the problem, you can either write your custom navigation provider (if your scenario demands dynamic/frequent addition of Site Pages by the Content administrator and for each addition of page, the link for the page is required to be added to the Menu) or for Static Scenarios you can just manually the nodes in the Navigation tree using Sharepoint Designer. You can even think over creating a feature for extension of Site Navigation nodes.

Navigation Control

WSS provide for Quick Launch Webpart which can show Document Libraries, Sites etc but that is more suited for intranet Scenarios. For extranet/Internet scenarios you may want to either use ASP.NET Site Navigation Control or a Sharepoint enhancement to it.

MOSS provides far greater capabilities in terms of Navigation by using Site Navigation and Structure feature and few Navigation webparts. The feature allows complete control over what should be rendered and how it should be rendered. The changes can be published at will using the publishing feature available.

You will certainly miss the site navigation and publishing capabilities of MOSS.

Branding

Branding means application of Master page, control over site’s look and feel etc.

MOSS provides publishing feature so Master page in one Site Collection is visible to all sites under it so essentially there is one Master Page from which all sub mater pages can derive and this can be controlled at design time.

WSS does not provide for this because lacking publishing feature, each site has its own Master Page document library and you cannot share the master page across site collections/Sites, at least at design time.

The way to solve this problem is to deploy the master page as a Site Collection feature. The feature can be Activated/Deactivated to site collection/sub sites and it programmatically sets the site’s master page. You will still miss the option to select and preview the master page each time a new page is created.

Localization Needs

MOSS provides for feature called site variations which provide for great support for localization. Localization involves both Site Localization and Content Localization. WSS’s localization support is mainly resource files based.

Authentication, Authorization and User Profile Management

Both in WSS and MOSS you can have your custom role and authentication provider and register it with WSS/MOSS. MOSS by itself provides for User Profile store which you may want to harness. Please refer this excellent whitepaper for understanding User Profile and Management in Sharepoint. https://store.bamboosolutions.com/kb/article.aspx?id=10829

Webpart in WSS

Web parts are stored in Sharepoint Database and be activated/deactivated to a site collection/site as a feature. They are reusable components which can be added to any page.

Following are the options for Web parts:

1. Custom ASP.NET 2.0 Webpart

2. Sharepoint based web part

3. Custom ASCX Control within a web part

Design Considerations for Web part

- Caching

- Deployment in GAC/Bin folder

- Interconnection between web parts

- Easy Customizability of web part

- Customization of webpart Layout at runtime

- AJAX Type Controls in a webpart

 

And following is the comparison chart

Create a custom ASP.NET 2.0 Web Part	Create a SharePoint-based Web Part	Custom ASCX Control in a Web part
- For most business needs. - To distribute your Web Part to sites that run ASP.NET 2.0 or SharePoint sites. - When you want to reuse one or more Web Parts created for ASP.NET 2.0 sites on SharePoint sites. - To use data or functionality provided by Windows SharePoint Services 3.0. For example, you are creating a Web Part that works with site or list data.	- When you want to migrate a set of Web Parts using the SharePoint-based Web Part infrastructure to Windows SharePoint Services 3.0. - To create cross page connections. - To create connections between Web Parts that is outside of a Web Part zone. - To work with client-side connections (Web Part Page Services Component). - To use a data-caching infrastructure that allows caching to the content database.	Advantages - Familiarity - Reusability - Development speed - Full Programming support and customizable   Disadvantages - Slight Performance difference - Deployment (Multiple DLLs)

 

Web parts can be Created/Customized using Windows Sharepoint Designer and Visual Studio.

Product group recommendation is to use ASPX based webparts as far as possible.

Site Realization using WSS

Let us take a basic scenario where you have following goals and requirements:

1. You want custom look and feel, Style sheet and Navigation etc

2. Anonymous and as well as authenticated user access

3. Multiple document libraries (may some lists also)

 

Based on your required site structure, you can create a web application and a site collection under it. Then you can add any number of sub sites under to realize your actual site structure.

 

Once you have the structure in place, the resulting website will be Windows authentication based. We can extend this website to allow for Network load balancing and anonymous access. Extend the web application to Internet Zone and allow for anonymous access for this site. Both of these sites will point to only one copy of content.

 

Now we allow for custom authentication by changing the web.config file of the user created website to switch to custom membership provider. Then you can import all your users to the WSS profile database. To configure authorization, you can create specific roles with permissions suited to your needs and then add those profiles to the specific roles. Create various document libraries which you may be interested in.

 

Now we will address branding aspects, you can create a new master page and for deployment create a feature that deploys your master page. Activate this feature to site collection and all sites can refer to it. For navigation you can create your own webpart which accepts various properties and using Sharepoint object model creates the menu items for you. You may also consider using existing Sharepoint provided Navigation providers and controls.

 

You can easily add additional features like search etc. Configure search services for your site by defining the search and indexing server. Please note that the page that shows search results used application.master as the master page.

 

For the content part, now you can create multiple webparts which provides for your business functionality.

Site Realization using MOSS

Refer ECM team blog here https://blogs.msdn.com/ecm/archive/2006/10/30/building-tylerbutler-com-part-1-planning-and-basic-branding.aspx

Conclusion

While MOSS provides for lot of features and is an excellent platform for portal and Enterprise application integration but it involves huge licensing cost, for basic set of needs WSS platform may suffice.

Hope the information above will help you take an informed decision!!

Comments

• Anonymous
  July 01, 2008
  PingBack from http://wordnew.acne-reveiw.info/?p=4592

• Anonymous
  July 03, 2008
  I use WSS as an Internetsite on http://www.sharepointlive.tv

• Anonymous
  July 03, 2008
  SharePointCommunityCamp 15./16.9.2008 Mindjet Extends Power of Visual Collaboration Tipps Sharepoint

• Anonymous
  July 11, 2008
  Initially when I first created a webpart for Sharepoint/WSS, I was kind of confused with the number of

• Anonymous
  September 23, 2008
  Hello, I'v  read yr post and it easily bypass a problem with the menu. I want to implement a corporate internet Site with 9 categories (nine items on the main menu) where each category goes as deep as 4 levels! Implementing subsites and subweb doesn't look a promising (or feasible) idea, because : a) security is per per list and per page and NOT by a category ( I mean top menu items) b) I need to show views of lists in pages lying in different categories c) I want to use sharepoint designer and XSLT to show the data - CQWP is an option yet .... d) If I have 8 categories in the top menu and each of this can go 4 levels deep, i need a LARGE number of sub-sub-sub-subsites!! e) Changing categories and moving pages is a nightmare. What is the proposed solution to this problem?

• Anonymous
  September 24, 2008
  For Enterprise Scenarions(if you really want to use WSS) it makes sense to write Custom Navigation Provider. MOSS provides you this implementation OOB. It's wont be much different from writing a Site Navigation Provider for any .NET 2.0 ASPX Webs, but differences will come in for Security Trimming etc where you may have to use Sharepoint Object Model.

• Anonymous
  October 01, 2008
  One of the most important things when using WSS as a platform for an Internet Web site is performance.  Unlike MOSS, WSS doesn't have the OOTB ability to turn on output caching on the web part pages.  I wrote a post on my blog to help people who want their WSS Internet Web Site to run very fast and have the pages come out of the cache while still accounting for the different types of design modes and unpublished pages.  You can see this here: http://www.imason.com/blogs/noorez_khamis/archive/2008/09/30/how-to-use-output-cache-to-cache-wss-site-web-part-pages.aspx

• Anonymous
  November 20, 2008
  Nitish- I am using WSS 3.0 for an intranet set of site collections. In this we are using a central site for our data collections - ex. a central forms document library. When using web part pages on the parent site, WSS provides web parts for constructs already created like the document library. Here is where I am stuck... In other sites throughout the collection I am searching for a way to place those same web parts upon web part pages. For example. //intranet/site1/forms/ = all forms document library //intranet/site1/webpages/page1.aspx = uses a the wss-created web part to view the forms library located in its own site. //intranet/site2/webpages/page2.aspx = i need to place a web part on this page that views the Forms document library from Site1. How is this possible? I am sure a custom web part could be written somehow. Or perhaps manual entries in the content database to instantiate a web part for Page2.aspx and then point it to the Site1 Forms library? Thanks, -Trey twhite @ fire . ca . gov

• Anonymous
  November 20, 2008
  Wont Site pages suffice your needs here... Site pages are the one available to all Sites within a site collection. Once you got to the site collection, you can access information within any subweb provided you have access. You got full control using OM.. Look at some of the samples on Ted pattison's blog(blog.tedpattison.net).. Look into downloads section, you may even get some samples for reference...

• Anonymous
  November 21, 2008
  Nitish- Thank you for the swift response. I checked out Ted Pattison's blog, and it was very helpful, but mainly for other issues. Also, his example downloads of site and application pages are down. Bummer. Perhaps if I explain my need a little better... When a user creates a list or library construct on a WSS site, WSS provisions a WebPart for that construct so that it may be plopped on Web Part Pages. When a user edits the page, and adds a web part to a given zone, the provisioned web part for the list or library is found there. The functionality I am trying to accomplish is to be able to add a web part to Page1.aspx of NewSite, that is providing a view into MyList of OldSite. Does that make sense? I can think of 2-3 ways this might be possible, but I am nervous to go tweak stuff I don't understand well enough yet.

1. Is there a way to instantiate a copy of the MyList web part on OldSite within Page1.aspx on NewSite?
2. Is there a way to instantiate any library web part on NewSite and then somehow change a db entry for the part to force it to pull data from MyList on OldSite instead of its original view target?
3. Is there a way to write a web part that allows me to designate a target list/library from another site in the site collection? The site collection in question has no restricted permissions so authentication or pulling from areas a user shouldn't have access to is not a worry for now. What are your thoughts Nitish? Thank you up front for your help and advice. -Trey

• Anonymous
  November 23, 2008
  Is there a relation between Site1 and Site2 you mentioned above, I assume they belong to same Parent. Ideally you use sub sites either when the content is logically different  and you need separation of permissions/roles OR you need better load balancing. Now think again why do you need sub sites in that case? Coming back to your question of enabling a Common Webpart with Content from sibling site. You can use a Common Webpart and enable that Webpart as a feature provisioned to Site Collection. This way the webpart can be enabled to any site/subsite you want and can be versioned and controller. In this webpart, you can expose a property to accept the Site whose Library you want to access. Next, to get the content for this webpart, you can use Object Model to get the site context for the Specified Site/Subsite and then you can access the Document Library/Lists (provided user has access). Once you have the content, you can control the rendering as well. Object model will take care of automatic Security Trimming as well. I would strongly oppose hacking into Database because Database may change with Service Packs and may even get corrupt if you seriously play with them. Remember, it’s not just one database but a farm and actual content may be ghosted deep into remote database server to which you may not have permissions.

• Anonymous
  November 24, 2008
  Nitish- Once again, thanks for the response. In response to your topography planning advice, here's what we are doing and why we are doing it. Our web app, http://intranet/, contains a site collection of the same name. For now, let's say only two child sites exist: Data Center, and Orgnization. Each organizational unit in the department has their own site (child sites to Organization) with which to display information about themselves as well as provide relevant content. Data Center is a repository for all the documents, files, images, etc that this department wants on its Intranet (not the stuff used to actually build the website, just material for consumption). For example, we have a large set of electronic forms in this department: pdf files, word docs, images, and more, which all serve different purposes and have different owners. This central repository is used to ease navigation (so no user needs to remember what unit provides the form), and avoid redundancy (common forms might otherwise be uploaded in multiple site libraries and causes issues with content management and consistency). Our solution was to create a "Forms" library within the Data Center site, using meta data columns like Category, Purpose, etc. to sort and filter where needed. The issue from there becomes... each organizational unit needs to display the content relative to their business function. We could do this by using the content editor web part or a links list and its web part, and create links to their forms in the Data Center, but this is tedious, and compromises lots of functionality that the document library web parts provide (sorting, grouping, filtering, etc.). So we are looking for a way to plop a web part on a unit's page that functions exactly like a document library's web part, only allowing the unit to point it to the Data Center's Forms library and modify its view to return on the content they wish to provide on their page. Whether Human Resources, Fire Protection, IT, etc. they all use this web part, and modify view, filtering by Category, Purpose, etc. Now when a new document is uploaded to the Intranet, it goes in the data center and every unit's site is immediately displaying the new content... no new links to be created, no html to modify, no worries about URLs changing when a filname is changed between versions, etc. Make sense? As for a solution... If I understand you right, this web part does not exist. I would have to create a web part mimicking the functionality of a document library viewer, but allowing in its properties the ability to set a target site and library? If this is the case, can you provide any guidance on creating this web part in Visual Studio? Or know the name of the template the library web parts already use so I could use that as a starting point? Thanks for the awesome advice. -T

• Anonymous
  November 25, 2008
  Your problem is interesting. MOSS typically provides Publishing Infrastructure specifically targeted for this kind of scenario. For you, either you can write your custom webpart (write to me in case you plan to do so, I can give you some pointers), or you can try using Content Query Webpart with Datasource and filter set to your sibling site and document library respectively. The you can use XSLT to customize the view. You may want to look at http://blogs.msdn.com/markarend/archive/2006/07/16/667500.aspx?harrison Any styling need, Heather Solomon is the guy!! http://www.heathersolomon.com/blog/articles/CustomItemStyle.aspx

• Anonymous
  September 16, 2009
  We've developped a module for WSS to support multiple localization see it at the following url:  http://bit.ly/Jbbsh Regards Edagrd