Created: 2016-08-25 15:11 Updated: 2025-04-17 12:10

Recentemente me deparei com uma instalação do Windows Server 2012 R2 na qual um colega de trabalho estava tendo dificuldades. A dificuldade foi a seguinte: ele instalou o Apache, mas não conseguia fazê-lo executar o serviço. Observamos isso também no windows Server 2019 Essentials.

Num primeito momento, desativamos o serviço http usado pelo Windows, o que não foi uma boa ideia:

net stop http
sc config http start= disabled

Muita atenção ao formato do comando: no parâmetro start= disabled, há espaço em branco apenas após o sinal igual (=), mas não antes do mesmo.

Este procedimento permitiu a inicialização do Apache na porta 80, mas teve consequências bastante sérias, que só foram relatadas muito tempo depois: a atualização do Windows parou de funcionar. Não sei se isso ocorreu imediatamente, ou se afeta apenas determinadas atualizações ou ainda, se começou ocorrer em função de alguma atualização que tenha ocorrido com sucesso. O fato é o seguinte: o servidor deixou de receber atualizações por bastante tempo e, quando foi substituído por um mais novo, peguei este cara para estudar.

Comecei pelos procedimentos básicos, como o seguintes:Executei todos os procedimentos possíveis, como os seguintes:

No entanto, nada disso funcionou. Aí, um colega lembrou que, para executar o Apache, o serviço http interno teve que ser desabilitado. Isso leventou um alerta na minha mente.

Depois de pesquisar bastante, descobri o seguinte: o serviço HTTP que, que pode ser desativado com o comando net stop http é um driver do sistema (http.sys) e é essencial para o funcionamento de diversos serviços do Windows que escutam na porta 80. Esse driver é um listener de baixo nível no kernel, utilizado por vários softwares do próprio Windows, tais como:

Desabilitá-lo pode causar falhas em serviços que usam chamadas HTTP internas, mesmo que você não veja isso externamente.

Então, sim, o serviço HTTP do Windows (http.sys) pode ter relação com a instalação de atualizações, especialmente quando o Windows Update ou outros componentes do sistema tentam usar a API do HTTP ou dependem de serviços como o BITS (Background Intelligent Transfer Service) e Windows Update (wuauserv), que usam o subsistema HTTP para comunicação.

Então, como o servidor estava fora de operação, desativei o serviço do Apache e tentei iniciar o serviço http com o comando:

net start http

Mas o serviço não iniciou. Tentei verificar o estado do serviço:

sc qc http

Mas não obtive resposta. Então, forcei a barra através do registro do Windows:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP

Alterei o valor do parâmetro Start para 3. Eis os valores possíveis:

Reiniciei o servidor porque, bem, é Windows...

Depois, verifiquei novamente o estado do serviço http:

sc qc http
[SC] QueryServiceConfig SUCCESS

SERVICE_NAME: http
        TYPE               : 1  KERNEL_DRIVER
        START_TYPE         : 3   DEMAND_START
        ERROR_CONTROL      : 1   NORMAL
        BINARY_PATH_NAME   : system32\drivers\HTTP.sys
        LOAD_ORDER_GROUP   :
        TAG                : 0
        DISPLAY_NAME       : HTTP Service
        DEPENDENCIES       : WinQuic
        SERVICE_START_NAME :

Então, iniciei a verificação de atualizações. Foram instaladas várias delas, sem erro. Como nenhum atualização era instalada antes da ativação do http.sys, estou assumindo que este era o problema (só o tempo dirá).

Depois de várias atualizações e reinicializações, resolvi pesquisa mais um pouco.

Descobri como verificar quais URLs e portas o http.sys está usando:

netsh http show urlacl

No servidor em questão (2019), a saída foi bastante longa:

C:\Users\Administrator>netsh http show urlacl

URL Reservations:
-----------------

Reserved URL            : http://*:5357/  
    User: BUILTIN\Users
        Listen: Yes
        Delegate: No
    User: NT AUTHORITY\LOCAL SERVICE
        Listen: Yes
        Delegate: No
        SDDL: D:(A;;GX;;;BU)(A;;GX;;;LS)

Reserved URL            : http://+:80/Temporary_Listen_Addresses/
    User: \Everyone
        Listen: Yes
        Delegate: No
        SDDL: D:(A;;GX;;;WD)

Reserved URL            : https://*:5358/
    User: BUILTIN\Users
        Listen: Yes
        Delegate: No
    User: NT AUTHORITY\LOCAL SERVICE
        Listen: Yes
        Delegate: No
        SDDL: D:(A;;GX;;;BU)(A;;GX;;;LS)

Reserved URL            : http://+:10247/apps/
    User: NT AUTHORITY\Authenticated Users
        Listen: Yes
        Delegate: No
        SDDL: D:(A;;GX;;;AU)

Reserved URL            : http://*:2869/
    User: NT AUTHORITY\LOCAL SERVICE
        Listen: Yes
        Delegate: No
        SDDL: D:(A;;GX;;;LS)

Reserved URL            : http://+:10246/MDEServer/
    User: NT AUTHORITY\Authenticated Users
        Listen: Yes
        Delegate: No
        SDDL: D:(A;;GX;;;AU)

Reserved URL            : https://+:5986/wsman/
    User: NT SERVICE\WinRM
        Listen: Yes
        Delegate: No
        SDDL: D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-412116970)

Reserved URL            : http://+:47001/wsman/
    User: NT SERVICE\WinRM
        Listen: Yes
        Delegate: No
        SDDL: D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-412116970)

Reserved URL            : http://+:5985/wsman/  
    User: NT SERVICE\WinRM
        Listen: Yes
        Delegate: No
        SDDL: D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-412116970)

Reserved URL            : https://+:3392/rdp/
    User: NT SERVICE\TermService
        Listen: Yes
        Delegate: No
        SDDL: D:(A;;GX;;;S-1-5-80-446051430-1559341753-4161941529-1950928533-810483104)

Reserved URL            : http://+:3387/rdp/
    User: NT SERVICE\TermService
        Listen: Yes
        Delegate: No
        SDDL: D:(A;;GX;;;S-1-5-80-446051430-1559341753-4161941529-1950928533-810483104)

Reserved URL            : https://+:443/sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/
    User: NT SERVICE\SstpSvc
        Listen: Yes
        Delegate: Yes
    User: BUILTIN\Administrators
        Listen: Yes
        Delegate: Yes
    User: NT AUTHORITY\SYSTEM
        Listen: Yes
        Delegate: Yes
        SDDL: D:(A;;GA;;;S-1-5-80-3435701886-799518250-3791383489-3228296122-2938884314)(A;;GA;;;BA)(A;;GA;;;SY)

Reserved URL            : http://+:80/0131501b-d67f-491b-9a40-c4bf27bcb4d4/
    User: NT AUTHORITY\NETWORK SERVICE
        Listen: Yes
        Delegate: No
        SDDL: D:(A;;GX;;;NS)

Reserved URL            : https://+:443/C574AC30-5794-4AEE-B1BB-6651C5315029/
    User: NT AUTHORITY\NETWORK SERVICE
        Listen: Yes
        Delegate: No
        SDDL: D:(A;;GX;;;NS)

Reserved URL            : http://+:80/116B50EB-ECE2-41ac-8429-9F9E963361B7/
    User: NT AUTHORITY\NETWORK SERVICE
        Listen: Yes
        Delegate: No
        SDDL: D:(A;;GX;;;NS)

Reserved URL            : https://+:10245/WMPNSSv4/
    User: NT SERVICE\WMPNetworkSvc
        Listen: Yes
        Delegate: No
        SDDL: D:(A;;GX;;;S-1-5-80-2375682873-768044350-3534595160-1005545032-2873800392)

Reserved URL            : http://+:10243/WMPNSSv4/
    User: NT SERVICE\WMPNetworkSvc
        Listen: Yes
        Delegate: No
        SDDL: D:(A;;GX;;;S-1-5-80-2375682873-768044350-3534595160-1005545032-2873800392)

Aplicando um filtro na saída, obtive algo mais legível para o meu propósito:

C:\Users\Administrator>netsh http show urlacl | findstr "http://\+:80"
    Reserved URL            : http://+:80/Temporary_Listen_Addresses/
    Reserved URL            : http://+:80/0131501b-d67f-491b-9a40-c4bf27bcb4d4/
    Reserved URL            : http://+:80/116B50EB-ECE2-41ac-8429-9F9E963361B7/

Observer que o http.sys está ouvindo na porta 80 para 3 URLs. Como resolver isso e poder utilizar o Apache? Há duas opções:

  1. Configurar o Apache para utilizar uma porta diferente, liberando a porta 80 para o http.sys;
  2. Remover as URLs do http.sys que utilizam a porta 80, no entanto, este procedimento pode provocar o problema novamente, caso desabilitemos uma URL necessária.

Com um pouco mais de pesquisa, acabei descobrindo o seguinte: as linhas que reservam http://+:80/ ou similar, são utilizadas por serviços do Windows, como o IIS e o WSUS; ou por algum software instalado posteriormente. Caso se tenha certeza que o IIS, o WSUS e que nenhum outro software utilize o http.sys então, segundo minha pesquisa, as reservas de URLs que utilizam a porta 80 podem ser removidas. Isso garantirá que o Apache possa ser executado na porta 80 e que os serviços de atualização continuem funcionando (como o BITS e o Update). Porém, como eu disse, deve-se ter certeza de que nenhum software precise de acesso ao http.sys. Mas atenção: só remova as ACLs que utilizem a porta 80, pois as demais são utilizadas por outros serviços.

Se você quiser prosseguir com a aventura e desabilitar as reservas das URLs que utilizam a porta 80, o exemplo a seguir ilustra como fazê-lo para reservas do exemplo anterior:

netsh http delete urlacl url=http://+:80/Temporary_Listen_Addresses/
netsh http delete urlacl url=http://+:80/0131501b-d67f-491b-9a40-c4bf27bcb4d4/
netsh http delete urlacl url=http://+:80/116B50EB-ECE2-41ac-8429-9F9E963361B7/

Minha sugestão: como muitos serviços internos do Windows são uma verdadeira incógnita exceto, talvez, para os especialistas certificados no Windows, eu acredito que a melhor opção, caso o Apache seja necessário (e porque muitos desconfiam no IIS), seja reconfigurar o Apache para ele utilizar uma porta diferente da 80 e, claro, uma que esteja na lista de reservas do http.sys, que pode ser obtida com o seguinte comando:

netsh http show urlacl | findstr "http://"

É isso. Fui.