BCM mode Problem in Project Server 2010

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.