Part 1 - The BasicsPart 2 - User InterfacePart 3 - TriggersPart 4 - Timer JobsPart 5 - Configuration OverviewPart 6 - Configuration InternalsPart 7 - Variation Hierarchy CreationPart 8 - Creating Page VariantsPart 9 - Creating Site VariantsPart 10 - Restructuring the HierarchyPart 11 - Variations Fixup ToolPart 12 - CustomizationPart 13 - LoggingPart 14 - TroubleshootingPart 15 - "View Changes" ButtonPart 16 - Translation SupportPart 17 - MOSS 2007 vs. SP 2010Part 18 - FAQ
This part will provide troubleshooting steps for the following common type of 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:
If the Variation Log indicates that the timer job is not executed:
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
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"}
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.
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.
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.
Note: You can use the following powershell command to dump all event receivers registered on a specific Pages library.
PS> (get-spweb http://servername/en).Lists["Pages"].EventReceivers | select Type,Class | fl
The following event handlers need to be registered on the Pages library to ensure that the variation system works correct:
Type : ItemDeletingClass : Microsoft.SharePoint.Publishing.PagesListCPVEventReceiverType : 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
Note: You can use the following powershell command to dump all event receivers registered on a specific Site:
PS> (get-spweb http://servername/en).EventReceivers | select Type,Class | fl
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.
Here we need to differentiate between two different problems:
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.
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.
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
Note: You can use the following powershell command sequence to dump the binary content from the SPFile object of the VariationRootPageLayout.aspx page layout to the file system:
PS> $byteArr = ((get-spweb http://server).Lists["Master Page Gallery"].Items | where{$_.Name -match "VariationRootPageLayout.aspx" }).File.OpenBinary()
PS> [System.IO.File]::WriteAllBytes( "c:\VariationRootPageLayout.aspx", $byteArr)
In general, there are five different reasons, which can cause routing problems with the Variation landing page:
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.
Either site/page properties are not correctly set or entries in the relationships list are missing or incorrect.
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.
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.
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.