Vista clients became unresponsive after network move

As you can tell I am not an expert on administrating a network. I
learn as I face this kind of problems. You can't imagine how valuable
this discussion is. Thank you for bearing with me so far.

There were 2 reasons for why I did not bother setting DHCP on the DC:
1) The router has DHCP, and I thought 2 DHCPs cannot coexist
peacefully 2)I assigned static IPs to these computers way before the
DC, and I wasn't aware of that the DHCP on DC can assign those IPs.

I guess in order to utilize the DHCP on DC, I should: 1)Assign IPs to
the computers on DHCP 2)make computers get an IP from DHCP 3)
Deactivate the DHCP on the router.
Is that correct?

The clients have static IPs, ranging from 192.168.1.110 to
192.168.1.254
DC has static IP of 192.168.1.100
The IP range 192.168.1.101 - 109 is reserved for dynamic allocation by
the DHCP on the router for wireless devices.
As Bill suggested, it is probably not a good solution to assign IPs to
clients one by one, however I have never visited a client to change
its IP (so far).

What I don't understand is why should moving affect any of this? My DC
configuration was never changed. Our ISP is the same, they only gave
us different public IPs. To me, the only thing that needed to be
changed was the WAN IP setting on the router, and everything should
have worked as it had been working before. Clients still have the same
gateway, same DC, same DNS, same everything - why should they even be
aware of a physical move?

BTW, I really appreciate your time here as I am learning along the
way.

I meant to answer you but quoted Ace instead about the DHCP issue.
Feel free to interrupt! :)

Yes, but not in that order. You are correct, two DHCP servers with
identical or overlapping scopes will conflict. In your case, I would
simply disable DHCP on the router, then enable it on the DC. The
advantages are the DC's DHCP (Windows DHCP) interoperates with Dynamic
DNS, as well as uses AD Kerberos security, which the router does not
(nor can it) support. If the router does support Dynamic DNS, it's
optinos are limited with controlling how to register clients into DNS
for the foward lookup zone, and reverse lookup zone.

So you are saying that internally the IP subnet never changed. From
earlier posts, I assumed the internal range was changed.

Getting back to the TCPIP warning 4227, which I didn't realize was an
EventID# that you are receiving, and thought you were receiving it
elsewhere, it appears to indicate something else is going on with the
client side. Read the following, which doesn't provide specifics, but I
just want to confirm this is the error in the log you are getting.
http://www.eventid.net/display.asp?e...=tcpip&phase=1

Are you still receiving other errors on the client side or the DC?
Looking back in this thread, you indicated a DNSAPI 11166 error? You
didn't post the EventID#, which I believe Meinolf assumed it was 11166,
which we see off an on. That usually can be alleviated by creating a
reverse zone.

If you see any other errors that are still occuring, *please* post the
_EventID#_ and the Source name in the event message to better help so
we can look them up specifically by their numbers and messages.

The DNS API error was 11166, but I haven't seen that since 11/9. I
think the updates I made after your suggestions fixed that problem.

I checked the event log of the station named MOSCOW which I have to
restart this morning. I can see that it downloaded updates from
Microsoft and installed them at around 3AM this morning. It restarted
at around 3:25AM. There are no events logged until 7AM, which shows 2
events until my restart at 8AM: 7003 MS Office 12 Session Terminated,
and 4227 TCP/IP warning. I checked the link you provided but I could
not find an answer: The clients don't have torrent or other port-
consuming applications. Every TCP port is set to expire withing 600
seconds on the router, and I don't have more than 500 open ports at
any given time on the network, let alone having too much open ports
off peak hours.

DNS server events since the move:
10/17 - DNS server has started
11/5 - Error 4015 "The DNS server has encountered a critical error
from the Active Directory. Check that the Active Directory is
functioning properly. "
11/5 - Error 4004 "The DNS server was unable to complete directory
service enumeration of zone .."
11/5 - Error 4004 "The DNS server was unable to complete directory
service enumeration of zone _msdcs.Global.local."
11/5 - Error 4004 "The DNS server was unable to complete directory
service enumeration of zone Global.local. "
11/5 - DNS server has started (3 minutes after the errors)
11/6 - DNS server has started
11/13 - Warning 4521 "The DNS server encountered error 32 attempting
to load zone 1.168.192.in-addr.arpa from Active Directory. " (This
happened right after adding reverse lookup zone)"
11/14 - DNS Server has started (I restarted the DNS server to see if
any of the errors above are logged. No events logged since then)

Directory Server Events:
Until the move, events are consistent (700,701,102,103,1000,1394,1869)
10/17 - Information 1404 NTDS KCC "The local domain controller is now
the intersite topology generator and has assumed responsibility for
generating and maintaining intersite replication topologies for this
site." (on the day of the move)
After the move, events are consistent (700,701,102,103,1000,1394,1869)

I think this started before the move. Apparently there are some AD
issue, hence why the errors about the reverse zone popped up after
creating the zone. Also, why would it even give you a 1404 if it is the
only DC/GC you have?

Run the following, please:

dcdiag /v /fix > c:\dcdiag.txt
netdiag /v /fix > c:\netdiag.txt

Please post error or failures you see in the log.

Do you have AD Sites setup?
You said you only have one DC, correct?

Did you run those diagnostics I suggested?

I do not know why 1404 is logged. I don't even know what the intersite
topology generator is. That's the only entry for that event, and it
happened once the DC is booted up in the new office location.

I ran the dcdiag and netdiag. All the tests passed OK, some skipped
but no errors or failures.

After reading the whole thread, here are a couple other ideas to check out.

Verify there's not a speed or duplex mismatch between switch and hosts.
Since you changed the switch, this could be a possible issue.

Check and/or disable the autotuning settings, I have had similar issues with
both Vista and Server 2008 that were resolved by this.

This command will disable autotuning:
netsh interface tcp set global autotuninglevel=disabled

I ran the dcdiag and netdiag as you suggested. All the tests passed
OK, some skipped but no errors or failures. And yes, only one DC.

For now I suggested users to shut their computer down before leaving
for the day since this happens only a handful of computers. Maybe we
will hire a network admin to look into this. My knowledge is limited,
and I have spent more time than anticipated. I thank you all.

I will give it a try before I give up on this whole issue.

Per Paul's suggestion, I disabled autotuning on TCP for two clients
last night, and they were OK this morning. So far so good. I assume
this was the cause, and I will post back if disabling autotuning was
not the solution.

I am also glad to fix the small glitches on the server along the way
with the help from you guys :)

That may be a better course of action. A qualified individual should be
able to spot or figure out the problem hands on. If you need any more
assistance that we can help with through the Microsoft newsgroups,
please do post back.

Refresh my memory, please. What is DHCP Forwarding mode on the router?

From all of us suggesting help, we all said to eliminate the router for
DHCP. Unless I misunderstand what Forwarding mode does.

Is the router a wireles AP, too? If so, set it to 'corporate' mode (or
whatever it's called that will not make it NAT to wireless folks) so
the wireless folks are on the same subnet as the wired subnet.

What kind of router is it

Ace is exactly right. DHCP running on a windows server (it can be any
member server, it need not be the DC) can integrate itself with DNS
automagically. It really is a superior solution to router or other OS-based
DHCP (and DNS) services.

It really does make desktop IP addressing a lot easier to administer.

If you have hosts that need to stay on the same addresses you can do that by
setting up a DHCP reservation. That way they always get the same IP
address. This is very handy for dumb devices like printers. Plug their
network MAC address into a reservation and never worry about having to
configure the front panel again.

My only complaint about the DHCP service is there's not an easy way to
convert an existing lease to a reservation. Just makes for some added work
through retyping.

No worries. Be sure to follow up with the group when you get things working
better.

Good point. One of the very few nuances compared to all the goodies
Windows DHCP provides!!

Disabling Autotuning did not solve my issue.

I will play around with DHCP more. I already entered reservations in
DHCP, and put the DHCP on the router in "Forwarder" mode. I will start
setting the clients one by one so that they can obtain IP from the
DHCP. This works on wired clients, but now all the wireless clients
are gone e.g. they cannot even locate the SSID when the DHCP on the
router is either disabled or in Forwarder mode.

It seems that the router was the problem. I haven't seen this
particular problem since I replaced the router. I guess that's what I
should have tried first. It was a Linksys router with DD-WRT firmware.

Apparently DHCP forwarding mode is when you want to use a DHCP server
outside of the network. If there is a DHCP on the network, it is
advised to turn the router's DHCP off completely.

Now I put a new wired router with DHCP off (DNS and DHCP is handled by
the DC), and I connected the old router to the new router to serve as
a wireless access point (WAN/DHCP off). Both wired and wireless
clients can now get IPs from the server. Just the way I wanted it! IP
reservations seem to be working fine too.

Another annoyance I found during this process was that once a client
is told to use the DHCP instead of static IP, it will use an
unauthenticated network connection (Global.Local 2) until it's
restarted (or else its network-related capabilities will be limited).
Once it's restarted it detects the domain network Global.Local fine.

So DHCP forwarding is like an IP helper (on Cisco) or a DHCP Relay
Agent (under Windows).

Disabling DHCP on the router is what we've been saying, correct?

Where is global.local2 coming from? Is there another DHCP on the
network? Sorry, but I'm not sure what you mean by an unauthenticated
network connection.

Yes, you told me to disable the DHCP. In current setup it works like a
charm.
As for the "domain.local 2" problem, I don't know the cause but I
don't care much since it goes away after one restart. You can find
similar discussions all over the internet (one is at
Current setup is working fine so thank you very much again for all the
help.