Migrating shares to a different drive on various Windows Server versions

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:

Windows Server 2008 Share MigrationAs 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:

In case you have ABE disabled, a log of Process Monitor running on Windows 2008 R2 would be exactly the same as the one of Windows 2008 posted above.

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.


6 comments on the post

  1. Thank you for outlining this and pointing out the pit falls. I am looking to move shares on a 2008 server and knowing what to look out for is a real help.

  2. Really well thought out and written. Why not just use disk management to change the drive letter of the new drive to that of the old?
    In my case, I added a larger drive as “Z:”, moved hundreds of thousands of files and permissions from “D:”. Then, removed drive D. Changed Z to D. Boom, done.

    • I guess your way defeats the whole purpose of this action. The purpose is probably not to just change the drive letter of a share. The purpose is to change the physical location of the data. Perhaps this is needed because you are running out of disk space.

    • That was so easy why didn’t I think of that?!? Sure glad Todd did ‘cuz it worked like a treat. BTW you need to turn off the “Server” service, make the change, then restart the services. You are a genius Todd!! Thanks.

  3. Pingback: View Shares Server | Shares, Stocks, Forex Investments

Leave a Reply

Your email address will not be published. Required fields are marked *