Machines not being registered in DNS anymore
I noticed new machines are not being registered into DNS.
There are all Windows XP and Server 2003 machines that have the option
checked "Register this connection's address in DNS" checked.
I can see the machines in "DHCP Adress Leases" on the DHCP server, but
these machines are not listed in any DNS servers.
The DHCP server also has the options below selected:
Enable DNS dynamic updates ...
Always dynamically update DNS A and PTR records
Discard A and PTR records when lease is deleted.
Despite all this, the machines are not listed in any DNS servers.
What could be the issue?
RE: Machines not being registered in DNS anymore
Very strange. Are there any errors in the dns event log??
James.
--
James Yeomans, BSc, MCSE
Ask me directly at: http://www.justaskjames.co.uk
"mygposts@gmail.com" wrote:
> I noticed new machines are not being registered into DNS.
> There are all Windows XP and Server 2003 machines that have the option
> checked "Register this connection's address in DNS" checked.
> I can see the machines in "DHCP Adress Leases" on the DHCP server, but
> these machines are not listed in any DNS servers.
> The DHCP server also has the options below selected:
>
> Enable DNS dynamic updates ...
> Always dynamically update DNS A and PTR records
> Discard A and PTR records when lease is deleted.
>
> Despite all this, the machines are not listed in any DNS servers.
>
> What could be the issue?
>
Re: Machines not being registered in DNS anymore
Can you manually force a machine to register?
"ipconfig /registerdns"
Re: Machines not being registered in DNS anymore
In news:f8345b52-d470-4936-90da-826a318ab8f7@w39g2000prb.googlegroups.com,
mygposts@gmail.com <mygposts@gmail.com> requesting assistance, typed the
following:
> I noticed new machines are not being registered into DNS.
> There are all Windows XP and Server 2003 machines that have the option
> checked "Register this connection's address in DNS" checked.
> I can see the machines in "DHCP Adress Leases" on the DHCP server, but
> these machines are not listed in any DNS servers.
> The DHCP server also has the options below selected:
>
> Enable DNS dynamic updates ...
> Always dynamically update DNS A and PTR records
> Discard A and PTR records when lease is deleted.
>
> Despite all this, the machines are not listed in any DNS servers.
>
> What could be the issue?
Things to consider for DNS registration to work
1. Only use the internal DNS server. Never use any external, router or ISP
DNS server in any machine's IP config properties in an AD infrastructure.
Only use an external or ISP's as a forwarder in DNS. Otherwise, expect
problems.
2. The Primary DNS SUffix on the machine MUST match the zone name in DNS.
3. Allow updates must be set in the zone properties.
4. Multihomed DCs, especially if DNS is on them, can cause *unpredictable*
issues. This can possibly be one of them.
5. If the AD domain name is a single label name, such as "DOMAIN" instead of
the "domain.com" or "domain.internal," etc, format, it will not register.
As asked by James, any errors in the event viewer? Also, can you post an
unedited ipconfig /all of a sample workstation please as well as the zone
name they should be registering into?
Thanks,
Ace
This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.
Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCT
Microsoft Certified Trainer
For urgent issues, you may want to contact Microsoft PSS directly.
Please check http://support.microsoft.com for regional support phone
numbers.
Re: Machines not being registered in DNS anymore
On Nov 2, 9:21 pm, "Ace Fekay [Microsoft Certified Trainer]"
<firstnamelastn...@hotmail.com> wrote:
> Innews:f8345b52-d470-4936-90da-826a318ab8f7@w39g2000prb.googlegroups.com,
> mygpo...@gmail.com <mygpo...@gmail.com> requesting assistance, typed the
> following:
>
> > I noticed new machines are not being registered intoDNS.
> > There are all Windows XP and Server 2003 machines that have the option
> > checked "Register this connection's address inDNS" checked.
> > I can see the machines in "DHCPAdress Leases" on theDHCPserver, but
> > these machines are not listed in anyDNSservers.
> > TheDHCPserver also has the options below selected:
>
> > EnableDNSdynamic updates ...
> > Always dynamically updateDNSA and PTR records
> > Discard A and PTR records when lease is deleted.
>
> > Despite all this, the machines are not listed in anyDNSservers.
>
> > What could be the issue?
>
> Things to consider forDNSregistration to work
> 4.MultihomedDCs, especially ifDNSis on them, can cause *unpredictable*
> issues. This can possibly be one of them.
The only errors in DNS are errors that appear when the DNS servers are
rebooted. Nothing related to registering DNS.
There are multihomed DCs with DNS and they point to themselves for
DNS. They are multihomed to keep the traffic used for network backups
off of the regular prodution network.
What can be done?
Re: Machines not being registered in DNS anymore
In news:2a68043c-af28-4c6d-b005-46fbf1d599c8@c36g2000prc.googlegroups.com,
mygposts@gmail.com <mygposts@gmail.com> requesting assistance, typed the
following:
> The only errors in DNS are errors that appear when the DNS servers are
> rebooted. Nothing related to registering DNS.
> There are multihomed DCs with DNS and they point to themselves for
> DNS. They are multihomed to keep the traffic used for network backups
> off of the regular prodution network.
>
> What can be done?
Sorry, multihomed DCs are unpredictable. Too many factors involved.
Single-home them. The system state data is really not that large to backup
across the regular subnet at night compared to an SQL or especially an
Exchange backup. But of course, this is up to you or your team to discuss
and put in a change management to alter your design.
If you would like to configure the DCs to not register the unwanted
(backups) connection into DNS, especially the SRV records (which do not stop
even if unchecking 'do not register this connection checkbox in NIC
properties), see this link and search the string "Multi-homed DCs, What a
Mess... It cuts into your drinking time" for instructions on how to control
DNS registration with multihomed DCs.
http://www.fekay.com/SupportBlogs.htm
I hope that helps.
Ace
Re: Machines not being registered in DNS anymore
On Nov 5, 8:06 pm, "Ace Fekay [Microsoft Certified Trainer]"
<firstnamelastn...@hotmail.com> wrote:
> Innews:2a68043c-af28-4c6d-b005-46fbf1d599c8@c36g2000prc.googlegroups.com,
> mygpo...@gmail.com <mygpo...@gmail.com> requesting assistance, typed the
> following:
>
> > The only errors in DNS are errors that appear when the DNS servers are
> > rebooted. Nothing related to registering DNS.
> > There are multihomed DCs with DNS and they point to themselves for
> > DNS. They are multihomed to keep the traffic used for network backups
> > off of the regular prodution network.
>
> > What can be done?
>
> Sorry, multihomed DCs are unpredictable. Too many factors involved.
> Single-home them. The system state data is really not that large to backup
> across the regular subnet at night compared to an SQL or especially an
> Exchange backup. But of course, this is up to you or your team to discuss
> and put in a change management to alter your design.
>
> If you would like to configure the DCs to not register the unwanted
> (backups) connection into DNS, especially the SRV records (which do not stop
> even if unchecking 'do not register this connection checkbox in NIC
> properties), see this link and search the string "Multi-homed DCs, What a
> Mess... It cuts into your drinking time" for instructions on how to control
> DNS registration with multihomed DCs.http://www.fekay.com/SupportBlogs.htm
>
> I hope that helps.
>
> Ace
It is not just system state data being backed up. One of the DCs is
also a file server with tons of data that takes too long to backup at
10/100 speeds. The second nics were added so the servers can also
connect to a small gigabit switch used for backups. There are not
enough ports on the switch to use the same switch for the production
network.
It looks like the only solution (since purchasing all-new gigabit
switches for everyone is not going to happen anytime soon) is to look
at that DNS registration log link.
Re: Machines not being registered in DNS anymore
On Nov 6, 4:16 pm, mygpo...@gmail.com wrote:
> On Nov 5, 8:06 pm, "Ace Fekay [Microsoft Certified Trainer]"
>
>
>
>
>
> <firstnamelastn...@hotmail.com> wrote:
> > Innews:2a68043c-af28-4c6d-b005-46fbf1d599c8@c36g2000prc.googlegroups.com,
> > mygpo...@gmail.com <mygpo...@gmail.com> requesting assistance, typed the
> > following:
>
> > > The only errors in DNS are errors that appear when the DNS servers are
> > > rebooted. Nothing related to registering DNS.
> > > There are multihomed DCs with DNS and they point to themselves for
> > > DNS. They are multihomed to keep the traffic used for network backups
> > > off of the regular prodution network.
>
> > > What can be done?
>
> > Sorry, multihomed DCs are unpredictable. Too many factors involved.
> > Single-home them. The system state data is really not that large to backup
> > across the regular subnet at night compared to an SQL or especially an
> > Exchange backup. But of course, this is up to you or your team to discuss
> > and put in a change management to alter your design.
>
> > If you would like to configure the DCs to not register the unwanted
> > (backups) connection into DNS, especially the SRV records (which do notstop
> > even if unchecking 'do not register this connection checkbox in NIC
> > properties), see this link and search the string "Multi-homed DCs, Whata
> > Mess... It cuts into your drinking time" for instructions on how to control
> > DNS registration with multihomed DCs.http://www.fekay.com/SupportBlogs.htm
>
> > I hope that helps.
>
> > Ace
>
> It is not just system state data being backed up. One of the DCs is
> also a file server with tons of data that takes too long to backup at
> 10/100 speeds. The second nics were added so the servers can also
> connect to a small gigabit switch used for backups. There are not
> enough ports on the switch to use the same switch for the production
> network.
>
> It looks like the only solution (since purchasing all-new gigabit
> switches for everyone is not going to happen anytime soon) is to look
> at that DNS registration log link.- Hide quoted text -
>
> - Show quoted text -
Also, the two nics are on different subnets. I read somewhere that
using two nics on a dc is only a problem when both nics are on the
same subnet.
Re: Machines not being registered in DNS anymore
In news:979f1b0d-d772-4db6-b149-36cf2d8cb1dd@a29g2000pra.googlegroups.com,
mygposts@gmail.com <mygposts@gmail.com> requesting assistance, typed the
following:
> Also, the two nics are on different subnets. I read somewhere that
> using two nics on a dc is only a problem when both nics are on the
> same subnet.
Actually if on the same subnet, you can team them. But if on different
subnets, and one is NOT reachable by clients, yet the registration exists in
DNS and will more than likely be given to a client in a query response, then
YES it WILL be problematic.
I explained what the problems that can occur in that link. I'll post it here
for your convenience. It talks about using the DC as a NAT device because
that is the common reason many multihome a DC, but the same thing occurs due
to the mutliple NICs and different subnets they are on. Please read throught
it. I will be glad to respond to any specific questions you may have.
- Ace
=======================
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
With all due respect, multi-homed DCs are not recommended because of the
associated issues that WILL occur with AD. If using a DC as an internet
access gateway, I recommend purchasing an inexpensive Linksys, DLink, etc,
Cable/DSL router to perform NAT for you, take out the extra NIC off the DC,
but still let the DC handle DHCP (and not the router).
If used for some other reason, I would highly recommend removing the NICs
and apps and use a non-DC for the task.
Little background on AD and DNS:
First, just to get this out of the way, if you have your ISP's DNS addresses
in your IP configuration (DCs and clients), they need to be REMOVED. If the
ISP's DNS is in there, this will cause additional problems. I usually see
errors (GPOs not working, can't find the domain, RPC issues, etc), when the
ISP's DNS servers are listed on a client, DCs and/or member servers, or with
multihomed DCs. If you have an ISP's (or some other outside DNS server or
even using your router as a DNS server) DNS addresses in your IP
configuration (all DCs, member servers and clients), they need to be REMOVED
and ONLY use the internal DNS server(s). This can be very problematic.
More background: AD uses DNS. DNS stores AD's resource and service locations
in the form of SRV records, hence how everything that is part of the domain
will find resources in the domain. If the ISP's DNS is configured in the any
of the internal AD member machines' IP properties, (including all client
machines and DCs), the machines will be asking the ISP's DNS 'where is the
domain controller for my domain?", whenever it needs to perform a function,
(such as a logon request, replication request, querying and applying GPOs,
etc). Unfortunately, the ISP's DNS does not have that info and they reply
with an "I dunno know", and things just fail. Unfortunately, the ISP's (or
your router as a DNS server) DNS
doesn't have information or records about your internal private AD domain,
and they shouldn't have that sort of information.
Also, AD registers certain records in DNS in the form of SRV records that
signify AD's resource and service locations. When there are multiple NICs,
each NIC registers. IF a client, or another DC queries DNS for this DC, it
may get the wrong record. One factor controlling this is Round Robin. If a
DC or client on another subnet that the DC is not configured on queries for
it, Round Robin will kick in offering one or the other.
If the wrong one gets offered, it may not have a route to it. On the other
hand, Subnetmask Priortization will ensure a querying client will get an IP
that corresponds to the subnet it's on, which will work. To insure
everything works, stick with one NIC.
Since this DC is multi-homed, it requires additional configuration to
prevent the public interface addresses from being registered in DNS. This
creates a problem for internal clients locating AD to authenticate and find
other services and resources such as the Global Catalog, file sharing and
the SYSVOL DFS share and can cause GPO errors with Userenv 1000 events to be
logged, authenticating to shares and printers, logging on takes forever,
among numerous other issues.
But if you like, there are some registry changes to eliminate the
registration of the external NIC or simply use the internal networking
routing to allow access. Here's the whole list of manual steps to follow.
Another problem is the DC now becomes part of two Sites. This is another
issue that can be problematic.
But believe me, it's much easier to just get a separate NAT device or
multihome a non-DC then having to alter the DC. If the both NICs are
internal, I would suggest to pick a subnet, team the NICs and allow your
internal routers handle the traffic between subnets - Good luck!
1. Insure that all the NICS only point to your internal DNS server(s) only
and none others, such as your ISP's DNS servers' IP addresses.
2. In Network & Dialup properties, Advanced Menu item, Advanced Settings,
move the internal NIC (the network that AD is on) to the top of the binding
order (top of the list).
3. Disable the ability for the outer NIC to register. The procedure, as
mentioned, involves identifying the outer NIC's GUID number. This link will
show you how:
246804 - How to Enable-Disable Windows 2000 Dynamic DNS Registrations (per
NIC too):
http://support.microsoft.com/?id=246804
4. Disable NetBIOS on the outside NIC. That is performed by choosing to
disable NetBIOS in IP Properties, Advanced, and you will find that under the
"WINS" tab. You may want to look at step #3 in the article to show you how
to disable NetBIOS on the RRAS interfaces if this is a RRAS server.
296379 - How to Disable NetBIOS on an Incoming Remote Access Interface
[Registry Entry]:
http://support.microsoft.com/?id=296379
Note: A standard Windows service, called the "Browser service", provides the
list of machines, workgroup and domain names that you see in "My
Network Places" (or the legacy term "Network Neighborhood"). The Browser
service relies on the NetBIOS service. One major requirement of NetBIOS
service is a machine can only have one name to one IP address. It's sort of
a fingerprint. You can't have two brothers named Darrell. A multihomed
machine will cause duplicate name errors on itself because Windows sees
itself with the same name in the Browse List (My Network Places), but with
different IPs. You can only have one, hence the error generated.
5. Disable the "File and Print Service" and disable the "MS Client Service"
on the outer NIC. That is done in NIC properties by unchecking the
respective service under the general properties page. If you need these
services on the outside NIC (which is unlikely), which allow other machines
to connect to your machine for accessing resource on your machine (shared
folders, printers, etc.), then you will probably need to keep them enabled.
6. Uncheck "Register this connection" under IP properties, Advanced
settings, "DNS" tab.
7. Delete the outer NIC IP address, disable Netlogon registration, and
manually create the required records
a. In DNS under the zone name, (your DNS domain name), delete the outer
NIC's IP references for the "LdapIpAddress". If this is a GC, you will need
to delete the GC IP record as well (the "GcIpAddress"). To do that, in the
DNS console, under the zone name, you will see the _msdcs folder.
Under that, you will see the _gc folder. To the right, you will see the IP
address referencing the GC address. That is called the GcIpAddress.
Delete the IP addresses referencing the outer NIC.
i. To stop these two records from registering that information,
use the steps provided in the links below:
Private Network Interfaces on a Domain Controller Are Registered in DNS
http://support.microsoft.com/?id=295328
ii. The one section of the article that disables these records is
done with this registry entry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
(Create this Multi-String Value under it):
Registry value: DnsAvoidRegisterRecords
Data type: REG_MULTI_SZ
Values: LdapIpAddress
GcIpAddress
iii. Here is more information on these and other Netlogon Service records:
Restrict the DNS SRV resource records updated by the Netlogon service
[including GC]:
http://www.microsoft.com/technet/tre...o_rr_in_ad.asp
b. Then you will need to manually create these two records in DNS with
the IP addresses that you need for the DC. To create the LdapIpAddress,
create a new host under the domain, but leave the "hostname" field blank,
and provide the internal IP of the DC, which results in a record that looks
like:
(same as parent) A 192.168.5.200 (192.168.5.200 is used for illustrative
purposes)
i. You need to also manually create the GcIpAddress as well, if
this is a GC. That would be under the _msdcs._gc SRV record under the zone.
It is created in the same fashion as the LdapIpAddress mentioned above.
8. In the DNS console, right click the server name, choose properties, then
under the "Interfaces" tab, force it only to listen to the internal NIC's IP
address, and not the IP address of the outer NIC.
9. Since this is also a DNS server, the IPs from all NICs will register,
even if you tell it not to in the NIC properties. See this to show you how
to stop that behavior (this procedure is for Windows 2000, but will also
work for Windows 2003):
275554 - The Host's A Record Is Registered in DNS After You Choose Not to
Register the Connection's Address:
http://support.microsoft.com/?id=275554
10. If you haven't done so, configure a forwarder. You can use 4.2.2.2 if
not sure which DNS to forward to until you've got the DNS address of your
ISP.
How to set a forwarder? Good question. Depending on your operating
system,choose one of the following articles:
300202 - HOW TO: Configure DNS for Internet Access in Windows 2000
http://support.microsoft.com/?id=300202&FR=1
323380 - HOW TO: Configure DNS for Internet Access in Windows Server 2003
(How to configure a forwarder):
http://support.microsoft.com/d/id?=323380
Active Directory communication fails on multihomed domain controllers
http://support.microsoft.com/kb/272294
<==*** Some additional reading ***==>
More links to read up and understand what is going on:
292822 - Name Resolution and Connectivity Issues on Windows 2000 Domain
Controller with Routing and Remote Access and DNS Insta {DNS and RRAS and
unwanted IPs registering]:
http://support.microsoft.com/?id=292822
Active Directory communication fails on multihomed domain controllers
http://support.microsoft.com/kb/272294
246804 - How to enable or disable DNS updates in Windows 2000 and in Windows
Server 2003
http://support.microsoft.com/?id=246804
295328 - Private Network Interfaces on a Domain Controller Are Registered in
DNS [also shows DnsAvoidRegisterRecords LdapIpAddress to avoid reg
sameasparent private IP]: http://support.microsoft.com/?id=295328
306602 - How to Optimize the Location of a DC or GC That Resides Outside of
a Client's Site [Includes info LdapIpAddress and GcIpAddress
information and the SRV mnemonic values]:
http://support.microsoft.com/?id=306602
825036 - Best practices for DNS client settings in Windows 2000 Server and
in Windows Server 2003 (including how-to configure a forwarder):
http://support.microsoft.com/default...b;en-us;825036
291382 - Frequently asked questions about Windows 2000 DNS and Windows
Server 2003 DNS
http://support.microsoft.com/?id=291382
296379 - How to Disable NetBIOS on an Incoming Remote Access Interface
[Registry Entry]:
http://support.microsoft.com/?id=296379
Rid Pool Errors and other mutlhomed DC errors, and how to configure a
multihomed DC, Ace Fekay, 24
Feb 2006
http://www.ureader.com/message/3244572.aspx
_________________________
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
Ace
Re: Machines not being registered in DNS anymore
On Nov 7, 8:31 pm, "Ace Fekay [Microsoft Certified Trainer]"
<firstnamelastn...@hotmail.com> wrote:
> Innews:979f1b0d-d772-4db6-b149-36cf2d8cb1dd@a29g2000pra.googlegroups.com,
> mygpo...@gmail.com <mygpo...@gmail.com> requesting assistance, typed the
> following:
>
> > Also, the two nics are on different subnets. I read somewhere that
> > using two nics on a dc is only a problem when both nics are on the
> > same subnet.
>
> Actually if on the same subnet, you can team them. But if on different
> subnets, and one is NOT reachable by clients, yet the registration existsin
> DNS and will more than likely be given to a client in a query response, then
> YES it WILL be problematic.
>
> I explained what the problems that can occur in that link. I'll post it here
> for your convenience. It talks about using the DC as a NAT device because
> that is the common reason many multihome a DC, but the same thing occurs due
> to the mutliple NICs and different subnets they are on. Please read throught
> it. I will be glad to respond to any specific questions you may have.
>
> - Ace
>
So, you are saying that if the separate subnet created for the backups
is not used and both nics on these servers were put on the same IP,
there would be a way for the 5 servers to transfer the backup data
between each other over the limited port gigabit switch at gigabit
speeds and at the same time communicate properly with the all the rest
of the network connected to the big 10/100 switches and then there
would be no need for the registry hacks?
It doesn't seem like it would work properly if teamed with on nic
connected to a 10/100 switch and the other connected to a gigabit
switch at the same time.
Re: Machines not being registered in DNS anymore
In news:7ca4b92f-0757-4afa-8605-6ba5053a2986@k36g2000pri.googlegroups.com,
MyGposts <mygposts@gmail.com> requesting assistance, typed the following:
>
> So, you are saying that if the separate subnet created for the backups
> is not used and both nics on these servers were put on the same IP,
> there would be a way for the 5 servers to transfer the backup data
> between each other over the limited port gigabit switch at gigabit
> speeds and at the same time communicate properly with the all the rest
> of the network connected to the big 10/100 switches and then there
> would be no need for the registry hacks?
> It doesn't seem like it would work properly if teamed with on nic
> connected to a 10/100 switch and the other connected to a gigabit
> switch at the same time.
If teaming them, yes, on a gigabit switch. Teaming is one IP, so no need for
any addition configuration alterations. It may even be a good idea to let
the DCs be DCs and move that massive amount of data on to a non-DC with two
NICs. A multihomed non-DC is much easier to control DNS registration by a
simple box being unchecked, unlike a DC.
--
Ace