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.
Related
TFS user management has been changed to small purple box(link taking us to visual studio page), how do we maximize and bring back it regular view.
Apart from this users tab everything else looks okay.
How do we resolve this issue, is it normal behavior of TFS ?
Could not reproduce it with the same TFS version. Suggest you also try some more client machines to see if the issue exist, if not this should be a client side issue.
Sign out your account, use another account to login the web portal, and take a look at users page if you got same result.
Besides you could also try with some other browsers IE/Chrome/Firefox to narrow down the issue.
If this is not a client side issue, since the web portal is automatically installed and configured when you install or upgrade TFS. You could check the Event View on TFS server machine if there are some error message. Select a recently TFS server backup and restore it, this may do the trick.
Found solution for this issue.
The thing causing the issue is URL SCAN that was installed along with IIS.
it is blocking certain requests on TFS and some css(which caused change in TFS user management view)
Once after removing this from the IIS, user management view came back to normal.
First off, I read all other Questions, that relate to this, I did an extensive google search on this topic and could not get a working answer.
I installed the Community Version of Visual Studio 2015 in mid November and been using it since then. After finishing my project, I went back to pen and paper for new formulas and noe came back to implement all those neat things.
Now it says, that my trial license has expired and should be renewed. I already read, I should use my MicrosoftAccount to do that, and proceeded by doing that.
Now this happened
It says, I should check firewall and prxoy settings and I read about contactiong the administrator. So that, what I did, but he says, there is no proxy, no block by firewall or anything else.
When running VS as administrator (after entering my credentials) I can create new projects and debug existing ones, so no problem there. However I can not use the program as normal user.
I read somewhere here to try repair it via systemcontrol, but that did not work either.
Does anyone has a solution?
In addition: There is also no "Enter License Key here" field, so that is also not an option.
(several Days later)
Halleluja, I found the answer! After digging through some Microsoft Help-Forums, I came upon this Thread, that not only perfectly describes my problem, but also gives a solution. So dear visitor from the future, who googled the problem and came upen this Stackoverflow Question: Follow the link above!
So, after sniffing packets harder than a drug addict, trying to find a difference in TLS exchanges between my computer and VS licensing server when using a domain account and when a using local account, and noticing no difference, I recalled why I had pushed this hypothesis to the side: our network supports TLS 1.2 perfectly well, as I can connect to TLS 1.2-only remote hosts without any issue.
This means the issue lies elsewhere, and is caused by Visual Studio treating domain accounts and local accounts differently when trying to renew licensing information.
The good news is I've found why and how to fix it.
I recalled that earlier this year, when we upgraded our commercial department from Windows 7 to Windows 10, they all encountered issues while trying to configure their mail accounts on Microsoft Outlook: an unknown error 0x8004011c. If you search around for it you'll quickly find that this only happens when using domain accounts and not when using local accounts (sounds familiar, heh?). The fix to bypass this issue is to set a specific Windows cryptography-related registry key.
When digging a little deeper, you can find that this fix is related to KB 3000850 (which I sadly cannot link to due to my account not being verified) and is actually described in the "Known issues" section, as well as in Samba-related documentation ("Required Settings for Samba NT4 Domains").
In short: Windows 8.1+ clients (with KB3000850) joined to an NT-Style domain are not able to use Windows Credential Manager. This doesn't occur when not using a NT-Style domain. The fix seems to globally authorize using Windows Credential Manager whatever the domain context.
So, to wrap it up, if:
You have a NT-Style domain (such as when using a Samba domain controller)
You have Windows 8.1 or later
vYou encounter issues when renewing your Visual Studio license
Then, set the following registry key:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Protect\Providers\df9d8cd0-1501-11d1-8c7a-00c04fc297eb]
"ProtectionPolicy"=dword:00000001
This solved the issue on our domain, for all machines and accounts tested.
As to why Visual Studio 2015 needs to use Windows Credential Manager and not Visual Studio 2013, someone from Microsoft will have to chime in there to explain because I have no clue.
You are using a very old Samba server that uses unsupported features. NT4 came out in 1995. Active Directory didn't exist back then. A lot has changed in the last 20 years, including strengthening security and gradually removing older, less secure features like LanMan and NT4 domains.
Instead of weakening security, you should follow the advice posted in the page you linked, Required Settings for Samba NT4 Domains:
Microsoft discontinued the official support for NT4 domains in their Windows operating systems. ... Anyway, consider migrating to a Samba Active Directory (AD) to avoid problems if a future update from Microsoft disables or removes the unsupported NT4 features.
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.
We are working with Visual Studio 2010 and Team Foundation Server 2010. We did not have any problems for about half a year, but:
Since a couple of days we get the following error: Team Foundation services are not available from server (...) The remote name could not be resolved; (...)
The problem occurs randomly (we are unable - yet - to pinpoint the conditions on which it occurs) and persists until we restart Visual Studio. The problem occurs about 8 times per day per developer.
Because we seem not to get past this problem and we cannot find anybody writing about this specific combination (the error and the 'remote name' part), I thought it wise to ask you guys about it ;) . Could anyone please help?
This is a client, server or infrastructure related problem on network level. The DNS entry for your TFS server cannot be resolved correctly at times for host dfz-vm223.
Suggestions for troubleshooting:
On some developer systems, replace the hostname dfz-vm223 by the ip-address of the TFS server. If the problem stop occuring there the DNS system is instable.
Setup a continuous ping stream (ping -t dfz-vmm223 from command window) and see if the host system is pingable in case you have TFS server problems.
Just found out what the problem was: the problem is proxy related. When we disable our proxy, the problem is gone. It appears our proxy and TFS are troublesome together. If anyone experiences the same problem and you are working with a proxy server, I would suggest you try disabling the proxy too.
I had the same problem, although I'm using VS2012 and a WAN connection to TFS.
I solved the problem by flushing the DNS cache.
To flush the DNS cache, start a command prompt with admin rights: ipconfig /flushdns
You need to do this in all the computers where the problem occurs.
I know this is old, but I had this problem sometimes when I ran Fiddler.
Sometimes Fiddler would crash or not clean up properly and the whole machine would get into some weird state where not even reboots were helping. The solution to it usually is to start Fiddler again, turn off any interceptors/collecting traffic and shut it down again.
Some of my co-workers and I had this problem as well. Out of about 25 developers, most never got this error. But three of us got it pretty consistently. The symptoms are identical, but we are using Visual Studio 2013 almost exclusively. In this version of Visual Studio, the error is preceded by the code: TF400324.
We found eventually that the three of us had all installed Productivity Power Tools 2013. And the developers that were not affected by this error had not installed it. Most had not heard of it. This used to be a very popular extension, so I have always installed it as I set up my system since about 2007. But apparently, in its modern incarnation in Visual Studio 2013, perhaps in combination with some quirk in our network or something, it can cause this problem. We have each uninstalled it, and have not gotten this error since. (It's been several months now.)
If you have this extension installed, you probably already know about it, because you probably installed it yourself. You probably started using it years ago, and it became a habit to add to each new installation. You will find that today, the default installation of Visual Studio actually includes most of its features already. To uninstall, go to Tools --> Extensions and Updates... Then click on Productivity Power Tools 2013, and click Uninstall.
Hade the same issue. For whatever reason the windows DNS Client service on my PC wasn't running. Changing it from Disabled to Automatic solved this problem for me.
Too long for comments:
First off, as #kroonwijk stated, this is an infrastructure issue. Your DNS queries are either timing out or the DNS server is not responding at certain times.
In a comment you mentioned a change over from regular machines to laptops for your entire dev team. If I had to make a bet I'd say that the DNS configuration on the laptops is not the same as what you had on the other machines.
You need to take this up with your infrastructure people. If you still have access to the older machines boot one of them up and compare the IP configuration. If not, get them to fix the problem. The DNS resolution problem could be any one of a number of factors. For example, the new machines could be pointing to an incorrect DNS server that has network issues or their might be some incompatibility between how Win7 makes DNS requests and your DNS server.
I have also experienced this problem and it doesn't always have to do with name resolution.
If you add an entry to your %systemroot%/system32/drivers/etc/hosts file for your TFS server, it removes any dependance on your name resolution servers.
If you are still experiencing the problem, then it has to do with either visual studio or one of the VS Extensions that you are running. There may be a memory leak somewhere. Disable all your Extensions using the extension manager, restart VS, and see if you still experience the problem.
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.