B
Bad-Mo-Fo
Hello everyone,
So i am in the process of setting up what might be called a disaster recovery site. I created a VM on Azure, got it all up and running. Set it up as a 2nd DC with global catalog, DNS. I am hoping to get DFS working between it and my physical site. Both servers are running 2012 R2. Our internet connection is 200Mbps. I setup a hard VPN to Azure on our firewall, so that is the only connection to the Azure VM.
I setup DFS no problem. I setup one main DFS Namespace, and then four replication groups within that. I read somewhere that having the server on Azure be the DFS namespace holder was the way to go so that is what I did. Three of the folders work great, and i mean great, i create a new folder and before i can even switch over to the other server it has replicated, less then a second. I started replicating these folders the end of last week. I have almost 3TB of data to replicate. when i came in this morning the three had fully replicated. (Besides *.bak files. On a side note i need these to replicate as well if someone could tell me how to make that happen. We use AutoCAD and it uses .bak files.) The issue is the fourth folder doesn't replicate at all. I set these up all at the same time, with very similar settings. The only real difference is that my redirection folder is shared as "redirection$" in order to keep it hidden. This folder is setup the same on both ends. However i named the replication group "userfiles". The forth folder is my folder for redirecting user files, and the folder redirection works fine to the initial share. So the only difference here is the permissions set on the folder. I am trying to maintain the permissions as best i can so that users don't have access to each others files, so the permissions are set to accommodate that. What i would call a standard setup, as far as redirection is concerned. Tried restarting DFS service, made sure RPC working on both machines. DFS management says all topologies are fully connected. I keep coming back to permissions, but shouldn't DFS be sort of immune to ACL entries? Also when i try to run any reports against DFS management it never completes. The only entries in either event log are 5014 for a brief break in connectivity. and info entries 5004 stating that connection was reestablished. There are a few entries of 4204 and 4208 refrencing the staging space and being above the high watermark. (i dont really know what this means) and then coming back below the high watermark. Again this folder is only user files, pics and docs, nothing really big. Our projects folder, by far the largest with the largest files replicated fine, almost 2.5 TB.
Another odd thing is now my mapped drives are very spotty as far as connecting and staying connected. I chalked this up to the files replicating in the background, and that may be true, as now those folders are replicated, i haven't tested the stability of those mapped drives yet today.
I am fairly new to DFS. I mean i have known about it for years, but never had to use it so i definitely could have messed something up.
Any help would be appreciated.
Continue reading...
So i am in the process of setting up what might be called a disaster recovery site. I created a VM on Azure, got it all up and running. Set it up as a 2nd DC with global catalog, DNS. I am hoping to get DFS working between it and my physical site. Both servers are running 2012 R2. Our internet connection is 200Mbps. I setup a hard VPN to Azure on our firewall, so that is the only connection to the Azure VM.
I setup DFS no problem. I setup one main DFS Namespace, and then four replication groups within that. I read somewhere that having the server on Azure be the DFS namespace holder was the way to go so that is what I did. Three of the folders work great, and i mean great, i create a new folder and before i can even switch over to the other server it has replicated, less then a second. I started replicating these folders the end of last week. I have almost 3TB of data to replicate. when i came in this morning the three had fully replicated. (Besides *.bak files. On a side note i need these to replicate as well if someone could tell me how to make that happen. We use AutoCAD and it uses .bak files.) The issue is the fourth folder doesn't replicate at all. I set these up all at the same time, with very similar settings. The only real difference is that my redirection folder is shared as "redirection$" in order to keep it hidden. This folder is setup the same on both ends. However i named the replication group "userfiles". The forth folder is my folder for redirecting user files, and the folder redirection works fine to the initial share. So the only difference here is the permissions set on the folder. I am trying to maintain the permissions as best i can so that users don't have access to each others files, so the permissions are set to accommodate that. What i would call a standard setup, as far as redirection is concerned. Tried restarting DFS service, made sure RPC working on both machines. DFS management says all topologies are fully connected. I keep coming back to permissions, but shouldn't DFS be sort of immune to ACL entries? Also when i try to run any reports against DFS management it never completes. The only entries in either event log are 5014 for a brief break in connectivity. and info entries 5004 stating that connection was reestablished. There are a few entries of 4204 and 4208 refrencing the staging space and being above the high watermark. (i dont really know what this means) and then coming back below the high watermark. Again this folder is only user files, pics and docs, nothing really big. Our projects folder, by far the largest with the largest files replicated fine, almost 2.5 TB.
Another odd thing is now my mapped drives are very spotty as far as connecting and staying connected. I chalked this up to the files replicating in the background, and that may be true, as now those folders are replicated, i haven't tested the stability of those mapped drives yet today.
I am fairly new to DFS. I mean i have known about it for years, but never had to use it so i definitely could have messed something up.
Any help would be appreciated.
Continue reading...