Can't TFS data tier "share" an existing data tier?
Like everyone else, I'm trying to get a TFS set up (do you think you could make it any more difficult?!). At any rate, we were going down the path of a dual-server deployment.
+ We already have SQL Server 2005 server w/ SP1 running on a W2003 R2 (virtual) server.
+ I have also already installed the SQL Server Reporting Services databases already on that SQL server box as we intend to use RS in general for our various web development projects. Only the RS databases were installed on this SQL box using the Files only, do not configure option during the SQL setup process. I have another (virtual) web server where our custom ASP.NET web projects and RS's Report Server and Report Manager components are deployed.
+ We will be setting up TFS's application tier on its own (virtual) server separate from the SQL Server and Web servers.
+ We added Analysis services to the SQL Server server as that seemed to be a requirement for TFS, althought I was not intending to use AS at this time.
+ Now, finally getting back to installing the data tier components of TFS, the TFS setup is complaining:
<------>
Description
SQL Server 2005 Reporting Services service is installedWorkaround / Remedy
SQL Server 2005 Reporting Services service is installed on the data-tier computer. The service should instead be on the application-tier computer. Uninstall SQL Server 2005 Reporting Services service from the data-tier computer and run setup again.<----->
So, I guess my question is can't TFS take advantage of an *existing* SQL Server server with RS databases on it?
Answers
You should be able to do what you want, although we strongly recommend that v1.0 not share a SQL instance. We definitely will block if we see RS on the data tier. This has to do with RS existing on multiple boxes. SQL Std only allows one RS to be active at a time, while Enterprise doesn't. And if the DBs, etc already exist then ACLs, keys, etc. become an issue. You could uninstall RS and clean up your RS databases, install TFS and then come back later and put RS on the data tier. Not to say you won't have issues (e.g., std vs ent), etc. but you should be able to move forward. But again, we aren't recommending this solution.
As for AS, the TFS Warehouse depnds on this for managing cubes, etc. and it is a pre-req.
marc
p.s. I'd be interested in understanding your "more difficult" comment. We are working on the next release and would like to better understand the pain points.
All Replies
You should be able to do what you want, although we strongly recommend that v1.0 not share a SQL instance. We definitely will block if we see RS on the data tier. This has to do with RS existing on multiple boxes. SQL Std only allows one RS to be active at a time, while Enterprise doesn't. And if the DBs, etc already exist then ACLs, keys, etc. become an issue. You could uninstall RS and clean up your RS databases, install TFS and then come back later and put RS on the data tier. Not to say you won't have issues (e.g., std vs ent), etc. but you should be able to move forward. But again, we aren't recommending this solution.
As for AS, the TFS Warehouse depnds on this for managing cubes, etc. and it is a pre-req.
marc
p.s. I'd be interested in understanding your "more difficult" comment. We are working on the next release and would like to better understand the pain points.
I've got to agree with the first comments. We're a small development shop and we have a single database server with three SQL instances - SQL 2005 in-house apps (e.g. Dynamics GP, etc...), SQL 2005 development, SQL 2000 development. We're looking to re-use our SQL 2005 in-house apps instance for TFS Workgroup Edition. I'm stuck with the same issue as above where we have a RS instance deployed on the database server for our various applications to share.
While it's great to say that you recommend not to share a SQL instance I don't think that is practical in smaller environments. Sure, I could spark up a Virtual Server instance but there is unnecessary duplication of resources with that approach. I've seen this "single box for a single app" mentality with other apps (e.g. the SharePoint PSS folks saying that residing on an Active Directory server isn't fully supported) and I think it's poor excuse. The better response would be to try and understand what is preventing it from residing on the same server. For example, I'm curious what the real reason is that the TFS install guide says "Team Foundation Server cannot be installed on a domain controller and does not support installing other servers such as Exchange Server or Host Integration Server on the same computer".
As Marc outlined if Reporting Services doesn't support multiple instances in SQL Server Standard Edition then it should be all the more important for the TFS team to move away from the "we want a dedicated environment" thought process. Not everyone has a few billion in the bank to buy new servers with.
I guess we'll stick with our Subversion deployment until TFS resolves this issue in a supported fashion.
Cheers,
Colin
