We've transitioning from Rackspace dedicated boxes to a completely cloud Azure environment. Production servers and development and as an MS shop we're going to be using Visual Studio Team Services. As an MS ISV partner we have a bunch of MSDN seats so our developers are all going to have an MSDN w/ VS Premium account which we'll use with Team Services/TFS. We're replicating our production web server on a virtual machine but after some refactoring will eventually move to an Azure website.
My question is about when users leave the company. Right now we have everyone log into a development server using RDP. They develop on that server. When someone is gone we shut their access off to that server.
With Team Services when the user opens up a project do they automatically get the entire project downloaded to their local development environment/machine? If someone leaves the company is there a process using VSO that secures that code and removes it from them or makes it inaccessible? Any way to lock it down when we need to? I can't seem to find a procedure to do this.
To add or remove someone from the account, go to the Users hub on the home page for your account. If you remove a user from it, that user will no longer be able to access your account.
When users connect to your account, they'll need to take some action to get source code. That would be cloning in the case of using Git or creating a workspace and running get for TFVC.
If the user has source code, for example, on a machine, there is no way to remotely remove it. They won't be able to get updates, etc., but there's nothing running on the computer that would be able to erase the code the user has already obtained.
All source code sharing i know allow zipping up or browsing the local repository. Including VS Team Services.
Daniel Mann is correct . Developing on shared servers via RDP is terrible for productivity due to development being graphics and disk intensive, often requiring admin rights and reboots / crashes, debugging triggers system interrupts, out of memory loops are fun on a shared machine ie they stuff everybody else around. (Even with RDP you can copy and paste or map a network drive locally or upload to the net )
If your doing critical stuff the ONLY thing that really works is physically bring them in to non internet connected machine /network with USB disabled. However these mechanisms especially denying internet will half productivity.
This is why most organizations rely on legal contracts. On a 2M project is it worth making it a 4M project? There are cases where this is required normally around national security /CIA / Defence but not for IP, there are better / trickier ways.
Pretty much all binaries are reverse engineer-able with little effort if you really want to. obfuscation does very little.
Related
I have TFS 2015 installed on one of the company's servers. I try to access TFS using web access and it is extremely slow, it takes more than 5 minutes for a page to load and sometimes even longer. If I restart the server, TFS becomes a little bit faster (a page would need only a minute or so to load), but soon it becomes slower.
The server itself is okay. The CPU and memory are not even fully utilized (~20% - ~40% is utilized).
Other applications that are installed on the server are working fine, so it's just TFS.
Any suggestions?
Log in the application tier machine to try to access the web access to see whether you can see the same behavior.
Check the network connection between the application tier machine and data tier machine if you set up TFS in a multiple server configuration. You may try to turn off the firewall and anti-virus software on the machines.
Clean the cache folder on the application tier, usually the folder locates in: C:\TfsData\ApplicationTier\_fileCache
Check the Requirements and compatibility, to see whether your TFS set up on a appropriate environment.
If the items above is not helpful. You may need to consider move your TFS to another hardware.
Suppose we have a machine shared by many developers. Developers have access to different parts of the project, they don't see all the same complete source code. Suppose also that we use this shared machine even to test job interviewer on some test programs.
How do we protect source code in the local workspaces? I mean, we wouldn't want that developers/job interviewer are able to see/copy what they are not allowed to. We use Visual Studio & TFS 2012 in a Windows environment.
Thanks.
If your users do not have admin permissions, you could store the workspace in the users profile. So it is only accessible for them (and administrators). But you should be careful with this, because the size of the profile could grow extremely, which would have effect to your login time on other machines. Also some companies set a max size for profiles, which could be exceeded fast using this method.
Another option would be to store the workspace on a network share, which has personalized permissions.
Recently our Development user group (Windows) has started showing with a Red Cross in Team Explorer and we cannot expand it anymore.
I have tried removing and re-adding the group but to no avail.
Does anyone know why it would display like this?
We are using TFS 2010 with VS2010 SP1 and August's Power Toys.!
BTW, "Technical Testing Team" is another Windows Domain User Group, just like Development and that works OK.
In general, the red crosses on particular services are caused either by that service being unavailable or by permissions issues...
Are you still able to perform actions that require admin permissions? Does this apply to a single project or all?
How are you defining your developers? A windows domain group? If so, is the TFS server able to see the DC?
I'd suggest you try installing Team Explorer on the TFS server and running it when logged on as yourself - see if you have the same problem. If not, it may be network or firewall problems between your dev machine and the server. At least it would narrow the problem down.
Edit 1:
Do reports work properly? (Specifically, do the graphs show up in reports)?
What auth are you using? Kerberos?
What account is TFS running as? What permissions (if any) does that account have on the network?
Can you see the security information you'd expect in the TFS_Configuration database? (Try tbl_SecurityAccessControlEntry) [Usual "Change nothing, do it at your own risk" disclaimer]
Edit 2:
As per the install docs, the TFS service should be running under its own account (IIRC they suggest Domain\TFS.Service). Check the permissions on the windows services on the TFS Server and see who they're running as. Makes sure the permissions for that user are correct as per the installation instructions
NTLM can cause problems as it doesn't allow credentials to be delegated/relayed the way Kerberos does (and has some picky setup requirements) - but that's obviously not why it's broken all of a sudden (and that usually manifests as graphs not displaying in reports).
WRT: the SecurityAccessControlEntry table, I was more interested in making sure there were entries and that it could be read properly than the contents.
I assume you've tried deleting/recreating groups - If not, give it a shot (deleting the domain group may be an issue with other services but try using a different (new) group and removing the old one from TFS entirely)
I have to admit I'm running out of ideas after that. If it were me, I'd try a clean install on a new server/VM and either point the new install at the old data store [multiple server setup] or export/import projects [single server setup].
For Multiple server setups, this would determine if it's a TFS installation issue/data corruption. For single-server, there's a good chance this would just clean up the problem. You could, of course, also ex/import on multi-server too if it does turn out to be a data thing.
You may want to hang on to see if someone has a less drastic solution.
Looking in the General tab of the VS Output windows there is a message:
Skipping loading group Development into Team Members because it has 102 members.
Looks like VS has a limit on here.
I'm currently working on a migration from svn to mercurial. My needs are plain and simple, I need source control over an intranet in our company. I see examples everywhere for setupping remote repos over IIS. I just don't see the point when I can just make a share on a server.
Can I still setup authorizations and authentications on repos using NTFS permissions?
Am I missing something?
Thank you
Putting a repository on a file share works, but it's not the way recommended by the Mercurial team.
See the "shared disk" part of Publishing Repositories on the HG wiki:
generally restricted to intranets, not generally recommended due to general issues with network filesystem reliability
Be sure to check out Chris Becke's answer as well, because he points out another valid disadvantage (people with write access deleting stuff from the network share, be it intentionally or not).
If you are aware of (and can live with) these things, putting the repositories on the network share is without a doubt the easiest way to setup.
My personal experience is that it works perfectly as long as the Windows share is on a "real" Windows machine.
At work we're using a share on a real Windows server without problems, but at home I ran into issues with a NAS (which behaves like a Windows share but actually runs on Linux).
You can read more about my experiences here:
Can you 'push' to network share using Mercurial on 64bit Windows 7?
There are a number of reasons to prefer, well, anything at all to a writable file share.
In essence it comes down to, there is a limited amount of damage someone can do with the ability to do a push via a web-method.
A read/write share on the other hand is necessary to do a push, but also allows a user to delete an entire repo, history and all.
Without even invoking malicious intent, people (or rogue software agents) have been know to navigate to random network shares and accidentally drag a file to someplace it doesn't belong.
The best reason to lock your PC is not because your co-workers find it amusing to use an unlocked email account to send porn to HR, but because its amazing what a cleaning lady can do with a rag and a keyboard. Its also amazing what Music Library applications can find while scanning all shares in a workgroup, and carefully "move" and catalog to someones Library.
So we decided to go with visual studio team foundation server for version control, etc. Getting ready to deploy today and read in installation guide:
"You cannot install Team Foundation Server on a domain controller or a computer that is running other server products such as Exchange Server or Host Integration Server."
That and other comments in the guide lead me to think ms does not want me to install tfs on anything other than a server dedicated soley to hosting tfs (ie don't put it on one of my front-end webservers or backend dc).
I am planning on doing a single-server deployment (mostly for simplicity). Can anyone verify that tfs has to be on a dedicated machine? If so, should I virtualize it and hang it off one of the front end machines?
Thanks all...
Performance is pretty important for TFS - check-ins, for example, should be pretty instantaneous or it can have a dramtic impact on developer productivity.
That said - it doesn't need a lot of horsepower - here's a link to the Server Requirements My current client is going "Virtual" - there should be no reason not to - assuming you know how to "tune" your virtual servers to perform equivilantly to the stated hardware specs.
One of the key things to remember, ALL data in TFS is stored in SQL server, so anything running on the same hardware that can affect SQL Server performance will affect TFS's performance. That is why it's important to have Build Server(s) distributed on another machine. Software builds are VERY "File-System" itensive operations and can have a very negative impact on SQL Server performance - hence why it's important to move that off to another "box"
From my experience this is because of the user membership that comes with a domain controller where creating the necessary TFS groups on the domain controller gives incorrect permissions.
However, there is a workaround:
Installation of the TFS Data Tier
Components on a Domain Controller
Copy the contents of \dt in a temp. directory, e.g. C:\TEMP\dt.
Open the file hcpackage.xml in Notepad or any XML capable editor
Search for the phrase “domain controller”.
Change the first WQL after the first match to
<WQL
namespace="\\.\root\cimv2"
query="SELECT * FROM Win32_ComputerSystem WHERE Domain !=''
AND
DomainRole >3"
action="="
count="1"
/>
You have to change count="0" to count="1".
Restart the setup.