NI Package Management Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 

Reduce need for elevated privileges for NI Package Manager

It would appear that NI Package Manager requires elevated privileges via User Account Control to even run.

Whilst clearly for some actions this will be required for some install/uninstall actions and e.g. changing registry entries, it isn't clear why this is needed simply to open Package Manager to view what is installed and for other actions which may only make JKI VI Package Manager type changes to VIs within vi.lib etc.

 

If the medium/long term plan is for NI Package Manager to replace JKI VI Package Manager then it needs to support the ability for developers to easily add/remove VI packages without requiring IT administrator assistance each time.

It would be much better if the application was structured such that elevation is only required when this is absolutely necessary for the actions being undertaken at that moment and/or the user is able to explicitly run the application with elevated privileges where these will be required.

I did try to post this in Additional NI Software Idea Exchange and that wasn't possible but please move this should there be somewhere more appropriate.


Adam
8 Comments
Active Participant

Agreed. Microsoft themselves state a design goal of UAC should be to "eliminate unnecessary elevation" (per this article).




Certified LabVIEW Architect
Unless otherwise stated, all code snippets and examples provided
by me are "as is", and are free to use and modify without attribution.
Proven Zealot

I am flagging this idea for the NIPM team.

Member

Hi All, I just want to acknowledge that this request has reached R&D and we agree that it is a good idea. It is on our backlog to consider for a future release.

 

Thanks and keep the feedback coming!

 

Aaron Peña

Product Owner, Package Management and Licensing

Active Participant

Hi All,

 

I spoke about this with you (Aaron) at the european CLA summit and I believe this should be a high priority item to get included into the NI Package Manager. I dream of a day I can point my colleagues to the NI Package Manager so that they can install turn-key NI solutions that we have made straight onto their machines without having to involve IT. It would also be great to distribute all of our custom toolkits for the various NI software platforms that we have. At the moment we are using an application I created to manage installs of packages separate from the NI Package Manager that requires no admin rights (however it is a pain to maintain and is not the right way to do things).

 

Also, to put a number behind this, I currently have over 100 people using a piece of software created in LabVIEW that allows sequencing of hardware. Every update I make I need to get these 100+ people to contact IT and get them to run a new installer (since some dependencies may have changed). I can tell you now, IT are never happy with me as I constantly create work for them Smiley Sad


Larry Colvin
Associate Principal Engineer
Dyson Technology Ltd.

Member

Hi All, 

I am trying to deploy LabVIEW VIs by using NI Package Manager. I am building the package using NIPKG from the command window. The issue is after deploying If I want to edit and save those VIs it is asking for admin permission. Is there any way where we can remove that permission while building?


Proven Zealot

> Is there any way where we can remove that permission while building?

 

No. By design, anything installed is not meant to be touched. That is a hard wall that we do not intend to weaken. If you want to change files after they are installed, the intent is that you need to rebuild the installer and install a new version.

Member

I second thread opener's request and want to add following feature:

 

In current version, you need admin rights to deploy a package - if you install it as "normal user", you could enter an admin login during deployment.
In several cases, this workflow (admin right required, but you could use adml-account during deploy) seems oK - But, as I observed:

If, for example, a package is deployed in a user-specific folder, e.g. "Desktop", all content is currently deployed in admin's desktop (e.g. adml_thamberger's instead of thamberger's Desktop) -> so in this case, after deployement, package is again not visible for the normal, unpriviledged user.

Of course, in some cases you may choose your paths more cleverly - but anyhow, this trap currently exists...

Member
Status changed to: Under Consideration