[hoover11]

Thanks in advance for any suggestions or help. I have been Googling around with no luck on this -

On our internal network, clients are having intermittent IE Web 404 errors when connecting to our web server. I suspect there is something wrong with name resolution or DNS b/c when sometimes I try and ping the local DC, it times out on a few of the pings. No other servers are having this problem. Intermittently, when I do an NSLOOKUP on the webserver it gives an error that it can't find the server.

I never lose connection the server with a \\servername\c$ or pings from a WKS never time out. When I see these 404's, I sometimes get a time-out from my Remote Desktop Connection to the server.

Our Setup:
Win2k8 R2 servers
Win7 clients with IE8 & IE9
All connections in the same office on the same 1GB network
About 50 computers - network is not overloaded
The web server sits near idle - no other apps installed

Here is what I have done:
Deleted machine from DNS and recreated it
Moved machine to another NIC on the server
Disabled IPV6 (we only use IPV4)
All latest patches installed
Troubleshot with the web application team (who manages the web app)
I just added an LMHOSTS file with #PRE #DOM with the local DC (still same issue)

A few errors I am seeing on bootup in event log:
5719 Netlogon - This computer was not able to set up a secure session with a domain controller
1055 GroupPolicy - The processing of Group Policy failed. Windows could not resolve the computer name.
130 Time-Service - NtpClient was unable to set a domain peer to use as a time source because of failure in establishing a trust relationship between this computer and the '' domain in order to securely synchronize time.

Thanks again.

[RicklesP]

Try divorcing the web server from the domain, reset the web server computer account in AD, then rejoin the server to the domain. Sounds like your web server isn't really in the domain, based on the time & group policy issues.

When you have the server in a WORKGROUP, verify pings to assorted IP adds around your network to verify that server can see every connected subnet. Also check firewall settings to make sure IIS is available.

Report back.

[[JM]]

Sounds like you have a few things going here. Lets address one at a time.

404 Errors - A web server will return a 404 error when it is unable to locate a resource based on the URI. In other words, page not found. This is not a DNS error, nor a network connection error. You should check the URL and make sure that it is correct. If you are having intermittent 404 errors, that is strange because either the resource is there or its not. So I would go back and make sure that you are actually seeing a 404 error.

PING timeouts - So when you PING another host on the network, the only time DNS is involved is for resolving the name you are pinging. after that, any issues you see, like dropped pings, means that you have a potential network issue. Try pinging the target from a different computer and/or from a different subnet. This issue can be due to a variety of issues, bad NIC on the source/target computer, bad cables, bad switch port, etc... You need to scope this problem, i.e. find out how many computers experience this issue.

NSLOOKUP- error that it cannot find the server. This could be that you are missing the host record in the zone, or that the information you typed into NSLOOKUP was not fully qualified. make sure that when you use nslookup, type the FQDN, i.e., hostname.domain.tld.

Remote Desktop issues - again, go back and validate if you are seeing a 404 or a different error. the 404 doesnt seem correct to me.

[hoover11]

Thanks so much for the replies. No luck yet. Here is an update.

Removed the machine from domain, put in workgroup, and rejoined. Pretty much the same errors:

129 - Time-Service - NtpClient was unable to set a domain peer to use as a time source because of discovery error.
1053 - Group Policy - The processing of Group Policy failed. Windows could not resolve the user name.
5719 - netlogon

IIS is available. One ping to the local DC failed when it was in a workgroup. It is almost like the ping initially fails then finds the server just fine - (from other ping tests I have been doing). Like there is a hesitation when it is not in cache.

Could it be something with the DNS server? Nothing jumped out on the DNS server logs. Maybe my DNS settings on the Web Server (which are correct)? Should I use a different primary DC (on another subnet)? I don't want to rebuild this server just yet.

No other servers (which are same make / model / OS and were built at the sametime) are having these problems. I should have mentioned that I used another port on the switch, changed out the NIC cable, and move to another NIC on the server.

Thanks again.

[hoover11]

One more thing. Every once in a while when I do an NSLookup on the server I get dc.domain.biz can't find webserver: Non-existant domain.

This points to not having at PTR record. I have verified I do have a PTR record for this webserver.

[Blood]

Could it be a firewall configuration issue on the clients? Have you tried disabling all security on the clients and seeing if the issue persists?

[wullieb1]

Where is your webserver located???

[lloco69]

Did you check this ?

This problem may occur if you have all of the following:

• Using a DHCP reply to forward DHCP requests (e.g. using VLANs and an IP helper on the router to forward DHCP requests)
• Windows 7 clients
• Windows Firewall Public Profile turned on (default configuration - all profiles)
• DhcpConnForceBroadcastFlag = 0 (Default for Windows 7)

The problem occurs when your client has to access the DHCP server via a DHCP relay, such as a router or switch and the DhcpConnForceBroadcastFlag registry key is still set to the default(0). In this situation, the client sends out a broadcasts requesting an IP address, the DHCP relay forwards the request to the DHCP server, the DHCP server sends the reply(ACK reply) to the relay and the DHCP relay sends a unicast reply to the client. If the Public profile is turned on in the Windows Firewall (on by default) then the ACK reply is dropped by the windows 7 clinet firewall . Using Netmon you can see the correct traffic on the wire, but the client is not accepting the ACK packet.