Domain Controllers Can't reach Default Gateway...

[Dave Onex]

Hi Folks;

Neither of my domain controllers can reach the default gateway even though
it's properly defined and there are valid forward and reverse records in
DNS. Pinging the DG results in...nothing. !

Every other machine on the network can ping the DG. All machines are on one
LAN segment with one default gateway.

Everything here is Windows 2000 Advanced Server and ISA 2004.

Background....

I made some network changes by promoting a different machine to become the
DC for the domain. Everything went well and the original machine was demoted
back to standard server. No issues - all is well. Event logs are spotless. A
perfect DCPROMO if ever there was one.

I then promoted a different machine to become a supplemental DC and
everything went well with one issue - FRS reports it's having problems
connecting to the existing DC and reports that it's likely a DNS issue.

I check the DNS network wide and find that there are proper forward and
reverse entries for the server in question. I triple check by looking them
up from a dos prompt - all OK.

So why does FRS fail? Unknown.

I then run netdiag /fix and it reports that the only issue is that it cannot
connect to the default gateway. I check the default gateway and it's
correct! I then ping the default gateway and what do I find? No response.
How can that be?

After checking all machines I find that the only two that can't ping the
default gateway are the Domain Controllers. The DG is properly defined in
each case and there are valid forward and reverse entries in the DNS for the
DG.

I have no clue what's wrong. The key might be that only the domain
controllers can't reach the DG. Can anyone help?

Thanks!
Dave

[Dave Onex]

I seem to have fixed it. It appears to have been a firewall issue where the
firewall was denying ICMP traffic from those two servers :-)

Best;
Dave

Post by Dave Onex
Hi Folks;
Neither of my domain controllers can reach the default gateway even though
it's properly defined and there are valid forward and reverse records in
DNS. Pinging the DG results in...nothing. !
Every other machine on the network can ping the DG. All machines are on
one LAN segment with one default gateway.
Everything here is Windows 2000 Advanced Server and ISA 2004.
Background....
I made some network changes by promoting a different machine to become the
DC for the domain. Everything went well and the original machine was
demoted back to standard server. No issues - all is well. Event logs are
spotless. A perfect DCPROMO if ever there was one.
I then promoted a different machine to become a supplemental DC and
everything went well with one issue - FRS reports it's having problems
connecting to the existing DC and reports that it's likely a DNS issue.
I check the DNS network wide and find that there are proper forward and
reverse entries for the server in question. I triple check by looking them
up from a dos prompt - all OK.
So why does FRS fail? Unknown.
I then run netdiag /fix and it reports that the only issue is that it
cannot connect to the default gateway. I check the default gateway and
it's correct! I then ping the default gateway and what do I find? No
response. How can that be?
After checking all machines I find that the only two that can't ping the
default gateway are the Domain Controllers. The DG is properly defined in
each case and there are valid forward and reverse entries in the DNS for
the DG.
I have no clue what's wrong. The key might be that only the domain
controllers can't reach the DG. Can anyone help?
Thanks!
Dave

[Ace Fekay [MCT]]

Post by Dave Onex
I seem to have fixed it. It appears to have been a firewall issue where the
firewall was denying ICMP traffic from those two servers :-)
Best;
Dave

Post by Dave Onex
Hi Folks;
Neither of my domain controllers can reach the default gateway even
though it's properly defined and there are valid forward and reverse
records in DNS. Pinging the DG results in...nothing. !
Every other machine on the network can ping the DG. All machines are on
one LAN segment with one default gateway.
Everything here is Windows 2000 Advanced Server and ISA 2004.
Background....
I made some network changes by promoting a different machine to become
the DC for the domain. Everything went well and the original machine was
demoted back to standard server. No issues - all is well. Event logs are
spotless. A perfect DCPROMO if ever there was one.
I then promoted a different machine to become a supplemental DC and
everything went well with one issue - FRS reports it's having problems
connecting to the existing DC and reports that it's likely a DNS issue.
I check the DNS network wide and find that there are proper forward and
reverse entries for the server in question. I triple check by looking
them up from a dos prompt - all OK.
So why does FRS fail? Unknown.
I then run netdiag /fix and it reports that the only issue is that it
cannot connect to the default gateway. I check the default gateway and
it's correct! I then ping the default gateway and what do I find? No
response. How can that be?
After checking all machines I find that the only two that can't ping the
default gateway are the Domain Controllers. The DG is properly defined in
each case and there are valid forward and reverse entries in the DNS for
the DG.
I have no clue what's wrong. The key might be that only the domain
controllers can't reach the DG. Can anyone help?
Thanks!
Dave

I was going to say it was probably an ISA issue. If ISA is on a DC, it can
be extremely problematic for a number of reasons. First, it's a DC. If a DC
has more than one NIC, IP address or RRAS on it, it causes a complexity that
causes DNS registration issues. On top of that, if you install ISA, the
complications logirithmically increase.

Glad you figured it out.
--
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Please reply back to the newsgroup or forum for collaboration benefit among
responding engineers, and to help others benefit from your resolution.

Ace Fekay, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007, MCSE & MCSA
2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer

For urgent issues, please contact Microsoft PSS directly. Please check
http://support.microsoft.com for regional support phone numbers.

[Dave Onex]

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

Post by Ace Fekay [MCT]

Post by Dave Onex
I seem to have fixed it. It appears to have been a firewall issue where
the firewall was denying ICMP traffic from those two servers :-)
Best;
Dave

Post by Dave Onex
Hi Folks;
Neither of my domain controllers can reach the default gateway even
though it's properly defined and there are valid forward and reverse
records in DNS. Pinging the DG results in...nothing. !
Every other machine on the network can ping the DG. All machines are on
one LAN segment with one default gateway.
Everything here is Windows 2000 Advanced Server and ISA 2004.
Background....
I made some network changes by promoting a different machine to become
the DC for the domain. Everything went well and the original machine was
demoted back to standard server. No issues - all is well. Event logs are
spotless. A perfect DCPROMO if ever there was one.
I then promoted a different machine to become a supplemental DC and
everything went well with one issue - FRS reports it's having problems
connecting to the existing DC and reports that it's likely a DNS issue.
I check the DNS network wide and find that there are proper forward and
reverse entries for the server in question. I triple check by looking
them up from a dos prompt - all OK.
So why does FRS fail? Unknown.
I then run netdiag /fix and it reports that the only issue is that it
cannot connect to the default gateway. I check the default gateway and
it's correct! I then ping the default gateway and what do I find? No
response. How can that be?
After checking all machines I find that the only two that can't ping the
default gateway are the Domain Controllers. The DG is properly defined
in each case and there are valid forward and reverse entries in the DNS
for the DG.
I have no clue what's wrong. The key might be that only the domain
controllers can't reach the DG. Can anyone help?
Thanks!
Dave

I was going to say it was probably an ISA issue. If ISA is on a DC, it can
be extremely problematic for a number of reasons. First, it's a DC. If a
DC has more than one NIC, IP address or RRAS on it, it causes a complexity
that causes DNS registration issues. On top of that, if you install ISA,
the complications logirithmically increase.
Glad you figured it out.
--
Ace
This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.
Please reply back to the newsgroup or forum for collaboration benefit
among responding engineers, and to help others benefit from your
resolution.
Ace Fekay, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007, MCSE & MCSA
2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
For urgent issues, please contact Microsoft PSS directly. Please check
http://support.microsoft.com for regional support phone numbers.

[Ace Fekay [MCT]]

Post by Dave Onex
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

[Dave Onex]

Post by Ace Fekay [MCT]

Post by Dave Onex
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

Excellent tips Ace - they certainly would have cased it for me. I 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

[Ace Fekay [MCT]]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex
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

Excellent tips Ace - they certainly would have cased it for me. I 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

[Dave Onex]

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex
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

Excellent tips Ace - they certainly would have cased it for me. I 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

[Ace Fekay [MCT]]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex
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

Excellent tips Ace - they certainly would have cased it for me. I 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

[Dave Onex]

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex
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

Excellent tips Ace - they certainly would have cased it for me. I 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

[Dave Onex]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex
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

Excellent tips Ace - they certainly would have cased it for me. I
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

[Ace Fekay [MCT]]

Post by Dave Onex

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex
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

Excellent tips Ace - they certainly would have cased it for me. I
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.
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

[Dave Onex]

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex
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

Excellent tips Ace - they certainly would have cased it for me. I
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.
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

[Ace Fekay [MCT]]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex
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

Excellent tips Ace - they certainly would have cased it for me. I
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.
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

[Dave Onex]

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex
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

Excellent tips Ace - they certainly would have cased it for me. I
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.
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.

[Ace Fekay [MCT]]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex
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

Excellent tips Ace - they certainly would have cased it for me. I
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

[Dave Onex]

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex
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

Excellent tips Ace - they certainly would have cased it for me.
I 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

Hahaha - I din't understand all of that one but it sounds like it might be
what happened.

Here's what I did. Formerly I had one DC called mail (it was also the mail
server). It was an old NetFinity machine (weighed about 160 pounds) and I
wanted to get rid of it. The problem is, the new machine absolutely had to
have the same name. You can't have two machines with the same name on the
network at the same time so I promoted an existing machine called NS1 to
domain controller with the catalog enabled.

I then removed the mail server and installed the new mail server. I then
created another new machine (called backup) and then made it a domain
controller too. So, the domain controller used to be mail and then became
NS1 and then I added one called backup. Both of them have the catalog option
enabled.

Right now I left NS1 as a domain controller - so now I have two. The mail
server is now just mail. But, the NTP server was originally MAIL and it was
also the original Certificate Server. So maybe somewhere in there the laptop
got confused. I know I was (for a while). :-0

The good news is that everything worked out perfectly in the end. Every
machine is working perfectly and you can really tell that DNS is tight
because name resolution is instant. On every machine the event and system
logs are spotless with one exception (and this happens on several machines);

Event ID 42

WMI ADAP was unable to create object Win32_PerfRawData_DNS_DNS for
Performance Library DNS because no value was found for property index 3272
in the 009 subkey

I cased that @&#^$ issue before I changed the network around (I had every
event and system log perfect) but I've since forgotten how I fixed it and
Google searches don't seem to return the great results they used to :-(

Best!
Dave

PS>That was a great article on the time service - unfortunately it never
seemed to show in the Google searches back when I was having the issue :-(

[Ace Fekay [MCT]]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex
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

Excellent tips Ace - they certainly would have cased it for me.
I 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

Hahaha - I din't understand all of that one but it sounds like it might be
what happened.
Here's what I did. Formerly I had one DC called mail (it was also the mail
server). It was an old NetFinity machine (weighed about 160 pounds) and I
wanted to get rid of it. The problem is, the new machine absolutely had to
have the same name. You can't have two machines with the same name on the
network at the same time so I promoted an existing machine called NS1 to
domain controller with the catalog enabled.
I then removed the mail server and installed the new mail server. I then
created another new machine (called backup) and then made it a domain
controller too. So, the domain controller used to be mail and then became
NS1 and then I added one called backup. Both of them have the catalog
option enabled.
Right now I left NS1 as a domain controller - so now I have two. The mail
server is now just mail. But, the NTP server was originally MAIL and it
was also the original Certificate Server. So maybe somewhere in there the
laptop got confused. I know I was (for a while). :-0
The good news is that everything worked out perfectly in the end. Every
machine is working perfectly and you can really tell that DNS is tight
because name resolution is instant. On every machine the event and system
logs are spotless with one exception (and this happens on several machines);
Event ID 42
WMI ADAP was unable to create object Win32_PerfRawData_DNS_DNS for
Performance Library DNS because no value was found for property index 3272
in the 009 subkey
event and system log perfect) but I've since forgotten how I fixed it and
Google searches don't seem to return the great results they used to :-(
Best!
Dave
PS>That was a great article on the time service - unfortunately it never
seemed to show in the Google searches back when I was having the issue :-(

I recently published it from my private archives.

See if the following help with that WMI ADAP issue.

How to troubleshoot WinMgmt-based performance counter errorsDescription: WMI
ADAP was unable to create Object Index number from the Performance Library
serivce name because the value is not found in 009 subkey ...
http://support.microsoft.com/kb/266416

W2K Event ID 54 \Device\WMIServiceDevice17 posts - 9 authors - Last post:
Jul 8
Event ID 42: "WMI ADAP was unable to create object Win32_PerfRawData_DNS_DNS
for Performance Library DNS because no value was found for ...
http://social.technet.microsoft.com/Forums/en-US/winserverhyperv/thread/b5196294-2a17-48de-b8e0-1f103059b79c

Ace

[Dave Onex]

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex
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

Excellent tips Ace - they certainly would have cased it for
me. I 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

Hahaha - I din't understand all of that one but it sounds like it might
be what happened.
Here's what I did. Formerly I had one DC called mail (it was also the
mail server). It was an old NetFinity machine (weighed about 160 pounds)
and I wanted to get rid of it. The problem is, the new machine absolutely
had to have the same name. You can't have two machines with the same name
on the network at the same time so I promoted an existing machine called
NS1 to domain controller with the catalog enabled.
I then removed the mail server and installed the new mail server. I then
created another new machine (called backup) and then made it a domain
controller too. So, the domain controller used to be mail and then became
NS1 and then I added one called backup. Both of them have the catalog
option enabled.
Right now I left NS1 as a domain controller - so now I have two. The mail
server is now just mail. But, the NTP server was originally MAIL and it
was also the original Certificate Server. So maybe somewhere in there the
laptop got confused. I know I was (for a while). :-0
The good news is that everything worked out perfectly in the end. Every
machine is working perfectly and you can really tell that DNS is tight
because name resolution is instant. On every machine the event and system
logs are spotless with one exception (and this happens on several machines);
Event ID 42
WMI ADAP was unable to create object Win32_PerfRawData_DNS_DNS for
Performance Library DNS because no value was found for property index
3272 in the 009 subkey
event and system log perfect) but I've since forgotten how I fixed it and
Google searches don't seem to return the great results they used to :-(
Best!
Dave
PS>That was a great article on the time service - unfortunately it never
seemed to show in the Google searches back when I was having the issue :-(

I recently published it from my private archives.
See if the following help with that WMI ADAP issue.
WMI ADAP was unable to create Object Index number from the Performance
Library serivce name because the value is not found in 009 subkey ...
http://support.microsoft.com/kb/266416
Jul 8
Event ID 42: "WMI ADAP was unable to create object
Win32_PerfRawData_DNS_DNS for Performance Library DNS because no value was
found for ...
http://social.technet.microsoft.com/Forums/en-US/winserverhyperv/thread/b5196294-2a17-48de-b8e0-1f103059b79c
Ace

Been there, done them both. The KB article made the most sense but entering
the clearadap and resyncperf commands result in the error being immediately
logged again in the system log. This tells me it's not a startup issue
because the machine is idle at the time.

I suspect I'll have to live with them both. I thought there was a KB article
on re-building the counters but ever since Microsoft started monkeying with
the site I can't seem to find anything anymore - Argghh!

Best & Thanks!
Dave

[Ace Fekay [MCT]]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex
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

Excellent tips Ace - they certainly would have cased it for
me. I 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

Hahaha - I din't understand all of that one but it sounds like it might
be what happened.
Here's what I did. Formerly I had one DC called mail (it was also the
mail server). It was an old NetFinity machine (weighed about 160 pounds)
and I wanted to get rid of it. The problem is, the new machine
absolutely had to have the same name. You can't have two machines with
the same name on the network at the same time so I promoted an existing
machine called NS1 to domain controller with the catalog enabled.
I then removed the mail server and installed the new mail server. I then
created another new machine (called backup) and then made it a domain
controller too. So, the domain controller used to be mail and then
became NS1 and then I added one called backup. Both of them have the
catalog option enabled.
Right now I left NS1 as a domain controller - so now I have two. The
mail server is now just mail. But, the NTP server was originally MAIL
and it was also the original Certificate Server. So maybe somewhere in
there the laptop got confused. I know I was (for a while). :-0
The good news is that everything worked out perfectly in the end. Every
machine is working perfectly and you can really tell that DNS is tight
because name resolution is instant. On every machine the event and
system logs are spotless with one exception (and this happens on several
machines);
Event ID 42
WMI ADAP was unable to create object Win32_PerfRawData_DNS_DNS for
Performance Library DNS because no value was found for property index
3272 in the 009 subkey
every event and system log perfect) but I've since forgotten how I fixed
it and Google searches don't seem to return the great results they used
to :-(
Best!
Dave
PS>That was a great article on the time service - unfortunately it never
seemed to show in the Google searches back when I was having the issue :-(

I recently published it from my private archives.
See if the following help with that WMI ADAP issue.
WMI ADAP was unable to create Object Index number from the Performance
Library serivce name because the value is not found in 009 subkey ...
http://support.microsoft.com/kb/266416
Jul 8
Event ID 42: "WMI ADAP was unable to create object
Win32_PerfRawData_DNS_DNS for Performance Library DNS because no value
was found for ...
http://social.technet.microsoft.com/Forums/en-US/winserverhyperv/thread/b5196294-2a17-48de-b8e0-1f103059b79c
Ace

Been there, done them both. The KB article made the most sense but
entering the clearadap and resyncperf commands result in the error being
immediately logged again in the system log. This tells me it's not a
startup issue because the machine is idle at the time.
I suspect I'll have to live with them both. I thought there was a KB
article on re-building the counters but ever since Microsoft started
monkeying with the site I can't seem to find anything anymore - Argghh!
Best & Thanks!
Dave

Have you seen this one yet?

How to manually rebuild Performance Counter Library valuesHow to manually
rebuild Performance Counter Library values. View products that this article
applies to. This article was previously published under Q300956 ...
http://support.microsoft.com/kb/300956

Ace

[Dave Onex]

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex
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

Excellent tips Ace - they certainly would have cased it for
me. I 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

Hahaha - I din't understand all of that one but it sounds like it might
be what happened.
Here's what I did. Formerly I had one DC called mail (it was also the
mail server). It was an old NetFinity machine (weighed about 160
pounds) and I wanted to get rid of it. The problem is, the new machine
absolutely had to have the same name. You can't have two machines with
the same name on the network at the same time so I promoted an existing
machine called NS1 to domain controller with the catalog enabled.
I then removed the mail server and installed the new mail server. I
then created another new machine (called backup) and then made it a
domain controller too. So, the domain controller used to be mail and
then became NS1 and then I added one called backup. Both of them have
the catalog option enabled.
Right now I left NS1 as a domain controller - so now I have two. The
mail server is now just mail. But, the NTP server was originally MAIL
and it was also the original Certificate Server. So maybe somewhere in
there the laptop got confused. I know I was (for a while). :-0
The good news is that everything worked out perfectly in the end. Every
machine is working perfectly and you can really tell that DNS is tight
because name resolution is instant. On every machine the event and
system logs are spotless with one exception (and this happens on
several machines);
Event ID 42
WMI ADAP was unable to create object Win32_PerfRawData_DNS_DNS for
Performance Library DNS because no value was found for property index
3272 in the 009 subkey
every event and system log perfect) but I've since forgotten how I
fixed it and Google searches don't seem to return the great results
they used to :-(
Best!
Dave
PS>That was a great article on the time service - unfortunately it
never seemed to show in the Google searches back when I was having the
issue :-(

I recently published it from my private archives.
See if the following help with that WMI ADAP issue.
WMI ADAP was unable to create Object Index number from the Performance
Library serivce name because the value is not found in 009 subkey ...
http://support.microsoft.com/kb/266416
W2K Event ID 54 \Device\WMIServiceDevice17 posts - 9 authors - Last
post: Jul 8
Event ID 42: "WMI ADAP was unable to create object
Win32_PerfRawData_DNS_DNS for Performance Library DNS because no value
was found for ...
http://social.technet.microsoft.com/Forums/en-US/winserverhyperv/thread/b5196294-2a17-48de-b8e0-1f103059b79c
Ace

Been there, done them both. The KB article made the most sense but
entering the clearadap and resyncperf commands result in the error being
immediately logged again in the system log. This tells me it's not a
startup issue because the machine is idle at the time.
I suspect I'll have to live with them both. I thought there was a KB
article on re-building the counters but ever since Microsoft started
monkeying with the site I can't seem to find anything anymore - Argghh!
Best & Thanks!
Dave

Have you seen this one yet?
How to manually rebuild Performance Counter Library valuesHow to manually
rebuild Performance Counter Library values. View products that this
article applies to. This article was previously published under Q300956
...
http://support.microsoft.com/kb/300956
Ace

That's the one I was looking for... thank you!

[Ace Fekay [MCT]]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex
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

Excellent tips Ace - they certainly would have cased it for
me. I 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

Hahaha - I din't understand all of that one but it sounds like it
might be what happened.
Here's what I did. Formerly I had one DC called mail (it was also the
mail server). It was an old NetFinity machine (weighed about 160
pounds) and I wanted to get rid of it. The problem is, the new machine
absolutely had to have the same name. You can't have two machines with
the same name on the network at the same time so I promoted an
existing machine called NS1 to domain controller with the catalog
enabled.
I then removed the mail server and installed the new mail server. I
then created another new machine (called backup) and then made it a
domain controller too. So, the domain controller used to be mail and
then became NS1 and then I added one called backup. Both of them have
the catalog option enabled.
Right now I left NS1 as a domain controller - so now I have two. The
mail server is now just mail. But, the NTP server was originally MAIL
and it was also the original Certificate Server. So maybe somewhere in
there the laptop got confused. I know I was (for a while). :-0
The good news is that everything worked out perfectly in the end.
Every machine is working perfectly and you can really tell that DNS is
tight because name resolution is instant. On every machine the event
and system logs are spotless with one exception (and this happens on
several machines);
Event ID 42
WMI ADAP was unable to create object Win32_PerfRawData_DNS_DNS for
Performance Library DNS because no value was found for property index
3272 in the 009 subkey
every event and system log perfect) but I've since forgotten how I
fixed it and Google searches don't seem to return the great results
they used to :-(
Best!
Dave
PS>That was a great article on the time service - unfortunately it
never seemed to show in the Google searches back when I was having the
issue :-(

I recently published it from my private archives.
See if the following help with that WMI ADAP issue.
How to troubleshoot WinMgmt-based performance counter
errorsDescription: WMI ADAP was unable to create Object Index number
from the Performance Library serivce name because the value is not
found in 009 subkey ...
http://support.microsoft.com/kb/266416
W2K Event ID 54 \Device\WMIServiceDevice17 posts - 9 authors - Last
post: Jul 8
Event ID 42: "WMI ADAP was unable to create object
Win32_PerfRawData_DNS_DNS for Performance Library DNS because no value
was found for ...
http://social.technet.microsoft.com/Forums/en-US/winserverhyperv/thread/b5196294-2a17-48de-b8e0-1f103059b79c
Ace

Been there, done them both. The KB article made the most sense but
entering the clearadap and resyncperf commands result in the error being
immediately logged again in the system log. This tells me it's not a
startup issue because the machine is idle at the time.
I suspect I'll have to live with them both. I thought there was a KB
article on re-building the counters but ever since Microsoft started
monkeying with the site I can't seem to find anything anymore - Argghh!
Best & Thanks!
Dave

Have you seen this one yet?
How to manually rebuild Performance Counter Library valuesHow to manually
rebuild Performance Counter Library values. View products that this
article applies to. This article was previously published under Q300956
...
http://support.microsoft.com/kb/300956
Ace

That's the one I was looking for... thank you!

You are welcome!

[Dave Onex]

Post by Ace Fekay [MCT]

Post by Dave Onex
That's the one I was looking for... thank you!

You are welcome!

Ace, are you still monitoring this thread? I got myself in a little bit of
trouble.... :-(

[Ace Fekay [MCT]]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex
That's the one I was looking for... thank you!

You are welcome!

Ace, are you still monitoring this thread? I got myself in a little bit of
trouble.... :-(

What did you do?

[Dave Onex]

Post by Ace Fekay [MCT]

Post by Dave Onex

Post by Ace Fekay [MCT]

Post by Dave Onex
That's the one I was looking for... thank you!

You are welcome!

Ace, are you still monitoring this thread? I got myself in a little bit
of trouble.... :-(

What did you do?

I tried to make my network faster :-0
You found it (the new post). :-)