\\computername error: The target account name is incorrect.

[Guest]

Network: Primary Domain Controller (PDC), Domain controller(DC) + 10
workstations.

Implemented new firewall and forgot to disable it's DHCP server. Next
morning come-in and can't access \\PDC. \\IPaddress method works fine. Many
other functions work like that as well (e.g. connecting to PDC services
console is possible only as IP). Pinging works fine by name or IP. So does
netstat -A, -a.
DNS looks fine.

DHCP contains BAD_ADDRESS entries after I released them all. Machines with
dynamic IP continue to work fine though.


Steps taken:
external dhcp disabled and all leases dropped ofcourse
flushed dns
left and re-joined domain on several machines
looked into this article: http://support.microsoft.com/?id=288167
but even workstations can't connect. they don't have Kerberos Center to
disable.
Tried it anyways on DC, but get same error when run netdom resetpwd....

What can I do to diagnose it further. Any hints or tips on how to proceed. I
am not very experienced so I appreciate your assistance.


Sergey

 

[Steven L Umbach]

Check to make sure the domain controller is pointing to itself ONLY as it's
preferred dns server as shown by ipconfig /all and that it has a static IP
address. Your Windows 2000/XP Pro computers must point to only the domain
controller as their preferred dns server. You say dns looks fine, but I am
not sure what you mean by that and a common problem is that domain computers
are configured to use ISP dns server as a preferred dns server and this must
never be done. See the link below for more info on AD dns.

http://support.microsoft.com/default.aspx?scid=kb;en-us;291382

Use Ipconfig /all on your computers to make sure they have the correct IP
addresses and that dns is correct. Then use the support tools netdiag and
dcdiag on your domain controller to see if it reports that it has a clean
bill of health and check Event Viewer for any pertinent errors. If problems
are found on the domain controller they are probably dns related and after
verifying proper configuration run the following commands on the dns server
in this order. Ipconfig /flushdns, ipconfig /registerdns, netdiag /fix, net
stop netlogon, net start netlogon. Then check dns on your server to make
sure that your domain zone exists and that _srv service records exist also
for the domain. You can also use netdiag to domain computers to check for
problems. My guess is that your problems are probably dns related. Critical
network resources are found by domain computers querying dns in an Active
Directory domain and if domain computers start trying to find those records
on an ISP dns server all kinds of problems will ensue.--- Steve

 

[Guest]

Steven, thank you for your advice.

This morning one of the users couldn't log in anywhere on the network. I
linked it back night before when I tried following Microsoft article,
disabling kerberos center and resetting netdom. But I ran netdiag /fix and it
solved the problem. However old problem of not being able to access
\\EXCHANGE remains.

Couple more facts:
When looking at \\DC2 DNS, first DNS server \\EXCHANGE has STOP sign next to
it and said access is denied.
DC2 DNS can be accessed ok.

C:\>net use \\exchange
System error 1396 has occurred.

Logon Failure: The target account name is incorrect.


after running netdiag /fix on \\DC2 the only warning message came up was this
[WARNING] Failed to query SPN registration on DC
'exchange.domain_name.local'.

But I'm not sure if it was there before and Microsoft article mentiones it
as known but harmless warning.

netdiag /fix ran fine on \\EXCHANGE second time

I will monitor both DCs over weekend and keep searching for solution.

 

[Steven L Umbach]

If you have not done such yet try running dcdiag on both of the domain
controllers to see if anything pertinent is reported. It may take a bit for
things to get back in synch and hopefully by now they are working
etter. --- Steve

 

[Guest]

Steven,

PDC and DC had trouble replicating..
The File Replication Service is having trouble enabling replication from DC2
to EXCHANGE for c:\winnt\sysvol\domain using DNS name DC2.domainname.local.
FRS will keep trying.

And while running dcdiag:
Starting test: frssysvol
Error: No record of File Replication System, SYSVOL started. The Active
Directory may be prevent from starting. There are errors after SYSVOL has
been shared. The SYSVOL can prevent the AD from starting.

I understand that all these errors stem from one problem.
Firewall DHCP that I left on overnight somehow took over duties of PDC. Even
after I deleted DHCP range and disabled DHCP service and restarted firewall,
PDC can't find it's way back as PDC of network.

I can't be the only one who turned on second DHCP server on different
machines on same network and caused something similar. I just want my network
back! With all it's faults I'll take it back and let bygones be bygones. But
it's not doing that.

 

[Steven L Umbach]

I find it hard to believe that just enabling DHCP on a firewall appliance as
the domain controllers should have static IP addresses [I hope your's did ].
But you never know or it could be a coincidence. Does the sysvol shared
folder exist on both domain controllers? If you enter \\dcname\sysvol in
the run box of each dc you should be able to access the sysvol share on the
other domain controller [using the other domain controllers read name
instead of \\dcname of course]. I would also run dcdiag /fix on each domain
controller and rerun netdiag on each one to see what is reported. If
possible run ipconfig /all on each domain controller and paste in a reply
here. Also reboot the problem domain controller if you have not done such
lately. Check your dns Management Console on each domain controller to make
sure your domain zone exists, that the IP addresses shown for your domain
controllers are correct, and that the _srv records exist on each domain
controller. --- Steve

http://support.microsoft.com/?kbid=260371 --- this link may be helpful.
http://support.microsoft.com/?kbid=241515 --- how to verify _srv records
including the use of nslookup.

 

[Guest]

Steven, I am happy to report that the problem went away. It looks like
running netdiag /fix and dcdiag /fix and following up with restart (several
other machines had to be reintroduced to domain) solved the DNS mix up, just
like you said. I would like to thank you for being on the other end and
walking me through, when it seemed like hell on this end. DHCP scope still
had bad_addresses, so I just deleted it and created new scope and now it
seems fine.

Sergey

 

[Steven L Umbach]

Excellent. Glad you got it sorted out and thanks for reporting back. ---
Steve