0

This is all in the context of Windows 10, both client and server.

Background: Some programs block installation/running on shared network folders. I don't mean errors due to sharing/file permissions or needing to enable policies in GPO/registry; I mean they outright tell you network installs "won't work" and then block them, even when using a mapped network drive (ie "\\SERVER\DriveP" mapped to "Z:\" on the local machine).

A workaround I've found is creating a VHD/VHDX on the network share, then using Disk Management on the local machine to mount that VHD as a local drive. For example, I create a VHD file "VirtualDrive.vhd" in "\\SERVER\DriveP", then attach that VHD to "D:\" on the local PC. This seems to be 100% transparent and functionally identical to a drive physically plugged into the PC; programs that normally block (or don't function with) mapped network installs, work with this method.

In short: I have programs installed on a network drive by using a locally-mounted VHD which is physically stored on a network drive.

Question: Is there any way for a program to detect that the drive it's running on ("D:\" in this example) is actually a VHD stored on a remote computer but mounted locally, rather than a drive physically plugged into the PC?

  • 1
    You had a problem, you found a solution that worked for you...so it would seem your answer is already clear. – Don Simon Mar 27 '19 at 21:56
  • @DonSimon True I found a solution to a problem, but this question isn't about fixing a problem; the question is whether that workaround can be detected (given a new program to run or a program update). Several of my friends could benefit from this workaround, but my fear is that if the workaround (for what should be considered absolutely basic functionality) "gets out", it could be blocked in future versions - most likely because certain devs don't want to deal with the potential for a small handful of support tickets. If it can't be detected, then I can save my colleagues a lot of hassle. –  Mar 27 '19 at 22:03
  • In the possible future passasge of time, could some programmer write something that detects your workaround? Yes. Is it likely? Impossible to know. – Don Simon Mar 27 '19 at 22:12
  • "Could some programmer write something that detects your workaround? Yes." This is exactly the question. How can it be done? I'd consider this to be similar to asking whether or not VMs can be breached, but in a much simpler scenario. Maybe I should have rephrased - I'm not asking "in the infinite multiverse could this potentially happen at some arbitrary future point in time", I am asking "can this be done, with techniques that already exist, right now" –  Mar 27 '19 at 22:14
  • If the program is running with administrator privilege, then definitely yes: it could always look up what device the volume is located on and identify it as the "Microsoft Virtual Disk" device. I'm not *quite* certain whether you can do this without administrator privilege, but you very probably can. However, it seems unlikely that anyone would bother. There are genuine problems that can be caused by running from a network share, but that's not because the data is on the network, it is specific to the way network shares work. Your solution won't have the same issues. – Harry Johnston Mar 30 '19 at 08:10

0 Answers0