"New hardware found" for each ISO filename

[Anonymous]

Hi there,

We maintain a database of ISO images that are available for our network users to mount at their WinXP/SP3 workstations using WinCDEmu.

Everything works just fine, except for the annoying fact that with each new ISO filename being mounted on each workstation, WindowsXP adds a new “hardware storage device” and asks the end user to restart his workstation. Consecutive mounts of the same ISO filename do not cause this behaivour.

This is quite an annoyance for us and in order to circumvent it I added an automated file-copy procedure that takes a copy of the ISO image file from the file server onto the local harddisk and then mounts that file (using batchmnt.exe).
The local harddisk filename is always constant, hence Windows notifies about new hardware just once. The drawback of this procedure is the time taking to copy the ISO file from the server to the local workstation – so we’d very much prefer mounting the ISO image directly from the server!

Is there a way to trick WinCDEmu (without renaming the original file in the server) such that different source ISO filenames would result in the same single constant named hardware device?

Many thanks in advance,
Uri Inbar
Alyn Hospital
Jerusalem, Israel.

[support]

This was originally done to make Device Manager display correct image names as device names. However, the overhead of “new device found” every time really seams unreasonable. It will be fixed in the next version.

[Anonymous]

Thanks for the quick reply!
When do you expect this newer version to become available?

Much obliged,
Uri

[Anonymous]

Hi there,

We need to be able to mount ISO fies from a DFS (Distributed Files System) UNC path.

At the moment WinCDEmu copes well with regular UNC shares such as \servershare…, but seems to be unable to handle DFS pathes – niether using domain FQDN (e.g., \my.domain\namespacedfsroot…) nor NetBios (\DOMAINNAMEnamespacedfsroot…) – both fail with an error. Note that both DFS path formats (doman and netbios) work perfectly well for all other needs such as windows explorer, vbscripts, etc. We’re using Win2008 DFS with WinXP/SP3 clients.

For the time being I’ve bypassed the problem by first mounting the DFS share on a logical network drive (“net use”) and then mounting WinCDEmu from the logical drive (which works okay), but it seems preferable that WinCDEmu cope with DFS pathes by itself.

Thanks,
Uri.

[Author]

Posts