stsadm error when using createsiteinnewdb

Had a peculiar problem where a customer received errors when using the above command to provision a new suite collection.
The error was: stsadm: Value cannot be null. Parameter name: v1

It appears that this was entirely down to a change in SQL access rights for the service running WSS

Further investigation found the following full error in the logs:

stsadm: Value cannot be null. Parameter name: v1 Callstack: at System.Version.op_LessThan(Version v1, Version v2) at Microsoft.SharePoint.Administration.SPDatabase.EnsureSqlDatabase(SqlConnectionStringBuilder connectionString) at Microsoft.SharePoint.Administration.SPDatabase.SetDatabaseOptions(SqlConnectionStringBuilder connectionString, Dictionary`2 options, Boolean wYukon) at Microsoft.SharePoint.Administration.SPDatabase.Provision(SqlConnectionStringBuilder connectionString, SqlFile sqlFileId, String sqlSignaturePath, Dictionary`2 options) at Microsoft.SharePoint.Administration.SPContentDatabase.Provision() at Microsoft.SharePoint.Administration.SPContentDatabaseCollection.Add(SPContentDatabase database, Boolean provision, Boolean allowUpgrade, Boolean flushChan...

Ensuring that your custom master file is loaded on each new site created

The following code ensures that when a site is provisioned it uses your master file.

Once you have compiled it you will need to register the http module in the web.config file.

e.g.

<add name="ensuremaster" type="ensuremaster.ensuremaster,ensuremaster, Version=1.0.0.0, Culture=neutral, PublicKeyToken=e2afe595d5cd71e3" />

using System;

using System.Web;

using System.Web.UI;

using System.IO;

namespace ensuremaster

{

public class ensuremaster : IHttpModule

{

public void Init(HttpApplication context)

{

context.PreRequestHandlerExecute += new EventHandler(context_PreRequestHandlerExecute);

}

void context_PreRequestHandlerExecute(object sender, EventArgs e)

{

Page page = HttpContext.Current.CurrentHandler as Page;

if (page != null)

{

page.PreInit += new EventHandler(page_PreInit);

}

}

void page_PreInit(object sender, EventArgs e)

{

Page page = sender as Page;

if (page != null)

{

// Is there a master page defined?

if (page.MasterPageFile != null)

{

// only change the default.master files as those are the offenders

page.MasterPageFile = "/_catalogs/masterpage/samplests.master";

}

}

}

public void Dispose()

{

}

}

}

In order to remove 'Open in Windows Explorer' from the 'Actions Menu' for all users other than Website Owners

· Make a copy of the DefaultTemplate.ascx form the 12\templates\controltemplates\ directory.

· Rename the copy to CustomDefaultTemplate.ascx.

· Find the line ID="OpenInExplorer" (usually line 1812).

· Change PermissionsString="UseClientIntegration" to PermissionsString="ManageWeb" and save the file.

· Reset IIS.

WSS Emailing Itself -: x-mailer: Windows SharePoint Services (version 3)

I had a case recently where a client wanted to send access request emails to an email enabled document library. We encountered the problem of WSS not being able to handle the x-mail header.
A solution was to create a vbscript that fired when an email entered the 'Drop' folder of IIS mailroot and stripped out the problematic header.
Initial testing proved successfull and this has now been implemented.


solution
1. copy Smtpreg.vbs into the c:\inetpub\AdminScripts - smtpreg is available to download from MS.

2. create a vbs file from the script below and copy it to the AdminScripts folder (I named mine wss)

3. run the following commands to register the script

cd c:\inetpub\adminscripts
cscript smtpreg.vbs /add 1 OnArrival DeleteMsg CDO.SS_SMTPOnArrivalSink "mail from=*"
cscript smtpreg.vbs /setprop 1 OnArrival DeleteMsg Sink ScriptName "c:\Inetpub\AdminScripts\wss.vbs"

4. This will now catch all mail on arrival and remove the offending header.