In preparation for the first meeting of the newly-formed VSTS group, I took some time last week to personally run through the dual-server deployment procedure for Team Foundation Server 2008. Sad to say, little has improved from the 2005 version in way of the installation procedure.
But then again, I wonder how much ought to be hidden to simplify the process.
Installation of Team Foundation Server is complex. One has to be well aware of the various Microsoft technological pieces that make up TFS, split across the two servers (APPTIER for App tier server, DATATIER for Data tier server)
- Active Directory
- SQL Server 2005 database engine
- SQL Server Analysis Services
- SQL Server Reporting Services
- Windows Sharepoint Services 3.0
- Internet Information Services
The administrative responsibilities necessary to manage a TFS deployment cannot be downplayed. Failure to realise how they work together, especially how domain accounts form the credential gel to bind the various processes as one, usually proves to the be hurdle preventing many - especially pure application developers - from achieving a working installation to even begin experiencing VSTS as it was designed and intended.
As with common wisdom from TFS 2005 experience, following the installation guide to the letter helps a lot. And so I did. However, there was one section How to: Install SQL Server Reporting Services in a Dual-Server Deployment that did not sit well with me, quoted below (emphasis mine)
To install SQL Server 2005 Reporting Services by using the installation wizard
-
Log on to Windows using an appropriate domain account (for example, TFSSETUP) for Team Foundation Server.
-
Insert the installation DVD for SQL Server 2005 Enterprise Edition or Standard Edition.
-
On the SQL Server 2005 Start page, click Server components, tools, Books Online, and samples.
-
On the End User License Agreement page, review the license agreement. If you accept the terms and conditions, select the I accept the licensing terms and conditions check box, and then click Next.
-
On the Installing Prerequisites page, click Install.
-
After installation of the prerequisites, click Next.
The Microsoft SQL Server Installation Wizardstarts.
-
Click Next.
-
On the System Configuration Check page, perform any required actions, such as restarting the server, and then click Next to start installation.
-
On the Registration Information page, complete the registration information, and then click Next.
-
On the Components to Install page, select the Reporting Services check box, and then click Next.
-
On the Instance Name page, click either Default instance or Named instance. If you clicked Named instance, type the name of the instance. Click Next.
-
On the Service Account page, click Use the built-in system account, and then click Network Service. In Start services at the end of setup, select the Reporting Services check box, and then click Next.
-
On the Report Server Installation Options page, make sure that Install but do not configure the server is specified, and click Next.
Team Foundation Server will configure the report server for you.
-
(Optional) On the Error and Usage Report Settings page, select one or both check boxes to specify where information about errors and feature usage should be sent, and then click Next.
-
On the Ready to Install page, review the list of components to be installed, and then click Install.
The Setup Progress page shows the status of each component.
-
After installation has completed, click Next.
-
Click Finish to close the wizard.
NETWORK SERVICE account? On the APPTIER server? How is that supposed to appear to the DATATIER server? According to Microsoft, with this setup, the computer DOMAIN\APPTIER$ account would be used when the SSRS service connects over to the database at the DATATIER server. The DOMAIN\APPTIER$ account is automatically provided the necessary privileges to access the SSRS databases. So no worries. Until the TFS setup program throws the error
Error 29112. Team Foundation Report Server Configuration: Either SQL Reporting Services is not properly configured, or the Reporting Services Web Site could not be reached. Use the Reporting Services Configuration tool to confirm that SQL Reporting Services is configured properly and that the Reporting Service Web site can be reached, and then run the installation again. For more information, see the Team Foundation Installation guide.
A quick check with the Event logs revealed that ANONYMOUS was the credential being passed to the database, which obviously is going to fail authorization.
Event Type: Failure Audit
Event Source: MSSQLSERVER
Event Category: (4)
Event ID: 18456
Date: 11/02/2009
Time: 10:55:34 AM
User: NT AUTHORITY\ANONYMOUS LOGON
Computer: DATATIER
Description:
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. [CLIENT: 192.168.1.25]
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 00004818 0000000e 0000000d 00460054
0010: 00320053 00300030 00570038 00410044
0020: 00410054 00070000 006d0000 00730061
0030: 00650074 00000072
For reasons not properly discovered, the computer account is not passed through in my environment. Which means the TFS installation cannot complete in my scenario. Which means nothing to play with at all, unless I manually descend to fix the underlying authentication problems. At this stage, I left the error dialog box open for the moment to carry out the following changes
- Assign the RSExec role to DOMAIN\TFSService in the ReportServer and ReportServerTempDB databases at the DATATIER server.
- Add DOMAIN\TFSService as a member of the SQLServer2005ReportServerUser$APPTIER$MSSQLServer group in the APPTIER server.
- Modify the SQL Server Reporting Services (MSSQLServer) Windows service in the APPTIER server (Computer Managment) with the service account DOMAIN\TFSservice (which is running the AppPool for the TFS web services) instead of NETWORK SERVICE.
- Restart that Windows service.
With that I click Retry on the dialog box and it got passed this error. And within a few moments of happy database access, got pounced by the second-level boss
Error 28806. An unexpected error occurred. Verify that SQL Server Reporting Services is installed and running on the Team Foundation app tier and that you have sufficient privileges to access it. For more information, see the setup log.
This time round, it is the SSRS web service, not the Windows service, that is putting on a mask. Looking at the IIS ReportServer AppPool sure enough turns out as NETWORK SERVICE for its identity.
- Assign DOMAIN\TFSservice as the ReportServer AppPool identity.
- Add DOMAIN\TFSservice as a member of the SQLServer2005ReportServicesWebServiceUser$APPTIER$MSSQLServer group in the APPTIER server.
With that I click Retry on the dialog box and it got passed this error. I felt some odd feeling of deja vu.... before yet another boss jumped into the path preventing me from saving my princess.
Error 28805. The setup program cannot complete the request to the server that is running SQL Server Reporting Services. Verify that SQL Server Reporting Serivces is installed and running on the Team Foundation app tier and that you have sufficient permissions to accept it. For more information, see the setup log.
On visiting the SSRS management site at http://localhost/Reports the following error was eager to greet me
The Report Server Web Service is unable to access secure information in the report server. Please verify that the WebServiceAccount is specified correctly in the report server config file. (rsAccessDeniedToSecureData)
Indeed, it seemed Microsoft is quite bent on using NETWORK SERVICE to operate the entire chain of SSRS configurations, which was simply not working in my case. I have had to manually reconfigure every step of the way
Appearing to have slain the last dragon, the TFS installation dialog finally completed successfully. Happy I managed to counter-deceive the setup program to make SSRS work, I visited the default Sharepoint site at http://localhost/
Cannot connect to the configuration database.
What's the problem now - Sharepoint as well? Yes, you guessed it correct - NETWORK SERVICE was the culprit again.
-
In the APPTIER server, open up Administrative Tools and launch SharePoint 3.0 Central Administration. This should bring up IE accessing http://localhost:17012 , which should be default address for the Sharepoint Central Administration site.
-
Click on the Operations tab, then click on Service Accounts under the Security Configuration section.
-
In the Service Accounts page and the Select the component to update section, choose the Web application pool radio option with
-
Under the Select an account for this component section, select Configurable radio option and type in DOMAIN\TFSservice as the user name, with its password.
-
Click OK to persist this setting.
Once the Sharepoint web application identity is synchronised with the rest using the same domain service account, its access to the configuration database was resolved. In looking around, I am definitely not alone with this problem. It seems Microsoft has missed out on something important that prevents certain environments or servers from installing with the "ideal" credentials - the computer account - and really offers little in the installation procedure to fix the problems. I relied heavily on my past experience with SSRS and AD setup to get around this. From what I have observed, there are still other DCOM permission errors showing up, but those have to be dealt with another day.
UPDATE 17 Feb 09
The DCOM errors turn out to be related to Sharepoint: Event ID 10016
The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID {61738644-F196-11D0-9953-00C04FD919C1} to the user DOMAIN\TFSservice SID {...} The security permission can be modified using the Component Services administrative tool.
This happens because the DefaultAppPool identity got changed to DOMAIN\TFSservice, which was previously NETWORK SERVICE. From Sharepoint's installation procedure, it was not prepared to have DOMAIN\TFSservice run its process. In order to modify IIS WAMREG Admin Service (the CLSID referred to above), follow the instructions illustrated at
http://www.sharepointassist.com/2009/01/27/61738644-f196-11d0-9953-00c04fd919c1-launch-permissions/