There are no more endpoints available from the endpoint mapper

Sponsored Links

Joining computers to the domain from a remote site fail with the error shown
in the subject title. Using the articles below i have tried the resolutions
shown and yet i still can't establish the exact cause of this issue.
Initially i thought this was a networking issue but using Portquery.exe to
test the 'Domain and Services' ports shows their are open. I know the
services are running on the DC's, as joining a workstation to the domain from
the Head Office works. The connection between the head office and remote
site is using an VPN over an ADSL link. Checking the line utilisation shows
the line is hardly being used (5-10%).

Reviewing the NetSetup.log shows the correct DC is located but reports the
error as 'NetpGetComputerObjectDn: Unable to bind to DS on '\\DC8': 0x6d9'.
'0x6d9' translates to 1753 which using 'net helpmsg 1753' returns the
endpoint mapper error in the subject title.

Has anyone got a resolution or experienced this before?


Articles:
How to troubleshoot RPC Endpoint Mapper errors
http://support.microsoft.com/kb/839880

Join and Authentication Issues
http://www.microsoft.com/technet/pro....mspx?mfr=true

NetSetup.log
01/25 17:33:23 NetpDoDomainJoin
01/25 17:33:23 NetpMachineValidToJoin: 'WORKSTATION'
01/25 17:33:23 NetpGetLsaPrimaryDomain: status: 0x0
01/25 17:33:23 NetpMachineValidToJoin: status: 0x0
01/25 17:33:23 NetpJoinDomain
01/25 17:33:23 Machine: WORKSTATION
01/25 17:33:23 Domain: DOMAIN\DC8
01/25 17:33:23 MachineAccountOU: (NULL)
01/25 17:33:23 Account: DOMAIN\ADMINISTRATOR
01/25 17:33:23 Options: 0x3
01/25 17:33:23 OS Version: 5.1
01/25 17:33:23 Build number: 2600
01/25 17:33:23 ServicePack: Service Pack 2
01/25 17:33:23 NetpValidateName: checking to see if 'DOMAIN' is valid as
type 3 name
01/25 17:33:23 NetpCheckDomainNameIsValid [ Exists ] for 'DOMAIN' returned 0x0
01/25 17:33:23 NetpValidateName: name 'DOMAIN' is valid for type 3
01/25 17:33:24 NetpJoinDomain: status of connecting to dc '\\DC8': 0x0
01/25 17:33:24 NetpJoinDomain: Passed DC '\\DC8' NOT verified as DNS name
'\\DC8.DOMAIN.LOCAL'
01/25 17:33:24 NetpJoinDomain: Passed DC '\\DC8' verified as Netbios name
'\\DC8'
01/25 17:33:24 NetpGetLsaPrimaryDomain: status: 0x0
01/25 17:33:24 NetpGetDnsHostName: Read NV Hostname: WORKSTATION
01/25 17:33:24 NetpGetDnsHostName: PrimaryDnsSuffix defaulted to DNS domain
name: DOMAIN.LOCAL
01/25 17:33:24 NetpLsaOpenSecret: status: 0xc0000034
01/25 17:33:25 NetpManageMachineAccountWithSid: NetUserAdd on '\\DC8' for
'WORKSTATION$' failed: 0x8b0
01/25 17:33:26 NetpManageMachineAccountWithSid: status of attempting to set
password on '\\DC8' for 'WORKSTATION$': 0x0
01/25 17:33:26 NetpJoinDomain: status of creating account: 0x0
01/25 17:33:31 NetpGetComputerObjectDn: Unable to bind to DS on '\\DC8': 0x6d9
01/25 17:33:31 NetpSetDnsHostNameAndSpn: NetpGetComputerObjectDn failed: 0x6d9
01/25 17:33:31 ldap_unbind status: 0x0
01/25 17:33:31 NetpJoinDomain: status of setting DnsHostName and SPN: 0x6d9
01/25 17:33:31 NetpJoinDomain: initiaing a rollback due to earlier errors
01/25 17:33:32 NetpGetLsaPrimaryDomain: status: 0x0
01/25 17:33:32 NetpManageMachineAccountWithSid: status of disabling account
'WORKSTATION$' on '\\DC8': 0x0
01/25 17:33:32 NetpJoinDomain: rollback: status of deleting computer
account: 0x0
01/25 17:33:32 NetpLsaOpenSecret: status: 0x0
01/25 17:33:33 NetpJoinDomain: rollback: status of deleting secret: 0x0
01/25 17:33:33 NetpJoinDomain: status of disconnecting from '\\DC8': 0x0
01/25 17:33:33 NetpDoDomainJoin: status: 0x6d9

Hi
Most of the times this is a FW issue or DNS, check those.

--
I hope that the information above helps you.
Have a Nice day.

Jorge Silva
MCSE, MVP Directory Services

Hi Jorge,

This is not a DNS issue as the NetSetup.log shows, the computer is
successfully locating the DC and discovering the LDAP service (\\DC8), it
fails during the bind process. This failure sounds like a FW issue, but to
resolve i need clear prove. As the microsoft tool, portquery.exe,
successfully confirmed access to all Directory required ports I'm finding it
difficult to prove. As stated below, this site is connected over a VPN
tunnel and although the band width is adequate the latency is around 23-28ms.
Surely this isn't to much for an RPC connection?

The only other point i can think of confirming is that it is not being
effected by GPO's being restricted on low bandwidth sites. As the security
settings are quite high, it's possible that this is causing the
success/failure difference between the HQ and remote site.

Any other suggestions would be appreciated.

Thanks

"Jorge Silva" wrote:

> Hi
> Most of the times this is a FW issue or DNS, check those.
>
> --
> I hope that the information above helps you.
> Have a Nice day.
>
> Jorge Silva
> MCSE, MVP Directory Services

Okay,
Please review the following
Active Directory in Networks Segmented by Firewalls
http://www.microsoft.com/downloads/d...displaylang=en

Also have a look at the MTU size, I'm saying this because there was I known
issue with MTU Size in ADSL routers, as far as I know this problem is not
commum these days, but you never know.

--
I hope that the information above helps you.
Have a Nice day.

Jorge Silva
MCSE, MVP Directory Services
"Joel_uk" <Joeluk@discussions.microsoft.com> wrote in message
news:5E149E22-5649-40DE-9424-5274DC764C71@microsoft.com...
> Hi Jorge,
>
> This is not a DNS issue as the NetSetup.log shows, the computer is
> successfully locating the DC and discovering the LDAP service (\\DC8), it
> fails during the bind process. This failure sounds like a FW issue, but
> to
> resolve i need clear prove. As the microsoft tool, portquery.exe,
> successfully confirmed access to all Directory required ports I'm finding
> it
> difficult to prove. As stated below, this site is connected over a VPN
> tunnel and although the band width is adequate the latency is around
> 23-28ms.
> Surely this isn't to much for an RPC connection?
>
> The only other point i can think of confirming is that it is not being
> effected by GPO's being restricted on low bandwidth sites. As the
> security
> settings are quite high, it's possible that this is causing the
> success/failure difference between the HQ and remote site.
>
> Any other suggestions would be appreciated.
>
> Thanks
>
> "Jorge Silva" wrote:
>
>> Hi
>> Most of the times this is a FW issue or DNS, check those.
>>
>> --
>> I hope that the information above helps you.
>> Have a Nice day.
>>
>> Jorge Silva
>> MCSE, MVP Directory Services