Configure Remote SharePoint Extensions for Team Foundation Server 2013 on a SharePoint 2013 Farm

Configure Remote SharePoint Extensions for Team Foundation Server 2013 on a SharePoint 2013 Farm

I recently had to configure the Remote SharePoint Extensions (aka Extensions for SharePoint Products) for a Team Foundation Server 2013 on a SharePoint 2013 Farm.

Most of the content you find on the MSDN or in blog posts explains you how to do that on a single SharePoint server. Here are some very good articles that you can find that explain a lot of tricky details.

However, as soon as you want to configure the extensions in a SharePoint farm, it’s a whole different story. There is usually very little documentation about that process. All you might find is something like “You need to install the extensions on all servers in the farm”.

Interesting, but very insufficient. I recently did it at a customer’s and because I encountered a few problems to say the least, I have decided to write about my experience.

The environment

First let me describe the environments I was working with

  • TFS 2013
    • 1 Application Tier server (Application Tier + Reporting Services)
    • 1 Data Tier server (SQL Server DB engine + Analysis Services)
    • 1 Build Server (1 build controller + 4 build agents)
  • SharePoint 2013
    • 3 SharePoint Front servers ( 2 + 1 in a different physical location for redundancy)
    • 2 SharePoint Application servers (1 + 1 in a different physical location for redundancy)
    • 1 SharePoint Search server
    • 3 SQL Server in an Always On cluster

The things you want to know about

The trick to know is that you need to be very careful about the order in which you do things when you setup the Remote SharePoint Extensions in the production environment of your SharePoint otherwise you might end up breaking the whole farm.

There are normally two steps when installing the Remote SharePoint Extensions

  • First you setup the binaries
  • Second you configure the extensions

The first step seems quite safe. It is only copying binaries at the right place on your server after all. But it might ask you for several reboots of the machine, which is probably something you want to be aware of.

The second step though, is not so harmless. What Microsoft documents very poorly is what is exactly done during this “Configure” step. What is actually done is not trivial and the wizard will give you no warnings. As soon as you press the Configure button in the wizard that is launched automatically once the binaries have been deployed, here is what is going to happen

  • TFS Templates will be deployed
  • All the web.config files of your existing web applications in your farm (except the one for the Central Administration luckily) will be modified to add references on TFS assemblies and new http handlers and modules for TFS
  • IIS will be reset

That doesn’t look so bad, but since you are in a farm, those web.config will be automatically deployed on the other servers of the farm. And guess what will happen when you try to connect to one of your existing web apps ? You get a 500 because IIS is trying to start a web app that references assemblies like Microsoft.TeamFoundation.xxx.dll that are not yet present on the system.

How to proceed in the right order

  • Make sure all your SharePoint servers are up to date with .NET Framework 4.5.1
    If they don’t have it, the setup of the Extensions will install it for you (thanks). But it will ask you for a reboot of the server with only one option on the message box. Once you click Ok on this one, it’s too late and your server is already rebooting. So be careful.
    TFS_Extensions_Reboot
    I
    t is probably better to foresee the installation during a period of time where you know the reboot is not going to be a problem
  • Install the Remote SharePoint Extensions on all SharePoint servers
    You should install the extensions on all the servers in your farm, except maybe the SharePoint Search server. In our case, that means on the 3 SharePoint Front servers + 2 SharePoint Application servers.
    But again be careful. You don’t want to run the configuration wizard right away once the binaries have been deployed on the first server. Just cancel the wizard and go install the extensions on the other servers before you do anything else.
    Make also sure that you take the stripped down version of the installer that will only setup the Remote SharePoint Extensions, and not the complete binaries for TFS. You can find it on the ISO under the directory Remote SharePoint Extensions
  • Configure the Remote SharePoint Extensions on all SharePoint servers
    Once the binaries have been properly deployed on all servers in your farm, you can launch the configuration wizard, starting with the server that hosts the Central Administration (in our case the first SharePoint Application server). You will probably get yet another surprise that you need to reboot the machine (again). Once you configured the first server, you need to proceed with the rest of them. If you don’t, the templates for TFS sites will not be deployed and your SharePoint Front servers will not be able to display your Team Portal sites.

Conclusion

I still don’t understand why the wizard is changing your existing web applications configuration files without your consent, instead of waiting for you to point it to the new/existing web app that you will use for TFS. It should at least give you a clear warning about what it is going to do. I also can’t understand why Microsoft cannot manage to provide a product setup without 1 to 3 reboots in the process.

My recommendation when installing the Remote SharePoint Extensions : do it during a time where your SharePoint will not be under heavy load since the reboots will of course slow it down. You might even prefer provisioning a few extra VMs for a dedicated SharePoint environment for TFS, so you don’t mess up your organization production environment.

Cédric Pontet

Cédric Pontet is a seasoned Lean and Agile practitioner, with more than 13 years of experience in software development. He really started focusing on Agile project management when he joined Agile Partner. Since 2005. Cédric has been involved in sizable projects, for several customers in sectors as various as "notaries" public sector, intellectual property management, banking & insurance, or post & telecom. He has been working on these projects first as a developer, and then as an architect and a team leader, gaining more and more experience and agility, while always keeping an eye on technology evolutions. Lately, Cédric has been spending more time coaching teams to start their agile transformation, evangelizing Lean and Agile values, in Luxembourg and its neighboring countries, not only for software development but beyond.

No Comments

Post a Comment

Comment
Name
Email
Website