Service Listens to Instead of

Azure AD Connect failure binding instead of

In some cases, the Windows operating system will bind service listeners to instead of the default (all IP addresses on the system).

This will cause your system to stop responding to remote connections on all services bound to instead of

One example of this is when Azure AD Connect stops accepting WinRM (remote PowerShell) sessions:

Azure AD Connect WinRM Connection Failed

Another example could be IIS stopping servicing web requests.

To verify if you’re experiencing this issue, check what IP listener is registered for your service.

E.g., if you’re seeing problems with remote PowerShell (WinRM), check the listener port of the WinRM service (TCP 5985):

C:\>netstat -nao | findstr "5985"
  TCP              LISTENING       4

As seen in the above example, port 5985 is bound to and not (as expected).

If you take a look at the registered listeners, you’ll see the following output, which further validates the cause of the problem:

C:\>PS C:\>netsh http show iplisten

IP addresses present in the IP listen list:

This configuration will block remote TCP connections to port 5985 and effectively breaks remote PowerShell.

To solve this issue, remove the listener by issuing the following command in an administrative command prompt:

C:\>netsh http delete iplisten ipaddress=

IP address successfully deleted

Immediately after issuing this command, the WinRM service will bind to the default listener:

C:\>netstat -nao | findstr "5985"
  TCP               LISTENING       4
  TCP    [::]:5985              [::]:0                 LISTENING       4

Remote PowerShell will start working again, and this is reflected in the Easy365Manager settings:

Easy365Manager settings configuration