Security requirement for SharePoint backup shared folder

STSADM command is the only tool available when scheduling a SharePoint catastrophic backup. And this command requires a shared folder to store backup files. It's essential to setup appropriate permissions for this folder in order to have a successful backup run. From what I have done in our environment, the following accounts need modify (or change) permissions:

1. The account configured to run the Windows scheduled backup task
2. The moss farm account - this is the account used to run SharePoint jobs and Central Administration application pool.
3. The account for SQL Server services.
4. The Sql Server computer account. It's the Sql Server server name with a $ sign. For example, if your server name is sqlserver1, then the account name is sqlserver1$.

The same account permissions need to be configured for Sharing Permission, and Folder permission in Windows explorer.

Error when access a local SharePoint site using host headers

I run into a problem of accessing a SharePoint site which was setup using host headers instead of host name plus port number. When I tried to access the site locally on the server, I was asked to provide authentication information. Even the correct login name and password were given, the server failed to authenticate.

The same site can be accessed from another computer without any problem.

After some research, I found out this is a result of loopback security check that exists from Windows Server 2003 SP1 and later. Micsoft described this feature in the following articles:
http://support.microsoft.com/kb/926642
http://support.microsoft.com/kb/896861

Microsoft also give workaround to fix this issue. The following is a copy and paste from the two articles:

Method 1: Specify host names
Note We recommend that you use this method.

To specify the host names that are mapped to the loopback address and can connect to Web sites on your computer, follow these steps:

Click Start, click Run, type regedit, and then click OK.
In Registry Editor, locate and then click the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
Right-click MSV1_0, point to New, and then click Multi-String Value.
Type BackConnectionHostNames, and then press ENTER.
Right-click BackConnectionHostNames, and then click Modify.
In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.
Quit Registry Editor, and then restart the IISAdmin service.


Method 2: Disable the loopback check
Follow these steps:
Click Start, click Run, type regedit, and then click OK.
In Registry Editor, locate and then click the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
Right-click Lsa, point to New, and then click DWORD Value.
Type DisableLoopbackCheck, and then press ENTER.
Right-click DisableLoopbackCheck, and then click Modify.
In the Value data box, type 1, and then click OK.
Quit Registry Editor, and then restart your computer.


We took the first approach - specifying host names in the BackConnectionHostNames entry and our issue was solved.

Pain with MOSS content import

Today I was trying to import a SharePoint website using Sharepoint Content Depolyment Wizard. I exported the source site to a folder and create the dest site with an empty site collection using stsadm command. When I started imporint I kept having the error "sharepoint import FatalError: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))".

This has driven me crazy. I did a few google search but it didn't help at all.

And finally I got the problem solved. When I created the site collection I specified a different login account as ownerlogin, other than the account I used to login to the server. This makes the given account as site collection administrator, but the current login account doesn't have access to the site collection.

Then I went to central admin, assign the current login as secondary administrator to the site collection. Then the import process was successful.

Unique CorellationToken for each Task activity in WSS workflow

I was strugling with a workflow that the CreateTask did not create a task as expected. After googling around and it turned out that Task-related activities need a unique CorellationToken value.

There are three groups of activities with each group has it's own CorellationToken, and activities with the same group should share the same correlation token:


Workflow token:

OnWorkflowActivated
OnWorkflowItemChanged
OhWorkflowItemDeleted
SetState
SendEmail
UpdateAllTasks


Task token:

CreateTask
CreateTaskWithContentType
UpdateTask
DeleteTask
CompleteTask
RollbackTask
OnTaskChanged
OnTaskDeleted
OnTaskCreated


Modification token:

EnableWorkflowModification
OnWorkflowModified

SharePoint Workflow failed to start

If a workflow is created through a WSPBuilder project, the workflow would have problem to start. To solve this problem, the .csproject file needs to be modified manually. Open the project file in notepad, add the following line

Import Project="$(MSBuildExtensionsPath)\Microsoft\Windows Workflow Foundation\v3.5\Workflow.Targets"

right after the line

Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets"


Then problem solved.

This is really a frustrating issue.

Deploy a wss solution from Visual Studio 2008 extension for WSS has error

It's anoying to have this error when I deploy a soltion:


The feature name XXX already exists in SharePoint. You need to rename the feature before solution deployment can succeed.

To solve this problem you can't just rename the feature as that just adds more mess. The correct approach is to go to SharePoint Central Administration webiste, in the operations web, choose Solution Management.

Find that solution that causes trouble, extract that solution. Then remove that solution from the list.

After the solution is removed, the Visual Studio 2008 can deploy it to SharePoint again.

ADO closes a recordset before any data is read from a stored procedure

Recently I was working on a legacy VB Script file which has following code:

dim conn
Set conn = CreateObject("ADODB.Connection")
conn.ConnectionTimeout = connTimeOut
conn.CommandTimeout = connCmdTimeOut
conn.Open connString

dim dbCmd
set dbCmd = CreateObject("ADODB.Command")
dbCmd.CommandTimeout = 300
dbCmd.CommandType = adCmdText
dbCmd.ActiveConnection = Conn

sqlText = "ReportScheduler '" & currentDate & "' "
dbCmd.CommandText = sqlText
dim rsScheduledReports
set GetScheduledReports = dbCmd.Execute

if not rsScheduledReports.EOF then

...


Each time when the code is executed to this line, an error is generated :

ADODB.Recordset: Operation is not allowed when the object is closed

This is strange as there are actually many records come from the database and this is proved by executing the sql in Management Studio mannually.

The VBScript code worked on SQL Server 2000, recently we upgraded to version 2005 then it breaks.

I spent a lot of time googling on the Internet and finally a trick fixed it. Just add this line to the beginning of the stored procedure: SET NOCOUNT ON.

This makes me thinking what's difference between SQL Server 2000 and 2005 version when adding set nocount on statement in a stored procedure. The behaviour must have changed for new version.