Solved

Moving DFS Folders to a New Drive

Posted on 2011-03-02
21
4,833 Views
Last Modified: 2014-06-25
I have a DFS share between 2 offices. I have one office where the drive space is getting low. I have created a new drive array and mapped the drive to the server. I need to move my DFS folder to this new drive. This is in an AD Namespace. Nothing is going to change except the folder will will now be at G:\DriveName where it was at F:\DriveName. I have seen various articles on what may be best, all slightly different. I thought what might be best was to set F:\DriveName as a new replicated folder and then after everything replicates take the G:\DriveName out of the DFS. Would this work or is it best to do somethibg different?
0
Comment
Question by:barrykeel
21 Comments
 
LVL 5

Expert Comment

by:Noduzz
ID: 35022130
Yeah that would be the best way to perform what you want done.  That would replicate all the data to the new drive and then you can just remove the old target.
0
 

Author Comment

by:barrykeel
ID: 35023610
I not sure if my idea will work. Seems I can't add the new folder for replicating because it complains that the folder is on a server already in the replication group. Maybe I need to copy the files first, delete the old path and then add the new one.
0
 
LVL 3

Expert Comment

by:eviljester
ID: 35032906
Are you doing this in a 24hr environment? If not, some time after hours when the resource is not in use. Delete the replication group, move the data from the existing location to the new location. Then recreate the replication group using the new location.
If it is a 24hr environment, then you might just have to schedule some downtime, and do the same as above.
0
 
LVL 1

Expert Comment

by:patkremer
ID: 35046661
Funny we've never had this situation come up - maybe our volumes are oversized. It doesn't make logical sense to me that you wouldn't be able to have 2 folders on the same server participate in a replication group, but your testing appears to say that is the case.

You wouldn't have to cause downtime, but you can minimize the deployment time by using robocopy or something similar to prepopulate the new drive with the data. Then during the cutover, disable DFS targets for office A. During the initial sync, people in both offices will be using office B to serve up the files - so those in office A will have to deal with WAN latency to retrieve their files. After the initial sync is complete, enable the target for office A and all will be back to normal.
1
 

Author Comment

by:barrykeel
ID: 35046950
For patkremer. You did mention to stop the replication service on server A. I am going to back the files up and then restore to the new directory with existing permissions. Then break the replication group and re-apply the group with the new link on the server. Do think that stopping the DFS service should be done if the backup utility is DFS aware? I think I should stop the DFS service before even beggining, regardless. By stopping the service I have read there is no need to back up and restore the sragging folders, correct. Also, the server that the isue on is the master server, but it uses a mesh topology and replicates 24/7.
0
 

Author Comment

by:barrykeel
ID: 35046954
I meant Staging Folders, not sragging.
0
 
LVL 1

Accepted Solution

by:
patkremer earned 500 total points
ID: 35047497
I assume you're using a DFS namespace i.e. \\mydomain.com\Share1 points to \\serverA\share1 and \\serverB\share1?

Copying the files to the new drive via either a backup or just using robocopy is the fastest way. You could actually remove ServerA from the replication configuration and then add it back with the new path, but you'd then have to wait for the entire set of files to traverse the WAN.

So I'd first go into the DFS namespace configuration, go to the namespace servers tab, and disable referrals to ServerA. Then I'd shut down and disable DFS services on ServerA. You don't need to worry about the staging folders. Then I'd disable the Replication group, you don't want any surprise replication.

Copy ServerA's files over to the new drive.

Reconfigure the replication group to replicate between ServerA and ServerB. Be careful here, make sure you pick ServerB as the primary member or you're going to overwrite your good, live copy of the files. When the event viewer shows that the initial sync has completed, you can then change the DFS config to point to the new folder and enable referrals.
0
 

Author Comment

by:barrykeel
ID: 35047569
I am actually doing the back up right now. I tried to stop the service but it started back when I launched the DFS console. Anyway. I stop the replication for server A and removed it from the namespace. Right now I checked and the clients only see server B. I was thinking the same about server B now being the primary. So I would just delte the reference for A, then add it back with the new path. When you say "you can then change the DFS config to point to the new folder and enable referrals." you are referring to adding it back to the Namespace, correct?
0
 
LVL 1

Assisted Solution

by:patkremer
patkremer earned 500 total points
ID: 35047926
Correct, adding it back to the namespace with the new path on the new drive.

You might want to stop and disable the services to make sure they don't come back on unexpectedly.
0
 

Author Comment

by:barrykeel
ID: 35056845
I got the meberships back for replication, but I still have it disabled as a referral. I could not see anywhere adding it back to set the primary. I have seen so far a lot of 4202 and 4204 warnings since starting back. I have been waiting on the 4104 but have yet to see it. Since I pre-seeded the directory and have a 10 meg dedicated pipe I thought initial replication would take a couple of hours. I am at six hours so far and I really need to get this back online. I hope this hasn't gone south. Any ideas?
0
 

Author Comment

by:barrykeel
ID: 35063793
All finally looks to have come back OK.  Got the 4104 initial replication and have now added the referral back. Final issue. I did get a warning about a folder of files in the staging area that were not set for replication because they were pre existing files. Should these be added back to the new directories? I do not need to lose any data.
0
 
LVL 1

Expert Comment

by:patkremer
ID: 35064778
You got the warning like "Any local pre-existing content in this replicated folder that did not exist on the primary member for XXXXX has been moved to the hidden system folder DfsrPrivate\Preexisting " ?

Are there a bunch of files in there? Does it appear that replication deleted new files that were on ServerB?

I'm a little concerned that your replication used server A as the primary. When you added server A back to the replication group, it should have given you the option to specify the primary.
0
 

Author Comment

by:barrykeel
ID: 35065095
It did not give me the option. I did get some errors at first about it couldn't make a connection with incoming server B. It took most of the day and the users were using server B . Got a few high water warnings. Increased the size of the staging area. How would I tell if it used  A and what would be the consequences?
0
 

Author Comment

by:barrykeel
ID: 35065135
There were around 30 to 50 files out of about 800,000. The 800,000 make up about 570 gigs.
0
 
LVL 1

Expert Comment

by:patkremer
ID: 35066008
I'd make a backup copy of Preexisting and ConflictandDeleted, look for anything from today. If a user opened up a file on B before server A did its replication check on that file, server A could have deleted that updated file. If they opened a file on B after A did its replication check, the updated file would have (correctly) found its way from B to A.
0
 

Author Comment

by:barrykeel
ID: 35069774
I am sure that Server A was still seen as the primary. I ran a report from the DFS console and got the following:
During the initial replication process for replicated folder DOCS, the DFS Replication service identified pre-existing local content that was not present on the primary member and moved the content to H:\data\DOCS\DfsrPrivate\PreExisting. The DfsrPrivate\Preexisting folder is a hidden system folder that is located under the local path of the replicated folder. Content in the DfsrPrivate\PreExisting folder will not be replicated to other members of the replication group, nor will the content be deleted by the DFS Replication service during any automatic clean-up.

Maybe I should have deleted and reset both members since A was the original primary. Then when re-creating I could have chose the primary as server B. Anyway it lloks as if what I need to do is add the files back to the appropriate folders that are being replicated and have the users check them.

Patkremer, you stated "If a user opened up a file on B before server A did its replication check on that file, server A could have deleted that updated file." I take these are the files in the Preexisting and ConflictandDeleted?
0
 

Author Comment

by:barrykeel
ID: 35069795
If I move them back to the folders where they need to be to replicate, I take it I should remove the GUID at the end of each file?
0
 

Author Comment

by:barrykeel
ID: 35070133
One other thing I noticed. The files in the preexisiting folder are from server A. I thought they should be mostly from the secondary. So if A was the primary they sshould have been from server B, correct?
0
 
LVL 1

Expert Comment

by:patkremer
ID: 35098737
Yes on removing the GUID.

Correct on the Preexisting / and ConflictAndDeletef folder

How are you coming to the conclusion that A was definitely the primary?

If the files in the conflict folder are from Server A, that means Server B was the primary and it deleted files from A because they did not exist on B - the initial replication will mirror the primary to the secondary.

If the files in the conflict folder are from Server B, then Server A was the primary. I would expect that A was (correctly) NOT the primary. If you had users working an entire day on B, it is likely that A would have gotten rid of more than 30-50 files.

0
 

Author Comment

by:barrykeel
ID: 35177927
Yes, my users were working off of server B all day. I see what you are saying about the replication with deleting the files from A since it was mirroring B. I did let the users look through the deleted files after I renamed them. Most users said there files were OK. I only had one user find some files in the deleted folders that they said they needed. All other users said they were OK. Both A and B are now referrals and I have had no complaints after about 10 days. So I would say so far everything went fairly well.
0
 

Expert Comment

by:matt160
ID: 40156843
I know this is an older article but it's the top one in the search. When deleting members in DFS they are tombstoned. There is a MS article KB961655 on this and the work around.
0

Join & Write a Comment

Resolve DNS query failed errors for Exchange
Know what services you can and cannot, should and should not combine on your server.
This tutorial will walk an individual through the steps necessary to join and promote the first Windows Server 2012 domain controller into an Active Directory environment running on Windows Server 2008. Determine the location of the FSMO roles by lo…
This tutorial will walk an individual through the process of configuring their Windows Server 2012 domain controller to synchronize its time with a trusted, external resource. Use Google, Bing, or other preferred search engine to locate trusted NTP …

760 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

19 Experts available now in Live!

Get 1:1 Help Now