I have created Scheduler Job in Azure using HTTPS action to periodically ping ASP.NET Web application deployed on VM. Web application is configured with HTTPS binding using SSL certificate. I have configured IIS security using IIS Crypto 2.0 tool.
Scheduler Job fails with an error:
Http Action - Request to host 'www.somesamplehost.com' failed: SendFailure The
underlying connection was closed: An unexpected error occurred on a
send.
The same URL works fine when I try to access it from any browser.
Screenshot from Azure Portal:
The issue was due to SSL certificate. I have ECC SSL certificate for my Web Application and Azure Scheduler Job does not support making requests to Web Application that has that kind of certificate.
Guys from MS suggested alternative for Scheduler Job. It is a feature in Azure Portal called "Logic Apps". You can set it up in a way that it periodically makes requests to specific URL, but "Logic Apps" has much more capabilities compared to Scheduler Job.
Related
I am using a third party library (MinIo dotnet SDK) in my .NET application. I successfully send the requests on the localhost, but at the time of publish on the IIS server, the requests are met with the following error.
MinIO API responded with message=Connection error:The SSL connection could not be established, see inner exception.. Status code=0, response=The SSL connection could not be established, see inner exception., content=
Same problem here this week.
We had to install the (root) certificate we used for our minio/S3 server on the machine we ran our application on.
If you don't want to use SSL, you have to use MinioClient.WithSsl(false).
I am trying to integrate Jenkins and Web deploy v3.5 over "HTTP" connection. The server has IIS 10 and Windows Server 2016. The build is getting failed with an error,
Web deployment task failed. (Could not complete the request to remote agent URL 'http://IPAddress:8172/MSDeploy.axd?site=WebSite'.)
I am using the following command,
/property:configuration=Dev /p:DeployOnBuild=True /p:DeployTarget=MsDeployPublish /p:CreatePackageOnPublish=False /p:AllowUntrusted=True /p:MsDeployPublishMethod=WMSvc /p:MsDeployServiceUrl="http://IpAddress:8172/MSDeploy.axd" /p:DeployIisAppPath="WebSite" /p:AllowUntrustedCertificate=True /p:Username=SomeUsername /p:Password=SomePassword
Troubleshooting:
8172 port is allowed for Jenkins.
Web deployment services are running.
Users have been given with sufficient rights to the directory.
WebDeploy user is added to administrator group.
I am suspecting if Web deploy tool doesn't work over HTTP connection, is that true?
Web Deploy is actually just a way of deploying. The services are running on a server and listening on the port 8172. I do not get why you are using a whole web adress, when all you need is the connection to the server (ip or domain only!).
Example: 0.00.000.000 or example.org
Check if you installed the handler too. You need the web deploy service and handler running.
Regards,
Maheshvara
I encountered the problem by taking following steps,
Ms web deploy works under the secure connection. it should be called by https://
Configured three rules as mentioned under Management Service Delegation Rule
2.1 ---- createApp with WDeployConfigWriter User
2.2 ---- setAcl
2.3 ---- contentPath_intiApp
Reference: https://learn.microsoft.com/en-us/iis/publish/using-web-deploy/configure-the-web-deployment-handler
In 2.1 step, WDeployConfigWriter user needs to be created manually. Web deploy tool use two users WDeployAdmin and WDeployConfigWriter
Reference: https://blog.richardszalay.com/2013/08/02/manually-creating-wdeployadmin-and-wdeployconfigwriter/
I deployed an Asp.Net Web API project on Amazon Web Services' Elasticbeanstalk (IIS configured machine). Everything works fine except WebSocket. To test the WebSocket easier I use Simple WebSocket Client extension on Chrome.
When I make a request to the API, I get the following (error) message (I observe this message over developer console's network tab):
WebSocket connection to 'ws://my_url' failed: Error during WebSocket handshake: Unexpected response code: 400
I have not found enough information to overcome this problem.
I tried enabling all Inbound/Outbound TCP connections from all ports and all IPs under Security Groups.
I tried creating an empty Asp.Net Web API project that only has a basic sample of WebSockets (just sending a message to the connected user) and deploying it to a brand new environment and application on AWS.
Nothing has worked so far.
I am using Microsoft's WebSockets, .NET Framework 4.5.1.
What are the possible solution ways?
If you are using AWS Elastic Load Balancer in your elastic beanstalk then ELB does not support web sockets and you have to apply a work around. Change your Load Balancer top classic load balancer that supports Websockets.
https://aws.amazon.com/blogs/aws/new-aws-application-load-balancer/
I solved the problem by adding All TCP on Inbound segment of Security Groups and using the IP address of the server instead of AWS created name.
I got 2 servers with two equal wcf services hosted on them and one client application server. I can connect to endpoints and send a requests to both services using test wcf client app (.NET Web Service Studio) from my local machine successfully. But when I am trying to connect from client application server using the same test wcf client app I successfully connected only to the one wcf service server, but I have got an error when connecting to another one:
System.Net.WebException: There was an error downloading 'https://XXX/XXX?wsdl'. ---> System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it XX.XXX.XX.XXX:443
I performed netstat -an | find "443" command in command prompt on the client server and on my local machine to find out the difference and here what I have got:
1. On my local machine:
2. On the client app server:
What I already tried to do on client application server is:
- turned off firewall;
- stopped windows firewall service
- uninstalled mcafee virusscan enterprise application.
(I tried to set "prevent mass mailing worms from send mail" first, but mcafee was in foreign language that I don't understand, so I just uninstalled it)
after running command netstat -aon | findstr "443" on client application server I have got this result:
but I still got an error.
Does anybody know how to solve this issue?
Could be the problem on the wcf service server side?
The solution was predictable simple one - firewall was blocking the port,
but it's important to notice that the issue was caused by firewall on the wcf service server side, but not on client application server, which is making the request to that service.
I asked the technical support of that server, and they made firewall changes.
After that error was disappeared.
I faced the same issue and tried different ways to fix this. Nothing works. Later i found the issue which is, the application i tried to run is https and in my IIS, https binding was not created. I created binding https with the website and it works.
I have a WCF service which is being called from my web application.
The WCF service call is made on SSL port 443.
When my application makes the call, i recieve the following error message in my log file:
The HTTP request is unauthorized with client authentication scheme 'Ntlm'. The authentication header received from the server was 'Negotiate,NTLM'
I checked the iis authentication headers on my machine(IIs 5.1) and the machine where the WCF service is deployed(IIS 6.0) using the cscript command:
For iis 5.1
adsutil set w3svc/1/ntauthenticationproviders "Negotiate,NTLM"
Simlilarly, the header has been set on server machine IIS 6.0 using the command:
adsutil set w3svc/1/root/ntauthenticationproviders "Negotiate,NTLM"
I have repeatedly checked the headers and they have the same value of "Negotiate,NTLM" at both ends, yet my service call is failing.
Kindly help.
With NTLM authentication, the user executing on the calling server must be verifiable within the domain within the headers. This would mean that your IIS 5.1 machine would have to have its IIS instance (application pool) running under a domain viable user. Since the application pool is almost universally run by either Local System, Network Service, or AppPoolService (or similar system account) nome of which are domain available, you will need to configure the IIS instance that is performing the call to be run by a service account with appropriate permissions in the domain.