Although people are pointing out specific services (e.g. the "Web Deployment Agent Service"), this fails to address the root cause. If you just disable services that trigger the problem, chances are it will rear its head again in the future in a marginally different guise. So it's worth understanding what's going wrong, because that leads to a better fix.
This problem arises when an application server wants total control of port 80. This conflicts with a feature of Windows that is designed to enable multiple processes to handle requests on port 80. It's entirely possible to have any number of processes all receiving HTTP requests on port 80, because Windows has a built-in HTTP dispatch mechanism. Each process can tell Windows which URLs it wants to handle.
However, if an application server totally ignores this, then you're back in the less flexible old-school sockets world where only one process can receive requests destined for any particular port.
That may be fine - if you really don't want anything other than a particular process handling HTTP request on port 80, then it becomes tolerable to use an application server that fails to support the more flexible mechanisms offered by Windows. (And some popular app servers have this limitation. E.g., AFAIK, Tomcat is incapable of playing well with others, and insists on having port 80 all to itself. So if you're using someone else's app server, it may well be impractical to adapt it to use the preferred mechanism.)
Windows attempts to accommodate such inflexible services by not binding its dispatch mechanism to port 80 until something actively asks for that. (This is why you won't necessarily see a problem initially, but can run into this issue after some sort of update or config change.) But relying on this is not a very solid solution - you're essentially trusting to luck that nothing attempts to listen under port 80 before your app server launches. (There are various reasons a process might speculatively attempt to register for certain URLs on port 80, and back off if it's not allowed.)
So if you want one service to have exclusive access to port 80, you'd better tell Windows. It's not really good enough to attempt to switch off all services that might try to use the usual port sharing mechanism, because it's difficult to be confident that you've found all of them. (Particularly when Windows updates seem to change what's on by default.) It's probably good practice to disable the ones you know about, but it's best to approach this from both ends: disable services you don't want, and also ensure that it's not possible for ones you didn't know about to trip you up.
By default HTTP.SYS
(the underlying port sharing HTTP dispatch mechanism in Windows) is able to listen on all addresses. But you can tell it not to. This page shows one way to do that: http://www.mikeplate.com/2011/11/06/stop-http-sys-from-listening-on-port-80-in-windows/
That is a relatively light way to do it, because it still enables listening on localhost for IPv6. It just frees up IPv4 port 80. You could take it further with more specialized config. (You could even disable HTTP.SYS
entirely, but that might break things using ports other than 80, so it may cause problems.)
But whatever you do, the point is to ensure that HTTP.SYS
doesn't attempt to listen on port 80 on the IP address you care about. Once you've done that, you don't need to worry about disabling services, nor do you need to worry about other changes re-introducing the problem. If you've ensured that the endpoint you need is effectively out of bounds for port sharing, then you should find that the system process stops binding to it.
Try running gpresult /R
for RSoP summary or gpresult /V
for verbose output from the command line as an administrator on the computer. It should output something like this:
C:\Windows\system32>gpresult /V
Microsoft (R) Windows (R) Operating System Group Policy Result tool v2.0
Copyright (C) Microsoft Corp. 1981-2001
Created On 2/10/2010 at 10:27:41 AM
RSOP data for OQMSupport01\- on OQMSUPPORT01 : Logging Mode
------------------------------------------------------------
OS Configuration: Standalone Workstation
OS Version: 6.1.7600
Site Name: N/A
Roaming Profile: N/A
Local Profile: C:\Users\-
Connected over a slow link?: No
COMPUTER SETTINGS
------------------
Last time Group Policy was applied: 2/10/2010 at 10:16:09 AM
Group Policy was applied from: N/A
Group Policy slow link threshold: 500 kbps
Domain Name: OQMSUPPORT01
Domain Type: <Local Computer>
Applied Group Policy Objects
-----------------------------
N/A
The following GPOs were not applied because they were filtered out
-------------------------------------------------------------------
Local Group Policy
Filtering: Not Applied (Empty)
The computer is a part of the following security groups
-------------------------------------------------------
System Mandatory Level
Everyone
Debugger Users
IIS_WPG
SQLServer2005MSSQLUser$OQMSUPPORT01$ACT7
SQLServerMSSQLServerADHelperUser$OQMSUPPORT01
BUILTIN\Users
NT AUTHORITY\SERVICE
CONSOLE LOGON
NT AUTHORITY\Authenticated Users
This Organization
BDESVC
BITS
CertPropSvc
EapHost
hkmsvc
IKEEXT
iphlpsvc
LanmanServer
MMCSS
MSiSCSI
RasAuto
RasMan
RemoteAccess
Schedule
SCPolicySvc
SENS
SessionEnv
SharedAccess
ShellHWDetection
wercplsupport
Winmgmt
wuauserv
LOCAL
BUILTIN\Administrators
USER SETTINGS
--------------
Last time Group Policy was applied: 2/10/2010 at 10:00:51 AM
Group Policy was applied from: N/A
Group Policy slow link threshold: 500 kbps
Domain Name: OQMSupport01
Domain Type: <Local Computer>
The user is a part of the following security groups
---------------------------------------------------
None
Everyone
Debugger Users
HomeUsers
BUILTIN\Administrators
BUILTIN\Users
NT AUTHORITY\INTERACTIVE
CONSOLE LOGON
NT AUTHORITY\Authenticated Users
This Organization
LOCAL
NTLM Authentication
High Mandatory Level
The user has the following security privileges
----------------------------------------------
Bypass traverse checking
Manage auditing and security log
Back up files and directories
Restore files and directories
Change the system time
Shut down the system
Force shutdown from a remote system
Take ownership of files or other objects
Debug programs
Modify firmware environment values
Profile system performance
Profile single process
Increase scheduling priority
Load and unload device drivers
Create a pagefile
Adjust memory quotas for a process
Remove computer from docking station
Perform volume maintenance tasks
Impersonate a client after authentication
Create global objects
Change the time zone
Create symbolic links
Increase a process working set
Or if you are logged in to a Windows Server OS with the ActiveDirectory PowerShell Module (or Client OS with the Remote Server Administration Tools) try the Get-ADPrincipalGroupMembership
cmdlet:
C:\Users\username\Documents> Get-ADPrincipalGroupMembership username | Select name
name
----
Domain Users
All
Announcements
employees_US
remotes
ceo-report
all-engineering
not-sales
Global-NotSales
Best Answer
It doesn't look like there's a way to refresh it. For now I have reconfigured the service to use another port until it's more convenient for me to restart.