I am using VSSConverter.exe to migrate from VSS to TFS (About time too). I am having an issue because the account I am running it under is not on the same domain as the TFS server. Is there any way to tell the VSSConverter.exe tool which server account to use?
For example when I use the tf command line I add the /login:myname,mypassword switch like this:
C:> tf dir $\ /login:myname,mypassword etc...
Is there some way I can do the same with the VSSConverter.exe?
The error I am getting by is this:
TF60071: Your user account does not have permission to connect to the Team
Found ation Server 'https://www.example.com/tfs/DefaultCollection'.
Please contact your Team Foundation Server administrator and request that
the appropriate permission be added to your account.
VSSConverter.exe will try and connect to TFS with the account that it is currently running as. Sometimes that account cannot be added to TFS, or used with TFS - e.g. There is no domain trust between the two domains.
To specify alternate credentials, you can use the windows credential manager to store them. VSSConverter will then try and use these to connect to the server.
In Windows 7, you can do this:
Control Panel > User Accounts > Manage Windows Credentials > Add a Windows credential
Network address: www.example.com
User name: DOMAIN\user
Password: Password
You can also get to it by going to:
Start > Run
Type: **rundll32.exe keymgr.dll,KRShowKeyMgr**
Related
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.
I installed TEE-CLC-11.0.0.1306 onto my Windows Server 2003 R2. I am able to perform TF commands in the command line successfully. But when I set the TF_AUTO_SAVE_CREDENTIALS environment variable, I get this error:
A client error occurred: The credentials cannot be saved to the active credential manager (Null Credentials Manager). You must manually configure stored credentials for this mechanism or specify credentials a different way.
I opened the "Stored User Names and Passwords" tool by running: control keymgr.dll
and I can't seem to manually create the credentials. On my Window 7 machine, the TEE credentials are stored properly and working, so I went to: Control Panel\All Control Panel Items\Credential Manager to look at the entry for TEE as an example, but it didn't exist.
Why can't the credentials be stored by the 'tf' command after setting the environment variable?
Is the issue related to the OS (Windows Server 2003 R2)?
Where are the credentials stored when this is properly enabled? (I can't find them on my Win 7 machine.)
Is there a way to manually create the credentials on the Window Server 2003 R2 machine, as the error message suggests?
The Team Explorer Everywhere command-line client cannot save credentials on Windows. Team Explorer Everywhere, like Visual Studio, uses the Windows credential manager to persist credentials. Credentials stored in Credential Manager will override your domain credentials if you are domain-joined or a shadow account.
Simply open the
Credential Manager and add credentials for the TFS server.
(Technically Windows is not a supported platform at all, we would recommend you use the actual TFS command-line client, part of the Team Explorer installation. The above steps work for it, too.)
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\
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.
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.