Thursday, December 19, 2013

Options to deal with Fab 40 ProjectTrackingWorkspace site migration to SharePoint and Project server 2013

If you are using Fab 40 practically ProjectTrackingWorkspace on SharePoint Project Server 2010, you might be already aware of the issues like custom Commands tab is missing when you open or try and add a new item, such as an issue or risk. You will also notice that the Links field is missing from the form, and in List Settings you will not see the Links column, which should be present and of type Project Link. We worked with Brian Smith from Microsoft project server team and identified the fix as he published in Microsoft blog.

Now after three years and we are upgrading to SharePoint and Project Server 2013, we try to upgrade the Fab 40 sites to 2013 by deploying the Fab 40 solution with 14 hive compatible mode as described in previous blog.  Now, we are experience the same issue again on Project Server 2013! Even worse, some application pages cannot be opened with the following error message.

Failed to find the XML file at location '15\Template\Features\PWSCTypes\feature.xml'

After digging into the issue, we confirmed that this is the same issue we were facing on SharePoint and Project Server 2010. The issue is ProjectTrackingWorkspace site definition solution deployed the following seven features that overwrite those from Project Server 2013 features. It’s interesting that the seven features from Project Server 2013 are with capital letters but the ones from Fab 40 ProjectTrackingWorkspace are lower letters as in the following screenshots. The top one is for Project Server 2013 feature folders and the bottom one is for Fab 40 ProjectTrackingWorkspace feature folders.



In addition, Fab 40 ProjectTrackingWorkspace solution will also overwrite the following resource files that will impact Project Server 2013 functions.



  • pws.de-de.resx
  • pws.es-es.resx
  • pws.fr-fr.resx
  • pws.he-il.resx
  • pws.it-it.resx
  • pws.ja-jp.resx
  • pws.ko-kr.resx
  • pws.pt-br.resx
  • pws.resx
  • pws.zh-cn.resx
  • pws.zh-tw.resx
This is all included in the Fab 40 ProjectTrackingWorkspace solution. Now we can discuss the options how to fix this issue on SharePoint and Project Server 2013. Here are the three options we have tried for your reference.



1. First and preferred option is to delete all Fab 40 sites or migrated them to support site templates like team site. You could use either server API or third party tool like Metalogix. This is recommended by Microsoft.

2. Second option is to create custom dummy ProjectTrackingWorkspace site definition without the seven features, resource files, or list any list definitions. Deploy this dummy definition to SharePoint and Project Server 2013. Migrate ProjectTrackingWorkspace site and then retract dummy solution after upgrade. 

This is a workaround that all ProjectTrackingWorkspace sites could be migrated and upgraded to 2013 version. These sites will continue working since the Project Server 2013 have the same features deployed. However, there are certain lists from ProjectTrackingWorkspace site definition will not functioning since the list definition has not been deployed to 2013. The long term is to migrate these ProjectTrackingWorkspace sites to support site template.

3. The third option is to deploy Fab 40 as compatible mode to 2013 as described in previous blog, retract Fab 40, and then fix the issue published by Brian Smith for SharePoint 2010. This is same process and we have a shorter way to fix the sisues as described below.


  • Retract the current ProjectTrackingWorkspace solution
    • Uninstall-SPUserSolution -Identity ProjectTrackingWorkspace.wsp -Confirm:$false
  • Delete the current ProjectTrackingWorkspace solution
    • Remove-SPSolution -Identity ProjectTrackingWorkspace.wsp -Confirm:$false
  • Run Project Server Web Front Server Installation pjsrvwfe.msi on each WFE to repair MPS
  • Reinstall all the Project site features for 2013
    • Install-SPFeature -path PWS -Force
    • Install-SPFeature -path PWSCommitments -Force
    • Install-SPFeature -path PWSCtypes -Force
    • Install-SPFeature -path PWSDocLibs -Force
    • Install-SPFeature -path PWSFields -Force
    • Install-SPFeature -path PWSIssues -Force
    • Install-SPFeature -path PWSRisks -Force
  • IISRESET on all WFEs

Although both option #2 and #3 could resolve the Fab 40 ProjectTrackingWorkspacesite migration to SharePoint and Project Server 2013, we believe the long term solution is to remove all Fab 40 sites or migrate the to supported site templates.

Friday, December 13, 2013

Quest webpart 2013 or Quick Apps for SharePoint 2013 issues


Quest webpart for SharePoint 2010 has been renamed as Quick Apps for SharePoint to support SharePoint 2013. You can unleash the full potential of SharePoint 2013 and 2010—without relying on expensive development resources for every customization and enhancement. If you are upgrading these webparts, you should read my previous blog tips to upgrade Quest webpart on SharePoint 2013. In this blog, we will list the major issues after the upgrade and hopefully there are some solutions or workarounds out there.




The first issue is Quest installation removes the "Session" module for all webapps as in the following screenshot. 

 

"Session" module is used for session configuration like session timeout for our extranet users. We have configured one hour timeout for external users for security reasons. I'm not sure whether we could configure Quest first and enable the session afterward. We would need some confirmation from Dell.

The second issue enable Quest for the large webapp from SharePoint central admin timed out as shown in the following screenshot.
 


It works for small webapp that contains less site collections. It seems like Quest activation for webapp will add entry to farm property bag. Since large webapp with large amount of site collections needs to insert large amount of property bag that will cause the timeout.

The third issue is related to issues #2 and we found many new property bag entries after activate the Quest on webapp as shown in the following screenshot.


It seems like the Quest is adding the site collection GUID into the farm property bag and there are many entries just entered as "q" without any GUID. This might not causing the timeout when activating Quest, but also might cause farm property bag maintainability issues. If you have any insight information on the reason behind, please let us know.

We are still testing the Quest Quick Apps for SharePoint 2013 at this point. We might found additional issues in the future.