I don't have a question, but just discovered a couple of odd quirks with Site Replication
My Primary DC has 2 IPs on 2 different subnets to which it responds to requests.
I have a remote site that is connected via SSTP that I just added, and site replication was failing from the corp office to the remote site.
PDC responds to DNS requests on 2 different class C subnets, call them A & B
Using the RSAT DNS tool..
The NS record for the corp DC has, in order, A & B IP addresses, and the remote site is set up to make requests to the B address. Apparently, since the A address is at the top of the IP queue, and the remote site cannot talk to it, once the replication fails, AD does not attempt to locate an alternate IP address over which to send replication info. So, I tried to delete the "A" IP address from the remote site's forward lookup zone from the NS record, at which point the DNS tool just froze up and made the corp DC/DNS server lock up as well. Tried this 2 or 3 times, all to the same end. Timed replication and forced replication (through AD S&S) fails.
Log on to the DC, launch DNS, delete the "A" IP address from the remote site forward lookup successfully. Force replication through AD S&S, replication successful.
Go back to the NS record for the forward lookup zone, the "A" IP address has been re-added, but apparently now that AD knows which IP it is supposed to use, this isn't a problem.
Just thought I'd share this because it took me about 12 hours to figure out that this was the problem.
The quirks are
1) You can't use the RSAT DNS tool to delete an IP address from an NS record, you have to log on to the DC and launch the 2008 R2 DNS tool
2) Site replication can fail when using a DC/DNS server to respond on different subnets if the remote site makes requests to any of the non-primary IP addresses. No earthly idea why, but that's what was happening.
Hope this helps somebody.