In your query you can add the component for local user and then add a qualifier of the accounts you want.
can you give me an example ?
cause i don't see another's parameters to add who can give me the exact information
What exactly are you trying to get? Can you describe a little more / provide a mock up photoshop/screenshot of what you want to achieve)?
Also - what version of LD do you use? This isn't related to "please update" - but if it's easier to give you an example LD-query, I could whip one up on the relevant version of LD and export / copy/paste its text here & you can import it then to look at.
LANDesk's data relationship paradigm is centered around computers / devices -- so if you just write a query to select "list me things that have local administrator groups" then yes - we're going to respond with "every computer in this list has a group of "local administrator" " ...
If you're trying to report "Please list me - for every device - which local user is part of the local administrators group", then that needs to be done via column sets .
Here's a screenshot of a query I whipped up on the quick:
* See that I'm querying for the "Local group" with the name of "Administrators" - this will pre-filter my result set to ONLY include that bit of data.
* I'm also adding the data column for "Members" (bottom right) - so I can see who are the members of the Local Administrators group.
The results of that looks then like this:
It's also pretty easy to haul this data out of the database (if you JUST want to have those strings that'll be easier to pull). In that event, you'd be wanting to look at the LOCALGROUPS table.
Hope this helps?
Hello phoffmann ,
Thank you for your answer. I did the filter in your query, but the problem is that if I have two different administrator accounts on the same machine it fate me the result on the same line in "Members" instead of having two lines that match each accounts.
The query is correct but the treatment is not very clean.
Well - you're dealing with a single string-value that is an amalgamation of all members.
From a DB-efficiency view, it does what it needs to - it allows you to check if a user - such as "JoeSixpack" - is included in a group or not easily, and doesn't waste more DB space on 1:* (one to many) style entries (for instance - software information tends to be in a one-to-many style format) as there are a lot of additional attributes that matter to each "item" that need to be added.
Group-members are just "a list of names" and as such would be rather wasteful from a DB-perspective ... it's much neater to have 1 line per local group item per device, than "X"-many items ... and the list of local users & memberships can get out of control pretty fast - leading to an very busy & heavy line-count table ... which would be "nicer" for this specific request, but not really ideal from a performance & data handling perspective.
So there's quite a bit of reason behind the design decision. Bear in mind that the LD database can get quite big "as is" and we have to try & ensure that it
If you want the cleaner version, I pointed out the DB fields that you can extract the strings from, and you can then script the data handling side of things.
You can split strings up very easily through scripts (I would personally recommend getting friendly with PowerShell as it's very versatile & gets to interact with a LOT of other systems pretty easily). And it's got plenty of google-able resources.
Here's a few conversations / articles on splitting up strings via PowerShell for instance that you can use as a basis for your needs: