Re: FRS Only replicates on inbound connection, no changes go out.
- From: Mike Drechsler - SPAM PROTECTED EMAIL <mike-newsgroup@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 22 Aug 2005 07:44:50 GMT
Ace Fekay [MVP] wrote:
In news:iBbOe.73325$576.70237@xxxxxxxxxxxxxxxxxxxxxx,
Mike Drechsler - SPAM PROTECTED EMAIL <mike-newsgroup@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> made this post, which I then I commented on below
Oh one other thing. All the DFS shares do not show this unjoined status, only the sysvol shows this status. All DFS entires show that both in and outbound replication is joined and the status shows OLP_ELIGIBLE but all 3 DFS replicas also only replicate changes into the remote server but not out from it just like sysvol.
Besides being a possible DNS config issue, this more and more looks like a possible firewall or VPN issue. As long as the SRVs are available for each DC, and it will resolve the queries for the service locations, then we can rule that out. You can try to point all the DCs to one DNS server, the one it's working from, and test that out, and it doesn't work, then we can rule out DNS issues, unless the routers cannot handle ENDS0, which allows UDP response traffic greater than 512 bytes. You will have to check the router's vendore docs on that.
However, to continue, there was a previous poster I was helping out months ago with a similar situation. He allowed me to remote into it to work on it, and we wound up working on it together (over the phone too) for a couple of days. It racked my brain. Finally I asked about the VPNs and what he may have changed, if anything. I asked to see his VPN connection properties on his routers, specifically the MTU settings. It turned out he recently upgraded one of his VPN router's firmware and specifically the MTU (I forget the name brand). The new firmware, for some reason, forced the MTU to 1492. It would not allow me to change it to 1500, which is default and where it should be. The other end was the default 1500. Usually ADSL will cause a lower MTU since it uses the 8 bytes for header info. But he had T1 lines. It didn't make sense. Luckily he had saved the previous config file. Once he replaced the old version, everything started working again, replication errors disappeared and we were all happy! Apparently something was up with the newer firmware. He wound up upgrading the VPN routers with Netscreens, which are very effective units.
Another good idea.
I did some MTU tests, messed with the MTU sizes on the routers on either end and I'm 99.99% sure that there is no MTU or WAN issues blocking replication. I changed the MTU values of the tunnels to be manualy set to make sure. I can do RPC communication (view event logs remotely) withough problems on either machine. I can transfer large or small files without problems. I can do ping tests with the -f (do not fragment) switch and it correctly reports the packet requires fragmenting when it reaches a certain size with no "gap" where it simply goes into a request timed out mode. (IE. packets size 1416 works, size 1417 gives "packet requires fragmenting but DF bit set" as it should). The routers on both ends have no packet filters installed between the sites, it's wide open between the two for traffic on any port, any protocol, and any address. Packetloss as measured by ping tests with 1416byte data sizes show 0 lost packets and over 1000 received while transferring an 80GB file from the remote server to the main server.
I let it run for about 90 minutes and did a restart of both servers just after changing the MTU values on the routers. It is only doing the replication in a single direction. As a further test I created a new DFS link with some test folders. I threw a few text files into the remoteserver and set it as the master when enabling replication. After everything settled down the files appeared on the main server as you would expect but after this, new files added on the remote server or changes to existing files are not being replicated to the main server. Changes on the main server are replicating to the offsite server just the same as all the other DFS and sysvol folders so even a brand new folder setup exibits the problem which means D4 and D2 restore is not likely going to help me either.
-- WARNING! Email address has been altered for spam resistance. Please remove the -deletethispart-. section before replying directly. Mike Drechsler (mike-newsgroup@xxxxxxxxxxxxxxxxxxxxxxxxxxxx) .
- Follow-Ups:
- Re: FRS Only replicates on inbound connection, no changes go out.
- From: Ace Fekay [MVP]
- Re: FRS Only replicates on inbound connection, no changes go out.
- References:
- FRS Only replicates on inbound connection, no changes go out.
- From: Mike Drechsler - SPAM PROTECTED EMAIL
- RE: FRS Only replicates on inbound connection, no changes go out.
- From: garry
- Re: FRS Only replicates on inbound connection, no changes go out.
- From: Mike Drechsler - SPAM PROTECTED EMAIL
- Re: FRS Only replicates on inbound connection, no changes go out.
- From: Mike Drechsler - SPAM PROTECTED EMAIL
- Re: FRS Only replicates on inbound connection, no changes go out.
- From: Ace Fekay [MVP]
- FRS Only replicates on inbound connection, no changes go out.
- Prev by Date: Re: Expiry of the accounts that haven't been used for 45 days
- Next by Date: Re: ADC of remote site take time about 15 Min to prepar network connen
- Previous by thread: Re: FRS Only replicates on inbound connection, no changes go out.
- Next by thread: Re: FRS Only replicates on inbound connection, no changes go out.
- Index(es):
Relevant Pages
|