AA-in-CA
asked on
Folder redirection: best to robocopy from old server to new server?
Consider the following scenario:
Our customer has purchased a new file server for their redirected folders, call it "NewServer". Their redirected folders currently reside on another server, "OldServer". Folder redirection policy is as follows:
We don't want to use the optimized move procedure described in here, but we also don't want to leave NewServer "empty" until users logon and their workstations copy their folders to the new location. The reason for this is because some users have very large folders, and may get impatient and turn off their PCs during the logon copy process, resulting in an inconsistent folder state.
That leaves this option: robocopy the folders from OldServer to NewServer when users aren't working, and update policy to point to the new location. Policy will have refreshed by the time the users come in, so their PCs will have the updated policy setting.
Will that procedure work correctly?
In other words, if I robocopy the folders from OldServer to NewServer, and just update the policy to point to NewServer, will the workstations "understand" that they need to sync offline files using the new location, without users needing to wait for a file copy to finish?
Our customer has purchased a new file server for their redirected folders, call it "NewServer". Their redirected folders currently reside on another server, "OldServer". Folder redirection policy is as follows:
We don't want to use the optimized move procedure described in here, but we also don't want to leave NewServer "empty" until users logon and their workstations copy their folders to the new location. The reason for this is because some users have very large folders, and may get impatient and turn off their PCs during the logon copy process, resulting in an inconsistent folder state.
That leaves this option: robocopy the folders from OldServer to NewServer when users aren't working, and update policy to point to the new location. Policy will have refreshed by the time the users come in, so their PCs will have the updated policy setting.
Will that procedure work correctly?
In other words, if I robocopy the folders from OldServer to NewServer, and just update the policy to point to NewServer, will the workstations "understand" that they need to sync offline files using the new location, without users needing to wait for a file copy to finish?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I'm just wondering why wait?
If they are supposed to be identical then you Robocopy /MIR //oldserver1/share1 //newserver2/share2
Unless you run it local to where data resides, which I recommend
Robocopy /MIR E:/OfflineFiles //newserver2/share2
So there are inconsistencies if doing this from a 2003 SMB share to a 2008 R2 or 2012 SMB Share. 2003 Server last I checked still supported LANMAN 1.
And that Redirected folders section, your looking at cutting over 1 user at a time? That UNC has to be changed.
Your wanting to copy "permissions" as well yes?
Robocopy /MIR
Scheduled Task, sync every night until cut over.
Not 100% though because I don't know what OS your copying from and too.
Your best bet, mentioned earlier - Arnold - is DFS root and DFS folders that you can put BOTH shares behind the same DFS Name Space and use Replication.
Now, I cannot remember if this works going from 2003 server to 2008R2.
For one, you cannot go Full Native Mode. If it were just a file server, still depends on functional level.
So, you have a big need for users to store data on their laptops or desktops?
I try to avoid offline folders but if no choice I would minimum stand up a stand-alone DFS server. Maybe AD integrated depending on functional level.
Other wise, Robocopy /MIR source destination *.* /R:0 /W:0
But, here is the problem, it includes everyone from original source. So original source must be the always updated and you do one final sync for that user before archiving somewhere else to make sure user got all files.
If you have users already cutover, that data would be overritten.
Hence, Robocopy source destination *.* /COPYALL /E /R:0 /W:0
So, this will syncronize the files and only the delta changes.
And, retain security permissions (ACL,DACL)
You can add a /MOVE to do one person or group of persons at a time.
You could add the user ID's to a users.txt file
Create a CMD file for you base script
Open CMD to the base script directory
Type FOR %a in (users.txt) do (rcopy %a)
%a being each line in users.txt then do robocopy (your batch file) and it would parse the entire txt file, then complete.
If they are supposed to be identical then you Robocopy /MIR //oldserver1/share1 //newserver2/share2
Unless you run it local to where data resides, which I recommend
Robocopy /MIR E:/OfflineFiles //newserver2/share2
So there are inconsistencies if doing this from a 2003 SMB share to a 2008 R2 or 2012 SMB Share. 2003 Server last I checked still supported LANMAN 1.
And that Redirected folders section, your looking at cutting over 1 user at a time? That UNC has to be changed.
Your wanting to copy "permissions" as well yes?
Robocopy /MIR
Scheduled Task, sync every night until cut over.
Not 100% though because I don't know what OS your copying from and too.
Your best bet, mentioned earlier - Arnold - is DFS root and DFS folders that you can put BOTH shares behind the same DFS Name Space and use Replication.
Now, I cannot remember if this works going from 2003 server to 2008R2.
For one, you cannot go Full Native Mode. If it were just a file server, still depends on functional level.
So, you have a big need for users to store data on their laptops or desktops?
I try to avoid offline folders but if no choice I would minimum stand up a stand-alone DFS server. Maybe AD integrated depending on functional level.
Other wise, Robocopy /MIR source destination *.* /R:0 /W:0
But, here is the problem, it includes everyone from original source. So original source must be the always updated and you do one final sync for that user before archiving somewhere else to make sure user got all files.
If you have users already cutover, that data would be overritten.
Hence, Robocopy source destination *.* /COPYALL /E /R:0 /W:0
So, this will syncronize the files and only the delta changes.
And, retain security permissions (ACL,DACL)
You can add a /MOVE to do one person or group of persons at a time.
You could add the user ID's to a users.txt file
Create a CMD file for you base script
Open CMD to the base script directory
Type FOR %a in (users.txt) do (rcopy %a)
%a being each line in users.txt then do robocopy (your batch file) and it would parse the entire txt file, then complete.
I heartily agree with arnold <cheers, mate> Since you are changing anyways setup dfsr and the share properly add the 2 targets.. and after a while a week or so remove the source target. Keep DFSR as it is very handy to have and lets you change things in the future.
The problem is that the way things work with folder redirection is that the source must be available until the destination is fully populated.
The problem is that the way things work with folder redirection is that the source must be available until the destination is fully populated.
If you are using dfs shares, you can use the dfs-r replication to. Copy the data out and transition to the new server by adding the new server as the dfs target for the share while changing the distribution policy favoring the new as primary target. Then after a few days, remove the old server as the target.
The only thing you will need to make sure is set tge share rights on the newserver.