Here is a Bug we found in TFS 2008. At least I think it's a Bug. It happens when you try to delete (or perform other workspace actions) on a workspace owned by a user who no longer is in Active Directory.
1) Create an AD account and use it to log into TFS 2008, create workspaces and check out files.
2) Then, leaving some files checked out such, delete the account in AD. This is what happens when someone leaves your company.
3) Go back to TFS and try to delete their workspace. E.g. tf workspace /delete /server:http://tfs.int.mycompany.com:8080 Z055638-XPA;Z055638 *where Z055638 is the user who left the company.
4) You should get the error "TF50605: There was an error looking up the SID for Z055638" which to me means since the account can't be found in AD (the user left the company) you can't delete their workspace and thus can't "undo" any files they have checked out.
To resolve this, we had to manually update the TfsVersionControl, Tbl_Workspace table. Cameron Vetter's post gave us the idea. We changed the OwerId field to a valid user for that workspace. The we were able to delete it.
Not ideal, but worked for us. I've submitted this to Connect as well.
Thursday, July 24, 2008
Bug in TFS 2008: "TF50605: There was an error looking up the SID for "
Posted by Mac Noland at 8:01 AM 5 comments
"Waiting for version updates to finish..."
Last week we noticed a colleague's Teamprise hanging at the end of a Get Latest Version. The message was something along the line of "Waiting for version updates to finish...". Unfortunately on my local machine, everything worked as expected. Typical I guess.
Anyway, I was playing around with the VPC image developers (and the person having trouble) use and noticed that *.tfs.mycompany.com* was not listed in the Eclipse proxy exclusion list. It is my belief, if *.tfs.mycompany.com* is not added, you'll also get the strange "Waiting for version updates to finish..." behavior, and possibly other network related issues. In addition, Teamprise has a good article titled TKB00021 Diagnosing Common Connection Problems that also provides help with connection issues.
To properly set your proxy settings in Eclipse, you can go to Window > Preferences > General > Network Connections and add *.tfs.mycompany.com* to your "No Proxy for:" host list. There is also a short cut in Teamprise if you hit a wall during the initial Import.
Posted by Mac Noland at 8:01 AM 0 comments
Labels: Teamprise
Wednesday, July 23, 2008
Why some files don't get pushed to TFS drop location.
Yesterday I got a question about why *.dat files were not being added to the ./Binaries folder during a Team Build, and thus not pushed to the TFS drop location. The *.dat files are used by a third party software we use to track browser requests.
After digging around a bit, we found that the *.dat files were added to the .NET 3.5 C# web project with the element <None. Other files part of this third party were added as <Content.
...
<Content Include="Views\Browse\ItemControl.ascx" />
<None Include="bin\bhawk_sp.dat" />
...
A very intellectual developer in our group (not me) found out that the *.dat files were added with "Build Action" defaulted to None. To change this, I believe he Right Clicked on the file > Properties > and changed the Build Action to Content.
Now the *.dat files get copied over to the ./Binaries directory and pushed to the Drop Location.
Posted by Mac Noland at 6:42 AM 0 comments
Friday, July 11, 2008
Analysis Services hung on Data Tier
While looking at our TFS 2008 Data Tier today I noticed that the msmdsrv.exe resource (i.e. Analysis Services) was using 99% of the Data Tier CPU. I knew that when the OLAP processing happened, the Data Tier process would spike. But this spike was consistent. Something was wrong.
When running the GetWarehouseStatus web service (i.e. http://localhost:8080/Warehouse/v1.0/warehousecontroller.asmx?op=GetWarehouseStatus) we got "ProcessingOlap". Typically this takes a minute or two for us. Oddlly, we were getting this status for over an hour (though I'm sure it was happening for a while longer than that).
We figured the process was hung and wanted to restart it. We have about 150 users on the system so we didn’t want to recycle IIS as it would drop users. So instead of recycling IIS on the App Tier, we shut down the Analysis Service on the Data Tier. This brought the Data Tier CPU usage back to normal.
Then to test things out, we invoked the data warehouse update (using the Run web service). When the OLAP processing ran, the Data Tier process neared 100% a number of times (as expected). After about a minute, the process finished and the Data Tier was back in good standing.
We're not sure what to take away from this, but it's something we'll have to monitor.
Posted by Mac Noland at 9:50 AM 0 comments
Tuesday, July 01, 2008
Odd Security issue on Windows 2008 Server running IIS 7.0
To be honest, I can't make sense of this error or it's resolution. However, I wanted to write it down incase we ever run across it again.
My project team has the first Windows 2008 servers in the data center. This means that if something goes wrong, everyone gets to stair back at us saying "why in the heck did you guys adopt this new OS so fast." And true to form, something did go wrong. We started getting the error "The server encountered an error processing the request. The exception message is 'Access is denied.'" when performing some actions (of which I'm not 100% sure as another sub-group wrote the code) in a Web Service running under IIS 7.0.
We knew this had to be some kind if security issue so we went through the standard steps. Oddly enough, our Data Center contact (who is a Microsoft Wizard) stumbled on a resolution where he added "Network Service" to the local Administrators group (this was a last resort). As we kind of expected, this resolved the error. He then removed "Network Service," as having it in the local Administrator group would be stupid, and rebooted. We expected the error to come back. Nope, that seemed to fix "it." We repeated this on one other machine and magically it fixed it as well.
We're not sure why this works. We continue to laugh about it and just hang our heads low.
The server encountered an error processing the request. The exception message is 'Access
is denied.'. See server logs for more details. The exception stack trace is:
at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object
[] inputs, Object[]& outputs)
at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage4(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage3(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage2(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage1(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)
Posted by Mac Noland at 11:59 AM 3 comments