skip to main |
skip to sidebar
It can happen to everybody. A DFS Link gets deleted in the wrong way by accident, and now it's stale sources are being a burden in your DFSroots directory. This can happen due to errors in namespace replication or unclean shutdowns. The directory cannot be opened or manually deleted, so how can we get rid of this?
When you try to open the directory you'll get the following error:
It makes sense to get this error, because DFS make a sort of junction point on your fileserver to relocate you to the real point. When you try to delete the folder you'll get this error:
When a DFS link gets created, a reparsepoint is created in the DFSroots directory. This is a link to the original directory. Also, see: http://msdn.microsoft.com/en-us/library/aa365503(VS.85).aspx for more information.
This reparsepoint is also what's causing the error. Normally, if you try to open a reparsepoint (like AppData in Windows 7 is), you'll get redirected to the original directory. In the case of DFS this works somewhat different, because the original directory isn't located on the same server.
To fix this we have to take some steps. First, open up Command Prompt and browse to your DFSroots directory. In my case this is C:\DFSroots. Open up your DFS namespace and look at the folder contents. This folder is what's being published when an user accesses your DFS namespace.
Above are the folder contents of the DFSroots folder in my test environment. Top Secret is a stale folder, so I'd like to delete this. Windows contains a tool called fsutil that can help us reach this goal. Type: fsutil reparsepoint query \\. In my case this would be fsutil reparsepoint query "C:\DFSroots\Public\Top Secret". Remember to enclose your query with quotes ("") when your name contains spaces.
The result should look alot like the following:
As you can see within the Tag Value, this reparsepoint is created by/for Microsoft DFS. Now, we're gonna delete this reparsepoint so our view of the namespace will be nice and clean again. Type: fsutil reparsepoint delete \\ and press Enter. Again, mind the quotes.
In this case the rule is: No result is good result. When you get a blank line your command succeeded. When you try to remove something that's not a reparse point you'll get an error looking a lot like the following one:
This means the reparse point is already deleted or you're giving in the wrong directory in your command line.
Hope this helps in keeping your DFS environment clean and tidy.
Regards,
Stefan Hazenbroek
A short while ago a question was asked on the Technet Forums regarding folders not being shared as expected after a reboot. This specific issue was in regard to BitLocker, but this same issue applies when the folders are being hosted on a volume that's connected through a SAN (Fibre/iSCSI and such)
After being able to answer the question I thought I'd post a short blog article in regard to this issue, because it's a very common issue and not very well documented.
Issue
When you reboot your server all shares that are hosted on a SAN, on a BitLocker protected volume or anything other that needs a service in order to ensure it's availability. After restarting the Server service these shares come available, but there are no clear errors in the eventlog that states something is wrong.
Resolution
The issue is due to the BitLocker (or the service that connects your FC/iSCSI devices) service not being started yet when the Server service is started. When the server service is started, it tries to locate all folders to share and disregard the ones that aren't reachable. Because the service required is started shortly after, you won't notice any apparent issues until you investigate them.
Luckily this issue is quite easily fixed by editing a value in the registry. I'll explain this by showing an example.
1. First, open up services.msc.
When you look at the screenshot below, you'll see the shortname of BitLocker Drive Encryption. Write down this name or save it somewhere, we'll need it later.
2. Open regedit (Start, Run, type: regedit)
Browse to Hkey Local Machine\SYSTEM\CurrentControlSet\LanManServer
When you look in the key you'll see a value called DependsOnService. In my case this value is filled with SamSS and Srv. Open up this value.
As you can see, both services that need to be started in order to start the Server service are SamSS and Srv. Place the cursor after Srv and press Enter. Now type bdesvc (or the name of your required service you located in Step 1) and press Enter again. After filling in the value it should look like this:
Press Ok and reboot your server.
After a reboot your shares will be available directly from boot as they should be. Remember to remove the added service when you disable BitLocker again or remove the disks from SAN, otherwise the Server service won't be able to start.
Hope this helps.
Regards,
Stefan Hazenbroek
