Thursday 26 June, 2008 (.Net | Bugs | Fixes | Team System)
We have just had a major Active Directory issue that has affected the Team Foundation Server instance that all the developers at the client that I am working at use. The problem occured when some users where erased in the Active Directory and were subsequently recreated with the same user names. These new user accounts cannot access the Team Foundation Server.
A large part of the problem was solved by just removing users from TFS and then putting them back in again. This recreates all the wiring under the surface in TFS so that the users can access the server but all their existing workspace info, pending checkins and so on are lost locally yet exist in Team Foundation Server with a different Owner under the same user name... The only way to tell them apart is by their SID and that the original account may get suffixed with a number in workspace lists: AD\username:61.
My first thought was to remove all the workspaces and pending checkins and let people manually resynch their projects. When I clicked undo pending change for a bunch of changes in Attrice Sidekicks an unhandled exception popped up: "Object reference not set to an instance of an object". I just can't undo these changes, there is a clue to the problem when I try to unlock a changed file, I get an Unlock error:
Failed to unlock $/Project/Path/file (TF14061: The workspace COMPUTERNAME; AD\username does not exist.)
I can't search for workspaces by username either, even doing a simple TFSSecurtiy /i "ad\username" /server:TFSName for one of the affected accounts returns "Error: The identity cannot be resolved." Since the original accounts have been removed from Active Directory I cannot easily get hold of their SIDs for querying with TFSSecurity. Attempting to delete the workspaces from the command line return the following error:
TF14061: The workspace WORKSPACENAME;AD\username does not exist.
Things seemed pretty messed up... I found some clues as to what was required to get things working again:
http://support.microsoft.com/kb/948679
http://support.microsoft.com/kb/823278
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=454060&SiteID=1
According to the KnowledgeBase articles trying to create a new project while TFS is in this state may result in the following error:
TF30170: the plugin Microsoft.ProjectCreationWizard.WorkItemTracking Failed during task WITS from group WorkItemTracking
Basically Team Foundation Server has a bug that causes deleted accounts to not be resynched correctly and SharePoint doesn't handle recreated user accounts at all - you have to resynch them manually. Unfortunately in addition to this there is a bug in TFS SP1 which prevents TfsAdminUtilI from correcting the SIDS! You get the following error:
ERROR: Could not access database.
In the end I managed to correct all the problems, here are the steps required:
- Contact Microsoft Support and request the hotfix for http://support.microsoft.com/kb/934216
- Install the hotfix...
- Follow the steps in http://support.microsoft.com/kb/948679 to resynch the users SIDs in TFS
- Follow the steps in http://support.microsoft.com/kb/823278 to resynch the users in SharePoint
- Recycle the TFS App Pool to force an update of all users and groups in TFS.
Look out with users who have their workspaces mapped to "c:\documents and settings\" the new user accounts cannot necessarily access their old files there since they now log on with a new account (which just happens to have the same name).
Tuesday 09 January, 2007 (.Net | Team System)
Download the sample code.
I have tried different methods to move work items from one Team Foundation Server to another. The easiest method is doing it with Excel, but the problem is that I also want to keep all the work item history which Excel cannot do.
I found that the Revision property of each work item contains an array of complete copies of the work item as it appears at each revision. So iterating over each revision in order allows us to recreate each version that was saved! By setting the system time to the time of the original revision we can recreate a work item including all its changes, provided that we execute the code on our server so that the date changes are reflected when the work items are saved. An added bonus of iterating over each revision and saving them is that all the state changes are legal so we don't need to figure out how to get our work item to it's final state if we have complicated state transition rules.
If we execute our updates as a different user than the one that made the changes originally then each history entry will be tagged as "Edited by XXX on behalf of YYY". Unfortunately it appears that project reports are not updated with the historic data, all the new work items will be added to the reports the day that you import them.
The following code illustrated how I have copied almost all of the basic data from work items using revisions (unfortunately indentation was lost when I copy/pasted the code):
foreach (Revision r in wi.Revisions)
{
foreach(Field f in r.Fields)
{
if(f.ReferenceName == CoreFieldReferenceNames.ChangedDate)
{
System.Diagnostics.Debug.WriteLine(f.Name + " : "+ f.Value);
//Copy revision date
System.DateTime revDateTime = (System.DateTime)f.Value;
revSysTime.wDay = Convert.ToUInt16(revDateTime.Day);
revSysTime.wHour = Convert.ToUInt16(revDateTime.Hour);
revSysTime.wMilliseconds = Convert.ToUInt16(revDateTime.Millisecond)
revSysTime.wMinute = Convert.ToUInt16(revDateTime.Minute);
revSysTime.wMonth = Convert.ToUInt16(revDateTime.Month);
revSysTime.wSecond = Convert.ToUInt16(revDateTime.Second);
revSysTime.wYear = Convert.ToUInt16(revDateTime.Year);
}
if(f.ReferenceName != CoreFieldReferenceNames.History
&& f.ReferenceName != CoreFieldReferenceNames.WorkItemType
&& f.ReferenceName != CoreFieldReferenceNames.TeamProject
&& f.ReferenceName != CoreFieldReferenceNames.Id
&& f.ReferenceName != CoreFieldReferenceNames.IterationId
&& f.ReferenceName != CoreFieldReferenceNames.IterationPath
&& f.ReferenceName != CoreFieldReferenceNames.AreaId
&& f.ReferenceName != CoreFieldReferenceNames.AreaPath
&& f.ReferenceName != CoreFieldReferenceNames.CreatedBy
)
{
if(!f.IsComputed && f.IsValid)
{
destItem.Fields[f.Name].Value = f.Value;
}
}
}
System.Collections.ArrayList arrl = destItem.Validate();
if(arrl.Count > 0)
{
//Handle validation errors
}
else
{
GetSystemTime(ref currentSysTime);
SysTimeNeedsReset = true;
if(SetSystemTime(ref revSysTime) == 0)
{
throw new ApplicationException("SystemTime was not set!");
}
destItem.Save();
if(SetSystemTime(ref currentSysTime) == 0)
{
throw new ApplicationException("SystemTime was not reset!");
}
SysTimeNeedsReset = false;
}
}
You can download the code to the minimal WinForms app that I have created for copying work items here. The code is provided as-is with no guarantees or support...
Things that are not handled at all are: user mappings if the source and destination server have different users, area and iterations, links and attachments. There may be more things that are missing or don't work that haven't affected my setup.
Tuesday 09 January, 2007 (Team System | Tips)
I have had several discussions with people I work with about where to put your documents when using Team Foundation Server. Obviously there are several places to put documentation depending on what sort of document it is. There are at least three places that make sense to me:
- In the SharePoint Portal
- In the Version Control repository
- As attachments on Work Items
Each of these places has their advantages and disadvantages. I have found two interesting blog posts on one by Jason Barile and one by Jeff Atwood. For me I only use Work Item attachments for documents that have no project-historic value and only cover a single work item. Screen shots for bugs is a classic example. Anything that is scoped to more than a single work item or might be of value for new project members as background material or details of why the system has been built the way it is must be stored somewhere more visible.
The Version Control repository is great for code, but for me I really don't want to see documentation in there for two reasons. All project members might not have Team Explorer installed. That means that anything that is placed under source control is effectively hidden to project members who don't work in Visual Studio. In addition the documents might not be fully visible to project members who do use Visual Studio since generally we map up our Solutions and projects and get the latest version through the IDE integration in the Solution Explorer not by using the Source Control Explorer. So if someone creates a new folder in Source Control that is not part of one of the projects that I am working on then I generally won't see it straight away. The SharePoint Portal has two advantages visibility and accessibility. All the documents are clearly visible in one place (Documents and Lists) and in addition we are not restricted to documents we can also use lists and WebParts to display additional data like reports and external links to help project members understand whats going on in addition to just getting hold of the right documents. Users who want to find information aren't required to have Visual Studio installed and configured they only need a browser to get hold of the documents.
- Use the SharePoint Portal for info that needs high visibility.
- Use the Version Control repository for code.
- Use Work Item attachments for documents that only relate to a single work item.
Thursday 23 November, 2006 (Bugs | Team System)
I have been attempting to run a Team Foundation build server on a separate machine outside our domain. Install and connectivity between the servers was no problem but once we got the build configuration up and tried to perform a build from Team Explorer we got an error:
TF42056: The build service could not connect to the Team Foundation Server: TF30063: You are not authorized to access https://myserver.
I tried all our standard solutions:
- Set https://myserver as local intranet in Internet Explorer security settings.
- Stored username and password in the control panel applet.
- Cached username and password in Team Explorer
The IDE works perfectly but nothing works when we run Team Build, it turns out that this is an unsupported configuration due to the Team Build service not picking up locally configured alternate credentials. It's a known issue in v1 for some of the command line tools. So far there doesn't seem to be a workaround that could fix this, perhaps SP1 will add alternate credential support for all the command line tools.
These MSDN forum threads didn't really help us but might help others with non-domain related issues:
https://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=380144&SiteID=1
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=20644&SiteID=1
UPDATE:
I continued searching for info on this and found http://msdn2.microsoft.com/en-US/library/ms400712(VS.80).aspx#:
The Team Foundation client is in a workgroup instead of a domain, but Team Foundation Server is deployed in a domain. Local user accounts must be created on the Team Foundation client computers. If you do not want to require users to type a user name and password every time that a Team Foundation client must connect to Team Foundation Server, make sure that the local user accounts use the same user name and password as the domain user names. For more information, see Managing Team Foundation Server in a Workgroup.
I couldn't get a local workgroup account set up so that it mapped to a domain account but I attempted a completely local configuration which did work even though my Team Foundation Server is set up in a domain:
- Create a local build user account (tfsbuilder) on the Team Foundation server.
- Add the tfsbuilder account to the Build Service TFS group for your project, this has to be done through Team Explorer on the TFS server since clients can't add local accounts to the TFS server.
- Create a local build user account (tfsbuilder) on the build server.
- Give the tfsbuilder account all required permissions. I'm not sure which they are but I added the user to the Power User group and this works.
- Change the logon account for the Team Build Service to you local tfsbuilder account also giving the user log on as service permission.
- Restart the team Build Service.
- Kick off a build from your client and things should work smoothly!
The same solution should work for all command line tools using the "run as" start method.
Friday 17 November, 2006 (SharePoint | Team System)
I am looking at the steps necessary to move projects between two Team Foundation Servers where both servers have existing projects setup. The lack of information on how to do this on the Internet and forums indicates that this is not something that is easy to accomplish. We have selected the server which we have customized as the target machine and luckily the other server has a default installation of TFS on it so we don’t need to synchronize any of our own customizations.
I found a post on the Team Foundation Server forums which basically says MS will be looking at this but that there is no existing solution.
I also found a listserver mail archive which indicated that source control and work item history may be lost in the transfer.
At the moment I have a couple of working theories depending on what is possible through the extensibility API available at the VSIP site.
The simplest solution
- Manually create the Team Project
- Upload all the documents to SharePoint manually
- Use Work Item Utility, Mark Browns code for work item shallow copy or Excel to copy work items.
- Get the latest version of items in source control, unbind from the server and then check into the new server and rebind.
A complex solution
- Manually create the Team Projects
- Upload all the documents to SharePoint manually
- Adapt Work Item Utility (http://www.gotdotnet.com/codegallery/codegallery.aspx?id=b29d4456-c4ba-474e-a422-0479471776e1) to copy the history of all items if it is possible.
- Develop a tool (or find one on the internet) that gets every version of all the files in source control and checks them in with their original dates to the new server.
The second solution is better because we would like to keep all the history but I have a feeling that it may be difficult, maybe even impossible to keep history. Buck Hodges has posted a source control API sample and I believe that this could be modified to get existing code history and check it in to a different server. For the history to be persisted in the new server the CreationDate of the PendingChange objects that are checked in would need to be modified and the server would have to trust the date in the pending change from the client over its own date (unlikely). The super complex solution is to run the tools on the server and modify them so that the server’s date and time is changed between each check in to get them to occur at the right point in time! Probably a lot of work...
Wednesday 15 November, 2006 (SharePoint | Team System | Reviews)
I got a question from one of my many readers 
wondering why I didn't think that TeamPlain was right for me. Since this is a topic that I was planning on writing about I put together a list of my gripes! Unfortunately I haven't had time to try out Teamprise yet which is a related technology, but if I ever get around to it I will definitely write about it here too.
Don't get me wrong I think that TeamPlain is a great piece of software, I would really like to be able to use it but I have some issues with it. I work as a consultant on smallish custom development projects (2-10 developers) for clients who are usually not that technically savvy. Projects normally range from a couple of weeks to a year or so (although some are a lot longer). We also work quite a lot off-site and on multiple projects in parallel, so having a web and web service based interface to Team Foundation Server is great for us. Best of all most of the features that we as developers need is built into the product more or less out of the box. The value that TeamPlain could offer us is giving our clients, project managers and general executive types easy access to more parts of TFS than they get through SharePoint.
Problems that I see with TeamPlain for us
- When opening documents via TeamPlain they are not opened via SharePoint and cannot be updated to the SharePoint document library. SharePoint is web based also so we could just have connected to the SharePoint site instead.
- Reports can be accessed via SharePoint just as well as with TeamPlain, ok you don't get the nice looking drop-downs with a list of reports. On the other hand the reports are web based so users can connect to the report server instead.
- The integration with Source Control is read-only so it is only useful for non-developer access to source control. We don't want non-development artifacts stored in source control; they should be stored on the SharePoint site or in the wiki, so we have no use of this feature.
- There is no SharePoint integration, so you have to choose if you go in through SharePoint or the TeamPlain entry point. Since we also have a wiki this means we actually have to choose between three entries instead of having one big Project Dashbord with the status of the entire project and quick access to all areas. We have implemented a quick fix for our wiki by putting it inside a WebPart on the SharePoint site, we could do the same with TeamPlain but I don’t believe that this is optimal.
- There is no API for interacting with or modify TeamPlain nor is it possible to use parts of the TeamPlain GUI in other Web Apps or from within SharePoint. The license explicitly prohibits users from modifying TeamPlain.
Features that would make me look at TeamPlain again
- SharePoint integration so I could give users access to the features in TeamPlain that I want through WebParts. Then each Project could customize their views depending on their specific needs.
- Floating user licensing for the lite edition since we only really need the work item editing capabilities for our clients at the moment.
- Some form of feature customization or extensibility, partly just for the sake of it (I am a developer after all) but also because I believe that customizable products will always be more useful.
Wednesday 15 November, 2006 (.Net | SharePoint | Team System)
Unfortunately it will not be possible to upgrade Team Foundation Server to Windows SharePoint Services 3 when it is released, see Jason Bariles blog for more info. This feature will not be added in the upcoming Service Pack (SP1) either. So for the time being we will all just have to make do with WSS 2 features and add any additional functionality that we need through TFS extensibility and custom SharePoint features. 
Thursday 09 November, 2006 (SharePoint | TechEd 2006 | Team System | Scrum | FlexWiki)
I have been working with Visual Studio Team System since the public Beta came out so the possibility of customizing, reconfiguring and extending Team System was not new for me. Unfortunately I am slightly disappointed with the content of this White Board Discussion since I have been looking forward to hearing how others are implementing Team System, I was expecting more information and tips on actually getting management buy-in and best practices for process adoption. We are in the middle of rolling out Team System for our Microsoft development projects so I know that the real value of Team System can only really be realized when you customize your setup. But at the same time it was good to hear that the work that we are doing thinking about how to customize Team System and our Team Foundation Server setup is what others also are thinking about.
Right now the state of our setup is the following:
- Team Foundation Server setup with SSL over multiple dns names. This was no trivial task since there was no official documentation for setting up TFS with SSL when we did this. Now there is a step-by-step guide on MSDN http://msdn2.microsoft.com/en-gb/library/ms242875.aspx. Additionaly you need to “hack” your IIS and TFS configuration if you want it to work. Perhaps I will get back to this in a future post.
- ScrumForTeamSystem (http://www.scrumforteamsystem.com/). Since we have a couple of projects that use Scrum it made sense to have a process template that supports Scrum.
- TeamPlain Web Access (http://www.teamplain.com/). We are still evaluating this and although it works quite well, I am not sure that it is right for our use.
- FlexWiki (http://www.flexwiki.com/). I have come to love Wikis for simplifying and reducing the friction to start writing documentation of our systems. We have integrated FlexWiki into our SharePoint portal sites by simply adding a Page Viewer WebPart with a large height.
- SharePoint hotfix 915746 (http://support.microsoft.com/kb/915746). Without this hotfix you cannot add new Web Parts to you portal sites.
New features that we are looking at implementing:
- Custom Process Templates and work items. We have a project on our Team Foundation Server for Team Foundation Server customization (almost a meta project).
- Implementing some ideas from Trac (http://trac.edgewall.org/). Mainly a changelog WebPart for aggregating a change history for our WorkItems, source code, portal documents, Wiki pages. This could probably be implemented as an RSS aggregator.
- One-stop dashboard in Sharepoint for a quick overview of the state of everything in our project.
- RSS feed for changes to make it easier for developers to participate in different parallel projects.
Technorati tags: TechEd-Developers
Disclaimer
The opinions expressed herein are my own personal opinions and do not represent
my employer's view in any way.
Sign In