Prev: 37 Hosting Web www.ivys.es
Next: Locating Domain Controller
From: Dave Onex on 13 Nov 2009 21:20

"Ace Fekay [MCT]" <aceman(a)mvps.RemoveThisPart.org> wrote in message
news:e1Q%236iBZKHA.5108(a)TK2MSFTNGP06.phx.gbl...
> "Dave Onex" <dave(a)microsoft.com> wrote in message
> news:%23dFH0A%23YKHA.4148(a)TK2MSFTNGP04.phx.gbl...
>> 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


From: Ace Fekay [MCT] on 14 Nov 2009 12:57
"Dave Onex" <dave(a)microsoft.com> wrote in message
news:ea4X7DNZKHA.1592(a)TK2MSFTNGP06.phx.gbl...
>
> "Ace Fekay [MCT]" <aceman(a)mvps.RemoveThisPart.org> wrote in message
> news:e1Q%236iBZKHA.5108(a)TK2MSFTNGP06.phx.gbl...
>> "Dave Onex" <dave(a)microsoft.com> wrote in message
>> news:%23dFH0A%23YKHA.4148(a)TK2MSFTNGP04.phx.gbl...
>>> 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


From: Dave Onex on 14 Nov 2009 14:39

"Ace Fekay [MCT]" <aceman(a)mvps.RemoveThisPart.org> wrote in message
news:%23%23nFpPVZKHA.1640(a)TK2MSFTNGP06.phx.gbl...
> "Dave Onex" <dave(a)microsoft.com> wrote in message
> news:ea4X7DNZKHA.1592(a)TK2MSFTNGP06.phx.gbl...
>>
>> "Ace Fekay [MCT]" <aceman(a)mvps.RemoveThisPart.org> wrote in message
>> news:e1Q%236iBZKHA.5108(a)TK2MSFTNGP06.phx.gbl...
>>> "Dave Onex" <dave(a)microsoft.com> wrote in message
>>> news:%23dFH0A%23YKHA.4148(a)TK2MSFTNGP04.phx.gbl...
>>>> 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



From: Ace Fekay [MCT] on 14 Nov 2009 16:07
"Dave Onex" <dave(a)microsoft.com> wrote in message
news:%23fkA3IWZKHA.5608(a)TK2MSFTNGP05.phx.gbl...
>
> "Ace Fekay [MCT]" <aceman(a)mvps.RemoveThisPart.org> wrote in message
> news:%23%23nFpPVZKHA.1640(a)TK2MSFTNGP06.phx.gbl...
>> "Dave Onex" <dave(a)microsoft.com> wrote in message
>> news:ea4X7DNZKHA.1592(a)TK2MSFTNGP06.phx.gbl...
>>>
>>> "Ace Fekay [MCT]" <aceman(a)mvps.RemoveThisPart.org> wrote in message
>>> news:e1Q%236iBZKHA.5108(a)TK2MSFTNGP06.phx.gbl...
>>>> "Dave Onex" <dave(a)microsoft.com> wrote in message
>>>> news:%23dFH0A%23YKHA.4148(a)TK2MSFTNGP04.phx.gbl...
>>>>> 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


From: Dave Onex on 14 Nov 2009 18:51

"Ace Fekay [MCT]" <aceman(a)mvps.RemoveThisPart.org> wrote in message
news:uFVID6WZKHA.196(a)TK2MSFTNGP05.phx.gbl...
> "Dave Onex" <dave(a)microsoft.com> wrote in message
> news:%23fkA3IWZKHA.5608(a)TK2MSFTNGP05.phx.gbl...
>>
>> "Ace Fekay [MCT]" <aceman(a)mvps.RemoveThisPart.org> wrote in message
>> news:%23%23nFpPVZKHA.1640(a)TK2MSFTNGP06.phx.gbl...
>>> "Dave Onex" <dave(a)microsoft.com> wrote in message
>>> news:ea4X7DNZKHA.1592(a)TK2MSFTNGP06.phx.gbl...
>>>>
>>>> "Ace Fekay [MCT]" <aceman(a)mvps.RemoveThisPart.org> wrote in message
>>>> news:e1Q%236iBZKHA.5108(a)TK2MSFTNGP06.phx.gbl...
>>>>> "Dave Onex" <dave(a)microsoft.com> wrote in message
>>>>> news:%23dFH0A%23YKHA.4148(a)TK2MSFTNGP04.phx.gbl...
>>>>>> 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


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: 37 Hosting Web www.ivys.es
Next: Locating Domain Controller