BEFORE: I had a TFS 2010 on a temporary test environment set up with a project and I had web users and everything worked great.
NOW: I've installed it on a permanent environment (same O/S, domain, everything) but any permissions I set no longer seem to have any effect.
It seems only the service account can access any features.
Authentication is NTLM.
Any network users I give access to are either being asked for their credentials to connect to the server and being rejected regardless (they can connect to the default IIS fine) or they get:
500 - Internal server error.
There is a problem with the resource you are looking for, and it cannot be displayed.
Ridiculous, but the problem is that the new install was on the E: not the C: so the local NETWORK SERVICE account (that I use as a service account for TFS) did not have access to the files/folders under \Program Files\Microsoft Team Foundation Server 2010\
Related
After updating from TFS 2018 v3 to DevOps Server 2019.0.1 last weekend I now receive this authentication error when attempting to manage security:
TF30063: You are not authorized to access tfs.
I receive this error when attempting to manage security from the Server Administration Console via Application Tier > Administer Security. I also receive the error when I attempt to set permissions via tfssecurity cli tool. I am in the local administrator group and I am listed in the console administration user section.
I'm trying to set permissions because after the update I received several reports from employees that receive errors when they try to access their projects. Those errors are:
TF40049: You do not have licensing rights to access this feature: Code.
*** Edit: Update
This error reoccurred when I upgraded from 2019 to 2020 RC1. The difference is, this upgrade required a migration of the server- since server requirements changed for the new version of DevOps Server.
I spent 8 hrs working through this issue yesterday, and this is what fixed our problem:
deleted DevOps server cache. (location of cache listed in devops admin console on server)
reboot server.
I deleted the cache off the server based on an article I read with the same error, a user was having security/permissions issues with visual studio and they deleted the vs cache on their local machine and it solved their problem. I don't know if deleting the cache or the reboot would have fixed it independently because I did them both as a single troubleshooting step.
Hope this helps someone.
** Edit: Update 08/13/20 **
After upgrading again, I have ran into the same issue and this does not fix my error anymore. I've tried deleting the server cache, rebooting, reapplying permissions, configuring a new service account, reapplying changes, rebooting again, etc. I still have not found a solution for this error. I cannot schedule backups through the supplied backup scheduler without permissions to manage security settings through the configuration panel.
I have TFS 2010 set up on TESTServer.
If I am on the server (logged in as administrator) I can access the web portal for TFS using the following
http://TESTServer:8080/tfs/web/
but when I am on my own computer still in the same network, when I try the same URL, I get challenged for a username and password. Even when I enter the administrator details, it does not accept them.
Also I tried the following
http://TESTServer:8080/services/v1.0/ServerStatus.asmx?op=CheckAuthentication
Which says the resource can not be found
* update***
I got it to work with the IP address... but if I ping the name it gets the correct IP address??
Any ideas?
Thanks
Since you cannot connect to http://TFSSERVER:8080/services/v1.0/ServerStatus.asmx?op=CheckAuthentication it could be that you have incorrect proxy settings in your organization. Could it be the proxy settings have changed?
Have you checked your host file for any entries regarding your TFS server?
Can you open a telnet session to port 8080 on your TFS Server?
Grant Holliday wrote a couple of steps you can do to troubleshoot TFS connection issues.
After DCpromoing and then demoting the server that TFS runs on, we cannot use WSS ("Cannot connect to the configuration database") to manage team projects. I believe that if I could find the default permissions that are set up when TFS is first installed on a server that is joined to a domain - in terms of any service accounts that are created and which accounts various services should run as - I would be able to get it back up and running again. Does anybody know the default NT accounts and permissions for Team Foundation Server?
That error sounds like a SharePoint error. This technet article outlines the permissions (server, SQL, registry) that are required for a default WSS install.
Is anyone successfully using MsDeploy for deploying windows services with a preSync runCommand? I've got it working using an Administrator account, but can't for the life of me get it working on a standard user account. Unfortunately I can't use integrated authentication (we're deploying to an external box), and the thought of our Administrator password sitting in plaintext in logs on our build server doesn't exactly make me feel too comfortable. For that matter, neither does any user credentials - but I can't see a way around that.
The command I'm using is this:
"tools/deploy/msdeploy.exe" -verb:sync
-preSync:runCommand="tools\Deploy\PreSyncCommand.cmd",waitInterval=30000
-source:dirPath="C:\BuiltSourcePath"
-dest:computerName=https://server:8172/msdeploy.axd?site=dummysitename,userName=service-deploy,password=service-deploy-pass,authType=basic,dirPath="C:\DeployPath\"
-allowUntrusted
with rules set up in IIS for the dummy site to allow the authentication for the service-deploy windows account, with contentPath and runCommand permissions (for the moment set to C:\ as it's not entirely clear whether this needs to be set to the temporary path that MsDeploy streams to, or the deployment path?). The service-deploy account also has full control of the target directory. I get the following back:
Performing '-preSync'...
Info: Using ID '7a7d34a1-b5d8-49f1-960a-31c9cf825868' for connections to the remote server.
Info: Using ID '4d0b910c-aca4-4640-84bd-3597d22d99d1' for connections to the remote server.
Info: Updating runCommand (C:\TeamCity\buildAgent\work\aec989676b349656\tools\De
ploy\PreSyncCommand.cmd).
Warning: Access is denied.
Warning: The process 'C:\Windows\system32\cmd.exe' (command line '/c "C:\Windows
\ServiceProfiles\LocalService\AppData\Local\Temp\giz2t0kb.0ay.cmd"') exited with
code '0x1'.
This happens even if the contents of PreSyncCommand.cmd is blank. The same command runs fine if I pass in Administrator credentials. I've tried using ProcessMonitor to check if anything's being denied access but can't see any - so I'm guessing it's still a MsDeploy authentication rule. There's nothing in WmSvc.log (debugging is enabled), nor in the event log.
Any ideas? Thanks!
Since you're using Web Deploy via WmSvc, you need to setup appropriate delegation rules on the destination server:
Within IIS Manager, open the "Management Service Delegation" feature. Add a new rule which at least specifies the runCommand provider. In the Run As section, choose Specific User and provide credentials for a local administrator account on that machine. This is the identity under which your runCommand scripts will be executed. Finally, the user which you're specifying for the destination dirPath provider needs to be added to the delegation rule.
That allows you to invoke a deployment using a non-privileged account, and yet have it executed on the target machine under administrative credentials.
More information on IIS feature delegation: http://learn.iis.net/page.aspx/516/configure-the-web-deployment-handler/
I'm trying to install Team Build (2008) on a different Build Server (BS) to the Application Tier (AT). BS is a 32-bit Windows 2008 server (as is the AT). They are on a corporate domain.
The EXE in question is
C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies>
TFSBuildService.exe
The service on BS cannot start - the error is "Windows could not start the Visual Studio Team Foundation Build service on Local Computer\r\nError 5: Access is denied.". There is NO additional information in the Event Log. It is set to run as DOMAIN\TFSSERVICE account, which is also added to the Local Administrators group. It fails very quickly.
When I try to run it 'interactively' - the error on the command line is "Program too big to fit in memory".
It seems to me like this should be a fairly simple thing to set-up and use. What am I missing?
Notes:
I got my .config from Buck. I'm pretty sure I've correct set the ports, Windows Firewall rules
I can access the web services on AT from BS via Internet Explorer (using the DOMAIN\TFSERVICE login)
I've added DOMAIN\TFSSERVICE user to a TFS project's Build Services group
I have checked DOMAIN\TFSSERVICE has full permissions on pretty much everything on the Build server.
Try this:
Associate the default port to the new build service account using the wcfhttpconfig.exe command-line tool located in the following folder:
C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies
Execute (from the folder above):
wcfhttpconfig.exe reserve DOMAIN\UserAccount 9191
Full credit from the following post:
http://wesmacdonald.spaces.live.com/Blog/cns!25108A9ADA96C9D7!1553.entry
I suggest you should set up a dedicated TFSBUILD account and not use the TFS Service account for this task as a best practice.
OK, the fact that you can access web services using the TFSSERVICE account from BS through to AT is a good thing, I am making the assumption you have created a LOCAL account on the BS machine for the TFSSERVICE account?
If not, please:
add a LOCAL account with the same name as DOMAIN\TFSSERVICE.
ensure that the password matches that of the DOMAIN\TFSSERVICE account.
ensure that account has "log on as a service" right under Local Security Policy.
Please read article: http://social.msdn.microsoft.com/Forums/en-US/tfsbuild/thread/d519b8e3-451a-4f07-97b1-e2943c2756c2
My issue was that my passwords for the AT and BS machine had to MATCH on the same domain. Please double-check that the TFSSERVICE account password matches on both the AT and BS machine, as the service will use impersonation when on the same domain.