Yesterday I was working on a change to move a shared folder from one drive to another. The original plan was fairly simple:dekor-okno
So, as you see, the plan is indeed simple enough. Anyhow, it did not worked. After successfully going through 1st and 2nd steps, the 3rd step failed. After changing drive letter in the registry, it automatically got reset to the previous one. Since the change window was limited, I had to go with the way I tried to avoid at first – unshare old folder, share a new one and reapply share permissions. It worked because it was a single share I was dealing with. If I would have like 50 shares, recreating each of them manually would take quite long. Therefore today, in my testing environment, I tried to find out why the original idea did not work.
Before going with my findings, I would like to provide more information about the 3rd step described above.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares registry key stores all shared folders on the system. In fact, they key contains not only shared folders, but shared printers, too. It does not contain system shares (C$, Admin$ etc.), though. Each value in this key has the following data:
The line we are interested in particular here is “Path=E:\TestShare“. Changing E: to F: (or any other drive letter) should allow us to redirect the share to a different location, making migration of the share much easier. Anyhow, looks like it works as it suppose to not on all versions of Windows Server.
You are lucky if you do not have Windows Server 2008 (not R2), as well as Vista, in your environment. Despite all the other issues those operating system have, it looks like there are two issues related to shared folders being stored in registry, too.
The first issue is that changing path of a share in the registry does work if the share has Access Based Enumeration (ABE) enabled. You can easily see that by looking into the value in the registry: the shares having ABE enabled have CSCFlags value set to “2048” instead of “0” (or some other value in case it has caching enabled). If that is the case, as soon as you edit the Path and (re)start “Server” service, the value would automatically revert back to the original one:
As you can see in a log generated by Process Monitor above, lanmanserver service, during its’ start, reads the shares (first line) and their security data. It sees the new drive letter we put in the registry, it checked the path and the folder but at some point (highlighted line) it switches back to the previous value (C: drive). After repeating all the same actions with the drive as it did with the other one, it writes the previous value back to the registry (last line).
The behavior like this looks very strange. I cannot think of any logical reason why having Access Based Enumeration enabled could impact this. I also was unable to trace any more details in Process Monitor what might be causing that.
Either disabling Access Based Enumeration using MMC or changing value of CSCFlags to 0 solves the issue – restarting the service no longer reverts the Path value:
Anyhow, there is another related issue on Windows Sever 2008 – for changed path to take effect, a reboot is required! Even if the registry value points to a new path now, the share would still point to the old path. You can see that while accessing the share, using MMC console, or simply checking the folder in Explorer. Once the server is rebooted, the share will be pointing to the new path. My guess is that it might be caused by “System” process not updating handles to a new path correctly.
So, in case you you need to migrate a lot of shares on Windows Server 2008, the plan should be similar to this:
The plan is much more complicated as it was before, so you should think whether it will be more efficient than simple recreating the shares and replying the permissions. It is likely to depend on the number of shares you have to migrate.
It looks like the issues described above applies only to Windows Server 2008. There are no such issues presented in 2008 and 2012 versions of Windows Server. What is more surprising, that an earlier version of Windows Server – 2003 – does not have this issue either. Changes to a share path are applied after restart of lanmanserver service – no reboot is required.
It might be worth mentioning that having ABE enabled on a share in Windows Server 2008 R2 results in very similar actions of lanmanserver as they were in 2008 version of Windows. That is, the paths are read twice and the value is written back to the registry afterwards. The only different is that it is not reverted back to the previous one:
So, if you are planning to migrate share on Windows Server 2003, 2008 R2 and 2012, the original plan, posted at the beginning of this post, would work. For Windows Server 2008, though, you would need to use a plan similar to the one I added to corresponding section.