Team Foundation Server - Setup, Administration and Operations Blog

Removing an Admin Console User with DBO Permissions

2013-05-01T22:10:00Z

In TFS 2012, you may notice you're unable to remove an Admin Console User who is the SQL database owner (dbo). This is usually the user who initially installed and configured TFS. In this scenario, you will select an Admin Console User in the Admin Console and click the link to "Remove" them, but the user will not actually be removed despite seeing a "Success" message for the removal. Even after restarting the Admin Console, you will see that the user you tried to remove is still an Admin Console User.

This behavior occurs because:

1) Your SQL Server always needs there to be someone with dbo permissions for each database in order to run

2) TFS requires that an Admin Console User has these permissions so that an admin in the deployment has rights to alter all TFS-related data

If you would like to remove an Admin Console User who is dbo, you must first reassign the dbo role to a different Admin Console User. Since the dbo role gives users such elevated permissions in SQL, TFS will not automatically choose a new dbo for you.

To reassign the dbo role, open SQL Management Studio and change the db owner in the "Files" page of the database properties dialog. Remember, the person you move dbo permissions to must also be an Admin Console User.

After you have done this, go back to the TFS Administration Console and try the removal again. This time, it should succeed.

TF255146: Team Foundation Server requires SQL Server 2008 R2 (10.50.1600) or greater.

2013-04-29T15:02:00Z

While trying to configure a 2012 version of Team Foundation Server Express or Basic, you may hit the following error message during the Readiness Checks:

TF255146: Team Foundation Server requires SQL Server 2008 R2 (10.50.1600) or greater. The SQL Server instance A5100854\SqlExpress you supplied is version ??.??.???.
Cannot assign a default value to a local variable. Must declare the scalar variable “@BackupCompressionDefault”.

Unfortunately this error message does not provide very helpful or precise information, and you may not be sure what you need to do to get past it. The message has been improved in the next release of TFS. Until then, please consult one of the 2 possible scenarios below for information on how to unblock configuration of TFS 2012.

Scenario 1: Configuring with the TFS Basic wizard

If you're configuring with the Basic wizard, the error message means that you provided a SQL Server instance that is too old to be upgraded automatically or used in place with TFS 2012. When the version number shows up as "??.??.???" it means the instance is SQL 2005 or earlier, and TFS requires at least SQL Server 2008 R2. In this situation you have several options. You can:

Return to the previous page in the wizard and select a new SQL instance to configure TFS with.
Manually upgrade the instance you chose to SQL 2008 R2 or higher.
Uninstall the instance you chose. TFS configuration can then install a newer version of SQL Express for you to use with TFS.

Scenario 2: Configuring with the TFS Express wizard (aka the "New Server" wizard)

If you're configuring with the Express wizard, the problem is a bit more complex. You will still see the error message in cases where the SQL instance being used for configuration is too old to be upgraded automatically or used in place with TFS. However, in the Express wizard there is no option to choose a particular SQL Express instance to configure TFS against. TFS Express can only be configured with a SQL Express instance named "SQLEXPRESS," which is the default SQL Express instance name. Any other instances of SQL Express on your server will be ignored. Therefore, you can have an outdated version of SQL called SQLEXPRESS and also a newer, usable version of SQL with a different name, and configuration will still be blocked. Your options for unblocking configuration on your server are to:

Upgrade your SQL Express instance (the one named SQLEXPRESS) to SQL 2008 R2 or higher.
Uninstall the instance named SQLEXPRESS so that TFS Express can install a fresh instance of SQL Express 2012 with the same name.

We hope this post is helpful to anyone who runs into this problem.

TF400371, TF14045 | Configuring Proxy in an Untrusted Domain

2013-04-15T19:55:00Z

If you are running TFS 2012 RTM, Update 1, or Update 2 and are trying to configure a proxy machine in an untrusted domain, you will find that the configuration process blocks this previously supported scenario with the following errors:

TF400371: Failed to add the service account 'TFSPROXY\TFSProxy1' to Proxy Service Accounts Group. Details: TF14045: The identity with type 'System.Security.Principal.WindowsIdentity' and identifier 'S-1-5-21-4198714966-1643845615-1961851592-1024' could not be found..

Fortunately, there is a workaround that will help you get Proxy back up and running. Please follow these steps:

If you are on TFS 2012 RTM or Update 1, you will need to upgrade to Update 2.
Once you are on Update 2, you will need to join your proxy server to TFS by placing it in a workgroup during configuration
After configuration is complete, move your proxy server back into the untrusted domain. Please be sure you continue to follow the guidance around shadow accounts closely.

We apologize for the inconvenience and will be including the fix for this bug in Update 3.

TF255455: SQL Server Reporting Services is configured to require a secure connection. However, no HTTPS URL is configured with a valid certificate.

2013-03-19T19:20:00Z

If you are seeing this error, it means that your Reporting Services instance was set up to require a secure (SSL) connection, but for some reason your configuration does not meet all the requirements for SSL. Reporting Services will not work correctly until you've ensured you meet all the requirements for SSL (a real, valid certificate; a matching machine name; etc.) or you've reduced your connection security requirements.

In the most common scenario, there was for some reason already a (invalid) certificate on the machine that made an SSL assumption when Reporting Services was installed, so it set up HTTPS and set a SecureConnectionLevel of 2. This can be any certificate in the local store with the purpose set to * (anything) or server authentication. When TFS detects that SecureConnectionLevel=2, it requires that the user use HTTPS; however, if the certificate doesn't work, HTTPS will fail. The best way to fix this is to change the Reporting Services config file to set the SecureConnectionLevel to 0 - ie, do not require a secure connection - instead of 2. The steps are as follows:

Open the rsreportserver.config file, which is usually located in %Program Files%\Microsoft SQL Server\MSRS10.<instancename>\Reporting Services\ReportServer\
Search for the line that reads <Add Key="SecureConnectionLevel" Value="2">
Change it to <Add Key="SecureConnectionLevel" Value="0">, and save the file.
Restart setup.

If you did intend to use a certificate but find that it isn't working, please check that the name the certificate applies to exactly matches the name of the server you are trying to connect to. Note that certificates will not recognize when a local name and fully qualified domain name belong to the same machine, so if you are trying to connect to Reporting Services using the local name, but the certificate knows that machine by its FQDN, .NET will fail the communication. To avoid this issue, either ensure that the name of the machine you're connecting to always matches the name in the certificate, or add another certificate that applies to the second name. Another possible issue you could be facing lies in the fact that .NET will fail communication with your server if the certificate you have is self-signed and not trusted. This is only an issue if your Reporting Services is remote; communication will still work if it is local. To work around this issue, try using a certificate that is signed by a recognized certificate authority.

For more information on SQL's connection security settings, see the official docs here:

Upgrade Failure: "The installation and configuration of Team Foundation Server succeeded, however upgrading the data was unsuccessful"

2013-03-05T20:42:00Z

If you received this message on the completion page of the TFS upgrade wizard, it means that the application tier of your TFS instance was successfully upgraded to the new version, but some or all of your team project collections were not. In this case, you will be able to use TFS to create new projects and collections, but you will be unable to access your old content until you manage to successfully upgrade it as well.

The main reason for TFS being unable to upgrade team project collections is that their data was already either corrupted, incomplete, or stuck between schema versions. You will need to contact customer support for assistance troubleshooting these data issues and getting your data back to a workable state. However, there is also a chance that the upgrade process failed because TFS's network or SQL connection was lost partway through the upgrade. Before calling support, you may want to double-check, and if necessary repair, these connections and then try re-running the upgrade on your project collections. To retry the upgrade, remove all the non-functional team project collections from your new instance of TFS and use the attach command to attach the backups of these collections to your server. Please remember to make a copy of your backups before attempting the attach so that you will still have a copy of your data in its original state in the event that the attach fails.

Upgrading AlwaysOn and Mirrored Environments

2013-03-05T17:49:00Z

Update 4/30/2013: We have found a bug in TFS 2012 Update 2 that blocks usage of this feature for instances using SQL Mirroring. If your Team Foundation Server is configured with SQL Mirroring, you should remove your databases from their mirrors before upgrading, as upgrading with SQL Mirroring in place will cause the servicing steps to fail. This issue does not affect deployments that use SQL AlwaysOn. This bug has been fixed in Update 3 and we apologize for the inconvenience.

Starting with Team Foundation Server 2012 Update 2, TFS users will be able to upgrade deployments that use SQL AlwaysOn High-Availability Groups or Database Mirroring. In the past, and for a number of good reasons, the upgrade process would always try to place the databases into the SIMPLE recovery model, which is not compatible with database farms such as AlwaysOn and mirroring groups. Therefore, users had to remove all databases from these features before attempting to upgrade, or else the upgrade would fail. TFS will now detect that a deployment’s configuration database is involved in SQL AlwaysOn or database mirroring and will present the user with the option to upgrade their deployment in the FULL recovery model, thereby bypassing the requirement to disassemble their farm before upgrading. In addition to being able to upgrade this way from the upgrade wizard, users can use this feature when performing an attach of a Team Project Collection or an unattended upgrade, as these commands essentially perform the same database upgrade operations as a standard upgrade. However, upgrading in the FULL recovery model, while convenient, requires more log and disk space than upgrading in the SIMPLE recovery model. Not having sufficient space to upgrade in the FULL recovery model will cause the upgrade to fail. Your TFS database administrator should review the following documentation on the added risks of upgrading in the FULL recovery model carefully before you proceed to use this feature.

What is the difference between the SIMPLE and the FULL recovery model?

The SQL Server recovery model controls the way SQL transactions are logged and whether these transactions can (or must) be backed up. Databases are typically put into either the SIMPLE or the FULL recovery model. The SIMPLE recovery model automatically reclaims log space after transactions are completed to minimize log space requirements; on the other hand, the FULL recovery model keeps all transactions in the log until they can be backed up to another location. This means that databases using the FULL recovery model can be recovered to any point in time, while databases using the SIMPLE recovery model can only be restored to the latest full backup.

How does this apply to Team Foundation Server upgrades?

By default, the Team Foundation Server upgrade process switches databases into the SIMPLE recovery model to service them. This allows for a faster upgrade and minimizes the chance that the heavy transaction load of an upgrade will cause the system to run out of log space, which would result in the upgrade process failing.

However, there are a number of options that an advanced operations group may use in SQL Server, outside the scope of TFS, to provide business continuity, disaster recovery, or high availability to their deployment. These options include Log Shipping[1], Database Mirroring, and AlwaysOn Availability Groups, and all are dependent on the databases in question being put into FULL recovery model and staying in FULL recovery model. Up until now, attempting to upgrade an entire server farm at once would fail because the TFS servicing steps were unable to put the databases into the SIMPLE recovery model. Thus, the only way for users to upgrade AlwaysOn or mirrored environments was to remove their databases from these groups and upgrade them individually. Now that Team Foundation Server 2012 officially supports SQL AlwaysOn High-Availability Groups, the upgrade wizard will intelligently detect when a database is involved in SQL AlwaysOn or Database Mirroring and allow the deployment to remain in the FULL recovery model during upgrade.

If you are using AlwaysOn or Database Mirroring with TFS, you should only have one database group and your configuration database should always be part that group. When you run the upgrade wizard and point it to your configuration database, the wizard will detect its involvement in AlwaysOn or mirroring and display the additional text outlined in red on the page. You will not be able to continue with upgrade until you confirm that you would like to stay in the FULL recovery model during the process. If you don’t want to proceed with upgrade in the FULL recovery model, you still have the option of removing your databases from their farm and upgrading them individually in the SIMPLE recovery model. You will need to close the upgrade wizard and restart it once you have made that change to all affected databases. Don't forget -- if you choose to revert to the SIMPLE recovery model during upgrade, you will need to re-enable AlwaysOn or mirroring for each database after your upgrade. If you are using SQL AlwaysOn, you will also need to remember to add your databases back into their AlwaysOn availability group.

So tell me, what are the risks of not putting the databases into the SIMPLE recovery model prior to upgrading?

Log and disk space

The primary risk will be amount of log space required by the database to complete the update. Upgrade will make changes to the SQL databases in a number of serial transactions. These transactions may be quite large. When the database is using the SIMPLE recovery model these transactions can be purged from the logs by SQL as soon as they are committed. Under FULL recovery these committed transactions will need to be backed off to disk before they can be purged. Additionally, the transactions will need to be written to the Failover Partner/Secondary database(s)’ log files – a process known as hardening – before they can be removed from disk. Where the log space requirements with SIMPLE recovery model may have been the single largest transaction during the update, the new log space requirement with FULL will be the single largest transaction plus some additional quantity of space for committed transactions that have not yet been written to disk and hardened at the secondary. There is also a completely new requirement that the server’s disk have sufficient space available to store these transactions until they are written over to the secondary log files. Running out of space is the primary risk as the update won’t be able to complete without adequate log space. The only way to know what “adequate” is for certain will be to monitor log and disk space usage during a test upgrade. We have provided some guidelines in the “Metrics” section around the recommended amount of log space based on our own internal testing of the feature, but every update and every TFS deployment will be different.

Performance

Less of a risk, but an equally important factor will be an increase in the length of time required to do the update. Upgrading in the FULL recovery model requires the transaction log to be backed off to the “Backup Log,” which will impact both disk and transaction log performance. Both Database Mirroring and AlwaysOn Availability Groups will require the log records to be written to the mirroring partner/secondary database(s) before the committed transactions can be removed from the log. This will add additional network load as the transactions are copied over. If your server is set to use the Synchronous transmission option the commit of the transaction on the primary will be delayed until the secondary can also commit, which may introduce additional latency. For more details on Synchronous versus Asynchronous transmission, see “Advanced Options: Commit Latency Mitigation.”

As the ATs should be quiescent during the upgrade, there should be no load considerations for the primary databases. If the AlwaysOn High-Availability Group’s secondary databases are set to being used for Read Only requests, that load could potentially slow down the transfer of the log records and their application if read-only users are running queries in the secondary databases. Thus, it is advisable to disable user access to these databases during the upgrade. One should be able to change them from read-only to non-readable in the AlwaysOn Availability Group dashboard and then back again after the upgrades.

Metrics

As stated previously, the only way to truly know how much extra log and disk space will be adequate for performing upgrades in the FULL recovery model is to monitor log and disk space usage during a test upgrade. This is because the amount of database changes contained in each TFS upgrade will be different depending on which release you are upgrading to and which release you upgrade from. The topology of one’s TFS databases and the amount and density of the data in these databases will also be a factor. That being said, here is data from a set of sample upgrades that we performed using customer data. We will continue to update this data periodically as we perform more testing on different-sized databases. You may want to use this data to help you decide whether you want to risk upgrading in the FULL recovery model without running a test upgrade first.

TFS Instances (sizes in MB), upgrading from TFS 2010 SP1 to TFS 2012 Update 2:

Database	Database size before upgrade	Log space used in SIMPLE	Log space used in FULL
Configuration	8157.13	31.36	342.23
Collection 1	124.56	62.81	358.22
Collection 2	74.44	7.13	121.29
Collection 3	4707.50	695.50	2234.19
Collection 4	85.06	46.41	372.64
Collection 5	56.75	17.18	347.29
Collection 6	93.63	27.46	389.36
Collection 7	124.69	27.84	403.97
Collection 8	79.13	37.51	350.14
Collection 9	140.44	54.68	399.38
Collection 10	83.81	32.85	153.02
Collection 11	180.00	39.42	451.45
Collection 12	95.81	33.31	366.82
Collection 13	859.13	50.14	578.27
SSRS Warehouse	1439.69	34.79	36.08

Database	Database size before upgrade	Log space used in SIMPLE	Log space used in FULL
Configuration	2123.75	722.02	2814.43
Collection 1	323.88	308.71	309.09
Collection 2	141221.63	5856.43	36525.21
Collection 3	4865.35	228.74	1202.33
Collection 4	45879.94	4337.93	38279.04
Collection 5	12642.38	3059.35	13616.81
Collection 6	91.19	36.11	348.6
Collection 7	74.25	34.07	45.57
Collection 8	138.19	40.44	340.21
Collection 9	3021.13	1536.38	5336.12
SSRS Warehouse	17738.5	65.13	64.79

Database	Database size before upgrade	Log space used in SIMPLE	Log space used in FULL
Configuration	1131.38	377.56	1281.98
Collection 1	1635.94	410.25	1458.83
Collection 2	75.31	62.64	343.59
Collection 3	394577	13165.34	106366.87
Collection 4	62.5	94.28	219.13
Collection 5	382,88	269.35	570.19
SSRS Warehouse	33685.38	111.11	114.62

Database	Database size before upgrade	Log space used in SIMPLE	Log space used in FULL
Configuration	172.75	20.29	303.03
Collection 1	245791.13	8671.32	72119.40
SSRS Warehouse	38510.88	85.02	85.27

Tips for minimizing risk

While upgrading in the FULL recovery model rather than the SIMPLE recovery model does add risk to your ability to successfully upgrade your Team Foundation Server, there are a number of ways to minimize this risk. For example, it is always a good idea to manually grow the amount of space allocated to your SQL transactions logs as much as possible prior to running the upgrade. As stated above, if you use SQL AlwaysOn you should also consider disabling users' read access to your secondary databases during the upgrade to maximize the speed of log transfers from primary to secondary. And finally, it is absolutely crucial to have current backups of all your TFS data prior to performing any type of upgrade.

In addition to these general tips, there are some advanced options that you may want to consider taking advantage of to minimize your risk further.

Advanced Options: Log Backup Mitigation

For Database Mirroring/AlwaysOn Availability Groups we can throw the transaction log backups away by backing them off to a NUL device. This will keep them from hitting the backup disk which will save us backup disk space, IOPS, and backup disk write latency. While not quite as nice as the SIMPLE recovery model, it is roughly equivalent in function. The transaction log files would only have value if we wanted to restore the databases to a point in time during the upgrade, which is a highly unlikely scenario. Additionally, in order to restore the databases one would have to remove them from Mirroring/AlwaysOn. A catastrophic upgrade failure that cannot be restarted would warrant a restore from the full backups as one will want to get back into a pre-update state to proceed. After the upgrade a full backup should be taken again to restore the integrity of subsequent transaction log backups.

Most systems that do transaction log backups do them on a 15 minute or longer duration. To minimize the delay in backing off committed transactions we should increase the frequency to every minute. To do this, it is probably easiest to disable the normal backup job and setup a new one that runs every minute, and goes to a NUL device.

Advanced Options: Commit Latency Mitigation

There isn’t a lot that can be adjusted with regard to delivering transactions to the failover partner. We can choose whether the Mirror/AlwaysOn Group will be Asynchronous or Synchronous. If log or disk space is a concern, it is generally advisable to use Asynchronous delivery. Under Asynchronous delivery the failover partner/secondary database(s) are allowed to get behind on the delivery of the transactions, and the primary will not delay the commit of the transaction until it has been written at the destination. This exposes the system to data loss at the destination if there is a catastrophic failure. This scenario won't make you any worse off that if you had just torn down your database farm from the start, with one caveat: if the failover partner/secondary database(s) goes offline and transactions aren't delivered then it will need to be removed promptly from Database Mirroring/AlwaysOn to avoid unchecked transaction log growth. Before allowing access to the read-only databases, they should be checked to see if the application of the transactions is behind. There may be a period where the primary is brought back online to resume operations, but the read-only databases are given more time to finish applying the transactions. Because the TFS update frequently makes DDL and DML changes to the databases the secondary databases should be fully caught up with the update changes before being brought back into operation. All the usual methods of improving log performance are still applicable such as growing out the logs for the expected usage prior to running the update, and having the logs on fast disk.

Again, though it's not required, the best way to minimize risk is to run a practice upgrade on a cloned test environment prior to upgrading your production server. This is especially true if you have never serviced your databases in the FULL recovery model and don't know what to expect.

Provided that the appropriate cautionary measures are taken, the ability to upgrade in the FULL recovery model should ultimately make server upgrades more efficient and convenient for users with SQL AlwaysOn or database mirroring.

What if I want to upgrade in the FULL recovery model, but the upgrade wizard doesn’t present me with the option to do so?

As this is a brand new feature for Update 2, there may be edge cases where the upgrade wizard does not correctly detect that your configuration database is involved in AlwaysOn or database mirroring and therefore does not give you the option to upgrade in the FULL recovery model. There are also a number of other scenarios that are not formally supported by TFS where a user may want to upgrade in the FULL recovery model. These include:

If your databases are involved in Log Shipping. Log Shipping is not officially supported for use with TFS, but many users have found that they are able to set up Log Shipping for their TFS databases without issue.
You have a simple database but want the option of upgrading in the FULL recovery model to keep your SQL transaction chain unbroken. However, keep in mind that you should not have any reason to want to restore your databases back to a point in time where they were only partially upgraded.
Your configuration database is not involved in AlwaysOn or Database Mirroring, but some or all of your collection databases are. Since the upgrade process only checks the configuration database and not the collections for these features, it will attempt to convert all databases to the SIMPLE recovery model in this case. This will cause upgrade to fail as soon as it reaches a collection that cannot be placed into the SIMPLE recovery model.
- If your TFS instance is set up this way, you should really consider adding the configdb to your database farm. The data stored in the configdb is essential to TFS. If data from the configdb is lost or corrupted your TFS instance will probably be irrecoverable.

Thus, we have created a manual override that will allow any user to upgrade in the FULL recovery model, even when the upgrade wizard does not detect the need to. To use this override, open SQL Management Studio and set the extended property,

“TFS_UPGRADE_IN_FULL_RECOVERY_MODEL = Yes”

for each database you wish to upgrade in the FULL recovery model. Note that if this extended property is set to anything other than “Yes,” it will be ignored during the upgrade and TFS will default to upgrading all your databases in whichever recovery model the wizard detected it should use. After the upgrade, you should remove this extended property from your databases so that you do not unintentionally leave it set for any future upgrades.

Caveats, Limitations, and Known Issues

When upgrading a TFS instance that uses SQL AlwaysOn, please be sure to provide the wizard with your AlwaysOn Group Listener (AGL) rather than to the primary or secondary replica of your configuration database, as the AGL will always point to whichever database is labelled as the primary. If you are upgrading a database mirror, please be sure to point the wizard to the primary replica of your configuration database.
Team Foundation Server does not support having a combination of AlwaysOn databases and mirrored databases on the same instance. If SQL AlwaysOn is enabled for a particular SQL Server instance, upgrade will not detect databases involved in any kind of mirroring; it will only detect standalone databases and the databases that are involved in SQL AlwaysOn.
As explained above, there is an override you can set to upgrade individual databases in the FULL recovery model if you so choose. This should unblock upgrades for any AlwaysOn or mirroring cases we do not correctly detect in the wizard as well as for any unsupported scenarios that may need to leverage this feature.
This feature also applies to unattended upgrades and Team Project Collection attaches and detaches, as these operations all perform the same type of database servicing as an upgrade using the wizard. If you don't want your databases left in the FULL recovery model, don't forget to remove them from their replication feature prior to running any of these commands.
Remember that there’s no way to guarantee whether you will be able to successfully upgrade using the FULL recovery model without attempting to do so on an identical test instance first. Prior to performing an upgrade, always ensure you have a current full backup of your TFS data. If your upgrade fails, you will need to use this backup to restore your data before attempting to upgrade a second time.

¹Log Shipping is not a feature officially supported by TFS. However, it is still possible to upgrade databases involved in Log Shipping by using a manual override. See “What if I want to upgrade in the FULL recovery model, but the upgrade wizard doesn’t present me with the option to do so?”

Troubleshooting Installation of Team Foundation Server

2013-03-05T14:59:00Z

Below is a list of common problems that can occur while installing Team Foundation Server, as well as suggestions for resolving these problems.

The most common reasons for an installation of Team Foundation Server to fail are:

You do not have enough disk space to perform the installation.

Solution: Clear enough disk space on your machine to complete the installation, then retry. The download page should give a clear indication of how much space is required.

Not all components from a previous installation were completely removed.

Solution: Check Add/Remove Programs to see if there is an entry for the previous installation. If there is, uninstall it. If there is no entry, you may want to try using an msiexec command to uninstall it (this requires searching your package cache for packages associated with the installation, which can be tedious). Then retry your installation.

A network connection or connection to a file directory was lost while the installation was trying to move files to the disk.

Solution: Re-establish your connections and retry the installation.

You started the installation while logged on with an account that is not a member of the Administrators group on the local computer.

Solution: Add the user account to the Administrators group on the local computer, or log on as a user that is already a member of that group; then retry the installation.

The hardware or software the machine uses is incompatible with the product being installed.

Solution: Remove or replace the incompatible software or hardware.

The ISO image file is bad. This problem almost always involves a trial edition of Team Foundation Server.

Solution: Obtain a new ISO image file and retry the installation.

You may also want to examine the installation log files for insight into why the install failed. There should be one log file for each MSI installed (or attempted), as well as one for the TFS bootstrapper; all are titled in the form of "dd_tfs_server_<timedatestamp>*.log" and located in the server's AppData folder. Search for lines that start with the tag, "[Error]" or scroll to the bottom of the log to view the most recent activity.

If these suggestions do not resolve the problem you are seeing, please try re-running the installation once again. Should the installation fail, take careful note of any errors you are seeing and then contact customer support.

TF401066: Upgrading TFS on a machine with underscores in its name

2013-03-04T23:25:00Z

If you received this warning message when upgrading your instance of Team Foundation Server, it means that you're trying to upgrade Team Foundation Server on a machine with underscores in its name. It is strongly discouraged to give your machine a name that contains underscores in it if you plan to install TFS, because doing so will prevent you from connecting to TFS Web Access using Internet Explorer. The reason for this is that Internet Explorer will not send cookies to a hostname with underscores in its name, and you must have cookies to use TFS Web Access because Web Access searches for an anti-forgery cookie when you connect. Thus, if you run Internet Explorer, you will be unable to connect to Web Access and perform certain administrative functions such as administering team project security, assigning group membership, and assigning work item areas and iterations.

If you would like to be able to use Web Access after upgrading (and you almost certainly do), you have three options:

1. Connect to TFS using a browser other than Internet Explorer. TFS supports the latest versions of both Chrome and Firefox, so you can install one of these browsers and connect to Web Access through them without issue.

2. Create a new host header binding through IIS to bind a new hostname that does not contain underscores to your machine. You can then use this alias when connecting to Web Access and Internet Explorer will not throw an error.

3. Access your Application Tier via its IP address rather than by name.

You could also try to perform a machine rename like the error code suggests; however, this is only advised if you are performing a clean install rather than an upgrade. If you already have SQL, Reporting, and/or SharePoint configured on your server, doing a rename will cause the bindings to those programs to break. The Reporting and SharePoint bindings are easy enough to repair, but you will need to run some complex SQL scripts to re-establish a connection to SQL. So unless you have a skilled database administrator who is willing to do that for you, this approach is not recommended.

Unattended Installation of TFS 2012

2012-10-01T14:43:00Z

Introduction

What is Unattended Installation?

Unattended install is a feature of Team Foundation Server that lets a user pre-set all configuration parameters for a desired TFS instance in advance. This allows TFS to be configured from start to finish without pausing for input from the Configuration Wizard during the process. Unattended Installation takes place via the command prompt. This paper describes the two commands through which it is performed: Create and Configure.

Who Should Use Unattended Install?

This feature is ideal for users who are very familiar with TFS and the configuration process, and whose environment divides TFS functions over many different machines. For example, many large-scale enterprise systems have several servers that are designated to builds. Unattended install allows an administrator to quickly kick off the Team Build installation process on these machines without having to supervise each one independently. Furthermore, since the configuration for each build server will likely be almost or completely identical, it should be easy to set each machine’s configuration parameters quickly.

Feature Overview

The unattended install feature can be used to configure all different instance types of TFS. These include: Basic, Standard, AT-Only, Build, Proxy, and SharePoint Extensions. To do this, you must determine in advance how the instance should be configured—usually by creating an .ini file and editing it — and then run the specified configuration in the command prompt. This paper covers both the Create command to make this file and the Configure command to actually run the configuration. It explains the different options, or parameters, for these commands and touches on a few scenarios that unattended install does not support.

The feature’s name is somewhat of a misnomer because the “unattend” commands actually perform configuration work as opposed to installation. In order to carry out the full end-to-end installation of TFS, from loading the bits onto the disk to configuring them, you must make a batch file or PowerShell script that combines the unattend commands with an additional install command. The first command to run is the install command, which is not part of the unattend feature. To install the bits, navigate to the location of the program’s main executable (this is likely on a DVD that is inserted into the machine). Then, depending on whether the version of the program is TFS or TFS Express, enter one of the following commands:

tfs_server.exe /quiet or tfs_express.exe /quiet

After this step is complete, proceed to the unattend commands in the next sections.

Creating a Configuration File

The first step to initiate an unattended installation is to create a configuration file for the specific type of installation to be performed. This step creates a file with all relevant parameters for the given installation and performs an environment scan on the machine to populate them with smart default values.

Navigate to the Tools directory within the TFS folder. By default, this folder is placed in the Program Files folder of the local machine’s C: drive.

cd C:\Program Files\Microsoft Team Foundation Server 11.0\Tools

Once in the Tools folder, you can run the Create command. The basic syntax for this command is:

tfsconfig unattend /create /type:<type> /unattendfile:<file> [/inputs:<inputs>]

Here is a valid example command:

tfsconfig unattend /create /type:basic /unattendfile:configbasic.ini

See the results below. The command will be recognized and an activity log created.

The Create command has two required parameters and one optional parameter. ‘/inputs:’ is optional and will be explained later. ‘/type:’ and ‘/unattendfile:’ are always required. The possible configuration types are explained in the following section. ‘/unattendfile:’ represents the user-specified path for the configuration file and must end in.ini.

Types of Installations

The unattended install feature supports all the same installation types that the Configuration Wizard supports and contains fields for the same set of configuration parameters. For the most part, the name of each configuration type for unattended install mirrors the name in the Wizard. Here is a list of names and descriptions of the types of unattended configurations:

BASIC: Configures the essential development services for Team Foundation Server. This includes Source Control, Work Item Tracking, and Test Case Management.
STANDARD: Configures the essential development services along with integration with Reporting Services and SharePoint Products. Requires at a minimum to either set ‘UseWss=False’ or provide ‘WssAdminSiteAccountName.’
- Note – Since the configuration file for this install type allows Reporting and/or SharePoint to be disabled, it embodies both the Standard and Advanced configurations in the Configuration Wizard. The configuration file default is to set ‘UseReporting=True’ and ‘UseWss=True,’ thereby invoking a standard configuration.
ATONLY: Reinstalls the Team Foundation Server application tier using existing databases or adds another application tier to a load-balanced farm.
BUILD: Configures Team Build services. Creates or replaces build hosts. Creates, adds, or replaces build controllers and build agents.
PROXY: Configures a version control proxy service.
SPINSTALL: Installs SharePoint on server operating systems.
- Note – Unlike in the Configuration Wizard, SharePoint is not installed automatically before an unattended TFS Standard configuration. Therefore, the user may need to run ‘spinstall’ before ‘standard’ if the user plans to set ‘UseWSS=True.’
SPEXTENSIONS: Configures SharePoint extensions.

Note – Unlike in the Configuration Wizard, SharePoint is not installed automatically during a SharePoint Extensions configuration. The user must run ‘spinstall’ before ‘spextensions’ if SharePoint is not already installed on the machine.

UPGRADE: Upgrades Team Foundation Server to the current version from a previous release (where permitted). This includes upgrading TFS 2012 quarterly RTM's and GoLive CTP's.

Note – Upgrade is not currently listed as an install option in the help guidance for this feature, but it does exist. We are working to remedy this now.
Note – Before running this configuration, you will need to ensure you have a current backup of your databases and then override 'ConfirmBackup' so that 'ConfirmBackup=True.' Otherwise, the configuration will not run.

While the smart defaults in the configuration file for each type normally result in a successful configuration, it is important to examine the validity of each parameter in this file after it has been created. The smart default may not match the user’s expectation or intention. For some installation types, such as standard, additional information must always be entered by the user before the configuration file will run. To enter or overwrite parameter values, you can either specify inputs in the Create command or open and edit the configuration file after it has been created.

To specify inputs in the Create command, append the optional ‘/inputs:’ parameter to the end. Inputs are specified as <key>=<value> pairs, separated by semicolons. The key must match the name of a parameter in the configuration file, and the corresponding value is the string that will override the default value for that parameter.

Here is an example command that utilizes the ‘/inputs:’ parameter:

tfsconfig unattend /create /type:standard /unattendfile:configstandard.ini /inputs:UseWss=False;UseReporting=False

Note: It is not required to create a configuration file before running the command to configure a TFS instance. However, skipping to the Configure command requires knowledge of the specific installation type’s parameters and often their default values for the local machine. Thus, it is not advisable to skip the file creation step except for in very specific cases, like when revising or replicating a pre-existing machine configuration.

Editing the Configuration File

To edit the configuration file that resulted from the previous step, simply enter the name of the filepath into the command prompt. This will open the file in a text editor.

Below is an example of a file that was generated for a standard configuration. Since the file is named “create” and exists in the local directory, it was opened by entering create.ini into the command prompt.

The lines with a leading semicolon are comments to help clarify the meaning of the parameter below it. Be sure to edit the line containing the parameter and not the comment. Once the desired changes are made, save the file and close it.

Running the Configuration

The final step of the unattended installation is to run the desired configuration on the machine. This process performs the same validation checks as the Configuration Wizard and then configures the specified TFS instance on the machine.

The Configure command can be run in two ways. The first option is to specify a configuration file. This uses the file that was created in the previous two steps and is the recommended way to run an unattended configuration. The other way is simply to specify a type of installation to run (in the same way that a user specifies a configuration file type in the Create command), with the option of specifying inputs to override the smart defaults. These options are mutually exclusive; you cannot specify both a file and a type.

The basic forms of the Configure command are:

:: Option 1

tfsconfig unattend /configure /unattendfile:<file> [/inputs:<inputs>] [/verify] [/continue]

:: Option 2

tfsconfig unattend /configure /type:<type> [/inputs:<inputs>] [/verify] [/continue]

Each parameter for the Configure command is explained in the table below.

Table of Configure Parameters

Command	Behavior	User Input	Required?
/unattendfile:, /type:	Same behavior as in Create. Unattendfile: the path for the .ini input file. Type: The type of unattended configuration to run.	Specify a configuration file. Specify one of the possible types.	Either the configuration file or the type is required, but only one may be specified.
/inputs:	Has the same syntax as in the Create command. When ‘/type’ is specified, allows override of smart defaults; when ‘/unattendfile’ is specified, overrides values in the file.	<key>=<value>, separated by semicolons	Optional
/verify	Stops the process after the verification checks; does not configure	No additional input	Optional
/continue	Overrides the default behavior of stopping configuration on a warning until user presses ‘Enter.’	No additional input	Optional (Has no effect when ‘/verify’ is also specified)

Note: In cases where the user intends to run a configuration without creating a configuration file to manage the inputs, it is strongly recommended to run ‘/verify’ before proceeding with the full configuration.

Examples:

Below are two examples of valid configuration commands.

:: Run readiness checks only on a configuration by type with 1 override

tfsconfig unattend /configure /type:atonly /inputs:UseSqlAlwaysOn=True /verify

:: After viewing results of the checks, run configuration straight through

tfsconfig unattend /configure /type:atonly /inputs:UseSqlAlwaysOn=True /continue

:: “configureatonly.ini” has been made using “tfsconfig unattend /create…”

:: Basic command to run a configuration by file

tfsconfig unattend /configure /unattendfile:configureatonly.ini

Sample Output

The screenshot below is sample output for a successful unattended Build configuration. Notice that the input parameters for the configuration are displayed on the screen as the command is run, followed by the readiness checks and the configuration steps. A final message is displayed at the bottom stating whether or not the configuration completed successfully, followed by the file path to the event log for the process.
If there had been any issues with the configuration process, warnings would be displayed in yellow and errors would be displayed in red. Warnings require the user’s approval to continue with configuration unless ‘/continue’ is specified. In the case that there are errors, configuration will not succeed.

Demo

Check out our demo video, where we create an unattended installation of Team Build.

(Please visit the site to view this video)

Feature Limitations

There are a few scenarios that unattended installation does not currently support:

Unattended install is only intended for use in on-premises scenarios. Although the Configuration Wizard can also install Build and Proxy instances that point to Azure databases, this functionality has not been implemented for the command line (there is no place to supply the Azure Cloud Storage account information).
As stated above, the ‘standard’ and ‘spextensions’ processes do not install SharePoint automatically during unattended configuration. SharePoint must be installed separately using ‘spinstall’ before running these installations if it has not been installed already.
Unattended install is available for Team Foundation Server Express; however, only the ‘build’ and ‘basic’ (where ‘SqlInstance=SqlExpress’) configuration types will succeed. Unattended install will block on configuration types that cannot be installed on the Express SKU, such as ‘spinstall,’ ‘spextensions,’ and ‘proxy,’ and will raise errors for the ‘atonly’ and ‘Standard’ configuration types, since TFS Express is only compatible with SQL Express.
Reusing unattended configuration files across machines is not currently supported because configuration files use the machine name in certain default parameter values. It is a goal to improve this functionality in the future. In the meantime, users can write their own scripts to dynamically switch out the machine names in their configuration file to suit their needs.

Other Resources

Help Documentation

Most of the information covered in this whitepaper is summarized in TFSConfig Help for user reference. This Help documentation lists the commands necessary to run an unattended install and includes all required and optional parameters for these commands. It also provides example commands and a description of each of the supported installation types.

To access the Help documentation for this feature, navigate to the Tools folder in your TFS directory using the command prompt. If you installed Team Foundation Server to Program Files on your C: drive, the command will look like this:

cd C:\Program Files\Microsoft Team Foundation Server 11.0\Tools

Once you have navigated to the appropriate location, type: tfsconfig help unattend

The following page contains a screenshot of the information that should appear.

Again, although not listed here as a valid type, unattended "upgrade" is also supported.

Network Considerations for TFS Proxy Servers

2012-03-23T13:59:32Z

If you are installing a TFS Proxy server on a machine that is configured to
automatically receive the proxy settings from your network (this is different
than DHCP) you may have connectivity issues when running the TFS Proxy Service
as a machine account, such as NETWORK Service.
For servers it is generally recommended that they use pre-configured IP
and network Proxy settings (if needed).

You can verify this setting on your machine by opening up Internet Explorer / Tools
/ Internet Options / Connections / LAN Settings.

The problem is that these settings are cached at a user level the first time
Internet Explorer (or default browser) is run.
If you are using a machine account such as NETWORK Service, it will
never run the browser, and get these proxy settings.

In this situation you will either need to:

Manually configure the proxy settings for this server (preferred)
Run the TFS Proxy Service as a user account, login via this account,
and launch the web browser so the proxy setting are cached.