I developed a webservice that I'm testing on my development machine using IIS. If I call the webservice from the local machine (http://localhost/BaanWeb/service1.asmx, click on the webservice) the debugger hits a breakpoint.
If I call the same webservice from a remote machine (http://ipaddress/baanweb/service1.asmx, click the webservice) the webservice is called, I see a value being returned, but the breakpoint is not hit, so I cannot debug.
You need to attach to the remote server (at "ipaddress"): http://msdn.microsoft.com/en-us/library/233w9kd4(v=vs.90).aspx
This article may also help (even though it is asp.net specific): http://www.codeproject.com/Articles/38132/Remote-IIS-Debugging-Debug-your-ASP-NET-Applicatio
Related
I have added this question on ServerFault but no one replied.
I have a .net application which calls a webservice deployed on my local windows server 2012 on IIS, and the sql server database resides on that server too. All employees connect to the same service and DB since we're all on the same domain, and I publish the app and webservice to the server through visual studio (2012).
Now I need to make employees access this application when they are outside the company's network, so I deployed the webservice on IIS on one of our remote windows 2012 servers, I created a public shared folder in my remote server and added to app webservice files to it and in visual studio I changed the publish method to web deploy and filled in the information as below:
Server: https://x.x.x.x/
Site Name: https://x.x.x.x/PublicFolder
Destication URL: https://x.x.x.x/PublicFolder/Application
When I click Validate Connection, it fails with the following message:
Could not connect to the remote computer ("x.x.x.x"). on the remote
computer make sure that Web Deploy is installed and that the required
process ("Web Management Service") is started. Learn more at:
http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_DESTINATION_NOT_REACHABLE.
Unable to connect to the remote server
Note that I tried to replace https with http and I got another error:
Could not connect to the remote computer ("x.x.x.x"). on the remote
computer make sure that Web Deploy is installed and that the required
process ("Web Management Service") is started. Learn more at:
http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_USER_NOT_ADMIN.
the remote server returned an error: (401)Unauthorized
I went to the previous link and I did what they suggested:
Create a separate user group MSDepSvcUsers on remote computer.
Create an local account A on both local & remote computer.
Add A to MSDepSvcUsers on remote computer.
Use account A to publish, this will allow you to publish without
needing to use built-in admin account.
but the same error (NOT_ADMIN) remained
UPDATE: I found another possible solution:
Add/modify windows registery key
“HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\”
and set it “1”.
After I added this registry key, the error changed to:
site 'http:' does not exist ... #ERROR_SITE_DOES_NOT_EXIST
So now if I put wrong credentials, I get the unauthorized error, if I use correct credentials I get side does not exist error.
What should I do?
It worked!!
I mean the connection, it's now validated, all I had to do is change site name from "http://x.x.x.x/PublicFolder" to "Default Web Site\SiteName" !!
This was really confusing, finally got it!
I have IIS (localhost:443) and Tomcat (localhost:8080) both running on my local machine. The Tomcat contains Java web services and I can remotely debug it in Eclipse IDE. I have an application installed in my IIS and when I access the page of that application, it requests a web service in Tomcat.
The problem is that when I try to load the page (the one deployed in IIS), my Eclipse won't go to the break point, meaning no request was retrieved on the Tomcat side.
But when I try to execute a request using SoapUI, Tomcat receives it and it enters my breakpoint in Eclipse. (meaning that the web services are accessible)
I cannot debug the application in IIS so I cannot determine why it can't call the web service.
Do I need to setup Windows Firewall for it? I'm just running those apps in my local machine.
Any ideas?
I got it working. My problem was permission issues in c:\windows\temp directory. I found my answer here http://nishantrana.wordpress.com/2008/02/06/unable-to-generate-a-temporary-class-result1-error-cs2001-source-file-cwindowstempfilenamecs-could-not-be-found-error-cs2008-no-inputs-specified/
I have a 3rd party webservice that runs by posting a soap message directly to a dll.
It runs perfectly on my development machine, but when I try and deploy it to Windows 2008 R2 64-bit using IIS 7 it fails, indicating error 404 2 1260 in the IIS7 log.
I have done all of the normal stuff, including:
Setting the ISAPI and CGI Restrictions,
Adding the Handler Mappings and setting them to Execute,
Setting Handler Mappings Feature Permissions to Execute
but none of that helps.
When I enable Failed Request Logging, the lowest-level detail that I can get is:
Error Code 0x800704ec
Error Code 2147943660
Error message IsapiModule This program is blocked by group policy
What is going on!?
The DLL was a 32-bit DLL.
By default, IIS 7 running on Windows Server 2008 R2 64bit doesn't allow 32bit dlls to run.
There's a little setting in the Application Pool Advanced Settings called Enable 32-Bit Applications. Set it to True in the application pool to which your web service belongs, and it should start working!
I have a web service running under IIS7 on a server with a host header set so that it receives requests made to http://myserver1.mydomain.com.
I've set Windows INtegrated Authentication to Enabled and everything else (basic, anonymous, etc) to Disabled.
I'm testing the web service using a powershell script, and it works fine when I run it from my workstation against http://myserver1.mydomain.com
However, when I run the same exact script on the IIS server itself, I get a 401-Unauthorized message.
In addition, I've tried installing the web service on a second server, myserver2.mydomain.com. Again I can call my test script fine from BOTH my workstation and from myserver1.
So it seems the only issue is when the client is on the same box as the web server itself - somehow the windows credentials are not being passed or recognized.
I tried playing with IE settings on myserver1 (checked and unchecked 'Enable Windows Integrated Authentication', and added the URL to Local Sites). That did not seem to have an effect.
When I look at the IIS logs, I see the 401 unauthorized line but very little other information.
I see basically the same behavior when testing with IE (v9) - works from my workstation but not when IE is running on the IIS server.
I found the answer after several hours:
By default, there is something called a LoopbackCheck which will reject windows authentication if the host header used for the site does not match the local host's name. This behavior will only be seen when the client is on the local host. The check is there to defeat possible reflection attacks.
More details here:
http://support.microsoft.com/kb/896861
The kb item discusses ways to disable the Loopback check, but I ended up just switching from using host headers to ports to distinguish the different sites on the IIS server.
Thanks to those who gave assistance.
Try checking the actual credential that is being passed when you are running on the server itself. Often times you will be running on some system account that doesn't have access to the resource in question.
For example, on your box your credentials are running as...
MYDOMAIN\MYNAME
and the server will be something like...
SYSTEM\SYSTEM_ACCOUNT
and so this will fail because 'SYSTEM\SYSTEM_ACCOUNT' doesn't have credentials.
If this is the case, you can fix the problem in one of two ways.
Give 'SYSTEM\SYSTEM_ACCOUNT' access to the resource in question. Most people would avoid this strategy due to security concerns (which is why the account has no access in the first place).
Impersonate, or change the credentials of the client manually to something that does have access to the resource, 'MYDOMAIN\MYNAME' for example. This is what most people would probably go with, including myself.
Now I want to prefix this with I am unsure whether this should be here or on server fault so I'll post it here to begin with.
We are developing a REST API in Coldfusion 9 which is being hosted on IIS 7 for a client which on certain calls must call another internal webservice. When making these calls from the server that the API is hosted on there are no errors, however when we make the call from a remote machine the following message is returned:
'connection failure. status code unavailable.'
I have googled the issue where the following was suggested as a fix http://www.talkingtree.com/blog/index.cfm/2004/7/28/20040729 but it does not work for me. The following are the notes from my own testing:
The calls which are causing the issue are a mix of get, put, post and delete.
The only common part of each call is the talking to the same webservice.
I am able to call the webservice directly from the places where I make the remote calls to the API from.
While all the calls make a call to the same webservice they do not all make the same call to the webservice.
Ideas:
Call the web service remotely using a URL that resolves to the internal ColdFusion server (e.g. http://[servername]:8300). You will probably have to some configuration to get this working. Reason for doing so is to identify if IIS or ColdFusion is the root cause. If you can hit the internal server remotely then IIS is probably the issue.
Is the web service call over SSL? If so, is remote caller also ColdFusion? If you've answered both yes, check to see if the SSL certificate is trusted by the remote caller's JVM. If not, you need to register it as part of the JVM's keystore.
Can you ping the host server from the caller? If not, does the caller need a "hosts" entry?
If enabled on your host, review the .NET filter and how it interacts with HTTP calls. I've experienced a situation where I was unable to access a folder called "/bin" because the .NET filter intercepted the requests.
The issue turned out to be that each of the calls required basic authentication which the calls themselves were handling, however basic authentication had been turned on in IIS which was causing IIS to intercept any requests with an Authorization header.
This causes an issue as IIS assumes that if authentication is passed up then it is for a user on that machine/domain and would reject any other credentials (which were valid for the system). It was working when we were logged into the machine because it was coming locally it did not need to authenticate the user.