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 “\\\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

Branchcache demonstration, part 2

Welcome back to my Branchcache demonstration.

Configure the Hosted Cache server

Picking up where part 1 left off, the next step is to configure the host cache server, though you can implement Branchcache without this. In hosted cache mode we store the cache on a designated server in the branch office and clients can pick up cached content from here. On the server located in the branch office , just start up Powershell and run

Install-WindowsFeature BranchCache -IncludeManagementTools

Once the feature is installed you configure the server, still from Powershell with

Enable-BCHostedServer (For servers who’s not domain joined)


Enable-BCHostedServer -RegisterSCP (For domain joined, enables automatic discovery from BC-clients)

To confirm the configuration you run


You should see the status something like this


and further down


Configure the clients

As for the clients things are simply configured in Group Policy

First we go to “Computer Configuration, Policies, Administrative Templates, Network, BranchCache” and set the following settings


Setting both the Distributed cache mode and the automatic hosted cache discovery makes the client search AD for a hosted cache server. If it finds a local server then it operates in hosted cache mode, and if not then the clients switch over to distributed mode.

Next we need the firewall configured. In the GPO we navigate to “Computer Configuration, Policies, Windows Settings, Security Settings, Windows Firewall with Advanced Security”

  1. Create a new inbound rule, select “predefined” and “BranchCache – Content Retrieval (Uses HTTP)“, next twice and then “Allow the connection” and click Finish
  2. Create a new inbound rule, select “predefined” and “BranchCache – Peer Discovery (Uses WSD)“, next twice and then “Allow the connection” and click Finish
  3. In outbound rules, create the exact same 2 rules as you just did for inbound.

After the GPO is done and linked to the correct OU you can turn to your clients and run

gpupdate /force

Then the Brachcache service must be restarted, so run from Powershell

Restart-Service PeerDistSvc

And to check the status it’s


Notice that the client has detected a hosted cache server and is then set itself to use it.


So from now on the data from the file share on the content server will be cached on the hosted cache server whenever a client in the branch office access it.

Does it work?

In order to verify this I have performed the following test:

  1. On the hosted cache server, start performance monitor and load all Branchcache counters
  2. From one client copy a file from the file share on the content server to the local hard drive
  3. From another client copy the same file to its local hard drive
  4. Check the Branchcache counters on the hosted cache server that Branchcache works.

And after these steps I had the following result i Performance Monitor


“SMB:Bytes from server” is from the first copy operation where the data is copied from the content server and then cached on this server. “SMB:Bytes from cache” is the second copy operation where the clients get all the data from the cache on the hosted cache server instead of from the content server which is located in another site. Looks great! 🙂

Finally, if you want to read more aboiut deploying Branchcache I recommend you read the Branchcache Deployment Guide from Microsoft. It can be downloaded here:

Branchcache demonstration, part 1

Introduction to Branchcahce

Branchcache was introduced in Windows Server 2008 R2 and it is a tool to reduce the impact of having low bandwidth between a branchoffice and a central file server. The short description would be that either a dedicated server, or the clients themselves, cache the content when a file is opened or copied across the WAN link. When the next client access the same file, most of the content is available on the LAN and the need to copy data across the WAN link is reduced, resulting in a better user experience.

If you want to read more about Branchcache you can check out my own post about it:

In Windows Server 2012 there has been many improvements to Branchcache. A few highlights include:

  • No limitation to number of hosted cache servers in each branch office
  • No need for a separate GPO for each site
  • No need to deploy a certificate to the hosted cache servers
  • Clients can autoconfigure between hosted cache and distributed cache mode
  • Duplicate content is only downloaded once
  • Cache is encrypted by default
  • Cache can now be pre-loaded

Full list of changes are located here:

Branchcache can operate in either “hosted cache mode” where a server in the branch office stores the cache, or in “distributed cache mode” where the clients store and shares the cache among themselves. Now I want to make a simple demonstration of Branchcache in hosted cache mode using Windows Server 2012 and Windows 8. First of all:

The lab setup

  • 1 domain divided in 2 sites “HQ” and “SmallOffice” (guess which one is the branch office) with a DC in each site.
  • 1 centralized file server as “content server” (the server containing the files)
  • 1 server in the branch office as “hosted cache server” (the server containing the cache of the content)
  • 2 clients in the branch office
  • All servers are Windows Server 2012, all clients are Windows 8

AD Sites is one of the key components here so make sure you define your sites and subnets correctly.

Setting up the content server

In Windows Server 2012 Powershell is dramatically expanded and improved so it’s no surprise that we use Powershell in the implementation  On the newly installed Windows Server open Powershell and run

Install-WindowsFeature FS-BranchCache -IncludeManagementTools


Next up is to enable the hash publication of the content server. Here we make a GPO and link it to the OU containing the content server. 2 simple settings located under “Computer Configuration, Policies, Administrative Templates, Network, Lanman Server”. Once it’s deployed it’s time for a “gpupdate” on the content server


After the group policy is set you have to share a folder and enable brachcache on that share. Simpe way to do so in the GUI


Now that the content server is ready I’m gonna fill it up with some files and in part 2 we will set up the Hosted cache server and the clients and I’ll do a proof of concept.

See you in part 2!

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.




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



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?


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


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


  • 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.