I'm trying to plan for a migration but need to target the application to users in particular active directory groups. Problem is that I also need to be able to easily identify machines that have a particular configuration. Can anyone tell me how I could combine an Active Directory Query and an Inventory Query so that I can both target and report on the potential targets?

Nem - the only way I'm aware of where this can be done easily is to use our ADGroups module. It's a free utility that you install on your core server and it looks through the inventory database looks up the group membership of the logged on user, and then puts that group membership information directly into the inventory database. It was designed with your type of requirement in mind.

There are two versions. The 'Lite' version is the free one that you run whenever you want and then you can run your reports and target. The 'Pro' version is chargeable and gives you an automated schedule for updates plus it detects when the logged on user changes and updates the membership immediately. The pro version also populates the machine information, more user information such as location, email address, phone number etc, and it also does this for the primary user as well.

It is a low cost as we think its really useful so will cost in the region of $500-600 dollars as a one-off fee (if I remember the price correctly). For more information take a look at http://www.networkd.com/LANDesk_Add-On_ADGroups.html. You will be able to use the pro version for 30 days if you want to try it out.

Maybe some more specific information may help us come up with a solution. So with my assumptions on what you are trying to do is:

So you can have a LDAP target that identifies either users/workstations. Probably users. So just target the users you want to hit - This is the large net.

So then you probably want to filter on something machine specific. You could use prereq queries or dependant packages based on your requirements - just guessing at this point.

Or you could script something in the package that makes a decision based on something on the workstation.

Example - I target the 8.8 client to specific custom LDAP queries we write, however, I have a prereq query that will not allow it to install on machines where the client already exists.

If you let us know what specifically you want to accomplish we may be able to mix something up. Am I close?Not trying to tread on Mark and Mark's utility just trying to see if a native approach is doable.

Thanks zman. I know i can do this with pre-requisites but that doesn't help me report. I want to be able to run a query that tells me who the targets are likely to be be so that I can report to the respective department heads to let them know what the potential costs of the upgrade are. I'm sort of stuck with the way it work now with having to perform the distribution and see if it works before I can work out whether I can proceed. Unfortunately that won't work for me because I can't have half the targets on one version and the other on an old version because of file format issues. This is complicated because these people are distributed across multiple offices and other departments use the same app but will not be upgrading.

Access to the app is controlled by group membership, so I want to identify those that have the app, are authorised to use it because they are in the right departmental group, but match/don't match the application system requirements. After that I can arrange for the appropriate software/hardware updates and then target the distribution with a pre-req attached knowing that any I can't install to are now the exception rather than the rule.

Mark, I am downloading adgroups now and will take a look. It sounds promising but I'll need to test it and I'll let you and others know if it worked for me.

Cool. One issue with LDAP reporting/syncing, at least in my shop, is that there is not a one to one relationship between user and computer (e.g., one user to one computer with no roaming profiles and users never logon to a different workstation). If you have a 1:1 god love you. Our problem is our users roam all over the place. We have machines with over 200+ profiles, etc.. So at any given inventory scan the ldap information reported back is just for that current user.

Yes this is a very difficult issue, since software 9 out of 10 times is licensed per workstation installation. So you can very easily provide a report of ldap group membership, but that does not really give you total possible amount of installs since Sally can install the software and run it on multiple workstations. So if NetD's utility works for you then you are golden. If not you will most likely be exporting out to excel and doing a Vlookup table. There are numerous ways to get ldap information either into LANDesk or aftwerwards into reports. A freeware Excel plugin Memm allows for LDAP lookups within excel. Great for exported CSV files.

One other thing you might want to consider that also addresses zman's point about users moving around is the data that LANDesk does collect in this area. Take a look at the inventory of a machine and you will see LDAP location and Primary User.

LDAP location is the location of the machine account in AD. If you have that well structured, then perhaps you can use this in your query.

Primary user is the person normally using this machine and that also shows location in AD although not group membership. If the structure matches your needs than perhaps you could target against this and because it is the normal user rather than the last user it would asnwer some of zman's concerns.

Mark (Star) - thanks for that, it looks pretty good but looking at our environment unfortunately we just don't have that level of structure in our OUs so close but no cigar i'm afraid.

Mark (McGinn) - I downloaded ADGroups and tried it out. I have to say that it ran beautifully and gives me exactly the information I need to do this. I'm going to run with it for the trial period to make sure it performs as expected but so far it looks really good. I can also see how I can use this information to produce better reports as well for each of our departments. Unless someone else comes along with a better option I might be blowing the dust of my corporate credit card.