Last week I had the situation where we wanted to use Team Foundation Server 2010 but IT locked down most of the required network options. Basically it came down to the fact that only the most basic form of Internet protocols were in place, i.e. http traffic on port 80.

First option … convince the IT guys to open other ports (8080) on the network. Hmm, tried it, been there, no option. These are the NO-guys!

So here we are, we have a Team Foundation Server installer that installs on port 8080 by default and a network on port 80. Wouldn’t it be an option to just reinstall and enter port 80 as the port to install Team Foundation Server on?

Well, no. The deployment in this case was a ‘small’ one (virtual) server installation with SharePoint, Reporting Services and TFS on the one box. And TFS just does not like it when there already is someone else (SharePoint) covering the standard 80 port.

So standing up a new instance on port 80 is not an option unless you decide to move all your other port 80 services to another box.

That leaves nothing else than either give up move into the virtual domain and accept that port 80 is not an option or to go on into the well known trial on error debugging mode and see how we can open things up on port 80!

Giving up obviously is for the weak of heart but not for me. So let’s do it!

What I did is to start off with the default installation using port 8080 and later on try to move it over to port 80. (I already tried installing on port 80 but this hit so many issues that I reverted everything back to the original status and settled for installing on port 8080)

OK, first let’s try to fix the issue where port 80 is already in use by SharePoint. From several earlier endeavors in network land I was aware of the Host Name feature where you use different names to identify several services on one port. What we do now is moving the default SharePoint http://<servername> to http://sp.<servername> but leave the service on port 80.

This step will be a bit different for TFS on SharePoint Services and TFS on SharePoint Server. I will highlight both options here.

For SharePoint Services go to the “SharePoint 3.0 Central Administration” tool and under Operations select “Alternate Access Mappings”

Click the “Alternate Access Mappings” and select “Edit Public URLs”

Select the  “Default Web” from the listbox in the top right corner and change the “Internet” textbox to http://sp.<yourdomainorserver>

Note:
Because your machines need to resolve the URL given here you should add the entries also to your DNS server. To test it I didn’t add the URLs to my DNS (especially as this is managed by the NO-guys) but added them temporary to the hosts file (c:\windows\system32\drivers\etc) on both the server as the client machine.

Let’s rewind and do it again for SharePoint Server 2010:

Open IIS, select the web entry that covers the SharePoint port 80 entry. Right click and select the Site Bindings option from the menu and edit the existing entry. Leave it all as it was except for the Host Name. Change the textbox to http://sp.<yourdomainorservername>

While you are at it in IIS now browse to the SharePoint Admin Site “SharePoint 2010 Central Administration” and under System Settings click on “Configure alternate access mappings”

Select the SharePoint – 80 web and change the default entry to http://sp.<yourdomainorservername> as well. (I guess you could do the same thing as with the SP Services option, to leave the default as is and change the Internet box to http://sp.<yourdomainorservername> but I must admit that I didn’t test that.

Now we can test to see if we can access SharePoint on http://sp.<yourdomainorservername>.

On your client PC this would not be an issue but when you try it on the server you’ll hit a security issue blocking the site. In order to resolve this next hurdle we will make some changes in the registry.

The steps for this are also described in Kb 896861: http://support.microsoft.com/kb/896861 but I will present them here as well.

The first registry entry we are setting is setting the DisableStrictNameChecking registry entry to 1.

1. Locate and click the following key in the registry:
   HKEY_LOCAL_MACHINE\System\CurrentControlSet\
   Services\LanmanServer\Parameters
   
2. On the Edit menu, click Add Value, and then add the following registry value:Value name: DisableStrictNameChecking
   Data type: REG_DWORD
   Radix: Decimal
   Value: 1

Next setting the BackConnectionHostNames …

1. In Registry Editor, locate and then click the following registry key:
   HKEY_LOCAL_MACHINE\SYSTEM\
   CurrentControlSet\Control\Lsa\MSV1_0
   
2. Right-click MSV1_0, point to New, and then click Multi-String Value.
3. Type BackConnectionHostNames, and then press ENTER.
4. Right-click BackConnectionHostNames, and then click Modify.
5. In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.
6. Quit Registry Editor, and then restart the IISAdmin service

In this case you will add http://sp.<yourdomainorservername>. Later on you will add http://tfs.<yourdomainorservername> to cover the TFS entry.

Registry entries done? Best thing to do here… reboot the server (You may get away with only doing an IISReset but if you want to be sure … reboot it).

Now you’ve rebooted, check the new SharePoint entry in your browser. Open up the browser and goto http://tfs.<yourdomainorservername>. If all goes well you now see the next picture.

TFS will be our next stop. This is where this exercise all started.

Instead of changing the Host Name here we will add a new Host Name and leave the 8080 entry intact. Right click in IIS the Team Foundation Server entry, select the Site Bindings option and click the Add button to add a new entry. Create a type http to All Assigned on Port 80 named http://tfs.<yourdomainorservername>. Now do another IISReset.

Next thing to do is get into TFS Administration Console and select the Application Tier and hit the “Change URLs” option.

Within the Change URLs dialog change the Notification URL to http://tfs.<yourdomainorservername> and make sure the Server URL is http://localhost:8080/tfs

You will notice that when you select the “Use : “ radiobutton and enters http://localhost:8080/tfs that after closing the dialog and reopen it will change back to the “Use Localhost” radio button. Just check on the Application Tier page that the server URL shows http://localhost:8080/tfs

Make sure this dialog shows you’re the both ports 80 and 8080.

So, now this should do the trick don’t you think? Let’s try it…. open http://tfs.<yourdomainorservername>/tfs in your browser

WTF!! Another error, will this never end?

Here we go again, solving another issue. What happens is that on the serverside TFS tried to resolve things to port 80 as your initial call was on port 80. Now you have to make clear to the server that it needs port 8080 internally.

In order to do this, edit the web.config file found at C:\Program Files\Microsoft Team Foundation Server 2010\Application Tier\Web Access\Web

In the web.config you find the entry:

<tfServers>
<!– <add name=”http://server:8080″ /> –>
</tfServers>

Change this to (note the slash tfs extension):

<tfServers>
<add name=”http://<servername>:8080/tfs” />
</tfServers>

Save the web.config and do another IISReset (better safe than sorry) end retry testing your TFS site: enter http://tfs.<yourdomainorservername>/tfs

Yess, this time it worked as expected.

Once you have this in place you can try to connect to your new port 80 URL from within Visual Studio 2010.

By doing all this you should now be able to resolve your SharePoint site and TFS site on the single server by using a set of hostnames instead of ports:

– http://sp.<yourdomainorservername>
– http://tfs.<yourdomainorservername>

As far as I have seen so far everything is working like it should work. Reporting was already available on port 80 but you could decide to move this also to something like http://reporting.<yourdomainorservername>. I’m not yet in the position to also test if this all interferes with build services or test management so let me know if you hit on issues where moving to port 80 interferes.

Don’t forget to request for the two (or more in case you include reporting) DNS entries with the IT guys and remove the entries from the hosts files you created earlier to resolve the names.

For now I’m very happy to getting it all to work on port 80 to be able to work within our ‘locked down’ network! It turned out to be a very big article but I hope it will serve you as a reference to set up your own ‘port 80’ installation.