Content Deployment was failing with the following error in the logs:
Title: Field name already exists. The name used for this field is already used by another field in the list. Select another name and try again.
Object: User Information List
We had a publishing site that was upgraded from SharePoint 2007 to SharePoint 2010 that was using content deployent from a staging site to a deployed site.
We could see using SharePoint Manager 2010 that we had duplicates in the destination site that were not in the source site.
We opened a job with Microsoft and we found someone with a similar issue on the msdn forums
Microsoft gave us an executable ‘RemoveDuplicateColumn64‘ to remove the duplicates, we ran it for each duplicate.
The exe prompts you for all the required parameters, one of which is the duplicate internal name which in our case was FirstName0, again we used SharePoint Manager to find the internal name.
We have no idea how these duplicates got there but since removing them a couple of months ago there have been no problems with the content deployment.
This problem could likely be avoided by using the new snapshot content deployment available in SharePoint 2010.
Recently I upgraded a SharePoint 2007 content database to SharePoint 2010 using the database attach method, there were a few gotchas.
- Navigation not showing – displays – ‘Error’
- When rerunning a database attach Upgrade it fails with two errors, in the log the error is Exception: ‘Object reference not set to an instance of an object.’
- Page layout urls still point to the old database
Navigation not showing – displays – ‘Error’
This was an easy one, simply restart the application pool and it should go away.
Unfortunately before I figured this out I thought there had been a problem during the content database upgrade so I deleted the upgrade database and restored the 2007 database tried to rerun the upgrade, at which point I kept getting error number 2.
When rerunning a database attach Upgrade it fails with two errors, in the log the error is Exception: ‘Object reference not set to an instance of an object.’
The was also easily rectified, this happens when you try to rerun an upgrade from within the same command window as previous upgrade, close your powershell window and restart it.
Page layout urls still point to the old database
As part of the upgrade I was moving the site to a new domain, this may also be the case if you are moving a content database to another environment, say your test or development environments.
I had to download the lapontie PowerShell extensions and run the following to remove the wrong url and change it to a relative path.
Get-SPWebApplication "http://<newwebapp>" | Repair-SPPageLayoutUrl -RegexSearchString "(?:http://)" -RegexReplaceString "/"
My client had the requirement to bulk approve or reject items in a document library or list. Using document sets wasn’t the solution as the only thing they had in common was that they all need to be approved at the same time.
I found this excellent solution from Sohel’s blog which was almost perfect…
It handles workflow if they are running which other solutions I found didn’t. One limitation was that it only worked for document libraries, not lists.
All I needed to do was update the elements file to below and I had it on both document libraries and lists.
Description=“Uses the notification area to display a message.“
Alt=“Approve multiple items“
ScriptSrc =“/_layouts/SharePoint.ApproveRejectTest/Scripts/ApproveReject.js” />
I’m sure all your SharePoint sites are far too great to have any internal broken links 😉
But there may be a situation when someone incorrectly links to your SharePoint site and you want to give a custom error page to provide a ‘nicer’ 404 failure page and provide an opportunity for the user to seek more help or to be able to navigate elsewhere on your site.
go from this
to something like this
Here is how you do it
1. Create your custom ‘page not found’ page and approve it. You probably also want to remove it from any navigation and exclude it from search results. I created my custom error page in the pages directory of the root site.
2. go to ..\14\TEMPLATE\LAYOUTS\1033 and take a copy of sps404.html and rename the copy to custom404.html
3. edit the file so that stsnavigate line points to the page you created in step 1
4. Open sp2010 management shell and run the following PowerShell commands (change <sitename> to your site URL)
$webapp =Get-SPWebApplication http://<sitename>
$webapp.FileNotFoundPage = "custom404.html"
To redirect to a custom error page for other http errors see my other blog on How to Create a Custom Error Page on SharePoint
If you are migrating your SharePoint site to a new domain or if you have parallel environments in another domain (e.g. for testing, development etc.) You may wish to move a content database and all its permissions to the new domain.
Here is an easy way to do it.
- Create a SQL backup of the source content database
- Stop the SharePoint services on the destination server
- In SQL Management Studio restore the content database back over the destination content database
- Start the SharePoint services on the server
- Run the user migration script by SharePoint Voodoo. WARNING:- Users need to exist in both the old and new domain.
- You may need to go into SharePoint designer and resave and republish your workflow, if you don’t you may get a ‘user not found’ when starting a workflow or accessing workflow settings
P.S. I doubt if this is the Microsoft recommended method! You could also run a content deployment from the source to destination server.
To perform a successful initial content deployment from a publishing site the destination has to be an empty site.
This is not to be confused with the <blank> site template.
I have had some success when picking the <choose template later> option in the site creation page in Central Admin but sometimes even this fails.
The only sure way of creating a blank site is to use the following stsadm command
STSADM.EXE -o createsite -url <site-collection-url> -ownerlogin <domain\username> -owneremail <email@address>
Users were having a very strange error where they were being continually prompted for login credentials and even when supplying them they would still not get access and their account would lock.
Interestingly this was not happening on all our SharePoint 2010 sites and only happening to users running windows XP with IE8.
I read many articles on DisableloopBackCheck such as this one from Spencer Harbar which also outlines the dangers, however this was not the issue for me.
Then I came across this blog by Lambert about Prompt authentication dialogue issue using IE8 to access SharePoint sites hosted on Windows Server 2008(R2), not quite the same as my issue but made me check my Kernel Mode Authentication for the site in IIS, mine was disabled as suggested in this blog but I also checked this setting for sites that were not having this issue and I found it to be ticked. I ticked it and the login prompts are gone after initial login.
This tick box is un-ticked by default for SharePoint 2010.
So there you have it, if you are having login pop-ups on xp client machines only then check out the setting below in IIS.
PowerShell ISE is a much more convenient way to write and execute SharePoint PowerShell scripts, but you have to perform a few extra steps after the default installation to get PowerShell ISE up and running.
Scot Hilier has written an excellent step by step guide in how to set up PowerShell ISE for SharePoint
Once you have done that check out this Powershell cheat sheet.
Now you will never need to login to ‘Central Admin’ again
Sometimes if a back up fails or for some other reason you SharePoint sites can site can be left quiesced and/or the site collections and central admin site will be locked.
Some of the symptoms of a quiesced or locked farm or site can be a failing content deployment, or users complaining that they can’t edit and have lost their permissions.
Unlike SharePoint 2007 you can no longer unquiesce a farm through central admin unless you add a custom solution such as the one from estruyf .
You have to use PowerShell. Here is the command.
stsadm -o unquiescefarm
Even after running the above command I have still found that some of sites (including central admin) are locked.
You can check you site collections and central admin site are not locked by running the following command
stsadm -o getsitelock -url http://<site>
You can update/unlock using
stsadm –o setsitelock –url http://<site> –lock none