Moving Site Collections between Content Databases

I recently had to move a lot of site collections between content databases. The reason is that we don't want content databases to exceed 100GB. We have quota system in place where each site collection has a quota specified.

I did some planning to ensure that the total size of a content database do not exceed 100GB by summing all the quotas of the site collections. i.e. More content databases were created.

There are a lot of blogs out there to move site collections and I am not going to duplicate that. Just a little something I learned along the way.

Make sure there is enough disk space for the move. In other words ensure the drive the log file for the originating content database and the target content database has enough space. If the site collection is 20GB make sure you have 25GB disk space each for the LOG's and another 25GB for the target content database.

If you don't have enough disk space the process will fail. This is what happened to me. But, I then made sure there is adequate disk space for the move. And then the process failed because the Site collection already exists in the target content database. I never cleaned up the previous attempt's writing to the content database.

I then made matters worse by using stsadm -o deletesite -siteid -databasename . I wanted to delete the orphan site in the target content database. Not knowing that the command will remove the site collection out of the configuration.

So now the original content database had the orphan site collection. Luckily this can be fixed easily enough.

stsadm -o deletecontentdb -databasename -url
stsadm -o addcontentdb -databasename

The addcontentdb command forces SharePoint to remap all the site collections in the content database. So the data was never deleted, it was just "lost", or an orphan.

Error Deleting Site Collection

When trying to delete a site collection, the following error pops up:

Command: stsadm -o deletesite -url http://servername/sites/sitename
Error: The system cannot find the path specified. (Exception from HRESULT: 0x80070003)

An error like this prevents you from upgrading SharePoint aswell, because you won't be able to access the site collection either. I found out the hard way.

To resolve the error, detach and attach the content database of the afflicted site collection.
i.e.

stsadm -o deletecontentdb -databasename wss_content_name -url http://servername

stsadm -o addcontentdb -databasename wss_content_name -url http://servername

The resource cannot be found.

A user was complaining that he can't create a library or a list on his sub site. The library was indeed created, but when the user navigated to the library, i.e. /sites/sitename/listname/forms/allitems.aspx, then the error displayed was:

Server Error in '/' Application.

The resource cannot be found.

Description: HTTP 404. The resource you are looking for (or one of its dependencies) could have been removed, had its name changed, or is temporarily unavailable. Please review the following URL and make sure that it is spelled correctly. Requested URL: /xxxx/sitename/listname/forms/AllItems.aspx

This was strange, since the library was successfully created, and you could navigate to the library with SP Designer or with Site Settings -> Content and Structure. Looking into the ULS Logs showed that the site was configured to use a master page that did not exist anymore, e.g.

10/16/2009 11:25:00.34 w3wp.exe (0x10B0) 0x1920 Windows SharePoint Services General 8nca Verbose Application error when access /sites/sitename/listname/Forms/AllItems.aspx, Error=The file /sites/sitename/sitename/sitename/sitename/_catalogs/masterpage/default.master does not exist. at Microsoft.SharePoint.ApplicationRuntime.SPRequestModuleData.GetWebPartPageData(HttpContext context, String path, Boolean throwIfFileNotFound) at Microsoft.SharePoint.ApplicationRuntime.SPVirtualFile.CalculateFileDependencies(HttpContext context, SPRequestModuleData basicRequestData, ICollection& directDependencies, ICollection& childDependencies) at Microsoft.SharePoint.ApplicationRuntime.SPDatabaseFile.EnsureDependencies(HttpContext context, SPRequestModuleData requestData) at Microsoft.SharePoint.ApplicationRuntime.SPDatabaseFile.EnsureCacheKeyAndViewStateHash(HttpContext context, SPRequestModuleData re...

Navigate to Site Settings -> Master Page, will reveal the error as well, e.g.

The system master page setting currently applied to this site is invalid. Please select a new master page and apply it.

Fixed easily enough by choosing a valid master page.

DeadLock Detected Event 2262

Error in the Application Event Log:

Event Type: Warning
Event Source: W3SVC-WPEvent
Category: None
Event ID: 2262
Date: 2009/09/10
Time: 07:31:36 AM
User: N/A
Computer: XXXXXXXXXXXXXXXXX
Description:ISAPI 'C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll' reported itself as unhealthy for the following reason: 'Deadlock detected'.

Checking the SQL server revealed over 30 deadlocks on one content database. Every site in the affected content database was inaccessable. The rest of the sites on other content databases were fine.

While many different reasons could cause the Deadlock, such as third party applications running SQL queries on the content databases with the "No Lock", our problem seemed to be something else.

Further investigation showed that the SQL Server was not configured optimally. The server is 64bit SQL Server 2005 Enterprise. Things we checked and changed:

Make sure that AutoGrow on the Content Databases are set to more than 500MB. As well as the Log files AutoGrow is set to 500MB. IF the log file size increases over 10GB in one day then set the initial size to 10GB.

Max degree of Parallelism, check this blog: http://blogs.msdn.com/grahamk/archive/2009/06/15/troubleshooting-sql-server-deadlocks-and-performance-when-running-sharepoint.aspx

We set our servers Max Degree of Parallelism to 1.

Our server has 16GB Ram. SQL Max memory was set to 14GB, which left 2 GB for the OS and other applications. The number of worker threads in a 64bit environment is 576. Each worker thread requires 2MB of RAM. That equals 1GB of RAM just for the worker threads. AS I understand, if there is not enough memory available for the worker threads, then memory contention occurs.

This could create deadlocks, as some of the worker threads are waiting for the other worker threads to complete.

So, leave 2GB for the OS, 2GB for the worker threads, and at 2 GB for other Applications. So means you set the maximum memory for SQL to 10GB on a 16GB box in a 64bit environment.

All these changes definately increased our server performance.

The parameter is incorrect.

This error: "The parameter is incorrect.", is displayed in the crawl log of a content source. The result is of the error is the problematic site collection is not indexed. After researching the problem on the internet, it became evident that the site collection has an ACL list exceeding ~1000 users. See this blog .

Our problematic site had a lot of broken inheritance and a lot of SharePoint Groups. But I still wasn't sure that the ACLs exceeded 1000 users. So I wrote this little program to get the exact size of the ACL in the site collection:

try
{
using (SPSite _site = new SPSite(url))
{
try
{
IDictionary AllReusableAcls;
AllReusableAcls = _site.GetAllReusableAcls();
System.Console.WriteLine("Count of Values in ACL: {0}", AllReusableAcls.Values.Count);

foreach (KeyValuePair kvp in AllReusableAcls)
{
SPReusableAcl spRACL = kvp.Value;
SPBasePermissions spBase = _site.GetEffectiveRightsForAcl(spRACL);

System.Console.WriteLine(kvp.Key + ": " + spBase.ToString());
}
}
catch (Exception ex)
{
System.Console.WriteLine("Error: " + ex.Message);
}
}
}
catch (Exception ex)
{
System.Console.WriteLine("Error: " + ex.Message);
}

This confirmed my suspicion. There were 2383 keys in the ACL.

As the above mentioned blog propose, we had to reduce the number of keys in the ACL.

While reducing the number of keys in the ACL, as reported by the program, did not solve the problem, it could have compounded the problem.

Further investigation revealed a SharePoint user group with more than 6000 users. When a SharePoint user group exceeds 1000 users, then use an AD Group.

Upload Multiple Documents - Not shown on menu

This could be due to a corrupt Office 2007 installation on the client machine. Repair or reinstall Office 2007 on the client machine.

Or it could be due to ActiveX Security settings in the browser. Check the security settings for the applicable Zone. I.E. Check that ActiveX is allowed.

Or check in Central Admin/Application Management/Authentication Providers, select the correct Web Application and click on default. Ensure that "Enable Client integration" is set to "yes".

Top Link Bar

Not an error exactly, but the Top Link Bar doesn't highlight correctly, i.e. when you click on a subsite, the button is not highlighted.

Rather annoying, but simple to fix.

1. Site Settings
2. Top Link Bar
3. Edit the Link properties

Make sure the link is in relative URL format and includes the page, i.e. /sites/sitename/default.aspx, or /someurl/somesite/mypage.aspx

If you can't edit the link, then delete the button, and recreate it.

Thats it!

SharePoint designer Hit Counter not work after installing SP2

This blog helped me: click me.

RENDER FAILED

After applying SP2, I got this error only on one site collection. Most of the lists gave returned this error. Also editing the Web Part gave this error: Cannot save the property settings for this Web Part. Incorrect function. (Exception from HRESULT: 0x80070001).

Resolution in this case: Site collection Locked, unlock site collection.

Import and Export using STSADM

There is a lot of information on the Web for using the import and export function of stsadm. I must say I have picked up two things that I can't find on the Web. Maybe it will be useful for you to.

Like all the other blogs/site say, make sure the patch levels are exactly the same between the origin server and destination server.

When migrating content that uses one of the 40 free templates from Microsoft, then your manifest.xml will have some funny stuff in it.

Error when trying to import:
FatalError: The content type name cannot contain: \ / : * ? " # % < > { } ~ &, two consecutive periods (..), or special characters such as a tab.

This is due to the in the content type name. To resolve it is simple, but a lot of work.

Example:
Open the manifest.xml (from your export folder, either use nofilecompression, or open the cab and extract it. Problem is, you will have to build the cab file after editing the manifest.xml)

Name="$Resources:tsa,transaction;"
In the 12 hive (12\Resources), open the file tsa..resx. Search in the file for text: transaction,
<data name="transaction" space="preserve">
<value>Transaction</value>
Now we have the value with which we will replace in the manifest.xml
Name="$Resources:tsa,transaction;" will change to
Name="Transaction"

And that is it. There will however be a lot of $Resources: tags. I made a script that replaces all the $Resources: with the correct value.



The other problem is, we have a tool called Quest. Now Quest has a lot of event handlers. This is to audit and track actions on SharePoint. So, when you export a site on a SharePoint Server that has Quest installed, then you export the Event Handlers as well. As in:

<eventreceivers>
<eventreceiver id="6e590fc1-4538-407f-8443-faedc5a5c222" class="Quest.ITSP.Monitor.Solution.EventReceivers.CEventReceiver4Item" name="Quest.ITSP.Monitor.Solution.EventReceivers.CEventReceiver4Item::ItemAdding" webid="0faba338-278d-4cad-8f1a-93a9d64d3d1e" hostid="0faba338-278d-4cad-8f1a-93a9d64d3d1e" hosttype="Web" type="ItemAdding" sequencenumber="10064" assembly="Quest.ITSP.Monitor.Solution, Version=1.1.0.452, Culture=neutral, PublicKeyToken=39f564e586a37f3c" data="" filter="" credential="0">
<eventreceiver id="3b84a287-8173-436e-bd3d-148fff8b987d">
....

Just delete the Quest Event Receivers from the manifest.xml.

Edit: 24/07/2009: If the target server does not have Quest installed, then you should remove all references to Quest. All the EventReceivers that reference Quest, as well as:

<SPObject Id="f90f3a29-6297-40a2-bc83-c3f23be994cb" ObjectType="SPFeature" ParentId="" ParentWebId="597c735e-0060-4e20-83a9-1447040f9fce">
<Feature Id="f90f3a29-6297-40a2-bc83-c3f23be994cb" FeatureDefinitionName="Quest.ITSP.Monitor.Web" WebId="597c735e-0060-4e20-83a9-1447040f9fce" />
</SPObject>
in the manifest file.
AND in the Requirements.xml:

<Requirement Type="FeatureDefinition" Id="f90f3a29-6297-40a2-bc83-c3f23be994cb" Name="Quest.ITSP.Monitor.Web" />



There you go!

Could not load file or assembly 'Microsoft.SharePoint.ApplicationPages, ....'

When a user tries to open a site page on SharePoint, or view the Version History of a document. I don't know why this happens. [Edit] Some pages displays fine, others don't.

What you can try is to add a space to the end of the web.config file (of the affected IIS Site), and save the web.config file. Worked for me.

InfoPath - Insufficient Security Privilege

Certain users get "Insufficient Security Privilege - This form cannot be opened because it requests domain security level and is only allowed restricted security level. Contact the form author to resolve the issue."

1. Clear the Internet Explorer Cache
2. Delete all files under %UserProfileFolder%\Application Data\Microsoft\InfoPath
Should actually be only 1 file, infopath.tbs.
3. Delete the cache in %UserProfileFolder%\Local Settings\Application Data\Microsoft\InfoPath\FormCache2 - For Office 2007 or FormCache1 for Office 2003

Problem should be sorted.

Resolution for Event ID 7888 - Only site admin can access Data Source object from user profile DB

My SharePoint Farm runs in least privileges mode. For over a year it has been running without the 7888 Event. All of a sudden it started logging the error on the indexing server. This Blog Post helped.

The specified web does not contain a reporting metadata list

Occurs when a user wants to view the "Site Audit Log" or "View Workflow Reports".

Something that happens when you import a site. The Reporting Features are active, but do not work. I think this is what caused it in anycase. Could be something else.

Deactivating the Reporting Features at Site Collection Level and then running the following command:

stsadm -o activatefeature -name Reporting -url http://servername/sitecollection -force

Seems to fix the problem.

Exception from HRESULT: 0x80040E14

When a user tries to edit or add an item on SharePoint, the following error is displayed:

Exception from HRESULT: 0x80040E14

This could be due to "Not enough disk space on the SQL Server".

First Blog .... ever!

This is my first blog. I have never attempted to blog. This blog will be all about SharePoint and the funny stuff that happens to me whilst administrating SharePoint.

Short, concise, to the point.