During Database Attach Upgrade, not sure how to successfully use Test-SpContentDatabase

Question

I'm using the following Technet articles to do a test migration of my WSS 3.0 site collection to SharePoint Foundation 2010 using the Database Attach Upgrade method:

"Attach databases and upgrade to SharePoint Server 2010"

"Upgrade process overview (SharePoint Server 2010)"

"Prepare the new SharePoint Server 2010 environment for a database attach upgrade"

I've jumped from these articles to a number of other linked Technet articles to work through the process so far.  I'm doing this in a test environment I've (thru considerable work) set up to mirror my production environment.

I've created a new SharePoint Foundation farm, and as directed in the last article linked above, created a new Web application, Site Collection, etc,  using the same URL as the existing WSS 3.0 Web application. I'm now attempting to "Verify the new environment" by running the Test-SpContentDatabase command against my original WSS 3.0 content database (still in service in the test environment's WSS 3.0 Farm) AND my newly created and configured Web Application with the identical name in the SharePoint Foundation Farm.  That's where I'm running into trouble.

Below is the command I'm running and the resultant output:

Test-SpContentDatabase -name ContentDB -webapplication http://intranet -serverinstance SQL\WSSInstance 

Category : SiteOrphan Error : True UpgradeBlocking : False Message : Database [ContentDB] contains a site (Id = [obscure-GUID-11lkn124 blah blah], Url = [/]) whose url is already used by a different site, in database (Id = [different-obscure-GUID-1978432 blah blah], name = [ContentDB]), in the same web application. Consider deleting one of the sites which have conflicting urls. Remedy : The orphaned sites could cause upgrade failures. Try detach and reattach the database which contains the orphaned sites. Restart upgrade if necessary.

It seems pretty clear to me I'm having issues because in both the old and the new farm my DBs and Web Applications are identically named.  I used the same names not only because I was directed to by the documentation, but also because those names make sense to me and I want to preserve them.  However, I'm not sure what to do next.

On a guess, I tried detaching the WSS 3.0 content DB from the WSS 3.0 farm, thinking that might remove the associations recorded in the DB with the WSS 3.0 web application and resolve the error.  Alas, it didn't change anything.

Advice?  Thoughts?  Suggestions?  If anybody knows of a better walkthru or guide than the TechNet documentations, I'm open to them.  I will say, I'm really glad I'm doing this in a test environment, but even a failure or screw-up here is painful, given the amount of time and work that's been required to set this all up.

Thanks in advance!

BJ

Answer 1

I've created a new SharePoint Foundation farm, and as directed in the last article linked above, created a new Web application, Site Collection, ...

Category : SiteOrphan Error : True UpgradeBlocking : False Message : Database [ContentDB] contains a site (Id = [obscure-GUID-11lkn124 blah blah], Url = [/]) whose url is already used by a different site, in database (Id = [different-obscure-GUID-1978432 blah blah], name = [ContentDB]), in the same web application. Consider deleting one of the sites which have conflicting urls. Remedy : The orphaned sites could cause upgrade failures. Try detach and reattach the database which contains the orphaned sites. Restart upgrade if necessary.

This error is saying that in the content database exists a site "/" that exists in the new web application. This makes sense since in your new farm you've already created the site collection.

I suggest you delete the root site collection (at "/") in the new 2010 farm and try the Test-SPContentDatabase again. The error should no longer appear.

In theory, if Test-SPContentDatabase finds no issues it will output nothing at all.

---

Jason Warren
Infrastructure Specialist
Habañero Consulting Group
www.habaneros.com/blog

Answer 2

The error message says it all,

At target, you have a site collection which is causing all this,Do the upgrade on the blank Web Application. Having same name at two different farms for the the web application wont do any damage. It should do the check without any error. All the best!

---

Ashish Ranjan (Please click "Marked As Answer" if a post solves your problem or "Vote As Helpful" if a post has been useful to you)

Answer 3

Jason and Ashish,

Thanks for your replies.

Jason: My site collection exists (on both old and new farms) as http://intranet/.  However, when I go to the Site Collection List (also on old and new farms) I see what you are saying: the URL on the left is simply listed as / , but the table on the right looks kind of like the following:

URL http://intranet

Title The Intranet

Description

Primary Administrator: DOMAIN\administrator

E-mail address: [e-mail]

Database Name: ContentDB

The only other web application I have is the Sharepoint Central Administration.

It seems I have a chicken and egg problem; clearly I can't delete the Web Application that I'm trying to test the ContentDB against (apparently the root, even though it's at http://Intranet/ ??), but if I create the web application with a different name or with a different heirarchy, I'm no longer following the instructions in the article "Prepare the new SharePoint Server 2010 environment for a database attach upgrade" which state I should create a Web Application with the same URL and alternate access mappings.

Maybe I'm okay to create a second web application with a totally random URL solely for the purposes of running the Test-SPContentDatabase?  And if the results don't expose any issues, I can assume my actual destination Web Application will handle the migration just fine?

Ashish,

Thanks for your reply also, but I wonder if you really read and understood my question?  Or perhaps I don't fully understand what you're suggesting I do. I think it SHOULD do the check without any error as you say, but clearly I'm getting an error.

Thanks again, sorry for the delay in replying - I've been occupied with other things this week.

BJ

Answer 4

It seems I have a chicken and egg problem; clearly I can't delete the Web Application that I'm trying to test the ContentDB against (apparently the root, even though it's at http://Intranet/ ??), but if I create the web application with a different name or with a different heirarchy, I'm no longer following the instructions in the article "Prepare the new SharePoint Server 2010 environment for a database attach upgrade" which state I should create a Web Application with the same URL and alternate access mappings.

Do you need the site collection that is at the root in the new farm? My assumption is no -- you are attempting to migrate a database to this web application. The database contains the root site collection, in which case the site collection in the new web application is not needed. Yes, you need to create the web application, but you most certainly do not need to create a site collection in this web application in order to migrate a database that contains the site collections you are migrating.

To put another way: you do not need to delete or create a new web application in the new farm. You do need to verify that the root site collection at / is of value to you (again, my assumption is it is not, you created because you were copying the old farm). Delete the site collection if it is not needed and then run Test-SPContentDatabase. If you need it, then we need to figure out another plan of action.

---

Jason Warren
Infrastructure Specialist
Habañero Consulting Group
www.habaneros.com/blog

Answer 5

Jason,

Thanks for the speedy reply! Before I saw it, I acted to test my own theory by creating a new test Web application with a new site collection, on the assumption the identical names were the cause of the conflict. The command still failed with the same error message.

Your reply contained the insight I needed: The Test-SPContentDatabase command is meant to check a database against a *Web application*, not against a *site collection*. After seeing your reply I deleted the site collection in the Web application I'd just created, and ran the command again.  Success!!  At least, I think it's a success - instead of an error message, I got absolutely no output from the command at all, which from your earlier reply I believe is exactly the desired result.

After a careful re-reading of the "Prepare the new environment" article I previously referred to, I realize now that it only talked about recreating the Web Application. I mistook its advice to "Re-create included paths (such as /Sites)" to mean I should recreate the site collection, which I realize now is not what it meant.  The answer from Ashish now also makes sense to me in the context of this understanding, although I couldn't have made the leap without Jason spelling it out for me.

Thanks again for guiding me through this - hopefully others who make the same mistake I did can find this thread and realize their error.

Gratefully,

BJ

Answer 6

Awesome, I'm glad you figured it out!

Yes, no output is the desired output. HOWEVER, this does not mean there will be no errors when mounting the database, Test-SPContentDatabase just validates some obvious things (in this example a site collection with the same path, but others include missing solutions, web parts, wrong versions, etc).

Do check the upgrade logs after the attach.

---

Jason Warren
Infrastructure Specialist
Habañero Consulting Group
www.habaneros.com/blog

Answer 7

Will do. I've already run the STSADM.EXE -o preupgradecheck and resolved the couple of minor issues it discovered, so with both of these commands now giving me an apparently clean bill of health, I'm hoping my upgrade goes smoothly. I've never done much tweaking or customizing of the site collection, but I'll find out soon.

BJ