DReplication stops after office move
We have the following Scenario
SBS Server (Main Server) to DR Server (remote Site) DFS working ok
Client moved Office with the Main server (New public IP on Virgin Broadband)
Firewall disabled on Virgin Router
Client has Cisco HW firewall in place
After the move the setup is
Virgin router Netgear 4 port Switch Cisco Firewall (Data/Mail)
We now have the issue, after the servers are rebooted DFS works fine for 25 mins, then it drops the DFS namespace from the DR Server
DFS then only works in one direction,
DR Server Main SBS server ,
Ping works in both directions ip & Name
SBS Server (Main Server) to DR Server (remote Site) DFS working ok
Client moved Office with the Main server (New public IP on Virgin Broadband)
Firewall disabled on Virgin Router
Client has Cisco HW firewall in place
After the move the setup is
Virgin router Netgear 4 port Switch Cisco Firewall (Data/Mail)
We now have the issue, after the servers are rebooted DFS works fine for 25 mins, then it drops the DFS namespace from the DR Server
DFS then only works in one direction,
DR Server Main SBS server ,
Ping works in both directions ip & Name
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
As an additional note we are getting:
ActiveDirectory_DomainServ
ActiveDirectory_Domain_Ser
ActiveDirectory_Domain_Ser
But also in the Sites and Services MMC we have a Conflict site with the GUID
CNF-AD-SS.JPG
ActiveDirectory_DomainServ
ActiveDirectory_Domain_Ser
ActiveDirectory_Domain_Ser
But also in the Sites and Services MMC we have a Conflict site with the GUID
CNF-AD-SS.JPG
We have removed the CNF entry from Sites and services on both sites the problem persists.
From troubleshooting AD the issue appears to be with AD port traffic not getting through in one direction. From research this maybe to do with MTU sizes and the traffic being dropped between the sites. I can't get 389, 3268 or 135 to connect when using portqry.
If I ping the problem DC with ping problemDC -f -l 1392 it responds but it fails with a data size any higher than that.
On another system which works the data size can be as high as 1406
From troubleshooting AD the issue appears to be with AD port traffic not getting through in one direction. From research this maybe to do with MTU sizes and the traffic being dropped between the sites. I can't get 389, 3268 or 135 to connect when using portqry.
If I ping the problem DC with ping problemDC -f -l 1392 it responds but it fails with a data size any higher than that.
On another system which works the data size can be as high as 1406
I have modified the LAN interface on the server where the packets are sent from but not received by the partner DC with following this article:
http://www.sysadmintutorials.com/tutorials/microsoft/windows-2008-r2/how-to-set-windows-2008-r2-mtu/
The problem is the MTU size before fragmentation seems to be dropping lower on a daily basis on the 9th it was 1392, yesterday when I made this change is was 1358 and today it is 1330?
AD Replication is currently working in both directions but DFS still has some RPC issues which results in intermittent DFS connectivity.
Why would the pingable packet size be dropping between the sites? Surely if the issue was a black hole router the configured status would be static unless it keeps using a different route to the site yet because it is over an IPSEC VPN tunnel I can't use tracert to see any difference
http://www.sysadmintutorials.com/tutorials/microsoft/windows-2008-r2/how-to-set-windows-2008-r2-mtu/
The problem is the MTU size before fragmentation seems to be dropping lower on a daily basis on the 9th it was 1392, yesterday when I made this change is was 1358 and today it is 1330?
AD Replication is currently working in both directions but DFS still has some RPC issues which results in intermittent DFS connectivity.
Why would the pingable packet size be dropping between the sites? Surely if the issue was a black hole router the configured status would be static unless it keeps using a different route to the site yet because it is over an IPSEC VPN tunnel I can't use tracert to see any difference
Premium Content
You need an Expert Office subscription to comment.Start Free Trial