Is there a way to publish an existing folder to the namespace?

So I recently began managing an existing DFS replication server.  The current configuration is:

Server 1- DC, DFSR, File Server
Server 2- DC, DSFR, File Server

I added a new sever, server 3, and it is just DFSR and a file server.  I was able to add the replication folders and replication works fine.  I did notice that the replication folders are not published.  I am a novice to DFS, but from what I understand, you do not need to publish a folder to the namespace if it is on a DC.  However, I am getting rid of DFSR on the DC's and need to publish the folders.  When I try to do this, I get an error stating that the folder already exists and I can not get it to publish to the namespace.

Is there a way to publish an existing folder to the namespace?
Glen KrinskySystems AdministratorAsked:
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:
DFS-N and DFS-R are mostly unrelated technologies. You don't need to implement them together. You seem to be confusing the two, given your description.
Glen KrinskySystems AdministratorAuthor Commented:
No, I get it.  But once DFSR is removed from the DC's, the replicated folders will have to be published to the namespace so they visible to the users correct?

"To make replicated folders available to users, you must share them and, optionally, publish them in an existing namespace."
Cliff GaliherCommented:
"and optionally"

You can share replicated folders without putting them in DFS-N.

If you want the unified names pace that DFS-N provides, you only publish that folder name once. You then define multiple targets.

Be very cautious here!!! Mixing DFS-N and DFS-R improperly can result in version conflicts!  Don't try to make a poor man's cluster by combining these technologies.
Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

Glen KrinskySystems AdministratorAuthor Commented:
Ok, understood.  Can I remove the published folder and then re-publish it to ensure the versions are the same?
Cliff GaliherCommented:
I still don't think you are quite understanding me.  DFS-N and DFS-R are *completely* separate.

Let's say you have two servers.  You can replicate \\server1\finance and \\server2\finance using DFS-R with not any DFS-N involved.  Yay.  Those files are shared, but not published.  Thus publishing is optional.

Now, let's look at DFS-N without DFS-R.

A very large company ended up with two servers for files because they have so many clients.  One server holds their "residential" client files and later, as they got bigger, they added a second server to hold "commercial" clients.  Instead of making users memorize server names, they use DFS-N.

Users can go to \\company\customer-data\commercial and DFS-N points the client (discreetly) to \\server2\customer-data
Users can go to \\company\customer-data\residential and DFS-N points the client (discreetly) to \\server1\customer-data

Users see a "unified" namespace, but the data is spread across many servers.  That's why you'd use DFS-N.

Now...let's look at combining them.

You take \\server1\finance and replicate it to \\server2\finance using DFS-R.

You "publish" \\company\data\finance are only doing this once...via DFS-N.
You set multiple targets (this isn't publishing) so users going to \\company\data\finance get pointed/redirected (discreetly) to \\server1\finance *or* \\server2\finance ...because of how DFS-N distributes targets (there is some complex intelligence here...)

Now.  User one opens \\company\data\finance\cool-excel-file.xlsx ...and DFS-N redirects them to server1.  They are now actually working on \\server1\finance\cool-excel.xlsx   ...and that's fine.

A second user comes alone and opens \\company\data\finance\cool-excel-file.xlsx ....and DFS-N redirects them to servers.  They are now actually working on \\server2\finance\cool-excel.xlsx  ...and here's the problem   Server2 is *UNAWARE* another user has the file open on server1!  File locks are per-server.  *SO* ....user1 makes some changes.  user2 makes different changes.  They both hit save, maybe even hours apart...and DFS-R can no longer know which file is the "right" file to replicate.  VERSION CONFLICT!!!

You *have* to manually choose the "right" file and one of those users *will* lose data.  Unpublishing and republishing a namespace will not address this issue.  Namespaces have nothing to *do* with this issue.  Yes, you could stop replicating and start replicating from scratch...which is overkill...because now you basically did choose which file "wins" (by choosing the entire server, and creating a ton of replication traffic), but one of those users will *Still* lose the data from the "losing" server/file.

Yes, domain controllers use DFS in this way.  But  you usually don't have admins on multiple DC's trying to edit the same file near the same time (say a group policy) that goes against every change-management best practice *ever.*  So for sysvol and netlogon replication, it works.  And there *are* scenarios and workflows that the two can be combined.  I'm not saying definitely don't do it.  I'm saying BE CAUTIOUS!  Given your previous use of terminology, I got the distinct feeling you weren't overly familiar with how these two technologies interact and I've seen too many "poor man's clusters" gone seemed worth the warning.

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
Glen KrinskySystems AdministratorAuthor Commented:
Ok.  So if I am understanding you correctly...

Server1\sales is replicated with server2\sales.  User makes a change in server2\sales, it replicates to server1\sales, no problem.  Since its the "same folder" it doesn't need to be in the namespace.  However, if I have server1\sales\public and server2\sales\private and want them to appear as server\sales I would publish them to the namespace and they would appear as a single location.

If this is the case, then publishing in m y environment is not needed as DFSR keeps the files replicated properly anyway.
Cliff GaliherCommented:
Something like that.
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.