Hi, the information can be found under OS - Drivers and Services and you can query for name and status.
This information is only as up to date as the last inventory scan that was sent from that machine.
Verismic Software - http://www.verismic.com
Precision Engineering for Systems Management
Check Our New Power Manager Solution
What if I would create a query that shows all computers that does not have a specific service registered or the service exists, but is not running?
I tried to use:
EX1: ("service - name = not exist" and service - name = "Blahblahblah") OR ("service - name = "Blahblahblah" and "service - status <> running"),
but it gives me no results.
When I created two separate queries:
EX2: ("service - name NOT LIKE Blahblahblah")
EX3: ("service - name = Blahblahblah" AND "service - status = stopped")
they both seemed to return correct hosts.
I just can't make it working as one query and have the results combined.
workstation is like a spider's web.. it has components which connect to a server and into other computers.,,
You're misgrouping the items in example one.
A grouping that contains a NOT EXIST can not also contain one that is looking for a match. Its almost like asking, if it doesn't exist AND exists at the same time.
I also see the same problem with the <> not working with identifying services that are not running, so i played with it and found out that it looks like you will want to use > "greater than" to identify anything not running, since all other choices are alphaetically greater than "Running"
So basically change your query to this:
"service - name = not exist"
(service - name = "Blahblahblah" AND "service - status > running")
This is the proper logical arrangement.
either it doesn't exist OR it does exist but its not running.
This Should work. Its working for me :-)
Thanks for discovering this! I didn't realize the flaw. Now, looks like we need to ask our TAM a question about this flaw in the query logic.
A correction to my last post..
instead of service not exists, it would be best to go with service <> "service name", because service not exists, doesn't refer to a specific service. It refers to all entries for service. So basically, if you have an incomplete record without any services listed in a device, then it'll show that. that's probably not at all what you want to return in your query.
In maths there is a rule, so we know that 2+3x5= 17 is correct and 2+3*5=25 is wrong.
However, in logic there seems to be no such rule for precedence so a query in the form "A and B or C" is not clearly defined. I think in LDMS it just starts at the start and works its way through the query.
...so if you ever mix an "And" and an "Or" statement in the same query you should always use the Group function - even if the query seems to give you the answer you expect. It makes it easier for others to understand what you were thinking :-) So my example would become either "A and (B or C)" or "(A and B) or C" depending on what I was actually looking for. The brackets make it clear to anyone else reading my query what I am doing - even though one of the queries would have worked without the brackets.
Thanks for the reply.
It was just my misunderstanding of how "service - name" function works. Let's say I thought that ("service - name = not exist" and service - name = "Blahblahblah") would mean that I defined the service name "Blahblahblah" and I stated that service with such name does not exist on the currently selected machine.
Of course, it was a logical mistake, my bad. But I still don't know why the second part "OR ("service - name = "Blahblahblah" and "service - status <> running")" won't work...?
I also see the same problem with the <> not working with identifying services that are not running, so i played with it and found out that it looks like you will want to use > "greater than" to identify anything not running, since all other choices are alphaetically greater than "Running""
Yeah, that could work - but it would just be simpler to use <> instead, right?
I'm with ya on both counts!
I made the same mistake on the name = and not exists. Really the "Not exists" feature in the query logic has very little use in my personal experience. Its a counterintuitive notion to look for something that's NOT in a DB, but it does serve a purpose for compound search items.
The fact that the "<>" does not actually work in this particular circumstance is a puzzle to me. It seems that it should work, and its exactly how i had wrote a services query for "Windows Firewall" not running. It seemed the intuitive choice. I assumed that the query was working. It wasn't until i read your post here, and started testing it more that i realized that i was getting a false negative.
Glad we're all in here contributing to finding flaws in LANDesk :-)
In principle, I agree with your logic, but there's just one problem.. We're dealing with LANDesk.
In my experience, I've found that groupings can cause queries to explode, so i tend to be very sparing with the groupings if at all possible. I've had scenarios where the simplest of groupings will cause a query to just break, and once its broke, the most efficient course is to delete the thing and start all over. Admittedly its rare, but the fact that it happens at all makes me gun shy with grouping, so even though it would look better, and perhaps interpret better by others, i pretty much stay with the KISS model. If it isn't needed, i don't put it in a query. By having unneeded things\steps in processes, a later editor might make assumptions about a thing. Like, "well it has those, so they must be required!" That's often not the case in life. Obviously, this is just a query in LDMS, but for every interpretation of a thing there might be an equally valid alternate interpretation. In this case its, LANDesk has some strange flaws, so group at your own risk. :-)
Okay, i can't put this thing down until i've beaten the crap out of it, so here's the conclusion i've come to.
What we assume about "<>" is perhaps incorrect. It occurred to me that perhaps "<>" doesn't mean "Does not equals", which in programming is the common interpretation. Based on the behavior of it in a landesk query it now seems that it actually means "Greater than AND also Lesser than", at the same time! This is a serious problem, but it may be limited to compounded queries such as this. Since there's only one possible side that a value can be on in relation to a compared value. Case in point... 5 > 10, but 5 is not also less than 10 at the same time. Thats simply not possible, however this appears to be the outcome with this particular query structure. On a services status value there's only a handful of possibilities. Running, Starting, Stopped, Stopping... there's also the more obscure values such as Paused, and what not, but for this scenario let's just deal with the typicals... So if one writes a query asking service <> "Stopped"... it will not show anything at all. In fact, you can replace the comparison with any of value, it will always return nothing. I suspect it is because a value of "Running" is ONLY less than "Stopped", but not also greater than at the same instance. This is really stupid, but this is how it is working. I then considered the possiblity that this is an alpha character situation and maybe "NOT LIKE" would do a better job. No such luck. "NOT LIKE" returns nothing as well. So i did another test and created a query looking for anything but "Starting". I structured it with (service name = "blah" and service status < "Starting"), then an OR, then (service name = "blah" and service status > "Starting"). BLAMO! It works! All devices with a service status above or below "Starting" show up!
So in closing, it appears that "<>" has mutiple personalities. Sometimes it means "doesn't equal" and other times it means "Greater and lesser) and "NOT LIKE" doesn't help the situation when its encountered.
PS: If you found any of this useful, please mark the question as answered. Would be greatly appreciated on this end.
Good job finding out the LDMS' way of "<>" interpretation. Unfortunately - I can't mark the question as solved, because... it was not me who started the thread.
Anyway - thanks again, dear Watson
Oh whoops! My bad! Yeah, this was a really old thread!
So your query has been answered now..