Ah it's spring and we're still plugging away on getting TFS installed on our DEV environment. In TFS's defense most of the big delays are big company bureaucracy. That being said, installing TFS is not as easy as installing MS Word on my grandmother's PC. Here are some of the issues we ran into and the resolutions. I've also included some big company standard deviations we did. By big company standard deviations I mean things like our system administrators make us install "third-party" software on the D: drive instead of the C: drive. I can't imagine the number of hours upper management spent on that decision.
First a bit of background. From what I can tell our company supports Windows based servers with two groups. For this discussion let's call the database group the "DBAs" and the system administrators "Sys Admins." Upper management actually refers to them as something totally different, but the average sane person can't understand upper management's terminology (or thought process for that matter). The DBAs and Sys Admins work like this: In the morning the DBAs get coffee on the second floor, Sys Admins the fourth. DBAs go out to lunch at 11AM. Sys Admins eat at their desk around noon. DBAs drink Diet Coke, Sys Admins drink regular Pepsi. To an outsider one could conclude the two groups try to avoid each other at all costs. Thus, it's with these two groups we must coordinate the temperamental TFS install.
- The DBAs like to use a standard company SQL install image for all data tier machines. Unfortunately the big company image does not include Integration Services and Analysis Services. Apparently we're the first team that needs such "advanced technology." Lesson number one, don't install a base SQL 2005 64-bit image on a cluster and then expect to install Integration Services and Analysis services afterwards. After three days working with Microsoft, our DBAs gave up and re-installed SQL 2005 64-bit with Integration Services and Analysis Services selected on the initial install. I'm not sure why adding these two components after the cluster is setup is such a big deal, but the amount of vulgar language the DBAs used it must be a big deal.
- Our DBAs have "Big Company Approved" Reporting Services install instructions that includes "Configuration." We had the DBAs do the basic install with their instructions, then tackled them before they could run through the "Configuration" section. From what we're told, the TFS install does the configuration for us.
- We installed the TFS App Tier software to the d: drive. That is a requirement from the Sys Admins. No big deal here.
- Here is a big one. The entire datacenter has some kind of "flash copy agent" software running on port 8080. Conventional wisdom would lead you to believe one can simply change the TFS msiproperty.ini to some other port (e.g. 8888) and install TFS. There I go again thinking conventional wisdom is logical. Changing the misproperty.ini file resulted in the following error: "Error 28925.TFServerStatusValidator: Calling the Team Foundation Server ServerStatus Web service failed. Additional details about the problem can be found in the setup log. Verify your network configuration. For more information on troubleshooting this error, see the Microsoft Help and Support Center. Log file: TFServerStatusValidator - Team Foundation Server Status Validator tool (C) Copyright 2006 Microsoft Corporation. All rights reserved." The details are outlined in my forum posting (http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1411189&SiteID=1&mode=1). After giving up and calling Microsoft, the support folks from India had the Sys Admin shut down the agent software running on 8080, install TFS to port 8080, step through a number of manual steps which included making a database change to switch URL values from 8080 to 8888 (steps are in my forum posting above), restart all TFS related applications/services, and finally start the flash copy agent software back up on 8080. The look on our Sys Admin's face after all this was priceless!
- Since our DBAs don't let the Sys Admins on the database machines and vice versa, we had some trouble installing the App Tier. From what we found out, the TFSSetup account used to install the App Tier needs to be a local administrator on the App Tier and a member of the local administrator group on the Data Tier. After bringing in a United Nations negotiator, we got the DBAs to "temporarily" add the Sys Admin's TFSSetup account to the local administrator group on the Data Tier. The install went fine after that.
- The TFS administrator (i.e. me) won't be a local administrator on either the App Tier or Data Tier. That would be against company policy. So we followed the three sections outlined by Microsoft (http://msdn2.microsoft.com/en-us/library/ms253096(VS.80).aspx) and added our team's group name to the appropriate locations in TFS, SharePoint, and SQL Reporting Services. Amazingly this seems to work just fine.
- Lastly we had to add the TFSReports user to the local administrator group on the App Tier to get around the error "The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID {BA126AD1-2166-11D1-B1D0-00805FC1270E} to the user NT AUTHORITY\NETWORK SERVICE SID (S-1-5-20). This security permission can be modified using the Component Services administrative tool." The end user error was "Reporting Services Error --- An error has occurred during report processing. (rsProcessingAborted) Get Online Help Cannot impersonate user for data source 'TfsOlapReportDS'. (rsErrorImpersonatingUser) Get Online Help Logon failed. (rsLogonFailed) Get Online Help For more information about this error navigate to the report server on the local server machine, or enable remote errors --- SQL Server Reporting Services." Being the install instructions say "This account should not be an administrator on Team Foundation Server computers" I'm pretty sure this is not correct. However at the time of this posting, no one from Microsoft can give us any guidance on better way to get Reporting Services to work. I'll keep this forum (http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1345776&SiteID=1) updated if we ever figure out a better way to handle this.
