Remote access to Team Foundation Server 2010 - tfs

We are four developers in different locations (in a 100 km radius of each other) tryint o collaborate on a software development project.
We would like to install Team Foundation Server 2010 on one of our machines (we are all using Windows 7) and use that as our central source code repository and work items management.
However we cannot seem to be able to configure TFS to accept remove connections (through Visual Studio). Is it possible to use TFS in this manner?

TFS is just a bunch of web services and should be set up for remote access out of the box.
Things you'll probably need to configure.
Make sure that the windows firewall is allowing TFS to accept incoming requests on port 8080 (the TFS install may do this for you)
Configure your router to use "Port Forwarding" so that requests from the internet to port 8080 are routed to the machine with TFS installed.
Your ISP probably allocates IP addresses dynamically so you might need to sign up for a Dynamic DNS service such as NO-IP.com. (check which ones are supported by your router)
Once you've done this then you should be up and running.
I'm sure others will suggest that you ditch TFS and use a DVCS such as GIT or Mercurial, they have a point! You should consider if it's worth the effort of getting TFS to work in this way when another system might be easier to get up and running.

TFS works just fine for this type of scenario and whether you use a DVCS or not you're still going to have to configure access. You don't need to set up proxies. TFS is extremely fast even over a slow connection. The 3 things you need to remember if you're not on the same domain as the TFS are:
Have the TFS administrator set up your TFS rights using a domain account set up for you. If you don't have a domain account set one up and use it. If there's no domain then create a workgroup account or a local TFS server account.
Add your domain (or workgroup or local TFS server) account credentials manually to the Windows credential store or TFS will keep bugging you to login and that's a pain. Make sure you include the domain (or workgroup or local machine name) in the user name in this format: MyDomainOrMachineOrWorkgroup\MyUserName. No backslash at the beginning, no backslash at the end.
You need to either use the IP directly to connect or add an entry to your hosts file (C:\Windows\System32\drivers\etc\hosts). For those that haven't ever gone into this file the "etc" is actually the directory name not just me saying "and so on". The entries there tell you that when you type an address like mytfs.mydomain.com it should go to IP such and such. That's all.

#Nigel We have TFS on a remote server with local proxy at my workplace. Our internet connection is quite slow relative to the number of developers on site. TFS has extremely poor performance in this configuration compared to having the server local. Our solutions can be several hundred MB to download (of which there are a few branches). Checking version history is slow and painful. Retrieving shelvesets is slow and painful. Checking in on VS2010 or VS2008 is slow and painful. Fortunately VS2012 does this asynchronously so checking in is not so bad but you will eventually get a modal dialog when the op is complete.
All in all, I would say a poor experience compared to SVN let alone DVCS.

you can use AnyDesk (version 5.2+) which allow you to set up TCP connection between clients.
I used it for connecting my client PC to a Team Foundation Server (TFS) over the internet. The server and client are behind NAT. I set the local and remote ports to '8080' and I can connect to server from client using this address on client: 'http://localhost:8080/tfs/'
Reference: TCP-Tunneling-AnyDesk

Related

Access TFS in another domain

I need to access TFS outside the domain. I thought that I can publish the TFS through WAP, but it seems that TFS does not support the authentication used by ADFS. Any other idea on how to do this? Thanks.
TFS does not support ADFS, there is a user voice here, you can go and vote it up or summit a new user voice to achieve it in future.
However, to access TFS outside the domain you can try below items:
Try to provide access to TFS over a virtual private network (VPN).
Try to provide access to TFS through a reverse proxy such as Microsoft Internet Security and Acceleration (ISA) Server.
Try to host your TFS server on an extranet.
You can reference this article : Providing Internet Access to Team Foundation Server
Besides, you can use Visual Studio Online, connecting remotely is a good option. And if you are doing any cloud work it integrates nicely.
This link (http://msdn.microsoft.com/en-us/library/ms252507(v=vs.100).aspx) from Microsoft describes various domain \ work group combos for your reference.

TFS express access for remote users

I have a TFS express configured on my windows server. Is it possible to invite a remote user on his email address, so that he can connect to the server and access project collections? I had been through few similar SO posts, and tried to explore almost all parts of the admin panel, but could't found such feature.
(I know this is available in case of visualstudio.com, but I need to invite a remote user to my locally hosted TFS).
Question:
- Is it even possible to allow remote user to access my TFS?
- If so, how to authenticate him?
Other Info: TFS is perfectly configured, and is accessible remotely as http://xyz:8080/tfs
No this is not possible. When TFS is installed on-premise it reads its users from the Windows Active directory and/or local Windows Server users.
When TFS is configured to be accessible remotely, like you say using an externally visible domain name, you need to register a Windows user either in Active Directory (preferred) or locally on the server.
To make your life easier, consider employing Visual Studio Team Services, the cloud service based offering that offers mostly the same services TFS does. It also provides 5 free users, doesn't need to be installed and maintained on a Windows Server, doesn't cost you a Windows Server license and allows you to invite people using their Microsoft Account/Windows Live ID.

Need to restrict TFS users by IP

We have 2 subnets (VLAN1 and VLAN2). TFS is installed on server with both network interfaces .
Domain controller is up for all subnets.
VLAN1 is main office with many computers (and users). VLAN2 in highly secured area for developers only.
VLAN1 users use TFS for posting bugs, viewing progress etc. VLAN2 users use it at full.
The problem is - to restrict access to sources from VLAN1 even for developer user accounts.
Denying access to TFS from VLAN1 for developer users - is valid answer too, but i do not know how((
Any ideas??
EDIT - From comment to answer from #Robaticus
The point is to restrict reading sources from outside.
If you block (at the network) port 8080 (the default), users won't have access to TFS through Team Explorer, only through the website at port 8090 (also the default).
Valid users would still be able to view source through the web portal, but would not be able to update it.
EDIT
Based on the requirement to restrict reading of sources from people outside, if you first do what was mentioned above (blocking 8080), you could always secure the directories for the source control under Team System Web Access. This might be a little ugly (giving 401 errors), but it might work.
It looks like the directory that would need to be secured is under the website:
Team System Web Access->UI->Pages->Scc
This would remove source code browsing from the Web UI for everyone, though. In my opinion, that wouldn't be a real problem, as this function likely gets used only rarely.

TFS and Forms Authentication

I don't know squat about TFS, other than as a user who has performed simple check in/outs.
I just installed it locally and would like to do joint development with a friend.
I was having trouble making my TFS web site on port 8080 visible (the whole scoop is here if your interested) and I wonder if it could be related to the fact that TFS is probably using Windows Authentication to identify the user.
Can TFS be set up to use forms authentication?
We probably need to set up a VPN, though that's a learning curve too.
To use TFS, do our machines have to belong to a domain?
We're not admin types, though he is better than me, though I would be interested in any feedback or advice on which path is likely to pan out the best. I already got AxoSoft OneTime working in this type of an environment and it suits us well, but I am tempted at all the bells & whistles with TFS and the ability to tie tracked bug items to code changes.
As far as finding a good way to share code, do sites like SourceForge allow one to keep code secure among members only?
It does not need to be installed in a domain. I'm running TFS at home within a workgroup on a virtual machine.
Create a user on the machine that hosts TFS. Let's assume this machine is named TFS-MACHINE. Grant that user appropriate Team and Project rights.
When connecting to TFS from the remote machine, the user should be prompted for a user ID and password. They should use a User ID of TFS-MACHINE\username and the appropriate password.
Regarding external spots to host code. If you're looking for cheap/free, you can look at something like Unfuddle, which supports SVN and Git.
If you're looking for hosted TFS, the only place I've been able to find thus far is SaaS Made Easy, but they can start getting a bit expensive, depending on the number of users you have.
Keep in mind if you're going to host locally that you'll still need to do things like periodic backups, etc.

TFS remote users... SSL + Password or VPN?

I'm currently tasked with setting up a TFS server for a client. The TFS will mainly be accessed by local (on-site) users through the internal network... Easy!
But what about the few remote users we have? Should they connect via VPN or is it better to make the TFS server public and have the users connect over SSL and provide username and password to the TFS?
Do you have any suggestions on how these solutions will perform compared to each other?
VPN is the way to go if you want the optimal TFS experience with TFS 2005 or TFS 2008. While TFS mainly uses web service based protocols that can all go over SSL, there are a few small things that will not work unless you have proper network access. For example:
Viewing the Build Log (unless worked around)
Access Team Build drops
Publishing Test Results
As well as a few other little niggles. Going the VPN route will also mean that your TFS installation will vary less from a standard base TFS installation which gives you some peace of mind that you won't run into any problems when it comes to upgrading to a new version, applying service packs etc. (or at least any problems you run into will have been run into by many before :-) ). Going the SSL route you are treading a less worn path - though obviously plenty of people do run it that way including CodePlex and all the commercial companies that provide a hosted TFS installation.
The downside of VPN is that usually you are granting users to an entire section of your network (unless you are running TFS in it's own mini private network or something). If you go down the SSL route then be sure to properly test the new team projects as this is easy to break and you might not realise until you try and create one either inside or outside the network.
For additional information, see Chapter 17 of the TFS Guide.
I'd start with a few questions: does the client have a VPN? And are the remote consumers on this VPN already? How secure does this need to be?
(In our case, we have lots of outside vendors we don't want on our VPN, so our source control is publicly accessible with SSL)
When I did it, I used a VPN. Was easier to setup, and made sure that no-one could even see the machine with out being authenticated via the VPN - this was obviously way better from a security standpoint, which trumped any performance benefit we would have got from using SSL, if there even was one...
My previous experience with TFS was in an environment where we had a team of developers staffed out at client sites all over the city. In many situations we still accessed our TFS instance instead of something at the client site. We used SSL with public access to TFS. It worked very well for us.

Resources