2007/2010 reorganization: After migration you see two lists with the same name in the Site Content

After migration of a list using SharePoint 2007 /2010 reorganization scenario you could see duplicated lists on the target site:

Actually both links open the same list.

As a workaround:

1. Open the list settings.
2. Set a non-default view as a default.The duplicated link is gone.
3. Switch back to the desired default view.

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

  

Gradual Site Delete: Gradual deletion of site collection in SharePoint 2010

When you delete a Site Collection in SharePoint 2010 from Central Administration or from the site collection settings it is being deleted gradually.
The gradual deletion is performed by the Timer Job Definition called Gradual Site Delete.
In few words:
 The site reference is deleted from SiteMap and Sites tables of configuration and content databases and added into the SiteDeletion table. The Site collection is unavailable for users. But sub-sites still exist in the Webs table of content database. This behavior can cause some issues for third-party tools which read these tables.
 The Gradual Site Delete Timer Job definition is scheduled to be running one time a day. It can be started manually from Central Administration -> Monitoring -> Review job definitions -> Gradual Site Delete.
Here you can edit the timer job or run the job immediately

Refer the following article for more detailed information about the Gradual Site Delete timer job definition.

To delete the site collection completely use the following PowerShell command:

Remove-SPSite -Identity "<URL>"