[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 853
  • Last Modified:

VS 2010 Deploys Per-User Features During Install Which Require Access to install media

There is a slight problem with VS 2010 installer, it seems.
•         Let’s say the installer installs the app from a network share (for example the J: drive, which the installing person has access to).
•         The installer (with Admin Rights) performs the install of the MSI and the default is already set that the app should be installed for everyone.  
•         The app will launch fine for the admin installer user.
•         Then, the installer logs off and a second user logs on who doesn’t have access to the original installation drive… in this case the J: drive.
•         When the second user first launches the app, it begins configuring features for the application for the user, and a dialog box appears, which says that in order to complete the configuration, the program needs access to the original source directory… in this case the J: drive.  The second user, of course doesn’t have access to this directory and receives an error message which says to locate the media on the J:\ drive and try again.  Since the second user cannot complete the installation, the launch fails with a fatal run-time error.  

This is not normal behavior for an install (and does not occur for apps built with VS 2008) and would create problems when any user logs in for apps built with Visual Studio 2010.
In the install we actually did, because it was a priority, the installer got around the problem by copying the original install bits to the local PC and installing the app from there.  That way, subsequent users of the PC would have access to the install bits the first time they launched the app.  This is not an acceptable Enterprise solution.
Any ideas as to how to avoid this problem, or what may be causing it?  We don't get this problem when VS 2008 is used to build the MSI.   When we use VS2008 to build, there is also a Setup.exe generated, but when we build with VS2010, there is no Setup.exe generated, if that helps.
0
MichaelJMurray
Asked:
MichaelJMurray
  • 7
  • 7
  • 6
  • +1
2 Solutions
 
cyborgrdCommented:
I do following. Put every file what you have in user profile to allusers profile also (dublicated files)
in this case the files will be repaired from allusers profile and not from the msi. I do it so. I put the files to allusers profile first and then dublicated file to the user profile. Registry keys etc will be repaired from the cashed file.
0
 
Vadim RappCommented:
Regardless of what VS2008 was doing, I don't see that's wrong. If you really want the installation be installed per-user, then surely every user needs access to the installation source. Not only during the installation, but also in case the application later gets damaged and Installer needs to perform repairs.

If you want the installation be available to all users of the machine ("and the default is already set that the app should be installed for everyone. "), then this is what per-machine installation is for.

If this is about the mapped drives, i.e. the problem is not in the second user have no permissions for the file share with the installation, but in him having no drive letter mapped to it - don't use drive letters, use UNC, i.e. the installation should be available from \\server\share\file rather than from J: mapped to it.
0
 
CSI-WindowsCommented:
This is the standard behavior for MSI - for per-user fixup self-healing to work, users need readonly, access (mapped drive if installed via mapped drive) to a copy of the source install files.

The setup.exe was likely copying your source locally and running from there.

You would either need to make sure users can access the drive.  Or provide the same install files at a UNC location they have access to and include that in a SOURCELIST property like this:

J:\abcpackage> msiexec /i abc.msi SOURCELIST=\\server\share\abcpackage

The abcpackage folder must contain the exact same files as J:\abcpackge for this to work.

If you are a commercial software developer, the risk is that the administrators doing the setup do not understand the requirements for MSI source list access.  Should be relatively rare in large corporations - so if you are only experiencing this in your testing, it may not actually bother your customers.  Small organizations - your mileage may vary :)
0
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
MichaelJMurrayAuthor Commented:
vadimrapp1, I was not clear.  We do not wish per user install.  We wish to have ithe app completely install on the machine, and once installed, it is done and finished, and no subsequent user will have to install anything else, not even "features", when they start up the app for the first time.  It matters not if we use a mapped drive or UNC, the second user does not have permissions to the admin network drive where the bits are stored in a configured repository.  We do not wish to put the install bits where any user can get them because we, IT, control what goes on the users' machines.

cyborgrd, I do not understand your suggestion that the files will be "repaired"from allusers profile.  Do you mean:  "The files will be installed from allusers profile" ?  And, what is an "allusers profile" in a Visual Studio 2010 deployment project?
0
 
Vadim RappCommented:
Then you need to find out why self-repair is launched when users logon. The installation must have something per-user that is missing. Please look at the article How to fix Windows Installer Efforts to Self-Repair , start with looking at the event log.
0
 
MichaelJMurrayAuthor Commented:
CSI-Windows, we are a large enterprise and want to control what business users install on their own computers.  Normally, we use orca to break apart the MSI  received from the developer after the change has been approved, and the installer would use a custom install tool, not the Windows installer.  In this particular case, the installer just double-clicked on the MSI in the network repository to do the install.
0
 
MichaelJMurrayAuthor Commented:
vadimrapp1, it is not doing self-repair, it is installing features.  Do you have experience using VS 2010 to build and deploy apps?
0
 
Vadim RappCommented:
You said: "When the second user first launches the app, it begins configuring features for the application for the user". This is self-repair, and in the event log you will find the records mentioned n the article.
0
 
MichaelJMurrayAuthor Commented:
vadimrapp1;
 
From EventVwr log:

We get MsiInstaler error:
Detection of product '{C28B0797-7A47-415A-8F15-312720955C5A}', feature 'DefaultFeature', component '{A83B627C-7C1B-503C-18C7-05B0ECA25F63}' failed.  The resource 'HKEY_CURRENT_USER\Software\Costco Wholesale\MemIncomeEFT\{A83B627C-7C1B-503C-18C7-05B0ECA25F63}\DesktopFolder' does not exist.

And then we get:
Detection of product '{C28B0797-7A47-415A-8F15-312720955C5A}', feature 'DefaultFeature' failed during request for component '{5CB29EF4-E1ED-0798-A982-B2802E7A4C09}'

Then we get:
Product: MemIncomeEFT -- Error 1706. An installation package for the product MemIncomeEFT cannot be found. Try the installation again using a valid copy of the installation package 'MemIncomeEFT.msi'.
 
Then:
Product: MemIncomeEFT -- Configuration failed.

Finally:
Windows Installer reconfigured the product. Product Name: MemIncomeEFT. Product Version: 1.0.2. Product Language: 1033. Reconfiguration success or error status: 1603.
0
 
Vadim RappCommented:
So here's your culprit: registry key  'HKEY_CURRENT_USER\Software\Costco Wholesale\MemIncomeEFT\{A83B627C-7C1B-503C-18C7-05B0ECA25F63}\DesktopFolder' . It is indeed per-user.
0
 
CSI-WindowsCommented:
A couple other options include:

1) Use a hidden share for the files (e.g. \\Server\hiddenshare$.  Hidden shares are configured by adding a "$" sign to the end of the share name.

2) Use the MSIRestrictRun (http://desktopengineer.com/msirestrictrun) script to embed self-disablement when end users do not know the secret to getting the packages to run.  It's too hard to explain how this script works on this thread, but I will say that it edits the MSI with standard MSI functionality - the script is NOT used for deployment.  You can pair it with messing with the shell verbs for "msi.package" so that users can't even double click packages at all.

vadimrapp1 is correct - it is using self-healing to "fault in" the user profile portions of the package.  However, whether you call it "self-healing" is simply semantics since MSI is designed to use self-healing in this manner.
0
 
MichaelJMurrayAuthor Commented:
Thanks, CSI-WIndows and vadimrapp1 for all your help.  It was interesting and I learned a lot.  But the solution had to do with package that Visual Studio generates from the build and it appears to a bug for Micro$oft:  
The following is an extract from the post that follows:
http://connect.microsoft.com/VisualStudio/feedback/details/551667/setup-project-has-some-keys-created-under-hkcu-even-if-the-intallallusers-is-true

I create a simple setup project in VS 2010. Then modify the property InstallAllusers to true. After building the msi when I run the msi on a client machine I choose "Install for every user" and then I can run the app successfully. After that I logged on another user and tried to run the app at this time a message occurs stating that "please wait while Windows configures ..."
I researched the issue and noticed that even if in VS we have set the property InstallAllusers to true when we open the msi in ORCA MSI Editor the AllUsers propery has value 2 and there is a registry key for desktop shortcut created under HKCU. (The root column has value 1 which means HKCU)
So I modified root column from 1 to 2 which means the registry root will depends on the user's choice (HKLM for "Install for every user" and HKCU for "Just for me".
Thus the issue of configuring for second logged on user is eliminated. However, I wonder why in Orca MSI editor AllUser has value 2 and the keys for shortcut are created under HKCU by default even if we have specified InstallAllUsers to true in VS.

Posted by Microsoft on 5/10/2010 at 11:29 AM
Hi,

Thanks for reporting this issue. After looking into this, we recognize this is a problem with advertised shortcuts in MSI, which setup projects always use. To workaround this problem, instead of modifying the root column from 1 to 2, you can set it from 1 to -1 instead. The -1 allows the installer to write the registry value under HKCU and HKLM based on whether it's a per-user or per-machine installation, which gives the installer more flexibilty.

Please let us know if you have additional questions within 7 days.

Thank you.

SInce the solution was to use Orca to tweak the MSI but I am grateful to the two who responded, I'm going to accept both their solutions.
0
 
CSI-WindowsCommented:
I'm not sure I'm understanding the thread that you've reposted.

"...there is a registry key for desktop shortcut created under HKCU"

MSI does not create shortcuts using the "Registry" table, but rather the "Shortcut" table.  The only type of shortcut that uses the registry is a namespace shortcut - but then it does not trigger MSI.

The solution offered would not seem to fix the core problem of having a per-user install - it simply shifts registry keys depending on the TYPE of install (Per-User or Per-Machine).

But, if it solves your problem then you're off to the races :)
0
 
CSI-WindowsCommented:
Ah, I see now - it is indeed a namespace shortcut !
0
 
Vadim RappCommented:
1. I don't quite understand what is the purpose of having registry key pointing to the desktop.  I posted this question in the Connect report you mentioned, maybe Microsoft will explain. CSI-Windows, if you understand this, I'd appreciate if you could share; what is namespace shortcut you mentioned?

2. Actually, I wouldn't worry about Installer launching self-repair on the 1st launch by the new (for the product) user. Lots of applications do have per-user settings, even when installed per-machine; usually these settings are quietly created by the application itself on the 1st run, but they as well can be created by the installation in this exact fashion that we encountered in this thread; the only practical difference is Installer's progress dialog. So why is that such a problem? you might also remember that after the installation of new version of Internet Explorer, each user has dialog "Configuring user settings..."on the first logon, doing the same thing. It's not the first time I encounter nervous reaction to this, including my own installations, but I don't think it's necessarily bad thing that must be eliminated. It can be by design, and it happens only on the first run. If it happened on every run, that would be a true problem.

3. With all due respect to CSI-Windows, for the purposes of E-E's KB, I don't see anything in the comment http:#36905921 that would be related to the solution you have found.
0
 
MichaelJMurrayAuthor Commented:
The bug in the setup package project in VS is that the setup ignores the AllUser and makes it per user regardless of the intention of the developer who designed it for Allusers or the Admin who actually chooses Everyone during the install.  The setup just ignores the settings and the choices and makes it per user anyway.  And it is a very serious issue because while the Admin has permissions to the setup folder, the second user does not, so the second user cannot use the app at all because they can never get to the media to create the current user setting which they don't want but which the setup forces them to create.  This is something that Microsoft said they fixed in VS 2010 but I have not seen it.  And Vadimrapp1, you should be grateful for the points you got because another would have said you missed the point (pun intended).
0
 
CSI-WindowsCommented:

The Shell Namespace can contain virtual objects such as the Recycle Bin.  It looks like this application may be creating a virtual object.  More information here: http://msdn.microsoft.com/en-us/library/windows/desktop/cc144090(v=vs.85).aspx

The reason the source lists are not resolving is that the requester wants to prevent end users from installing the software by using the location the software was installed from as they indicated in 36905489.  The solution offered in 36905921 relates to how to: a) prevent end users from installing packages while b) allowing source lists to resolve properly for self-healing.
0
 
CSI-WindowsCommented:
MichaelJMurray,
You may also be able to fix this behavior by changing ALLUSERS in the property table to "1".  At least this may flesh out why ALLUSERS=2 (if that's also in the log) is gracefully failing over from a Per-Machine to a Per-User.  Take a look here to see that ALLUSERS=2 can shift to Per-User: http://msdn.microsoft.com/en-us/library/windows/desktop/aa367559(v=vs.85).aspx

You would need to check the log file for the actual value of ALLUSERS because this VS property "InstallAllUsers" and the dialog box are not properly manipulating "ALLUSERS" there may be a different problem in the package (e.g.  the CA that translates the VS property and/or install dialog to the proper ALLUSERS value)
0
 
Vadim RappCommented:
MichaelJMurray, I'm certainly very grateful for the points, although I don't think I missed anything: the reason for Installer's self-repair was in HKCU key that I correctly pointed out for you. It was totally different matter why this HKCU key was in the installation to begin with, and yet another totally different matter that the setting "install for all users" in Visual Studio did not correctly translate into the property ALLUSERS in Installer, which, as you correctly pointed out, indeed should affect all registry keys; but in this particular installation, the key that you have obtained using my article + my comment was the reason for the self-repair, and as you have confirmed yourself, once you have changed it to HKLM, the problem was gone.

But regardless of this, on E-E it's not right to accept solutions that "totally missed the point". We will now have to involve a moderator in order to adjust this.
0
 
MichaelJMurrayAuthor Commented:
Opening the MSI in Orca and manually changing the root for the DesktopFolder and the ProgramMenuFolder in the Registry table from 1 or 2, to -1 fixed the problem.  Whether the root is set to 1 or 2 (which are the only options using the MSI generated by VS 2010), the installer package generated by VS 2010 is going to create the namespaces in HKCU, not in HKLM.  Our company policy requires those to be installed in HKLM.  Without installing the desktop and program files registry settings in HKLM, the user will be prompted at app launch for access to the install media so it can create the user's registry settings in the HKCU.  Out-of-the-box VS 2010 deployment package has in my observation no way to create an MSI that will automatically install those namespaces in HKLM.   In our company, we need to install the namespaces for Desktop and Program FIles in HKLM, not HKCU.  So we have an added step to tweak the MSI  registry table with Orca before deployment.
0
 
CSI-WindowsCommented:
Michael,
I guess what I am trying to express is that getting the original error with the registry key hard coded to HKCU location should be fixed by re-coding it to HKLM.  If it is not, then you might be accidentally getting a per-user install.

In this segment from the thread you posted:

"I researched the issue and noticed that even if in VS we have set the property InstallAllusers to true when we open the msi in ORCA MSI Editor the AllUsers propery has value 2 and there is a registry key for desktop shortcut created under HKCU. (The root column has value 1 which means HKCU)
So I modified root column from 1 to 2 which means the registry root will depends on the user's choice (HKLM for "Install for every user" and HKCU for "Just for me".

The bold portion is a wrong assumption. (See here) that is not directly addressed by the Microsoft response.  They had coded it to HKCU (value of 1) and changed it to HKLM (value 2) and it fixed it.

Microsoft then tells them to code it to -1 to get the auto re-direction between HKCU and HKLM.

So if your package now has the registry key coded to -1 and ALLUSERS to 2 you have the possibility of a per-user install succeeding.

If your policy is to have this type of thing (or all packages) only go to per-machine, I would suggest:

1) Set the registry Key to "2" (HKLM)
2) Set ALLUSERS to 1 in the property table. (manual edit)
3) Use a launch condition to make sure ALLUSERS=1 (in VS2010)
4) Remove the dialog that asks whether to install per-user or per-machine. (in VS2010 ? not sure)

Then you will get either a proper per-machine install or an error right up front.

It will also work for automated installs where someone sets ALLUSERS=2 on the command line or a transform - the launch condition in the MSI log will reveal why the package did not run.
0

Featured Post

Free learning courses: Active Directory Deep Dive

Get a firm grasp on your IT environment when you learn Active Directory best practices with Veeam! Watch all, or choose any amount, of this three-part webinar series to improve your skills. From the basics to virtualization and backup, we got you covered.

  • 7
  • 7
  • 6
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now