Checkout this new tool that I just uploaded to codeplex!!

This tool can get the “expanded” security group membership on all “Areas” for all team projects in a given collection.

This can be handy when you want to troubleshoot an orphan user issue in TFS. So an orphan user would be a user that has been removed from all server\project level security groups in TFS but still end up showing as a member of the Project Collection Valid Users group. One of the reasons why this could happen is because the user has a direct permission assigned to it in some Area in some Team Project in the collection. This is where this small tool can help you. It goes through each team project in a TPC, and for each Team Project it iterates through each defined Area and then it dumps out the security group membership for each area.

Pre-requisite:
Needs to be run on the TFS 2010 App Tier machine (because it has dependency on a TFS server side assembly)

Usage:
GetAreas.exe “Collection Uri”

Example:
GetAreas.exe “https://server:8080/tfs/DefaultCollection”
Or
GetAreas.exe https://server:8080/tfs/DefaultCollection > Dump.txt

Check out this tool that I just published to https://gettfsusers.codeplex.com.

I am writing this post as I have got a lot of people who wanted a post on this scenario.

So here it goes. I will be referring you to the steps in my earlier post on performing a side-by-side upgrade from WSS 2.0 to WSS 3.0 for TFS 2008 posted here.

Here is what you need to do:

#1 Run the pre-scan tool for WSS 3.0 on the WSS 2.0 machine

Download the WSS 3.0 Pre-Scan tool from the download center:
https://www.microsoft.com/downloads/details.aspx?FamilyID=e8a00b1f-6f45-42cd-8e56-e62c20feb2f1&DisplayLang=en

Open a command prompt windows & change to the folder where you have downloaded the pre-scan tool. Run the pre-scan tool as:
PreScan /ALL

#2 Take a backup of the WSS 2.0 content database

#3 Restore the backup to the SQL machine for your TFS 2010 server

#4 Install and configure WSS 3.0 with SP2 on the TFS 2010 machine. You have to select advanced and server farm options during the installation process for WSS 3.0. Post installation you have to run the SharePoint Products and technology wizard to configure SharePoint. (follow guidance in step 7 & 8 in https://blogs.msdn.com/b/lakhminder/archive/2008/07/08/upgrading-wss-2-0-to-wss-3-0-after-a-tfs-upgrade.aspx)

#5 Extend the default web site with a temporary contentdb(step 9 in https://blogs.msdn.com/b/lakhminder/archive/2008/07/08/upgrading-wss-2-0-to-wss-3-0-after-a-tfs-upgrade.aspx).

#6 Un-attach the temporary content db and attach the restored db from #3 above (This is covered in step 10 in https://blogs.msdn.com/b/lakhminder/archive/2008/07/08/upgrading-wss-2-0-to-wss-3-0-after-a-tfs-upgrade.aspx)

That’s it, from this point on you can use the TFS 2010 upgrade wizard and include SharePoint as part of the upgrade experience.

[options]

UseAllowVerbs=0                ; If 1, use [AllowVerbs] section, else use the
                               ; [DenyVerbs] section.   The default is 1.

UseAllowExtensions=0           ; If 1, use [AllowExtensions] section, else
                               ; use the [DenyExtensions] section. The
                               ; default is 0.

NormalizeUrlBeforeScan=1       ; If 1, canonicalize URL before processing.
                               ; The default is 1.  Note that setting this
                               ; to 0 will make checks based on extensions,
                               ; and the URL unreliable and is therefore not
                               ; recommend other than for testing.

VerifyNormalization=1          ; If 1, canonicalize URL twice and reject
                               ; request if a change occurs.  The default
                               ; is 1.

AllowHighBitCharacters=0       ; If 1, allow high bit (ie. UTF8 or MBCS)
                               ; characters in URL.  The default is 0.

AllowDotInPath=1               ; If 1, allow dots that are not file
                               ; extensions. The default is 0. Note that
                               ; setting this property to 1 will make checks
                               ; based on extensions unreliable and is
                               ; therefore not recommended other than for
                               ; testing.

RemoveServerHeader=0           ; If 1, remove the 'Server' header from
                               ; response.  The default is 0.

;**Note setting RemoveServerHeader to 1 will cause the Team Project Creation fail with 400 bad request error while uploading files to WSS document list libraries

EnableLogging=1                ; If 1, log UrlScan activity.  The
                               ; default is 1.  Changes to this property
                               ; will not take effect until UrlScan is
                               ; restarted.

PerProcessLogging=0            ; This property is deprecated for UrlScan
                               ; 3.0 and later.  UrlScan 3.0 and later can
                               ; safely log output from multiple processes
                               ; to the same log file.  Changes to this
                               ; property will not take effect until
                               ; UrlScan is restarted.

AllowLateScanning=0            ; If 1, then UrlScan will load as a low
                               ; priority filter.  The default is 0.  Note
                               ; that this setting should only be used in
                               ; the case where there another installed
                               ; filter is modifying the URL and you wish
                               ; to have UrlScan apply its rules to the
                               ; rewritten URL.  Changes to this property
                               ; will not take effect until UrlScan is
                               ; restarted.

PerDayLogging=1                ; If 1, UrlScan will produce a new log each
                               ; day with activity in the form
                               ; 'UrlScan.010101.log'. If 0, UrlScan will
                               ; log activity to urlscan.log.  The default
                               ; is 1.  Changes to this setting will not
                               ; take effect until UrlScan is restarted.

UseFastPathReject=0            ; If 1, then UrlScan will not use the
                               ; RejectResponseUrl.  On IIS versions less
                               ; than 6.0, this will also prevent IIS
                               ; from writing rejected requests to the
                               ; W3SVC log.  UrlScan will log rejected
                               ; requests regardless of this setting.  The
                               ; default is 0.

LogLongUrls=0                  ; This property is deprecated for UrlScan 3.0
                               ; and later. UrlScan 3.0 and later will
                               ; always include the complete URL in its log
                               ; file.

UnescapeQueryString=1          ; If 1, UrlScan will perform two passes on
                               ; each query string scan, once with the raw
                               ; query string and once after unescaping it.
                               ; If 0, UrlScan will only look at the raw
                               ; query string as sent by the client.  The
                               ; default is 1. Note that if this property is
                               ; set to 0, then checks based on the query
                               ; string will be unreliable.

;
; If UseFastPathReject is 0, then UrlScan will send
; rejected requests to the URL specified by RejectResponseUrl.
; If not specified, '/Rejected-by-UrlScan' will be used.
; Changes to this setting will not take effect until UrlScan
; is restarted.
;
; Note that setting "RejectResponseUrl=/~*" will put UrlScan into Logging
; Only Mode.  In this mode, UrlScan will process all requests per the
; config settings, but it will only log the results and not actually
; reject the requests.  This mode is useful for testing UrlScan settings
; on a production server without actually interrupting requests.
;

RejectResponseUrl=

;
; LoggingDirectory can be used to specify the directory where the
; log file will be created.  This value should be the absolute path
; (ie. c:\some\path).  If not specified, then UrlScan will create
; the log in the same directory where the UrlScan.dll file is located.
; Changes to this setting will not take effect until UrlScan is
; restarted.
;

LoggingDirectory=Logs

;
; If RemoveServerHeader is 0, then AlternateServerName can be
; used to specify a replacement for IIS's built in 'Server' header
;

AlternateServerName=

;
; UrlScan supports custom rules that can be applied in addition to the other
; checks and options specified in this configuration file.  Rules should be
; listed in a comma separated string in the RuleList property.  Each rule in
; the list corresponds to two sections in this configuration file, one
; containing the options for the rule, and one containing deny strings for
; the rule.
;
; Here is an example:
;
;   [Options]
;   RuleList=Rule1
;
;   [Rule1]
;   AppliesTo=.exe,.dll        ; A comma separated list of file extensions to
;                              ; which the rule applies.  If not specified,
;                              ; the rule will be applied to all requests.
;
;   DenyDataSection=Rule1 Data ; The name of the section containing the
;                              ; rule's deny strings
;
;   ScanURL=0                  ; If 1, the URL will be scanned for deny
;                              ; strings. The default is 0.
;
;   ScanAllRaw=0               ; If 1, then the raw request header data will
;                              ; be scanned for deny strings.  The default
;                              ; is 0.
;
;   ScanQueryString=0          ; If 1, the the query string will be scanned
;                              ; for deny strings.  The default is 0.  Note
;                              ; that if UnescapeQueryString=1 is set in the
;                              ; [Options] section, then two scans will be
;                              ; made of the query string, one with the raw
;                              ; query string and one with the query string
;                              ; unescaped.
;
;   ScanHeaders=               ; A comma separated list of request headers to
;                              ; be scanned for deny strings.  The default is
;                              ; no headers.
;
;   DenyUnescapedPercent=0     ; If 1, UrlScan will scan the specified part
;                              ; of the raw request for a % character that is
;                              ; not used as an escape sequence.  If found,
;                              ; the request will be rejected.  This check
;                              ; can be used with ScanQueryString=1,
;                              ; ScanAllRaw=1, or the list of ScanHeaders.
;                              ; The default is 0.  Note that if you want to
;                              ; deny non-escaped % characters in the URL,
;                              ; you can set VerifyNormalization=0 in the
;                              ; [Options] section and then add % as a
;                              ; [DenyUrlSequences] entry.
;
;   [Rule1 data]
;   string1
;   string2
;

RuleList=

[RequestLimits]

;
; The entries in this section impose limits on the length
; of allowed parts of requests reaching the server.
;
; It is possible to impose a limit on the length of the
; value of a specific request header by prepending "Max-" to the
; name of the header.  For example, the following entry would
; impose a limit of 100 bytes to the value of the
; 'Content-Type' header:
;
;   Max-Content-Type=100
;
; Any headers not listed in this section will not be checked for
; length limits.
;
; There are 3 special case limits:
;
;   - MaxAllowedContentLength specifies the maximum allowed
;     numeric value of the Content-Length request header.  For
;     example, setting this to 1000 would cause any request
;     with a content length that exceeds 1000 to be rejected.
;     The default is 30000000.
;
;   - MaxUrl specifies the maximum length of the request URL,
;     not including the query string. The default is 260 (which
;     is equivalent to MAX_PATH).
;
;   - MaxQueryString specifies the maximum length of the query
;     string.  The default is 2048.
;

MaxAllowedContentLength=30000000
MaxUrl=260
MaxQueryString=2048

[AllowVerbs]

;
; The verbs (aka HTTP methods) listed here are those commonly
; processed by a typical IIS server.
;
; Note that these entries are effective if "UseAllowVerbs=1"
; is set in the [Options] section above.
;

GET
HEAD
POST
OPTIONS
SEARCH
PUT

[DenyVerbs]

;
; The verbs (aka HTTP methods) listed here are used for publishing
; content to an IIS server via WebDAV.
;
; Note that these entries are effective if "UseAllowVerbs=0"
; is set in the [Options] section above.
;

PROPFIND
PROPPATCH
MKCOL
DELETE
COPY
MOVE
LOCK
UNLOCK

[DenyHeaders]

;
; The following request headers alter processing of a
; request by causing the server to process the request
; as if it were intended to be a WebDAV request, instead
; of a request to retrieve a resource.
;

Translate:
If:
Lock-Token:
Transfer-Encoding:

[AllowExtensions]

;
; Extensions listed here are commonly used on a typical IIS server.
;
; Note that these entries are effective if "UseAllowExtensions=1"
; is set in the [Options] section above.
;

.htm
.html
.txt
.jpg
.jpeg
.gif

[DenyExtensions]

;
; Extensions listed here either run code directly on the server,
; are processed as scripts, or are static files that are
; generally not intended to be served out.
;
; Note that these entries are effective if "UseAllowExtensions=0"
; is set in the [Options] section above.
;
; Also note that ASP scripts are denied with the below
; settings.  If you wish to enable ASP, remove the
; following extensions from this list:
;    .asp
;    .cer
;    .cdx
;    .asa
;

; Deny executables that could run on the server
.exe
.bat
.cmd
.com

; Deny infrequently used scripts
.htw     ; Maps to webhits.dll, part of Index Server
.ida     ; Maps to idq.dll, part of Index Server
.idq     ; Maps to idq.dll, part of Index Server
.htr     ; Maps to ism.dll, a legacy administrative tool
.idc     ; Maps to httpodbc.dll, a legacy database access tool
.shtm    ; Maps to ssinc.dll, for Server Side Includes
.shtml   ; Maps to ssinc.dll, for Server Side Includes
.stm     ; Maps to ssinc.dll, for Server Side Includes
.printer ; Maps to msw3prt.dll, for Internet Printing Services

; Deny various static files
.ini     ; Configuration files
.log     ; Log files
.pol     ; Policy files
.dat     ; Configuration files
.config  ; Configuration files

[AlwaysAllowedUrls]
;
; URLs listed here will always be explicitly allowed by UrlScan
; and will bypass all UrlScan checks.  URLs must be listed
; with a leading '/' character.  For example:
;
;   /SampleURL.htm
;

[DenyUrlSequences]
;
; If any character sequences listed here appear in the URL for
; any request, that request will be rejected.
;

..  ; Don't allow directory traversals
./  ; Don't allow trailing dot on a directory name
\   ; Don't allow backslashes in URL
:   ; Don't allow alternate stream access
%   ; Don't allow escaping after normalization
&   ; Don't allow multiple CGI processes to run on a single request

[AlwaysAllowedQueryStrings]
;
; Query strings listed here will always be explicitly allowed by
; UrlScan and will bypass all query string based checks.
;

[DenyQueryStringSequences]
;
; If any character sequences listed here appear in the query
; string for any request, that request will be rejected.
;

<   ; Commonly used by script injection attacks
>   ; Commonly used by script injection attacks

use Tfs_DefaultCollection

--Select * from tbl_EventSubscription

Select 'bissubscribe /unsubscribe /id ' + CAST(id as varchar(255))+ ' /collection https://TFS2:8080/tfs/ProjectCollectionName'
from dbo.tbl_EventSubscription
where ID>1

Copy the o/p of the above sql , open notepad, paste & save the file as a batch file.

Open elevated command prompt & change to %TFSInstallDir%\Tools folder and run the batch file from there.

That’s it all alerts should be gone now.

Step #1: Export the MSF Agile\CMMI 5.0 process templates to a folder. In my examples the process template is downloaded in the following folders:

C:\MSF for Agile Software Development v5.0

C:\MSF for CMMI Process Improvement v5.0

Instructions to download process templates are available here.

Step #2: Prepare the Reports Manager Site to host the new reports for the team project

Example:

For a team project name A, browse the reports uri which would host the reports for the team project A. An example of this uri would be:

General Syntax:

https://<reportservername>/Reports/TfsReports/<CollectionName>/A

Example:

https://localhost/reports/tfsReports/defaultcollection/A

Note: For Server 2008\2008 R2, you would need to browse the reports site in an elevated IE browser window.

Create a new folder, by clicking on “New Folder” option, in the https://localhost/reports/tfsReports/defaultcollection/A site and call it “Old Reports”.

Move the existing rdl files to the newly created folder. You can click on “Show details” option. Doing so will enable you to select multiple reports & move them to the “Old Reports” folder in a single operation. Click “Hide Details” after moving the reports. The reports site for the team project A would look like this:

Step #3 Upload new reports

To add reports

1. Click Start, right-click Visual Studio, and then click Run as administrator.

2. Create a file, and copy and paste the following code into it:

<?xml version="1.0" encoding="utf-8"?>

<Project xmlns="ProjectCreationSettingsFileSchema.xsd">

<TFSName>CollectionURI</TFSName>

<LogFolder>LogFolderName</LogFolder>

<ProjectName>TeamProjectName</ProjectName>

<AddFeaturesToExistingProject>true</AddFeaturesToExistingProject>

<ProjectReportsEnabled>true</ProjectReportsEnabled>

<ProjectReportsForceUpload>true</ProjectReportsForceUpload>

<ProjectSiteEnabled>false</ProjectSiteEnabled>

<ProcessTemplateName>ProcessTemplate</ProcessTemplateName>

</Project>

3. Replace the placeholder attributes with values that meet your project criteria.

4. To upload the most recent versions of the reports that are provided in the process template, specify true for the ProjectReportsForceUpload tag.

<ProjectReportsForceUpload>true</ProjectReportsForceUpload>

5. Save the file as an XML file.

6. Run the File.BatchNewTeamProject command, and specify the file that you saved in the previous step.

7. To verify that the reports are available, from Team Explorer, expand your team project node, expand Reports, and then expand Bugs, Build, Project Management, or Test. 

8. Double-click a report that you want to view.

To run the team project batch file command

1. On the View menu, click Team Explorer.

2. On the View menu, point to Other Windows, and then click Command Window.

3. In the Command Prompt window, type the following command, specifying the path and file name of the file that you saved earlier in this topic. For example, type the following command:

File.BatchNewTeamProject C:\File.xml

4. To determine the outcome of running the command, view the contents of the log file. This file is written to the location that you specified for LogFolderPathName in the File.xml file.

Review the messages in the log file to determine whether the command was successful. If error messages occur, correct the parameters, and rerun the command.

Post deployment Issues:

Issue#1: Reports will throw error about missing columns or datasets.

Fix:

1. Create new team projects with MSF Agile 5.0 & MSF CMMI 5.0 based templates.

2. Rebuild the warehouse dbs from Tfs Admin Console->Application Tier->Reporting->Start Rebuild option:

3. Verify reports to check for any outstanding errors.

- TFS 2010 is integrated with MOSS 2007\SharePoint Server 2010 Ent Edition

- MOSS 2007 has Excel Calculation Services + Single Sign Configured according to the guidance available here.

- SharePoint Server 2010 has Excel Services + Secure Store Service configured according to the guidance available here.

Permissions:

The user must be a site collection administrator

Enable TFS 2010 features for Agile 4.2 site collection:

Before enabling the features the site collection would appear as:

After enabling the TFS 2010 features the site collection would appear as (note the new items in the quick launch menu):

You can clean up the old TFs 2008 style quick launch links for Reports & make the site collection appear as:

Steps to enable TFS 2010 features on the site collection:

Step# 1: Browse the team portal in a IE

Step# 2: Go to Site Actions->Site Settings

Step# 3: In the Site Settings page, under Site Collection Administrator, click Site Collection Features.

Step# 4: On the Features page, find the feature with the name of “Visual Studio Team Foundation Server Web Part Collection” and click the Activate button. Return to the Site Settings page.

Step# 5: On the Site Settings page, under Site Actions click Manage site features

Step# 6: Find the feature with the name “Agile Dashboards with Excel Reporting” and click Activate.

Step# 7: Return to the home page for the site collection and verify that you have the quick launch links for TSWA portal, Excel Reports & the new TFS 2010 dashboards.

Enable TFS 2010 features for Agile 4.2 site collection:

Steps to enable TFS 2010 style features on a CMMI 4.2 site collection are the same except for Step#6 where you would activate the feature with the name “CMMI Dashboards with Excel Reporting”.

SOLUTION

=================

At a high level:

1. You must add the new work item types, test case and shared steps, to your upgraded team project to use Microsoft Test Manager.

2. You must add link types and categories that are provided with version 5.0 of the MSF process templates. You must customize existing work item types to have the new fields appear on the work item forms.

3. You must also upload a mapping file that specifies the work item type to support automatic creation of bugs or code defects by Microsoft Test Manager.

The witadmin and tcm tools used in commands are available in one of the two folder paths depending on x86 or x64 OS:

** x86 Path **

C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE>

** x64 Path **

C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE>

Steps:

Step #1 Take backups of the TFS Configuration, Collection & warehouse db.

Step #2 Export the MSF Agile\CMMI 5.0 process templates to a folder. In my examples the process template is downloaded in the following folders:

C:\MSF for Agile Software Development v5.0

C:\MSF for CMMI Process Improvement v5.0

Instructions to download process templates are available here.

Step #3 Get the list of existing link types:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE>witadmin.exe listlinktypes /collection:https://localhost:8080/tfs/DefaultCollection > c:\LinkTypes.txt

Step #4 If the LinkTypes.txt file does not contain the following type then proceed to #5:

Reference Name: Microsoft.VSTS.TestCase.SharedStepReferencedBy

Names: Test Case, Shared Steps

Topology: Dependency

Is Active: True

If the Test Case & Shared Steps link types are already present you should take a backup of the existing link types for Test Case & Shared Steps before proceeding to #5

Step #5 This is a one-time operation & it will add\upload the Shared Steps and Tested By Link Types to the collection:

witadmin importlinktype /collection:https://localhost:8080/tfs/DefaultCollection /f:"C:\MSF for Agile Software Development v5.0\WorkItem Tracking\LinkTypes\TestedBy.xml"

witadmin importlinktype /collection:https://localhost:8080/tfs/DefaultCollection /f:"C:\MSF for Agile Software Development v5.0\WorkItem Tracking\LinkTypes\SharedStep.xml"

You should run the following command to confirm that the link types have been uploaded to the collection:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE>witadmin.exe listlinktypes /collection:https://localhost:8080/tfs/DefaultCollection > c:\LinkTypesVerify.txt

Step #6 onwards need to be performed against each TFS 2008 team project in the collection for which TCM needs to be enabled

Step #6 Export the list of work item type definitions(witd in short) by running the following command:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE>witadmin listwitd /collection:https://localhost:8080/tfs/DefaultCollection /p:Agile001 > c:\Agile001.txt

You should see an output like:

(For MSF Agile 4.2)

Bug
Task
Quality of Service Requirement
Scenario
Risk

(For MSF CMMI 4.2)

Bug
Task
Issue
Change Request
Risk
Requirement
Review

Ensure that the TestCase & SharedStep witds are not listed as part of the output. If these witds are part of the output then you would need to follow the guidance available in the “Customizing an Existing Test Case Type of Work Item” section of this article.

Proceed to Step# 7.

Step #7 Add the TestCase & Shared witds:

witadmin importwitd /collection:https://localhost:8080/tfs/DefaultCollection /p:Agile001 /f:"C:\MSF for Agile Software Development v5.0\WorkItem Tracking\TypeDefinitions\TestCase.xml"

witadmin importwitd /collection:https://localhost:8080/tfs/DefaultCollection /p:Agile001 /f:"C:\MSF for Agile Software Development v5.0\WorkItem Tracking\TypeDefinitions\SharedStep.xml"

When you run the above commands you might get an error message as following:

ISSUE:

TF212018: Work item tracking schema validation error: TF26177: The field System.

AreaId cannot be renamed from 'AreaID' to 'Area ID'.

RESOLUTION: From:

When you import types of work items, an error message might indicate a naming conflict. This conflict occurs more frequently in deployments that were upgraded from an earlier release of Team Foundation. The friendly name was renamed for several system and test case management fields before the final release of Visual Studio Team Foundation Server 2010. System fields that were renamed include System.AreaID, System.IterationID, System.HyperLinkCount, System.ExternalLinkCount, and System.AttachedFileCount.

You can resolve this error by renaming the field either in the XML definition for a work item type or by using the witadmin changefield command-line tool. For more information, see Managing Work Item Fields [witadmin].

Review the attributes that are assigned to the field in the project collection. You can use the witadmin listfields command:

witadmin listfields /collection:https://localhost:8080/tfs/DefaultCollection > c:\ListFields.txt

Look for the name attributes for the System.AreaID, System.IterationID, System.HyperLinkCount, System.ExternalLinkCount, and System.AttachedFileCount fields. An example taken from the c:\ListFields.txt file for the System.AreaId field:

Field: System.AreaId
Name: AreaID <-- Note: in TFS 2010 world this name would be “Area ID”
Type: Integer
Use: System Field
Indexed: False
Reportable As: None

To resolve the TF212018 error run the following commands and type ‘y’ when prompted to confirm the change:

(NOTE: These commands will need to be run just once at the collection level)

For TestCase

witadmin changefield /collection:https://localhost:8080/tfs/DefaultCollection /n:"System.ExternalLinkCount" /name:"External Link Count"

witadmin changefield /collection:https://localhost:8080/tfs/DefaultCollection /n:"System.RelatedLinkCount" /name:"Related Link Count"

witadmin changefield /collection:https://localhost:8080/tfs/DefaultCollection /n:"System.HyperLinkCount" /name:"Hyperlink Count"

witadmin changefield /collection:https://localhost:8080/tfs/DefaultCollection /n:"System.AttachedFileCount" /name:"Attached File Count"

witadmin changefield /collection:https://localhost:8080/tfs/DefaultCollection /n:"System.AreaId" /name:"Area ID"

For SharedStep

witadmin changefield /collection:https://localhost:8080/tfs/DefaultCollection /n:"System.IterationId" /name:"Iteration ID"

Sample output:

You should now be able to add the TestCase & SharedSteps witds by running the command:

witadmin importwitd /collection:https://localhost:8080/tfs/DefaultCollection /p:Agile001 /f:"C:\MSF for Agile Software Development v5.0\WorkItem Tracking\TypeDefinitions\TestCase.xml"

witadmin importwitd /collection:https://localhost:8080/tfs/DefaultCollection /p:Agile001 /f:"C:\MSF for Agile Software Development v5.0\WorkItem Tracking\TypeDefinitions\SharedStep.xml"

Proceed to Step# 8

Step #8 Run the following command & confirm that there are no catogeries are listed in the ExportCategories.xml file.

C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE>witadmin.exe exportcategories /collection:https://localhost:8080/tfs/DefaultCollection /p:Agile00 /f:c:\ExportCategories.xml

Note

Importing the categories XML file into a project will overwrite all existing categories. Categories that were previously defined but not specified in the file will be deleted.

Proceed to Step# 9

Step #9 Add Categories for Work Item Types by running the following command:

witadmin importcategories /collection:https://localhost:8080/tfs/DefaultCollection /p:Agile001 /f:"C:\MSF for Agile Software Development v5.0\WorkItem Tracking\categories.xml"

You should get the following error:

ISSUE: (This is a MSF Agile Specific issue and **does not** happen with CMMI based team projects)

TF237059: The import of the category definition failed. In the type definition, category Requirement Category refers to a work item type that does not exist User Story.

RESOLUTION:

Open the C:\MSF for Agile Software Development v5.0\WorkItem Tracking\categories.xml

Change:

<CATEGORY name="Requirement Category" refname="Microsoft.RequirementCategory">

<DEFAULTWORKITEMTYPE name="User Story" />

</CATEGORY

To:

<CATEGORY name="Requirement Category" refname="Microsoft.RequirementCategory">

<DEFAULTWORKITEMTYPE name="Scenario" />

</CATEGORY>

Now you should be able to import the category by running the command:

witadmin importcategories /collection:https://localhost:8080/tfs/DefaultCollection /p:Agile001 /f:"C:\MSF for Agile Software Development v5.0\WorkItem Tracking\categories.xml"

Proceed to Step# 10

Step# 10 Modify Work Item Type Definitions

Perform the following tasks:
- Modify the Bug Type Definition
- Modify the Scenario(for Agile) or Requirement(for CMMI) Type Definition

Note: You should take backups of the existing bug and scenario\requirement type definitions before changing & uploading them back to the team project. Upload operation will overwrite the existing type definitions.

To back up the existing bug and scenario\requirement type definitions

Run the following commands:

witadmin exportwitd /collection:https://localhost:8080/tfs/DefaultCollection /p:Agile001 /n:bug /f:"C:\MSF for Agile Software Development v5.0\MyBug.xml"

For Agile team project run:

witadmin exportwitd /collection:https://localhost:8080/tfs/DefaultCollection /p:Agile001 /n:scenario /f:"C:\MSF for Agile Software Development v5.0\MyScenario.xml"

For CMMI team project run:

witadmin exportwitd /collection:https://localhost:8080/tfs/DefaultCollection /p:CMMI001 /n:requirement /f:"C:\ MSF for CMMI Process Improvement v5.0\MyRequirement.xml"

Make copies of the MyBug.xml & MyScenario.xml\MyRequirement.xml

To modify MyBug.xml:

1. Open the C:\MSF for Agile Software Development v5.0\MyBug.xml file in VS

2. Perform the changes documented in the “Modify Bug Type Definition” section in this article and save the file.

Note:

ð Skip the first step which talks about exporting the type. We have already covered it.

ð Under the section "To modify the bug type definition", step 3 there is a missing "<"
From: FIELD name="System Info" refname="Microsoft.VSTS.TCM.SystemInfo" type="HTML" >
To : <FIELD name="System Info" refname="Microsoft.VSTS.TCM.SystemInfo" type="HTML">

ð For the section where the article says delete or replace xml, a suggestion here would be to comment the section that needs to be removed instead of deleting it.

3. Run the following command to upload the changes:

witadmin importwitd /collection:https://localhost:8080/tfs/DefaultCollection /p:Agile001 /f:"C:\MSF for Agile Software Development v5.0\MyBug.xml"

To modify MyScenario or MyRequirement.xml file”:

1. Open the C:\MSF for Agile Software Development v5.0\ MyScenario.xml file in VS

2. Perform the changes documented in the “Modify the Scenario or Requirement Type Definition” section in this article and save the file.
Note:

ð Skip the first step which talks about exporting the type. We have already covered it.

ð For the section where the article says delete or replace xml, a suggestion here would be to comment the section that needs to be removed instead of deleting it.

3. Run the following command to upload the changes:

witadmin importwitd /collection:https://localhost:8080/tfs/DefaultCollection /p:Agile001 /f:"C:\MSF for Agile Software Development v5.0\MyScenario.xml"

To verify the changes:

1. In Team Explorer , right-click your team project, and then click Refresh.

2. Right-click Work Items, point to New Work Item, and then click Scenario.

3. Verify that the new fields and changes to the work item form appear.

Step #11 Follow the instructions in the “Specifying the Bug Type to be Created in Microsoft Test Manager” section of the article.

Run the following command (I saved the bugfieldmappings.xml file to C:\MSF for Agile Software Development v5.0 folder):

tcm bugfieldmapping /import /mappingfile:"C:\MSF for Agile Software Development v5.0\bugfieldmappings.xml" /collection:https://localhost:8080/tfs/DefaultCollection /teamproject:Agile001

Now you should be able to launch the Test Manager & start creating test cases for your TFS 2008 team project.

Summary:

Run the following command once per Team Project Collection:

-- Import Link Types

witadmin importlinktype /collection:https://localhost:8080/tfs/DefaultCollection /f:"C:\MSF for Agile Software Development v5.0\WorkItem Tracking\LinkTypes\TestedBy.xml"

witadmin importlinktype /collection:https://localhost:8080/tfs/DefaultCollection /f:"C:\MSF for Agile Software Development v5.0\WorkItem Tracking\LinkTypes\SharedStep.xml"

-- Fix Errors in Step #7

For TestCase

witadmin changefield /collection:https://localhost:8080/tfs/DefaultCollection /n:"System.ExternalLinkCount" /name:"External Link Count"

witadmin changefield /collection:https://localhost:8080/tfs/DefaultCollection /n:"System.RelatedLinkCount" /name:"Related Link Count"

witadmin changefield /collection:https://localhost:8080/tfs/DefaultCollection /n:"System.HyperLinkCount" /name:"Hyperlink Count"

witadmin changefield /collection:https://localhost:8080/tfs/DefaultCollection /n:"System.AttachedFileCount" /name:"Attached File Count"

witadmin changefield /collection:https://localhost:8080/tfs/DefaultCollection /n:"System.AreaId" /name:"Area ID"

For SharedStep

witadmin changefield /collection:https://localhost:8080/tfs/DefaultCollection /n:"System.IterationId" /name:"Iteration ID"

Run the following command once per Team Project:

NOTE: These command have to be run against the xml files for the process template that corresponds to your team project. I have two team projects Agile001 and CMMI001 based on Agile and CMMI respectively. The folder paths referred in the file paths should be adjusted to C:\MSF for Agile Software Development v5.0 and C:\MSF for CMMI Process Improvement v5.0 based on Agile or CMMI team projects.

**AGILE VERSION**

--ADD WIT TYPES

witadmin importwitd /collection:https://localhost:8080/tfs/DefaultCollection /p:Agile001 /f:"C:\MSF for Agile Software Development v5.0\WorkItem Tracking\TypeDefinitions\TestCase.xml"

witadmin importwitd /collection:https://localhost:8080/tfs/DefaultCollection /p:Agile001 /f:"C:\MSF for Agile Software Development v5.0\WorkItem Tracking\TypeDefinitions\SharedStep.xml"

-- ADD CATEGORY TYPES

witadmin importcategories /collection:https://localhost:8080/tfs/DefaultCollection /p:Agile001 /f:"C:\MSF for Agile Software Development v5.0\WorkItem Tracking\categories.xml"

-- MODIFY THE BUG TYPE DEFINITION

--First export the type
witadmin exportwitd /collection:https://localhost:8080/tfs/DefaultCollection /p:Agile001 /n:bug /f:"C:\MSF for Agile Software Development v5.0\MyBug.xml"

--Make change to type in VS
--Import the changed type

witadmin importwitd /collection:https://localhost:8080/tfs/DefaultCollection /p:Agile001 /f:"C:\MSF for Agile Software Development v5.0\MyBug.xml"

--MODIFY the Scenario or Requirement Type Definition

--First export the type

witadmin exportwitd /collection:https://localhost:8080/tfs/DefaultCollection /p:Agile001 /n:scenario /f:"C:\MSF for Agile Software Development v5.0\MyScenario.xml"

--Make change to type in VS

--Import the changed type

witadmin importwitd /collection:https://localhost:8080/tfs/DefaultCollection /p:Agile001 /f:"C:\MSF for Agile Software Development v5.0\MyScenario.xml"

-- Add bugfieldmapping

tcm bugfieldmapping /import /mappingfile:"C:\MSF for Agile Software Development v5.0\bugfieldmappings.xml" /collection:https://localhost:8080/tfs/DefaultCollection/teamproject:Agile001

**CMMI VERSION**

--ADD WIT TYPES

witadmin importwitd /collection:https://localhost:8080/tfs/DefaultCollection /p:CMMI001 /f:"C:\MSF for CMMI Process Improvement v5.0\WorkItem Tracking\TypeDefinitions\TestCase.xml"

witadmin importwitd /collection:https://localhost:8080/tfs/DefaultCollection /p:CMMI001 /f:"C:\MSF for CMMI Process Improvement v5.0\WorkItem Tracking\TypeDefinitions\SharedStep.xml"

-- ADD CATEGORY TYPES

witadmin importcategories /collection:https://localhost:8080/tfs/DefaultCollection /p:CMMI001 /f:"C:\MSF for CMMI Process Improvement v5.0\WorkItem Tracking\categories.xml"

-- MODIFY THE BUG TYPE DEFINITION

--First export the type

witadmin exportwitd /collection:https://localhost:8080/tfs/DefaultCollection /p:CMMI001 /n:bug /f:"C:\MSF for CMMI Process Improvement v5.0\MyBug.xml"

--Make change to type in VS

--Import the changed type

witadmin importwitd /collection:https://localhost:8080/tfs/DefaultCollection /p:CMMI001 /f:"C:\MSF for CMMI Process Improvement v5.0\MyBug.xml"

--MODIFY the Scenario or Requirement Type Definition

--First export the type

witadmin exportwitd /collection:https://localhost:8080/tfs/DefaultCollection /p:CMMI001 /n:requirement /f:"C:\MSF for CMMI Process Improvement v5.0\MyRequirement.xml"

--Make change to type in VS

--Import the changed type

witadmin importwitd /collection:https://localhost:8080/tfs/DefaultCollection /p:CMMI001 /f:"C:\MSF for CMMI Process Improvement v5.0\MyRequirement.xml"

-- Add bugfieldmapping

tcm bugfieldmapping /import /mappingfile:"C:\MSF for CMMI Process Improvement v5.0\bugfieldmappings.xml" /collection:https://localhost:8080/tfs/DefaultCollection /teamproject:CMMI001

My TFS site was hosted on standard port 8080 on a member server in my Internal testing contoso.com domain.

So I  had created a DNS alias record called “MyTFS” for my TFS server whose NetBIOS names is tfs001.

Now I went into IIS & dropped the default header (port 8080, all-unassigned) for the TFS web site.

I added a new header, port 80, MyTfs, all-unassigned for the TFS web site.

I did a IISReset /noforce. (Note: Make sure you are appending the /noforce switch, sometimse the command errors out. If that happens, keep running IISReset  /noforce again until it succeeds. Without the noforce switch the new host header settings may not be preserved for the TFS site in IIS.)

Then I went in the TFS Admin console & updated my Notfication & Server uris from:

https://tfs001:8080/tfs

to

https://mytfs/tfs

This automatically changes my TSWA site uri to https://mytfs/tfs/web.

Now I edited the web.config file in the root of the TSWA site(which is the “web” folder in TFS install dir) in a text editor such notepad and changed the section:

<tfServers>

      <!-- <add name="https://server:8080" /> -->

    </tfServers>

To:

<tfServers>

<add name="https://mytfs/tfs" />

</tfServers>

I saved & closed the web.config file.

Did an IISreset /noforce.

I am able to browse TSWA site in IE using https://myTFS/tfs/web and use TSWA for any Collection\Project.

Terms: --- TPC= Team Project Collection, TP=Team Project, TFC=Team Foundation Client or Team Explorer  ---

So we know that we can take out RS & WSS from TFS 2010 on-demand. Suppose you have a server in which we used the TFS 2010 advanced configuration wizard to configure TFS minus RS & WSS features. You had a TPC & created a Team Project called Alpha over there. Obviously when you connect to this TP using TFC you will not see a Reports node.

Now we decided to enable reporting for our TFS 2010 instance & we now want our TPC to have reports for our TPs.

So we use TfsMgmt.exe to wire TFS 2010 with an RS instance & we went ahead configured RS & SSAS. We also set the RS folder path in the RS properties for our TPCs to /TfsReports/CollectionName.

So now we go ahead create a new team project called Beta.

What we will see after connecting to both Alpha & Beta team projects is that I now have a Reports node under each of them in TFC.(Very Cool!!)

However the Reports folder under the Alpha project is empty, but the Beta project (which was created after reporting was enabled for TFS 2010 & the concerned TPC) has all the required reports under the Reports folder.

So this is similar to a situation where we have a TFS 2005/2008 deployment & we loose our Reports dbs & we now find that there are no reports for his our Team Projects. So we can use TfsUploadReports tool to get the default reports back.

Put simply we need reports for our Alpha Team Project. You can do this by following instruction which are now available at https://msdn.microsoft.com/en-us/library/ff462695(v=VS.100).aspx.  (Awesome!!)

(A word of caution: please use VS to create the xml file as mentioned in the article, the XML code designer in VS can pick any syntactical errors which can easily happen if you create\edit xml in Notepad)