File and DFS migration script

Currently I am in a project which will migrate several users in a large AD environment from one site to another as the current site is being decommissioned. This involves (among other things) migrating files and DFS Namespace to another file server and domain controllers and since this is a repetitive task for each department, I’ve made myself a sort of workbook in Powershell that I’d like to share with you.

This is a script which I load into an elevated PowerShell ISE, and change the input variables in the top and save a copy for each department. Then I can load the script I need, run all parameters and just mark and run selection (F8 hotkey) depending on the task at hand. The script is divided into 11 parts for tasks during preparation and during cut over. I’ve used comments to clearly divide the tasks.

To put it in perspective: The script linked will handle:

  • The department “Billing”
  • Short-reference “Bill”
  • Currently has a share named “Billing$” on the old file server
  • Linked to the DFS Namespace “\\corp.contoso.com\Bill” which is used for drive mapping.

The script will check and perform the different tasks needed to move their data to another file server and update both DFS Root Targets to the new domain controllers (which will host the namespace itself).and Folder Targets which points to the new file server.

The script can be downloaded here

Personally I found this makes it a lot easier, as the project goes on, to handle several ongoing migration jobs either in preparation or at cut over phase. It also makes sure the result is consistent and reduces the risk for failure.

As always feel free to use and customize to meet your own requirements

Advertisements

The story of DFS and one-way replication

Greetings. Finally my schedule allows me to blog a little bit again, and this time I’m going to return to DFS Replication (DFS-R) and mention a few things about one-way replication.

The default

A default DFS-R setup features a two-way replication which replicates all changes made in either enabled partner in the replication group. This means that any changes made on any partner will be replicated throughout the replication group. Now there are several scenarios (for example software distribution from a central storage) where you want to prevent changes made in the branch offices to replicate.

One-way replication vs Read-only replication

With Windows 2008 R2 we got the option to make replicated member read-only. This marks the entire replicated folder, with subfolders and files, as read only for all users. This way there is no replication from this member because no changes can ever be made. This is the supported way of achieving one-way replication, but you are limited to read access and can’t make any changes whatsoever to the replicated folder.

 

DFS-R_readonly

 

The other way is to manually edit the replication connections and set the connection status to “disabled”. This will prompt a warning message saying the topology is not fully connected. This configuration is NOT supported but it kind of works. So what does “kind of works” mean? Well, say there’s a central site and a branch office with DFS-R to replicate a folder and you disable the sending connection from the branc hoffice to the central site.

  • Files and folders created in the central site is replicated to the branch office
  • Files and folders created in the branch office are not replicated to the central site

So far so good? However:

  • If a file is first copied to the branch office, and later an updated version of the same file is copied to the central site, the older version in the branch office will not be updated.
  • This seem to be true for Windows Server 2008 R2 and in my Windows 2012 lab, the file in the branch office is replaced and local changes are being discarded when a newer version of that file is copied into the central site.
  • I have not found anything that suggest this configuration is supported in Windows Server 2012

DFS-R_oneway

 

To sum up

The choice of one-way replication in DFS-R is to make a replicated member real-only if you are using 2008 R2. This is the supported configuration. There are an unsupported way which is to disable the replication connections in DFS-R and it works with one exception unless you run Windows Server 2012 where so far this seem to work as it should.

 

I hope you have enjoyed this post, more DFS-R to come so stay tuned 😉

DFS-R or Branchcache?

ATTENTION!

I’d like to write more about DFS and Branchcache. Which subject within these two fields do you want to read more about? Do you have unanswered questions about any of these two technologies? Please use the comment section below and let me know what you want me to write regarding Brachcache or DFS. Thank you 🙂

Recently I’ve been discussing DFS replication (DFS-R) and Branchcache (BC) as solutions that allow users in regional offices access their files on a central fileserver across the WAN link. As always there is no “one size fits all” answer in the IT business, and so I’d like to share their different pros and cons with you all.

DFS-R was introduces in Windows Server 2003 R2 and replaced FRS (File replication Service) both for replicating Active Directory and for creating your own file server replication. DFS-R is implemented on a pr folder basis, and it will (after the initial sync) replicate only the changes within a file and not the entire file when a user make a change to it, and you can easily customize replication schedule and bandwidth consumption. The replication in DFS-R uses a multiple-master model so any server in the replication group can make changes and it replicates to all other members in the replication group, making this a very easy way to provide duplication of data which can be stored on servers either in the same site or a remote site. Note that DFS-R does not require DFS Namespaces though they are usually combined.

Branchcache is a feature introduced with Windows 7 and Windows Server 2008 R2 which allows a server or client in a remote site to cache data accessed from a file server. Whenever a file is accessed from a BC-enabled share, the client will create a cache of the files data which is now available for other clients is the same site when they try to access the same file. This way only a minimal amount of data, and the files metadata, has to be transferred over the WAN-link and the users can access most of the file over the local network. Branchcahe can be set up in hosted cache mode if the regional office has a local server. This will make this server host the cache and making it available to all local clients. For offices without a server, BC can be set up in “Branchcache distributed mode” which makes all the Windows 7 clients share their caches among themselves.

So what’s the big difference then? The biggest difference is that DFS-R is a replica of the data, while BC is only a cache. Because of this the two solutions act differently pretty much all the time.

Starting with redundancy, the DFS-R creates a complete replica of the data making it available in case one of the servers becomes unavailable, while BC requires the source file server to be available or the users can’t access the files.

DFS-R requires a local server which is Windows Server 2003 R2 or later, while BC can operate in offices without a local server, or a local server earlier than Windows Server 2008 R2.

BC requires Windows 7 Enterprise or Ultimate on the client and Windows Server 2008 R2 on the server, while DRS-R has no client requirements as the files is just another SMB share.

Filelocking is one of the most common challenge with DFS-R because when a user open a document the file is automatically locked for editing for other users, but only for user which uses the same server. The filelock does not replicate and so the file is available for editing on other servers which can cause a conflict. The last one who saves wins, and the other changes are stored in a folder which contains replication conflicts. This of cource something the administrators have to resolve in each such conflict. In BC there is only one file so filelocking works as normal and no users can edit a file that’s open.

As for bandwidth consumption it is really hard to tell as there are many factors that affects how much replication traffic will occur, but DFS-R provides more options to control and tune the replication. BC will save all changes to a file over the WAN-link and pull all file metadata which isn’t in the cache available at the local site. DFS-R will have a complete replica of all the files and after the initial synchronization when you set up DFS-R only the changed file blocks will ever cross the WAN again

Here a simple review of the differences

Filelock

  • DFS-R: Only within the same server, filelock is not replicated
  • BC: Filelock as usual

Filversions

  • DFS-R: If replication conflict, 2 or more versions, must be addressed by admin
  • BC: 1 version

Require server at regional office?

  • DFS-R:Yes
  • BC: Yes, for hosted cache mode. No, for distributed mode

Latency at file changes

  • DFS-R: Minimal (saved at local server, then replicated according to schedule)
  • BC: None

Server requirements

  • DFS-R: Windows 2003 R2 or more recent
  • BC: Windows 2008 R2 Enterprise

Client requirements

  • DFS-R: None
  • BC: Windows 7 Enterprise/Ultimate

Server implementation

  • DFS-R: Server Role, replication groups manually set up.
  • BC: Share property, GPO settings

Client implementation

  • DFS-R: None
  • BC: GPO settings

Available if WAN goes down?

  • DFS-R: Yes
  • BC: No

Data duplicaiton?

  • DFS-R: Yes, each server has a full copy of the data
  • BC: No, files are stored centrally with some data available locally

And if you have several regional offices, remember than you can use both solutions and give DFS-R to some offices and let the rest use Branchcache.