Project Server Blog

This issue has recently affected more than one of my customers, so I thought after a few months working with Microsoft support it is definitely worth sharing;

Problem:

When attempting to disable BCM mode from Server Settings in a migrated Project Server 2010 environment, unchecking the BCM mode option leads to corruption in multiple project schedules when opened in MS Project 2010.

The following message is displayed:

An unexpected problem occurred while opening the file.

The file may be damaged. Try using a backup copy.

Cause:

After much investigation it seems that the enterprise custom fields configured as “Workflow Controlled” are at fault here, it seems that when disabling BCM mode some (not necessarily all!) projects which have values set in custom fields that are workflow controlled will become corrupt according to MS Project 2010. No service patch or cumulative update (as yet: Dec/2011) helps, but clearly something in the configuration of those fields gets messed up when BCM is switched off.

For Google and those into debugging WinProj, the internal error is:

The error occurs because the following error is returned when NonCoreProjectData is read.

The queried PID is Bad_PID, and the call winproj!TBkndPropCntr::GetAccessInfoPid cannot get Access information.

Solution:

Fortunately there is one, although a hotfix might come in the future, for my customer(s) working with MS we were able to find a procedure to fix the corruption.

Firstly when you disable BCM (by unchecking Enable Project 2007 Compatibility Mode in Server Settings – Additional Server Settings) the following SQL query can be used to identify any projects that may fail:

select distinct PROJ.PROJ_NAME from MSP_PROJECTS as PROJ

inner join MSP_PROJ_CUSTOM_FIELD_VALUES as PROJCF

on PROJ.PROJ_UID = PROJCF.PROJ_UID

inner join MSP_CUSTOM_FIELDS CF

on CF.MD_PROP_ID = PROJCF.MD_PROP_ID

where MD_PROP_IS_WORKFLOW_CONTROLLED = 1

order by PROJ.PROJ_NAME

In my recent case it was just about every project! But regardless of how many the following steps will correct the issue for those identified projects:

1. Backup your 4 x Project Server and 1 x SharePoint databases!
2. Copy Workflow Stage configuration from Server Settings – Workflow Stages. Copy Grid data to Excel, the columns required most are; Stage Name,  Required Custom Fields and Read Only Custom Fields. (You’ll need this info later!)
3. Copy Enterprise Custom Field configuration from Server Settings – Enterprise Custom Fields. Copy Grid to Excel. (Again this is for later reference)
4. Open each Workflow Controlled custom field from Server Settings and uncheck “Workflow Controlled” then save, this removes every field from every workflow stage configuration.
1. Note: For each field this will REMOVE the Read Only and Required configuration from each workflow stage where this field is used! (Make sure you have your backup from step #1!)
5. If required Force Check in all checked out projects, check queue to ensure all jobs complete before continuing.
6. From Server Setting – Additional Server Settings – Uncheck "Enable Project 2007 Compatibility Mode"
1. Restart MS Project
7. Open each affected project, save and publish them. (Note a full publish from MS Project is required – nope bulk publish using ProjTool doesn’t help!)
8. Now to correct the custom field and workflow configuration, re-open each custom field previously changed and recheck the “Workflow Controlled” setting. (Using the information backed up in step #3)
9. Now Reconfigure the required custom fields and  read-only custom fields for ALL workflow stages. (Using the information backed up in step #2)
10. Re-test affected projects.

The process effectively removes the “corruption” caused by the Workflow Controlled attribute in those projects, and fortunately if you are stuck after unchecking the BCM box without a backup using these steps (minus step 6) still should work!

I hope if you have this issue that you are seeing it only in Dev, as there is no better test of a DR procedure than unchecking that one little check box!

Hope that helps someone else out there.

One thing I always have to search for when creating a new EPT is the appropriate icon to use. I have previously found and used some of the out-of-the-box icons that can be found in any default Project Server 2010 installation and thought that I might share them here.

There is in fact a long list which I have included below (forgive me copyright gods in MS!), to use one of these icons, just update the image URL under Server Settings –> Enterprise Project Types, for example to update the default Sample Proposal with any of the icons below, simply modify the image URL under:

For a Master Project icon (taken from the image below), replace the URL above with the following:

/_layouts/inc/pwa/images/CenterMasterProject.png

Full list of icons (16×16 size only):

Enjoy!

A customer of mine had this one after completing the upgrade to SP1 recently, basically all cube building would fail with the following error:

Your CBSRequest job failed. Its current state is FailedNotBlocking. It was 0% complete. It entered the queue at 09/02/2011 11:00:26.

[snip…]

The errors returned from the queue are as follows:

Error ID: 17007

Error ID: 26000

[snip…]

<class name="CBS message processor failed">

<error id="17007" name="CBSOlapDatabaseSetupFailure" uid="7d14c29d-a133-492b-baea-2e7c0bec444b" QueueMessageBody="Setting UID=00007829-4392-48b3-b533-5a5a4797e3c9 ASServerName=server ASDBName=FullCube1 ASExtraNetAddress= RangeChoice=0 PastNum=1 PastUnit=0 NextNum=1 NextUnit=0 FromDate=01/04/2010 00:00:00 ToDate=12/31/2011 00:00:00 HighPriority=True" Error="Error Setting Olap Database ‘FullCube1′ roles: Error: This method can only convert identity claims, and only when a logical conversion exists.&#xD;&#xA;Parameter name: encodedClaim" />

This customer is using Claims-NTLM (ie AD users via Claims) for logins and that seems to be the cause of this issue. The give away is clearly in the error: “This method can only convert identity claims”.

Solution

Fortunately the solution turned out to be rather simple, it seems that SP1 does some additional checking when setting up the Cube Roles, as a result when users in the Project Server have issues then this error is caused.

A little more info can be seen in the ULS log:

09/02/2011 12:00:33.18  Microsoft.Office.Project.Server (0x17B0) 0x1A04  SharePoint Foundation   Claims Authentication d01p Medium  ConvertWindowsClaimToWindowsPrincipalName() encountered error: Some or all identity references could not be translated.

As it turns out a number of users in PWA have left the company and in this case as no AD-sync is used some of the accounts had been deleted from Active Directory but not updated in PWA server settings.

It seems also that accounts set as “inactive” also caused this error if they were in a group with the Global “View OLAP Cubes” permission.

The fix was to remove those user accounts from the PWA groups ‘Project Managers’, ‘Portfolio Managers’ and ‘Executives’ (and any others with the above permission).

Finally I just tested this in a non-Claims lab, and the problem doesn’t occur, in fact the cube log identifies and lists the invalid account then continues processing, so technically I would call this one a code defect.

Hope that helps someone else out there!

A common requirement for many SharePoint and Project Server deployments is to have an external facing interface using an alternate Forms based authentication method, the most common is using an ASP.NET SQL provider which since the 2007 version is the one of the simplest options. With 2010 however and Claims authentication this requires that you convert your existing Windows authenticated Web Applications to Claims based NTLM authentication, this process is well documented online for SharePoint 2010, however I have recently found that with Project Server 2010 a number of problems can be encountered.

Here is a typical error with the Project Details webpart after conversion:

[Hi Google: (An unknown error has occurred)]

In this blog I’m not going to cover the whole process of setting up Extranet access, I’ll leave it to you to read some of the other excellent blogs on the topic linked below. What I will cover is how to do the not-so-well documented parts.

To Start With: Procedure to Setup Extranet Access

The general procedure for extending a Project Server application for extranet users is something like this:

1. Provision a ASP.NET SQL membership Provider.
2. Extend the Web Application to add an Extranet zone.
3. Configure the Claims membership providers in the web.config files.

References for these steps:

1. MMohanty: http://blogs.technet.com/b/mahesm/archive/2010/04/07/configure-forms-based-authentication-fba-with-sharepoint-2010.aspx
2. Geoff Varosky: http://gvaro.wordpress.com/2011/03/28/planning-and-configuring-extranets-in-sharepoint-2010part-1/
3. Geoff Varosky: http://gvaro.wordpress.com/2011/04/01/planning-and-configuring-extranets-in-sharepoint-2010part-2/

If you have followed those steps discussed in the links, then when you will likely have found that you are seeing all sorts of security issues after changing your Classic Web App to Claims.

In short the error above originates from the procedure used to migrate the application to Claims:

(WARNING: Don’t use the above commands!)

Unfortunately this does not fully migrate the SharePoint application and from my experience will lead to errors such as the first one above.

Migrating the Web Application to Claims Without Issues

Fortunately Microsoft has a well documented procedure: http://technet.microsoft.com/en-us/library/gg251985.aspx

$WebAppName = "http:// yourWebAppUrl"
$account = "yourDomain\yourUser"
$wa = get-SPWebApplication $WebAppName

Set-SPwebApplication $wa -AuthenticationProvider `

  (New-SPAuthenticationProvider) -Zone Default

Note: that the above commands migrate ALL Web Applications sharing that URL, it is not possible to only migrate your Extended application!

That command will migrate the web application fully and prepare it for Claims authentication, and don’t forget the TechNet article discusses the need to update your portalsuperreaderaccount and portalsuperuseraccount accounts if they have been set, which can be done easily using the following commands:

$wa.Properties["portalsuperuseraccount"] = "i:0#.w|domain\apppool"

$wa.Properties["portalsuperreaderaccount"] = "i:0#.w|domain\apppool"

$wa.Update()

Migrating Users to Re-enable Login

Once your Web App is in Claims mode then you will still need to migrate your AD users, this part is not so well documented.

Essentially you need to use the PowerShell command Move-SPUser to move all of your existing “DOMAIN\username” users to the new Claims-NTLM identity “i0#.w|domain\username”.

Before you can do this you need to ensure that your admin user has permissions to access this site, this can be done from Central Admin by updating the Web Application Policy:

Add or re-add your user account (DOMAIN\adminuser) with Full Control to the web application in question, before proceeding with the following steps. (Note: the above Policy should now show your Admin user with the User Name like so; “i:0#.w|domain\adminuser”)

Next, here is the command to migrate a single user:

Get-SPUser -web http://server/pwa -identity "DOMAIN\user" | Move-SPUser -NewAlias "i:0#.w|domain\user" –IgnoreSID

The command will actually give the following error:

However if you then use Get-SPUser you will note that the account has actually been migrated.

So for my purposes I wrote the following script which will migrate all users without the claims prefix “i:0#.w|” (Yep ignore those errors!):

$UsersToMigrate = Get-SPUser -web http://server/pwa | `

  where {$_.UserLogin –like ‘DOMAIN\*’ }

 

ForEach ($user in $UsersToMigrate)

{

  Get-SPUser -web http://server/pwa -identity $user | Move-SPUser `

    -NewAlias ("i:0#.w|"+$user.UserLogin.toLower()) -IgnoreSID

}

After running the above, users should now be able to login to your migrated Web Application with any AD user!

If you see other errors running either that script or the above command by itself, make certain that you can do the following without errors:

Get-SPUser –web http://server/pwa

If not check your web policy again as above.

Finally Adding Your Claims Users to PWA

Now we have a fully migrated Claims-NTLM Web Application in addition to a newly created Extranet Claims Web Application which is attempting to use a Forms membership provider (SQL-MembershipProvider if you following the steps linked above).

The next steps are again well documented in the links above, configure your web.config files and then setup your SQL users.

The final problem you may face when attempting to add your new forms users to PWA, assuming (if using SQL that your ASPNETDB database permissions are correctly set) then adding the users to SharePoint will be easy using Site Actions – Site Permissions – Grant Permission, however what you will may see when attempting to add to Users to PWA is an error like the following:

(Error Message: The NT account specified is invalid. …)

This is because the user has not yet been added to the SharePoint site collection which fortunately is easy enough to fix, just add the user to SharePoint from Site Permissions first!

From Site Actions –> Site Permissions:

As long as SharePoint can find the user (make sure to use the full username!) then once you hit Ok the user identity will be added to the Site Collection, and then you will be able to add the user to PWA!

FYI if like me you like doing things in bulk here’s the PowerShell command to do the above:

New-SPUser -UserAlias "i:0#.f|SQLMembershipProvider|JaneDoe" -Web http://server/pwa -DisplayName "Jane Doe" -Email jane@blah.com

All done, enjoy your forms membership provider!

While investigating a solution for a customer who has a pretty common problem I came across another new feature to be included in Project Server 2010 Service Pack 1.

The problem comes about from the requirement to regularly publish project schedules to ensure that reporting data is kept up to date, this is particularly important when using Project Server timesheets which effectively demands that every active project be published at least once per period.

Normally this is okay, but when managing small projects some PM’s may have dozens or more active projects resulting in a significant administrative burden.

What’s new in SP1?

It seems that one of the unannounced new features is the inclusion of an option to “Automatically Publish” Task Updates approved by a rule, apparently the Status Approvals rule configuration will include this to make many of our lives easier!

I look forward to seeing it, and will update this post post release.

Update:

Looks like a few others a confirming this, see Christophe’s blog for some screenshots:

• One Small Check Box, One Giant Leap for Project Server – Gary Chefetz
• Automatically Publish Updates thanks to Project Server 2010 SP1 – Christophe Fiessinger

The end of June is the date announced for the release of SP1 for Project, Project Server and SharePoint 2010, one new feature (or ‘fix’) that is very exciting is:

• Multi-Browser Support for time entry in Project Web App – Post on 5/17
  • With SP1, Project Web App pages needed by team members to submit task status and timesheets are supported on FireFox, Safari, and Chrome.

Finally some support (albeit limited) for non-IE browsers!

Read more about SP1, here (Official Project Blog) and here (Office Sustained Engineering Blog).

Update 16/07:

Here’s a screenshot using Chrome:

A very frequent request I get is how to change the default permissions assigned by Project Server to Project Workspace Sites for all projects, unfortunately this is not something that is configurable in Project Server so the only option out of the box is to disable the permissions sync and manage those permissions manually. Of course if you don’t want Administrators to manage every user manually this is not an option.

This is made more annoying if you want PM’s to be able to manage the site, as by default they only have Contribute like access.

There are a few options that exist out there, notably this one; Adjust the Default Project Web Access Permission Levels, which uses a SharePoint timer job to manage the default Permission Levels. However I have had need for something simpler, and so recently for a customer I implemented the following:

Modifying Basic Site Permissions using Project Events:

My solution is by intent extremely simple, so simple that I will include the main piece of code below (as well as having the full solution attached), in short what this code does is the following:

On Publish of any project does the following;

1. Retrieves the OWNER of the Project
2. Retrieves the Workspace Site of the Project
3. Adds the Owner to the default SharePoint role SPRoleType.Administrator

So as you can see it only updates one user’s permissions, however it would be trivial to update the code to do more based on the Project Team and other requirements.

Here is the bulk of the code:

if (wssData.ProjWssInfo.Count == 0)
{
  LogEventEntry(String.Format("No workspace site found for project: {0}", 

    projectData.Project.First().PROJ_NAME), EventLogEntryType.Warning);
}
else {
  // Open the SPSite and web
  using (SPSite pwsSite = new SPSite(wssData.ProjWssInfo[0].PROJECT_WORKSPACE_URL))
  {
    using (SPWeb pwsWeb = pwsSite.OpenWeb())
    {
      // Handle Null Email Address
      String ownerEmail;
      if (resourceData.Resources.First().IsWRES_EMAILNull()) ownerEmail = "";
      else ownerEmail = resourceData.Resources.First().WRES_EMAIL;

      // Add the new role assignment to the Owner
      SPRoleAssignment roleAssn = 

        new SPRoleAssignment(resourceData.Resources.First().WRES_ACCOUNT,
          ownerEmail,
          resourceData.Resources.First().RES_NAME,
          "Project Owner");
      SPRoleDefinition roleDefn = 

        pwsWeb.RoleDefinitions.GetByType(SPRoleType.Administrator);
      roleAssn.RoleDefinitionBindings.Add(roleDefn);

      pwsWeb.RoleAssignments.Add(roleAssn);
    }
  }
}

The code is bound to both OnPublished and OnSummaryPublished (to get the Save from PWA also), and ensures that the Owner will always have Admin rights, and if not all the PM has to do is republish.

Download only the WSP package here with – basic – instructions.

Download the full source package here.

Notes:

• As an Event the solution runs under the security context of the Project Server Event Service account, and so this user must be a user in PWA with appropriate access, I use administrator however it could get by with less.
• This completely ignores the WssSync jobs created by Project Server, as such some actions such as AD sync and group membership changes can apply permissions outside of typical Publish events. However in my experience with 2010 this will not remove existing SharePoint permissions (see one of my previous blogs on this).
• The solution is built with Visual Studio 2010 and packaged as a WSP allowing for simple installation using typical SharePoint means.
• The solution uses Project Server 2010 WCF methods to access the PSI, and so without modification it will not work on Project Server 2007.
• The solution logs error information to the Event Log and not the ULS, this is because I’m lazy. However it means that on Windows Server 2008 if the user (Event Service Account) is not a local admin it will fail and log nothing.

Post comments with any questions or additions even, but please note that I can’t provide support for the standalone WSP package.

Often I am asked by Project users about assignment units and how can you explain the behaviour in MS Project, most often the questions are around why the % assigned units of a particular resource assigned to a task (an assignment) can change unexpectedly.

The situation can be explained through the following scenario using MS Project 2007:

1. A Project Manager creates a task of 10 days, assigns a resource and sets the Units to 20% (15 hours of work with 1.5 hours planned per 7.5 hour day) using the task settings of Fixed Duration and Not Effort Driven.

1. Now the Resource submits a timesheet that contains Monday = 1.5h, Tuesday = 0h, Wednesday = 1.5h.
2. After the status update is accepted into the plan the resource Assignment Units has changed to 23% and a gap is shown in the Gantt chart bar.

This behaviour is expected. The cause is due to the missing day (Tuesday) of work which results in an additional 1.5h of work being spread across the remaining days of the task resulting in each remaining day now having 1.72 hours of work, or put another way a ‘peak’ assignment units of 23%.

This can lead to some confusion when looking at project schedules as if like many people your organisation assigns resources to work on such % allocations, typically through an approval process which dictates the "maximum" % allocation for any given resource.

The solution for the PM of course is to reduce the remaining work to return the peak units back to 20% ie in the above example subtract 1.5h work from the total. To see this do the following to correct the units in the above example:

1. The Project Manager now edits the remaining work for the given task and reduces it by 1.5h, now the Units returns to 20%.

What’s new in Project 2010?

This behaviour has changed significantly in Microsoft Project 2010! In fact the behaviour now is closer to what you might expect; Microsoft has introduced a new field in addition to Assignment Units you now have Peak Units which shows exactly what you might guess from the name in the example above, in short you can see both the original “assigned units” of 20% and the actual “peak units” of 23% together.

See the following quote from Microsoft:

"In Project 2007, and previous versions, when this value differs from 100% we show it next to the resource name in the Gantt chart. For Project 2010 we’ve made some changes to the way that the Assignment Units field is calculated. Primarily, these changes were made in response to customer feedback about the way calculations were impacted when resources entered overtime work. For this release we’ve clarified the definition of the Peak field and the Assignment Units field which previously had some functional overlap but now fill more defined, separate, roles. As a result of these changes the Assignment Units field is no longer automatically modified to be greater or less than default value of 100%; as a consequence the field does not show up in the Gantt chart as often as it used to."

Source: Assignment Units in Project 2010

• http://blogs.msdn.com/b/project/archive/2010/04/29/assignment-units-in-project-2010.aspx

For more information on task types, assignments and such here is another good read on the topic;

Task Types: Don’t Get Frustrated!

• http://www.mpug.com/News/Pages/Task-Type-Basics.aspx

I came across an unexplained issue recently with an ‘old’ Project Server 2010 customer, in short what happened was many of the permissions across the Project workspace sites were lost. Unfortunately the loss was triggered by performing a Playbooks (2010 version) backup of the server configuration which was even more concerning, considering that is such a commonly used tool.

In short we needed a way to restore all of the workspace site permissions to what they should be, without having to manually action each site.

Some background:

As it turns out Project Server 2010 has (once again) drastically changed the way that workspace site permissions are managed, fortunately changed for the better as now the behaviour is something like this:

1. On first publish or creation of the workspace all appropriate users are granted permissions based on their group memberships and if they are a member of the project team. (Just as it previously worked)
2. Subsequent publish jobs trigger another ‘Workspace Create’ job which now only adds new permissions but does not remove any existing ones, such as when a new team member is added to the plan. (This is similar to 2007 SP2)
3. Active Directory Sync jobs trigger a permissions sync which acts just like #2.

The big differences are the following:

1. During the sync NO permissions are removed. Thus correcting the old situation where an AD sync during business hours could result temporary permission losses.
2. Manually changed permissions at the SharePoint level are respected. For instance if you remove a particular user from a SharePoint site, Project Server will not add it back in either of the standard permissions sync jobs above.

The Solution: To Restore All Permissions

As you may have found for yourself due to the new behaviour if a user is deleted from the SharePoint site, re-publishing a project will no longer fix the permissions. As such a new solution was needed in my case where permissions were lost across all sites:

1. Create a new Project Server group containing all users.
2. Assign My Organisation Category to that group.
3. Assign Permission ‘View Project Site’ to My Organisation category.
4. Save the new group (and wait for queue jobs to complete).
5. Once confirmed permissions working delete the group (and again wait for the queue).

This will force a full refresh of the workspace site permissions across all users and all sites. Due the the new method of handling permissions it will only add each user with a minimum of ‘Reader’ unless they have another group which applies like Project Manager or Administrator, once you complete step 5 those unnecessary Readers will be removed, leaving only the correct permissions.

HTH,

This is an issue I have seen now with two different Project Server 2010 clients;

Symptoms:

• Certain Projects cannot be opened in either PWA or MS Project.
• Oddly the same projects do not appear to exist in the Draft database, but DO appear in the Published database.
• Projects cannot be deleted from Server Settings after selecting the Published version and hitting delete.

Errors:

Delete Queue job fails and review of the ULS log shows the following:

10/14/2010 11:30:40.33        Microsoft.Office.Project.Server (0x14A8)        0x172C        Project Server        Server-side Project Operations        7gvo        Critical        Standard Information:PSI Entry Point: Project User: i:0#.w|domain\administrator Correlation Id: e63eca62-f9fb-40d6-af52-db59bff5b7cd PWA Site URL: http://project2010:82/PWA SSP Name: Project Server Service PSError: ProjectDeleteFailure (23006) The request to delete a project encountered a problem – the relevant job failed in the Queue. Project UID: 01c7c325-1704-4269-8316-ab1b0bc85d07. Sub-job type where failure occurred: Microsoft.Office.Project.Server.BusinessLayer.QueueMsg.
AdjustTimeSheetForDeletedProjectMessage. Sub-job ID where failure occurred: . Specific stage in the sub-job where failure occurred: . Does this failure block the correlated job group: Undefined. See the ‘Manage Queue’ page in PWA for more details.

Additionally enabling Verbose ULS logging for all Project Server events turns up this one:

10/14/2010 11:50:05.33        Microsoft.Office.Project.Server (0x14A8)        0×1434        Project Server Timesheet myzd Verbose PWA:http://project2010:82/PWA, ServiceApp:Project Server Service, User:i:0#.w|domain\administrator, PSI: Start ApproveProjectTimesheetLines(approvedTimesheetLines=’ ‘, rejectedTimesheetLines=… [GUID’s removed] … 10/14/2010 11:50:05.33        Microsoft.Office.Project.Server (0x14A8)        0×1434        Project Server Timesheet myzl Verbose Error is: GeneralItemDoesNotExist. Details: . Standard Information: PSI Entry Point: Project User: i:0#.w|domain\administrator Correlation Id: e63eca62-f9fb-40d6-af52-db59bff5b7cd PWA Site URL: http://project2010:82/PWA SSP Name: Project Server Service PSError: GeneralItemDoesNotExist (10000)

Resolution:

It took the enabling of Verbose logging to figure out the cause, the give away was the timesheet line delete job, it seems that for some reason the TS Line GUID’s above were causing the failure.

So the solution was relatively simple, identify the Timesheets (and respective lines) and delete them manually.

To that end I ended up creating a couple of SQL scripts;

Script 1:

Identify all projects which exist in the Published Database but not in Draft.

– Query to identify projects in Publish but not in Draft

USE ProjectServer_Published
SELECT PubProj.PROJ_UID, PubProj.PROJ_NAME AS Published, DrafProj.PROJ_NAME AS Draft
    FROM ProjectServer_Published.dbo.MSP_PROJECTS AS PubProj
    LEFT OUTER JOIN ProjectServer_Draft.dbo.MSP_PROJECTS AS DrafProj ON PubProj.PROJ_UID = DrafProj.PROJ_UID
    WHERE DrafProj.PROJ_NAME IS NULL

Script 2:

Identify all Timesheets with lines against projects not in the Draft database.

– Query to identify timesheets with lines against projects not in draft

USE ProjectServer_Published
SELECT MSP_TIMESHEETS.TS_UID, MSP_TIMESHEETS.CREATED_DATE, MSP_TIMESHEETS.TS_CACHED_RES_NAME, MSP_TIMESHEETS.TS_COMMENTS
    ,RepTSP.PeriodName, RepTSP.StartDate, RepTSP.EndDate
    ,MSP_TIMESHEET_LINES.PROJ_UID, MSP_TIMESHEET_LINES.TS_LINE_CACHED_PROJ_NAME
    FROM MSP_TIMESHEETS
    INNER JOIN MSP_TIMESHEET_LINES ON MSP_TIMESHEETS.TS_UID = MSP_TIMESHEET_LINES.TS_UID
    INNER JOIN ProjectServer_Reporting.dbo.MSP_TimesheetPeriod AS RepTSP ON MSP_TIMESHEETS.WPRD_UID = RepTSP.PeriodUID
    WHERE
    MSP_TIMESHEET_LINES.PROJ_UID IN (SELECT PubProj.PROJ_UID
        FROM ProjectServer_Published.dbo.MSP_PROJECTS AS PubProj
        LEFT OUTER JOIN ProjectServer_Draft.dbo.MSP_PROJECTS AS DrafProj ON PubProj.PROJ_UID = DrafProj.PROJ_UID
        WHERE DrafProj.PROJ_NAME IS NULL)
    ORDER BY CREATED_DATE

Note: For both script’s replace your ProjectServer_* name, and then run this script against your PUBLISHED database.

Running the 1st script is not mandatory, although it can be useful as in my case it identified a few more projects with this issue. However: Ignore the ‘eGlobal …” project(s) and do not attempt by any means to remove them, you have been warned!

The second script will identify line by line timesheets that need to be edited / deleted before you can delete from Published the problematic project. This needs to be done in the usual ways, probably by the Resource themselves unless using delegation or something similar.

Cause:

Good question! I was not able to identify the root cause of this one, although I did notice it occurring to me during a training session that I was hosting, in fact the issue occurred on the test project I was working on while testing the creation and use of Timesheet approval rules and of course submitting / approving / rejecting test timesheets. However despite that clue I was never able to reliably reproduce the issue, please leave a comment if you have any other ideas!

Hope that helps someone out there!