none
"The feature you are trying to use is on a CD-ROM or other removable disk that is not available." when running a program for the first time as another user

    Question

  • I have a Setup Project built in VS 2008.  I run the setup is run on a new computer and instruct it to install for all users.  When I log in as a different user and then double click the desktop icon, I get the message:

    "The feature you are trying to use is on a CD-ROM or other removable disk that is not available."

    It asks me to insert the original CD ROM.

    Needless to say this is a nightmare scenario from a user support standpoint and I am trying eliminate it.  The install program does create (always) a registry DWORD item under the HKEY_CURRENT_USER branch to fix a bug with Crystal Reports 12.0.  It also creates (creates) a registry key in the HKEY_CURRENT_USER branch for may application to store user settings within.  That's all I can find in the install that would be user specific. 

    I tried creating those two entries manually and then start the application, but it still prompted me for the CD ROM.  This makes me think I miskeyed an entry.  I'll go back and try it again. 

    If I insert the CD Rom and let it do its thing, I can run the application without further prompting.  If I tell the set program to install for all users, why aren't the registry entries added to HKEY_CURRENT_USER put there for all users? 

     

     


    Andy
    • Edited by andy pelkey Saturday, December 10, 2011 11:17 PM
    Saturday, December 10, 2011 11:07 PM

Answers

  • I removed the registry entries created in HKEY_CURRENT_USER from my setup program.  The problem went away.  I then changed my application to do the same work.  Problem solved.


    Andy
    • Marked as answer by andy pelkey Sunday, December 11, 2011 12:07 AM
    Sunday, December 11, 2011 12:07 AM
  • The install can't possibly create the data for all users, because it doesn't know all the users (in a domain where anybody could log on on) and because it doesn't even work when you create a new user later on. The way it works is that it creates the new items for any new user that ever logs on, even if that user does not yet exist.  This is the way install-on-demand works.

    It really is best to have the CD available, or perhaps do the install from the hard disk, especially if you know other users may log on. The Windows Installer team recommends it, Rule 31:

    http://blogs.msdn.com/b/windows_installer_team/archive/2006/05/24/605835.aspx 

     


    Phil Wilson
    Tuesday, December 13, 2011 7:44 PM
    Moderator
  • It's generally anything that is per-user, and that includes HKCU registry entries as well as files in user profile locations.

    However..... the MSI file is cached (without files) in \windows\installer and contains the registry entries, so it shouldn't really need the CD to create registry entries.  If you look in Application Event log there should be an MsiInstaller log entry saying something about a product (your product code guid) needing a component (installer component guid). That component guid isn't visible in Visual Studio setup, so you'd need to open the MSI file with an MSI file editor (Orca, InstEd) to see what the component table for that guid refers to (probably something in the File table). If you know of anything in a user profile location, that would do it.


    Phil Wilson
    Wednesday, December 14, 2011 6:48 PM
    Moderator

All replies

  • I removed the registry entries created in HKEY_CURRENT_USER from my setup program.  The problem went away.  I then changed my application to do the same work.  Problem solved.


    Andy
    • Marked as answer by andy pelkey Sunday, December 11, 2011 12:07 AM
    Sunday, December 11, 2011 12:07 AM
  • I'm glad to hear that you solved it.

    Have a nice day!


    Mike Zhang[MSFT]
    MSDN Community Support | Feedback to us
    Monday, December 12, 2011 3:30 AM
    Moderator
  • The install can't possibly create the data for all users, because it doesn't know all the users (in a domain where anybody could log on on) and because it doesn't even work when you create a new user later on. The way it works is that it creates the new items for any new user that ever logs on, even if that user does not yet exist.  This is the way install-on-demand works.

    It really is best to have the CD available, or perhaps do the install from the hard disk, especially if you know other users may log on. The Windows Installer team recommends it, Rule 31:

    http://blogs.msdn.com/b/windows_installer_team/archive/2006/05/24/605835.aspx 

     


    Phil Wilson
    Tuesday, December 13, 2011 7:44 PM
    Moderator
  • That is a good point, I was thinking too narrowly of a PC not connected to a domain. 

    Having said that, many of my users have simple needs and less that basic computer skills.  In this case, I was able to move any work done to the HKEY_CURRENT_USER part of the registry out of the install and into the application itself.  I retested the application on a computer running windows 7 where I installed as one user and then used the application as another.  I did not get any prompt to install the CD.

    However, the very next day I intalled the application at a beta test site who has a network and a domain.  When I installed the software as the domain admin user, installed the software, logged in as a user who normally works on that particular workstation and tried to run the application from the desktop icon, it again asked me for the installation CD.

    I know the problem isn't the registry entries... I don't know what it is.  How do you tell what it is looking for on the CD?


    Andy
    Tuesday, December 13, 2011 8:02 PM
  • It's generally anything that is per-user, and that includes HKCU registry entries as well as files in user profile locations.

    However..... the MSI file is cached (without files) in \windows\installer and contains the registry entries, so it shouldn't really need the CD to create registry entries.  If you look in Application Event log there should be an MsiInstaller log entry saying something about a product (your product code guid) needing a component (installer component guid). That component guid isn't visible in Visual Studio setup, so you'd need to open the MSI file with an MSI file editor (Orca, InstEd) to see what the component table for that guid refers to (probably something in the File table). If you know of anything in a user profile location, that would do it.


    Phil Wilson
    Wednesday, December 14, 2011 6:48 PM
    Moderator
  • I had a similar problem, but mine came from creating a folder on the root of the HDD where my customer wanted there program installed.  I think put my primary output there and created short cuts to it.  Each time the installed program was run (from a shortcut) it tried to hit the msi file.  If the exe was run directly from the filesystem it worked fine and did not try to access the msi.

    The issue was resolved by using the "Application Folder" and just changing where it was pointing to and rebuilding the desktop and start menu shortcuts.

    Jacob

    Thursday, October 24, 2013 3:42 PM