I could not get rid of the entry in DNS even after deleting every instance of it from the copper.local domain, setting the interface to not register itself in DNS, making sure it wasn't set to respond to DNS requests, flushing the DNS cacehe and it would always come back.
Traffic was originating from the wrong IP address (192.168.1.50) instead of 192.168.250.3.
I'm going to throw Wireshark on the server(s) tomorrow when I get the chance for some more visibility.
I'll also turn on DNS debug logging to collect as much information as possible. re: e DNS, I meant did you try disabling it on the Windows 2008R2 box?
I would take any errors at this point just from a troubleshooting standpoint.
Also, I need to see why a secondary NIC IP that I deleted from the copper.local forward lookup zone and set the interface to not register in DNS still shows up in the secondary copper.local zone on the Boalsburg server after a successful zone transfer. I'm sure whatever it is, I'll get bit by it some day.
That change was replicated to the other copper.local domain controller. I'd be looking at the VPN configuration between sites now and verifying personally that the crypto maps and firewall rules actually do allow all traffic. And of course, the obvious launching of the DNS management console as Run As Administrator. I would also be using something like wireshark to see wtf is being passed to and fro. Posts in this and the Server Room forum have saved my bacon many a time. I'd be looking at the VPN configuration between sites now and verifying personally that the crypto maps and firewall rules actually do allow all traffic.
One thing to note, if there is any filtering, is that zone transfers (AFXR/IXFR) with windows do NOT use UDP/53. So if your network/VPN admin is saying 'oh yeah, we allow DNS' he may be only allowing port 53. One thing to note, if there is any filtering, is that zone transfers (AFXR/IXFR) with windows do NOT use UDP/53. So if your network/VPN admin is saying 'oh yeah, we allow DNS' he may be only allowing port 53.
Long story short, I can create a secondary forward lookup zone one way (add the copper.local zone to the blackberry.local DC) but not the other way (add the blackberry.local zone to the copper.local DC).
The 192.168.1.50 address is a virtual interface for a single Hyper-V guest on a secondary physical interface - oh yes they're rocking Hyper-V on a DC.
I reason I could still see the pings from 'PARKSERV' in the ASA logs was that the 'PARKSERV' was a named network object that included both IP addresses as the hosts.
Another unbelievably (to put it mildly) basic test that I overlooked - bi-directional ping.
Their Cisco guy was recently doing some work with a new UC560 phone system and also working to use AD authentication for their RA VPN - the RADIUS server it referenced was setup on PARKSERV (problematic DC).