3

After mounting my WSS_Content database, I went back to the migrated site collection to upgrade it, once I click "Im ready" to start the site collection upgrade, the processing screen flashes and then it goes to a white screen. Any assistance would be great

The log files read:

Failed to read resource file "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\Resources\ReportServerResources.en-US.resx" from feature id "(null)". 5db4fd9c-949d-9007-4fb6-adcf6da30e07

Failed to open the file 'C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\Resources\ReportServerResources.resx'. 5db4fd9c-949d-9007-4fb6-adcf6da30e07

"#20015: Cannot open "": no such file or folder. 5db4fd9c-949d-9007-4fb6-adcf6da30e07

(#2: Cannot open "": no such file or folder.) 5db4fd9c-949d-9007-4fb6-adcf6da30e07

I downloaded a patch to the SQL Server and now the files are there but it still goes to a white screen

6
  • did u try to upgrade the site collection with powershell?
    – Nk SP
    Apr 22, 2015 at 18:01
  • Yes, it goes to 100% then fails and says cannot complete this action
    – SpGurlz
    Apr 22, 2015 at 18:08
  • check the log from the upgrade monitor (http://centralAdmin/_admin/UpgradeStatus.aspx)
    – Nk SP
    Apr 22, 2015 at 18:11
  • after upgrading the SQL, did you try the upgrade site collection? if yes then what logs says
    – Waqas Sarwar MVP
    Apr 22, 2015 at 18:11
  • The database has been mounted already the CA Logs only tell me about the restoration of the db. The SQL Logs no longer tell me anything about the upgrade
    – SpGurlz
    Apr 22, 2015 at 18:13

2 Answers 2

1

You need to make sure the web applications and customizations are in place before you mount the content database to the web application. The full process is described in the article Upgrade content databases to SharePoint 2013:

Create Web Applciations

Create a web application for each web application that existed in the SharePoint 2010 Products environment. For each web application, do the following:

  • Use the same URL (including name, port, and host header) and configure alternate-access mapping settings.

  • If you use a different URL, Office applications might not be redirected correctly to the new URLs and all bookmarks to the old URLs will not work.

  • Use the same authentication method. For example, if you use Windows Classic authentication in your old environment, and you want to continue to use it, then you must create a web application that uses Windows Classic authentication. Because claims-based authentication is now the default option for SharePoint 2013, you must use Windows PowerShell to create a web application that uses Windows Classic authentication. For more information, see Create web applications that use classic mode authentication in SharePoint 2013 and Create claims-based web applications in SharePoint 2013. Alternatively, you can migrate to claims authentication. For more information, see Migrate from classic-mode to claims-based authentication in SharePoint 2013.

  • Recreate included paths.

  • Recreate quota templates.

  • Configure email settings for the web application. For more information, see Configure email integration for a SharePoint 2013 farm.

  • Enable self-service site creation for any web application that used it in the previous environment. Recreate any self-service site creation settings.

  • Create the managed path for the My Sites (/personal) on the web application that hosts My Sites. My Sites are available in SharePoint Server only.

  • Recreate any web application policies or other web application settings that you had configured in the previous environment.

Reapply customizations

One frequent cause of failures during upgrade is that the new environment does not have customized features, solutions, or other elements. Make sure that all custom elements from the SharePoint 2010 Products environment are installed on your front-end web servers before you upgrade any content databases.

In this step, you manually transfer all customizations to your new farm. Make sure to install any components that your sites depend on to work correctly, such as the following:

  • Custom site definitions
  • Custom style sheets, such as cascading style sheets, and images
  • Custom Web Parts
  • Custom Web services
  • Custom features and solutions
  • Custom assemblies
  • Web.config changes (such as security) Ensure that you transfer all unique settings from the Web.config files for each web application to the new servers.
  • Administrator-approved form templates (.xsn files) and data connection files (.udcx files) for InfoPath. InfoPath is available in SharePoint Server 2010 only.

Any other components or files on which your sites depend.

SharePoint 2013 can host sites in both SharePoint 2010 Products and SharePoint 2013 modes. The installation for SharePoint 2013 contains both SharePoint 2010 Products and SharePoint 2013 versions of many elements. The directories on the file system are duplicated in both the 14 and 15 paths, for example:

  • Web Server Extensions/14/TEMPLATE/Features
  • Web Server Extensions/15/TEMPLATE/Features

There are also two versions of the IIS support directories: _Layouts, _Layouts/15 and _ControlTemplates, _ControlTemplates/15.

Be sure to install customizations to the correct location in your new farm. For example, additional style sheets for SharePoint 2010 Products should be installed in the /14 path, not the new /15 path so that site collections that you haven’t upgraded can use them. If you want a solution to be available to both paths, install it two times, and the second time use the CompatibilityLevel parameter when you install it, and it will be installed to the /15 path. For more information, see Install-SPSolution.

For more information about how to update customizations for use in SharePoint 2013, see Redeploying Customizations and Solutions in SharePoint Foundation 2010 and SharePoint Server 2010. For more information about how to deploy customizations to your environment, see Install and manage solutions for SharePoint 2013.


When all this is done, you need to verify custom components by

Stsadm -o enumallwebs -includefeatures -includewebparts

This operation can report the templates, features, Web Parts, and other custom elements that are used for each site.

Run Test-SPContentDatabase to see if you're missing any solutions, features, managed paths or templates in your 2013 Web App.

Test-SPContentDatabase -name WSS_Content_DB -webapplication http://sitename

Follow the messeges and add the missing configuration/solutions/templates to your web app.

7
  • Ran that just a few features missing but it says it should not block the upgrade
    – SpGurlz
    Apr 22, 2015 at 19:09
  • @SpGurlz And it didn't. You actually had the site in a 2013 farm, with a GUI of 2010. But when you tried to upgrade the GUI to 2013 - something broke. And you need to fix it by adding and enabling the missing features.
    – Benny Skogberg
    Apr 22, 2015 at 19:20
  • How do I add these features?
    – SpGurlz
    Apr 22, 2015 at 19:33
  • @SpGurlz I guess you have them in a solution in the old farm, and you can extract the wsp (solution file) from the old farm and then run Add-SPSolution and then Install-SPSolution in the new farm. Follow the guide on how to extract wsp from 2010 farm
    – Benny Skogberg
    Apr 22, 2015 at 19:38
  • @SpGurlz I've updated my answer and included steps to take during content migration.
    – Benny Skogberg
    Apr 23, 2015 at 5:56
0

Although this is old, I wanted to share my solution. I had a ghost site sitting out there, I removed the site and I was able to upgrade the site collection. Here are the steps I took

PowerShell Script to find all websites

$site = get-SPSite https://<site> $w = $sites.webs $w $sites | gm $sites.allweb > C:\allweb.txt

If the site is in the list get the web id of the site using a Powershell Script

stsadm –o databaserepair –url https://<site> -databasename <database>

Find the second web id using the PowerShell Script below

stsadm -o enumallwebs -databasename <database> > C:\Allwebs.xml

Open the xml file and locate the site id. Use the second web id to forcefully delete the orphaned site.

stsadm -o deleteweb -force -webid <WebID> -databaseserver <SQL Server> -databasename <database>

Run the PowerShell script again to see if the site is now removed from the web site list

stsadm -o enumallwebs -databasename <database> > C:\Allwebs2.xml

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.