Aborted due to internal error while preupgradecheck

This seems to be a common error while preupgradecheck command runs in SharePoint server. Most of the time, we don’t get an insight from preupgradecheck generated html report, but looking at preupgradecheck logs will give us some idea as what is going on behind the process.

I encountered the same error “Aborted due to internal error” for InvalidDatabaseSchema while running the pre upgrade and the logs have given some idea to proceed towards fixing the errors. I tried finding with ‘InvalidDatabaseSchema’ in the logs which says checking schemas in content database <Database name>… and immediately after this step, there was an error with [SPObjectProcessor] which indicates as below

An unexpected error occured while processing a health analysis rule. This rule will be skipped. The following message was generated by the error: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Data.SqlClient.SqlException: CREATE DATABASE permission denied in database 'master'

This was apparently indicates that the problem is somewhere with the permissions. Then I tried getting the db_owner and security admin roles for my SharePoint farm account on SQL Server followed by running the pre upgrade check once again. Still getting the same error but this time, I did notice that the content database for ‘InvalidDatabaseSchema’ step in the logs was from Secondary SQL server. I then tried getting the same server roles on Secondary SQL server as well, followed by preupgradecheck once again; Surprised to see that the error ‘Aborted due to internal error’ is gone and Invalid Database Schema is passed.

Please note, if you have multiple SQL Servers in the farm, them ensure you have Security admin and db creator server roles on all the SQL servers before running the preupgradecheck.

If you see the same error, then try following the above and see the error goes away.

MySite migration over SharePoint 2010 with custom user profiles properties

MySite migration from MOSS 2007 to SharePoint 2010 would be a complex process, but I would say, it’s rather straightforward when we make a proper plan before migration of mysites. Many thanks to Mike Stevens for step by step approach, however I had to correct few of the steps for powershell cmdlets and verification check points while performing the approach at my environment. I have validated each the steps and try to illustrated the entire process in brief, so that it would help the community users to perform the steps in a seamless manner and make flatten their migration strategy.

Here we begin with,..

1.    Backup your existing MySite content database on your MOSS 2007 farm SQL Server

2.    Backup existing SSP database on MOSS 2007 farm SQL Server

3.    Move both database .BAK files to the new SQL Server( i.e. SP 2010)

4.    Restore the SSP database from .BAK as database named Profile_DB on your new SQL Server

5.    Restore the MySite database from .BAK as database named Content_MySite_DB on your new SQL Server

6.    Ensure the SP 2010 farm account has DB_Owner roles on above two restored DBs.

7.    Create a new Web Application in SharePoint 2010 to host your migrated MySite content (e.g. http://mysites)

8.    Detach the default Database from http://mysites application

9.    Attach and upgrade the restored 2007 MySite database (i.e. Content_MySite_DB) using the SharePoint 2010 Power shell

For e.g.

Mount-SPContentDatabase –Name WSS_Content_MySites –WebApplication http://mysites

10. Check and verify the Database has been upgraded successfully. Central Administration à Check Upgrade Status

If the DB upgrade status is failed, then do not proceed further. Please refer to the upgrade logs for errors and warnings. Troubleshoot them over and attached it back. Try this until you get the status as succeeded.

11. Stop  the following services in your SharePoint 2010 Central Administration site 

Central Administration à Manage Services on Server

·         User Profile Service

·         User Profile Synchronization Service

12. Delete existing User Profile Service Application, if they already exist [Central Administration à Manage Service Applications]

13. Make sure to check the box for delete associated data/content à OK

14. Reset IIS

15. Create a new User Profile Service Application in Central Administration [Central Administration –> Manage Service Applications –> New]

·         Name = “Test User Profiles”

·         Create New Application Pool
“Test Users pool”
DOMAIN\farm_account ( This account should have “Replicate Change Directory Permission on Domain Controller)

·         Profile Database

Use the restored 2007 SSP database as the “Profile Database Name” (Profile_DB)

Accept all other default database names

Enter the newly created MySite web application url (e.g. http://mysites) under My Site Host URL

16. Check and verify the SSP profile Database has been successfully upgraded with creation of User Profile Service Application. Central Administration à Check Upgrade Status

If the SSP DB upgrade status is failed, then do not proceed further. Please refer to the upgrade logs for errors and warnings. Troubleshoot it and try creating the User Profile Service app once again.

17. Go to “Administrators” in the ribbon menu for the User Profile Service Application and add the DOMAIN\farm_account with “Full Control” rights

18. Start the User Profile Service in Central Administration [Central Administration à Manage Services on Server]

19. Start the User Profile Synchronization service in Central Administration [Central Administration à Manage Services on Server]

·         Use DOMAIN\farm_account credentials

This will take a few minutes… wait until it finishes the process and make the Services back to “Started” mode

20. Reset IIS

21. In service.msc on your Central Administration host server (i.e. “App Server”), verify the two ForeFront Identity Management Windows services

·         Services are started
set to startup “Automatic”
Running as DOMAIN\farm_account

22. Setup Profile Import [Central Administration à Manage Service Applications à User Profile Service Application - click on title]

·         Click on the link “Configure Synchronization Connection” then  “Create a new Connection” [see examples below] 

·         Connection Name = “Test User Profile Sync”
Type = Active Directory
Connection Settings = dc.sub.domain
Authentication = Windows Authentication
Account Name = DOMAIN\ad_sync_account

Make sure your chosen account has “Replicate Change Directory” rights in AD

·         Click “Populate Containers”

·         Select the respective OU Containers which you wanted to populate in the user profiles

·         OK

23. Start Profile Synchronization

·         Central Administration à Manage Service Applications à “User Profile Service Application” à “Start Profile Synchronization” à Select the Start Full Synchronization radio button à OK

This will take a few minutes... Wait until you see the “idle” for Profile Synchronization Status on Manage Profile Service page.

24. Access the MySite with domain users and verify it’s accessible with all default user profile properties content.

Note: To get the content of all custom defined properties display on mysite, one must need to run the powershell cmdlet, because after a user profile application has been upgraded from MOSS 2007, single-string and multiple-string value properties are not available for use unless the Move-SPProfileManagedMetadataProperty cmdlet is run to map them to term sets within Managed Metadata Service.

25. To run this command. Open the SharePoint 2010 Management Shell

For e.g. Move-SPProfileManagedMetadataProperty
-ProfileServiceApplicationProxy adcf3276-410c-4083-a925-d51f09b60e56 -Identity SPS-Memberships -AvailableForTagging -TermSetName Memberships

To know the profileServiceApplicationproxy associated with the user profile service application, run the below cmdlet and copy it from powershell console

Get-SPServiceApplicationProxy

Note : Move-SPProfileManagedMetadataProperty cmdlet has to run for all the custom defined properties to mapped to its term sets

26. Verify the custom properties data exist in user profiles for domain users [Central Administration à Manage Service Application à User Profile Service Application à Manage User Profiles]

Try the steps and let me know how it goes. Do not hesitate to post here for any clarifications.

Thanks for stopping at it!!!