Please upgrade your web browser now. Internet Explorer 6 is no longer supported.
Zac Smith
SharePoint, WSS and MOSS development.

Multiple content databases - which is the default?

by Zac Smith 20-Jul-07, 0 Comments
One awesome new feature in WSS V3 is the ability to have multiple content databases per web application.
This can help make your databases more manageable if you have some really big sites.
One real life scenario that I have seen recently is with a client that has a WSS deployment with about 15 site collections. Most of the site collections are less than 1GB in size. However there is one site collection that is around 15GB. We decided to lump all the small site collections in one content database, and dedicate another content database to the large site collection.
This has a number of benefits around scalability, ease of backup and restore, increased flexibilty for DB migration and so on.
But after we have setup our content databases how do we ensure that any new site collections created will go in the right content database?
At first I thought any new site collections were created in the content database that was attatched last.
The real answer though is that any new site collection will be created in the database with the biggest difference between existing sites and maximum number of sites allowed.
Going back to my previous example which has the following setup:
DB Name
Num Sites
Max Sites
LargeSiteDB
1
50
SmallSitesDB
15
50
 
In this situation any new site collections will be created in the LargeSiteDB. I want this site collection to host just the one database so this is no good.
 
To remedy this there are two options:
1/ Set the LargeSiteDB status to offline. This doesn't take the DB offline - it just prevents the creation of new site collections.
2/ Reduce the Max Sites on LargeSiteDB to less than 35.
 
I would reccommend doing a combination, it would be good practice to set LargeSiteDB to offline anyway, and lowering the Max Sites value is a good indicator to other administrators.
 
Categories:

Restoring a content database to a new server

by Zac Smith 17-Jul-07, 0 Comments
This is a pretty basic procedure, but I have seen it gone wrong so many times I thought it worthy of a quick blog post.
 
The process is as follows:
1/ Take a SQL backup of an existing content database
2/ Restore SQL backup to new server
3/ Create managed paths to match the structure on the previous server ** important (see below)
4/ run the following stsadm command to attach the content db.
stsadm -o addcontentdb -url [WebAppURL] -databasename [RestoredDBName]
 
 
**
Step number 3 is where the problems all occur. When the addcontentdb command is run, the configuration database will be populated with all the sites in the content database. They will be populated according to the path structure in the previous server. Therefore your sites will not be restored if the managed paths do not exist.
Categories:

User cannot be found error

by Zac Smith 12-Jul-07, 1 Comment
When clicking on the Site Collection Administrators link in Central Admin the following error screen displays:
 
This annoying error can occur during wss migrations, basically it means the primary or secondary site collection administrator refers to a user that does not exist.
Unfortunately it is not possible to get into the screen where you would make the change. The STSADM command siteowner returns the same error.
 
The only solution that I have found is to make a small edit to the database. To do this open up the content database that corresponds to the site collection and look at the Sites table. Find the row for the site that is throwing the error and update the ownerID or SecondaryContactID (See disclaimer below).
 
Now if you have a number of sites then you will need to work out which site is causing the problem - and the guids arent terribly descriptive.
 
So how do we work out which one? PowerShell to the rescue!!
If you haven't discovered the awesomness of PowerShell you should go away and do that right now. Otherwise you can keep reading :)
 
The first command I will run loads the SharePoint dll (I actually have this setup in my profile).
 
[System.Reflection.Assembly]::Load("Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c")
 
Then I will create and SPSite object that will contain a reference to the site collection that is causing the error.
 
$spsite = New-Object Microsoft.SharePoint.SPSite("http://wsssite")
 
Now I can run commands on this object to discover various pieces of info. I could have created a little visual studio console app but that would just be annoying, plus interactively inspecting .Net objects is pretty damn cool.
 
So to get the site ID:
$spsite.ID.ToString()
 
And to get the details of the primary/secondary site coll admin details:
$spsite.RootWeb.SiteAdministrators
 
if you want a list of all available users you can try:
$spsite.RootWeb.AllUsers | ft Name, ID -auto
 
Now once you have worked out which user is causing problems (it could be both). Just update the IDs with valid user IDs and try navigating to the site collection administrators screen.
 
Disclaimer:
Editing the database in SharePoint is completely unsupported by Microsoft. If you do decide to make changes, I'd highly recommend making a backup first.
Categories:

Move a WSS sub site to the top level

by Zac Smith 9-Jul-07, 1 Comment
Had a situation recently where I needed to promote a subsite to a top level site. As STSADM backup/restore can only be used at the site collection level, a different approach was required.
As of WSS v3, there are two new STSADM commands - import and export.
The basic procedure to promote the subsite was to STSADM export the site to a file and then STSADM import it at the toplevel.
Here are the basic commands I used:
 
Export subsite
stsadm -o export -url http://toplevel/subsite -filename c:\subsite.bak -includeusersecurity -versions 4
 
Import subsite
stsadm -o import -url http://toplevel/ -filename c:\subsite.bak -includeusersecurity
 
A couple of things to note:
The -includeusersecurity switch ensures that all the columns such as modifed by, created by are maintained.
 
The -versions 4 switch will ensure that all versions of list items/documents are exported.
 
You must import/export to sites that share the same template. So a team site can only be exported and imported into another team site. You will know you are trying to import into non matching templates if you get the following error:
 
"The exported site is based on the template STS#1 but the destination site is based on the template STS#0" 
 
This means that a site based on the blank template is trying to be imported into a site based on the team template. To my knowledge there is no easy way of changing a sites templates.

The following lists some of the common WSS templates:

Team Site STS#0
Blank Site STS#1
Document Workspace STS#2
Wiki Site WIKI#0
Blog BLOG#0

 
If you want to know more there is a wealth of information on a blog post by Jackie Bodines. 
Categories:
SharePoint MVP
Subscribe with RSS

    follow me on Twitter »


    Friends

    Archives