03-07/10: List views are broken after migration.

Issue:

A source 2003 document library view has been modified by a user. Administrator performs the library migration and does not see error messages. But when the user goes to the target 2007 document library he does not see any objects there (the view is empty or contains an error message)
Example:
List views are stored in file system but the view changes are stored in database. When MM performs migration he applies changes incorrectly.

 
For example MM incorrectly migrates view in the following scenario:
You have Explorer view set as default view for the document library. When a user adds a new column the “Add to default view” option is checked and default view is modified. When administrator migrates the document library, the Explorer view is broken. It displays one column and it looks like there are no documents in the target document library.
Note: There might be other scenarios how to modify source view that MM migrates them incorrectly.

 
How to fix:

There are the following solutions: 

1. You can delete the broken view and re-create it on target site
2. You can disable view migration of a particular type of list. In this case MM will not migrate the list views. Only default list views will be created on target site.
To disable the view migration:

1. Open the "Quest Software\Migration Manager for SharePoint\MM4SP.Paging.CmdProcessor.xml" file
2. There is the following query in the "get_views_of_list":

SELECT *,page.LeafName as ViewUrl FROM [{0}].[dbo].WebParts wp
JOIN [{0}].[dbo].Docs page on page.Id = wp.tp_PageUrlID
JOIN [{0}].[dbo].Lists lists on wp.tp_ListID = lists.tp_ID
WHERE wp.tp_ListId = '{1}' and (tp_DisplayName is not null) and tp_DisplayName <> '' and wp.tp_WebPartTypeId = '7FBF9A80-8AE1-FA7E-9C51-30A786D33155' and (wp.tp_View is not null) and (lists.tp_ServerTemplate not in (106, 102))

You could add list types in addition to 102 and 106 to exclude their views.
There is a list of SharePoint list templates: http://sharepointkb.wordpress.com/2008/08/26/sharepoint-list-template-ids-registrationids-list-template-type-ids/

3. Once you added the required types, save the file and restart Source service.

If you have two agent deployment the changes should be done on both servers. 

2003-2007: User lost ability to add/remove user permissions.

Security in SharePoint 2007/2010 is very different from SharePoint 2003. That may cause a lack of permissions on target SharePoint after migration.
How 2003 security works:
You can create a new group with a custom permission set which allows users of the group to manage the site permissions:

Then you add a user to the group:

In SharePoint 2003 the USER5 user can add/remove users do the group.


How 2007/2010 security works:

The new version of SharePoint works differently.
For each group, an Owner should be specified. Also there is Group Settings where you could specify who can edit membership of the group:

So, that means even if you grant Full Control to a particular user on SP 2007/2010 that does not mean he will be able to add/remove users from site groups or change the group settings.

Who can edit permissions in SharePoint 2007-2010: 

1. The Group Owner of a SharePoint group has permission to add / remove users from a group.

2. The Site Collection Administrator has permission to add / remove users from a group.

3. Only one person (or group) can be assigned as the Group Owner.

How Migration Manager handles this.

Migration Manager creates corresponding groups on target site and sets the "{Site Title} Administrator" group as owner.
So, after the migration the users who were in the "My Custom Group" with the custom permission set won't be able to add/remove permissions on target site.
As a workaround, add users to the {Site Title}Administrator group or create a separate group with all the required users included and set it as Owner for groups.
You should keep in mind that adding a user to the Administrators group may add some extra permissions for the user. 

03-07/10 and 07-10: Links are not processed during migration.

Migration Manager does not process links during migration. So, you need to change URLs manually when migration completes.



How it works:
Links are stored in database as a relative URL. If during migration the URL hierarchy is changed the link is broken.
If only the host part of the URL is changed, the URL will work, but it's description stay the same as it was on source site.

For example:
 
Source site has a list with the "Hyperlink or Picture" field type. And there is the following item:

When you perform migration of the http://ksps:81 site to a new target site collection with the http://kmoss/sites/OldRoot URL, the list has the following list item:

 
 When a user tries to open the URL he sees error message, because the document has the http://kmoss/sites/OldRoot/Shared Documents/How it works.doc URL now, but the /sites/OldRoot part is not in the link.

If you migrate the http://ksps:81 site as a new root site collection (http://kmoss) (i.e. web application name is changed only), the link will work. In this case the link description stays original.

03-07/10: Unable to update the information in the Microsoft Office document

Issue:
The following error might occur for a document during 2003-2007 migration:
Unable to update the information in the Microsoft Office document *.*

How to fix:
The error occurs for documents that were created with a third-part tool. There is the following article where the error discussed.

The solution is:  

Open the document with the corresponding Microsoft Office application and save it back to the document library. This should help to migrate the document without issues.

Note: If the versioning is enabled for the document library you need do delete all previous versions of the document.

It is not MMSP issue.
If you download the file from source and then upload it to target manually and try to modify it's properties you receive the same error message:

 

SharePoint 2003-2010 migration requires direct permissions for target config db.

When you add a user into the Farm Administrators group in SharePoint 2010 it does not receive direct access to configuration database (as it was in SharePoint 2007).

To perform 2003-2010 migration, MM uses SharePoint Object Model which is working in a context of MMSP service account. 

That changes list of required permissions for 2003-2010 migration. In addition db_owner for target Configuration database is required or you could add the user to the SharePoint_Shell_Access role on target SQL server.
The following PowerShell command adds a user to the role:
Add-SPShellAdmin –username <your username>  

What does the "0x80040E14" error mean

During a migration the 0x80040E14 error may occur. The error occurs when it is unable to complete an action on SQL server. You nay see either of the following errors:

' Unable to complete this operation.  Please contact your administrator.’

'Exception from HRESULT: 0x80040E14’

How to fix:

If you see one of the following messages in Issue report or log files, you need to check the following:

1.     Target SQL server data drive is not full

2.     .mdf and .ldf files of target content database haven't reached their full allocated size

3.     Target content database files are set to increase when full.

Note: There can be another reason for the “0x80040E14” error. Refer to the following Microsoft article for more detailed information: http://support.microsoft.com/kb/841216

Why does MMSP need the prescan utility to be run?

First of all, I would like to notice that Prescan is Microsoft tool. It's required to run the tool before upgrading SharePoint 2003 environment.

There are posts explaining what prescan utility actually does: Don't be afraid of Prescan  and Your Friend Prescan.exe - How to Get it & What it Does

Among the other things prescan fills tp_fields column in the lists table to persist the list schema. It parses and saves List definitions with the associated Lists. SharePoint Portal Server 2003 Service Pack 2 already incorporates this feature whenever a list is modified; however, this process should be completed for all Lists, so prescan calls the SharePoint Portal Server 2003 Service Pack 2 method to persist that data.

The tp_field column contains list schema. So, if the prescan hasn’t been run, the column is left empty and MMSP cannot read the list schema.

In this case you see the following error message in issue report: 'Need to use 'prescan' tool! 

03-07/03-10: How to migrate Survey with all responses

Migration Manager preserves settings for the Survey lists. The “Allowed multiple responses” option which may cause issues with migration of survey responses. If some responses have been made by users that do not exist in AD anymore MM replaces the user account to the MM target service account. In this case all the further responses cannot be created and you see the “You are not allowed to respond again to this survey” error.
MM has a configurable option for Survey list migration.
User can define how to migrate the "Allowed multiple responses" option. 

To adjust the option:

1. Open the "Quest Software\Migration Manager for SharePoint\SpringConfigs\Migrators.xml" file and locate the following line:
   <property name="AllowMultiResponsesForSurvey" value="Default" />
2.  Set required value for this property.
   The possible values are:
   AlwaysOn - the "Allowed multiple responses" option always set to Yes on the target site (for all migration jobs)
   AlwaysOff - the "Allowed multiple responses" option always set to No on the target site (for all migration jobs)
   Default - the "Allowed multiple responses" option set as it was in the source site.
   To migrate all responses you should set the option to AlwaysOn.
3. Re-migrate the required surveys (i.e. delete the target survey and create a new job) or you re-migrate the whole site.

SharePoint 2003-2007 migration is not working.

There was the following question at Quest Community:

We are using SharePoint Migration Manager 2.1.1.1111 and trying to migrate SP 2003 to SP 2007.  Performed three simple 1 site migration, none of them worked, they just keep running without single content getting migrated.  Remaining Time shows as 30 mins however even after 2 hours nothing is happening.  No errors reported or no errors in Event viewer.

So, the current post is about troubleshooting 2003-2007/2010 migration and how to find out what is going on with a migration job.

Firstly, open the job’s Details page and look at the Objects migrated/total counter. The counter displays how many objects are extracted from source and how many are uploaded to target. 

The following states are possible:

• The counter is 0/1 - none of source objects are extracted and there is an issue with Source service.
• The counter is 0/N (where N > 1) – source objects are extracted but none of them are uploaded to target so, there is an issue with Target service or connection between source and target.
• The counter is M/N (where N >1 and M > 0) – the objects are extracted from source and uploaded to target. But if you don't see any objects uploaded to target, that means there is an issue with target objects creation and you have errors in the Issue report for the job.

The Advanced tab on the Details page contains information about Source and Target agents that processes the current job. Make sure the agents are correct. 

If it is possible, use one agent deployment. The previous post explains why and how you should do that. 

If it is two agents deployment, make sure you have the same version of MMSP installed on the source and target servers.
If the agents are assigned correctly, continue investigation. Based on the counter state, you can determine where to find an issue.

If you have issues with Source service (i.e. counter is 0/1):

1. Check if the Quest.MM4SP.SourceService service is running.
   You can use the Agents report to determine a state of MMSP agents processing the migration job.
   Or check the service from the Services snap-in. (For two agent installation, check the service on the source server.)
2. If the service is not started, try to start SourceService manually.
   If it is unable to start, make sure that Message Queuing service is installed and running and MMSP service account has access to the Repository database.
   If it starts but then fails, check log files for the error.
3. The main service log for the Source service is written into the “{MMSP install folder}\Logs\2003\SourceService.log” file. (For two agent installation, log file is located on the source server)
   Errors in the log file are written with the ERROR word. For example:

   2010-11-29 06:03:29,113 [7] ERROR Default [3.1.0.1341] - Error on init job: The 'FirewallTest' job stop by 'System.Data.SqlClient.SqlException: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)

   The error above means, there is an error with connection to the source SQL server. You could check if MMSP account is able to connect to SQL using ODBC connection.
   
   If you don’t know how to understand an error message in the main service log, let me know about it at Quest community

 If you have issues with Target service (i.e. counter is 0/N.):

1. Check if the Quest.MM4SP.TargetService service is running.
   You can use the Agents report to determine a state of MMSP agents processing the migration job.
   Or check the service from the Services snap-in. (For two agent installation, check the service on the target server.)
2. Check target service for any error messages from the service (find ERROR in logs).
   The main service log is written to the “{MMSP install folder}\Logs\2003\TargetService.log” folder and log file for a job is written to the “{MMSP install folder}\Logs\2003\{JobName}\ TargetService.log” folder.
3. If there is no error in the main log and the subfolder with the job name is not created, then there is an issue in communication between source and target. 
4. It may only occur if you have two agents installation (if you have the behavior with one agent installation, let me know).
   As written above, source and target agents communicate by use of MSMQ. An outgoing queue is created on source server as follows:
    And messages are sent to the target Private queue: 
   
   So, when there are no problems with communication, messages are successfully transferred. They stuck in source queue when there is a communication problem. You should resolve the communication problem or use one agent deployment.

When you have issues with target objects uploading: 

Investigate the “{MMSP install folder}\Logs\2003\{JobName}\TargetService.log” file. There can be number of files or they can be already archived to the “Old logs” folder, so find the first one.
The first log file should contain information about the first site (site collection) creation:
 

Or list creation if it is a list migration job.

You can see Access Denied error for example. So, you should check MMSP service account permissions for the Target farm.

Cheers,

Kate

PS. Let me know if you still have any question about troubleshooting 2003-2007/2010 migration 

Use one agent deployment for 2003 – 2007/2010 migration where is possible

We do not recommend using of two agents deployment to perform 2003-2007/2010 migration. When you use two agents deployment source and target MSMQs are used to transfer data between agents. There can be connection issues between the queues that slow down a migration speed or even break the migration process. So, use two agents only if it is not possible to use one agent.

To avoid two agents usage you can Configure stored credentials for accessing a source farm and Install QMC locally to add a source farm.

The scenario with one agent deployment is the following:

1. Install MMSP to the target SharePoint server. During installation specify a MMSP service account.
2. Make sure the MMSP service account has all the required permissions for Source and Target Farms. Add missing permissions if needed.
   

   Note: If you cannot grant Permissions for the Source farm to the MMSP service account, use Stored Credentials.
   

3. Add a source SharePoint 2003 farm into MMSP.Note: If you cannot add the source farm, you may install QMC to source farm to perform discovery. Refer to Online help

Configuring stored credentials
“Stored User Names and Passwords” option allows a particular user to logon automatically to the specified server using stored credentials.
To configure stored credentials:

1.  Logon to MMSP host under the MMSP service account.
2. On Windows 2003: Open Control Panel | Stored User Name and Password 
   On Windows 2008: Open Control Panel | User Accounts | Manage your network passwords
3.  Add user account and password for the source server.

   Note: If an alias is used for server, the original name should also be added.

4.  Restart the ServiceMonitor and CustomPageMigrator services.

The required permissions for MMSP service account:
1. The db_owner role for Repository database
2. The Log On As Service right on the MMSP host (by default it is granted automatically, when a service starts under the account)
Permissions for Target Farm
3. Local Administrator on Target server
4. Farm Administrator on Target SharePoint farm
5. The db_owner role for target Content and Configuration databases
6. Full Control granted via the Policy for Web application (for all site collections within the web application) OR the Site Collection Administrator permissions in the Target site collections (per site collection)  
Permissions for Source Farm
7. Local Administrator on Source Server
8. db_datareader for Source content and configuration databases