1 of 1 people found this helpful
You also need to enable real time processing.
The rule will then attempt to run against any scan file that comes in (but not mini-scans, just delta or full). However, the rule can only run if the data it needs is actually in the scan file. For example, if the rule needs the Computer.System.Serial Number field to run (such as a warranty web rule), then that field has to be in the scan file. Delta scans will normally not have the Computer.System.Serial Number, since it does not normally change, so the rule will not run. If a sync scan comes in, then the serial number will be in it and the rule will run.
So you can either drag machines to the rule to force it to run (but that can take some time to complete) or you could send out a task to force a full sync scan that would then return the information for the real-time processing to do it's job.
LANDesk Silver ESP
The One-Stop Shop for LANDesk Enhancements
Update - WoW & State Notifier now integrate for even more functionality
Update - State Notifier now detects machine and user Idle states
Thanks for the replies....I now have a few more questions.
I have checked on the core console and the "real time processing" option is set to enabled. However, the rules do not seem to be processing on every scan. The rule I am most interested in working is a custom rule, which should key on 'Computer.Device Name' so that should be in each scn file. I have also set 'active' the pre-configured rule 'Map Model' to rule out anything in our custom rule. Both rules do appear to run when you force a device to run a Full Sync Scan from the console. They do not appear to run when you do only a 'hardware scan' or 'hardware and software scan' only or on a devices normal daily scan. Currently running 'Managed Planet 9.0.6', LDMS 9.0 SP3.
Any ideas on the above scenario?
Any Data Analytics troubleshooting tips you can share or can you point me to the correct Data Analytics log files to look at?
Your time and assistance is greatly appreciated.
Actually using Computer.Device Name is not going to be in delta scans, since it does not normally change. It will only be in a sync scan. If you want to key off of something that is in every scan file, I use Computer.Device ID. That is always the first line in every scan file.
Thanks, will look to change our custom rule and see if that helps. So 'Map Model' will only run on a full sync scan also because it looks like it keys on Computer.System.Version or Computer.Model or Computer.System.Model? The description leads me to believe that it should run if the 'Computer.Model' field is blank, which is for most of our devices since I just turned the rule on a couple days ago. Unless of course I am missing something.
That is correct. When you turn a rule active, it is usually good to manually run it so that all the current machines get populated and then any new ones or changes get updated by the active rule.
I hope you don't mind me asking a related question (and larfun doesn't mind me hijacking his thread).
If I have a Map Data rule that pulls things in from various other values, and only one of those values changes, how does that get handled by real-time processing? Does it use the existing values in the database, or just those in the scan file?
Additionally, if the Map Data rule pulls in values that themselves are populated by other rules, does it handle that correctly during real-time processing?
A Map Data rule only reads one value. You may specify a whole series of source attributes, but it will only use the first one it finds that matches its validation expression. So if you have several that are sources and only one of them changes. That is the only one that will show up in a delta scan file. So that would be the only one that the rule can use.
When setting rules active the run order is important. When a rule runs, it modifies the scan file and then passes that modified scan file on to the next rule. So for example, if you have say an LDAP rule that pulls in user information and then a map rule that changes that data, you would want the LDAP rule to be run first. Then the LDAP data will be available to the map rule. I hope that makes sense.
I do get the run order thing and have been careful to try to get the Active group's order correct. It's useful to know that it works by passing the updated scan file to each rule, so I think, on that front, things are working as I hoped.
The Map Rule handling sounds like it's not quite doing what I hoped. The order in which it checks a series of source attributes implied to me some order of significance, but in the event that a delta scan only contains one of the source attributes, that value will always take precedence.
Perhaps some context would help. It's surprisingly complex for us to determine exactly which site a machine is located on. I'm using DTS to make it easier.
- AD OU (LDAP Location) is a good start, and generally the best authority, but some machines are deliberately in a non-location specific OU. Or some simply don't have LDAP data, because LANDesk is like that sometimes.
- The first three characters of the machine name is also a good reference, but there are some machines where even that doesn't work, due to non-compliant names or even legacy sites. It's also, as you mention, rarely included in a scan file.
- Last, but not least, is the IP address. I know DTS is designed to work with Default Gateway as the primary location indicator, but a) LANDesk doesn't report a default gateway for machines with a manually configured IP and b) we have users who travel between sites and users who connect via VPN. In both of these cases, LANDesk will report an IP address that does not refect the "Administrative" site of the machine. IP address is actually the least accurate indicator for us.
So, I have:
- Map List rule that maps LDAP Container into a "Site by OU" attribute
- Map List rule that maps (the start of) Device Name to a "Site by Name" attribute
- Map List rule that maps (the start of) IP Address to a "Site by IP" attribute
- Map Data rule that maps the above (in that order or priority) to a general "Site" attribute
Run manually, the above rule stack is pretty damned awesome and gives 99% of devices the right "Site", only really failing when a machine's LANDesk inventory data is broken beyond recognition. However, I've a feeling, in real-time processing, it's not going to work like that as an IP address change will mean the "Site by IP" attribute ends up in the scan file, but no others, so the Map Data rule may overwrite "Site" with an inaccurate value.
I suspect you're going to tell me I'm using a Map Data rule for something they're not designed for, as they're not designed to cater for conflicting source attributes. Is there a better way to do this?
It is always interesting to see what ideas our customers come up with. I can see that this design would work great against the database but not so good against a scan file. However, I think you can still get what you want. Instead of using a Map Data rule at the end, try a Calculate rule. The Calculate rule was designed to work on multiple attributes at the same time. For example, to calculate the percentage of free disk space, it needs to grab both the total space and free space at the same time. One thing we realized with this is that in these situations, perhaps only one of the attributes will be in the scan file and the other will not. So the calculate rule works differently. If ANY of the attributes in the rule are in the scan file, the rule will run and if some of the attributes are not in the scan file, it will pull the value from the database. For example, the total size of the disk did not change, but since it the amount of free space did, the service will look up the total space from the database and use that in the calculation.
So for your situation, I would create a calculate rule that checked the three attributes created by the three map list rules. I would have it do a check to see if the length of the value was > 0. If it was, use that value, otherwise return nothing. That way if one of the attributes is in the scan file, the map list will run and populate it. Then the calculate rule will pull the values from the database for the others. You will need to understand vbscript to use a calculate rule, but we have several examples. I would look at the Computer.Barcode rule as an example.
I have no problems....learning quite a bit.
Tested using the 'Device ID' as the key and my test rule did work fine. So we are configured properly to have real-time processing of rules.
Quick question on a 'Web Import' rule. This is the custom rule I mentioned earlier, it still does not run every time, but does pull needed data when run manually. We were originally keying on 'Device Name', but I have added 'Device ID' as the first listed option. No changes were made to the script that actually pulls the data from an external database. 1. What gets passed to the script in a Web Import rule? 2. Do I need to alter the script to accept two values, discard the 'Device ID' value and use the second passed value (Device Name which we need to match in the external db)? Thanks again for all the assistance, learning alot.
Just re-read your above post....maybe a Calculate rule here also since 'Device Name' will not always be in the scan file? Can a calculate rule be setup to pull data from an external db using the script we use now? Just looked at Calculate Rules, don't think this will work....
Hmmm, you really seem to be mixing up rule types. A web import will access a web page, but it seems you are talking about a Data Import rule instead.
Let me see if I get this correct. You have an external db that you want to always pull data from (I assume it gets updated periodically). The only link between that DB and LANDesk is the Device Name. So you want the data to be pulled from the external database after every scan, not just when the data changes in the scan file.
I believe you can do what you want, again with a calculate rule. You want the calculate rule to always run, so you should put in Computer.Device ID as one of the attributes. Since the calculate rule can also pull data form the LANDesk db, you can use that to get the Device Name and put it in the scan file. I would create a rule with destination of Computer.Device Name and script something like the following:
stemp = "!Computer.Device ID!"
retvalue = "!Computer.Device Name!"
Having Device ID causes the rule to always execute. The rule then returns the device name that is the db and puts it in the scan file as Device Name. Then have the db import rule set to run after this rule and it should do what you want.
Now that is a useful technique.
Maybe a useful feature to avoid the need for that workaround in a future version would be to have something like a "Forced Active" option for rules, so they always run on new scans, and in that mode they'll pull any attributes from the DB that are missing in the scan file, like a calculate rule.
DaveE, appreciate all the information....
You do understand the situation exactly. We went with the Web Import rule because the script gives us more control over how we get the information from the external db. I have tried your suggestion, created a Calculate rule as you specified (verified that it fires off on normal scans) but our custom Web Import rule still only pulls or updates the data with a manual run (dropping targets on rule) or forcing a Full Sync scan from the console. When testing to see if rule is running, I am running a hardware only scan of my device, after changing data in the external db.
Could my method of testing to see if it is working be flawed?
With this setup, what gets passed to our custom rule and how does it get passed to our custom rule?
I will also agree with Richard's suggestion for an option to check that makes rule run for any and all scans.