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?

I figured this may be a better community to ask than serverfault.


Over a long enough period of time it could be determined indirectly. It is not 100% reliable and it takes a lot of time, but this information could leak in from the real world.

Posit a program which runs continously, makes many disk requests and knows the loading on the system where it is running. As it considers the service times for requests eventually it must conclude that some responses take so long (due to network traffic, congestion, whatever) when the system is otherwise not loaded that the disk cannot possibly be a real hard drive connected to a motherboard.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy