none
Install for "All Users"

    Question

  • I am curious of how best to handle the situation of installing a VSTO addin for a non administrator user, when installing VSTO Redistributable requires the user to be an admin.

     

    If an admin could install the VSTO Redistributable and the addin (configured for all users) it would simplify distribution and setup of the application.

     

    Any thoughts would be helpful.

    Thursday, April 12, 2007 2:41 PM

Answers

  • Hi LastHope -

     

    Today is a good news, bad news kind of day.

     

    Good news! Installing an add-in for a local user is MUCH easier as a LUA with the new Office 2007 settings. No COM registration is necessary, so a LUA just needs to be able to write to HKEY_CURRENT_USER. In other words, any user can install any number of VSTO 2005 SE solutions without a problem -- as long as the VSTO SE runtime is installed on the machine.

     

    Bad news: the VSTO SE Runtime needs to be installed by an administrator.

     

    There is, unfortunately, really no way around the requirements for the VSTO runtime to be installed by an administrator. Apparently, there is a limited version of Group Policy for per-machine setups, but that is outside my knowledge ("Local Group Policy"). http://technet2.microsoft.com/windowsserver/en/library/16f4f08d-4a1d-485c-841b-d7387615cc151033.mspx?mfr=true should hopefully point you to something that might be able to help you.

     

    Good news: the same step that installs the VSTO Runtime should have no problem installing for all users in HKU, rather than HKLM.

     

    Sorry I don't have better news; the individual add-in can be installed/uninstalled on a per-user basis; the runtime, however, needs to be system-wide.

     

    Andrew

    Monday, April 23, 2007 6:14 PM
  • Hi LastHope -

     

    Local Policy does not exist for XP Home, from what little I could find.

     

    An Outlook 2003 solution being run against Outlook 2007 will not actually activate the magic "special loading" switch in Office 2007. Ergo, the HKLM key will continue to function.

     

    That is very much NOT the recommended route, but it will work in Outlook 2007.

     

    Of course, it's also unsupported. Given the constraints you're specifying, the only other option is to write a Custom Action that writes the HKCU\Software\Microsoft\Office\<App>\Addins\* keys to every user in HKEY_USERS -- of course, that has the disadvantage of needing to handle cleanup, and only the Administrator having the ability to patch the MSI.

     

    Andrew

     

     

    Monday, April 23, 2007 9:19 PM

All replies

  • This really depends on -your- situation. What is it you want to do.

     

    An example, in my office the VSTO runtime is pushed to the domain users, and the security is handles through group policy. That works fine for all users.

     

    -= Maarten =-

    Thursday, April 12, 2007 8:06 PM
  • I'd like to distribute a VSTO addin for Outlook 2007 that can be installed and run by a non-admin user.

     

    Unfortunately, the VSTO runtime cannot be installed by a non-admin user and the VSTO addin, if installed by the admin user, is not available to the non-admin user because VSTO addin applications cannot be installed for "All Users".

     

    Therefore, an Admin user must first install the VSTO redistributable, then the user must install the addin.

     

    I would prefer to package the VSTO redistrib in the setup with the addin to allow a user to download and install both VSTO and the addin in one shot.

     

    I am probably just going to have to caveat the addin with "User must have local admin rights".  (I guess I won't score any ISV app-certification points for that one)

     

     

    Thursday, April 12, 2007 9:05 PM
  •  

    The answer to your question is yes and no.

     

    For the VSTOR:

    You must be an administrator on the computer to install the Visual Studio Tools for Office runtime.

     

    There is however a workaround to install the addin to All Users. Something to do with switching the regkeys, read the thread in:

    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=357677&SiteID=1

     

    If you pull this off, you eliminated the two pass installation and the Addin is available for all users after being installed by the administrator.

     

    Hope it helps...

     

    -= Maarten =-

     

    Thursday, April 12, 2007 11:31 PM
  • I'm glad you pointed out the solution of changing the registry keys...I'd like to ask something: since many developers wrote about the fact that if you change the registry keys, the VSTO add-in won't be loaded as a COM add-in in the list of the COM add-ins (which is VERY annoying).
    Has this been fixed with VSTO SE? Is it possible to use BOTH keys? (currente user and local machine?)
    Friday, April 13, 2007 11:16 AM
  • The HKLM/HKCU distinction actually causes some complications, and was designed the way it was for a reason. Just switching to registering in HKLM is actually somewhat ill-advised.

     

    HKLM was intended to hold system-wide, admin-mandated COM Add-ins. Hence, in Office 2003 and previous, the COM Add-Ins dialog doesn't display the Add-Ins loaded by that key -- both to prevent casual users from disabling required Add-ins, and to restrict attempts to modify the HKLM key that non-administrators should not have access to. If you're logged on as an administrator, actually, you should be able to see the HKEY_LOCAL_MACHINE specified add-ins.

     

    HKCU was always intended to hold the add-ins intended to be controlled by the user. In Office 2007, the decision was made to display all Add-in entries in the COM Add-ins dialog (group policy constrained); however, without appropriate system permissions, an end user would still be unable to turn off HKLM-specified Add-ins. In order to move further into the direction of permitting user-based applications, rather than system-wide changes, the new Office 2007 will only load VSTO 2005 SE solutions that have been registered in HKEY_CURRENT_USER -- entries in HKEY_LOCAL_MACHINE will not be loaded. In Office 2003 (using VSTO), the solution will still be loaded, but this isn't supported moving forward.

     

    The preferred mechanism is to install the Add-in into HKCU; Group Policy can push your MSI down for every individual in an enterprise-scale solution regardless of system, and the question of whether you should force every user on a given machine to run your add-in comes into play on the smaller scale -- particularly given that they won't necessarily have the ability to uninstall the add-in.

     

    Thanks,

    Andrew Cherry

    Monday, April 16, 2007 10:29 PM
  •  

    Andrew, thanks for your clear information. Good to read some facts on how this is handled and with the destinction between Office 2007 and other versions.

     

    In the 'real' world it must be kept in mind that there is however a large portion not 'controlled' by group policy. This is making it hard (especially for those who are coming from VBA) to get the tool deployed without the pain where some items have to be installed as 'administrator' and the addin as 'user'. I know it's trendy to get all deployment done by the IT dept. but there is a large group out there without IT departements.

     

    The 'advice' to switch registry keys therefore certainly wasn't a solution to the issue presented here but often proved to be a workaround, evidently used a lot if you read previous posts in this forum.

     

    That said, the workaround to switch registry keys is - as you mentioned in your explanation - not preferred, not supported but can be used for as long as it works and you are helped and if it breaks you own the pieces .

     

    -= Maarten =-

    Monday, April 16, 2007 11:59 PM
  •  Andrew Cherry [MSFT] wrote:

    The HKLM/HKCU distinction actually causes some complications, and was designed the way it was for a reason. Just switching to registering in HKLM is actually somewhat ill-advised.

    HKLM was intended to hold system-wide, admin-mandated COM Add-ins. Hence, in Office 2003 and previous, the COM Add-Ins dialog doesn't display the Add-Ins loaded by that key -- both to prevent casual users from disabling required Add-ins, and to restrict attempts to modify the HKLM key that non-administrators should not have access to. If you're logged on as an administrator, actually, you should be able to see the HKEY_LOCAL_MACHINE specified add-ins.

    HKCU was always intended to hold the add-ins intended to be controlled by the user. In Office 2007, the decision was made to display all Add-in entries in the COM Add-ins dialog (group policy constrained); however, without appropriate system permissions, an end user would still be unable to turn off HKLM-specified Add-ins. In order to move further into the direction of permitting user-based applications, rather than system-wide changes, the new Office 2007 will only load VSTO 2005 SE solutions that have been registered in HKEY_CURRENT_USER -- entries in HKEY_LOCAL_MACHINE will not be loaded. In Office 2003 (using VSTO), the solution will still be loaded, but this isn't supported moving forward.

    The preferred mechanism is to install the Add-in into HKCU; Group Policy can push your MSI down for every individual in an enterprise-scale solution regardless of system, and the question of whether you should force every user on a given machine to run your add-in comes into play on the smaller scale -- particularly given that they won't necessarily have the ability to uninstall the add-in.

    Thanks,

    Andrew Cherry


    (Damn, I usually answer in this forum by cjhecking MSN, and has been closed ofr days! Stick out tongue)
    OK, as I said on another forum (and as Marteem has pointed to you), please tell me: what is at this point a possible work around for a Limited User Account, without an IT department on his own, that could push the addin MSI, to install and correctly load a VSTO SE add-in both in Office 2003 and Office 2007?

    Anything that might work on a smaller scale, to reproduce a "GroupPolicy" on a same computer (please, I really don't know [yet] of IT deployment, so maybe what Andrew told us might work on a single computer either?)

    Really, I don't know what to say to some users : "Please stick with Office 2003, switching to Office 2007 and the Add-in won't work as you're LUA...now you cannot see it in the COM Add-ins list, but hey, it damn works!"
    Friday, April 20, 2007 9:58 PM
  • Hi LastHope -

     

    Today is a good news, bad news kind of day.

     

    Good news! Installing an add-in for a local user is MUCH easier as a LUA with the new Office 2007 settings. No COM registration is necessary, so a LUA just needs to be able to write to HKEY_CURRENT_USER. In other words, any user can install any number of VSTO 2005 SE solutions without a problem -- as long as the VSTO SE runtime is installed on the machine.

     

    Bad news: the VSTO SE Runtime needs to be installed by an administrator.

     

    There is, unfortunately, really no way around the requirements for the VSTO runtime to be installed by an administrator. Apparently, there is a limited version of Group Policy for per-machine setups, but that is outside my knowledge ("Local Group Policy"). http://technet2.microsoft.com/windowsserver/en/library/16f4f08d-4a1d-485c-841b-d7387615cc151033.mspx?mfr=true should hopefully point you to something that might be able to help you.

     

    Good news: the same step that installs the VSTO Runtime should have no problem installing for all users in HKU, rather than HKLM.

     

    Sorry I don't have better news; the individual add-in can be installed/uninstalled on a per-user basis; the runtime, however, needs to be system-wide.

     

    Andrew

    Monday, April 23, 2007 6:14 PM
  • Dear Andrew,
    thank you very much for your kind response...but maybe I should specify in a better way my use case.
    My Add-in was initially developed to work with Outlook 2003, and that remains the main purpose...however, some of my users have switched to Outlook 2007, so I'd like to mantain compatibility (that means: a user will install Outlook 2007 over Outlook 2003, and opening the add-in will still load)
    With Outlook 2003, the only way for a LUA to install a VSTO solution was to switch the registry keys...since I switched to VSTO SE (which allows add-ins compiled for Outlook 2003 to work perfectly with Outlook 2007) I didn't change the registry keys because I wanted to check what happened with this version, and it's hard to decide what to do (If I change registry keys, Outlook 2003 LUA will be able to install, Outlook 2007 not...and that's the same on the other side)

    I'd like to thank you for your link...I'll try to get a look for local group policy (it's terrible that I'll have to specify different install instructions for Windows XP Home and Pro editions Sad )
    Monday, April 23, 2007 8:44 PM
  • Just a last question: do you know where I could get more informations on this (forum, mailing lists...)...I've started following the guide, but I cannot event open my Local Group Editor (gpedit.smc not found...sigh...and I'm using my administrator account...) Sad

    EDIT: I'm using Windows XP Home edition...so it seems that really it doesn't exist something user-friendly for this kind of users...then this is the worst case scenario:

    Using Windows XP Home Edition, one Administrator + X LUA...how can I make the add-in available without any problem?
    Monday, April 23, 2007 8:54 PM
  • Hi LastHope -

     

    Local Policy does not exist for XP Home, from what little I could find.

     

    An Outlook 2003 solution being run against Outlook 2007 will not actually activate the magic "special loading" switch in Office 2007. Ergo, the HKLM key will continue to function.

     

    That is very much NOT the recommended route, but it will work in Outlook 2007.

     

    Of course, it's also unsupported. Given the constraints you're specifying, the only other option is to write a Custom Action that writes the HKCU\Software\Microsoft\Office\<App>\Addins\* keys to every user in HKEY_USERS -- of course, that has the disadvantage of needing to handle cleanup, and only the Administrator having the ability to patch the MSI.

     

    Andrew

     

     

    Monday, April 23, 2007 9:19 PM
  • Hi.

     

    I tried to switch the registry keys from HKCU to HKLM, logged out and logged in with a different user (not local administrator on the computer) but then the addin wouldn't load.

    It would still work for the first user though (the one who installed the addin).

     

    Tried to make the second user local administrator on the computer and reinstalled the addin using the repair option, that seems to work.

     

    But how can I get it to work for all computers without having to reinstall it or beeing a local administrator?

     

    Regards,

    Håkan

    Monday, June 25, 2007 12:25 PM
  • Hi Håkan -

     

    Assuming you're talking about Outlook 2003, it's possible that the COM registration portion of the install was placed in HKCU subhive (HKCR is broken down into HKLM portions and HKCU portions, and dynamically merged). Especially if it worked when repaired, it sounds as if something related to the installation still wasn't being transferred over.

     

    In addition, the runtime still needs to be installed as an administrative task, so determining whether the runtime's registration or your solution's registration will take a bit of work; look for AddinLoader.dll in the registry on both a working account and a non-working account. If you see a difference, in all likelihood your solution was still registered for only the first user. If both users seem to share the same data, it's possible the runtime didn't install properly.

     

    Without more information on what changed when you repaired your setup, it's only guessing from this end.

     

    Andrew

    Sunday, July 08, 2007 11:17 PM
  • Comments removed by User 7/26/07

     

    Started new thread: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1917947&SiteID=1

    Tuesday, July 24, 2007 2:42 PM
  • Comments removed by User 7/26/07

     

    Started new thread: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1917947&SiteID=1

    Tuesday, July 24, 2007 4:31 PM
  • Hi Martin,

    Are you able to share how did you do it. I am about to do the same thing as well. Thanks.

    Dennise
    Tuesday, January 19, 2010 5:07 AM