Using replicated file services with domain namespaces and roaming user profiles?

Based on amazing feedback I got on other related questions I have decided to be brave and try something different, but I am not sure if it can be done. hoping someone has done this and has some insights :-)
Consider the following scenario.
All servers are on the same LAN, through the same Cisco switch and using gigbit ethernet. FYI!
We have a single 2008 R2 file server that hosts all of our department folders/files (e drive) and all of our user profile and user home folders (d drive).
The department folders are shared as 'groups' on the e: drive of that server and set via a logon script (mapping w: to server name \\fileserver\groups share), but there is a domain namespace as well (not sure why since it is not needed).
The user share (for roaming profile) on the d: drive of that server utilizes a domain namespace and that is how each profile is setup, i.e. the profile path and home folder path for each user account in AD points to the domain namespace (\\\users\username\profile).
I have two new 2012 servers (physical) built and ready to go with all the required roles, etc.
Initially I was merely going to robocopy the data over for the groups share to one of the new 2012 servers (server A) and then repoint the logon script mapping for users which would work fine once they log off and back on.
I was also going to robocopy the users share to a new 2012 server (server B), add it to the existing namespace (right now only hosted by the older 2008 R2 server) and then remove the 2008 r2 existing server from the namespace and that should work fine since the namespace continues (all files are on the new server B and it takes over hosting the namespace) and since the profiles for user accounts in AD point to the domain namespace (\\\users\username\profile) they wouldn't even notice.
Now the fun/confusing part. I realized that rather than using the two new 2012 servers to each take on one of the shares (groups and users) I could add both of them to both namespaces and then enable replication between them. In theory I would thus have some redundancy if one server goes down then the namespace and associated files still continue. For the groups (department folders/files) there is usually not that much change in the data so standard dfsr replication should handle it, but the users profile might be another story. What happens if a user logs into their PC and downloads their profile from server A, but then logs off saving the profile back to server A (can I even control which one they save to - affinity/cost??) and logs into another PC before server A and server B have a chance to replicate, but server A crashes. Now they are logging into the next PC using only the older profile from server B (the one that still hosts the namespace)? Also what happens when server A comes back online? Or is it better to make a Windows cluster (using the local space on each server - they have identical disks/raid and sizes - from the two servers and then add the cluster to the namespace to avoid the replication issue?
Laszlo DenesAsked:
Who is Participating?

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

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.

Cliff GaliherCommented:
You *will* have replication issues with your plan.  Even if a server doesn't crash.  You will have targeting issues and end up with file conflicts.  Bad things happen.  It is a common mistake I see.  If you were to do this, you'd want only *one* target to be live at a time.  The replication itself isn't the problem, but the fact that you'd have some machines connecting to target A and others to target B.  That does make a failover scenario a manual affair.

As for a cluster, that is the way to solve the problem.  BUT!!!  Both machines having the same local storage configuration isn't going to help. File clusters in 2012(R2) needs *shared* storage.  Local storage cannot be used.  So given your current configuration, you don't have what you need to do a cluster.

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:
Thank you Cliff I appreciate that... Isn't there some way( I recall reading something like it) for me to control which machine the users go to first... affinity in dfs or setting the cost...
Cliff GaliherCommented:
No. That doesn't work the way you think it does. You'd still end up with a percentage of connections going to each server... It just would no longer be 50/50. So bad things still happen.
IT Pros Agree: AI and Machine Learning Key

We’d all like to think our company’s data is well protected, but when you ask IT professionals they admit the data probably is not as safe as it could be.

Laszlo DenesAuthor Commented:
I think your insights are on the mark Cliff, but (because I have to justify my decision to my superiors) I am going to request for additional input. Does anyone have anything to add to the earlier observations. Please and thanks in advance of course.
David Johnson, CD, MVPOwnerCommented:
with roaming profiles you should ALSO use folder redirection with or without offline files.  Both should be using DSFR.  Even with just 1 server you should use DFSR as this future proofs things. i.e. want to upgrade servers.. add the new server, allow replication, remove old server.
Cliff GaliherCommented:
I think you swapped DFS-N and DFS-R.  You wouldn't ever use DFS-R for just one server (there would be no replicating.)   And while you might use DFS-R to do an actual migration, it usually wouldn't be left in place long term.  That is something you can deploy as part of the migration, but isn't something you need to use just to future proof.  DFS-N, however, would be something you'd want to use to future proof as you wouldn't have to update share names.

DFS-N and DFS-R are wholly separate technologies that happen to share the name "DFS."  But one can be deployed independent of the other.  I've deployed DFS-R to replicate normal (not DFS-N) shares.  I've used DFS-N without any replication, just to standardize naming.  And yes, I've deployed both.

But for roaming profiles, both should never be used simultaneously, and I'd even argue that DFS-R is a rather expensive and painstaking way to deal with a storage failure since any failover would have to be manual.  A real cluster, or good backups, are often a better alternative.  If you are using virtualization, restoring  VM with your shares and profiles is going to be easier than seeing if the outage occurred during a replication cycle, dealing with partial syncs, repointing the DFS-N namespace, and making sure you don't introduce more problems.

That's my opinion. YMMV.
David Johnson, CD, MVPOwnerCommented:
I was referring to DFS-N.  I agree that clustered shared storage is a best use case option
Departmental shares should be mapped in via your DFS Namespace. This will make migrations easier in the future, including now. If you just change the drive mappings via login script, you could have lots of references back to the old server name. Getting to a permanent UNC path via DFS Namespace mitigates this.

If you use roaming profiles, you should use redirected folders to minimize the amount of data that needs to be moved during logon and logoff events.

I would not leave two DFS Namespace targets active for the same link. Leave just 1 active at a time, and manually switch if you have a failure or need to do maintenance. This eliminates the file locking/corruption issues that you could experience when you combine DFS Namespace with DFS Replication.

If you want something hands off failover, you need a Windows fileserver failover cluster.
Laszlo DenesAuthor Commented:
Thanks everyone really appreciate it. Will keep both namespaces (groups users), copy over data from old server to new server(s), add new servers into existing namespace + make logon script change as needed and then remove the old server from the namespaces... that way everything continues... but on 2 servers instead of only one which means a lot more space... but will also consider the option (later on) of getting some shared storage to build a cluster for failover.
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.