Blog Post

Project Support Blog
2 MIN READ

Enterprise Global not loading after migration to Project Server 2019

Brian-Smith's avatar
Brian-Smith
Former Employee
Dec 02, 2020

Great to see so many people upgrading to the latest - but one issue we have heard is that the Enterprise Global template (EGT) cannot be opened in Project Server 2019 after the migration.  The problem appears to be that the Project UID for the EGT is changed - then it cannot be found under its new GUID.  Often this is seen to be happening when migrations start at an earlier release - like 2010 or 2013, but from the reports we have the problem only occurs at the final stage - and the EGT opened just fine in 2016.

The solution requires a bit of work in SQL Server, so if you are not comfortable working in SQL then either work with the database administrator for Project Server - or of course open a support ticket.  Always best too - if you either take a SQL backup before making any changes - or make the changes just after your normal backups occur - in case you need to revert.

To detect the issue you would first run a query like this one - substituting your content database name for dbname:

 

use dbname

 

select PROJ_UID, PROJ_NAME from pjpub.msp_projects where proj_name like '%eglobal%'

 

This may return a result similar to the following:

 

PROJ_UID                                                                           PROJ_NAME

75CDD7DB-1B68-4B70-A8D6-2FE52DA83ACD                 EGlobal

87537CC3-5AF6-421E-A42F-A27CB2A2EFA2                    EGlobal-20150320041555

 

Here, the EGlobal has the proper association to PROJ_UID = 75CDD7DB-1B68-4B70-A8D6-2FE52DA83ACD (this is the static GUID) and an older version of the EGlobal is shown here (the second row).

 

If the EGlobal has a different UID, then it’ll need to be updated to use the proper one.

 

For example, suppose the returned result looks like this:

 

PROJ_UID                                                                           PROJ_NAME

DF59652B-073D-4FB1-A16E-1F7233C439AE                    EGlobal

87537CC3-5AF6-421E-A42F-A27CB2A2EFA2                    EGlobal-20150320041555

 

You’d need to run an update query that looks similar to this:

 

use dbname

 

Update pjpub.msp_projects

Set PROJ_UID = '75CDD7DB-1B68-4B70-A8D6-2FE52DA83ACD'

where PROJ_UID = 'DF59652B-073D-4FB1-A16E-1F7233C439AE'

 

Use the GUID (in this example starting 'DF59,,,' that is the incorrect GUID returned from the previous select statement.

If this doesn't solve the problem - or if the GUID looks to be ok, then you have a different problem and would need to open a support ticket.

Thanks to Adrian and Ajith for help with putting these details together - and Dale and Paul for alerting us to the issue.

My suspicion is that this is a 2019 client issue - as just changing the GUID to try and repro the issue in 2016 does not give any problems - the EGT opens just fine whatever GUID it has...

Published Dec 02, 2020
Version 1.0

7 Comments

  • ricardoalves's avatar
    ricardoalves
    Copper Contributor

    Good afternoon Brian
    I read your article on the problem of Enterprise Global.
    I have a similar situation with a client. I followed the steps you indicated and successfully changed the EGlobal Guid via Database.
    However, after the first opening of EGlobal in MS Project that occurs successfully, later it returns to error. This is because Guid has changed again in the Database.

    What do you suggest in this situation? Unfortunately Guid is always changing in the database.

  • Thanks for sharing the steps Lee Mather - looks like the best way to recover.  It does appear that the change of GUID is something that could happen in earlier releases but isn't accommodated in the current release.  My apologies to all affected by this issue.

    Best regards,

    Brian

  • Lee Mather's avatar
    Lee Mather
    Copper Contributor

    Hi Flo,

     

    Thanks for sharing your details too. I would imagine your Ent Global UID = 5850E0F8-CDF2-4092-9CC3-577102564A24 as this is the default in Project Server 2007. 

     

    To resolve the issue we had to complete the following:

    1. Connect to Project Server 2016 (if you still have the upgrade environment) with Project Professional and save a blank project locally with all enterprise global items
      • Keep that MPP file safe
    2. Backup the Project Server 2019 content database
    3. Change the Ent Global UID in the Project Server 2019 database to 75CDD7DB-1B68-4B70-A8D6-2FE52DA83ACD using SQL Management Studio
      • Update pjpub.msp_projects

        Set PROJ_UID = '75CDD7DB-1B68-4B70-A8D6-2FE52DA83ACD'

        where PROJ_UID = '5850E0F8-CDF2-4092-9CC3-577102564A24'

    4. Connect to Project Server 2019 with Project Professional and open the Ent Global. The Ent Global will not contain any of the configuration but you can now open it. Use the Organiser in Project Professional to copy the Ent Global config from the MPP file in step 1 into the Ent Global as it will be blank after updating the UID in the previous step
    5. Save the Ent Global in Project Server 2019

    I would suggest opening a support case with Microsoft 🙂

     

  • Hey,

    Flo here from TPG The Project Group in Germany.

    We also ran into this and our PS has this history:

    • ProjectServer 2007, later migrated to 2010
    • 2010 migrated to 2013
    • 2013 just migrated over 2016 to 2019 a few weeks ago

    No we can't open enterprise global:

    • The following job failed to complete
    • Job Type: load
    • Error ID: 1028(0x404)
    • Error: Project does not exist.

     

  • Lee Mather's avatar
    Lee Mather
    Copper Contributor

    Hi Brian, do you think either there could be a fix implemented for this or the docs.microsoft.com site can be updated with the required manual steps? This could save a few support calls 🙂 

     https://docs.microsoft.com/en-us/project/upgrading-to-project-server-2019

     

    Thank you

     

  • Thanks Lee - it also appears that earlier versions were happy to open the EGT whatever the GUID - but not so 2019, which needs the exact GUID.

  • Lee Mather's avatar
    Lee Mather
    Copper Contributor

    Hi Brian,

     

    Thank you for the sharing the post. I just thought I would share some findings that others may find useful.

     

    Looking a little further into the issue we're experiencing with an upgrade from Project Server 2010 to 2019 that started life as Project Server 2007, I can confirm that in Project Server 2007 the default Enterprise Global GUID is 5850E0F8-CDF2-4092-9CC3-577102564A24. I have just built a new Project Server 2007 environment to confirm the default Enterprise Global GUID.

     

    It would appear that in later releases of Project Server, the default and expected Enterprise Global GUID is 75CDD7DB-1B68-4B70-A8D6-2FE52DA83ACD as mentioned in the post. When upgrading to Project Server 2019 from Project Server 2007 you will find that the Enterprise Global can't be opened. By changing the GUID to 75CDD7DB-1B68-4B70-A8D6-2FE52DA83ACD, you will be left with a blank Enterprise Global.

     

    Thank you

    Lee