Moving the default WHS shares RRS feed

  • Question


    Hi All


    Sincere apologies if this topic has been covered before but I can't find any references in the searches that I've done so far...


    Basically, I would like to change the physical location of some of the default WHS shares. Imagine that I have the standard single drive partitioned to the WHS SYS and DATA partitions but I would like to add another disk - or raid array and not use the WHS drive extender pool. I would like to move, for example, the \shares\Software folder - one of the ones that can't be deleted from the WHS console - to the new disk or array.


    In my testing, I have created a new folder on the DATA partition at D:\Test\Software, removed the share from \shares\Software and then shared the new folder. All good so far as we still have \\SERVER\Software available to the network. The problem is that the console reports the share as being empty which could only be true if the console can only look at \shares\Software. This would become a problem if I wanted to get at the Software share remotely through the WHS web server.


    I'm guessing that this has something to do with the following Registry keys:

    HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\DEFilter\IncludedDirectories - \shares\Software
    HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Services\DEFilter\IncludedDirectories - \shares\Software

    ...but editing the keys to reflect the new location makes no difference - and the keys get reset after a reboot and the folder has even been recreated after i'd deleted it.


    If I have to use the Drive Extender and dynamic disks, so be it, but I would like to have the flexibilty of other options...




    Thursday, July 24, 2008 11:48 AM


  • You cannot move the Shared Folders, they are 'hard-wired into the code.  Also, folders like Add-Ins and the Home Server Connector Software with the Software folder are required, so don't delete them either. (Updates use the paths to these, for their operation).




    Thursday, July 24, 2008 2:48 PM

All replies

  • As WHS uses the Software folder to store the latest connector install, I'd expect this is not something you can modify within WHS. The default shares are stuck there, but it doesn't prevent you from making your own seperate shares. WHS won't monitor them, but neither will they be affected from working.
    Thursday, July 24, 2008 2:05 PM
  • Cheers for that. My thinking was that, if WHS knows where the default Software folder should be, surely there must be some way to change that path. I'm now thinking, however, that this is something that's probably been hard-coded into the Console (or elsewhere!).


    I don't have a problem with having to manually create shares but it's not exactly elegant to have a Software and a (for example) My Software folder where the actual share exists.


    Given that WHS is designed to make the Client-Server relationship as easy as possible, I can certainly see the logic in forcing users down the default share/dynamic disks route but it's a bit of a frustration for those of us that like to tinker a bit more...

    Thursday, July 24, 2008 2:44 PM
  • You cannot move the Shared Folders, they are 'hard-wired into the code.  Also, folders like Add-Ins and the Home Server Connector Software with the Software folder are required, so don't delete them either. (Updates use the paths to these, for their operation).




    Thursday, July 24, 2008 2:48 PM
  • Thanks Colin - my suspicions are confirmed :-)


    Fair enough then - I'll content myself with what MS provides and i'll learn to live with dynamic disks! ;-)


    Cheers all.


    Thursday, July 24, 2008 4:31 PM
  • Hi all


    I've been doing a little more digging and, thanks to a friend of mine, I've found a new approach:


    If you add a new drive or create a new partition within the Disk Management console, do not assign a drive letter but choose to mount the partition in an empty NTFS folder. To use my previous example of the Software share, obviously you'd have to move the default contents out first (say to \Public) and then copy them back once the partition becomes available. Works a treat so far and, in theory, you could even start mounting RAID arrays in this manner.


    The fly in the ointment is that your WHS starts to complain about file conflicts: ie all of the files now stored on your new partition(s). I traced this back to the Drive Extender Migrator Service which, since I don't need to use the WHS Dynamic Disk Pool, I could happily disable the service. Job done - no file conflicts and all shares are reporting as completely healthy. The only problem is that WHS now complains that the Drive Extender Migrator Service is not running - aaarrgghhh!


    If someone could point me in the direction of how to stop WHS health-monitoring this service, I would be eternally grateful :-)





    Tuesday, July 29, 2008 11:34 AM
  • It's not clear to me what your final goal is, or why you want Windows Home Server rather than some other operating system. What is pretty clear is that you're trying to remove or circumvent core functionality in the product, and you're likely to fail. In the long run you're risking severe consequence, right up to total data loss.

    Have you considered just buying a copy of Windows Server 2003?
    Tuesday, July 29, 2008 12:30 PM
  • :-)


    WHS is a lot cheaper...


    While I take your point that I'm probably asking a lot of a product that is essentially designed not to be tinkered with, I like to tinker and if it increases the flexibility of the product, surely this kind of exploration is no different from offering an add-in that does something that WHS wasn't designed to do?


    In terms of comparisons between WHS and Server 2003, 2003 doesn't (as far as I am aware) run a Drive Extender Migrator Service but you can, if you so choose, run Dynamic Disks as opposed to basic partitions or RAID arrays. My thinking is that, since WHS is based on 2003, the same flexibility is there to be had. I would also doubt that simply disabling the Drive Extender Migrator Service is not going to be putting data at risk but, since i'm not working with Live Data at the moment, should that prove to be the case, I haven't lost anything.


    Maybe someone will find this useful?


    Tuesday, July 29, 2008 12:54 PM
  • Yes, WHS is cheaper, but it's not intended/designed to be Windows Server 2003 Lite.

    The difference between what you're doing and what an add-in might do is that an add-in will (in theory) not be using undocumented procedures or disabling core server functionality. It will be extending functionality in an easy to use fashion. And some of the add-ins out there are probably pretty risky. Smile

    I do understand the desire to tinker, though.
    Tuesday, July 29, 2008 7:08 PM
  • No, I completely agree that it's not supposed to be 2003 - or even SBS - Lite. There's features in WHS that I wish 2003 had!


    And vice-versa - But no product off-the-shelf is a Panacea.


    I've pretty much had my questions about WHS Disk Management answered - how it works, what's theoretically possible and what's not(!) and this has raised some questions on WHS self-checking and error reporting. If anyone has any thoughts, I'd be grateful for the input :-)

    Wednesday, July 30, 2008 8:57 AM
  • OK I'm going to put the thread to bed now :-)


    The inevitable conclusion is that you can happily use your own partition, disk or RAID array arrangement but not with the default shares and not with the Drive Extender Service. This is not a bad thing as, having now tried and thoroughly tested the facility, I actually rather like it and would happily recommend using it :-)


    My grateful thanks to all who contributed to the thread.






    • Proposed as answer by Zam442 Thursday, March 19, 2009 7:05 PM
    Friday, August 1, 2008 11:32 AM
  • Actually you could resolve this problem quite easily by creating static links to the default shares on the D drive to a new drive on something larger such as  RAID array installed after the fact.

    Download this tool, Junction LinkMagic and create static links to identical folders on the new drive or array.  I tested this feature on the 120-day trial last year but did not integrate into my home network due to the corruption issues resolve with PP1.  I am now building a new WHS and plan to use a large multi-drive RAID array for the storage but encountered the same hard-coded share problem as before.  Even if you move all of the files to a new location and reassign the drive letter to the new location so it matches the previous location it still breaks and the console indicates that your drive has failed even thought the content is intact in the new location.  I believe MS is creating unique volume identifiers to track the data so if you move it to a new drive, the unique ID does not match so MS flags it as an issue.  The static links worked wonders previously and I plan to use it again actually this evening when I finalize my installation.  I just spent three days troubleshooting AHCI installation issues but was successful in changing IDE to AHCI after the initial installation.  I stumbled across this thread hoping that someone else resolved the issue.  I can't be the only one to sneak around the shortsighted problem using static links.  Despite it being a typically UNIX convention Windows 2003 does support it but for the life of me I cannot understand why MS does not enable this functionality with the explorer interface.  You could try to use a SUBST in the CMD prompt temporarily but I do not know if this survives reboots or how that will act with the Console.

    Good Luck and Regards

    • Proposed as answer by Zam442 Friday, March 20, 2009 5:00 AM
    Thursday, March 19, 2009 7:14 PM
  • MS needs to add this functionality. I love the product but not being able to manage the location of the data drive or move it seems like more than just a limitation! Major fault...

    Thursday, March 10, 2011 4:24 PM