Well, the upgrades continue. Now, I am in the process of moving all of our DFS (Distributed File System) shares from our existing Windows Server 2003 Enterprise Edition (WS2003EE), to the new Windows Server 2003 R2 Enterprise Edition (WS2003R2EE). Here are some of the fun things I have found out while doing this.
First of all, DFS is Distributed Files System, which allows you to have shared documents on servers, without having to remember the name of the server it is on. This is very handy when you decide to replace a file server, because the new share location will simply use the same DFS name, no matter what the server name is. Here is an example:
You have a server named FileServer1 that shares a folder called Home, that is the My Documents for all of your users. A couple of years have passed and you want to replace FileServer1 with StorageServer. Without DFS, that folder, and each person’s folder in it, would have been at:
You would have to change the logon scripts for users, and run around and change any shortcuts people have created (not to mention shortcuts in documents) to point to the new location of:
With DFS, you can setup the name \\MyDomain\Files\Home, and then setup \\FileServer1\Home as a target for it. Then, you would use:
for their files. Then, when you bring in the new server, you simply add it as a target for the same root name, and you don’t have to change any shortcut names, or any logon scripts for anyone.
When you add a new server as a target for a name, you have to somehow copy all of the files to the new server. This can either be done manually using RoboCopy, or automatically using File Replication Server (FRS). FRS is also used after the files are copied to the server for the first time to keep copies on more than one server up to date.
Now that we have talked about the pie-in-the-sky way that DFS/FRS works, lets talk about the cold hard reality.
- DFS only works for file shares, it can not be used for printers. So, if you have a printer server setup to handle all of the printers for the department, then when you change servers, you are going to have to change the settings on every machine. You might be able to do some of that via VBS scripting or batch files, but then you get into a messy area of “what about that print queue for just that one manager” or how to implement the fix so that everyone gets it, without their machine taking far too long to startup on each restart.
- There are many handy tools that come with the DFS MMC snap-in. However, these are only for WS2003R2EE. If one of the machines is older, then those glorious tools are useless for you. Those tools would help you fine-tune replication properties and even view replication status. But, alas, if you are not on a R2 setup only, then they don’t do diddly for you. You are relegated to command line tools, editing registry entries, and the only replication status program I could find at MicroSoft.com, Sonar. It is about as user-friendly as jabbing ice-picks in your eyes.
I mentioned that you will be editing registry entries, I meant that. There are many things you need to do that only can be done from the registry. After which, you have to either restart the File Replication Service service itself, or just reboot the machine.
- Making changes to DFS is insane. Adding a target to an existing share? Removing a target from a share? Testing with some fake shares to see the performance of FRS? Well, all of these will work to drive you insane.
Adding a new server (target) to an existing share (root):
Logically, you would think that adding a target to a root share would be a matter of a few steps. 1) Open the DFS console, select the group and then the specific share. 2) Add a new target to the share. 3) When prompted, setup replication according to the screens given you. 4) Verify the new target is enabled. Hopefully, that would be it. You job is finished, and you can go have a beer.
However if you did this, then what would happen is that people would connect to the share and see either: A) nothing, no files, no folders, just nothing. B) lots of things missing. Why would this happen? Well, if a new target is enabled, then users can, and will, be sent to it. Even before replication has finished. They will then see only the things that have already replicated to the new target.
When this happens, you have to open the DFS console, and disable the new target. This will still allow replication, but not send people to the new target for the files. Then, everyone who is already logged in will have to log out and back in, or just reboot their machines.
Another problem you will have is that any file over ~500MB will not replicate, and replication will be awfully slow for everything else. This is because the default staging space for incoming and outgoing files is only 660MB, and FRS starts to bitch and complain, and stop replication, when that is 60% full. Also, the priority for FRS defaults to low, or as I like to put it, “a European Swallow could carry the data on floppy discs faster” priority. The staging size is changed only in the registry, the priority is changed in what seems to be the super-secret menus.
Changing the size assigned to staging for FRS is done in the registry key:
Parameters\Staging Space Limit in KB
Yes, ‘Staging Space Limit in KB’ is the name of the actual Registry entry. No, you can not enter the size in MB or GB, just KB. And remember, 1024KB = 1MB, 1024MB = 1GB, or 1048576KB = 1GB. Don’t forget the fact that staging begins to die out at 60% full. So find the largest file in the DFS share, and double that for the staging size. After changing that registry entry, you will need to restart the File Replication Service service, or reboot the server. You will need to edit this on all servers.
The steps to set the replication priority higher than European Swallow slow, requires navigating the myriad windows for the properties for the DFS console. Remember, all of the information you can easily find today is for the R2 release of Win Server 2003, not older versions.
- Open the DFS console, expand the group you want to edit, and then right-click on the share and choose Properties.
- From the properties window, click on the Replication tab, and then click the Customize button next to the topography type.
- This opens the topography window. From here, select one of the servers from the Connections area and click on the Priorities button.
- This opens yet another window, which shows a list of all of the other servers that connect to the server you just chose. Now you select a server, select a priority from the drop-down box, and then click Change. You must click Change, OK will not work. You will need to make this change for every server listed.
- Repeat step 4 for each server as the destination.
Once replication is complete, you can then enable the new target. You can either leave both enabled, or disable the old one after enabling the new one. However, if people map drives to these targets, it is best to have them reboot after disabling a target.
Removing an old server (target) from a share (root):
Once again, I like to look at how it would work, logically. 1) Open the DFS console, select the group and share, and then select the old server to remove. 2) Disable the target (old server). 3) Delete the target. If there were replications still waiting, or in process, then DFS should alert me, and allow me to not delete the target at that time. If so, then I would be able to try again later. When the old server was finally deleted, I could begin cleaning it up, removing files, or generally preparing it for removal.
Well, if I did that, I would quickly find files missing from the new server. Why, because even though DFS was turned off, and this is supposed to turn off File Replication, it doesn’t really. I don’t know how long it takes for that delete to propagate through the system, but 30 minutes is not enough. If you go to the old server and start deleting things, the new server will receive those delete commands through FRS and start deleting them. So, to fix this you have to either restart the File Replication Service service, or reboot the new server.
Testing with temporary shares:
If you decide to test how DFS and FRS would work on the new servers, you are going to have a number of headaches in store. Whenever you remove a target for a server, the registry entries for that target are not really removed. They still exist, and can cause worlds of problems with FRS, and even cause FRS to fail out. Yep, non-enabled targets that shouldn’t be replicating will cause problems with the replication service.
So, to actually remove something from File Replication Service, you have to dive back into the registry. There are two types of locations you need to work with. First is the Replica Sets, which is the information about what folders are replicated, replica name and type. These are under:
Each set with have it’s own unique Hex value for the key name. Then the rest of the information is under sub-keys for each one. The other type of location is the Cumulative Replica Sets. This seems to be information about how many replica targets there are, and therefore if replication should be started for that share. It is found at:
Parameters\Cumulative Replica Sets\
It uses the same Hex value for each key name. You will need to delete the entries for each unused DFS share from each of these locations. You will, of course, need to stop the FRS service, and make sure that not only the current control set is changed, but any other ControlSet### sets.
Have fun with it.
A new(er) post about DFS can be found in my DFS Questions and Answers.