Freigeben über

Project creation failing with error "The identity [Project Name]Project Administrators is not a recognized identity."

  • Artikel

This error showed up on the forums, so I want to post about it here to explain what happened to cause this bug and explain the symptoms (you're left with a partially-created project).

During project creation (when you click Finish on the Project Creation Wizard aka PCW), the parts of the particular process methodology template (see the ProcessTemplate.xml file in the methodology template) will be run based on the order in the dependency information (no, I haven't tried to hose it up by making a dependency loop, but it sounds like fun :).  The "Groups and Permissions" task is actually what creates the team project's application groups (see in the log entries like 'Creating application group for "Readers" URI' by the GSSStructureUploader module).  As part of that module's work, it implicitly creates the built-in "Project Administrators" group (this creation isn't currently written in the log file, I've filed a bug to see if this is a change we can make for V1, but as long as GSS didn't fail, the Project Administrators group was indeed created).  It was created before the other groups ("Readers", "Contributors", "Build Services", etc.), since it's part of the actual GSS creation/registration of the project.  A couple of the useful things to note about the Project Administrators group is that it has all permission on the project (including DELETE, the permission to delete the project), and the user that's creating the project is automatically added to the Project Administrators group for the project (and because of this, can delete the project they just created).

Later on in the process, the Version Control task runs, creating a new folder and attempted to assign permissions to it (check out Version Control\VersionControl.xml in the process methodology template to see what is created, or to change it as desired).  Specifically, it's going to attempt to assign all permissions on this new folder to the Project Administrators group.

Problem 1

Now, for performance reasons (obviously), we cache our permissions/group information, and with Beta3 there's a bug where that cache wasn't getting updated during the PCW run that created the new project groups.  That means when the Version Control task ran, and it asked the server to assign permissions on that newly created folder, the server turns around and attempts to look up the groups.  Unfortunately, because our cache is stale, we get an error that the group doesn't actually exist (even though it really does back in the database).  The server throws an exception back to the client (the Version Control task), which throws an exception itself, and the PCW sees that things have gone all pear-shaped.

Problem 2

The PCW sees the exception and does what it can.  It knows it couldn't get the project fully created (into the WellFormed state if you checked out my last post to list the team projects on the server), so it's going to attempt to clean up this partially-created project that's sitting on the server.  The first thing the project-deleter code does is go ahead and check to see if the user has permission to delete the project.  There are 2 ways a user can have that permission: 1) be in the Team Foundation Administrators group and 2) be in a group that has the DELETE permission on the project (typically, the Project Administrators group).  Unfortunately, as stated above our groups and permissions cache is still stale, so even though this user should have passed the permissions check for DELETE on the project, our permissions cache is out of date, so that check fails.  Because of this, our attempt to clean up our partially-created project fails.

The good news is that you can still delete this partial project even with the stale cache - a member of Team Foundation Administrators can run TfsDeleteProject /force and get it cleaned up.  The /force option is necessary when you're expecting parts of the delete to fail (since parts of the creation didn't happen, or succeed) and want it to attempt to delete all the parts, and not just stop when it hits the first problem.

Workaround

For beta3, for the user that's going to be creating projects, go ahead and add them to the "Team Foundation Administrators" group.  This can be accomplished by using a member of the Service Accounts or other member of the Team Foundation Administrators group and adding the account as a member of that group.  For instance, if your server name was Test01 and the account that's trying to run the Project Creation Wizard is called TfsSetup, you would run:

   TFSSecurity.exe /server:Test01 /g+ "Team Foundation Administrators" TfsSetUp

This issue should only affect users that aren't members of the Team Foundation Administrators group (for instance, a user given CREATE_PROJECTS permission specifically), and has already been fixed in our current bits.  Both of the 2 problems above have the same cause, and it's unfortunate that we didn't catch this in time for Beta3, but we've got it taken care of for our RTM bits.  Hopefully you won't see this problem in your own usage of Beta3 of Team Foundation, but if you do, hopefully you'll find this explanatory post via some search engine :)

If you think this may have happened on your Team Foundation server but you're not sure, you can use the ListTeamProjects utility to see which team projects you have on your server and what state they're in.  Any project in the [New] state is a candidate for being caused by this bug (partially created so it didn't make it to WellFormed, and could not be deleted).

Comments

  • Anonymous
    February 27, 2006
    Some information is out on the web about a bug that exists when creating a project that results in an...
  • Anonymous
    February 27, 2006
    Some information is out on the web about a bug that exists when creating a project that results in an...
  • Anonymous
    June 08, 2009
    PingBack from http://menopausereliefsite.info/story.php?id=1944