unir xp a dominio AUN

Eso está mal...a ver, en el AD lo primero que debe hacerse es eliminar la cuenta de maŽquina que no se use; después se crea la cuenta de máquina nuevamente para que se genere un nuevo SID para ella; después se añade la máquina al dominio

Salu2!!!

Javier Inglés
MS-MVP

:
<<<QUITAR "NOSPAM" PARA MANDAR MAIL>>>

Este mensaje se proporciona "como está" sin garantías de ninguna clase, y no otorga ningún derecho


"Nicolas" escribió en el mensaje news:096d01c3503f$39d29690$
Muchas gracias por la informacion
Me voy a poner a leerla ahora mismo a ver si saco algo.
Respecto a lo de cambiar el nombre de la maquina he
intentar unirla lo que me pasa e slo siguiente.

Se me une al dominio pero me sigue dando el error de
siempre. Entonces la maquina se llama por ejemplo
equipo24 ahora, pero en active directory se mantiene el
antiguo nombre por ejem equipo 4 por lo que cuando
reinicio el xp no me encuentra la cuenta de equipo.

Más posibilidades; crea antes el nombre de máquina en el

DCy prueba a unirlo; si falla; crea otro nombre, le
cambias el nombre a la estación y reinicias; después
intenta unirlo de nuevo.

A parte...hay más de un DC?? Si es así...replican éstos

correctamente??

Má info:

How Domain Controllers Are Located in Windows XP
PSS ID Number: 314861

Article Last Modified on 8/6/2002



The information in this article applies to:


a.. Microsoft Windows XP Professional



This article was previously published under Q314861
For a Microsoft Windows 2000 version of this article,

see 247811.

SUMMARY
This article describes the mechanism that Windows XP

Professional uses to locate a domain controller in a
Windows-based domain.

The article details the process of locating a domain by

its DNS-style name and by its flat-style (NetBIOS) name,
which is used for backward compatibility. In all other
cases, it is recommended that you use DNS-style names as
a matter of policy.

The article also addresses issues that are involved in

troubleshooting the domain controller location process.

MORE INFORMATION
The following sequence describes how the Locator finds a

domain controller:

a.. On the client (the computer that is trying to

locate the domain controller), the Locator is initiated
as a remote procedure call (RPC) to the local Netlogon
service. The Netlogon service implements the Locator
DsGetDcName API call.

b.. The client collects the information that is needed

to select a domain controller, and then passes the
information to the Netlogon service by using the
DsGetDcName call.

c.. The Netlogon service on the client uses the

collected information to look up a domain controller for
the specified domain in one of two ways:

a.. For a DNS name, Netlogon queries DNS by using

the IP/DNS-compatible Locator--that is, DsGetDcName calls
the DnsQuery call to read the Service Resource (SRV)
records and "A" records from DNS after the domain name is
appended to the appropriate string that specifies the SRV
records.

A workstation that is logging on to a Windows-based

domain queries DNS for SRV records in this general form:

_service._protocol.DnsDomainName

Active Directory servers offer the Lightweight

Directory Access Protocol (LDAP) service over the TCP
protocol. Therefore, clients find an LDAP server by
querying DNS for a record of the form:

_ldap._tcp.DnsDomainName

b.. For a NetBIOS name, Netlogon performs domain

controller discovery by using the Microsoft Windows NT
4.0-compatible Locator--that is, by using the transport-
specific mechanism, for example, Windows Internet Name
Service (WINS).

In Windows NT 4.0 and earlier, "discovery" is a

process for locating a domain controller for
authentication in either the primary domain or in a
trusted domain.

d.. The Netlogon service sends a datagram to the

computers that registered the name. For NetBIOS domain
names, the datagram is implemented as a mailslot message.
For DNS domain names, the datagram is implemented as an
LDAP User Datagram Protocol (UDP) search.

UDP is the connectionless datagram transport protocol

that is part of the TCP/IP protocol suite. TCP is a
connection-oriented transport protocol. Note that UDP
allows a program on one computer to send a datagram to a
program on another computer. UDP includes a protocol port
number, which allows the sender to distinguish among
multiple destinations (programs) on the remote computer.

e.. Each available domain controller responds to the

datagram to indicate that it is working and returns the
information to DsGetDcName.

f.. The Netlogon service caches the domain controller

information so that subsequent requests do not need to
repeat the discovery process. Caching this information
encourages consistent use of the same domain controller
and a consistent view of Active Directory.

When a client logs on or joins the network, the client

must be able to locate a domain controller. The client
sends a DNS Lookup query to DNS to find domain
controllers, preferably in the client's own subnet.
Therefore, clients find a domain controller by querying
DNS for a record of the form:

_LDAP._TCP.dc._msdcs.domainname

After the client locates a domain controller, the client

establishes communication by using Lightweight Directory
Access Protocol (LDAP) to gain access to Active
Directory. As part of that negotiation, the domain
controller identifies which site the client is in, based
on the IP subnet of that client. If the client is
communicating with a domain controller that is not in the
closest (most optimal) site, the domain controller
returns the name of the client's site.

If the client has already tried to find domain

controllers in that site (for example, when the client
sends a DNS Lookup query to DNS to find domain
controllers in the client's own subnet), the client uses
the domain controller that is not optimal. Otherwise, the
client performs a site-specific DNS lookup again by using
the name of the optimal site. The domain controller uses
some of the directory service information for identifying
sites and subnets.

After the client locates a domain controller, the domain

controller entry is cached. If the domain controller is
not in the optimal site, the client flushes the cache
after 15 minutes and discards the cache entry. The client
then attempts to find an optimal domain controller in its
own site.

After the client has established a communications path

to the domain controller, the client can establish its
logon and authentication credentials and, if necessary
for Windows-based computers, set up a secure channel. The
client then is ready to perform normal queries and search
for information against the directory.

The client establishes an LDAP connection to a domain

controller to log on. The logon process uses Security
Accounts Manager (SAM). Because the communications path
uses the LDAP interface and the client is authenticated
by a domain controller, the client account is verified
and passed through SAM to the directory service agent,
then to the database layer, and finally to the database
in the Extensible Storage engine (ESE).

Troubleshooting the Domain Locator Process
To troubleshoot the domain locator process:
1.. Check Event Viewer to see whether the event logs

contain any error information. On both the client and the
server, check the System log for failures during the
logon process. Also, check the Directory Service logs on
the server and the DNS logs on the DNS server.

To view Event Viewer in Windows XP, click Start, click

Control Panel, double-click Administrative Tools, and
then double-click Event Viewer.

2.. Check the IP configuration by running the

ipconfig /all command at a command prompt. Verify that
the configuration is correct for your network.

3.. Use the Ping utility to verify network

connectivity and name resolution. Ping both the IP
address and the server name.

4.. Check the Network Diagnostics tool in Help and

Support under "Use Tools to view your computer
information and diagnose problems" to determine whether
the network components are correctly installed and
working properly. Network Diagnostics also runs some
tests and provides information about the network
configuration, information that can be helpful.

5.. Use the nltest /dsgetdc:domainname command to

verify that a domain controller can be located for a
specific domain. The NLTest tool is installed with the
Windows XP support tools.

For information about how to install these tools,

refer to the following article in the Microsoft Knowledge
Base:

306794 How to Install the Support Tools from the

Windows XP CD-ROM

6.. Use the NSLookup tool to verify that DNS entries

are correctly registered in DNS. Verify that the server
host records and GUID SRV records can be resolved.

For example, to verify record registration, use the

following commands:

nslookup

server_name.child_of_root_domain.root_domain.com

nslookup guid._msdcs.root_domain.com

7.. If either of these commands does not succeed, use

one of the following methods to reregister records with
DNS:

a.. To force host record registration, type

ipconfig /registerdns.

b.. To force domain controller service registration,

stop and then restart the Netlogon service.

8.. To verify appropriate LDAP connectivity, use the

Ldp.exe tool to connect and bind to the domain
controller. Ldp.exe is a support tool that you can
install from the Windows XP CD-ROM.

For information about how to install these tools,

refer to the following article in the Microsoft Knowledge
Base:

306794 How to Install the Support Tools from the

Windows XP CD-ROM

9.. If you suspect that a particular domain controller

has problems, turn on the Netlogon debug logging. Use the
NLTest utility by typing nltest /dbflag:0x2000ffff at a
command prompt. The information is logged in the Debug
folder in the Netlogon.log file.

10.. If you still have not isolated the problem, use

Network Monitor to monitor network traffic between the
client and the domain controller.

For additional information, refer to the Windows 2000

Server Resource Kit, Chapter 10, "Active Directory
Diagnostic, Troubleshooting, and Recovery."

Keywords: kbDNS kbenv kbinfo kbnetwork KB314861
Technology: kbWinXPPro kbWinXPProSearch kbWinXPSearch



Presta a tención al nltest



Salu2!!!


Javier Inglés
MS-MVP

:
<<<QUITAR "NOSPAM" PARA MANDAR MAIL>>>

Este mensaje se proporciona "como está" sin garantías de

ninguna clase, y no otorga ningún derecho

"Javier Inglés [MS MVP]"

escribió en el mensaje
news:u%

En el dominio...están activos los 5 FSMO????
En el XP...has probado a hacer un ping al nombre de

dominio y ver que responde bien???

Y en el event viewer, qué más dice???

Salu2!!!

Javier Inglés
MS-MVP

:
<<<QUITAR "NOSPAM" PARA MANDAR MAIL>>>

Este mensaje se proporciona "como está" sin garantías de

ninguna clase, y no otorga ningún derecho

"Nicolas" escribió en

el mensaje news:072801c3502a$76a18050$

Siento taladrar pero es que hoy tengo que hacer el
dominio o joderme y hacer un grupo de trabajo.

Ya he probado poner la IP del servidor que es el que
tiene Active directory en la DNS de las maquinas xp...
y sigue diciendo exactamente lo mismo.

Supongo que antes funcionaba por que tendria algo de

DHCP

o algo asi para asignar dinamicamente.
(A lo mejor sigue activo y crea conflicto no tengo

ni

idea, puede ser una pedrada, vosotros direis).

Gracias por contestarme.

Para quien no haya leido el mensaje anterior o no os
acordeis era este:
La cosa esta asi.
Tenia un controlador de dominio w2000 server y unas
maquinas con w2000 profesional. Estas maquinas se unian
perfectamente al dominio sin poner nada en DNS ni puerta
de enlace, solo una ip estática.

Al actualizar las maquinas a wXP ya no me deja unir al
dominio.

-Las maquinas se ven entre ellas y ven al servidor
perfectamente

-cuando intento unirlas me llega a crear la cuenta para
el equipo en active directory en el servidor pero no la
llega a habilitar. Pero al final me da un error en las
maquinas xp y no me deja conectarme. El error es el
siguiente:
No se puede unir al dominio xxx . El servidor
especificado no puede ejecutar la operacion
solicitada.

-Tengo el firewall de xp desconectado.

.

Bueno veras. Yo no tengo ni puta idea de esto de redes
asi que si a alguien le dice algo esto.
Esto es lo que me salia en el visor de sucesos:

En el visor de sucesos de Directory Service dice:
-LDAP por medio de SSL no estará disponible por el
momento ya que el servidor no puede obtener un
certificado.

Y en el de DNS Server dice cosas como:
-El servidor DNS no puede completar la enumeración del
servicio de directorios de la zona capi.local. Este
servidor DNS está configurado para usar información de
Active Directory para esta zona y no puede cargar la
zona sin ella. Compruebe que Active Directory está
funcionando correctamente y repite la enumeración de la
zona. Los datos del suceso expresan el error.


Parece que dice cosas interesantes pero yo no se por
donde cogerlas.
Por cierto Javier Inglés muchas gracias por ayudarme y
contestarme tantas veces. Un chat para este tipo de
problemas triunfaria, no habra alguno por ahi?.

Eso está mal...a ver, en el AD lo primero que debe

hacerse es eliminar la cuenta de maŽquina que no se use;
después se crea la cuenta de máquina nuevamente para que
se genere un nuevo SID para ella; después se añade la
máquina al dominio

Salu2!!!

Javier Inglés
MS-MVP

:
<<<QUITAR "NOSPAM" PARA MANDAR MAIL>>>

Este mensaje se proporciona "como está" sin garantías de

ninguna clase, y no otorga ningún derecho

"Nicolas" escribió en

el mensaje news:096d01c3503f$39d29690$

Muchas gracias por la informacion
Me voy a poner a leerla ahora mismo a ver si saco algo.
Respecto a lo de cambiar el nombre de la maquina he
intentar unirla lo que me pasa e slo siguiente.

Se me une al dominio pero me sigue dando el error de
siempre. Entonces la maquina se llama por ejemplo
equipo24 ahora, pero en active directory se mantiene el
antiguo nombre por ejem equipo 4 por lo que cuando
reinicio el xp no me encuentra la cuenta de equipo.

Más posibilidades; crea antes el nombre de máquina en

el

DCy prueba a unirlo; si falla; crea otro nombre, le
cambias el nombre a la estación y reinicias; después
intenta unirlo de nuevo.

A parte...hay más de un DC?? Si es así...replican éstos

correctamente??

Má info:

How Domain Controllers Are Located in Windows XP
PSS ID Number: 314861

Article Last Modified on 8/6/2002

-

The information in this article applies to:


a.. Microsoft Windows XP Professional

-

This article was previously published under Q314861
For a Microsoft Windows 2000 version of this article,

see 247811.

SUMMARY
This article describes the mechanism that Windows XP

Professional uses to locate a domain controller in a
Windows-based domain.

The article details the process of locating a domain by

its DNS-style name and by its flat-style (NetBIOS) name,
which is used for backward compatibility. In all other
cases, it is recommended that you use DNS-style names as
a matter of policy.

The article also addresses issues that are involved in

troubleshooting the domain controller location process.

MORE INFORMATION
The following sequence describes how the Locator finds

a

domain controller:

a.. On the client (the computer that is trying to

locate the domain controller), the Locator is initiated
as a remote procedure call (RPC) to the local Netlogon
service. The Netlogon service implements the Locator
DsGetDcName API call.

b.. The client collects the information that is

needed

to select a domain controller, and then passes the
information to the Netlogon service by using the
DsGetDcName call.

c.. The Netlogon service on the client uses the

collected information to look up a domain controller for
the specified domain in one of two ways:

a.. For a DNS name, Netlogon queries DNS by using

the IP/DNS-compatible Locator--that is, DsGetDcName

calls

the DnsQuery call to read the Service Resource (SRV)
records and "A" records from DNS after the domain name

is

appended to the appropriate string that specifies the

SRV

records.

A workstation that is logging on to a Windows-based

domain queries DNS for SRV records in this general form:

_service._protocol.DnsDomainName

Active Directory servers offer the Lightweight

Directory Access Protocol (LDAP) service over the TCP
protocol. Therefore, clients find an LDAP server by
querying DNS for a record of the form:

_ldap._tcp.DnsDomainName

b.. For a NetBIOS name, Netlogon performs domain

controller discovery by using the Microsoft Windows NT
4.0-compatible Locator--that is, by using the transport-
specific mechanism, for example, Windows Internet Name
Service (WINS).

In Windows NT 4.0 and earlier, "discovery" is a

process for locating a domain controller for
authentication in either the primary domain or in a
trusted domain.

d.. The Netlogon service sends a datagram to the

computers that registered the name. For NetBIOS domain
names, the datagram is implemented as a mailslot

message.

For DNS domain names, the datagram is implemented as an
LDAP User Datagram Protocol (UDP) search.

UDP is the connectionless datagram transport protocol

that is part of the TCP/IP protocol suite. TCP is a
connection-oriented transport protocol. Note that UDP
allows a program on one computer to send a datagram to a
program on another computer. UDP includes a protocol

port

number, which allows the sender to distinguish among
multiple destinations (programs) on the remote computer.

e.. Each available domain controller responds to the

datagram to indicate that it is working and returns the
information to DsGetDcName.

f.. The Netlogon service caches the domain controller

information so that subsequent requests do not need to
repeat the discovery process. Caching this information
encourages consistent use of the same domain controller
and a consistent view of Active Directory.

When a client logs on or joins the network, the client

must be able to locate a domain controller. The client
sends a DNS Lookup query to DNS to find domain
controllers, preferably in the client's own subnet.
Therefore, clients find a domain controller by querying
DNS for a record of the form:

_LDAP._TCP.dc._msdcs.domainname

After the client locates a domain controller, the

client

establishes communication by using Lightweight Directory
Access Protocol (LDAP) to gain access to Active
Directory. As part of that negotiation, the domain
controller identifies which site the client is in, based
on the IP subnet of that client. If the client is
communicating with a domain controller that is not in

the

closest (most optimal) site, the domain controller
returns the name of the client's site.

If the client has already tried to find domain

controllers in that site (for example, when the client
sends a DNS Lookup query to DNS to find domain
controllers in the client's own subnet), the client uses
the domain controller that is not optimal. Otherwise,

the

client performs a site-specific DNS lookup again by

using

the name of the optimal site. The domain controller uses
some of the directory service information for

identifying

sites and subnets.

After the client locates a domain controller, the

domain

controller entry is cached. If the domain controller is
not in the optimal site, the client flushes the cache
after 15 minutes and discards the cache entry. The

client

then attempts to find an optimal domain controller in

its

own site.

After the client has established a communications path

to the domain controller, the client can establish its
logon and authentication credentials and, if necessary
for Windows-based computers, set up a secure channel.

The

client then is ready to perform normal queries and

search

for information against the directory.

The client establishes an LDAP connection to a domain

controller to log on. The logon process uses Security
Accounts Manager (SAM). Because the communications path
uses the LDAP interface and the client is authenticated
by a domain controller, the client account is verified
and passed through SAM to the directory service agent,
then to the database layer, and finally to the database
in the Extensible Storage engine (ESE).

Troubleshooting the Domain Locator Process
To troubleshoot the domain locator process:
1.. Check Event Viewer to see whether the event logs

contain any error information. On both the client and

the

server, check the System log for failures during the
logon process. Also, check the Directory Service logs on
the server and the DNS logs on the DNS server.

To view Event Viewer in Windows XP, click Start,

click

Control Panel, double-click Administrative Tools, and
then double-click Event Viewer.

2.. Check the IP configuration by running the

ipconfig /all command at a command prompt. Verify that
the configuration is correct for your network.

3.. Use the Ping utility to verify network

connectivity and name resolution. Ping both the IP
address and the server name.

4.. Check the Network Diagnostics tool in Help and

Support under "Use Tools to view your computer
information and diagnose problems" to determine whether
the network components are correctly installed and
working properly. Network Diagnostics also runs some
tests and provides information about the network
configuration, information that can be helpful.

5.. Use the nltest /dsgetdc:domainname command to

verify that a domain controller can be located for a
specific domain. The NLTest tool is installed with the
Windows XP support tools.

For information about how to install these tools,

refer to the following article in the Microsoft

Knowledge

Base:

306794 How to Install the Support Tools from the

Windows XP CD-ROM

6.. Use the NSLookup tool to verify that DNS entries

are correctly registered in DNS. Verify that the server
host records and GUID SRV records can be resolved.

For example, to verify record registration, use the

following commands:

nslookup

server_name.child_of_root_domain.root_domain.com

nslookup guid._msdcs.root_domain.com

7.. If either of these commands does not succeed, use

one of the following methods to reregister records with
DNS:

a.. To force host record registration, type

ipconfig /registerdns.

b.. To force domain controller service

registration,

stop and then restart the Netlogon service.

8.. To verify appropriate LDAP connectivity, use the

Ldp.exe tool to connect and bind to the domain
controller. Ldp.exe is a support tool that you can
install from the Windows XP CD-ROM.

For information about how to install these tools,

refer to the following article in the Microsoft

Knowledge

Base:

306794 How to Install the Support Tools from the

Windows XP CD-ROM

9.. If you suspect that a particular domain

controller

has problems, turn on the Netlogon debug logging. Use

the

NLTest utility by typing nltest /dbflag:0x2000ffff at a
command prompt. The information is logged in the Debug
folder in the Netlogon.log file.

10.. If you still have not isolated the problem, use

Network Monitor to monitor network traffic between the
client and the domain controller.

For additional information, refer to the Windows 2000

Server Resource Kit, Chapter 10, "Active Directory
Diagnostic, Troubleshooting, and Recovery."

Keywords: kbDNS kbenv kbinfo kbnetwork KB314861
Technology: kbWinXPPro kbWinXPProSearch kbWinXPSearch



Presta a tención al nltest



Salu2!!!


Javier Inglés
MS-MVP

:
<<<QUITAR "NOSPAM" PARA MANDAR MAIL>>>

Este mensaje se proporciona "como está" sin garantías

de

ninguna clase, y no otorga ningún derecho

"Javier Inglés [MS MVP]"

escribió en el mensaje
news:u%

En el dominio...están activos los 5 FSMO????
En el XP...has probado a hacer un ping al nombre de

dominio y ver que responde bien???

Y en el event viewer, qué más dice???

Salu2!!!

Javier Inglés
MS-MVP

:
<<<QUITAR "NOSPAM" PARA MANDAR MAIL>>>

Este mensaje se proporciona "como está" sin garantías

de

ninguna clase, y no otorga ningún derecho

"Nicolas" escribió

en

el mensaje news:072801c3502a$76a18050$

Siento taladrar pero es que hoy tengo que hacer el
dominio o joderme y hacer un grupo de trabajo.

Ya he probado poner la IP del servidor que es el que
tiene Active directory en la DNS de las maquinas xp...
y sigue diciendo exactamente lo mismo.

Supongo que antes funcionaba por que tendria algo de

DHCP

o algo asi para asignar dinamicamente.
(A lo mejor sigue activo y crea conflicto no tengo

ni

idea, puede ser una pedrada, vosotros direis).

Gracias por contestarme.

Para quien no haya leido el mensaje anterior o no os
acordeis era este:
La cosa esta asi.
Tenia un controlador de dominio w2000 server y unas
maquinas con w2000 profesional. Estas maquinas se unian
perfectamente al dominio sin poner nada en DNS ni

puerta

de enlace, solo una ip estática.

Al actualizar las maquinas a wXP ya no me deja unir al
dominio.

-Las maquinas se ven entre ellas y ven al servidor
perfectamente

-cuando intento unirlas me llega a crear la cuenta para
el equipo en active directory en el servidor pero no la
llega a habilitar. Pero al final me da un error en las
maquinas xp y no me deja conectarme. El error es el
siguiente:
No se puede unir al dominio xxx . El servidor
especificado no puede ejecutar la operacion
solicitada.

-Tengo el firewall de xp desconectado.

.

.

El primer error puede ser tolerable ya que el uso de LDAP por SSL es raro que se implemente. El segundo es debido a que puede ser un error temporal o bien el que configuró el AD y el DNS no lo ha hecho correctamentepor lo que habría que revisarlo de cabo a rabo para ver que está todo correcto.

Si no, poco se puede avanzar...has probado a crear una nueva cuenta y añadir el XP con el nuevo nombre???

Salu2!!

Javier Inglés
MS-MVP

:
<<<QUITAR "NOSPAM" PARA MANDAR MAIL>>>

Este mensaje se proporciona "como está" sin garantías de ninguna clase, y no otorga ningún derecho


"Nicolas" escribió en el mensaje news:04cc01c35046$9348cb20$
Bueno veras. Yo no tengo ni puta idea de esto de redes
asi que si a alguien le dice algo esto.
Esto es lo que me salia en el visor de sucesos:

En el visor de sucesos de Directory Service dice:
-LDAP por medio de SSL no estará disponible por el
momento ya que el servidor no puede obtener un
certificado.

Y en el de DNS Server dice cosas como:
-El servidor DNS no puede completar la enumeración del
servicio de directorios de la zona capi.local. Este
servidor DNS está configurado para usar información de
Active Directory para esta zona y no puede cargar la
zona sin ella. Compruebe que Active Directory está
funcionando correctamente y repite la enumeración de la
zona. Los datos del suceso expresan el error.


Parece que dice cosas interesantes pero yo no se por
donde cogerlas.
Por cierto Javier Inglés muchas gracias por ayudarme y
contestarme tantas veces. Un chat para este tipo de
problemas triunfaria, no habra alguno por ahi?.

Eso está mal...a ver, en el AD lo primero que debe

hacerse es eliminar la cuenta de maŽquina que no se use;
después se crea la cuenta de máquina nuevamente para que
se genere un nuevo SID para ella; después se añade la
máquina al dominio

Salu2!!!

Javier Inglés
MS-MVP

:
<<<QUITAR "NOSPAM" PARA MANDAR MAIL>>>

Este mensaje se proporciona "como está" sin garantías de

ninguna clase, y no otorga ningún derecho

"Nicolas" escribió en

el mensaje news:096d01c3503f$39d29690$

Muchas gracias por la informacion
Me voy a poner a leerla ahora mismo a ver si saco algo.
Respecto a lo de cambiar el nombre de la maquina he
intentar unirla lo que me pasa e slo siguiente.

Se me une al dominio pero me sigue dando el error de
siempre. Entonces la maquina se llama por ejemplo
equipo24 ahora, pero en active directory se mantiene el
antiguo nombre por ejem equipo 4 por lo que cuando
reinicio el xp no me encuentra la cuenta de equipo.

Más posibilidades; crea antes el nombre de máquina en

el

DCy prueba a unirlo; si falla; crea otro nombre, le
cambias el nombre a la estación y reinicias; después
intenta unirlo de nuevo.

A parte...hay más de un DC?? Si es así...replican éstos

correctamente??

Má info:

How Domain Controllers Are Located in Windows XP
PSS ID Number: 314861

Article Last Modified on 8/6/2002

-

The information in this article applies to:


a.. Microsoft Windows XP Professional

-

This article was previously published under Q314861
For a Microsoft Windows 2000 version of this article,

see 247811.

SUMMARY
This article describes the mechanism that Windows XP

Professional uses to locate a domain controller in a
Windows-based domain.

The article details the process of locating a domain by

its DNS-style name and by its flat-style (NetBIOS) name,
which is used for backward compatibility. In all other
cases, it is recommended that you use DNS-style names as
a matter of policy.

The article also addresses issues that are involved in

troubleshooting the domain controller location process.

MORE INFORMATION
The following sequence describes how the Locator finds

a

domain controller:

a.. On the client (the computer that is trying to

locate the domain controller), the Locator is initiated
as a remote procedure call (RPC) to the local Netlogon
service. The Netlogon service implements the Locator
DsGetDcName API call.

b.. The client collects the information that is

needed

to select a domain controller, and then passes the
information to the Netlogon service by using the
DsGetDcName call.

c.. The Netlogon service on the client uses the

collected information to look up a domain controller for
the specified domain in one of two ways:

a.. For a DNS name, Netlogon queries DNS by using

the IP/DNS-compatible Locator--that is, DsGetDcName

calls

the DnsQuery call to read the Service Resource (SRV)
records and "A" records from DNS after the domain name

is

appended to the appropriate string that specifies the

SRV

records.

A workstation that is logging on to a Windows-based

domain queries DNS for SRV records in this general form:

_service._protocol.DnsDomainName

Active Directory servers offer the Lightweight

Directory Access Protocol (LDAP) service over the TCP
protocol. Therefore, clients find an LDAP server by
querying DNS for a record of the form:

_ldap._tcp.DnsDomainName

b.. For a NetBIOS name, Netlogon performs domain

controller discovery by using the Microsoft Windows NT
4.0-compatible Locator--that is, by using the transport-
specific mechanism, for example, Windows Internet Name
Service (WINS).

In Windows NT 4.0 and earlier, "discovery" is a

process for locating a domain controller for
authentication in either the primary domain or in a
trusted domain.

d.. The Netlogon service sends a datagram to the

computers that registered the name. For NetBIOS domain
names, the datagram is implemented as a mailslot

message.

For DNS domain names, the datagram is implemented as an
LDAP User Datagram Protocol (UDP) search.

UDP is the connectionless datagram transport protocol

that is part of the TCP/IP protocol suite. TCP is a
connection-oriented transport protocol. Note that UDP
allows a program on one computer to send a datagram to a
program on another computer. UDP includes a protocol

port

number, which allows the sender to distinguish among
multiple destinations (programs) on the remote computer.

e.. Each available domain controller responds to the

datagram to indicate that it is working and returns the
information to DsGetDcName.

f.. The Netlogon service caches the domain controller

information so that subsequent requests do not need to
repeat the discovery process. Caching this information
encourages consistent use of the same domain controller
and a consistent view of Active Directory.

When a client logs on or joins the network, the client

must be able to locate a domain controller. The client
sends a DNS Lookup query to DNS to find domain
controllers, preferably in the client's own subnet.
Therefore, clients find a domain controller by querying
DNS for a record of the form:

_LDAP._TCP.dc._msdcs.domainname

After the client locates a domain controller, the

client

establishes communication by using Lightweight Directory
Access Protocol (LDAP) to gain access to Active
Directory. As part of that negotiation, the domain
controller identifies which site the client is in, based
on the IP subnet of that client. If the client is
communicating with a domain controller that is not in

the

closest (most optimal) site, the domain controller
returns the name of the client's site.

If the client has already tried to find domain

controllers in that site (for example, when the client
sends a DNS Lookup query to DNS to find domain
controllers in the client's own subnet), the client uses
the domain controller that is not optimal. Otherwise,

the

client performs a site-specific DNS lookup again by

using

the name of the optimal site. The domain controller uses
some of the directory service information for

identifying

sites and subnets.

After the client locates a domain controller, the

domain

controller entry is cached. If the domain controller is
not in the optimal site, the client flushes the cache
after 15 minutes and discards the cache entry. The

client

then attempts to find an optimal domain controller in

its

own site.

After the client has established a communications path

to the domain controller, the client can establish its
logon and authentication credentials and, if necessary
for Windows-based computers, set up a secure channel.

The

client then is ready to perform normal queries and

search

for information against the directory.

The client establishes an LDAP connection to a domain

controller to log on. The logon process uses Security
Accounts Manager (SAM). Because the communications path
uses the LDAP interface and the client is authenticated
by a domain controller, the client account is verified
and passed through SAM to the directory service agent,
then to the database layer, and finally to the database
in the Extensible Storage engine (ESE).

Troubleshooting the Domain Locator Process
To troubleshoot the domain locator process:
1.. Check Event Viewer to see whether the event logs

contain any error information. On both the client and

the

server, check the System log for failures during the
logon process. Also, check the Directory Service logs on
the server and the DNS logs on the DNS server.

To view Event Viewer in Windows XP, click Start,

click

Control Panel, double-click Administrative Tools, and
then double-click Event Viewer.

2.. Check the IP configuration by running the

ipconfig /all command at a command prompt. Verify that
the configuration is correct for your network.

3.. Use the Ping utility to verify network

connectivity and name resolution. Ping both the IP
address and the server name.

4.. Check the Network Diagnostics tool in Help and

Support under "Use Tools to view your computer
information and diagnose problems" to determine whether
the network components are correctly installed and
working properly. Network Diagnostics also runs some
tests and provides information about the network
configuration, information that can be helpful.

5.. Use the nltest /dsgetdc:domainname command to

verify that a domain controller can be located for a
specific domain. The NLTest tool is installed with the
Windows XP support tools.

For information about how to install these tools,

refer to the following article in the Microsoft

Knowledge

Base:

306794 How to Install the Support Tools from the

Windows XP CD-ROM

6.. Use the NSLookup tool to verify that DNS entries

are correctly registered in DNS. Verify that the server
host records and GUID SRV records can be resolved.

For example, to verify record registration, use the

following commands:

nslookup

server_name.child_of_root_domain.root_domain.com

nslookup guid._msdcs.root_domain.com

7.. If either of these commands does not succeed, use

one of the following methods to reregister records with
DNS:

a.. To force host record registration, type

ipconfig /registerdns.

b.. To force domain controller service

registration,

stop and then restart the Netlogon service.

8.. To verify appropriate LDAP connectivity, use the

Ldp.exe tool to connect and bind to the domain
controller. Ldp.exe is a support tool that you can
install from the Windows XP CD-ROM.

For information about how to install these tools,

refer to the following article in the Microsoft

Knowledge

Base:

306794 How to Install the Support Tools from the

Windows XP CD-ROM

9.. If you suspect that a particular domain

controller

has problems, turn on the Netlogon debug logging. Use

the

NLTest utility by typing nltest /dbflag:0x2000ffff at a
command prompt. The information is logged in the Debug
folder in the Netlogon.log file.

10.. If you still have not isolated the problem, use

Network Monitor to monitor network traffic between the
client and the domain controller.

For additional information, refer to the Windows 2000

Server Resource Kit, Chapter 10, "Active Directory
Diagnostic, Troubleshooting, and Recovery."

Keywords: kbDNS kbenv kbinfo kbnetwork KB314861
Technology: kbWinXPPro kbWinXPProSearch kbWinXPSearch



Presta a tención al nltest



Salu2!!!


Javier Inglés
MS-MVP

:
<<<QUITAR "NOSPAM" PARA MANDAR MAIL>>>

Este mensaje se proporciona "como está" sin garantías

de

ninguna clase, y no otorga ningún derecho

"Javier Inglés [MS MVP]"

escribió en el mensaje
news:u%

En el dominio...están activos los 5 FSMO????
En el XP...has probado a hacer un ping al nombre de

dominio y ver que responde bien???

Y en el event viewer, qué más dice???

Salu2!!!

Javier Inglés
MS-MVP

:
<<<QUITAR "NOSPAM" PARA MANDAR MAIL>>>

Este mensaje se proporciona "como está" sin garantías

de

ninguna clase, y no otorga ningún derecho

"Nicolas" escribió

en

el mensaje news:072801c3502a$76a18050$

Siento taladrar pero es que hoy tengo que hacer el
dominio o joderme y hacer un grupo de trabajo.

Ya he probado poner la IP del servidor que es el que
tiene Active directory en la DNS de las maquinas xp...
y sigue diciendo exactamente lo mismo.

Supongo que antes funcionaba por que tendria algo de

DHCP

o algo asi para asignar dinamicamente.
(A lo mejor sigue activo y crea conflicto no tengo

ni

idea, puede ser una pedrada, vosotros direis).

Gracias por contestarme.

Para quien no haya leido el mensaje anterior o no os
acordeis era este:
La cosa esta asi.
Tenia un controlador de dominio w2000 server y unas
maquinas con w2000 profesional. Estas maquinas se unian
perfectamente al dominio sin poner nada en DNS ni

puerta

de enlace, solo una ip estática.

Al actualizar las maquinas a wXP ya no me deja unir al
dominio.

-Las maquinas se ven entre ellas y ven al servidor
perfectamente

-cuando intento unirlas me llega a crear la cuenta para
el equipo en active directory en el servidor pero no la
llega a habilitar. Pero al final me da un error en las
maquinas xp y no me deja conectarme. El error es el
siguiente:
No se puede unir al dominio xxx . El servidor
especificado no puede ejecutar la operacion
solicitada.

-Tengo el firewall de xp desconectado.

.

.