WSS 2 Service Pack 3 filled with errors!

We are running Windows Sharepoint Services 2 in our intranet environment and have installed service pack 3 and have encountered irreversible errors. (The service pack can be downloaded at this link). Unfortunately Microsoft didn't release an uninstaller for the service pack - so desperate measures were taken in our organization. A significant error we experienced is the security for web parts for most of the websites does not allow anonymous access. Meaning most of our websites doesn't allow users to enter at all.

I have found another thread were users are experiencing the same issues + plus another handful: click here.

At the latest - Microsoft is aware of the issue and is scheduled to release a "hotfix" by January 08. Since we don't have the luxury of time - we would have to uninstall WSS entirely and reinstall with Service pack 2. Then just map to the existing databases since the databases are still intact and operational.

Good going Microsoft!

Error in WSS 2.0

I have come across a "RENDER FAILED" error in many of our lists in Sharepoint version 2.0. Although it is an inconsistent error (sometimes it happens - sometimes it doesn't) - a fix is found in another blog found here. I'll keep you posted if this works.

• The error shows up when accessing a list - looks like:

Set up a Web Farm in WSS 3.0

This post will show you how to set up a Web farm in WSS 3.0. I am assuming that you already have knowledge of WSS 3.0 such as web applications, site collections etc. I also assume that you already have a web application set up in your WSS 3.0 installation.

*Keep in mind that a web application requires a separate "Web Site" in IIS. With this said - you can set up several web applications in one web server - each application will have it's own respective port. The steps to do this is similar to setting up multiple databases within one site collection

1. Setup a content database -
   
   • From the Central Administration Website, go to the Application Management Tab
   • 
   • Click on "Add a content database"
   • 
   • Verify that you're in the right web application, enter the necessary information (database server, db name, authentication, search server etc. then click "OK"
   • 
   • After this process - double check your database server that the job was successful
     


2. Create a site collection-
   
• From the Central Administration Website - Go back to the Application Management Page, and select "Create Site Collection"
• 
• Verify that you're in the right web application, enter the necessary information
• 
3. View Site Collections within your application

• To see your web farm with their corresponding databases - go back to Application Management, Under Sharepoint Site Management > click "Site Collection List"
• 
• On the left hand side you will see you site collections, after clicking on each - notice the corresponding databases in the right hand side (Database Name)
• 
• And that's it. You have successfully set up a Web farm using the WSS 3.0 central administration web interface
  

WSS 3 administration

We all know WSS 3.0 has made significant changes from its predecessor. One in particular is the Central Administration area. In WSS 3.0, we now have the ability to create IIS websites from the web interface alone. I'm not referring to subsites or site collection - but actually creating a "website" inside IIS. In WSS 2.0 - you must manually create a website in IIS and then "extend" that website from the administration pages. In the new version, you can create: 1) web applications (which is a container of site collections - which requires a unique port, hence a "website" in IIS), 2) site collections within your web applications 3) content databases within the your web applications.

WSS 3.0 has made setting up a farm of websites and databases very easy and straightforward. A big leap from WSS 2.0

WSS 3 Database Names - Headache!

For anyone who has tried installing MOSS 2007 in a web farm - you'll come to notice how the databases the install will create for content is something like this: "SharePoint_AdminContent_fdbaaad6-ab7f-4bce-982c-3441d23fa8de"
(the GUID is appended to a default common name - Sharepoint_AdminContent & GUID)

During the installation you will get prompted on what to name your config db - which is good, but the content db has no prompt. I have tried renaming this by: stopping IIS, renaming the db, going into the "object" table and finding the entry *will not let you change due to the concatenation formula. And you will get the "unknown error" which is a big HEADACHE.

Luckily I found this post by Rickey Whitworth: http://www.whitworth.org/Blog/PermaLink,guid,fa4f11e2-221a-4321-a01e-cd466016d534.aspx

Wish MOSS had an easier fix though.

Upgrading to 3.0 Help

1) To speed up the upgrade, microsoft has provided some tools in order to upgrade your WSS 2.0 to version 3.0. Read the full article here.

2) Additionally:

"With the recent arrival of Windows SharePoint Services (WSS) 3.0, many administrators are faced with the task of upgrading their existing WSS 2.0 sites and data to their new WSS 3.0 environments. Though WSS 3.0 provides extensive tools that adequately migrate site data and upgrade site structure, additional work might be necessary to upgrade the structure of customized sites or site templates. However, additional work might be necessary to upgrade the structure of customized sites or site templates. Fortunately, the Microsoft® Solu­tion Accelerator team has released the Upgrade Toolkit for Win­dows® SharePoint® Services Sites and Templates, which provides guidance and tools around this practice (see the "WSS Resources" sidebar). This column focuses on some of the challenges and solutions associated with upgrading customized sites to WSS 3.0 environments"

Read more about this Utility Spotlight HERE.

3) Below is an image of the WSS site and site template upgrade workflow:

Document workspaces misconception

In WSS 2.0 there is a lot of automated features that can mislead users and even administrators. For example, each time a default web site is created a set of lists are already included. By this i mean the Announcements, contacts, events, links and tasks are already in your website by default (i.e. shown below)





The built in lists are part of a template for creating a website in sharepoint - even when creating a "blank" website. Document workspaces is a term that abstracts people from what it really is. A "Document Workspace" is simply a website.


with it's own set of lists and libraries included in it.

Recycle Bin in WSS 3.0 - Very Handy Indeed!

The Recycle Bin is a new feature in WSS 3. In version 2, once a document is deleted -it's gone! One would have to revert to an older version of the database in SqlServer to restore the document. Even for a accidental deletion of a document - just minutes ago!

WSS 3.0 offers the Recylce Bin!

A brilliant way of protecting your organization from the possibility of inadvertent or malicious deletion of important documents all from within the portal!

WSS is Microsoft's answer to DNN

Very interesting comparison between two platforms. DNN for certain has evolved from the IBS portal, which WSS also share a lot of similarities. This matrix of features show a great deal of information when deciding a CMS solution: Features Matrix Showdown

If you to read more about DNN and WSS head to head, the forum below is a good start:

Rebranding Sharepoint!

I found a very useful blog regarding rebranding Sharepoint. This should come very useful for designers who wish to customize their WSS site. There are many elements to remember - this blog covers each of them, in a laundry list fashion - on what to change when customizing your wss site. Here is the link: http://www.heathersolomon.com/blog/articles/SharepointDesignGotchas.aspx

How Sharepoint Lists work internally?

For anyone who has worked with lists in Sharepoint will come to wonder - How does this work? On occasion I did notice some weak spots: i.e no referential integrity between two lists - unlike two separate tables with unique keys and foreign keys. Although a Sharepoint list is pretty powerful especially when one has to create a spreadsheet with a form all from the browser. Now, I have some understanding on how lists work - but may be not totally.
I understand that by looking at the database, a list comprise of two tables (can be found in the content db of a sharepoint site):


1) the dbo.Lists table, and 2) the dbo.UserData table. Each time a list is created, an entry goes on the dbo.Lists table along with the necessary info (unique id, list title, created by, date and other metadata). Included in this entry is a "field" that defines the Columns inside that list - this is in the "tp_Fields" field. An screenshot of this is shown below:



From this single entry in the dbo.Lists table defines the makeup of a list.
Now the tricky part comes in the dbo.UserData table - where the user entries are entered. The table consists of over a hundred columns. A screenshot of the fields for this table is shown below:


Every time a user enters a data into a list, the stored procedure picks up: the list id, site id, user info, time stamp AND THEN plug in the rest of the data onto the proper column corresponding to the right datatype the list creator dictated from the initial creation of the list - columns whether it be nvarchar, float, datime etc.

Figuring out how this is done somewhere within the tp_fields column and the stored procedure is one ambitious task. Anyone have some explanation to this feel free to post. Thank you

Master Pages are not so "Global"

One thing I was wishing they would have changed in WSS 3 - Master pages to affect ALL pages within the site. I am talking about the "Create", "Edit", "View" pages. Why can't Master pages act more like a "skin" or a "theme" where - it is carried throughout the entire web site.
Am I alone on this?

Wikis in Sharepoint 3 - Amazing!

I have seen several wiki platforms but I must say - the layout, functionality, ease of navigation as well as the simplicity of the Wiki library is the best I've seen so far.