I've been trying to make use of the LANDESK Workspaces in my 2016 LDMS, however I can't get certain scenarios to work correctly and I have not found good documentation on how to do it.
Basically, I want to be able to control what users can see depending on their user accounts, not based on their machines. Let me paint the scenario:
I have Software_A. It's a per user licensed software, so I don't want to publish it to all users. Only users that are part of an AD group which gives access rights should get the ability to install this software, along with my helpdesk AD group.
Now, the AD piece is fairly straightforward, however when I use an LDAP query as the target, even specifying the user objects, it takes that LDAP user and tries to guess which machines belong to those users. Of course, this is completely inaccurate, especially if they are shared systems, or if it is looking at a tech's account since they can be flagged as the owners on multiple systems. I'd like to get it to a point where I can say... if you are part of this AD group, then you should see the option to install Software_A no matter where you log in.
Are there any documents regarding how the workspaces work (not in SD, I'm talking about the super gimped one that comes in LDMS that was supposed to be upgraded in March....)? How do we manage what end user's can and cannot see (there's no reason for end-users to see Task Summary or any other fields but their Software Catalog)?
It seems like it is right there to become a good solution, but the management part completely falls apart.
(My goal is to have a proper RBM structure in AD by roles. If a user gets added to a role, they'll be able to see all of the applications available for them to self-install. Techs will be able to log into anyone's system and be able to see a list of all available software, no matter the role. I know I can browse to the system and select 'Install Software', but that list is extremely unwieldy as I can't control what is on it, it just pulls all packages that the user's scope allows, which for admins is extremely long)
This is probably not what you want to hear, but, in newer versions Agent State will provide a more real time status of the machine including logged in user. I have not tested it yet but theoretically you could target the logged in user as provided by Agent State. 2017.3 is the first version that has Agent State incorporated, however, a later SU (SU1 I believe) changes the evaluation cycle time to 1 minute.
As I said, I have not tested, it's theoretical, but it seems like this would be a valid path. If you have a test system it would probably be worth it to test.