Query Check-in Policy Overrides

Use the following query to pull back a list of check-in policy overrides.  This works for Visual Studio Team Foundation Server 2010.  The Tfs_DefaultCollection database should be updated to match the name of your team project collection database.

USE [Tfs_DefaultCollection]

SELECT cs.[ChangeSetId], cs.[CommitterId], cs.[OwnerId], cs.[Comment], po.[Comment] AS [Override Reason],
       c.DisplayPart, cs.CreationDate, pf.[PolicyName], pf.[Message]
  FROM [tbl_PolicyOverride] AS po
INNER JOIN [tbl_ChangeSet] AS cs ON po.[ChangeSetId] = cs.[ChangeSetId]
INNER JOIN [tbl_Identity] AS i ON cs.[OwnerId] = i.[IdentityId]
INNER JOIN [Constants] AS c ON i.[TeamFoundationId] = c.[TeamFoundationId]
LEFT OUTER JOIN [tbl_PolicyFailure] AS pf ON cs.[ChangeSetId] = pf.[ChangeSetId]
WHERE cs.[CommitterId] = cs.[OwnerId]
ORDER BY c.[DisplayPart], cs.[CreationDate]

The WHERE clause makes sure the query doesn’t return policy overrides that are created by the build service when committing Gated Check-ins.

jb

New Dallas Team System User Group Website

http://dallasvstsug.ning.com/

The Dallas Team System User Group now has a social network on Ning!  We’ll be using this  as our primary site from now on.  You can keep up with the latest events and RSVP for the group meetings.  We’ve added a forum and already have a few threads out there that may be of interest to you.  You can add a picture to your profile, as well.  This helps us put faces with names so it’s not like we’re all meeting for the first time at each meeting.

There are a variety of RSS feeds to which you can subscribe, as well.  I’ve subscribed to the Latest Activity feed so I know when new members join or there’s activity on the forum.  We’re currently planning to add feeds for significant Team System content from around the web and Twitter posts from the experts.  Let us know what you’d like to see more or less of on the site.  I hope to see you out there.

jb

Fixing Project Portal Search

I discovered recently that searching on team project portals in SharePoint does not work out of the box.  If you try it, you'll most likely get a page with the following message:

"Your search cannot be completed because this site is not assigned to an indexer. Contact your administrator for more information."

If it works in your environment, fantastic!  If not, read on...

The resolution is simple really.  The basic steps can be found in the answer in the following MSDN forum thread:

http://social.msdn.microsoft.com/Forums/en-US/tfsadmin/thread/ffeaedec-7497-4c8c-8c2b-ffa185a949ee/

I verified the initial configuration in two separate test environments (TFS 2008 SP1 with WSS 3.0 SP1) and found the Windows SharePoint Services Search service disabled.  I've had reports of the same issue from environments where they upgraded from TFS 2005 with WSS 2.0.

Running through the SharePoint Products and Technologies Wizard with the default selections gets things configured so that Windows SharePoint Services Search shows up in SharePoint Central Administration | Operations | Topology and Services | Services on Server page.  From there you can start the service and configure the user accounts (I used the TFS service account making sure to include the domain).  When you go look at your content database under Applications Management | SharePoint Web Application Management | Content Databases, the dropdown next to the "Search Server" section should be enabled and contain the name of your server.  Select that and apply the changes.

Be sure to restart the Windows SharePoint Services Search service from the Services MMC snap-in after this.  I did not have to force an additional IIS reset to begin seeing search results.

Why the appropriate configuration isn't applied by the TFS install process is beyond me.  I'd be interested if someone in the know could clue me in.

jb

Notion Tools for Team System Features: Add By Date

You may or may not have heard about the recent release of Notion Tools for Team System.  If so, hopefully you've given it a whirl and seen features that are of value to you and your organization.  If not, you really should check it out; especially since it's free until the end of April.  Rather than leave it at that, I thought it would be helpful to blog about certain features of the tool that I have found valuable.

I'll start off with the "Add By Date" feature of the Notion Timesheet add-in that integrates into Visual Studio 2008.  This features allows me to load the timesheet grid with any work items against which I've recorded time for the currently selected week.  It comes in handy when I need to update my hours on a work item that isn't currently loaded in the grid.  I usually have Notion Timesheet bound to a custom work item query that returns items from a variety of team projects that are assigned to me that have not been closed.  Occasionally, before I've recorded all my time against a work item, it will be assigned to someone else or I'll close it inadvertently.  The "Add By Date" feature lets me quickly retrieve the work item and finish entering my time.  I also use it to go back and check my daily totals.

My projects move pretty fast so work items are always on the move.  The Notion Timesheet "Add By Date" has been a lifesaver on more than one occasion.  Look for more information on cool Notion Tools for Team System features soon.

jb

Injecting Version Numbers Into WiX Projects

I've been meaning to blog about this for a bit. When I responded to someone asking about this very thing on the OzTFS mailing list, I basically crafted the post. So here it is.

I was tasked with making sure the product version number was applied to the deployment package during the release build process. I pored over the problem for a while and found many strange and complex approaches to solving it. Then I had a V8 moment and realized the answer was much simpler than I thought.

I didn't have the burden of persisting the version number in any of my source code because it's date/time driven. I know a lot of people like incrementing revisions that rollover each day, but I gave that up for simplicity. The major and minor values are set statically in the TFSBuild.proj or passed in via command-line arguments. Those values change far less often so this was an acceptable approach. I can even use Error tasks to ensure those values are passed in when doing a release candidate build.

I was already using a regular expression-based FileUpdate task from the MSBuild.Community.Tasks component to update my AssemblyInfo files. I just applied the same technique to update the .wixproj files in the AfterGet target.

<CreateItem Include="$(SolutionRoot)\**\*.wixproj">  

   <Output TaskParameter="Include" ItemName="WixProjectsToVersion" />  

</CreateItem>  

<Attrib Files="@(WixProjectsToVersion)" Normal="true" />  

<FileUpdate Files="@(WixProjectsToVersion)" Regex="SimpleVersion=.*;DetailedVersion=.*&lt;" ReplacementText="$(WixVersions)&lt;" />

This updates preprocessor variables defined in the Property pages of the WiX project as follows.

SimpleVersion=1.0;DetailedVersion=1.0.0.0

The $(WixVersions) property is generated earlier in the build process. As long as it's value ends up looking similar to the following line by the time the FileUpdate task executes, you'll be in good shape.

SimpleVersion=3.5;DetailedVersion=3.5.123.12345

I then used the MSBuild task in the PackageBinaries target to compile the WiX projects. Setting the OutputPath property ensures that the resulting MSI file(s) end up where the rest of the build outputs are.

<MSBuild Projects="$(SolutionRoot)\Setup.wixproj"   

Properties="OutputPath=$(BinariesRoot);Configuration=Release" />

While we're on the subject of build outputs, I should mention a little trick that enables your WiX projects to be built on locally AND on the build server. This next snippet should be self-explanatory:

<!-- Preprocessor directives to conditionally set source paths based on type of build -->  

<?if "$(env.USERNAME)"="s-tfsservice"?>  

   <?define Project1Bin="..\..\..\..\..\..\Binaries\Mixed Platforms\$(var.Configuration)"?>  

<?else?>  

   <?define Project1Bin="..\..\..\some path\bin\$(var.Configuration)"?>  

<?endif?>

A lot of people struggle with the approach of specifying the DefineConstants property override in the <SolutionToBuild> element in their build scripts. The reason this doesn’t work is because those properties and items are all defined when the build is initialized. The dynamic version number hasn't been generated yet.

jb

How To Rename Your Reporting Services Databases

I've installed TFS in more than one environment where Reporting Services is already in use.  The big problem that everyone yells about is that TFS requires a blank RS instance in order to install it successfully.  In case you don't have a spare SQL database instance laying around, a nice workaround is to rename the RS databases from their default names.  This allows TFS to create the new RS databases it requires with the default and you can move on with your life.

Thanks to Bob Coppedge over at Simplex-IT for his original blog post on this.  I was able to follow his steps with some slight variations to rename the Reporting Services databases.

1. Backup the ReportServer and ReportServerTempDB databases you plan on renaming--just in case something goes wrong...which never happens, of course.
2. Stop Reporting Services using the Reporting Services Configuration Tool.
3. Script the stored procedures from the ReportServer database to new query window.
4. In the script, search for and replace CREATE PROC with ALTER PROC (one instance contains two spaces between CREATE and PROC.)
5. Save the script.
6. Rename the ReportServer and ReportServerTempDB databases.
7. Go back to the stored procedure script and search for and replace ReportServer with the new database name (ex. ReportServer to ReportServer-NEW.)
8. Save a copy of the script with a new name.
9. Execute the script.
10. Start Reporting Services using the Reporting Services Configuration Tool.
11. Go to the Database Setup "tab".
12. Click the Connect button and then click OK on the pop-up.
13. Select the new database name in the dropdown list.
14. Click Apply and then click OK on the pop-up.  An error will probably occur when saving the new connection info.  Click Apply again and it should succeed.

Finished!  You should be able to test the reports now.  I would go so far as to recommend this as a best practice.  You could leverage the same database server for multiple RS instances this way.  At the very least, it enables you to install Team Foundation Server against a database server that is already supporting an existing RS instance.

jb

Issues with Reporting Services Permissions

After working with TFS security for the better part of a year, I suddenly ran into a nasty permissions issue in Reporting Services this week.  I'll illustrate the problem using pictures.  When I look at security at the top level in Reporting Services using my tfsSetup account, I see that only the TFS Administrators group has the Content Manager role.  That's good because I don't necessarily want everyone looking at the project reports across the board.

Now I'll drill down into the folder for my team project.  In this case, the team project name is JobBoard.  Here I've broken the security inheritance and given my jobBoardProjectAdmin account the Content Manager role.  The expectation is that he or she will be able to manage security for that folder and any of the contained items without having to bug me.  I'd like to fully delegate that function to the JobBoard Team Project Administrator.

With that set up, let's see if the jobBoardProjectAdmin account has access to view the reports as well as administer security for the JobBoard folder.

Looks like I can see the list of reports but then I click the Properties tab...uh oh!  That doesn't look right.  Reporting Services gives me an error stating "The permissions granted to user 'VSTS2008\jobBoardProjectAdmin' are insufficient for performing this operation. (rsAccessDenied)".  I just gave that account the Content Manager role!  I'll check one of the reports.  Maybe that will work.

Same error.  I can view the report just fine, but I can't edit the permissions.  Argh!

So I do some Googling and really don't find much except for folks talking about giving the user some sort of access at a higher level.  I'd rather not have to do that but if I'm going, I'd prefer to do it once and get it over with.  I'll try giving all Authenticated Users the Browser role at the top level.  This may seem to fly in the face of my earlier statement about not wanting everyone to see all of the projects reports.  However, since I broke the security inheritance for the JobBoard folder, the Authenticated Users group won't have the Browser role at that level.  Only the users explicitly given permissions to the folder will be able to see it.  I'll use that policy going forward so the Authenticated Users approach is okay.

Now I'll I try the Properties tab for the JobBoard folder using the jobBoardProjectAdmin account.  The result:  I can see it AND manage permissions.

Success!...kind of.  Why does this work?  Why does this fix the problem?  Why do I have to do this?  Is this the way it's supposed to work?  I really don't know, but I'll have to live with it for now.  I'm working with SQL Server 2008 here.  The problem can be seen in SQL Server 2005, as well.  If anyone has feedback or ideas about this, feel free to respond.  If you're looking for a solution to the problem in your own environment, the Authenticated Users should work just fine.  You could always use a more specific domain group if you like.

On a side note, during this process I discovered a nice little feature in Visual Studio Team System that I hadn't seen before.  In the Security and Group Membership dialogs that are part of Team Explorer there are these links for SQL Server Reporting Services and Windows SharePoint Services Site Administration at the bottom.  I never paid attention to those until now.  They actually take you straight to the appropriate locations for administering security for those resources.

Interestingly enough, the Reporting Services link takes to you to the Properties tab of the top-level folder rather than the folder for the team project.  Strange...

jb