When we submit a Work Item to the TFS web service API, the following exception string is returned:
"The following error occurred:Access to the registry key 'HKEY_CURRENT_USER\ Software\ Microsoft\ Visual_Studio\ 8.0\ TeamFoundation\ Servers' is denied."
We have not encountered this before because (we think) previous calls have been using the local web service instance from Visual Studio 2005. We guessed this passes credentials. We also guessed this error is because the service (now on a remote server) is acting under IUSR or ASPNET.
We tried changing the permissions to the Registry branch to include IUSR and ASPNET but it did not impact the problem at all - same error string. We are using this feature to allow end users to submit bugs directly to TFS and the development team.
I hope the problem is clear enough.
Some attempts we have not tried are:
- Change the web service to impersonate a particular user {doubtful}.
- Apply DefaultCredential to web service.Credentials {maybe}.
- Make local\IUSR an Enterprise Admin on Production Domain {kidding}.
Thank you in advance for your help in this matter,
Submitting Work Item via Web Service API getting registry error
Bill Oliver
Jerry, you will encounter that message, "...Access to the registry key...is denied," if you are running a web service app that uses the client API but the user making the request doesn't have permissions and the service account running the web service can't access the current user hive of the registry (likely won't exist for a service account). What's happened is that the server has returned an error that the account is not authorized to access the server, and the client-side error handling code is trying to produce an error message that contains the display name of the server.
Buck
Wills
Using the object model, I have developed a quick prototype to deploy to our test server. Everything still worked fine on my local development machine. However, at the test server, I am now getting the following error:
TF30076: The server name (server) provided does not correspond to a server URI that can be found. Confirm that the server name is correct.
We have tried modifying the server name and that did not seem to help.
Are we still missing something
Thank you.
txc43
It's more a matter of impersonation - or in this case not impersonating. If, for example, I call the web service I expect it to impersonate me. I pass DefaultCredentials (from a WinForm) and don't allow anonymous (on IIS), but it still operates under IUSR instead of me. I return Environment.UserName and it's MY username! Somewhere there's a disconnect and we can't figure it out.
rwolinski
We have concluded that this is a matter of credential delegation. Because the credntial was being asked to make two hops from the client to the custom web service to the Foundation server; the second hop was in conflict with the domain policy.
We don't have a work around yet except to make all submissions impersonate a single user at the web service level and submit then or have the client bypass the custom service and speak directly to the Foundation server.
Needless to say neither of those is ideal. Any ideas for a work around other than those two would be warmly welcomed. We've hit this with other products and there are often undocumented methods that permit this by side-stepping how they impersonate.
Thank you.
Jandost Khoso
Anna, it is looking for the server name to be listed under the following registry key.
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0\TeamFoundation\Servers
There should be a string value there like the following.
servername = http://servername:8080
Baba urf Sivaji
One other possibility is that you could have the web application present the user with a "login" screen to supply user name and password, which would be used to construct a NetworkCredential object to pass to the TeamFoundationServer constructor. Of course, there are security issues to consider with that approach.
Buck
crazydrivr
Jerry,
Is there a special reason you are using the webservices directly
It's better to use the object model instead because that would take care of these things like authentication etc. Furthermore the object model is the documented way to interact with team foundation server and you should not build any extension on the naked webservices.
The object model is somewhat documented when you install the visual studio SDK. There a quite some samples you can use to interact with the team foundation server.
The objetc model is also very simple to use, so I would recommend useing that instead.
You can download the SDK at the following location:
https://affiliate.vsipmembers.com/login.aspx (you need to provide some info to get access,but it doesn't cost anything for affiliate membership)
Hope this helps.
Marcel
Akella
The web service runs under the account specified during setup. You can see it in inetmgr. That account should have permission to log on as a service. It may not. To quickly verify that it is a permission problem you could make that account a local administrator and try again.