Who might have an idea or 2 on this one? ... Ping ...

[TR]

FACTS - I have a network where I have an NT PDC with a
static IP address of 192.168.0.254. On this same
network, I have a windows2000 SBS with a static IP
address of 192.168.0.100. I have set up the Win2K server
with active directory and DNS and configured it in mixed
mode. The mixed mode names are different. For example,
the DNS domain name is mycompany.com, but the NetBIOS
name is Dell2000. Dell200 is what shows in Network
Places.

PROBLEMS -
1) When I join a computer to the Dell2000 domain, and
then log that user on, it takes about 10 to 15 minutes
for the user to see their desktop ... what could be a
reason(s) for it taking so long to log in? ... looking
for ideas ...
2) When I ping any user computer name on the network, I
am returned the IP# 69.44.57.202. Even if I give the
user a static IP number, I am still returned the
IP#69.44.57.202. The only way I can get that users new
static IP# is if I put the computer name and static ip
address in each PC's HOSTS file. Can you offer me some
suggestions on why I am getting 69.44.57.202?? ...
WINS? ... a router configuration? ...

Thanks

 

[Mike Aubert]

Slow logon is normally the result of incorrectly configured DNS.

In the Server's TCP/IP properties, do you have the server pointing at itself
for DNS? If the Server is configured to use itself for DNS name resolution,
open up the DNS console and expand the forward lookup zone for your domain.
Do you see folders called _msdcs, _sites, _tcp, and _udp?

In the client's TCP/IP properties, do you have the clients configured to use
Dell2000 as their DNS server?

------------------------------------------------------------------
Mike Aubert
MCSE, MCSD, MCDBA
(e-mail address removed)

Note the "news2" in my email address is temporary and may be changed in the
future, remove it to email me at my Permanente address.
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Marina Roos [SBS-MVP]]

Are you the same that posted something about this earlier?
If that NT already existed, you can't just add a SBS server. SBS has to be
the king of the forest so you will have to reinstall the NT4 to get this all
working fine.

 

[TR]

When I look at the Dell2000 DNS forward lookup zone, I do
see the folders called _msdcs, _sites, _tcp, and _udp.
In the mycompany.com forward lookup zone, I not only have
these folders, but am listing the servers IP address and
server name as a host record, the server IP address as a
Host (same as parent folder) and the
server_name.mycompany.com as a Name server (and of course
an SOA record). Does this mean the server is pointing at
itself for DNS? It does have the ISP DNS servers listed
for TCP/IP properties.

I am not on site right now, but I believe the
workstations are using the ISP DNS servers (in their
TCP/IP properties ... maybe some are set up this way and
others not ... make a difference??) When I look at the
TCP/IP properties for the NT PDC server, it lists itself
for a DNS server IP#.

Does this info help you to respond with further info or
advice?

If I delete the _msdcs, _sites, _tcp, and _udp folders in
my DSN forward lookup zone, might I be correcting my
problems, including why I am getting the IP# 69.44.57.202
returned? I am not using this server for anything other
than an internal network application server. I am not
hosting a web site, exchange server etc. I use an
external ISP for interenet access and for the company web
site.

Thanks.

 

[Mike Aubert]

That's why...your DNS configuration is not correct...

Start by configuring your DNS server to forward name resolution requests to
your ISP (this can be done in the DNS console under the server's property
pages). Also ensure that your DNS server does *not* have a "root" forward
lookup zone (the zone will be labeled as a single period ( . ) )

Next, you need to configure the Server's TCP/IP properties to point at
itself as the DNS server (not your ISP). This will send name resolution
requests to your DNS server. If your DNS server can not resolve the name
(i.e. the FQDN is not in mycompany.com) the request will be forwarded to
your ISP's DNS servers. You will need to run ipconfig /registerdns at a
command prompt and then restart the netlogon service. This will reregister
the DC's DNS records.

As for your clients.I'm assuming they are members of mycompany.com. If so,
go ahead and configure them to use Dell2000 as their DNS server (not your
ISP). Once the DNS server is changed run ipconfig /registerdns on each
client to reregister its DNS record. A host record should appear for each
client computer - if the records do not show up, the zones dynamic update
settings are not setup correctly.

Now, if your clients are not members of mycompany.com but rather the NT 4.0
domain let me know and wait on implementing the above. Is the NT 4.0 server
just running DNS or does it also have zone data?

Speaking of the NT 4.0 domain. Marina brings up a good point. Are you
planning on running two separate and independent systems?

------------------------------------------------------------------
Mike Aubert
MCSE, MCSD, MCDBA
(e-mail address removed)

Note the "news2" in my email address is temporary and may be changed in the
future, remove it to email me at my Permanente address.
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[TR]

Yes, I am the same that had the earlier post. The NT
server is to be taken off line. Right now, it hosts the
primary business application (a DOS legacy application
using Pervasive). Thought I would leave it alone. The
new SQL based application will run on the SBS. Sounds
like I might need to transfer the legacy app to the new
server and get the NT off the network?? Just didn't want
to have to go through this if I didn't have to. But all
employees will need to log into the SBS domain to access
the new application. When they do this, I wasn't sure
whether they would also be able to access the legacy
until the transition is complete.

 

[TR]

This is very helpful ... I have reconfigured the server
DNS as you have advised. I will now work on the
clients. Question(s), ... 1) should I be deleting the
folders called _msdcs, _sites, _tcp, and _udp? 2)When I
reconfigure this, do you expect when I ping a computer,
it will no longer return the IP# 69.44.57.202?

And, BTY, my DNS server does not have a "root" forward.
I did not realize that it was not right to have each PC
configured with the ISP DNS servers. I also did not
realize I should have them all point through the DNS
server forwarder. Assume this is the recommended
configuration for internal and external name
resolution ... yes? This might be "starting" to come
together for me.

 

[TR]

Here is what I have done on the client. I have changed
the IP properties to point to the Dell2000 DNS server.
Then I ran the ipconfig /registerdns and
stopped/restarted the logon service. What/when should
the client show up as an "a" record in the server DNS
file?

Thanks

 

[Marina Roos [SBS-MVP]]

Have you set options 003, 006 and 015 in DHCP-server, Scope options? 015
should point to your AD-domainname and that will be pushed to the clients.
In DNS-server you should set 'allow dynamic update' to yes on the properties
of the Forward and Reverse Lookup Zones.

 

[Mike Aubert]

You do not need to delete those subdomains unless you are still experiencing
problems - but they will need to be reregistered. When a Windows 2000 domain
controller starts or when you restart the netlogon service, the server will
recreate these subdomains and add the necessary records for itself.

Yes, this may also solve the 69.44.57.202 IP address issue.

------------------------------------------------------------------
Mike Aubert
MCSE, MCSD, MCDBA
(e-mail address removed)

Note the "news2" in my email address is temporary and may be changed in the
future, remove it to email me at my Permanente address.
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Rob Elder, MVP-Networking]

Make sure you have enabled your zone for dynamic updates.

The _TCP, _UDP, etc are not subdomains but SVR records. They are necessary
for your AD to work.