SharePoint Variations – The complete Guide – Part 14 – Troubleshooting

This part will provide troubleshooting steps for the following common type of problems:

• Propagation Problems
  • Variation Hierarchy is not created
  • Automatic Page/Site propagation does not work
  • Manual Page/Site propagation does not work
• Variation Label menu does not show correct results
• Variation landing page redirection does not work correct

   

Troubleshoot propagation problems

Propagation problems can be caused either in the application pool or in the SharePoint timer services. So the first troubleshooting step has to be to determine if the problem occurs in the application pool or in the timer service.

The following sequence of troubleshooting steps should be applied:

General steps

1. Check the Variation Log (see part 13 for details)
2. Check the ULS log for problems (see part 13 for the required categories)
3. Use STSADM -o variationsfixuptool -scan to analyze variation inconsistencies which might be related to the problem

    

Isolate if worker process or timerjob

If the Variation Log indicates that the timer job is not executed:

1. Check if the relevant timerjob for the web application is enabled and correctly scheduled
   

   Note: You can use powershell to dump a filtered timerjob list for your web application, which contains the relevant information. E.g. the following command dumps the information about the variation timerjobs for the web application on port 1007: PS> (get-spwebapplication http://servername).JobDefinitions | where {$_.DisplayName -match “variation”} | select DisplayName, IsDisabled, LastRunTime, Schedule | fl

2. Check if the relevant timerjob has been executed successfully in the relevant timeframe
   

   Note: You can use powershell to dump a filtered timerjob history for your web application. E.g. the following command dumps the history for all variation timerjobs for the web application on port 1007: PS> (get-spwebapplication http://servername).JobHistoryEntries | where {$_.JobDefinitionTitle -match “variation”} The following command dumps the history for the create hierarchies timer job: PS> (get-spwebapplication http://servername).JobHistoryEntries | where {$_.JobDefinitionTitle -match “Variations Create Hierarchies Job Definition”}

3. Check if a scheduled work item for the specific type and is created in the ScheduledWorkItems table when the relevant action is performed. See the table at the end of Part 4 to identify the Work item to look for.
4. Check if the scheduled work item is removed from the Scheduled Work Items table after the timerjob has been started and ended.
   

   Warning: Direct read access to a production SharePoint database can affect the performance of the site. It is recommended to open a support case with Microsoft to do this type of troubleshooting on a production system.

    

Troubleshoot propagation problems in variation timerjobs

If problems occur within a timerjob you usually have to rely on the information provided by the Variation Log or ULS logs to isolate the problem. If this information is not sufficient to isolate the issue you should consider to open a support call with Microsoft as advanced debugging skills will be required to further isolate the problem.

Troubleshooting propagation problems in the worker process

The following steps are relevant for spawn/hierarchy creation problems where the workitem is not added to the ScheduledWorkItems table in the content database.

In this case, the problem is caused inside the IIS worker process.

If an event handler should initiate the failing operation verify if the event handler is properly bound to the relevant Pages library or site.

The following event handlers need to be registered on the Pages library to ensure that the variation system works correct:

Type : ItemDeleting
Class : Microsoft.SharePoint.Publishing.PagesListCPVEventReceiver

Type : ItemAdded
Class : Microsoft.SharePoint.Publishing.PagesListCPVEventReceiver 
 
Type : ItemUpdated
Class : Microsoft.SharePoint.Publishing.PagesListCPVEventReceiver 
 
Type : ItemDeleted
Class : Microsoft.SharePoint.Publishing.PagesListCPVEventReceiver 
 
Type : ItemCheckedIn
Class : Microsoft.SharePoint.Publishing.PagesListCPVEventReceiver

The following event handlers need to be registered on the site to ensure that the variation system works correct:

Type : WebDeleting
Class : Microsoft.SharePoint.Publishing.CPVAreaEventReceiver 
 
Type : WebMoving
Class : Microsoft.SharePoint.Publishing.CPVAreaEventReceiver 
 
Type : WebMoved
Class : Microsoft.SharePoint.Publishing.CPVAreaEventReceiver

Be careful if you find that custom event receivers are listening to the same events as the logic in the custom event receivers might badly interact with the event receivers registered by the variation system.

For the manual spawn/hierarchy creation actions, you usually have to rely on the information provided by the Variation Log or ULS logs to isolate the problem. If this information is not sufficient to isolate the issue you should consider to open a support call with Microsoft as advanced debugging skills will be required to further isolate the problem.

Troubleshoot Variation Label menu related problems

Here we need to differentiate between two different problems: 

The variation labels menu never shows up

This is a common scenario if there is a problem in the VariationsLabelMenu.ascx, which causes the dynamic compilation to fail. E.g., incorrect assembly references can cause this problem. Unfortunately, SharePoint consumes such compile time problems and just silently hides the affected user control rather than showing the error.

The “easiest” way I found to troubleshoot these issues is to attach a debugger (e.g. Visual Studio) to the worker process and monitor the status messages while loading a page with the variation labels menu. Usually problems are reported as System.Web.HttpParseExceptions.

You might see messages like these:

(9ac.15d4): CLR exception – code e0434f4d (first chance)
CLR exception type: System.Web.HttpParseException
“Unknown server tag ‘CMS:VariationsLabelEcbMenuX’.”
 
(9ac.1268): CLR exception – code e0434f4d (first chance)
CLR exception type: System.Web.HttpParseException
“Could not load file or assembly ‘Microsoft.SharePoint.Publishing, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c’ or one of its dependencies. The system cannot find the file specified.”

You will have to analyze and correct the parser errors reported with the exception to fix the problem.

The variation labels menu does not show links to all existing peers

This usually indicates a problem in the relationship between the peer pages. Either site/page properties are not correctly set or entries in the relationships list are missing or incorrect.

The best way to isolate such problems is to use STSADM -o variationsfixuptool -scan to analyze the problems and STSADM -o variationsfixuptool -fix to solve the problem.

Troubleshoot Variation landing page related problems

The first important step is to check from which location the VariationRoot.aspx receives the logic to perform the routing.

As outlined in Part 10 it is possible to move the logic out of the VariationRootLanding.ascx into other controls or even into libraries in the SharePoint content database.

Verify the welcome page settings of the variation root site and ensure that it points to the VariationRoot.aspx page. Verify if the VariationRoot.aspx page uses the VariationRootPageLayout.aspx page. If customization has been applied to the variation root logic, use SharePoint designer or Powershell to inspect the content of the VariationRootPageLayout.aspx

Possible Reasons for routing problems with the variation landing page

In general, there are five different reasons, which can cause routing problems with the Variation landing page:

Problem in the variation label definition

Analyze using a custom view if the hierarchy for the desired target label is created and that the correct language, locale and top site is configured in the list item.

Problem with the relationship between variation peers

Either site/page properties are not correctly set or entries in the relationships list are missing or incorrect.

The best way to isolate such problems is to use STSADM -o variationsfixuptool -scan to analyze the problems and STSADM -o variationsfixuptool -fix to solve the problem.

Permission problems

If the logic in the VariationsRootLanding.ascx is using security trimmed API (e.g. Variations.Current.UserAccessibleLabels), it is possible the routine is influenced by different permissions of the users and whether they arrive on the page anonymous or authenticated.

Test if the users can navigate to the variation top site of the desired label using the direct URL.

Browser configuration problems

The default routing logic uses the language settings configured in the browser to determine the target label. If the user has changed these settings, the routing might not be as expected. A network monitor trace reveals the language settings configured by the user and can help to isolate such problems.

Problems in the logic of the landing page

Often the default routing logic does not fulfill the customer’s requirement and needs to be adjusted. Alternatively, customers have already implemented a custom logic, which does not work as expected.