Logon problems after beginning AD migration

[Geni]

Archived from groups: microsoft.public.win2000.active_directory (More info?)

Here's the scenario - I have about 28 NT domains, all with two-way trusts to
the domain in the central office. (None of the domains trust one another.)
Two weeks ago, I did an in-place upgrade of the central office domain to 2003
Active Directory.

Since then, I've had a sporadic problem with logons. It's specific to users
whose machines are in the trusted (NT) domains, but whose accounts are in the
central office domain (AD). When they try to logon to any account in the AD
domain, they get: The domain password you supplied is not correct, or access
to your logon server has been denied. This is happening not just with W9x
clients, but also 2000 and XP clients. The same machines can log on a local
domain account with no problem. Other machines in the local domain can log
on users on the central office domain with no problem.

I'm tearing my hair out over this one. If it were just W9X machines, I'd
assume it's a matter of AD client extensions, but the newer machines confuse
the issue.

A complication - when I did the upgrade, I upgraded my existing NT PDC. It
was barely adequate for 2003 server, so after I had a BDC in place, I tried
to transfer the FSMO roles to the BDC so I could demote and reload it. I was
unable to transfer the roles, as the BDC insisted the server with those roles
was offline. I finally did a seize of the roles, did a dcpromo /forceremoval
on the old PDC, then completely reloaded it and repromoted it, with the same
name. Did I miss something when I removed the old PDC from the domain?

Any advice would be helpful. Thanks!

 

[Guest]

Archived from groups: microsoft.public.win2000.active_directory (More info?)

The main issue here looks to be name resolution -specifically DNS. The OM
seizure and DC failure is separate, and quite possibly a red herring.

Follow the instructions in this article for help on the latter point you
posted:
-- http://support.microsoft.com/kb/216498


With regards to the trusts, the machines that are logging into the non-2003
domains need the authenticating DCs to be able to contact the correct DCs in
the 2003 domain. This means that the NT 4 BDCs need to be able to resolve
the SRV records that sort the DC, PDC, GC, etc. In order to do this, they
need to be able to resolve records in foreign domains. Either point the
BDCs to the DNS servers in the 2003 domain, or configure secondary DNS
servers in the NT 4 domains and configure the machines in these domains to
point at these DNS servers.

How's name resolution configured at the moment anyway?


--

Paul Williams

http://www.msresource.net/
http://forums.msresource.net/

"Geni" <Geni@discussions.microsoft.com> wrote in message
news:6DFEC854-9D0F-48CF-BA0F-659F225DED13@microsoft.com...
Here's the scenario - I have about 28 NT domains, all with two-way trusts to
the domain in the central office. (None of the domains trust one another.)
Two weeks ago, I did an in-place upgrade of the central office domain to
2003
Active Directory.

Since then, I've had a sporadic problem with logons. It's specific to users
whose machines are in the trusted (NT) domains, but whose accounts are in
the
central office domain (AD). When they try to logon to any account in the AD
domain, they get: The domain password you supplied is not correct, or
access
to your logon server has been denied. This is happening not just with W9x
clients, but also 2000 and XP clients. The same machines can log on a local
domain account with no problem. Other machines in the local domain can log
on users on the central office domain with no problem.

I'm tearing my hair out over this one. If it were just W9X machines, I'd
assume it's a matter of AD client extensions, but the newer machines confuse
the issue.

A complication - when I did the upgrade, I upgraded my existing NT PDC. It
was barely adequate for 2003 server, so after I had a BDC in place, I tried
to transfer the FSMO roles to the BDC so I could demote and reload it. I
was
unable to transfer the roles, as the BDC insisted the server with those
roles
was offline. I finally did a seize of the roles, did a dcpromo
/forceremoval
on the old PDC, then completely reloaded it and repromoted it, with the same
name. Did I miss something when I removed the old PDC from the domain?

Any advice would be helpful. Thanks!

 

[Geni]

Archived from groups: microsoft.public.win2000.active_directory (More info?)

The NT domain controllers are pointing to the same WINS and DNS servers as
the AD domain controllers, unfortunately. I'm hoping my techs gave me bum
information and these are all Win9X machines and the AD client extensions
resolves the issue. So far, all the ones I've been able to definitely track
down ARE Win9X.

"ptwilliams" wrote:

> The main issue here looks to be name resolution -specifically DNS. The OM
> seizure and DC failure is separate, and quite possibly a red herring.
>
> Follow the instructions in this article for help on the latter point you
> posted:
> -- http://support.microsoft.com/kb/216498
>
>
> With regards to the trusts, the machines that are logging into the non-2003
> domains need the authenticating DCs to be able to contact the correct DCs in
> the 2003 domain. This means that the NT 4 BDCs need to be able to resolve
> the SRV records that sort the DC, PDC, GC, etc. In order to do this, they
> need to be able to resolve records in foreign domains. Either point the
> BDCs to the DNS servers in the 2003 domain, or configure secondary DNS
> servers in the NT 4 domains and configure the machines in these domains to
> point at these DNS servers.
>
> How's name resolution configured at the moment anyway?
>
>
> --
>
> Paul Williams
>
> http://www.msresource.net/
> http://forums.msresource.net/
>
> "Geni" <Geni@discussions.microsoft.com> wrote in message
> news:6DFEC854-9D0F-48CF-BA0F-659F225DED13@microsoft.com...
> Here's the scenario - I have about 28 NT domains, all with two-way trusts to
> the domain in the central office. (None of the domains trust one another.)
> Two weeks ago, I did an in-place upgrade of the central office domain to
> 2003
> Active Directory.
>
> Since then, I've had a sporadic problem with logons. It's specific to users
> whose machines are in the trusted (NT) domains, but whose accounts are in
> the
> central office domain (AD). When they try to logon to any account in the AD
> domain, they get: The domain password you supplied is not correct, or
> access
> to your logon server has been denied. This is happening not just with W9x
> clients, but also 2000 and XP clients. The same machines can log on a local
> domain account with no problem. Other machines in the local domain can log
> on users on the central office domain with no problem.
>
> I'm tearing my hair out over this one. If it were just W9X machines, I'd
> assume it's a matter of AD client extensions, but the newer machines confuse
> the issue.
>
> A complication - when I did the upgrade, I upgraded my existing NT PDC. It
> was barely adequate for 2003 server, so after I had a BDC in place, I tried
> to transfer the FSMO roles to the BDC so I could demote and reload it. I
> was
> unable to transfer the roles, as the BDC insisted the server with those
> roles
> was offline. I finally did a seize of the roles, did a dcpromo
> /forceremoval
> on the old PDC, then completely reloaded it and repromoted it, with the same
> name. Did I miss something when I removed the old PDC from the domain?
>
> Any advice would be helpful. Thanks!
>
>
>

 

[Guest]

Archived from groups: microsoft.public.win2000.active_directory (More info?)

Good news!!

--

Paul Williams

http://www.msresource.net/
http://forums.msresource.net/

"Geni" <Geni@discussions.microsoft.com> wrote in message
news:EFD1329B-778C-429A-904E-0247D479BD45@microsoft.com...
The NT domain controllers are pointing to the same WINS and DNS servers as
the AD domain controllers, unfortunately. I'm hoping my techs gave me bum
information and these are all Win9X machines and the AD client extensions
resolves the issue. So far, all the ones I've been able to definitely track
down ARE Win9X.

"ptwilliams" wrote:

> The main issue here looks to be name resolution -specifically DNS. The OM
> seizure and DC failure is separate, and quite possibly a red herring.
>
> Follow the instructions in this article for help on the latter point you
> posted:
> -- http://support.microsoft.com/kb/216498
>
>
> With regards to the trusts, the machines that are logging into the
> non-2003
> domains need the authenticating DCs to be able to contact the correct DCs
> in
> the 2003 domain. This means that the NT 4 BDCs need to be able to resolve
> the SRV records that sort the DC, PDC, GC, etc. In order to do this, they
> need to be able to resolve records in foreign domains. Either point the
> BDCs to the DNS servers in the 2003 domain, or configure secondary DNS
> servers in the NT 4 domains and configure the machines in these domains to
> point at these DNS servers.
>
> How's name resolution configured at the moment anyway?
>
>
> --
>
> Paul Williams
>
> http://www.msresource.net/
> http://forums.msresource.net/
>
> "Geni" <Geni@discussions.microsoft.com> wrote in message
> news:6DFEC854-9D0F-48CF-BA0F-659F225DED13@microsoft.com...
> Here's the scenario - I have about 28 NT domains, all with two-way trusts
> to
> the domain in the central office. (None of the domains trust one
> another.)
> Two weeks ago, I did an in-place upgrade of the central office domain to
> 2003
> Active Directory.
>
> Since then, I've had a sporadic problem with logons. It's specific to
> users
> whose machines are in the trusted (NT) domains, but whose accounts are in
> the
> central office domain (AD). When they try to logon to any account in the
> AD
> domain, they get: The domain password you supplied is not correct, or
> access
> to your logon server has been denied. This is happening not just with W9x
> clients, but also 2000 and XP clients. The same machines can log on a
> local
> domain account with no problem. Other machines in the local domain can
> log
> on users on the central office domain with no problem.
>
> I'm tearing my hair out over this one. If it were just W9X machines, I'd
> assume it's a matter of AD client extensions, but the newer machines
> confuse
> the issue.
>
> A complication - when I did the upgrade, I upgraded my existing NT PDC.
> It
> was barely adequate for 2003 server, so after I had a BDC in place, I
> tried
> to transfer the FSMO roles to the BDC so I could demote and reload it. I
> was
> unable to transfer the roles, as the BDC insisted the server with those
> roles
> was offline. I finally did a seize of the roles, did a dcpromo
> /forceremoval
> on the old PDC, then completely reloaded it and repromoted it, with the
> same
> name. Did I miss something when I removed the old PDC from the domain?
>
> Any advice would be helpful. Thanks!
>
>
>