none
Project Server 2013 - 'Prepare Project Web App Permission Synchronization For Projects' - Site not found RRS feed

  • Question

  • Hi,

    After applying September '14 CU to Project Server 2013, we have detected an issue when 'Prepare Project Web App Permission Synchronization For Projects' fires with existing project sites (those created before the update was applied).

    What is happening, based on log files, is that Project Server tries to open the project site using the url http://server/myprojectsite instead of http://server/pwa/myprojectsite (note that /pwa is missing). It seems that Microsoft changed the way the project site URL is saved/retrieved in order to implement a new feature.

    In the Microsoft Project Support Blog a user named 'Hans' report that Microsoft is aware of this issue but no one knows when will be fixed.

    The next CU's (October and November) do not solve the problem. I wonder if anybody knows a way to mitigate the problem through a temporary workaround.

    Be aware this behaviour if you are planning to update your Project Server 2013...

    Kind regards,
    Tuesday, December 9, 2014 3:28 PM

All replies

  • I'm seeing this same issue on an environment with the October 14 CU.  I'm glad I found your post after researching for several hours.  I can't reproduce with new projects/sites.  It occurs for most but not all existing projects. The ULS Log Shows:

    Area     : SharePoint Foundation
    Category : General
    Level    : Medium
    EventID  : ai1wu
    Message  : System.IO.FileNotFoundException:
               <nativehr>0x80070002</nativehr><nativestack></nativestack>There is
               no Web named "/PROJECT SITE NAME"., StackTrace:    at
               Microsoft.SharePoint.SPWeb.InitWebPublic()     at
               Microsoft.SharePoint.SPWeb.get_AppInstanceId()     at
               Microsoft.SharePoint.SPWeb.get_Url()     at Microsoft.Office.Project
               .Server.BusinessLayer.SharePointSecurityHelper.TruncateGroupByName(S
               PWeb web, String groupName)     at Microsoft.Office.Project.Server.B
               usinessLayer.SharePointSecurityHelper.TruncateSPGroupByPermissionUID
               (SPWeb web, Guid feaActUid, String projName)     at Microsoft.Office
               .Project.Server.BusinessLayer.PSPermissionSynchronizer.TruncateSyncS
               ensitiveGroupsForProject(IEnumerable`1 permissions, Guid projUid,
               String projSiteName, Guid projSiteId)     at
               Microsoft.Office.Project.Se...

    Tuesday, December 9, 2014 11:33 PM
  • Can you check the following?

    1. Go to your PROJECTWEBAPP DB and run the below query on the PUB.MSP_PROJECTS table

    select PROJ_NAME, WPROJ_STS_SUBWEB_NAME,WSTS_SERVER_UID,WPROJ_ISSUE_LIST_NAME,WPROJ_RISK_LIST_NAME from PUB.MSP_PROJECTS where WPROJ_STS_SUBWEB_NAME is not null

    2. Compare the WSTS_SERVER_UID value with SITEID value in the Webs table in the Content DB hosting the PWA and Project site collections

    SELECT FULLURL, SITEID FROM WEBS

    Check if you observe that the SITEID in Webs table and the WSTS_SERVER_UID in the PUB.MSP_PROJECTS table are different which ideally should be same. 

    4. Also check if the WSTS_SERVER_UID is pointing to the same SITEID under which the workspaces needs to be created in PUB.MSP_WEB_ADMIN Table

    select WADMIN_CURRENT_STS_SERVER_UID from PUB.MSP_WEB_ADMIN

    Please let us know about your findings.



    Cheers! Happy troubleshooting !!! Dinesh S. Rai - MSFT Enterprise Project Management Please click Mark As Answer; if a post solves your problem or Vote As Helpful if a post has been useful to you. This can be beneficial to other community members reading the thread.

    Wednesday, December 10, 2014 8:58 PM
    Moderator
  • Hi Rcardo,

    i can confirm that the issue is been caused after applying September CU, and the cause of an issue is project site located under site collection other than root site collection. i.e. project site under PWA site collection will cause this queue error. 

    And temporary resolution, until an official fix releases in Jan/Feb, is to change the configuration from  for project sites to be created under root site collection.

    this configuration option is located here: central admin -> PWA Settings -> Project Site Provisioning Settings

    for current sites, you may need to delete existing sites and re-create them so that they can be created under root site collection using new configuration. (note that delete/re-creating exisitng site would be a tedious job and only do if possible in your current environment. in this case, wait for an official fix to be available, alternatively i would advise to log a ticket with MS so to help you provide an urgent fix)

    hope this helps.


    Khurram Jamshed - MBA, PMP, MCTS, MCITP ( Blog, Twitter, Linkedin )
    If you found this post helpful, please “Vote as Helpful”. If it answered your question, please “Mark as Answer”.


    • Edited by Khurram Jamshed Thursday, December 11, 2014 1:35 AM more details
    Thursday, December 11, 2014 1:14 AM
  • Hi Rcardo,

    I would not be able to confirm whether deleting the sites and recreating them would be a good option as this might be tedious

    I would request you to wait for me to check this internally and get back to you.

    Meanwhile, I would request you to share the details of the queries that I shared earlier.


    Cheers! Happy troubleshooting !!! Dinesh S. Rai - MSFT Enterprise Project Management Please click Mark As Answer; if a post solves your problem or Vote As Helpful if a post has been useful to you. This can be beneficial to other community members reading the thread.

    Thursday, December 11, 2014 1:27 AM
    Moderator
  • Hi,

    I can confirm that this solution will solve this issue for any new project site. We have applied this to our customer's environments and it worked, also our support colleagues are in touch with MS and shared valuable feedback related to issue.

    However, as i said earlier, its a temporary solution and any decision about existing project sites must be subject to environment and several other parameters and solely solution seekers call. 

    Hope this clarifies, and does help to extent.



    Khurram Jamshed - MBA, PMP, MCTS, MCITP ( Blog, Twitter, Linkedin )
    If you found this post helpful, please “Vote as Helpful”. If it answered your question, please “Mark as Answer”.

    Thursday, December 11, 2014 5:10 AM
  • Hi Dinesh,

    Here you have the results of the queries:

    PUB.MSP_PROJECTS
      WPROJ_STS_SUBWEB_NAME = PWA/Demo ISS 001
      WSTS_SERVER_UID = 9ED32CAA-E7EA-4D4B-BDF3-CB3DEC71868A
    WEBS
      FULLURL = PWA/Demo ISS 001
      SITEID = E536EB07-25C7-41DF-A019-25155DD5D6B9
    PUB.MSP_WEB_ADMIN
      WADMIN_CURRENT_STS_SERVER_UID = E536EB07-25C7-41DF-A019-25155DD5D6B9

    As you can see, the WSTS_SERVER_UID differs from the SITEID and WADMIN_CURRENT_STS_SERVER_UID.


    I appreciate the proposed solutions but we can't re create the sites nor change the url from "/PWA" to "/". So, as this issue affects only to site permissions synchronization, we will wait until February CU where there will be a fix for this (as Brian Smith said on his Project Server Support blog).
    Monday, December 15, 2014 10:40 AM
  • Hello,

    Unfortunetaly the February CU is not bringing any solutions here. The problem still exists. Ok, for new projects it works if you change the default root location of each site to the PWA root site collection, and not a sub site. However, all existing projects are a problem.

    Too bad that it still isn't fixed yet, and moving sites around is not an option here on our current environment. Therefore we have a bit too much of projects running in the system.

    Wednesday, February 18, 2015 12:03 AM
  • It looks like due to some issue your site id for another site has got updated with the PWA site in the MSP_PROJECTS.

    A simple update of the WSTS_SERVER_UID in MSP_Projects table with the one in SITEID observed in the Webs table should fix the issue.

    However, I would recommend that you raise a support case with Microsoft and get the issue looked into.


    Cheers! Happy troubleshooting !!! Dinesh S. Rai - MSFT Enterprise Project Management Please click Mark As Answer; if a post solves your problem or Vote As Helpful if a post has been useful to you. This can be beneficial to other community members reading the thread.

    Wednesday, February 18, 2015 12:24 AM
    Moderator
  • Hello,

    After doing some further tests it looks like we have a work around, but no final fix yet. This is what I did to make it work for existing sites :

    • Replace WSTS_SERVER_UID in the [PUB].MSP_Projects table with the SITEID you can find in the Webs table
    • Republish your project plan, or synchronize permissions from the PWA settings, and that should work.
    • Check the queue jobs for monitoring of the sync process

    However, for creating new sites (or new projects), there is still an issue. Make the following choice :

    • Agree that the new site will reside in the root site collection, so directly under /PWA, and it will work
    • If you do not agree for the new site to be hosted directly under /PWA (with us everything is stored under /PWA/Sites), the follow this procedure:
    1. Don't create the site from MS Project, but create it from the PWA settings > Connected SharePoint Sites > Create site
    2. Return to the database, and update the WSTS_SERVER_UID again. Only one record will be updated for your new site.
    3. Reopen the plan, and republish, or just synchronize the permissions from PWA settings

    Project Server is taking the root site collection of the web application instead of the root site collection of the PWA site. That should be fixed in a new update for Project Server. Hopefully soon.

    I hope in the meantime that this might help other people as well.

    Wednesday, February 18, 2015 12:52 AM
  • Hey all,

    I also had this issue after going from SP1/April CU to December CUs. Same queue and ULS errors. I opened a case and my fix was the same as above - replacing the WSTS_SERVER_UID for all affected projects (in my case, it was like 600+). We also found that using bulk site update feature in PWA actually could replace the WSTS_SERVER_UID with the wrong value - instead of using the PWA site ID it would use the root site collection site ID and of course that busts things. So the simplest solution was to just update all of them in SQL.

    Unlike the above I'm pretty sure all of my new projects are grabbing the correct UID though. I wish I knew why a ton of the older project sites has the wrong UID and why new ones don't.


    • Edited by aaronzott Thursday, February 19, 2015 7:39 PM
    Thursday, February 19, 2015 7:37 PM
  • Hi all,

    You can use this script by changing the names of the databases, but the rest is easy to go. This will set the GUID's correctly as workaround:

    DECLARE @CurrentRoot uniqueidentifier

    DECLARE @TopRoot uniqueidentifier

    DECLARE @PWARoot uniqueidentifier

    USE Intranet_Content

    SELECT @TopRoot = SITEID FROM WEBS WHERE FULLURL = ''

    SELECT @PWARoot = SITEID FROM WEBS WHERE FULLURL = 'PWA'

    PRINT 'Getting the GUIDs of site collections in the SharePoint database'

    PRINT CONCAT('Top root site collection : ', @TopRoot)

    PRINT CONCAT('PWA root site collection : ', @PWARoot)

    PRINT ''

    PRINT 'Now replace the parent site collections...'

    USE ProjectServer

    UPDATE PUB.MSP_PROJECTS

    SET WSTS_SERVER_UID = @PWARoot

    WHERE WSTS_SERVER_UID = @TopRoot

    UPDATE PUB.MSP_WEB_ADMIN

    SET WADMIN_CURRENT_STS_SERVER_UID = @PWARoot

    WHERE WADMIN_CURRENT_STS_SERVER_UID = @TopRoot

    PRINT ''

    PRINT '... Done... '

    PRINT 'You can now republish your project plans and resync security permissions'

    If you think this is a good work around, then mark this as solution to close this question on the forum. Thanks.

    • Proposed as answer by Guy Anthuenis Tuesday, March 10, 2015 10:58 AM
    Tuesday, February 24, 2015 9:45 AM