| Author |
Message |
Wendy Derman
Guest
|
 Posted:
Fri Dec 17, 2004 4:05 am Post subject:
Problem deleting target under domain DFS root |
|
|
Has anyone else seen this?
Occasionally I need to rename a target under our domain DFS root. Since it
doesn't appear that I can rename it, I create a new target and then delete
the old one (using the DFS admin tool).
The problem is, the old one sometimes doesn't go away completely. It will
occasionally show up in the list of subfolders under the DFS root, but as an
empty folder (using Windows Explorer - things look fine in the DFS admin tool
at this point). Other times it doesn't show up at all.
On investigating this, I did find an empty directory with the old name,
under the DFS share on one of the domain controllers (using Explorer, not DFS
admin). It did not show up in Explorer on either of the other 2 DCs. I went
ahead and deleted it directly from Explorer. Hopefully that wasn't a dumb
thing to do.
Any explanations as to why this happens? Am I doing something wrong when
deleting from the DFS admin tool? |
|
| Back to top |
|
 |
Richard Chinn [MSFT]
Guest
|
| Posted:
Wed Dec 22, 2004 8:42 am Post subject:
Re: Problem deleting target under domain DFS root |
|
|
I'm not a DFS expert, but one explanation might be that the reparse
point is not getting cleaned up on all the root servers. If you look
at the empty folder on your DFS root server, I think you'll find that
it is actually a reparse point (also known as a link or junction).
It's possible this isn't getting cleaned up properly.
I'm not sure of the mechanism used to clean up these reparse points.
It may be that DFS needs to do it when it finds information has
changed in Active Directory. If this is the case, the behavior you
are seeing could be due to AD replication latencies. You could try
waiting for a while to see if the "folder" is cleaned up
automatically. The amount of time you have to wait will be dependent
on your AD replication schedules. You could use the repadmin.exe tool
to speed things along.
--Richard
Please post FRS related questions to
microsoft.public.windows.server.dfs_frs and prefix the subject line
with "FRS:" to make it easier to spot. Note that FRS is used to
replicate SYSVOL on domain controllers and DFS root and link targets.
For additional FRS resources, please visit
http://www.microsoft.com/frs.
This posting is provided "AS IS" with no warranties, and confers no
rights.
On Thu, 16 Dec 2004 14:05:03 -0800, Wendy Derman
<WendyDerman@discussions.microsoft.com> wrote:
| Quote: | Has anyone else seen this?
Occasionally I need to rename a target under our domain DFS root. Since it
doesn't appear that I can rename it, I create a new target and then delete
the old one (using the DFS admin tool).
The problem is, the old one sometimes doesn't go away completely. It will
occasionally show up in the list of subfolders under the DFS root, but as an
empty folder (using Windows Explorer - things look fine in the DFS admin tool
at this point). Other times it doesn't show up at all.
On investigating this, I did find an empty directory with the old name,
under the DFS share on one of the domain controllers (using Explorer, not DFS
admin). It did not show up in Explorer on either of the other 2 DCs. I went
ahead and deleted it directly from Explorer. Hopefully that wasn't a dumb
thing to do.
Any explanations as to why this happens? Am I doing something wrong when
deleting from the DFS admin tool? |
|
|
| Back to top |
|
|
Wendy Derman
Guest
|
| Posted:
Wed Dec 22, 2004 9:43 pm Post subject:
Re: Problem deleting target under domain DFS root |
|
|
Thanks Richard!
I doubt very much that it's a replication issue. We only have 3 domain
controllers, all local, and I've seen these folders linger on for weeks after
I've deleted from DFS. No errors in Event Viewer, repadmin checks come back
clean, etc.
How do you tell that the folder is a reparse point rather than a normal
folder? Unfortunately I don't have an example to look at at the moment, but
next time it happens I'd like to check it out.
Also do you know if there is a way to report this to MS as a possible bug?
"Richard Chinn [MSFT]" wrote:
| Quote: | I'm not a DFS expert, but one explanation might be that the reparse
point is not getting cleaned up on all the root servers. If you look
at the empty folder on your DFS root server, I think you'll find that
it is actually a reparse point (also known as a link or junction).
It's possible this isn't getting cleaned up properly.
I'm not sure of the mechanism used to clean up these reparse points.
It may be that DFS needs to do it when it finds information has
changed in Active Directory. If this is the case, the behavior you
are seeing could be due to AD replication latencies. You could try
waiting for a while to see if the "folder" is cleaned up
automatically. The amount of time you have to wait will be dependent
on your AD replication schedules. You could use the repadmin.exe tool
to speed things along.
--Richard
Please post FRS related questions to
microsoft.public.windows.server.dfs_frs and prefix the subject line
with "FRS:" to make it easier to spot. Note that FRS is used to
replicate SYSVOL on domain controllers and DFS root and link targets.
For additional FRS resources, please visit
http://www.microsoft.com/frs.
This posting is provided "AS IS" with no warranties, and confers no
rights.
On Thu, 16 Dec 2004 14:05:03 -0800, Wendy Derman
WendyDerman@discussions.microsoft.com> wrote:
Has anyone else seen this?
Occasionally I need to rename a target under our domain DFS root. Since it
doesn't appear that I can rename it, I create a new target and then delete
the old one (using the DFS admin tool).
The problem is, the old one sometimes doesn't go away completely. It will
occasionally show up in the list of subfolders under the DFS root, but as an
empty folder (using Windows Explorer - things look fine in the DFS admin tool
at this point). Other times it doesn't show up at all.
On investigating this, I did find an empty directory with the old name,
under the DFS share on one of the domain controllers (using Explorer, not DFS
admin). It did not show up in Explorer on either of the other 2 DCs. I went
ahead and deleted it directly from Explorer. Hopefully that wasn't a dumb
thing to do.
Any explanations as to why this happens? Am I doing something wrong when
deleting from the DFS admin tool?
|
|
|
| Back to top |
|
|
Richard Chinn [MSFT]
Guest
|
| Posted:
Tue Dec 28, 2004 8:12 am Post subject:
Re: Problem deleting target under domain DFS root |
|
|
I can't recommend a tool in particular, but I believe if you do an
Internet search for "ntfs directory junctions" you should be able to
find a tool that will tell you the type of junction (reparse point) if
you specify a folder name / path.
With respect to filing a bug, I belive the way to do that is to open
up a support incident. They can follow up to determine if there is a
bug. The problem with this method is that you might get charged if
it's determined there's no bug. I'm not exactly sure what the details
are.
I checked with a DFS tester. He said that when you delete a link, the
DFS service on the server(s) that has the corresponding DFS root
target(s) will see the link deletion in AD, and it will then delete
the reparse point.
If you've created a multi-level link (e.g. LinkFolder\Link1 -- this
would be accessible as \\domain\root\LinkFolder\Link1), the DFS
service will delete the reparse point Link1 and then will try to
delete LinkFolder if there are no other files, folders, or reparse
points. If the folder isn't empty, it won't delete LinkFolder.
Also, every hour or so, the DFS service will retrieve the entire DFS
blob from AD and then match up links with reparse points. If it finds
any stray reparse points, it will delete them. If the folder that
contains the repase point is empty (but not the root) it will delete
that folder as well.
If you can reproduce the problem, go ahead and post the steps to this
newsgroup.
--Richard
Please post FRS related questions to
microsoft.public.windows.server.dfs_frs and prefix the subject line
with "FRS:" to make it easier to spot. Note that FRS is used to
replicate SYSVOL on domain controllers and DFS root and link targets.
For additional FRS resources, please visit
http://www.microsoft.com/frs.
This posting is provided "AS IS" with no warranties, and confers no
rights.
On Wed, 22 Dec 2004 07:43:07 -0800, Wendy Derman
<WendyDerman@discussions.microsoft.com> wrote:
| Quote: | Thanks Richard!
I doubt very much that it's a replication issue. We only have 3 domain
controllers, all local, and I've seen these folders linger on for weeks after
I've deleted from DFS. No errors in Event Viewer, repadmin checks come back
clean, etc.
How do you tell that the folder is a reparse point rather than a normal
folder? Unfortunately I don't have an example to look at at the moment, but
next time it happens I'd like to check it out.
Also do you know if there is a way to report this to MS as a possible bug?
"Richard Chinn [MSFT]" wrote:
I'm not a DFS expert, but one explanation might be that the reparse
point is not getting cleaned up on all the root servers. If you look
at the empty folder on your DFS root server, I think you'll find that
it is actually a reparse point (also known as a link or junction).
It's possible this isn't getting cleaned up properly.
I'm not sure of the mechanism used to clean up these reparse points.
It may be that DFS needs to do it when it finds information has
changed in Active Directory. If this is the case, the behavior you
are seeing could be due to AD replication latencies. You could try
waiting for a while to see if the "folder" is cleaned up
automatically. The amount of time you have to wait will be dependent
on your AD replication schedules. You could use the repadmin.exe tool
to speed things along.
--Richard
Please post FRS related questions to
microsoft.public.windows.server.dfs_frs and prefix the subject line
with "FRS:" to make it easier to spot. Note that FRS is used to
replicate SYSVOL on domain controllers and DFS root and link targets.
For additional FRS resources, please visit
http://www.microsoft.com/frs.
This posting is provided "AS IS" with no warranties, and confers no
rights.
On Thu, 16 Dec 2004 14:05:03 -0800, Wendy Derman
WendyDerman@discussions.microsoft.com> wrote:
Has anyone else seen this?
Occasionally I need to rename a target under our domain DFS root. Since it
doesn't appear that I can rename it, I create a new target and then delete
the old one (using the DFS admin tool).
The problem is, the old one sometimes doesn't go away completely. It will
occasionally show up in the list of subfolders under the DFS root, but as an
empty folder (using Windows Explorer - things look fine in the DFS admin tool
at this point). Other times it doesn't show up at all.
On investigating this, I did find an empty directory with the old name,
under the DFS share on one of the domain controllers (using Explorer, not DFS
admin). It did not show up in Explorer on either of the other 2 DCs. I went
ahead and deleted it directly from Explorer. Hopefully that wasn't a dumb
thing to do.
Any explanations as to why this happens? Am I doing something wrong when
deleting from the DFS admin tool?
|
|
|
| Back to top |
|
|
Wendy Derman
Guest
|
| Posted:
Wed Dec 29, 2004 2:51 am Post subject:
Re: Problem deleting target under domain DFS root |
|
|
Thanks for the detailed info. I will save this and check it out next time it
happens (and post results). However our DFS folders don't change names very
often, so I can't predict when that will be. It isn't frequent enough or
troublesome enough to place a support call and risk the $250. I was just
hoping there was something easy I was missing. :)
"Richard Chinn [MSFT]" wrote:
| Quote: | I can't recommend a tool in particular, but I believe if you do an
Internet search for "ntfs directory junctions" you should be able to
find a tool that will tell you the type of junction (reparse point) if
you specify a folder name / path.
With respect to filing a bug, I belive the way to do that is to open
up a support incident. They can follow up to determine if there is a
bug. The problem with this method is that you might get charged if
it's determined there's no bug. I'm not exactly sure what the details
are.
I checked with a DFS tester. He said that when you delete a link, the
DFS service on the server(s) that has the corresponding DFS root
target(s) will see the link deletion in AD, and it will then delete
the reparse point.
If you've created a multi-level link (e.g. LinkFolder\Link1 -- this
would be accessible as \\domain\root\LinkFolder\Link1), the DFS
service will delete the reparse point Link1 and then will try to
delete LinkFolder if there are no other files, folders, or reparse
points. If the folder isn't empty, it won't delete LinkFolder.
Also, every hour or so, the DFS service will retrieve the entire DFS
blob from AD and then match up links with reparse points. If it finds
any stray reparse points, it will delete them. If the folder that
contains the repase point is empty (but not the root) it will delete
that folder as well.
If you can reproduce the problem, go ahead and post the steps to this
newsgroup.
--Richard
Please post FRS related questions to
microsoft.public.windows.server.dfs_frs and prefix the subject line
with "FRS:" to make it easier to spot. Note that FRS is used to
replicate SYSVOL on domain controllers and DFS root and link targets.
For additional FRS resources, please visit
http://www.microsoft.com/frs.
This posting is provided "AS IS" with no warranties, and confers no
rights.
On Wed, 22 Dec 2004 07:43:07 -0800, Wendy Derman
WendyDerman@discussions.microsoft.com> wrote:
Thanks Richard!
I doubt very much that it's a replication issue. We only have 3 domain
controllers, all local, and I've seen these folders linger on for weeks after
I've deleted from DFS. No errors in Event Viewer, repadmin checks come back
clean, etc.
How do you tell that the folder is a reparse point rather than a normal
folder? Unfortunately I don't have an example to look at at the moment, but
next time it happens I'd like to check it out.
Also do you know if there is a way to report this to MS as a possible bug?
"Richard Chinn [MSFT]" wrote:
I'm not a DFS expert, but one explanation might be that the reparse
point is not getting cleaned up on all the root servers. If you look
at the empty folder on your DFS root server, I think you'll find that
it is actually a reparse point (also known as a link or junction).
It's possible this isn't getting cleaned up properly.
I'm not sure of the mechanism used to clean up these reparse points.
It may be that DFS needs to do it when it finds information has
changed in Active Directory. If this is the case, the behavior you
are seeing could be due to AD replication latencies. You could try
waiting for a while to see if the "folder" is cleaned up
automatically. The amount of time you have to wait will be dependent
on your AD replication schedules. You could use the repadmin.exe tool
to speed things along.
--Richard
Please post FRS related questions to
microsoft.public.windows.server.dfs_frs and prefix the subject line
with "FRS:" to make it easier to spot. Note that FRS is used to
replicate SYSVOL on domain controllers and DFS root and link targets.
For additional FRS resources, please visit
http://www.microsoft.com/frs.
This posting is provided "AS IS" with no warranties, and confers no
rights.
On Thu, 16 Dec 2004 14:05:03 -0800, Wendy Derman
WendyDerman@discussions.microsoft.com> wrote:
Has anyone else seen this?
Occasionally I need to rename a target under our domain DFS root. Since it
doesn't appear that I can rename it, I create a new target and then delete
the old one (using the DFS admin tool).
The problem is, the old one sometimes doesn't go away completely. It will
occasionally show up in the list of subfolders under the DFS root, but as an
empty folder (using Windows Explorer - things look fine in the DFS admin tool
at this point). Other times it doesn't show up at all.
On investigating this, I did find an empty directory with the old name,
under the DFS share on one of the domain controllers (using Explorer, not DFS
admin). It did not show up in Explorer on either of the other 2 DCs. I went
ahead and deleted it directly from Explorer. Hopefully that wasn't a dumb
thing to do.
Any explanations as to why this happens? Am I doing something wrong when
deleting from the DFS admin tool?
|
|
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in