Just added my first WIndows 7 Pro machine to the domain. Everything is working fairly well with the exception of one thing. I have a windows 2003 file/ IIS server that the Windows 7 machine can't ping, access its file shares, or any of its services (i.e. IIS). This is the only windows 2003 server I have in the domain. The windows 2003 server can ping and access file shares on Windows 7, The windows 7 workstation can access any of the other workstations or windows 2000 and windows 2008 servers. If I try to ping the Windows 2003 server, the first response every 15 minutes or so will come back < 1 ms, but the rest will timeout. If I try to connect to file share I get cannot connect. Any requests for web, etc, just time out. There is no firewall on any of the machines, I have set the NTLM setting to use LM & NTLM - use .v2 if authorized on both machines, no dice. Help!

This might be more of a Windows 2003 server issue, but here's what I've discovered. Running Network Monitor, I see that the server responds back with two ARP:Response: ARP:Response, 10.10.0.3 at 00-13-21-1F-70-77 ARP:Response, 10.10.0.3 at C4-7D-4F-60-5E-C0 Windows 7 is storing the second one. When I look at another computer's ARP table (arp -a), I see that the first one is what is stored. I deleted the offending entry on the windows 7 machine (arp -d 10.10.0.3) and added the other one using netsh: netsh interface ipv4 add neighbors "Local Area Connection" 10.10.0.3 00-13-21-1F-70-77 Pings and everything else started working as per normal. Now to troubleshoot where that second response is coming from *sigh*.

The wrong MAC corresponds to my Cisco ASA 5505 router. The Source comes from the windows 2003 server though. 4 8:12:57 AM 6/9/2011 1.6781814 TVCAN TV50 ARP ARP:Response, 10.10.0.3 at 00-13-21-1F-70-77 5 8:12:57 AM 6/9/2011 1.6781814 TVCAN TV50 ARP ARP:Response, 10.10.0.3 at C4-7D-4F-60-5E-C0

Running network monitor on other workstations seems to indicate that this problem is going on with every machine trying to access that server. However their ARP table isn't storing the wrong MAC address. The problem seems to actually be on the ASA 5505 - turning off PROXY ARP seems to have resolved the issue.