DFS namespace setup for new file server

I am about to bring on two new file servers (2012) to replace the existing one (2008 R2) and wanted to make sure I do it right for the DFS namespace.
We are using the DF
There are two critical shared items that I need to take into consideration on the existing file server.
A repository of all of our department folders on e: and on d: all user home directories (with profile folder for profile path and data folder for home folder).
My plan was to move each one of those to a separate folder.
The department folders on e: are referenced by a logon script so once I have robo copied those over I could just adjust the logon script to point to the new server.
The profile path to the user home directories is setup using the DFS namespace as they are \\domainname\users\username\profile and for the home folder \\domainname\users\username\data.
It's been ages since I worked with DFS namespace so my question is this... Can I just robo copy all the data over to the new server and THEN add that new server (the one for the user profiles etc.) to the existing namespace on the current file server and eventually (not sure how long it takes for the two servers to be synced) remove the old one, thus making it seamless for users. Although I will try to limit the number of users that need to logon/logoff during that time. Will that work?
Laszlo DenesAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Keelyn HenningIT System AdministratorCommented:
I would use FreeFileSync over RoboCopy. You can view what files are different and sync them must faster. I know this doesn't answer your question but I was very happy when I switched so I thought I would share.
1
Laszlo DenesAuthor Commented:
Will take at look at FreeFileSync ... thanks for that...
Still need input for original question... :-)
0
Keelyn HenningIT System AdministratorCommented:
The plan you have set up with work. As long as you keep the user path to the data with the existing server until your new servers are 100% linked you should be good. I would use FreeFileSync to get your initial setup going and than on the day you are ready, perform another FreeFileSync  once everyone is logged off and than switch your path over to the new server.
0
Protecting & Securing Your Critical Data

Considering 93 percent of companies file for bankruptcy within 12 months of a disaster that blocked access to their data for 10 days or more, planning for the worst is just smart business. Learn how Acronis Backup integrates security at every stage

Keelyn HenningIT System AdministratorCommented:
Obviously keep your old server up and running just in case something goes wrong and you need to switch back quickly.
0
Laszlo DenesAuthor Commented:
Thanks for the feedback.
How can I tell if they are 100% linked/synced, etc. Is there an obvious place to check?
I might use FreeFileSync if I find enough time to test it with that product, because it worked with Robo and I completed testing... it also let me do one copy and then only changes.. obviously any copy program would need to maintain all the NTFS permissions since the user folders have those set per user no inheritance and then the main share (users$) is just everyone full access share permissions.
So copy over all data from existing to new file server >> join new to old file server name space (at which point the name of the server is not relevant since it just point to the namespace since we have it setup in their profiles to go to \\domainname\users\username\data and not \\SPECIFIC SERVERNAME\users\username\data) >> make sure they are in sync/linked (so technically both will be serving users who log in like a fail over scenario) and then remove (after a few days) the old file server?
0
Laszlo DenesAuthor Commented:
checked out FreeFileSync and when I tried it ... looked at documentation ...it does not copy NTFS permissions over so it is no good for me as Robo Copy does... earlier question (repeated below) still open... cheers

So copy over all data from existing to new file server >> join new to old file server name space (at which point the name of the server is not relevant since it just point to the namespace since we have it setup in their profiles to go to \\domainname\users\username\data and not \\SPECIFIC SERVERNAME\users\username\data) >> make sure they are in sync/linked (so technically both will be serving users who log in like a fail over scenario) and then remove (after a few days) the old file server?
1
Keelyn HenningIT System AdministratorCommented:
I'm not sure what documentation you were looking at but FreeFileSync does carry over NTFS permissions.

https://www.freefilesync.org/faq.php

Which features make FreeFileSync unique?
  • Copy NTFS extended attributes (compressed, encrypted, sparse)
  • Copy NTFS security permissions
  • Copy NTFS Alternate Data Streams
1
Laszlo DenesAuthor Commented:
Care to point to the section I need to look at to make sure they do as I did not see that under options (compare, filter, sync).
I mapped 2 drives - one to my file server source 2008 R2 and one to my file server target 2012 - and ran the utility. It did copy over everything and fast, but none of the NTFS permission security groups and settings were there and they were replaced with default permissions on the new server.
0
Keelyn HenningIT System AdministratorCommented:
They are listed on this page: https://www.freefilesync.org/faq.php#features
0
Laszlo DenesAuthor Commented:
LOL... I saw that but it did not do it for me... anyway doesn't matter I have robo copy and that is tested by us already. Cheers though...
0
Laszlo DenesAuthor Commented:
One more question... after I copy everything with Robocopy and install DFS on the new server do I share out the "users" share (shared with everyone FC and then NTFS per folder on existing file server) on the new server before I add it to the existing DFS namespace, because 'share' permissions are not copied by Robocopy on NTFS and if the root folder is not shared on the new server (2012) then the roaming user profiles will not work when I turn off the existing 2008 server, even if the 2012 is part of the namespace and has sync'd. Thoughts?
1
Craig BeckCommented:
Is this a new DFS?
0
Laszlo DenesAuthor Commented:
No existing on 2008 R2... I am adding a new 2012 server to the existing namespace so I can (after I copy all data over, install DFS on 2012) decommission the 2008 R2 server without impacting user logon with roaming profile...
0
Craig BeckCommented:
So why not just allow DFS replication to copy the data over?... Or am I missing something?
0
kevinhsiehCommented:
You need to setup new shares on the new server(s) . This is required so that you can set them up as targets in the existing DFS Namespace. Note, that when new targets get added, they are automatically active. You need to disable then so clients don't start using the new servers until you are ready. After final sync of a share, disable the old target and enable the new one.

If your old servers also have the DFS Namespace, you will need to make so.e other servers namespace servers before you retire the old ones. Personally, I put the DFS Namespace root shares on my domain controllers.

Before or after completely retiring the old servers, make sure that all references to the old servers are deleted from the DFS Namespace.
0
Laszlo DenesAuthor Commented:
Craig - because I was under the impression that if the files (about 220GB) are copied over by the servers i.e. synced then it will take much longer than robocopy...
Kevin - just to make sure I got this right... so I install DFS on the new server... copy over all the data... make sure  that the new server has the same structure and same shares, e.g. users\user folders... with everyone Change or FC for sharing and then ntfs permissions per user folder --> and that is the way it is setup on the existing server right now... then I add the new 2012 server (with identical data and shares) to the existing namespace on the 2008 and disable it... on day of switch over I do final robocopy or sync, then enable new server 2012 and disable the 2008 existing one... presumably the new 2012 will then be the holder of the namespace alone... done... sound about right?
0
kevinhsiehCommented:
We may or may not be talking about the same things. The DFS Namespace service needs to be running somewhere. It doesn't need to be running on the file servers. Back when I stated with DFS Namespace, it HAD to be installed on domain controllers if you wanted to be able to use something like \\domainname\users\ . In your case, Users is the DFS Namespace Root share. I probably would not install the DFS Namespace service on the file server, because you would probably like have something like \\domainname\users pointing to \\newserver\users as the new DFS Namespace target. The issue is that you would have two different shares called users on the same server, which you can't do.

I am looking at your example paths, \\domainname\users\username\data, and my guess is that it isn't actually correct. For a DFS Namespace to work, you need a share on \\SomeDFS-Namescape-Server\users, and then there would be a junction point to some target share. The issue is that you would need to create a DFS Link for each username in your example, which would be PITA. Here's what I do, maybe you do something similar but just didn't post it this way publicly?

"\\domainname\DFS\users\%username%\data" as the user home directory. "DFS" is the Namespace root share. There is a folder link to "users", which points to "\\oldserver\users". I would add a new link to "\\newserver\users$". I like to hide all of my shares, because I always want users and sys admins to use the DFS Namespace paths. The link to "newserver\users$" needs to be disabled until the cutover.

The issue of which servers holds the DFS Namspace shares needs to be addressed. As I said earlier, mine are on domain controllers as that is where it had to be with Windows 2003. All namespace servers should be active at all the time. There is no way to make one inactive. Namespace servers have nothing to do with which server(s) have active targets and are actively sharing data. Here's an analogy: a DNS server is to a web server as a DFS Namspace Server is to a file server. You don't go moving DNS servers because you change web servers for your web site.

Does this help, or did I just make it more complicated?
0
Craig BeckCommented:
I think it would be way easier to simply add the new servers to the existing DFS namespace and just let it replicate, then drop the old server when you're ready.  No issue with file perms, nothing to change from the client side, etc...

If the servers are all on the same site, DFSR shouldn't take too long to copy 220GB to the new servers, and it would be quicker than Robocopy if you're doing it over a WAN anyway.
0
Laszlo DenesAuthor Commented:
Okay now I am confused...
See picture of our setup right now... only the users namespace is of concern and we only have one server FS1 that is the current 2008 server. Maybe I should (rather than coming up with scenarios) just ask what the critical steps are to make sure that the new server becomes part of the namespace, obtains a full copy of the users folder (with NTFS permissions and share permissions) from the old server and maintains the namespace so I can then turn off the existing 2008 server? Really appreciate a high level step by step as I sincerely thought it would become clear, but it has just become more confusing. Sorry and thanks so much.
The reason the namespace is on the file server is because it was done before I took over and it might be wrong, but since we are also dropping in new DC soon... it would be one less thing to worry about if it stays on the file server (the new one).dfs.jpg
0
kevinhsiehCommented:
Can you post a screenshot of the Namespace tab?

My guess is that whoever setup the system did something very...creative. It is possible that you don't have any Namespace links, and that the DFS Root share contains all of the actual data...which is not how it is supposed to work.

If that is the case, you add the new server as a Namespace Server at the time of cutover, and remove the old server. You lose the ability to have multiple potential file server targets, and the regular methods of using HA such as DFS-R are eliminated.
0
Laszlo DenesAuthor Commented:
I know what you mean because the namespace tab is empty... no folders... The person who set it up before me had no clue, but was too proud (I guess) to ask others. Any idea how I can fix this... any chance I can fix this during cutover on the new 2012 server... :-(
dfs2.jpg
0
Laszlo DenesAuthor Commented:
Okay so Kevin you are right and I have no idea how it could have worked in the past, except it did even though the are no Namespace links on the file server, nor anywhere else. I created a new namespace (properly) and added two servers to it, tested the replication and it worked pretty good as it replicated 8GB in less than 50 min so I would like to use it to move the 200 GB over to the new file server since they can both exist and copy data and still work for uses. However, how do I overcome the fact that I do not have a namespace link for it. What is the impact for replication and assuming replication still work, for when I remove the old server from the namespace. Will the new one (since there is no namespace link to hold the info) still continue to work. OR can I just copy over all the data with Robocopy, delete the namespace on the existing file server that is not setup right, recreate the exact namespace on the new file server so it does not change the UNC for users when they log in as their profile points to \\domainname\users\username\profile and add back the copied over data. Would that even work... i.e. can I recreate the same namespace or is their some hidden security identifier (GUID or SID) that would prevent this... thoughts...
0
kevinhsiehCommented:
Honestly, I like robocopy more than DFS-R for this. With robocopy, you know that you have all the files. Any exceptions or errors are in the summary. It's also faster than DFS-R for initial sync, and you don't have to worry about the service state, or database state. You would also need to cleanup the DFSRprivate hidden folder, which you should need to do anyway now that you have set it up.

As far as fixing the DFS Namespace, you would need to change the UNC path that is used, or create a link for every user. I am not really a fan of either idea. I see no reason why  after the final robocopy that you wouldn't just add the new server as a namespace server using the Users share, and then remove the original server as a DFS Namespace server. That should work. I don't see any reason why it wouldn't.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Laszlo DenesAuthor Commented:
okay robocopy it is... lol
so what is the impact of not having a dfsroot share folder (there was none on the fileserver, not the DC nor any other server) with the namespace link for the users and no namespace link under dfs?
0
kevinhsiehCommented:
What you have is that the Namespace root share still exists. It currently exists on \\oldserver\users . It functions like a regular share. You normally would have 0 bytes inside the folder as seen by the filesystem, as it would only have folders and junction points to the real shares. In your case, you don't have junction points, but you have lots of directories and files. That's okay. Not how is was designed to be used, but okay as long as you only plan to have 1 server  holding the content.
0
Craig BeckCommented:
If you're copying the data from the existing namespace to two servers you'll need to use DFSR between the two new boxes anyway so you might as well just do it now. It's safer.
0
Laszlo DenesAuthor Commented:
understood... but what happens, considering the current setup, if I want to add another server (very likely for redundancy) in the near future?
With DFS (if I make it replication) it copies it cover and knows about the content as it is DFS doing the copying... but with robocopy would I still do replication or just add the server (new) to the namespace of the old server once all the data has been copied and then remove the old server... I ask because I tried that earlier (no replication) and it after the warning (if no other server the namespace will get deleted) it deleted the entire namespace... even though I was showing two servers and only deleted one... I also tried it with two namespace servers (each having copied data by robocopy not dfs) without namespace link and after it was all setup (no errors) and I when I tried to remove the old server it warned me that it wants to remove the namespace itself... which breaks everything...
0
kevinhsiehCommented:
If you want to have a second server with a copy of the files, you are in a sub-optimal position. Your option for switching the active server from one to another is to add the new server as a namespace server, and to remove the old one. DFS-R would be the correct technology choice if you plan to do this.

Of course, what is the goal of doing so? Would it be another VM using different storage (maybe off site)? If not, you can always just disconnect VHDX/VMDK from old server and attach to new server if the concern is with the file server OS. I had to do that once in the middle of the day. Fortunately I was using DFS Namespace, so I could attach the VHDX/VMDK to a new server, adjust the DFS Namespace link targets to the new server, and everything worked again. Clients didn't even need to log out.

Can you post screenshots of the DFS Namespace management to show what you're doing to cause the issues? I know that I have accidentally deleted the entire namespace instead of deleting just a link, but you don't have any links, so I don't know that would happen. The UI isn't always the most intuitive.
0
Laszlo DenesAuthor Commented:
BTW thanks to both of you for all the great insights and feedback... very grateful...
The goal is to add a new file server to the existing namespace and then decommission the existing file server without significant downtime. Everything is physical. Later (in a few months) I was planning to add an extra file server (virtual or physical) to have redundancy.

I think I figured out why it kept trying to delete the namespace. Instead or right clicking the namespace server itself and selecting delete .. I was clicking on the actions tab (far right) and that delete clearly means something else. It is fine I can in fact delete just one of the servers...
1
kevinhsiehCommented:
Basically every new installation should be virtual, especially a file server. Virtualization rights increase the incentives to go virtual...a second Windows VM license on the same host.
0
Laszlo DenesAuthor Commented:
Thanks everyone. I think I got it.
1
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Distributed File System Replication (DFSR)

From novice to tech pro — start learning today.