Re: Domain Controllers Can't reach Default Gateway...
- From: "Ace Fekay [MCT]" <aceman@xxxxxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 17 Nov 2009 19:05:58 -0500
"Dave Onex" <dave@xxxxxxxxxxxxx> wrote in message
news:uCunV98ZKHA.4932@xxxxxxxxxxxxxxxxxxxxxxx
"Ace Fekay [MCT]" <aceman@xxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:Oscr4y8ZKHA.4268@xxxxxxxxxxxxxxxxxxxxxxx
"Dave Onex" <dave@xxxxxxxxxxxxx> wrote in message
news:e5c%23xlyZKHA.196@xxxxxxxxxxxxxxxxxxxxxxx
"Ace Fekay [MCT]" <aceman@xxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:Oxgy8exZKHA.1596@xxxxxxxxxxxxxxxxxxxxxxx
"Dave Onex" <dave@xxxxxxxx> wrote in message
news:uWf58uYZKHA.1640@xxxxxxxxxxxxxxxxxxxxxxx
"Dave Onex" <dave@xxxxxxxxxxxxx> wrote in message
news:eCyNwVYZKHA.4920@xxxxxxxxxxxxxxxxxxxxxxx
"Ace Fekay [MCT]" <aceman@xxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:uFVID6WZKHA.196@xxxxxxxxxxxxxxxxxxxxxxx
"Dave Onex" <dave@xxxxxxxxxxxxx> wrote in message
news:%23fkA3IWZKHA.5608@xxxxxxxxxxxxxxxxxxxxxxx
"Ace Fekay [MCT]" <aceman@xxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:%23%23nFpPVZKHA.1640@xxxxxxxxxxxxxxxxxxxxxxx
"Dave Onex" <dave@xxxxxxxxxxxxx> wrote in message
news:ea4X7DNZKHA.1592@xxxxxxxxxxxxxxxxxxxxxxx
"Ace Fekay [MCT]" <aceman@xxxxxxxxxxxxxxxxxxxxxxx> wrote in
message news:e1Q%236iBZKHA.5108@xxxxxxxxxxxxxxxxxxxxxxx
"Dave Onex" <dave@xxxxxxxxxxxxx> wrote in messageExcellent tips Ace - they certainly would have cased it for me. I
news:%23dFH0A%23YKHA.4148@xxxxxxxxxxxxxxxxxxxxxxx
Hi Ace;
In my case the ISA is just a member of the domain - not a
domain controller. Making the ISA a domain controller would be,
in my mind, a recipe for disaster especially from a security
standpoint.
I did find one other thing though and it was important. On one
of the domain controllers the active directory DNS zone for my
domain was missing an important entry. In the _msdcs area of
DNS it was missing the CNAME entry with the GUID for the other
domain controller. That's why it couldn't replicate with the
other domain controller.
When I was testing the DNS I was just using the other domain
controllers machine name. I didn't realize that that record in
that area of the DNS had to be there. In fact, I'd never
ventured into the active directory entries in DNS :-)
Anyway, got it cased and just wanted to update this thread for
archival purposes.
Best;
Dave
I'm glad you got to the bottom of it. The CNAME GUID, among
other SRV records, are all important records. What was the cause
of the missing records? Normally restarting the Netlogon service
on a DC will create the SRV records. If all things are
configured properly, one thing you can do is delete the
system32\config\netlogon.dns and netlogon.bak files, then run
ipconfig /registerdns, then restart Netlogon. If they're still
not being created, then I suspect a misconfiguration somewhere.
As long as you are only using the internal DNS servers, the zone
name allows updates, the Primary DNS Suffix (look at an ipconfig
/all) matches the zone name in DNS, and the domain is not a
single label name, you should be good to go. You can use this
list as things to look for when troubleshooting Dynamic DNS
registration problems.
Ace
don't know why the second Domain controller didn't have an entry
for the first. Once I figured that out I just copied the entry
from the first to the second and everything worked perfectly :-)
It's possible that there was a DNS issue - the network has 4 DNS
servers and they're pretty complex. I set them up years ago and,
generally, I've never looked at them since. So every time I have
to make changes I have to revisit DNS and get a handle on it all
over again. The neat thing is, there's nothing like a network
with perfect DNS. Resolution is instant and everything is snappy
:-)
Thanks again, those were/are really good tips.
Best;
Dave
Ok, you got me confused now. You have 4 DNS servers, but you have
two DCs, correct? Or have I misread this?
The best solution for AD is to use Windows DNS on the DCs
themselves. Using BIND or a non-DC for DNS will introduce
complications that if not properly designed, will cause AD issues.
The best recommendation as I mentioned, is to use Windows DNS. If
you have say two DCs, in DC1, point to itself as the first DNS
entry, and the partner DC2 as the second entry. In DC2, point to
itself as first and DC1 as the second entry. This is assuming that
the zone is AD integrated.
If you have four DCs, all DCs should point to themselves as the
first entry, and choose one of the others as the second entry.
If a BIND server is being used, the design would be based on what
capacity the BIND servers are providing the network. If you are
using them as a proxy resolver, eg as the forwarders for your
WIndows DNS servers, and the clients are not using them, then
there will be no problem. If you are using them for AD, BIND
doesn't support Kerberos security nor AD integration. AD
integration means the zone info is store in the actual AD database
which is replicated to all DCs. A BIND or non-DC as a DNS server
doesn't support this feature.
Ace
No confusion needed - you got it!
I have two DC's with AD integrated DNS and one other MS DNS server
configured as a secondary to DC1.
I then have one more DNS server sitting at the edge on ISA 2004
that resolves external requests from external users.
It's working perfectly thanks to your help!
Best;
Dave
You are welcome! :-)
Ace
Say, now that you are here.... and you know a lot about AD etc.....
:-)
I have a question that maybe you can help me with - it might be a
little off-topic but it's the last issue I'm facing on the network -
everything else is 100% perfect.
My server network is all Windows 2000. One of them has Certificate
Services installed. It's working perfectly in that all domain members
got the new root certificate automatically through active directory
and put it in the trusted root section of each machine. In addition,
each Windows 2000 machine can request a machine cert through the
MMC - so Certificate Services is working and configured fine.
The problem is my XP Pro laptop. It did not automatically get the new
root certificate from AD. I waited several days and also issued a
group policy update command - still nothing.
It used to work back when it was getting the certs from a different
machine. Network changes meant that the Certificate services was
removed the old machine and put on a new machine. No old certs were
transferred in the process - all certs are new.
Because the XP laptop wouldn't get the root certificate on it's own I
manually exported the root certificate for my domain and imported it
into the trusted root certificates on the laptop. From that point on
the laptop could request certificates and get them. I thought the
issue was fixed because I can now L2TP into the domain because the
certs are all correct.....
But a problem came up. The XP laptop is always coughing up errors
about w32 time. Specifically, it keeps reporting that the time it's
getting from the NTP server (a local DC) is not signed and that it
might have been tampered with. This is not the case - the XP laptop
is wrong.
The laptop is correctly configured to get it's time from the DC. The
registry entries are correct. Still, it thinks the time from the NTP
server is not signed properly.
I cannot help but think this is related to the laptop not being able
to automatically get the new domain cert from the new domain
controller (the certificate server).
Is there anyway to 'reset' the laptop's certificate settings? Perhaps
it's still looking for the old certificate server (even though it
shouldn't). I tried a gpudate /refresh and while that command works,
the error still arise about the time server and the signature.
I'm about as certain as I can be that actual issue boils down to
this: The XP laptop did not get it's new domain cert from active
directory as it should have. I'm quite certain all other problems
stem from that one oddity. Do you know what would cause that?
Thanks!
Dave
AHA!
I think I cased it. The original problem of the laptop not being able
to download the domain cert was caused by the local group policy on
the laptop being set to NOT perform this action. I don't know how or
why this occurred but the setting was located at;
gpedit.msc => Computer Configuration => Windows Settings => Security
Settings => Public Key Policies => Autoenrollment settings
Enroll Certificates Automatically was NOT selected :-0
Shortly after I selected it the laptop went off, got the domain
certificate and then grabbed a local machine certificate for itself.
I don't know how that setting changed - this machine used to do that
automatically. Anyway, it's another success story :-)
Best;
Dave
Glad to hear you figured that one out. I wouldn't have looked there
first, but I assume you must have searched around for possiblities. Are
you still getting w32time errors after the change?
Ace
Hi Ace!
Interestingly enough, it didn't fix the w32time errors. I was sure it
would because it was the only thing obviously wrong with the laptop
since the network was changed around. Other then the cert issue and the
time issue that laptop was as solid as always...
I could not figure out what was wrong with the time service on that
machine. Instead, I cheated. I went over to my other Xp Pro machine and
exported the entire W32time registry key and imported it into the
laptop. That fixed it (go figure!)
Sometimes it's easier to cheat then to diagnose. Thing is, the laptop
belongs to me and I never changed any of those settings. Prior to the
changes on the network it always got it's certificates and it never had
a time problem. So I don't know what caused the problems in the first
place. But, suffice to say, it's all done now!
Best (and thanks!)
Dave
Interesting cheat. That's one way of doing it.
Curious, how did you step up the time service? By registry entries, or
just using the default command lines (whcih works fine)?
Ace
Hi Ace;
I originally set it up just using the default DOS commands. Specifically,
net time /setsntp with the server name. When I started having problems I
did check for the correct server entry in the registry but that's it. I
can't for the life of me figure out where these two issues originally
stemmed from because both certs and w32tm never had any issues. They were
always 'set it and forget it'. It was only when I changed the network
around that these issues cropped up. As a result of the changes I dropped
to DOS and entered the /setsntp option to point to the new time server.
That seems to be when the problems started but how the registry for w32tm
got goofed is beyond me.
Hmm. I can't see how changing the network around could have caused it,
unless you put in a new DC and transferred the PDC Emulator FSMO role to the
new one from the old or other DC. Read my blog on the time service to get
some insight.
Configuring the Windows Time Service for Windows Server
http://msmvps.com/blogs/acefekay/archive/2009/09/18/configuring-the-windows-time-service-for-windows-server.aspx
Ace
.
- Follow-Ups:
- Re: Domain Controllers Can't reach Default Gateway...
- From: Dave Onex
- Re: Domain Controllers Can't reach Default Gateway...
- References:
- Domain Controllers Can't reach Default Gateway...
- From: Dave Onex
- Re: Domain Controllers Can't reach Default Gateway...
- From: Dave Onex
- Re: Domain Controllers Can't reach Default Gateway...
- From: Ace Fekay [MCT]
- Re: Domain Controllers Can't reach Default Gateway...
- From: Dave Onex
- Re: Domain Controllers Can't reach Default Gateway...
- From: Ace Fekay [MCT]
- Re: Domain Controllers Can't reach Default Gateway...
- From: Dave Onex
- Re: Domain Controllers Can't reach Default Gateway...
- From: Ace Fekay [MCT]
- Re: Domain Controllers Can't reach Default Gateway...
- From: Dave Onex
- Re: Domain Controllers Can't reach Default Gateway...
- From: Ace Fekay [MCT]
- Re: Domain Controllers Can't reach Default Gateway...
- From: Dave Onex
- Re: Domain Controllers Can't reach Default Gateway...
- From: Dave Onex
- Re: Domain Controllers Can't reach Default Gateway...
- From: Ace Fekay [MCT]
- Re: Domain Controllers Can't reach Default Gateway...
- From: Dave Onex
- Re: Domain Controllers Can't reach Default Gateway...
- From: Ace Fekay [MCT]
- Re: Domain Controllers Can't reach Default Gateway...
- From: Dave Onex
- Domain Controllers Can't reach Default Gateway...
- Prev by Date: Re: Domain Controllers Can't reach Default Gateway...
- Next by Date: Re: Domain Controllers Can't reach Default Gateway...
- Previous by thread: Re: Domain Controllers Can't reach Default Gateway...
- Next by thread: Re: Domain Controllers Can't reach Default Gateway...
- Index(es):
Relevant Pages
|