locked
Security Problem with Importing a New Work Item Type RRS feed

  • General discussion

  • I have a security problem with importing a new work item type:

    C:\Program Files\Microsoft Visual Studio 8\Common7\IDE>witimport.exe /f Task.xml /t MyServer /p MyProject
    Warning: TF26171: User/group '8bf66fb8-4812-4ee3-86f6-1d610dac52fb\Developers and Testers' is not found.
    TF26204: The account you entered is not recognized. Contact your Team Foundation Server administrator to add your account.

    The work item type definition file, Task.xml, does exist in the appropriate location. The Team Foundation Server, MyServer, does work and is accessible. The team project, MyProject, does exist. The project group, "Developers and Testers", does exist, though it was added manually today.

    What should I do?

    Tuesday, November 21, 2006 7:26 AM

All replies

  • Hello,

    The error is because it cannot find the Group you have added in the Work Item type rule.

    If you have manually added the group, Please check the name exactly matches. Then from the machine you are tryinf witImport, Please open Visual Studio

    Connect to your Server from Team Explorer, expand Work items node and click refresh.

    Now try witimport again.

    If it does not work, then please post the error message if it different and also the rule(xml) using this group.

    Regards,

     

    Tuesday, November 21, 2006 5:32 PM
  • The work item type you're trying to import contains reference to `[project]\Developers and Testers` group, and it looks like that group does not exist for the project you're trying to work with. Check whether that group is defined for this project; also, check the spelling.

    Thanks,

    Alex.

     

    Tuesday, November 21, 2006 7:45 PM
    Moderator
  • SSS> The error is because it cannot find the Group you have added in the Work Item type rule.

    I understood what the error message was about.

    SSS> If you have manually added the group...

    Yes, I added the group manually, as I stated this in my initial message.

    SSS> Please check the name exactly matches.

    I did this several times, and as I stated in my initial message, the group did exist.

    SSS> Then from the machine you are tryinf witImport... If it does not work...

    It didn't work... until the next day when the import was successful.

    AB> `[project]\Developers and Testers` group... does not exist for the project you're trying to work with.

    Again, the group did exist exactly for the project I worked with.

    AB> Check whether that group is defined for this project; also, check the spelling.

    Again, I did check several times, and the spelling was correct, too.

    However, now everything works fine (the next day the import was successful) but I still have questions regarding the situation... What was that? Is there any security caching mechanism that could be the reason? Is there a way to work it around (refresh the security cache manually)? Thanks.

    Thursday, November 23, 2006 2:09 PM
  • I can explain that. The warning about the missing group indicated that the group was not in cache on the client side. The fact that you saw it several times in a raw makes me think that that group did not exist on the server in the WIT database either, otherwise connecting to the server (which is the first thing witimport does) would bring it to the client side. The AT rejected your changes because it could not recognize that group.

     

    This indicates that syncing process, which keeps WIT users & groups data in sync with the rest of the system, was not working (or was doing some really long running task). Once it processed that group and synced it down to the work item tracking database, everything started working.

    Thanks,

    Alex

    Thursday, November 23, 2006 7:46 PM
    Moderator
  • The last question remain unanswered is, is there a way to work it around (refresh the security cache manually)? I mean, is there a way to force the security synchronization process? Sometimes we need to add something (import a work item type, add a group of users) as fast as possible and have no time to wait undefined time until the synchronization process occures...

    Friday, November 24, 2006 4:12 PM
  • Excuse me, is there anybody here? My questions are very important for me...

     Stanislav Ogryzkov wrote:

    The last question remain unanswered is, is there a way to work it around (refresh the security cache manually)? I mean, is there a way to force the security synchronization process? Sometimes we need to add something (import a work item type, add a group of users) as fast as possible and have no time to wait undefined time until the synchronization process occures...

    Or does everybody here always rely on the synchronization mechanism? How can we manage a real development process if I need to wait for about a day so that security changes could be applied? Without an option to run the synchronization process manually?

    Tuesday, December 12, 2006 1:08 PM
  • Stanislav,

    Sorry for the delayed response.

    Generally syncing users and groups does not take a long time, although we are making improvements to speed up syncing much larger groups.  I'm not sure what occured in your case here. When you added the group, did it contain an AD group with a large membership?

    Did you have any error messages or warnings in the NT Event Log?  Is this still happening?

    Thanks,

    Friday, December 29, 2006 12:34 AM
  • I am seeing this issue, too.  I add a group manually via Team Explorer, add one AD user to the group, then run WITIMPORT.  I get the same error messages.  The only message in my Application Event Logs I see are 1202 SceCli Warning messages "Security policies were propagated with warning. 0x534 : No mapping between account names and security IDs was done."  They are at random times, but could this be a related issue?
    Tuesday, May 1, 2007 9:03 PM
  • Eric,

     

    I assume at the time that when you re-opened the groups dialog, the new group and its AD member/identity shows up correctly in Team Explorere?

     

    Did you try running WITImport again at a later time?  Was this now successful?

    The NT Event log message does not seem relevant (I think).

     

    What version of the client/server are you running with - V1 or SP1?

     

    I'll see if we can find someone to try reproducing this problem.

     

    Wednesday, May 9, 2007 5:02 PM
  • Yes, the new groups were showing up.  If memory serves, I was able to work around this by restarting IIS.  After that, the WITImport was successful.

     

    We are hosting TFS (with SP1) on an instance of Windows Server 2003 on a virtualized server (unsure if this is a Microsoft or VMWare server).  Our client machines are XP SP2 Virtual PCs running Team Suite with SP1 - they are not members of a domain.

     

    Thanks!

    Wednesday, May 9, 2007 5:25 PM
  • Well, I am back with a "reincarnation" of the same problem. Since

    the first occurrence of the problem (see my initial post dated 21 Nov 2006) not many things changed except for now we use VSTS 2005 SP1. And the problem follows...

     

    I have a security problem with importing a work item type:

     

    C:\Program Files\Microsoft Visual Studio 8\Common7\IDE>witimport.exe /f Defect.xml /t MyTFS /p MyProject
    Warning: TF26171: User/group 'e248d668-5e4f-4e42-b3ca-c64c79590589\CCB_Customers_Testers' is not found.
    Warning: TF26171: User/group 'e248d668-5e4f-4e42-b3ca-c64c79590589\CCB_Developers' is not found.
    Warning: TF26171: User/group 'e248d668-5e4f-4e42-b3ca-c64c79590589\CCB_Developers' is not found.
    Warning: TF26171: User/group 'e248d668-5e4f-4e42-b3ca-c64c79590589\CCB_Testers' is not found.
    Warning: TF26171: User/group 'e248d668-5e4f-4e42-b3ca-c64c79590589\CCB_Customers_Testers' is not found.
    TF26204: The account you entered is not recognized. Contact your Team Foundation Server administrator to add your account.

     

    The work item type definition file, Defect.xml, does exist in the appropriate location (the same folder). The Team Foundation Server, MyServer, does work and is accessible. The team project, MyProject, does exist. The project groups, CCB_Customers_Testers, CCB_Developers and CCB_Testers, do exist (added a week ago, and can be seen from the Group Membership... dialog from Team Explorer).

     

    The question is, why does not witimport.exe "see" the mentioned project groups?

     

    Thank you in advance for your quick response.

    Wednesday, May 7, 2008 11:18 AM
  • Here's why this is happening. For certain historical reasons work item tracking uses its own storage for users and groups. There's a synchronization mechanism that keeps that storage in sync with the main storage (a.k.a. GSS). When synchronization stops working, it stops copying new identities into the private storage.

     

    Instructions on how to solve this problem will follow soon.

     

    Alex

    Wednesday, May 7, 2008 3:24 PM
    Moderator
  • How soon will the instructions follow? It is very critical for our development process...

     

    Thursday, May 8, 2008 5:09 AM
  • I've updated recently to SP1 and uploaded a new template for the first the since and now I'm having the same issue. I uploaded the template successfully but when I try to create a new project with this template, it doesn't seem to work properly.

     

    2008-07-09 12:15:33Z | Module: Work Item Tracking | Thread: 10 | Uploading work item type from file 'C:\Documents and Settings\as22217\Local Settings\Temp\TPW_tmp124A.tmp\WorkItem Tracking\TypeDefinitions\Création branche de développement.xml'...
    2008-07-09 12:15:35Z | Module: Work Item Tracking | Thread: 10 | TF26171: User/group 'b85b1e13-1b4f-4e67-80c5-48d7889d89b2\Intgrateurs' is not found.
    2008-07-09 12:15:35Z | Module: Work Item Tracking | Thread: 10 | TF26171: User/group 'b85b1e13-1b4f-4e67-80c5-48d7889d89b2\Intgrateurs' is not found.

     

    Here's a part of my template:

     

    <FIELD refname="System.AssignedTo">

    <READONLY not="[PROJECT]\Intégrateurs" />

    <ALLOWEDVALUES expanditems="true" filteritems="excludegroups">

    <LISTITEM value="[PROJECT]\Intégrateurs" />

    </ALLOWEDVALUES>

    <DEFAULT from="currentuser"/>

    <VALIDUSER/>

    </FIELD>


     

     

    First off, my group is named "Intégrateurs" and the server seems to ignore de "é". Second, The GUID 'b85b1e13-1b4f-4e67-80c5-48d7889d89b2' ain't the same as the local cache GUID on my development machine.

     

    My TFS server is hosted on virtual pc and I'm aware that GUID can change when a tech guy do some tasks.

     

    Wednesday, July 9, 2008 4:40 PM
  •  

     Aliaksei Baturytski - MSFT wrote:
    Instructions on how to solve this problem will follow soon.

     

    Of course, I'm disappointed with that Aliaksei's instructions haven't appeared here still...  However, I'm very glad that almost all security issues we met with TFS 2005 are gone after we moved to TFS 2008.

    Thursday, July 10, 2008 10:03 AM
  • Hi Guys,

    I am also having the same problem. I could not able to import a work item. I have created group called Code Reviewers on a particular team project. I exported work item and modified it in such a way that it could use Code Reviewers group.

    While exporting

    Warning: TF26171: User/group 'b7f56752-8972-44ee-bd05-e884a438f5f8\Code Reviewers' is not found.
    Warning: TF26171: User/group 'b7f56752-8972-44ee-bd05-e884a438f5f8\Code Reviewers' is not found.
    Warning: TF26171: User/group 'b7f56752-8972-44ee-bd05-e884a438f5f8\Code Reviewers' is not found.
    Warning: TF26171: User/group 'b7f56752-8972-44ee-bd05-e884a438f5f8\Code Reviewers' is not found.
    Warning: TF26171: User/group 'b7f56752-8972-44ee-bd05-e884a438f5f8\Code Reviewers' is not found.
    Warning: TF26171: User/group 'b7f56752-8972-44ee-bd05-e884a438f5f8\Code Reviewers' is not found.
    Warning: TF26171: User/group 'b7f56752-8972-44ee-bd05-e884a438f5f8\Code Reviewers' is not found.
    TF26204: The account you entered is not recognized. Contact your Team Foundation
     Server administrator to add your account.

    I have checked every thing.

    1. I had that group for that project.
    2. Group has Access permissions.
    3. I have users in that group.
    5. I could able to see that group from Team Explorer.
    6. I have created this group 1 week before(So that I think users and groups are in sync.)
    7. Itried with witimport and through Process editor also.

    and here is the event viewer log

    System.UnauthorizedAccessException: TF26204: The account you entered is not recognized. Contact your Team Foundation Server administrator to add your account. ---> System.Web.Services.Protocols.SoapException: b7f56752-8972-44ee-bd05-e884a438f5f8\Code Reviewers is not valid user. ---> b7f56752-8972-44ee-bd05-e884a438f5f8\Code Reviewers is not valid user. ---> b7f56752-8972-44ee-bd05-e884a438f5f8\Code Reviewers is not valid user.
       at Microsoft.TeamFoundation.WorkItemTracking.Proxy.RetryHandler.HandleSoapException(SoapException se)
       at Microsoft.TeamFoundation.WorkItemTracking.Proxy.ClientService.Update(String requestId, XmlElement package, XmlElement& result, MetadataTableHaveEntry[] metadataHave, String& dbStamp, IMetadataRowSets& metadata)
       at CProdStudioBackendChannel.Update(CProdStudioBackendChannel* , Boolean fBatchedSave, UInt16* bstrXMLUpdateData, UInt16** pbstrXMLUpdateData)
       --- End of inner exception stack trace ---
       at Microsoft.TeamFoundation.WorkItemTracking.Client.Provision.ProvisionClass.ImportValidateWorkItemTypeInternal(Int32 projectId, String methodologyName, XmlElement typeElement, ActionType action)
       at Microsoft.TeamFoundation.WorkItemTracking.Client.Provision.ProvisionClass.ImportWorkItemType(WorkItemStore ws, Int32 projectId, String methodologyName, String definition, ImportEventHandler handler)
       at Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItemTypeCollection.Import(String definition)
       at Microsoft.TeamFoundation.ProcessTools.TemplateEditor.TemplateEditorControls.frmWITDImport.ImportWorkItemType()
       at Microsoft.TeamFoundation.ProcessTools.TemplateEditor.TemplateEditorControls.frmWITDImport.frmProjectSelect_FormClosing(Object sender, FormClosingEventArgs e)

    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.


    Can anybody help me what is the problem with this.

    Regards,
    Ramesh
    Tuesday, September 30, 2008 6:36 AM
  • Hi,

    I had the same issue and resolved it by doing the following:

    Right click the project from Team Explorer
    Select Team Project Settings - Security
    Click "Add" and add the new defined group
    Check all permissions (Temporary)
    Retry the import

    If succeeds, you can remove the group or maintain the rights as you like.

    Hope this helps :)
    Wednesday, October 21, 2009 7:46 AM
  • If you want to kick in the sync job ahead of schedule you can log onto the TFS server and use the Services applet to start the sync service manually, then check in the app eventlog for status, see below:

    VSTS Sync Image
    Thursday, December 10, 2009 11:23 PM
  • Hi Everybody,

     

    The reality is that this error could be seen in some cases that don't have anything to do with security.

    In my case I had chosen default value for a field that didn't exist as an allowed value from the global list:

     

       <FIELD name="CLR Version" refname="Infragistics.CLR" type="String" reportable="dimension">
            <ALLOWEDVALUES>
              <GLOBALLIST name="Infragistics - CLR Versions" />
            </ALLOWEDVALUES>
            <DEFAULT from="value" value="N\A" />
          </FIELD>
    Correct (without a typo) value="N/A" which exists in the global list:
       <FIELD name="CLR Version" refname="Infragistics.CLR" type="String" reportable="dimension">
            <ALLOWEDVALUES>
              <GLOBALLIST name="Infragistics - CLR Versions" />
            </ALLOWEDVALUES>
            <DEFAULT from="value" value="N/A" />
          </FIELD>

    I would recommend that you check your recent changes and if such values exist in the global lists or listed items.

     

    Best regards,

    Alex

     

    Wednesday, August 10, 2011 9:57 AM
  • I have had the same problem with TFS 2017.2 and fixed it as follows:

    • Check spelling and permissions of the group, which allegedly does not exist. Let us call them "Developers and Testers".
    • Create a query where you have the clause: Assigned To = [Your Project]\Developers and Testers.
    • Regardless of the query results, retry the WIT upload. It worked for me.

    I suspect that the query triggers an internal database update. In any case, it worked for me after struggling several hours on this topic.

    Friday, October 27, 2017 10:58 AM