Windows Server

TK · Guest

I am learning more by the minute about DFS and Frs but it seems in that
process I have somehow shot myself in the foot.
I set up a Root with links pointing to the main server and secondary server
and enabled replication. I then realized that the way I had done it was not
going to be good because the UNC was going to be clumsy. So I deleted the
links and Root. The problem is that replication had already begun. Now one
of the folders on the secondary server which was being replicated cannot be
deleted. I get an error which says it cannot be deleted because "the network
location cannot be reached. For more information about Network
troubleshooting, see Windows Help."
What have I done and how can I undo it? The share it created on the main
server was able to be deleted without incident so what has locked this
folder? It had begun replicating one other folder too, but that one I was
able to delete.
Thanks in advance.
TK

Jill Zoeller [MSFT] · Guest

I can't quite tell why you can't delete the folder or what kind of folder
you want to delete. Is it a DFS root that you are trying to delete? If so, I
refer people to the KB below all the time, and this usually works.

HOW TO: Force Deletion of DFS Configuration Information 224384

http://support.microsoft.com/?id=224384

--
This posting is provided "AS IS" with no warranties, and confers no rights.

"TK" <sprdthword@hotmail.com> wrote in message
news:%23$ZtLsJrEHA.4004@TK2MSFTNGP10.phx.gbl...

TK · Guest

Jill,

Thanks for the response. I checked that link but it does not fit my
situation. The only setting in the AD was the one legitimate root that I
have which is working fine.

I'll tell you what I did as long as you promise not to laugh (well, at least
not too hard) and remember I'm learning and one sure way to do that is
through our mistakes.

This is what I did - at least to the best of my recollection:

I created a Domain DFS Root called Students because that corresponds to an
existing shared folder by that name.

Then I went to create a link. This I named 2005 because that corresponds to
an existing folder in the Share "Students". In the box where we set the
"path to target" I am pretty sure I put \\servername\Students.

I set up replication and all seemed fine.

Then I went to the Students folder and to my surprise I found a new folder
there with some weird numbered name. When I clicked on the existing 2005
folder it said it was not able to access the folder anymore. I then clicked
on the new folder and it had the contents of the 2005 folder.

I waited a while and when replication began to kick in I checked on the
second server and I had the shared folder "Students" there. Inside that
folder was one named 2005 but when I clicked on it I got the same message as
on the original server - no access. The weird numbered folder had not
replicated, but one of the other subfolders in the original Students folder
had - its name is 2006. I could click on it fine and see the contents that
had replicated to that point.

Figuring something was definitely wrong - I stopped replication. I went back
to the original server and deleted the link and root so I could start over
and do the whole thing right (in the meantime I had done a bunch more
research and reading about DFS and FRS). I went to the second server and was
able to delete the 2006 folder and its contents (which was only about half
the contents of the original 2006 folder), but the 2005 folder will not let
me delete it and I get the message I shared in the original post - "Cannot
delete folder 2005. The network location cannot be reached. For more
information about Network troubleshooting, see Windows Help."

So there you have it. Can you help me get rid of this unwanted folder.
Everything on the original server is fine - all folders and files are in
tact since I got rid of replication before deleting anything on the second
server.

I look forward to any help you can give. I have searched the Net high and
low but to no avail.

Thanks in advance,

TK

"Jill Zoeller [MSFT]" <jillz@online.microsoft.com> wrote in message
news:%23k20p7UrEHA.1036@TK2MSFTNGP10.phx.gbl...

Jill Zoeller [MSFT] · Guest

Sorry for the delay in responding, I've been on vacation.

The weird numbered folder you're seeing is likely a link folder that DFS had
to rename because it wasn't empty (does it look like
DFS.cf13c05f-5c10-4879-9acb-04ced8f46c7aLinkname).

Here's the procedure for deleting the folder; do you have a copy of Dfsutil?
It's a support tool and is available to download in the MS Download Center.

First, run:
dfsutil /viewdfsdirs:driveletter: /verbose

Identify the link folder whose reparse point you want to remove and then use
the following command:

fsutil reparsepoint delete linkfolderpath

If you want to read up on why this happened, see the section "Root Folder
and Link Folder Creation Process" in the DFS Technical Reference at
http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/techref/en-us/Default.asp?url=/resources/documentation/windowsServ/2003/all/techref/en-us/w2k3tr_dfs_how.asp

I need to run to a meeting now; I want to re-read your post to see if I can
give you some more insight about why DFS is behaving the way it is.

--
This posting is provided "AS IS" with no warranties, and confers no rights.

"TK" <sprdthword@hotmail.com> wrote in message
news:eU5nVRhrEHA.4008@TK2MSFTNGP14.phx.gbl...

TK · Guest

Jill,
That's exactly what it looked like and everything you said worked. Thanks a
million!
I followed your advice and read the technical reference at the site you
linked - it was excellent and I think shed a whole new light on what I did
and what I now need to do. If it's OK - I'm going to run by you what I did
and what I think I need to do now so you can verify it for me and hopefully
this will help anyone else who is new to DFS and FRS.
What I Did:
As mentioned before I have two servers - both are set up as DC's and one is
running Enterprise edition and one is running Standard edition of Server
2003.
I have several shared folders on the D drive of the "main" server (the
enterprise edition one) which I am trying to get fault tolerance and load
balancing on.
One is called Profiles - we use roaming profiles in a totally Windows XP Pro
environment (approx. 40 computers)
We have been running one of these servers for about 2 years now and the
other for only about a year or less.
When I first set up the DFS I did it on the main server and I set the
namespace to be the already existing, shared folder - Profiles. Then I set
up a root target on the second server with the same name and instituted FRS.
That all seemed to work fine and all the profiles replicated.
Then I went to set up one of the other shared folders from the main server -
Students (under this share are sub folders and in those sub folders are the
actual student sub folders) but it would not let me create the root target
on the secondary server. I figured out that was because it was the Standard
edition of Server 2003 and I can only have one root on it.
This is where everything stands right now - only the Profiles root and
target has been created.

What I Think I Need To Do:
Start from scratch - deleting the existing root and target (unless I can
safely rename the root to a folder which does not exist - something like
"Main").
Create a new root called "Main" and make the root target the same on the
second server.
Create links to the existing shared folders - Profiles, Students, Staff,
etc. and institute FRS on all links.
This will create the "Main" folder on the second server and copy all the
link folders and sub folders to the second server - right?
Then in the AD I need to change the path for the roaming profiles from
\\server\profiles to \\domainname\Main\profiles
I will also need to change all the Home Directory paths the same way
When it creates the share "Students" on the second server and copies all sub
folders over, will all the permissions copy over the same way or will I need
to change the permissions? I didn't see anything in that article about how
DFS and FRS treats folder permissions.
Once all this takes place - if the main server should go down for any reason
whatsoever, everyone should still be able to log on and have full access to
all their folders/files - right?
Sorry this has turned out to be more of a book than a question but since we
already had our main server hard drive crash some time ago, and since that
was a royal pain in the neck, I really need to get this right.
Thanks in advance for all your help.
TK

"Jill Zoeller [MSFT]" <jillz@online.microsoft.com> wrote in message
news:uffI51TsEHA.1308@tk2msftngp13.phx.gbl...

Jill Zoeller [MSFT] · Guest

I'm glad this fixed the problem! It sounds like you're getting the hang of
this :-)

You are right that using an existing shared folder for the DFS root wasn't
the best way to go. DFS does its own thing below that root and you really
should avoid putting data in there.

Your plan for creating a root called "Main" is a good one. When you first
create the root, you'll specify a shared folder (it must be called Main) and
then when you add a second root target, you'll specify another shared folder
called Main on your second server. At this point you can create a link that
points to a shared folder (repeat as necessary).

The FRS part is where it gets tricky. I highly recommend that you review the
FRS content in the Designing and Deploying File Servers chapter up on
www.microsoft.com/dfs. You'll want to ensure that your staging folder and
USN journal are sized appropriately; otherwise you will likely have
problems. You'll also want to consider where your staging folder is located
(ideally on a separate volume than your shared folders.) You'll want to
ensure that your servers are running the latest FRS hotfix described at
http://support.microsoft.com/?id=823230 (this requires a free call to PSS).
This will ensure that FRS has all the latest bug fixes and enhancements.
(For example, the default USN journal size is increased from 128 MB to 512
MB--and fyi the file server chapter states 512 is the default but the final
product ended up at 128.)

Next, you should review the DFS FAQ
(http://www.microsoft.com/windowsserver2003/techinfo/overview/dfsfaq.mspx)
to read about why using FRS with roaming profiles could lead to data loss.
Here is a quote from the FAQ: "Roaming profiles that are replicated via FRS
to multiple link targets might lead to data loss (due to FRS conflict
resolution) if a user logs in to multiple workstations, makes changes to the
same file on different targets, and then logs off both workstations." If
users will not be logged onto multiple workstations concurrently, then you
will not encounter the conflict resolution issue. It's very important to
understand the other scenarios in which FRS is recommended--these are
described in the File Server chapter I mentioned earlier. And finally, if I
haven't mentioned this before, you'll really want to check out Ultrasound as
a monitoring tool--it's quite sophisticated yet easy to use. It's available
on
http://www.microsoft.com/downloads/details.aspx?FamilyID=61acb9b9-c354-4f98-a823-24cc0da73b50&DisplayLang=en

After you've done your FRS research and are ready to get started, you'll
first need to add a second link target to each of your links. What this
means is that you'll need to create shared folders for Profiles, Students,
Staff, etc., on the second server. Make sure the permissions on these empty
shared folders are identical to the main shared folders--FRS doesn't
replicate shared folder permissions or the top-level folder's permissions.
(FRS will copy permissions for all files and subfolders, though.) These
folders can be empty--do not attempt to copy the data from the main server
into these folders or you'll cause FRS all kinds of grief. Next, for each
link, add a link target and specify the empty shared folder. When you do
this, you'll be asked whether you want to enable replication, and you'll
choose Yes. Next you'll be prompted to choose an initial master, which
should be the main server where the shared folder data is stored. (Initial
masters only apply during initial replication and recovery procedures.)
You'll next choose a topology and I believe that's it.

There will be some delay before replication actually begins. FRS has to do
some stuff in AD and the actual replication process is not as fast as file
copying. You might want to stagger when you enable replication--e.g., enable
replication on one link, wait for everything to be replicated, then enable
replication on the next link, and so forth.

Also, the file server chapter gives deployment procedures and job aids for
enabling replication. The chapter itself and the job aids can be downloaded
from
http://www.microsoft.com/downloads/details.aspx?FamilyID=55a30345-b54f-4806-9715-a953ceb19287&DisplayLang=en.

Hope this helps!
--
This posting is provided "AS IS" with no warranties, and confers no rights.

"TK" <sprdthword@hotmail.com> wrote in message
news:%234S1q8csEHA.3076@TK2MSFTNGP09.phx.gbl...

TK · Guest

Jill,
I was away for a few day so I hope you get this.
Everything you have given me has been a great help and I hope it will be for
others as well.
Thanks again and it is helpful people like you who make these forums so
necessary and profitable.
TK

"Jill Zoeller [MSFT]" <jillz@online.microsoft.com> wrote in message
news:%23f7tkqgsEHA.2128@TK2MSFTNGP11.phx.gbl...

	Windows Server Forum Index -> DFS and FRS	All times are GMT
Page 1 of 1