Stone Coast Web Design Blog

Unlike Sharepoint 2007 which required that it be installed on a Windows Server product (2003 or 2008), Sharepoint 2010 can be installed on Windows Vista or Windows 7 as long as they are x64 versions.  This is great for developers and for those who just want to learn more about the product.

It takes a few steps but I got it working on Windows 7 using these instructions:

http://msdn.microsoft.com/library/ee554869(office.14).aspx

Here is a huge list of free Sharepoint Web parts

http://www.amrein.com/apps/page.asp?Q=5794

I recently backed up our WSS 3.0 site using the STSADM command line tool and after it was finished every WSS site collection was marked read-only and none of our users could edit the sites.  I knew the backup using the stsadm tool put the site in read-only mode during backups but was mystified why it kept it that way when the backup was completed. It seems the force and nositelock parameters were first introduced in Windows SharePoint Services 3.0 with Service Pack 2 (SP2).

If changes are made to the site collection during the backup process, the backup can become corrupted. Backing up large site collections can take a long time. To reduce the chance that user activity will interfere with a site collection backup, or that the time that is required to back up large site collections will exceed the available maintenance window, follow these recommendations:

■ Do not use the Stsadm backup operation for site collections larger than 15 gigabytes (GB). For larger site collections, see the recommendations in Back up and restore site collections by using built-in tools (Windows SharePoint Services 3.0).

■ For the duration of the backup, set the site collection URL to read-only by using the Setsitelock: Stsadm operation (Windows SharePoint Services). This lets users view content on the site, but prevents activities such as adding or changing content that interfere with the backup process. When the backup is complete, return the access setting of the site collection URL to its default state.
In Service Pack 2 for SharePoint Products and Technologies, site collections are automatically locked as read-only before a backup process occurs. Therefore, there is no need to use the Setsitelock: Stsadm operation (Windows SharePoint Services) operation. If you do not want site collections to be locked as read-only, you must specify the nositelock parameter that is available in Windows SharePoint Services 3.0 with Service Pack 2 (SP2).

Setsitelock: Stsadm operation (Windows SharePoint Services)

To determine the lock status of the site, you can use the following getsitelock syntax
C:\>stsadm -o getsitelock -url http://tclconnect

Once the lock status of the site collection is determined, you can use the noaccess parameter of the setsitelock operation to lock out all users to the site:

stsadm -o setsitelock -url http://server_name -lock noaccess

You can use the Backup operation to create a backup of the site collection:

stsadm -o backup -url http://server_name -filename "filename.bak" -overwrite

After the site has been backed up, you can use the none parameter of the setsitelock operation to remove all locks to the site:

stsadm -o setsitelock -url http://server_name -lock none

Here’s a copy of the bat file that gets run to back up our WSS site using Windows Scheduler

@echo off
echo ====================================================
echo Backup Script For Office SharePoint Server 2007
echo ====================================================
cd c:\program files\common files\microsoft shared\web server extensions\12\bin
@echo off
stsadm -o Backup -nositelock -url http://tclconnect -filename d:\sharepointbackups\backup.bak -backupmethod full -overwrite

If you administer WSS or MOSS, you have used STSADM.exe found in C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\bin. To make it easier to access, there is a system variable named PATH. When you enter a program name in a command window, Windows looks for that file in all file paths defined in this variable.  This explains how to add the path to STSADM to this system variable.

1. Right-click My Computer and select Properties

2. Switch to the Advanced tab, and click its Environment Variables button

3. In the lower pane named System Variables, locate PATH and click Edit

4. Go to the end of the current list under Variable value and type in a semicolon as a separator and paste in C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\bin

5. Click Ok 3x

Now you can type STSADM from anywhere in a command window.

If you administer WSS or MOSS, you have used STSADM.exe found in C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\bin. I read about a GUI tool that sits on top of STSADM which makes it much easier to use. The name of the tool is Stsadmwin.exe and you can download it for free here.

Here is a screenshot of the product

Sometimes when adding custom Web parts to a Sharepoint site, a script or code error will cause the whole page to become disabled and you cannot edit or remove the offending Web part. Fortunately, there is a little trick you can use to get around this.  The trick is to add Contents=1 to the URL string which will bring up the Web Parts Page Maintenance page.  For example, typing in http://myserver/default.aspx?Contents=1 will display

From this page you can then choose the bad Web part and delete it.

I've been learning how to develop parts for WSS 3.0 and have found that debugging them is a real pain.  I picked up this tip from SharePoint Development and Programming FAQ which has proven helpful.

Problem

You receive “The "yourWebPartName" Web Part appears to be causing a problem” or a generic error message when developing a web part.

Cause

Exceptions are caught by SharePoint and a friendly error message is displayed instead of a stack trace.

Resolution

To configure SharePoint to display the full exception needed for debugging make the following changes to your SharePoint site’s web.config file (typically located in \Inetpub\wwwroot\wss\VirtualDirectories\yoursite).

· Find: <SafeMode CallStack="false" />

· Replace with: <SafeMode CallStack="true" />

· Find: <customErrors mode="On" />

· Replace with: <customErrors mode="Off" />

· Find: <compilation debug="false" />

· Replace with: <compilation debug="true" />

I frequently create User Controls in our WSS 3.0 environment use SmartPart to deploy them. 

Below is an example of a user control not using code-behind.

LastBAUserLogin.ascx

<%@ Control Language="VB" ClassName="LastBAUserLogin" %>
<%@ Import Namespace="System.Data" %>
<%@ Import Namespace="System.Data.SqlClient" %>
<%@ Import Namespace="System.Web.Configuration" %>
<%@ Import Namespace="System.Web.UI.UserControl" %>

<script runat="server">
</script>

<asp:UpdatePanel ID="MyUpdatePanel" runat="server">
       <ContentTemplate>
       </ContentTemplate>
 </asp:UpdatePanel>

This is an example utilizing code-behind

staff.directory.ascx

<%@ Control Language="VB" AutoEventWireup="false" codeFile="staff.directory.ascx.vb" Inherits="StaffDirectory" %>

<asp:UpdatePanel ID="MyUpdatePanel" runat="server">
      <ContentTemplate>
      </ContentTemplate>
</asp:UpdatePanel>

staff.directory.ascx.vb

Partial Class StaffDirectory
Inherits System.Web.UI.UserControl

End Class

You may see this error - more than once - when working with your Microsoft Office SharePoint Server (MOSS) 2007 or WSS 3.0 deployment. This often happens after you have applied an upgrade to an existing deployment. You may begin to see a lot of these errors pop up in the SYSTEM event log a:

Event Type:    Error
Event Source:    DCOM
Event Category:    None
Event ID:    10016
Date:        7/1/2008
Time:        9:49:50 AM
User:        NT AUTHORITY\NETWORK SERVICE
Computer:    TCLPRODAPP1
Description:
The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID
{61738644-F196-11D0-9953-00C04FD919C1}
to the user NT AUTHORITY\NETWORK SERVICE SID (S-1-5-20).  This security permission can be modified using the Component Services administrative tool

The error CLSID is followed by a class ID for the DCOM+ application that the service account trying to activate that application does not have permission to activate it.

This is the fix that worked for us.

Copy the GUID following the CLSID above, and Start-->Run-->regedit

Edit-->Find and paste in the GUID. It'll stop at the application entry - and you will want to note the application name on the right side pane. In this example, it was the IIS WAMREG admin service that popped up.

Now, open Component Services (typically, from the server - Start-->Administrative Tools-->Component Services), expand Component Services, Computers, My Computer, DCOM Config. Scroll down and find the application (IIS WAMREG in this case). Right-Click-->Properties and select the Security tab. You'll have some options here - the first block Launch and Activation Permissions - ensure that the Customize radio button is selected, and click Edit. Now, add your service account - giving it launch and activate - and in some requirements - remote launch / activate permission.

Restart IIS.

I've been having trouble getting WSS to index certain documents and working correctly and this article was helpful.

http://www.wrox.com/WileyCDA/Section/id-305250.html

How do I move WSS 3.0 for "Windows Internal Database" (the embedded version of SQL Server 2005 Express) to the full SQL Server 2005?

Description:

This text was written by Jim Sykora in a public newsgroup and he has very kindly allowed me to re-produce it here.
Many thanks, Jim.
-------
This scenario involves moving your WSS 3.0 sites from Windows Internal Database to Microsoft SQL 2005 (doesn't really matter whether it's local or remote to the main WSS server instance).

1. First Fully backup your current WSS Content databases. I've found no way to move config databases, and from my testing there seems to be little reason to do so.
a. Utilize stsadm.exe from a cmd prompt to back up your entire Sharepoint farm:
stsadm.exe -o backup -url http:// -filename C:\SPBackups\FullFarmBackup.dat
(you may want to change the path the backup file is stored depending on your situation)

b. Verify the backup is complete and browse to the location the backup file is stored to verify it exists and is of a reasonable size.

2. Uninstall WSS 3.0 from Add/Remote Programs Control Panel

3. *IMPORTANT* Remove Windows Internal Database -
http://support.microsoft.com/kb/920277
If you were utilizing a single-server, basic WSS 3.0 installation and uninstall it, it will leave behind the Windows Internal Database, which will cause any new installations of WSS 3.0 to have issues.

4. Reboot the server to finish up any uninstall scripts.

5. Make sure your SQL 2005 database is prepped per the instructions for installing a WSS 3.0 Server Farm and then install using the steps for a server farm (even if you'll only be installing on a single server).
a.
http://technet2.microsoft.com/WindowsServer/WSS/en/library/89e4c579-5720-45e
0-917e-abeb95266c3e1033.mspx

b.
http://technet2.microsoft.com/windowsserver/WSS/en/library/1f505e96-60e2-41a
c-bf5d-9739105f047c1033.mspx?mfr=true

6. Once everything is installed and you're using the SharePoint Products and Technologies Configuration Wizard to configure sharepoint make sure to point it to your existing SQL server as you go through the steps.

7. Upon completion of the wizard use WSS 3.0 Central Administration page to configure your basic settings such as Incoming and outgoing email settings, logging, search server, etc.

8. In Central Administration->Application Management choose "Create or Extend Web Application" to create your IIS instance. Follow the standard steps here.

9. In Central Administration->Content Databases choose "Add a content database" and use your SQL server. Don't forget to select your search server that you set up earlier. This will create an empty content
database which we will restore our site from step 1 to.

10. Open a command prompt again. Use stsadm.exe to restore your site farm:
ststadm.exe -o restore -url http:// -filename C:\SPBackups\FullFarmBackup.dat
This step will take a little bit, but should say Operation Completed Successfully at the end. You should now be able to access your sharepoint site again using the new SQL server database location.

This should also work as a disaster recovery process starting at step 2 being that you should have daily or weekly scheduled sharepoint backups using stsadm (and at least monthly SQL database backups to help with SQL performance and log management).

Later: Boris Gomiunik has a blog item on the way he did this here -

http://webborg.blogspot.com/2007/06/reinstalling-sharepoint-wss3-to-run.html

Here some links I've come across that I've found helpful

Building a Hello World Web Part for Windows SharePoint Services 3.0
http://aspalliance.com/1480_Building_a_Hello_World_Web_Part_for_Windows_SharePoint_Services_30.all
Based on this Ted Pattison video: http://go.microsoft.com/?linkid=6471616

Creating and Using Event Handlers in Windows SharePoint Services 3.0
Video: Ted Pattison
http://go.microsoft.com/?linkid=6471621

Creating and Testing Features with Windows SharePoint Services 3.0
Video: Ted Pattison
http://go.microsoft.com/?linkid=6471617

Creating a Custom Page Layout with SharePoint Server 2007
Video: Ted Pattison
http://go.microsoft.com/?linkid=6471618

Creating and Using Site Columns in Windows SharePoint Services 3.0
Video: Ted Pattison
http://go.microsoft.com/?linkid=6471619

Creating and Using Content Types in Windows SharePoint Services 3.0
Video: Ted Pattison
http://go.microsoft.com/?linkid=6471620

Creating and Using Event Handlers in Windows SharePoint Services 3.0
Video: Ted Pattison
http://go.microsoft.com/?linkid=6471621

MSDN Webcast: Developing SharePoint Workflows Using Visual Studio 2005 (Level 200)
http://go.microsoft.com/?linkid=6471622

SharePoint Server 2007 SDK: Software Development Kit
http://www.microsoft.com/downloads/details.aspx?FamilyId=6D94E307-67D9-41AC-B2D6-0074D6286FA9&displaylang=en

Windows SharePoint Services 3.0 Tools: Visual Studio 2005 Extensions
http://www.microsoft.com/downloads/details.aspx?familyid=19F21E5E-B715-4F0C-B959-8C6DCBDC1057&displaylang=e

I know this issue is going to come up soon for me so I've been researching possible solutions and came across this one.

http://wss.asaris.de/sites/walsh/Lists/WSSv3%20FAQ/DispForm.aspx?ID=1034

How do you move a WSS 3.0 database to a different SQL Server?

You cannot move the configuration database. 

1.  Detached the content database using SQL Manager

2.  Copied the database and log files to the new server

3.  Attached the content database to the new server

4.  Run the SharePoint Products and Technologies Configuration Wizard to remove it from the farm

5.  Run SharePoint Products and Technologies Configuration Wizard to recreate the farm and add the new database server. This will also create a
new configuration database.

6.  Once that is done, go to SharePoint Central Administration website and click on Application Management

7.  Select Create or extend web application to setup your new web application

8.  Select Content Database and add the new content database

9.  Restart IIS

I was experimenting with the AJAX Tab control extender which is part of ASP.NET AJAX Control Toolkit in Sharepoint.  The bottom part of the tabs was being cut off for no apparent reason.  When I would run the page locally, it would render fine but within Sharepoint, the text on the tabs was being cut off on the bottom. After several frustrating hours, I found out how to fix the CSS that was causing the problem.

After looking at the Tabs.css file, it appears that the right hand graphic on the tab control is set to a height of 21px. The tab itself with the text has a height of 13px. This can be remedied by modifying the xp theme to look like this:

.ajax__tab_xp .ajax__tab_tab {height:21px;padding:4px;margin:0;background:url(<%=WebResource("AjaxControlToolkit.Tabs.tab.gif")%>) repeat-x;}

The Tabs.css file can be found in the AJAX Control Toolkit (with source code).  I changed the CSS used by my particular theme which in my case was /_themes/Wheat/Whea101165001.css

Also, by default, the CssClass used by the Tabcontrol is .ajax__tabs_xp.  I changed mine to use .ajax__tabs so it would use the changed Css /_themes/Wheat/Whea101165001.css rather than the CSS used by the Tabcontrol.

Other resources that helped with this issue:

• http://www.codeplex.com/AtlasControlToolkit/WorkItem/View.aspx?WorkItemId=8580
• http://forums.asp.net/p/1148992/1868850.aspx#1868850

I recently tried adding a page to WSS 3.0 which utilized one of the ASP.NET AJAX components and received the error "Error - this control is not registered as a safe control." After some digging, I found out that you have take a few steps to get these AJAX control extenders to work in Sharepoint.

• AjaxControlToolkit.dll - Put this in your /Bin directory
• Add an assembly reference in the web.config (note: for the future versions of the Control Tookit, the version number can change.  Right-click on the dll and go to properties to find the dll verison):

   <assemblies>
   ...
   <add assembly="AjaxControlToolkit, Version=1.0.10920.32880, Culture=neutral, PublicKeyToken=28f01b0e84b6d53e"/>
   ....
   </assemblies>

• Add the tagprefix for the Control Toolkit in the web.config:

  <controls>
  ...
  <add namespace="AjaxControlToolkit" assembly="AjaxControlToolkit" tagPrefix="ajaxToolkit"/>
  ....
  </controls>

• Register the assembly as a safe control:  

I've found it surprising how tricky it is to run ordinary .aspx pages and applications in Sharepoint.  Chris Johnson from Microsoft offers some interesting alternatives on how to do this:

http://blogs.msdn.com/cjohnson/archive/2006/09/05/740498.aspx

One of the cooler tools I've come across for this is SmartPart which is a generic Web part allows you to host any ASP.NET user control within your SharePoint sites. It allows for a designer-driven approach to developing Web parts instead of very code-intensive approach that is available out-of-the box with SharePoint.  You can download SmartPart here. Jans offers a video and a user's guide to get you started.

I've started using Sharepoint at work and although I've been coding in ASP.NET a couple of years, I'm finding the learning curve a little steep. 

If you use the Microsoft Office SharePoint Designer to add a new page to your site, you will see that it looks just like any other ASP.NET page.  However, if you try an add an inline code block using the standard

<script></script>

tags, you'll receive an error similar to this one:  "An error occurred during the processing of /Pages/test.aspx. Code blocks are not allowed in this file."

Hmm… yeah, code blocks are allowed in ASP.NET pages. SharePoint disables the ability to create server-side script by default, you have to turn it on. You do that in the web.config file, in the configuration/SharePoint/PageParserPaths configuration section:

<PageParserPaths>

  <PageParserPath VirtualPath="/pages/test.aspx" CompilationMode="Always" AllowServerSideScript="true" />

</PageParserPaths>

By the way, there are multiple web.config files and the one you should edit is C:\Inetpub\wwwroot\wss\VirtualDirectories\80\web.config