Project Server 2010 - Users Modifying Fields within MS Project appears to produce a corruption RRS feed

  • Question

  • Hello everyone.  It’s been some time, but I’ve got another situation that I’d love to hear everyone's feedback on.

    A very unusual issue has surfaced surrounding users and their personal modifications of fields within their project.  We have a very active user base using MS Project 2010 and Project Server 2010.  By active, I mean that the users spend a good amount of time thinking of ways to personally change the look, feel and more importantly, the fields within MS Project to their individual liking.  Here are the steps one user took in this particular situation that is causing an issue:

    1. The user opened their project, selects a View and inserts an unused Text 27 column.
    2. Right clicked on that Text 27 column and selected Custom Fields.
    3. Renamed... the Text 27 field to (lets say Operations)
    4. Changed the Custom Attributes to Lookup and then created some lookup values for that newly defined attribute.
    5. Retuned to their current view, chose some tasks, and went about selecting those values they had just created in the modified Text 27 field.
    6. Saved and published their project.

    Here’s the unusually part.  They continued to do this for some time, claiming the values were retained each time it was saved and published.  Then one day...they opened their schedule to find that the values they had selected previously were now replaced with (please excuse my ignorance) what appears to be Chinese characters.  I’ve seen plenty of strange behaviors, but this particular circumstance is new to me.  That leads us to our simple questions:

      a.  Is this behavior expected or unexpected?

      b.  What do you believe would cause this behavior?

      c.  How would you go about remedying the situation?

    Below are the two proposed recommendations coming from two different angles.  Let me know what you think (theses are just summaries):

    Recommendation 1 - Modifying columns and particularly their intended values by the users is not recommended.  With heavy manipulation of fields from users we generally see a higher occurrence of issues surrounding those projects.  Text 27 is defined in our Project Server settings (Enterprise Global) as a text filed.  It should be left as such.  If the user desires to have a new lookup field added to the Enterprise Global they may introduce that recommendation at the next change request meeting.  Until then we should inform, educate and encourage the users not to perform these types of behaviors in MS Project connected to the Project Server.  From experience, we have seen that the more advanced the personal modification, the more likely a corruption may arise.

    Recommendation 2 - Backup, cleanup and then restore the Enterprise Global template.  Some have demonstrated success with these sorts of issues by making a backup of enterprise Global.  Backing up the Enterprise Global views to a local file.  Navigating to the published database and Executing Stored Procedure for dbo.MSP_WINPROJ_DELETE_EGLOBAL_PROJECT.  Commenting out some lines from in the E-Global.sql file.  Running a macro within MS Project.  Then begin the process of restoring your views to the Enterprise Global.  This has been tested and appears to resolve this issue.

    There you have it, two different ways to deal with this unusual situation.  I was under the impression that user modification of fields and columns, on a personal level was generally a no-no for the most extent, for these very reasons.  And that a Global Template rebuild was more of a DR related proceedure.  But since I’ve never run across this exact situation before, I wanted to see if you the the community had seen this behavior before, and how did you deal with it?

    As always, I very much appreciate the feedback.

    Chris Addis - MCTS

    Wednesday, April 10, 2013 2:29 PM


All replies

  • After a deep dive throughout this TechNet site, I’ve found about 3 different threads that seemed to be similar to this one here.  To summarize, they each appear to instruct the questioner to not allow or encourage users to use local custom fields.  Stating that “you cannot save or publish a local field”.  Is this the answer I’m looking for?  Does anyone agree or disagree with this recommendation?  Most importantly, why or why not?

    Thanks again for the help.

    Project Professional 2010 with Project Server 2010 - Issue using local custom fields

    Chris Addis - MCTS

    Wednesday, April 10, 2013 10:07 PM
  • Hi Chris,

    I wouldn't use local custom fields with Project Server, period. The organization should have an agreed upon approach to their metadata needs and those should be captured as Enterprise custom fields created and managed in PWA. Only ECFs are available for reporting so this pushed people to doing the right thing quickly.

    If you have different groups who can't quite agree on the custom fields, then you need Departments. See this for more info: The only caveat is that team member statusing has to be the same for all groups.

    Hope this helps!

    Treb Gatte | @tgatte |

    Friday, April 12, 2013 4:26 AM
  • Thanks Treb,

    Thank you for your response.  I agree with what you say and what others in our community appear to say as well.  Avoid the use of local custom fields and educate your users on the proper use of ECFs.  And yes, I would also agree that Departments might appear to be a good option in this case.

    Thanks again for your answer.  Let's see if anyone else has additional remarks.

    Chris Addis - MCTS

    Friday, April 12, 2013 1:24 PM
  • Hi Chris, there was  a bug where local fields could get 'switched' if different users had the same local field used for different purposes - sounds like this might be hitting your system.  This was resolved in the August 2012 Cumulative update for Project Server 2010 - so loading any update after that - for example the recently released April 2013 CU, should resolve this issue (but will not correct any switched fields). 

    I certainly agree with Treb, and sounds like you would like to head in this direction too - you would be better to control the usage of fields centrally - particularly at the task level - as many extra fields can introduce performance problems too.

    Best regards,


    Blog | Facebook | Twitter | Posting is provided "AS IS" with no warranties, and confers no rights.
    Project Server TechCenter | Project Developer Center | Project Server Help | Project Product Page

    Friday, April 12, 2013 4:53 PM
  • Hello Brian.

    Another great response, thank you Brian.  I was not aware of that issue and the related CU.  I will read through your link provided and find out where we are with that.

    It appears most of us generally discourage this behavior amongst our users, myself included, throughout the years.  However, it's always a good idea to discuss these sort of issues from time to time to remind ourselves why we recommend certain behaviors and why.  And occasionally, we learn or discover something new.

    Great information.  I'll be sure to pass it on.

    Chris Addis - MCTS

    Friday, April 12, 2013 5:29 PM
  • Hello Brian.

    I did check with our guys, and we are current with our CU's.  So I'm not sure if this is the same issue, or is it still recurring.  Either way, I think we will continue to monitor this unusual behavior to be sure it doesn't propagate.  We will also encourage users to limit there use of local custom fields.  Thank you very much Brian.

    No one seemed interested in Recommendation 2.  Recommendation 1 seems to be the path that agrees with our responses.  So if there are no other comments on this thread, I will mark Treb's response as our answer.  Thanks again for the help.

    Chris Addis - MCTS

    • Edited by Chris Addis - MCTS Monday, April 22, 2013 2:51 PM Added more detailed response
    Monday, April 22, 2013 2:44 PM