How to mass manage Blocked Inventory Items / Blocked Unknown Items

Version 8

    Verified Product Versions

    Endpoint Manager 9.5Endpoint Manager 9.6Endpoint Manager 2016.xEndpoint Manager 2017.x

     

    I - Introduction

    This article covers how to (mass-)manage the handling of items blocked by the Inventory Service, because of them not being approved.

     

    Normally an item that's recommended to be checked every week (or every two weeks), it does sometimes occur that this is forgotten for months (or even years) at a time. And by the time it's actually revisited, some 10,000+ items have gathered ... and the prospect of managing these manually can be quite daunting.

     

    This article will provide you with information to handle this situation and mass-manage this.

     

    II - Database Structure & Key Tables

    As with most advanced operations, we'll be dealing with direct SQL access. In this case, however, the number of tables to be looked at is very straight forward.

     

    Key tables are:

    * The METABLOCKED table

    * The METAIGNORE table

     

    That's pretty much all there is to it - a lot of responsibility in two small tables.

     

    II.A - The METABLOCKED table

    Despite its name, it's actually *NOT* a list of unmodelled data that's "blocked by the user" - rather it's all of the unmodelled data that's blocked because the "Block Unknown Items" option is enabled in the Inventory service.

     

    Anything that's new gets registered here. This is the table that gets read for contents when you look at the contents of the "UNKNOWN ITEMS" section for the Inventory service settings.

     

    II.B - The METAIGNORE table

    This table lists what BNF data has been actively set to be ignored.

     

    This table shouldn't messed with, EXCEPT for a (hopefully rare) case in which you've unintentionally set some "good, expected" unmodelled data BNF to be ignored and seek to rectify that mistake.

     

     

    II.C - Sideline - BNF? What's a BNF?

    BNF stands for "Backus-Naur Form". It's a method to formally and mathematically describe and define a language.

     

    In less technical speak, it's to help translate things in a more abstract, and more intuitive way. For instance, the LANDesk Inventory tree uses BNF in such a way that the average user only needs to know that his desired data sits in:

    Computer - OS - OS Name

     

     

    ... for instance. This abstractions is MUCH easier to remember than knowing what DB-table to look in for the operating system name.

     

    Essentially, this "data pathing" is the BNF that LANDesk uses to make the database-side of things much more transparent & accessible to most users (and uses).

     

    In this particular case, it allows the user to see "where the data WOULD go if it were accepted" in an expected and consistent format, without us having committed the relevant links in the database schema.

     

    II.D - Regarding Applicable Versions

    LANDesk Management Suite Versions:

    This information is applicable to LANDesk version 9.0 and onward.

     

    LANDesk Management Suite versions 8.x did not have the feature to "block unknown items".

     

     

     

    III - Preparation (MUST READ)

    The only thing you need to do - and you *MUST* do this is

     

    STOP THE INVENTORY SERVICE!

     

    This is an absolute *MUST* as you risk corrupting the database if you don't do this.

     

    Like ANY operation that doctors around with the database, this is a key requirement.

     

    In case you forget to do this, you're unlikely to single-handedly BREAK the database - but it's still going to cause some clean-up that I wouldn't envy doing (chances are, it may require deletion of custom data / unmodelled data and such "standard recovery options").

     

    As a bonus, have a backup of the database before you begin, but that's optional. By and large, this should be a low-intrusiveness operation.

     

    IV - How to delete "everything"

    This is very straight forward, really.

     

    Depending on whether you want to log the deletions of each row (for auditing), you can use either the "DELETE..." or "TRUNCATE..." syntax.

    delete from METABLOCKED
    

     

     

    - or -

    truncate table METABLOCKED
    

     

     

    Note that "Truncate" may not work for Oracle (it's a MS SQL command).

     

    IMPORTANT NOTE:

    The "Delete..." operator is slower, as it logs each deletion.

    The "Truncate..." operator is (MUCH) faster, as it does not log each deletion.

     

     

    Tempted though it may be, please don't use "drop table"... it's not that this would be unrecoverable - it will simply require you to run a COREDBUTIL => BUILD COMPONENTS, which can take quite a while (depending on the server in question and the size of the database).

     

    V - Fixing accidentally ignored legitimate custom data

    That's very simple.

     

    You just need to delete the relevant line(-s) from the METAIGNORE table.

     

    Then you re-inject an inventory scan (once the Inventory Service is up again) which has your desired, unmodelled data and since it's "new", it'll now show up under "unknown blocked items" again.

     

    VI - Mass-insertion of ignored data

    A little less straight forward than "just deleting everything", this is still pretty simple.

     

    The key elements are that both METABLOCKED and METAIGNORE use the BNF-datapath string to identify a data location. This is what you need to shift.

     

    So you need to do the following:

    Step 1 - grab the BNF from the METABLOCKED-table (the column-name is BLOCKEDBNF)

     

    Step 2 - inject the BNF from step 1 into the METAIGNORE-table (into the IGNOREFQA column).

     

    Step 3 - delete the relevant line in the METABLOCKED-table from step 1.

     

     

    The "inject" should be very straight forward, since the METAIGNORE_IDN is a self-incrementing identity attribute, and as such is not going to cause you headaches.

     

    That said, depending on what volumes you're talking about, it's advisable to do this on a "line by line"-batch job, to help ensure that you're not going to skip anything or run into problems.

     

    VII - What about "Mass-permitting" data?

    That's NOT something you should attempt through SQL (as creating the relevant data links is a thing requiring care). The "safest" approach if you must mass-permit unmodelled custom data is as follows:

     

    Step 1 - delete *all* currently unknown data, as per chapter IV.

     

    Step 2 - disable the "block unknown items" function in the Inventory Service.

     

    Step 3 - Start the Inventory Service and Inject a/several scan-files that have your desired unmodelled data with values.

     

    Step 4 - When done, stop the inventory service and re-enable "block unknown items".

     

     

    ... a slight alternative would be to delete all unknown data, WITHOUT disabling the "block unknown items" of step 2. After processing the inventory scan with (ideally - ALL of) your desired custom data, just go into the "UNKNOWN ITEMS" section and allow them as per normal (remember - this will require the re-start of the inventory service).

     

    This will handle all of the necessary data-structure linking in the background.

     

    VIII - In Conclusion

    This article should cover everything you need to handle massive amounts of unknown inventory items.