Consumption showing admin users
Whilst investigating a non-compliant licences I realised that the non-compliance was due to FNMS reporting support staff who had logged onto a PC as being users of the device in addition to the registered own of the device. Even though they did not start the application concerned they were reported as consuming a licence.
Also, we have two users sharing a device and they are both reported as consuming a licence even though one swears he has never started the application.
This has prompted two questions.
- Can we legitimately disregard admin accounts when calculating consumption and, if so, can this be taken into account on the dashboard.
- If we use a tool such as AppLoader to restrict access to applications will FNMS reflect this in consumption reports?
I'm new to FNMS so any advice welcome.
This thread has been automatically locked due to inactivity.
To continue the discussion, please start a new thread.
For #1, if you are following security best practice and the support people have an account for them to do email and other functions and a separate account for doing administrative work (usually a standardized method to differentiate the two) you can blacklist the Administrative accounts the same as service accounts.
Thanks for your reply.
For #2 I think there is an opportunity for debate here. For user based software the EULA will usually say that you need a licence for any user who can run the software. AppLocker will stop a user from running an application if they are not in the security group for it. However, FNMS reports the calculated user for a device so will presumably report that the user needs a licence even if AppLocker is stopping them from using the application.
How are you bringing the AppLocker restrictions into FNMS so it knows about it?
I know that the App-V 4.6 connector will flag a device as having an application installed if it is presented to an individual. Every user of the shared PC after that gets flagged as having access to the software and counts it as consumption.
Keep in mind, you may be able to meet the contract rules that way, but how are you going to get FNMS to manage to the rules you want it to follow.
"How are you bringing the AppLocker restrictions into FNMS so it knows about it?"
That was really the basis of my question. AppLocker is built into Windows 10 when bought through a VLSC agreement and is expected to be a widely used method of restricting access to applications.
Perhaps I should be making an enhancement request for a future release of FNMS to recognise AppLocker Security groups.
You still should be reviewing your License Agreements with your publishers. They may not take a tool like AppLocker into account. For example, look at a standard agreement for a Device-based license. If an application is installed on a device, it must be licensed whether it is used or not. So even if AppLocker is used, the install of the application needs a license.
The same may be true of some of your User-Based licenses. If it is installed on the device, then the user(s) associated with the device where the application is installed may need a license. Regardless of whether or not the user(s) have launched the application or even if they are not able to launch it.
@kclausen Thanks for your contribution. We wouldn't use AppLocker on device based licences, though these are becoming few and far between these days.
Software Licensing is certainly a minefield. We have one publisher who insists that we put measures in place to stop anyone who logs onto a device from starting their software, otherwise we have to have a licence for everyone in the company because, theoretically, any of them could log onto the device!
If the publishers terms allow restriction of access using Applocker or similar and only those users with permission can access/run the app then I recommend the following; rather than a User license, create a Named User license and allocate those users with permission to the license (enabling allocations consume license entitlements use right - so even if we don't find that user currently from last inventory on a device, as they could run it they should consume a license).