Is there a way for our development team to point Visual Studio at an instance of TFS on another domain?
Pretty green when it comes to Team Foundation Server and not sure if this should go in the overflow that handles IT admin stuff (from my understanding stackoverflow is more code related).
We just got bought by another company and they want us to use their TFS that resides on their domain. We are working on getting to one domain, but in the mean time we still have two separate domains that talk enough to get by.
Just as Daniel said, just make sure there is a trust relationship between the domains.
Generally if you can access the TFS that resides on another domain with you current domain user, then everything should be OK.
More information please see Trusts and Forests Considerations for Team Foundation Server and Grant the Allowed to Authenticate permission on computers in the trusting domain or forest for details.
You can also reference this related thread : TFS Cross-domain authentication without trust
Related
My organization serves the application development needs a number of different companies. When we develop an application for a company, we typically have users from that company perform the testing.
If we were to use TFS Web Access for testing, are we able to transfer the CAL license from one company's tester to another once a project has been completed? I couldn't find anything about it in their licensing whitepaper.
From the TFS licensing whitepaper:
if the contractor is using the client’s Team Foundation Server then
the client must supply a Team Foundation Server CAL for the
contractor’s use. This could be a CAL purchased separately or a CAL
that is included with the MSDN subscription that the client assigns to
the contractor temporarily.
So yes, it appears you can transfer CALS to different users as long as only one user is using the CAL (accessing the server) over any given period. (I think a "user" is not locked down to a specific individual)
However, this:
Team Foundation Server CALs are only valid for accessing a Team
Foundation Server acquired by the same organization
...implies that your customers cannot use your CALs, so would have to purchase their own.
It may be possible (from my reading of the white paper) for you to get a Device CAL, assign it to a laptop, and lend the laptop to your customer. But it'd be best to ask Microsoft to confirm that.
However, if your customers are only using the web interface for test feedback (limited to basic work item operations such as reporting bugs, responding to feedback requests, and viewing reports) they will not require a CAL. Clearly Microsoft recognises that your customers will need to be able to interact with your server to report bugs and feedback.
But ultimately if you're not sure, ask Microsoft to give you a clear (and legally watertight) answer. You can read the licensing documents until you lose the will to live (or even more than 3.2 minutes if you must), or ask a thousand of us to post our interpretations, but you won't know for sure unless you get MS to provide the actual answer.
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.
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.
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.
We're using TFS for source control and are trialling using the TFS work item tracking. I am trying to find out, is it possible for people who don't have visual studio installed to access, create and edit work items via a browser based user interface?
Our technical support team need to be able to use work items. TFS work items won't be suitable for our company if the support team and project managers can't get sufficient access.
I'm not familiar with how the licensing works either. If there is a way for non visual studio users to use TFS work items, will they need a license?
The are a number of choices (most costing money):
Team System Web Access
Team System Web Access (formerly known as TeamPlain) is a Web interface to Visual Studio 2005 Team Foundation Server. Team System Web Access is available as a free download for existing Team Foundation Server users, and will be incorporated into a future release of Visual Studio Team System.
Work Item Only View
Team System Web Access provides a work item only view that restricts functionality so that you can create and view only your own work items. This view is designed to facilitate working with Team Foundation Server when you do not have a client access license (CAL). You do not need a CAL to create new work items or to view and update work items that you created. The work item only view restricts functionality so that you are in compliance with this aspect of the Team Foundation Server end user license agreement. For more information, see Visual Studio Team System 2008 Licensing White Paper.
Outlook integration (from Brian Harry's blog)
Integration of Team Foundation Server work items into the Outlook user experience continues to be a popular area for innovation. Just recently an author sent me mail about a new one called Wit-It! that enables work item forms to be easily opened from TFS work item change notifications. It's not entirely unlike configuring links to Team System Web Access from event notifications but it uses local rich client UI that some will like better.
There are several other Outlook extension offerings out there with varying levels of completeness. If it's an area that iterests you, you can also check out:
TeamExpand
TeamLook
TeamCompanion
And I appologize if I left any out. As I say, clearly there is a lot of interest here and some creative people.
Team System Web Access is a good web-based option for non-visual studio users.
There should be a web interface, both a website and a SharePoint portal that gets installed with TFS. The portal will let you get to the documents and view some reports. The website will let you work with the documents, the source control, work items, and bug reporting.
As far as licensing goes, a full-blown TFS user requires a TFS CAL (in addition to the normal Windows Server CAL).
However, for particular types of 'light' users a TFS CAL might not be required (I'm not sure, but I'd think that a Windows Server CAL would still be required). See http://blogs.msdn.com/bharry/archive/2007/11/23/tfs-licensing-change-for-tfs-2008.aspx for some details.
As always, MS server application licensing requirements are often quite complicated - you will need to do your own research (probably in consultation with MIcrosoft) to determine your actual licensing requirements.