Confusion creating installers using 3.0

[Daklu]

I'm a little bit confused about the relationship between groups and installers.  My understanding is that Groups specify which licenses are granted to individuals while Installers control which packages are installed on the target computer.  Is this correct?

Assuming that is correct, what are my options for creating installers in this situation?  We have several flavors of Dev Suite licenses as well as several flavors of Labview licenses.  I'd like all the Dev Suite users to install a common set of toolkits regardless of the specific license they use, and all the Labview users to have a different set of toolkits installed.  However, I'd also like to have all the packages available on our network so users can install trial versions if they want to.

To avoid unnecessary disk use, I'd like to copy all the files from the Dev Suite disks over to our network and have the installers use them.  But when I create the installers they copy all the packages from my _SourceFiles directory into the directory for each installer, meaning I have 3 copies of some files on my install server.  I know there was a way around this in previous versions, but I don't remember how to do or if it is possible with v3.0.

[Michael_W.]

Hi Daklu,

It sounds like you have a good understanding of Groups and Volume License Installers (VLIs).  Groups are created to help you as the admin and the your users request permissions without having to micromanage individual permissions.

In this case, you can create one VLI using your most complete DevSuite package as the source.  When a user chooses a group, only the software licensed by that group will be selected for installation by default.

For example, in the following image I request to join a group that gives me permission to check out LabVIEW but nothing else:

Then I'm presented with all of the software included in the VLI but only LabVIEW is selected by default:

In this way, you can avoid having duplicate installers assuming all your software falls under one DevSuite umbrella.  Feel free to post back if you have further questions!

Cheers,

Michael Waage

Applications Engineer

National Instruments

[anivlmuser]

Building my first VLI using the new NIVLM 3.0 interface. It looks like "Groups" are replacing the earlier VLI "License Sets"?

I was using License Sets on my VLI to allow end-users to run the license set that corresponded to their serial number (both linking and naming each license set in a VLI with the serial number). Is there any reason I couldn't (or shouldn't?) continue to do this with the new "Groups"?

For example, will I now be building a Developer Suite VLI with several Groups that named after the serial numbers / packages they are assigned?

[Anna_K.]

Hello, yes you will use groups the way you used to use License Sets. However, unlike license sets in previous versions of NI VLM, groups do not need to be created each time a new volume license installer is created. This saves time when updating volume license installers. Also, if you receive a new software license for the VLA, you can add it to the applicable groups without updating any volume license installers. When you add it to a group, all users or computers in that group will have permission to use the software.

Groups should contain common sets of software. If 5 people are using LabVIEW Full Development System and LabVIEW Real-Time Module, 10 people are using Developer Suite Core, and 15 people are using LabVIEW Professional Development System, LabVIEW Real-Time Module, and LabVIEW FPGA Module, it makes sense to have 3 groups with those software licenses.  A group is not limited to one media set; it can include permissions for software from different media. If some people commonly use LabVIEW and TestStand, they can be in the same group even though the software is located on separate media sets. If someone does not fit within a group or groups, you still have the ability to assign an explicit license to the user.

Items within a group are not unique to only that group, they can overlap. Multiple groups can have the same license type. For example, LabVIEW FDS might commonly be used in the VLA so LabVIEW FDS named-user licenses would spread among several groups. This method is not the same as licenses shared among a pool of users in a concurrent license; each license will be assigned to one user in one of the groups. Also one person can belong to multiple groups. If someone needs LabVIEW Real-Time Module and LabVIEW Datalogging and Supervisory Control Module and the licenses are in 2 groups, the person can belong to both groups. NI VLM is smart enough to not check out two licenses for one person if the groups share software license types.