I applied a self-signed SSL certificate in IIS manager to Default Web Site(added the HTTPS binding) and after that when I'm trying to start the web site, I'm getting the following error message:
"The process cannot access the file because it's being used by another process. (Exception from HRESULT: 0x80070020) ". But when I remove the HTTPS binding, everything works fine.
So, what is the problem? What might have I done wrong?"
Have you tried the Microsoft Support Article that mentions this process error occuring when you try to start a Web site in the Internet Information Services MMC snap-in
If you're trying to do this on a local machine, Skype can block the https port (443). To stop this:
Skype - Tools > Options > Advanced > Connection, then uncheck 'Use port 80 and 443 as alternatives for incoming connections'. Then quite Skype (right click in task bar, 'Quit Skype'), and try starting the website again in IIS.
VmWare Workstation 8 grabs 443 for its VM Sharing feature. You can disable it in the settings. http://communities.vmware.com/thread/341114
Yes exiting the Skype desktop app fixed this for me also.
If your running Windows 8(.1) the Skype App (Windows Store App) doesn't use the local 443 port if you can live without installing the desktop Skype app. Also you can pin it to your taskbar. This solution is good enough for me since I don't need all of the features the desktop version offers.
You may want to use some sysinternals tools to see if the file is really used by another process. I recommend Process Explorer. Once you've located the culprit, you can usually see why it opens the file.
If you can't find any process, maybe your code tries to open the file; check for any file handlers you may not have closed.
Related
The new HTTP/3 protocol is supposed to be faster and more secure than HTTP/2. How do I enable it on Windows Server running IIS websites?
As of this writing, HTTP/3 is only supported on Windows Server 2022. If you are on any previous version, I'm afraid you are out of luck.
Assuming you are on Windows Server 2022, here is how you enable it.
Step 1: Update the Windows Registry
Copy and paste the following text into a new .reg file. You can call it something like "enable-http-3.reg"
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Client]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters]
"EnableHttp3"=dword:00000001
"EnableAltSvc"=dword:00000001
Once saved, execute it on your Windows Server 2022 by double-clicking it, or by using reg.exe.
Step 2: Enable TLS Cipher
Note: Based on feedback from other users, this step may be optional. However, I needed to enable it on my installation.
Open PowerShell as Administrator to enable the TLS_CHACHA20_POLY1305_SHA256 cipher suite. Execute the following command in PowerShell:
Enable-TlsCipherSuite -Name TLS_CHACHA20_POLY1305_SHA256 -Position 0
Step 3: Allow UDP Connections on Port 443
HTTP/3 uses QUIC protocol which uses incoming UDP connections on port 443. You'll need to allow connections if you're using a firewall. Here is how the rule might look in Windows Firewall:
Step 4: Add HTTP/3 Response Headers to IIS
HTTP/3 requires some special response headers within IIS. Select either the website, or the machine within IIS and select "HTTP Response Headers."
Create a new response header with the name alt-svc and the value h3=":443"; ma=86400; persist=1.
That's it! Now test to make sure HTTP/3 is working in your browser. Many modern browsers li support HTTP/3 so you shouldn't need any configuration changes. However, one thing to note is that HTTP/3 only works on HTTPS connections, so if you're loading a website using HTTP, it will not work. Make sure to configure websites in IIS to use HTTPS protocol.
You will know when HTTP/3 is working via the browser's dev tools. Open developer tools, click on the network tab and note the protocol column. Chrome 108.0.5359.94 screenshot:
Firefox 107.0.1 screenshot:
Troubleshooting Tips
Reboot Windows 2022 server
Make sure the website is loaded via HTTPS! Do you see the lock icon in the browser?
Completely close the browser (all tabs) and restart it before loading the website
Disable the browser cache via browser developer tools when testing
Completely clear the browser cache and reboot the client machine(s).
More resources and references:
https://4sysops.com/archives/increase-iis-performance-with-http3-in-windows-server-2022/
https://blog.workinghardinit.work/2021/10/11/iis-and-http-3-quic-tls-1-3-in-windows-server-2022/
https://techcommunity.microsoft.com/t5/networking-blog/enabling-http-3-support-on-windows-server-2022/ba-p/2676880
I'm trying to setup webdeploy on IIS8, but why am I getting 404 when accessing both https://[servername]:8172/msdeploy.axd and https://localhost:8172/msdeploy.axd locally.
I've installed management service.
I've installed webdeploy 3.5 using web platform installer. In Program and Features a changed the instalation of webdeploy to include all features including the handler.
In IIS Manager I've chosen Configure Web Deploy Publishing for default website's context menu.
I've restarted management service.
when i tried https://[servername]:8172/msdeploy.axd I was asked to enter credentials and accept the certificate. after that I got 404.
I've uninstalled webdeploy and installed using MSI manually including all features.
restarted entire server.
getting 404.
I don't believe you can open the service from a browser. I attempted that against a dev server that we deploy to many times a day and also received a 404. I would try deploying from VS instead as a test.
Also if anyone comes here and is using Visual Studio Publish dialog and the "Validate Connection" button fails: do NOT use the button when creating. Just click Ok, then Edit (in More actions menu).
In the Connection tab, click Validate Connection. This time it will asks you to accept an invalid certificate (since you likely self-signed it on your server). Accept it and the connection should go through.
Visual Studio 2015 (Loaded as Admin), Web API 2, Windows 10.
I have Local IIS with a subdomain sub.mylocalsite.com mapped through the hosts file to 127.0.0.1. The Web API 2 is loading and I am able to debug and do all the activities as expected.
On IIS, if I add a secure binding, with the proper self-signed certificate (without disabling the non-secure binding, i.e. keeping two bindings) and do an IIS Reset, I am able to access the https Web APIs as expected, however, when I click run to start debugging I get the standard error from VS of Unable to Start Debugging.
Please note that I tried both setting the start URL as http://sub.mylocalsite.com and https://sub.mylocalsite.com to no avail
Any solution?
I experienced the same thing, then saw this blog post. Try attaching to worker process, per this blog post:
https://blogs.msdn.microsoft.com/vijaysk/2007/10/17/visual-studio-debugging-websites-that-require-client-certificates/
The most important requirement for the pretty F5 key to work in Visual Studio is NTLM/Windows Intergated Authentication. Only then can it auto-attach to the IIS worker process. And this is where our trouble starts. Client certificates is a kind of an authentication mechanism. When you configure a website to require client certificates you are changing the authentication mechanism.
So if you are developing a website off an IIS server and you need to debug it with client certificates then you cannot just open your web project in visual studio and start debugging it. But what you can do is attach to the process running your code manually.
Open your project in Visual Studio and set a breakpoint as you usually do
Debug menu > Attach to Process > Select the process running your code.
I'm using VS2015 Update 1 to try and debug my site which I've uploaded in Debug mode to an Azure web app (NOT a vm). I am working from my work domain.
I've been following instructions similar to found here https://samlman.wordpress.com/2015/02/27/another-cool-way-to-remotely-debug-azure-web-sites/
I have:
Published my website in Debug configuration
Enabled Remote Debugging from the management console
Made sure my VS edition is set to 2015
Enabled Websockets (from trying to connect via websockets)
Checked that the firewall allows VS remote debugger, remote debugger monitor and remote debugger discovery through.
Checked the website is up and running (set it to always on just in case)
I have tried right clicking my app service in Server Explorer and "Attach Debugger".
I then tried to connect using Debug > Attach to process and using the qualifier mysite.azurewebsites.net as instructed on various blogs. Even tried transport as Websocket, Remote as well as Default.
All methods get me the following:
I then used Fiddler to see if I could find the answer from web traffic but no joy with that.
Would appreciate any suggestions to get me around this problem!
Edit
Under scm -
There was another firewall I wasn't aware of on the domain that was blocking the debugger.
Edit:
Ports requested
outbound:
UDP 3702
TCP 4020
TCP 4021
Port assignments are given here on MSDN page
All of the sudden I'm getting the following error on my local web server (Win7 64bit, IIS 7.5). I've uninstalled & reinstalled IIS locally and it didn't fix it. IIS is set to start up automatically and I can see that the service has been successfully started. Upon a fresh reboot if I go into IIS and click on start website I get the following error:
The process cannot access the file because it is being used by another process. (Exception from HRESULT: 0x80070020
If I try to start debugging on my local website project I get the following error:
Unable to start debugging on the web server. The underlying connection was closed. The connection was closed unexpectedly.
Any ideas on what I can try? I've been doing research on the issue and Microsoft suggest making sure no other service is listening on the same ports. I've verified that this isn't the issue.
Try changing the web site to use a port other than 80 (suggest 8080 for example) and see it if will start. If so that's a sure sign of another service using port 80 (Skype is a common culprit for this).
Application pool's identity password changed?
I know this is an old post, but I can't believe how many times I've been bitten by this. Some shops use integrated security for SQL, and often then on your local IIS needs your network login for the application pool. When your password expires, and you forget to change your password here, start banging your head on the wall... DOH!
Open IIS. Select Application Pools. Select the application pool used by your app. Click Advanced Settings... Select Identity, and the little "..." button to update your user/password.