none
'TCP port 135 (epmap service): NOT LISTENING' on Windows Server 2003 DC

    Question

  • c:\>portqry -n server -e 135 -p tcp
    Querying target system called:
     server
    Attempting to resolve name to IP address...
    Name resolved to 192.168.2.1
    TCP port 135 (epmap service): NOT LISTENING

    Since last friday I've been having this situation on my single Windows Server 2003 DC. There were no prior changes to AD, software installations or anything else, as far as I know.
    The DC is a DHCP server and it does provide addresses to clients and also redirects their DNS requests. Still, trying to use the DHCP management console results in a 'DHCP server not found' message. Also, DNS requests made from the DC itself time out as long as the DNS client service is running (they work fine otherwise).
    Numerous 1053, 4004, 4007, 4016 and errors in the System Log ensue. Any global catalog requests result in a 1869 -> 1655 (error 1722) -> 1126 EventID strings.

    ***

    The RpcSs service seems to be running as there aren't any messages in the event log showing it failed to start:

    C:\Distrib>tasklist /svc
    Image name                     PID Services
    ========================= ======== ============================================
    System Idle Process              0 N/A
    System                           4 N/A
    smss.exe                       312 N/A
    csrss.exe                      360 N/A
    winlogon.exe                   384 N/A
    services.exe                   432 Eventlog, PlugPlay
    lsass.exe                      444 HTTPFilter, kdc, Netlogon, PolicyAgent,
                                       ProtectedStorage, SamSs
    svchost.exe                    632 DcomLaunch
    svchost.exe                    748 RpcSs
    svchost.exe                    804 Dhcp
    svchost.exe                    844 LmHosts, W32Time
    svchost.exe                    860 AeLookupSvc, AppMgmt, AudioSrv, Browser,
                                       CryptSvc, dmserver, EventSystem, helpsvc,
                                       lanmanserver, lanmanworkstation, Messenger,
                                       Netman, Nla, RasMan, RemoteAccess,
                                       Schedule, seclogon, SENS, ShellHWDetection,
                                       TrkWks, winmgmt, WZCSVC
    spoolsv.exe                   1372 Spooler
    msdtc.exe                     1464 MSDTC
    appmgr.exe                    1540 appmgr
    <snip>

    Netdiag checks all fine (no WINS server, DC not registered at ISP's DNS servers, et c.) and this:

    DC list test . . . . . . . . . . . : Failed
    [WARNING] Cannot call DsBind to server.hoz.local (192.168.2.1). [RPC_S_SERVER_UNAVAILABLE]
    List of DCs in Domain 'HOZ':
    server.hoz.local

    ...

    [WARNING] Failed to query SPN registration on DC 'server.hoz.local'.

    Dcdiag:

    C:\Distrib>dcdiag
    Domain Controller Diagnosis
    Performing initial setup:
       [server] Directory Binding Error 1722:
       RPC server is unavailable.
       This may limit some of the tests that can be performed.
       Done gathering initial info.

    Doing initial required tests
       Testing server: Default-First-Site-Name\SERVER
          Starting test: Connectivity
             [SERVER] DsBindWithSpnEx() failed with error 1722,
             RPC server is unavailable.
             ......................... SERVER failed test Connectivity

    Doing primary tests
       Testing server: Default-First-Site-Name\SERVER
          Skipping all tests, because server SERVER is
          not responding to directory service requests

    When I set a random application to listen to port 135 the port responds, so I assume the port's not blocked.

    The system has been checked with Kaspersky Antivirus with latest bases revealing no virii.

    I've consulted numerous KB articles such as
    http://support.microsoft.com/kb/839880
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;816103
    http://support.microsoft.com/kb/831051
    http://support.microsoft.com/kb/156522
    and meditated over Google, but nothing has helped me so far.

    Any insight into the problem's origins or helpful advice would be appreciated.

    • Edited by Indrigis Friday, December 25, 2009 1:01 PM Formatting
    Friday, December 25, 2009 12:48 PM

All replies

  • Hi...
    You said you have kaspersky. Is it just antivirus or its a suite with firewall? As per the portqry result, it is sure that the port is blocked. Please check if you have any firewalls installed (may be kaspersky). You might have to configure it accordingly.

    If you have any network devices which may have hardware firewalls, please consider tem as well.


    Thanks, Arun.
    Friday, December 25, 2009 1:34 PM
  • KAV is a server installation so it only has an on-demand scanning module and an on-access scanner. No firewall there.

    The hardware firewalls are outside the scope and portqry results in 'NOT RESPONDING' both from this server and another member server with a TS role (connected via a simple 32-port switch).

    I haven't mentioned it specifically, but netstat -ano shows nothing actually listening on port 135 (unless I start netcat with -l -p 135 to verify lack of port blocking)
    Friday, December 25, 2009 1:45 PM
  • KAV is a server installation so it only has an on-demand scanning module and an on-access scanner. No firewall there.

    The hardware firewalls are outside the scope and portqry results in 'NOT RESPONDING' both from this server and another member server with a TS role (connected via a simple 32-port switch).

    I haven't mentioned it specifically, but netstat -ano shows nothing actually listening on port 135 (unless I start netcat with -l -p 135 to verify lack of port blocking)
    Can you please take a Netdiag report on the server where port seems to be blocked and upload here? 

    Thanks, Arun.
    Friday, December 25, 2009 2:25 PM
  • Uploaded it (component names in russian, though)
    http://c-s.nm.ru/netdiag.txt
    Friday, December 25, 2009 3:00 PM
  • Hello,

    Thanks for uploading the NetDiag output. It seems that we have a DNS issue here. The NEtdiag report is showing some errors saying that records have not been registered for the DCs on DNS servers 212.48.193.37 and 212.48.193.38.

    Please check where this macine is pointing for DNS. I would also like to know what machines are the IPs mentioned above. Are they still DNS servers? Please check these DNS servers and see if the records for the DCs (liek LDAP and KERBEROS) are registered there.

    (For testing you can do one thing. YOu can point a DC to any of these DNS servers and restart the Netlogon service to see if the records get registered on that DNS server or not)

    Also, there are some errors for NICs as well, I could not catch them quite well as they are in a different language. I would suggest you to go through the NIC errors and see if you can do something about that.

    I think this machine was acting as WINS. PLease check that as well.

    ( Sending name query to primary WINS server 127.0.0.1 - Failed).



    Thanks, Arun.
    Tuesday, December 29, 2009 9:50 AM
  • Hello,

    Well, 212.48.193.37/38 are the ISP's DNS servers behind the ADSL router at 192.168.1.1 and they wouldn't really care to register their clients' DNS records (nor they should as they aren't related to my domain). They are registered as redirection servers for 'all other DNS domains' for the purpose of resolving outside DNS requests made by internal clients. The 'register this connection's DNS entries' flag is not set, however, so the reason it's producing registration errors is beyond me.

    For DNS the machine is pointing to itself on one connection and to those two ISP's servers on the other one (it IS redundant, I know).

    As for the NIC errors the only ones I've noticed were 'this hasn't been used yet' warnings for the WAN miniports produced by Routing and Remote Access, so not really of any consequence too. If you could copy/paste one of the errors that seem suspicious, I'll gladly explain it.

    The WINS thing, again, seems like a mistype. There is no WINS role on the server and I'm pretty sure there wasn't one, so entering 127.0.0.1 for WINS was something on a reflex (I retyped all the settings for both LAN interfaces when first trying to diagnose the non-resolution problem).
    Tuesday, December 29, 2009 10:56 AM