SharePoint:FieldValue in 2010

In your migrated pages, you should see them all work correctly.  However, the moment you go to do something in the new Page Layouts of SharePoint 2010, you will quickly find that it doesn't work.  The new register directive sets the tag prefix as SharePointWebControls, NOT as SharePoint.

In 2007:

<SharePoint:FieldValue FieldName="CompanyUrl" runat="server" />

In 2010:

<SharePointWebControls:FieldValue FieldName="CompanyUrl" runat="server" />

Again, this is all driven from the register directive at the top of the page.


Field type BusinessData has duplicate definition

Another casualtiy of my upgrade.  The 12 Hive remains in the upgrade process, for some reason, SharePoint is still aggregating the old directory.  I removed the files (by raring them, just in case I needed any older non-migrated field types later) in the C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions12TEMPLATEXML directory and reset IIS.  The error went away 🙂


Database is too old and upgrade is required – WSS_Search SharePoint 2007

You may get one of these errors in your Health Analyzer logs.  I am getting it on a database called WSS_Search_SVR-WEB1.  What happened was that I had two server in my farm, one of which I decommisioned to move to 64bit before moving to 2010.

The older SVR-WEB1 had the WSS Search database tied too it.  But somehow when I decommisioned it, the entry in the objects heirarchy table remained (it became orphaned and the 2010 upgrade checker didn't say jack about them) and now I'm stuck with this weird database that is really OLD and SharePoint 2010 does NOT like.  How do I remove it? 

As always, I left with resorting to the objects table and doing a 'name like' and 'properties like' query to find anything that was related to the old server.  Once I find those things i run the STSADM -o deleteconfigurationobject -id "<object id>" command to remove them.

After removing the orphaned objects, I re-run the Health Analyzer job and the error goes away!  Whoot!


Missing server side dependencies. – SharePoint 2010

This error is like a catch all of anything that could go wrong in your 2010 Farm, especially after upgrade!  There is a reason the 12 Hive is left over at the end of the upgrade.  You have stuff in it!  If you don't write a feature upgrade event for all your custom features before youdo the upgrade, your feature directories don't get copied over.  The majority of errors I have for this health Analyzer Rule is from this very fact.  All I had to do was to move the older features over to the new 14 hive features directory.  Then all was good!

You can also reference this older post about the other causes of this error here.


Migrating User Forms Based Permissions in 2010 Upgrade

So not everything gets upgraded in the RTM build of 2010.  Seems the usernames and permissions end up getting lost when you upgrade.  There are several things you have to do to get your upgraded forms based authentication to work:

First error you will get is "Forms Based Authentication on classic Web applications has been deprecated."  this is solvable by opening SharePoint 2010 Management Shell to upgrade the web application to use claims based authentication

$w = Get-SPWebApplication "http://webappurl/"
$w.UseClaimsAuthentication = $true;

Second thing is to enable your forms based auth in the SecurityToken Service as in my other blog post

Next you need to ensure that your settings are valid in the Framework64 directory if you are using the machine.config to propagate your sql server settings for Aspnetsqlmembership.  This changed as SharePoint is now 64bit, and not 32bit.

Once this is done, you will NOT be able to login!  Why?  Because the internal naming of the user you have setup as the site collection administrator was tied to the old aspnetsqlmembershipprovider:username naming scheme in the databases.  The new naming convention is  i:0#.f|aspnetsqlmembershipprovider|username

How do you update this?  well, other than going into the database and updating it directly, you really have only one other choice, remove and add each user!  If you have 100's of users, if not 1000's, well your in for a long day!  Luckily, I wrote a nice little powershell script that goes in and adds/removes all the users.  Here it is (as with anything, use at your own discretion):

$spweb = get-spweb "webappurl"
foreach($spgroup in $spweb.groups)
write-host $

foreach($spuser in $spgroup.users)
write-host "Migrating: " $
$newuser = $spweb.ensureuser($
write-host "SPUser=" $spuser
write-host "NewUser=" $newuser
write-host "Adding user:" $ " to group: " $
if ( $newuser.userlogin -ne $spuser.userlogin)
write-host "Removing old user:" $ " from group: " $