Team Foundation Server

HintPath and Team Build

2008-08-29T13:47:00.000-07:00

Very long week so I've got to keep this short. For some reason when a developer added a Reference to his csproj file it didn't add a <HintPath. The build worked locally and it worked on the build machine when we ran the build manually through Visual Studio. However, when trying to run the build via Team Build, we got the error "Could not resolve this reference. Could not locate the assembly." We could see that when Csc.exe was called, our Reference was not referenced.

The fix was to add a <HintPath to the csproj file. After doing that, Team Build ran fine and we could see it added to the Csc.exe Reference command line. I didn't get time to figure out why, but thought I'd document it here for when it happens again.

Source Control Cache Hits on our server.

2008-08-12T08:18:00.000-07:00

I enjoy reading Grant's blog. In this Cache Hits post, he shows how to get your Cache Hit Ratio.

We're currently hitting our local Source Control cache 96.06% of the time. What are your numbers? I'm interesting in comparing.

Using $(WebProjectOutputDir) in the *.csproj file's PostBuildEvent

2008-08-11T12:13:00.000-07:00

A colleague of mine wanted to add a PostBuildEvent in their *.csproj file which would run a custom executable to create generated java script files.

The change (see BEFORE below) worked locally as the path they wanted the generated was $(ProjectDir) which mapped to the .\Sources directory on the build machine and their locally directory within their IDE. The issue was, we needed the generated files to be under .\Binaries on the build machine which didn't exist on their machine. More specifically, we needed this generated file created under $(OutDir)_PublishedWebsites\$(MSBuildProjectName) on the build machine which translates to .\Binaries\_PublishedWebsites\$(MSBuildProjectName).

What we ended up doing was, instead of using the $(Outdir) property, we used the $(WebProjectOutputDir) which was set in the $(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets file. Using this value allows the output directories to be correctly set on both the build machine (where we want to use .\Binaries) and $(ProjectDir) where we want to use the locally structure.

BEFORE:
"$(TargetDir)JavascriptFromMvcRoutes.exe" "$(TargetDir)$(TargetFileName)" "$(ProjectDir)js\Generated.js"

AFTER:
"$(TargetDir)JavascriptFromMvcRoutes.exe" "$(TargetDir)$(TargetFileName)" "$(WebProjectOutputDir)js\Generated.js"

TSWA Profile > Options Not Staying

2008-08-07T11:19:00.001-07:00

A colleague of mine tracked down an issue where all users' TSWA Profile > Options were not staying after they closed the browser. For example, a user would change their Theme to Olive, but after they closed their browser it would default back to the default.

We're not sure if this is the right fix, but we had to change permissions on the D:\Program Files\Microsoft Visual Studio 2008 Team System Web Access\Web folder so that "Users" had Modify permissions. Users are now able to change their Options and they stick.

Question Marks "?" on files in Teamprise

2008-08-01T14:29:00.000-07:00

A colleague of mine summoned me over to his desk. He had question marks "?" on all the files he checked out from the Teamprise Plug-in and was wondering why.

Typically I see files with question marks on them when the user has changed the file permissions without checking the file out. Teamprise, not knowing what the status of the file is (as I would expect), labels the file with a small question mark indicating that something has changed, but its not sure what. Or something like that.

However, in this case the user had promised me the files were checked out. He had the Pending Changes to prove it.

I did a quick search and after digging through a couple of my old posts, I found Martin's post Teamprise V2 Preview 2 where he discusses better off-line support. It's here he states "When you next connect, all the read/write files will have a little question mark on them inside Eclipse."

Now the user is using Teamprise 3.0, but my thought is this "question mark" behavior was not changed until 3.1, which by the way is what I’m using. He's been having a number of network issues so my guess is that his network connection was dropped thus resulting in Teamprise 3.0 to go into "off-line" mode. Once he was back online, he would have needed to run "Team > Synchronize" to synch back up with the server. This is exactly what we did and the question marks were changed back into check-marks indicating check out.

I couldn't reproduce this as I think Teamprise changed the behavior in 3.1. If I get sometime next week, I'm going to rollback my Teamprise version to 3.0, check out some files, drop my network connection and see if I can reproduce the error. Or more likely, simply upgrade him to 3.1!

Bug in TFS 2008: "TF50605: There was an error looking up the SID for "

2008-07-24T08:01:00.001-07:00

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.

"Waiting for version updates to finish..."

2008-07-24T08:01:00.000-07:00

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.

Why some files don't get pushed to TFS drop location.

2008-07-23T06:42:00.000-07:00

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.

Analysis Services hung on Data Tier

2008-07-11T09:50:00.000-07:00

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.

Odd Security issue on Windows 2008 Server running IIS 7.0

2008-07-01T11:59:00.000-07:00

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)

Bug in TfsAdminUtil Status

2008-06-30T08:27:00.000-07:00

While practicing hardware moves for both the App Tier and Data Tier, we're making use of the TfsAdminUtil command. We've had some issues with this tool. Mainly around really bad error message reporting. It seems like you can get the error "ERROR: TF55020: Could not access database." for any number of reasons. No other help is provided (e.g. "Check to make sure the Team Foundation Server App Pools and Site are up and running"). I'll try to gather some of the possible causes and solutions when I get some more time.

While trying to track down the root cause of this error, we made use of the "Status" switch. Below is what came back. You can see that Status says no Windows services are running as our TFSReports account. However, in the window you can see that "SQL Server Reporting Services" most certainly is running as TFSReports. I think this might be a bug in the tool, which given the poor error message handling, would not surprise me.

Ant and TFS 2008

2008-06-20T11:20:00.000-07:00

Yesterday estrada pinged me on how we build Java projects in TFS 2008. If you remember, I wrote an article a while back (about a year ago) on how we did it with TFS 2005.

My current group has written a custom MSBuild task to call Ant scripts. I would prefer to use Teamprise Build Extensions, but I joined this group late and they had already had much of the infrastructure written. We do some custom things like write writing Junit tests back to TFS. I don't believe Teamprise Build Extensions has that functionality though I could be wrong.

Anyway, my recommendation for calling Ant scripts with TFS 2008 would be to use Teamprise Build Extensions. The setup instructions are great and it's a nice, easy, way to get setup and running.

Let me know how it goes!

"Windows SharePoint Services version 2 templates are not supported in this version of the product."

2008-06-11T11:42:00.000-07:00

Today a trusted colleague of mine tried to create a new Team Project in TFS 2008 using the eScrum process templates. We've created around 10 of them in the past with the eScrum process template and everything went fine. Today however, which happened to be a day I'm off sick due to a nasty cold, we get the error "Windows SharePoint Services version 2 templates are not supported in this version of the product." Now why we're getting this now and not in the past, I'm not sure. Something must have changed, or the eScrum template got corrupt on the server. Not sure which is more probable.

After pounding my head against the wall, I ran into "Mike's Blog" (a great read if you have some time) where he gives one solution to our error. Here is my summary.

1) Did all the steps under Step 1), except bounced IIS, of Mike's article. Here were my commands when deleting and uploading the site template.

stsadm -o deletetemplate -title eScrum
stsadm -o addtemplate -filename C:\eScrum.stp -title eScrum

2) I also downloaded the eScum process template, saved the eScrum.stp to .eScrum\SharepointTemplate overwriting the one loaded, and uploaded the new process template labeled as "eScrum with WSS 3.0". To be honest, I'm not sure if this is needed but I did it anyways.

3) Tried to create Team Project called "Vertical Static Content" with new upload I called "eScrum with WSS 3.0" and it worked!

NOTES: During some experimentation, we got this error ""Plugin error text: “TF30272: Template not found on the server”" when trying to create a Team Project after deleting the eScrum template and before adding it back again. This leads me to believe there is something, other than what's in the Process Template, which needs to be on the server when creating Team Projects. Why? I can't understand.

Changing TFS Build Agent to look at a different TFS Server

2008-06-02T14:44:00.000-07:00

Just because I continue to forget; if you need to change the TFS Server for your TFS Build Agent, change the add key="AllowedTeamServer" value="http://tfs.mycompany.com:8080/" element in the C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\tfsbuildservice.exe.config file. Then bounce the TFS Build Agent via Services.

We have seen some instances where this change does not take affect right away. We even bounced the agent more than once with no affect. Oddly enough, when we got back from lunch everything was working. My assumption is that the agent uses a cache and that was not getting refreshed. Either that or heading to lunch fixes most everything ;).

CSS change for rendering Reporting Services correctly in FireFox

2008-06-02T14:15:00.000-07:00

Our FireFox users are having an issue with Reports rendering in a small scroll like box. They can only see the first two inches of a report and must scroll down to see the rest.

From what I can tell, a number of people are having this issue. If you search for "Reporting Services in FireFox" the first hit you get is Jon Galloway's post where he describes making the following CSS change.

/* CUSTOM CHANGE BY <My Company Name>: Fix report IFRAME height for Firefox */

.DocMapAndReportFrame {
min-height: 860px;
}

I ran a few test reports after making this change and I think it's going to work for us for now.

Adding an Organization Hierarchy in Team Build

2008-05-29T11:56:00.001-07:00

We really like Team Build. Especially Team Build 2008 which has the continuous integration ability. However any good product can always be improved.

To the left you'll see a screen shoot of one of our Team Projects and the builds under it. You can't see them all but there are 42 build definitions setup. Having them all in a flat view can be a bit overwhelming. Adding the ability to group these build types would be very cool. For example, the DownloadServlet builds might be under a folder called \Team Builds\DownloadServlet. Builds that run the Unit tests could be grouped as well.

The feedback I'm expecting is, why didn't we just break these out into separate Team Projects. Separate Team Projects would build the organization that I'm suggesting. While valid, we have hundreds if not thousands of "applications" to support. Most of them are supported by sub-groups in the company. For example, the applications behind these build types are all worked on by one group. We find it easier to group the applications together in one Team Project instead of all having autonomous Team Projects. We do the same for other groups and it works very well.

What are your thoughts? Would adding the ability to "group" build types be advantageous for other teams?

Bounce IIS after re-stamping your TFS Databases with InstanceInfo.exe

2008-05-27T08:40:00.000-07:00

We saw an interesting scenario today after restoring our TFS PROD instance to a TFS QA environment for testing. Even though we changed the Instance ID for each database (see here for instructions), the App Tier was still rendering the old Instance ID for the TfsVersion control database. This was causing the Source Control view to continue to look at the PROD server even though it said "QA". All other databases were rendering with the new Instance ID.

If you're not familiar with the Instance ID, let me take a second to explain it. The Instance ID is basically a GUID (globally unique identifier) for the TFS databases. While you may refer to the TFS Server as tfs.mycompany.com, your client software (e.g. Team Explorer) prefers to use the GUID.

From what Grant Holiday says, basically what happens is your client will send the URL (e.g. tfs.mycompany.com_ to the server's Registration.asmx web service to get the GUID (e.g. 2dbgh947-049b-7z6c-94y2-4b0767ggf790). Once the client has the GUID it will use that for future communication.

In our case, we properly changed the GUID using the InstanceInfo.exe utility and directions in this forum. However, the App Tier must have been caching the TfsVersionControl GUID as both PROD and QA were responding with the same GUID name, even though the database GUID was restamped. Here are the PROD and QA sections of our VersionControl.config file stored under %USERPROFILE%\Local Settings\Application Data\Microsoft\Team Foundation\2.0\Cache. Interesting enough, the repositoryGuid would stay the same, but the uri would change when we switched TFS Servers. Bad!!!

ServerInfo uri="http://tfsqa.mycompany.com:8080/" repositoryGuid="2dbgh947-049b-7z6c-94y2-4b0767ggf790"
ServerInfo uri="http://tfsprod.mycompany.com:8080/" repositoryGuid="2dbgh947-049b-7z6c-94y2-4b0767ggf790"

The fix was to bounce IIS on the QA App Tier. This reset the App Tier cache and thus resolved our issue. The lesson learned here is to bounce IIS after you re-stamp your TFS databases with new GUIDs.

Team Build's 'Get' always writes files with the current date

2008-05-15T12:50:00.000-07:00

We use Team Build for all of our builds including the packaging of our Static Content application. When Team Build does a 'Get' of Sources it writes the files with the creation/modify date of the current build time. For example if I checked in a file (e.g. Mac.jpeg) yesterday (5/14/08), but didn't run a Team Build until today, the file date would be today (5/15/08). For most things this is not an issue, but for Static Content it is.

The reason having the current date/time on Static Content is an issue is because of the way the browser caches things. When a request is made to our site(s), the browser will see that we have images (e.g. Mac.jpeg). Before grabbing the image from the web server the browser will check its local cache. If the image in the local cache has the same modify date as the image on the web server, the image is not requested, thus improving performance. However, if the local cached version of the image file is older than the web server's version, the new image is sent to the requested user.

The issue is, because Team Build always writes the files with the current date (e.g. 5/15/08), when we deploy them to the Static Content servers they all look like updated image files. This is bad as it invalidates ever user's cache and thus slows down our application as every image is sent to the user.

I've read a bunch of things on this and from what I've heard, the TFS Product Team might be looking into a fix for this. I've dropped our local Microsoft rep a note asking him if he had any details about that. I've also found this post from Cory Foy which looks like a custom task we might be able to write in order to get the behavior we need. If I get any word back from my Microsoft contact, I'll let everyone know. In the mean time, we are looking into Cory Foy's approach.

I'm also going to drop a note to the good folks over at Teamprise to get their input. We're using their Ant interfaces to TFS for some of our non-Microsoft builds and thus could have a similar issue.

Bug in the TFS 2008 Uninstall on Standby App Tier

2008-05-08T10:58:00.000-07:00

A colleague of mine, who has taken over many of my former TFS duties, ran into an interesting problem today. For reasons I won't get into, we were trying to uninstall TFS 2008 from our Standby App Tier.

The error we ran into was as follows. We found this error in the VSMsiLog which is created for installs and uninstalls.

05/08/08 11:35:14 DDSet_Status: --- STATUS: Found Reports.ReportsService=http://tfs.mycompany.com/ReportServer/ReportService.asmx
05/08/08 11:35:14 DDSet_Status: --- STATUS: Writing VSTF_RS_SERVER=tfs.mycompany.com into C:\Documents and Settings\appwesttfnqasetup\Local Settings\Temp\TfsCurrentConfig.ini section Config
05/08/08 11:35:16 DDSet_Error: *** ERROR: Failed to call WMI on the RS server. The most likely cause is that the firewall is blocking WMI calls or that the RS server is not reachable: The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)
05/08/08 11:35:16 DDSet_Status: Process exited with exit code: 16

05/08/08 11:35:16 DDSet_Error: GetCurrentTfsProperties failed with exit code: 16
MSI (s) (B4!A4) [11:35:22:083]: Product: Microsoft Visual Studio 2008 Team Foundation Server - ENU -- There is a problem with this Windows Installer package. Please refer to the setup log for more information.

You'll notice that the uninstall was looking for the value ReportService which is found in the TfsIntegration database's tbl_service_interface table. The value in that table is a FQDN which we use because we have Primary and Standby App Tiers. As defined in the TFS documentation, only one is active at a time.

The Bug in the uninstall is, if you are setup behind a FQDN the value of ReportService will be the FQDN (e.g. tfs.mycompany.com) instead of the value of the Standby App Tier, which is what you're trying to uninstall.

A quick Google search led me to this blog post by Nick Berardi on his Coder Journal. He ran into a similar issue during an upgrade. He got around the error by changing the ReportService value to match his App Tier.

While I never recommend messing with the TFS databases, being we're in a QA environment I gave Nick's idea a shot. Sure enough, the uninstall finished successfully. I then changed the value back to our FQDN so the Primary App Tier could be functional.

I'm not sure why the uninstall would need these values for Reporting Services. From what the uninstall documentation says, you must uninstall Reporting Services (and Share Point) as an independent step? Anyway, again while I never recommend manually changing values in the TFS databases, we ended up needing to as to get around the uninstall issue.

Deployment to IIS 7.0 using Power Shell

2008-05-01T08:47:00.000-07:00

Yes, I'm still here. Sorry for not writing anything lately on TFS. I've been in one of those two week Agile (with a capital A) "Iterations" which is when we get all the work done.

I don't really have anything important to share right now on our TFS adoption. Everything is going pretty good. Knock on wood!

While not really related to TFS though, I've fallen in love with Power Shell 1.0. Everyday I find another problem to solve with "commandlets" and all the great things a full featured shell offers. Along with the AppCMD command which ships with IIS 7.0, we're using Power Shell scripts to drive our deployment mechanism. Here is a simple example of what our scripts look like. It's actually working very well for us and far less overhead than creating an msi or Install Shield package.

You'll notice that we take the nuke and pave approach to deployment. That is, we check to see if the application directory is there, and if it is, we purge it. Then we copy over the new application version's code.

#Always get the script root. Per Microsoft's recommendation, each script should know their respected script root.
$SCRIPT_ROOT = Split-Path (Resolve-Path $myInvocation.MyCommand.Path)

#check to see if these values are already set. If not, set them to defalts.
if ($ENV_SITE_NAME -eq $null) {sv ENV_SITE_NAME -value Website}
if ($ENV_APPPOOL_NAME -eq $null) {sv ENV_APPPOOL_NAME -value WebsiteAppPool}
if ($ENV_PORT_NUMBER -eq $null) {sv ENV_PORT_NUMBER -Value "8080"}

sv APPCMD -value $env:systemroot\system32\inetsrv\AppCmd.exe
sv SITE_INSTALL_PATH -value "D:\Web Sites\$ENV_SITE_NAME"
sv APP_SERVICES -Value "aspnet_state", "W3SVC"
# ***************************************************
# Step 1)
# Clean up old install.
Invoke-Expression "$APPCMD delete site $ENV_SITE_NAME"
Invoke-Expression "$APPCMD delete apppool $ENV_APPPOOL_NAME"
if (Test-Path $SITE_INSTALL_PATH) {rmdir -Recurse -Force $SITE_INSTALL_PATH}
# ***************************************************# Step 2)
# Make dirs
New-Item $SITE_INSTALL_PATH -type directory
# ***************************************************
# Step 3)
# Create the AppPool for this site
Invoke-Expression "$APPCMD add apppool /name:$ENV_APPPOOL_NAME"
Invoke-Expression "$APPCMD set apppool /apppool.name:$ENV_APPPOOL_NAME /processModel.identityType:NetworkService"
# ***************************************************
# Step 4)
# This will add the site on port 81. This does not create an App or Virtual Director by default. *****
Invoke-Expression "$APPCMD add site /name:$ENV_SITE_NAME /bindings:`"http/*:${ENV_PORT_NUMBER}:`""
# ***************************************************
# Step 5)
# Craete App with the physical path and set the Apppool we need ******
Invoke-Expression "$APPCMD add app /site.name:$ENV_SITE_NAME /path:/ /physicalPath:`"$SITE_INSTALL_PATH`" /applicationPool:$ENV_APPPOOL_NAME"
# ***************************************************
# Step 6)
# Copy over files recursively (/E and /I), overwrite read only files (/R), surpress comfirmation (/Y), quietly *****
echo "Copy Files to WebSite"
xcopy $SCRIPT_ROOT\Website $SITE_INSTALL_PATH /E /I /R /Y /Q
# ***************************************************
# Step 7)
# Make sure any needed services are started before finishing and spits out their status.
Invoke-Expression "$APPCMD start apppool /apppool.name:$ENV_APPPOOL_NAME"
Invoke-Expression "$APPCMD start site /site.name:$ENV_SITE_NAME"
$APP_SERVICES Start-Service
$APP_SERVICES Get-Service
# ***************************************************
# Step 8)
# Make sure we didn't get any errors at deployment.
if ($error.count -lt 1)
{
Write-Output "" "Deployment Successful!" ""

}
else
{
Write-Output "" "Deployment Failed!" ""
$error
Write-Output ""
}

Follow-up on our Restore Attempt(s)

2008-04-15T13:21:00.000-07:00

Two weeks ago today I left the building frustrated with Microsoft because of poor documentation. You can see my rant here.

I'm still a bit miffed that the "How to restore..." document was (and still is as of this writing) wrong, but I'm feeling better that they have graciously apologized to me. And the fact that with the help of Support, we're up and running in the restored test environment. Being I'll most likely forget, here are the steps we had to do to get this test restore environment up and running.

First support walked through the steps 1 - 14 of "Restore and Test SQL Report Server, Reporting Services, and Default Reports" BEFORE we did "Rename the Team Foundation Data-Tier Server and Activate the Team Foundation Application-Tier Server" AND "Move User and Service Accounts" section. Why? I'm not sure if I understood the reasoning.

Second, support did the following steps on the App Tier and Data Tier once I handed over support with Easy Assist.

1) App Tier: Before they ran RenameDT, they changed the ReportSever AppPool identity from NetworkService to the TFSReports account.
2) App Tier: They ran RSKeyMgmt.exe –d which deleted all encrypted data on the server
3) App Tier: They ran RSKeyMgmt.exe –r on the GUID from the initial install of TFS on this new hardware. Somehow this GUID gets re-added?
4) Data Tier: Opened up the tbl_database table in the TfsIntegration database and changed all the ‘servername’ values to the new Data Tier.
5) Data Tier: Opened the tbl_service_interface in the TfsIntegration database and changed ReportsService and BaseReportsURL to have the new App Tier name.
6) In Reporting Services Configuration, they made sure that the TFSReports account was used instead of a built in account.

After they did all this, the RenameDT worked. Like my first point, I'm not sure I understood why they did all this and if it was all really needed.

Third, after "Rename the Team Foundation Data-Tier Server and Activate the Team Foundation Application-Tier Server" we did the "Move User and Service Accounts" section. All this worked just fine.

Fourth, this wasn't really related to the restore per say, but we did have to give the AppTier\Users group Read, List, Read & Execute on the c:\Program Files directory. Without this, the only users that could log in where those who were members of the AppTier\Administrators group. I'm not sure if this is correct, or why the TFS install didn't set it up for us? When I compared this test restore hardware with our current PROD hardware, the current PROD hardware was configured with AppTier\Users have that access to c:\Program Files so we just mimicked the behavior and it all worked. UPDATE: We also had to give AppTier\Users Full Control access to %Program Files%\Microsoft Visual Studio 2008 Team System Web Access\Cache.

Fifth, we finished steps 15 - 29 of "Restore and Test SQL Report Server, Reporting Services, and Default Reports". This all worked fine.

Sixth, and lastly, we changed the Instance ID so that we didn't have the same Instance ID for both our current PROD hardware and our test restore hardware. See this full forum for how to do this.

After all this, we currently have a test copy of our current PROD system restored so we can play around with it.

What is needed to write complex Reports

2008-04-09T09:20:00.001-07:00

There have been a number of people asking me what they need to install in order to get up and running with report writing using the "Business Intelligence Development Studio". Here is what I send them.

1) Install Visual Studio 2005. This step is optional.

2) Install "Microsoft SQL Server 2005 Express Edition Toolkit" which gives you the "Business Intelligence Development Studio (BIDS)"

3) Read Buck's blog and download the attached documentation to get your data sources setup and an initial report written.

4) Obtain a PHD in Computer Science if you have to write any MDX queries.

IE 6.0 crashes with Share Point 3.0

2008-04-08T13:18:00.000-07:00

Some of our users have had IE 6.0 crash on them (intermittently) while opening up documents from Share Point 3.0. While the error messages don't exactly match, they are similar to what's described in Steve's post.

I followed up with the users and it seems that Steve's fix, fixes their issues with IE crashing.

Thanks Steve for posting your find!!!! I'm hoping it will get me a free beer at the bar.

Cannot create a connection to data source 'TfsOlapReportDS'. (rsErrorOpeningConnection)

2008-04-03T06:40:00.000-07:00

If you ever see an error like below when trying to render a Report in TFS, make sure MS SQL Analysis Services is started under Control Panel > Services. Since we're running a duel server install, our MS SQL Analysis Service is running (or not running when we get this error) on the Data Tier.

An error has occurred during report processing. (rsProcessingAborted)
Cannot create a connection to data source 'TfsOlapReportDS'. (rsErrorOpeningConnection)
For more information about this error navigate to the report server on the local server machine, or enable remote errors

Frustrated with "How to: Move Your Team Foundation Server from One Hardware Configuration to Another"

2008-04-01T13:12:00.000-07:00

Nothing frustrates me more than when documentation is wrong or misleading. Case in point: The document "How to: Move Your Team Foundation Server from One Hardware Configuration to Another" explaining how to move TFS from hardware to hardware is probably one of the worst written documents I've ever read. Here are just a few of my observations.

- We've bombed out at "To rename the Team Foundation data-tier server". The first issue was that a small, yet critical, detail is left out of the document. It's missing the statement explaining before running TfsAdminUtil RenameDT you must modify the Service's web.config, making sure the connection string on the new server is referencing the old server. The Community Content says this at the bottom and also the "Microsoft Visual Studio 2005/.NET Framework 2.0" says it. So why doesn't the master document for TFS 2008 say this? If you fail to do the rename, the command comes back and says "data tier name not changed."

- Even after getting past this, we are still stuck though. According the support, we actually should do the "Rename the Team Foundation Data-Tier Server and Activate the Team Foundation Application-Tier Server" and "Move User and Service Accounts" AFTER we do other things like "Restore and Test SQL Report Server, Reporting Services, and Default Reports" which is two sections BELOW "Move User and...". What? If this is true, which we're verifying with our field rep, why does the document have them out of order? How can someone expect to know this?

- Lastly, the support rep (who was actually very helpful by the way), said that you basically have to disconnect the old TFS server when you do the migration. Meaning, you basically can't do a test restore on some QA hardware before you have to come in on a weekend to do the same steps on a live PROD system. We're checking with our field rep to make sure this is accurate, but if it is, which I'm praying it's not, where in this document does it state that you must disconnect the old system before doing the restore based move?

Sorry for my rant. I just get so frustrated when documentation is wrong or misleading.