Skip navigation
1 2 3 Previous Next


149 posts
Share This:

I wonder how many of you know what these are, at the bottom of (say) a Host node:

or like this, on a SoftwareInstance node:

Well, NIST maintains a National Vulnerability Database that provides a common classification of software in the form of those CPR Strings (Common Platform Enummeration is a structured naming scheme in URI format) and CPE ID.


If you have the Extended Data Pack installed (used to be a separately license entity), you will have the National Vulnerability Database patterns that generate this data. We currently conform to the still-supported CPE version 2.2, although we are looking to update in a future TKU as part of DRDC1-12249.


For my Postgres SI example, you get an link:

which takes you to this list at NIST.


I would be interested to know if anyone is actively using this data, and how. Are you feeding other security analysis tools?

Greg DeaKyne

Pre-Release Community

Posted by Greg DeaKyne Employee Jun 16, 2020
Share This:

Thanks to everyone that participated in the pre-release community prior to our 20.02 release.  We are ready to ramp this community up again with the upcoming 20.08 release (On-Premise & SaaS).  If you are already a member of the "BMC Helix Discovery Pre-Release Program" community, there's nothing that you have to do and look out for a forthcoming post in that community with further details on the first pre-release candidate.


If you are interested in joining the pre-release community so that you can get early access to these builds, test new features, and provide feedback to R&D, please send me a private message so that I can get you setup.  If you are discovering resources in the cloud or are looking to do so, you might find a new feature in 20.08 of interest to you!



Greg DeaKyne

Product Manager, BMC Discovery

Share This:

When learning a new programming language, it is common that you will see a simple "Hello World" program written in that language.


So, I wrote a Hello World program in TPL.

Actually, I wrote 2 of them:  One discovery pattern, and one syncmapping extension.


In TPL, the way to print "Hello World" is to use a log statement.

TPL provides a log statement for each logging level:






Here is a sample Hello World discovery pattern below.


The yellow italics represent identifiers.  An identifier is a made-up name.

host_node is the name of a variable which is created by the pattern.  It is set to the host node that triggered the pattern.

The trigger for the pattern is a Host.

When discovery scans a Host, the pattern is triggered.

The Hello World pattern does nothing at all except to write some messages to the logs.

The messages can be found in this log file:   /usr/tideway/log/tw_svc_eca_patterns.log




Here is a 2nd simple discovery pattern which is more useful:  it adds a new attribute called "source" to a Host. 



The yellow italics are identifiers.

The red italics is also an identifier, but further, host_node is the name of a variable, and it points to the host node in Discovery.

The trigger for the pattern is a Host.




And, finally, here is the sample syncmappping Hello World program:



The yellow italics are identifiers.

The red italics are also identifiers, but further, they are variables.

host is the host node from Discovery.

computersystem_ci points to the BMC_ComputerSystem CI in the CMDB.

syncmapping's do not have a trigger statement



All 3 TPL's are attached.

Share This:

While a few customers run Discovery appliances on physical hardware, the vast majority run on VMs, and those being on VMware ESX. An important consideration is the ability to use VMware Snapshots, which we mention in the docs, here. So what exactly is a snashot?


When triggered by an ESX administrator, the VM's entire memory, disk and configuration state is captured at that point in time. The original virtual disk (.vmdk file) s "frozen" and refered to as the parent. A new child .vmdk file is created, which contains differences to the snapshot state. Over time, the number of changes may grow, up to a limit of the entire orignal virtual disk size (plus small overhead). If more snapshots are taken subsequently, a hierarchy of  child deltas is created, looking something like this:

As you can imagine, the more snapshots the system has to manage, and the more changes the system makes, the more overhead in IO and storage use. Discovery's datastore makes intensive use of the disk.


See here for VMware's KB article "Best practices for using snapshots in the vSphere environment (1025279)". Of note are the headlines:

  • Do not use snapshots as backups
  • For better performance, use only 2 to 3 snapshots
  • Do not use a single snapshot for more than 72 hours
  • When using 3rd party backup software, ensure the snapshots are deleted after sucessful backup.


It is typical that Discovery Administrators are not also ESX Administrators, but I would recommended checking what the current snapshot policoes and procedures are for your Discovery virtual appliances. I have logged docs defect DRUD1-29882 to update the page with background and links to VMware's KB article.


Do let me know if you use snapshots, how often, and for what purpose. What processes do you have around them? Do you use any other backup and management software with them?

Nick Smith

Sizing your RAM

Posted by Nick Smith Employee Jun 5, 2020
Share This:

If you have an eye for detail, you may have noticed that the sizing guide for Discovery 20.02 (12) states that for produciton use, 64 GB RAM is the minimum for an appliance. This has increased from the Discovery 11.3 document recommends: 16 - 32 GB; For environments in which you discover storage, you should have more than 16GB RAM.


You may be wondering what has caused this increase - is there some specific feature or architecural change that now requires more RAM? Well, not really. If you just replace and existing 11.3 installation with 20.02 without changing usage profile, then you should see very similar RAM usage. Instead, it was felt that as time marches on more features are added that will steadily put introduce more memory pressure. Examples include:

  • Scanning large complex hosts or network devices with many interfaces
  • Complex patterns with large data sets to process
  • Mainframe discovery
  • Large storage device discovery
  • vCenter discovery
  • Deep database discovery
  • Password store integration.


And RAM gets cheaper. Thus, if you are considering upgrading, it may be a good time to review your installation and performance profile and see if it will remain adequate for (say) the next 12 months or if you should consider some RAM upgrades. Note that some time ago I wrote about the importance of more RAM in the context of datastore performance.


Unfortunately, under Appliance Configuration, you will still see:

I logged this as defect DRUD1-29779, and should be updated in patch 2.

Share This:

Greetings All,


AddRun.pngWe have just released a patch update for the recently released version of BMC Discovery, 20.02 (v12.0).  Patch 1 is currently available to download via the BMC Electronic Product Distribution (EPD) site.


For a list of bugs that were fixed in this release, release notes can be found here.


With Patch 1, you can now specify which outpost to perform specific discovery runs.  This is available when you select the Targeting type as IP Address.  You can select whether you want to perform the scan through a specific outpost or the local appliance.

Related Idea: Ability to force the Outpost use for a particular Scan


The May 2020 TKU is now available for download via BMC EPD site as it previously wasn't ready for 12.0 appliances.  Patch 1 must be applied before installing the May TKU.  (Note: This is the same TKU that was released on May 15th and now compatible with 12.0 Patch 1.  Customers on 12.0 are the only ones that need to take further action today in regards to the May 2020 TKU.)


We strongly recommend that you upgrade to version 12.0 Patch 1 if you are on any previous versions of BMC Discovery 11.0, 11.1, 11.2, or 11.3.  For details about the upgrade procedure, see the Upgrade BMC Discovery page.



Greg DeaKyne

Lead Discovery Product Manager

Share This:

With the recent release of BMC Discovery On-Premise 20.02 (12.0), now would be a great time to review:


1)  What version of BMC On-Premise Discovery you are currently running:


2)  What the supportability timeline looks like for that version.  The page in the link below contains information about the support lifecycle dates for BMC On-Premise Discovery.


3)  Your plan is to upgrade/migrate to a newer version of BMC On-Premise Discovery:


4)  End of vendor support for CentOS 6.   


The above should be a good starting point for determining what your timeline should be for an upgrade or migration to the latest version of On-Premise Discovery.

Share This:

We have discovered an important defect (DRUD1-29601) that affects attempts to upgrade to 2020-05 TKU if you have AWS sceduled scans.


If this is your situation please DO NOT attempt to apply the TKU, otherwise services will not start. There is a hotfix available from support to get out of this, but better to wait for the TKU re-release which is imminent (expect early next week).

Share This:

In certain cases, the Discovery datastore can grow sufficiently to fill its disk partition. Other partitions, such as /usr or /var, may also run out of space.


When this happens, Discovery services are stopped and the UI is not available.


One way to avoid this is to take advantage of a Discovery log file that tracks disk usage. This file is named "tw_appliance_df.log" and is updated daily. It's basically the output of a 'df' command, and it appends each new day's output at the end. This allows you to see growth over time.


The attached script reads this file and generates an email with an attached report. A quick look at this report shows you if any disk partitions are nearing 100% full. This allows you to take action before an outage occurs.


The script looks like this:



### Remove previous output file

rm -f /usr/tideway/df_report.txt

### Run the report

tail -10 /usr/tideway/log/tw_appliance_df.log > /usr/tideway/df_report.txt

### Email the results

echo "Current Discovery disk usage" | mailx -a "/usr/tideway/df_report.txt" -n -s "Disk Usage Report"


It will be necessary to edit the script to:

- Specify a valid smtp server

- Specify a valid email address


Also, since the length of the 'df' output can vary by environment, the value of the "tail -10" command may need to be adjusted to make sure that you're getting all the output of the most recent 'df' command, but not the output of the prior day.


Once the script has been edited, copy it to your Discovery appliance in the /usr/tideway directory and run these commands:


1. Use dos2unix to convert the script to UNIX format:


dos2unix /usr/tideway/


2. Run the script:


/bin/sh /usr/tideway/


Confirm that the /usr/tideway/df_report.txt file was created, and that the email was received.



The script can then be scheduled to run on a regular basis (weekly is suggested) using a cron job:


1. As the tideway user, create a cron job file, for example:


#===========/usr/tideway/etc/cron/df_report.cron ========


# cron job to report disk usage

# runs every Wednesday at 1:25pm


25 13 * * 3 /bin/sh  /usr/tideway/


Note: if the cron job file is created on your desktop and copied to the Discovery appliance, use dos2unix to convert the file to UNIX format:


dos2unix /usr/tideway/etc/cron/df_report.cron


2. Run /usr/tideway/bin/tw_cron_update to add this job to the crontab.


3. Run "crontab -l" to verify that the job is on the crontab.

Share This:

Hello Everyone,

I am excited to announce BMC Discovery 20.02 (v12.0) is now generally available.  The team put in a lot of hard work into this release as you can see below and via the release notes.


Below is a brief overview of some of the major features.


Introducing the BMC Discovery Outpost

The BMC Discovery Outpost is a lightweight Windows service for discovery of all types of devices. The BMC Discovery Outpost connects securely to your appliances over HTTPS by using a single, web-friendly port (443). You can deploy a BMC Discovery Outpost to scan multiple isolated network regions, replace scanning appliances in a consolidating system, replace Windows proxies, or simply provide more flexibility to segment your network discovery.


Related Idea:


Introducing Data Sources

Use a data source to add static sources of information to your discovered information. Data stores might be a centralized asset database, a store accessed using a REST API, or a file system on a host against which you can run commands. You write patterns that specify the target data source and provide queries to extract the information required. You can use data sources to query an asset database to find the location of hosts as they are discovered.


Data sources replace Integration Points used in previous releases.  A data source can be considered as a type of credential. A data source contains user name and password information, and is stored in the credential vault on the BMC Discovery appliance or BMC Discovery Outpost.


Related Idea:


New Integrations with Third-Party Credential Managers

  • Thycotic Secret Server
  • BeyondTrust Password Safe
  • Centrify Identity Platform
  • CyberArk. CyberArk has been supported since BMC Discovery 11.1. It can now be accessed over its REST API in addition to its CyberArk AIM Provider API.

Related Ideas: BMC Discovery integration with Beyond Trust & ADDM script support for Power Broker and other security products


Ability to Perform Backups/Compactions Online

A new datastore option is now available, multi-generational datastore, which allows you to perform backups and compactions without taking Discovery services down.  A multi-generational datastore is one in which data is stored in generations, or "layers" according to the age of the last write activity.  The system can only write to the current, most recent generation, so other read-only generations can be backed-up while the system is running.


Visit the docs page to learn more about this option, steps to migrate and other important notes to understand before making the change.


Related Ideas: Creating cluster backups without shutting down the services on the cluster members & Parallelise compaction and/or make it more flexible  


More Information

BMC Discovery version 20.02 files are now available for download at the BMC Electronic Product Distribution (EPD) site.


Read more in the release notes.

Share This:


Any patterns provided in the communities, provided by Users and by BMC employees are not part of the product, and are not necessarily thoroughly tested.

Use at your own risk.

NOTE: Please test all new patterns in a TEST environment!


How to get Started creating CMDB Syncmapping Extension patterns:  Getting Started creating a CMDB Syncmapping Extension pattern

Info about custom patterns and syncmappings, how to test, etc:  Helix Support: Discovery custom patterns discussion

Sample syncmapping 'stubs' / starting points :  Helix Support: Discovery: Sharing my library of syncmapping extension stubs

Sample patterns and syncmappings posted by Lisa:




I have a small library of syncmapping stubs / starting-points which I have written or kept over the years.

The syncmappings are mostly just some "stubs" to insert actual logic into.

I have decided to share them with everyone in a zip file, attached.


See also this link for custom patterns (with useful logic included), and other blogs which I have shared on the Communities:  Lisa Keeler


To use the attached syncmapping stubs:

The first step would be to download the zip file and unzip it.  Take a look!


And, see this link: Getting Started creating a CMDB Syncmapping Extension pattern


As stated in the "Getting Started" link, you must first create a plan and specify the "Source" and "Target" of the data.

The "Source" is the data you want to get from Discovery.  The "Target" is the place where you want to put the data in the CMDB.


For example, say I want to get some data from a NetworkDevice node in Discovery, and put it into the BMC_ComputerSystem class in the CMDB.

So, the "source" is NetworkDevice.  The "target" is BMC_ComputerSystem.


My plan needs to also include the specific attributes or data I am interested in from the Source, and the specific attributes I want to populate in the Target.

So, let's say I have noticed that when the data source is a NetworkDevice, the TokenId in the CMDB on the BMC_ComputerSystem is not populated.

(It is true, OOTB, the TokenId is not populated for a NetworkDevice).

But, my company requires a TokenId to always be present on the BMC_ComputerSystem CI's in the CMDB.


So my plan is like this:

                Source:                                            Target:

                NetworkDevice                                      BMC_ComputerSystem

Attributes:        the hashed key of the NetworkDevice                  TokenId



I should look in the listing of the zip file for filenames that contain the phrase "NetworkDevice" because that is the Source of the data.

And, I find 3 such samples in the listing of the zip file:





For my example, the name of this syncmapping looks particularly interesting: 



Maybe I'm home-free!  Let us look at the text of that syncmapping.

Below, the standard parts of the syncmapping are regular font, and the most interesting lines (the two lines which create and set the TokenId) are in bold.


tpl 1.13 module CMDB.Extension.NetworkDevice_setTokenId;



    origin := "Customer";

    tree_path := "Custom", "CMDB Sync", "NetworkDevice_ComputerSystem_setTokenId";

end metadata;


from CMDB.NetworkDevice_ComputerSystem import NetworkDevice_ComputerSystem 2.0;


syncmapping NetworkDevice_setTokenId 1.0


    Change values for NetworkDevice to BMC_ComputerSystem syncmapping



        tags CMDB, Extension;

    end overview;


    mapping from NetworkDevice_ComputerSystem.device as device

    end mapping;



        computersystem := NetworkDevice_ComputerSystem.device_cs;


        hashed_key := text.hash(device.key);

        computersystem.TokenId := "ADDM:%hashed_key%";


    end body;

end syncmapping;



So, my TokenId in the CMDB will look something like this:  "ADDM:<some hex number>"

If that's what I want, then I just Upload that pattern from the Manage->Knowledge page in the UI and test it on a testing system.


If I want the TokenId to look like this instead:  "ACME CORP:<some hex number>",

I can change this line of code:


OLD:          computersystem.TokenId := "ADDM:%hashed_key%";

NEW:          computersystem.TokenId := "ACME CORP:%hashed_key%";


After revising the pattern, I Upload it as described above, fix any compile errors, and test it.


Again, these syncmapping extensions are just some 'stubs' that are a 'start' on some logic.

The syncmapping stubs generally do not do anything interesting or sensible.




DIRECTORY LISTING OF THE ZIP FILE.  The ones for NetworkDevice are in bold:

$ ls -la

total 2112

drwxr-xr-x 1 LKEELER Domain Users    0 Mar 18 16:58 .

drwxr-xr-x 1 LKEELER Domain Users    0 Mar 18 16:58 ..

-rw-r--r-- 1 LKEELER Domain Users 1895 Apr 15 15:42 CMDB.BAI_Application_augment.tpl

-rw-r--r-- 1 LKEELER Domain Users  667 Apr 15 14:43 CMDB.Cluster_Cluster_augment.tpl

-rw-r--r-- 1 LKEELER Domain Users  649 Apr 15 16:18 CMDB.Cluster_Cluster_augment2.tpl

-rw-r--r-- 1 LKEELER Domain Users  668 Apr 15 16:17 CMDB.Cluster_IPEndpoint_augment.tpl

-rw-r--r-- 1 LKEELER Domain Users  682 Apr 15 14:43 CMDB.Cluster_SystemResource_extend.tpl

-rw-r--r-- 1 LKEELER Domain Users  692 Apr 15 14:44 CMDB.ClusterService_SystemResource_extend.tpl

-rw-r--r-- 1 LKEELER Domain Users  787 Apr 15 16:29 CMDB.Database_extend.tpl

-rw-r--r-- 1 LKEELER Domain Users 1416 Apr 15 14:46 CMDB.Group_StaticApplication_augment.tpl

-rw-r--r-- 1 LKEELER Domain Users  643 Apr 15 14:46 CMDB.Host_ComputerSystem_augment.tpl

-rw-r--r-- 1 LKEELER Domain Users  836 Apr 15 15:34 CMDB.Host_ComputerSystem_augment_virtual.tpl

-rw-r--r-- 1 LKEELER Domain Users  665 Apr 15 14:48 CMDB.Host_OperatingSystem_augment.tpl

-rw-r--r-- 1 LKEELER Domain Users  874 Jun 16 07:29 CMDB.HostContainer_ComputerSystem_extend.tpl

-rw-r--r-- 1 LKEELER Domain Users  959 Apr 15 15:23 CMDB.HostDetail_ComputerSystem_augment.tpl

-rw-r--r-- 1 LKEELER Domain Users  992 Apr 15 15:23 CMDB.HostDetail_OperatingSystem.tpl

-rw-r--r-- 1 LKEELER Domain Users 1348 Apr 15 16:30 CMDB.NetworkDevice_ComputerSystem_augment.tpl

-rw-r--r-- 1 LKEELER Domain Users  755 Apr 15 16:30 CMDB.NetworkDevice_setTokenId.tpl

-rw-r--r-- 1 LKEELER Domain Users 1035 Apr 15 16:31 CMDB.NetworkDeviceDetail_ComputerSystem_augment.tpl

-rw-r--r-- 1 LKEELER Domain Users  756 Apr 15 16:19 CMDB.RuntimeEnvironment_Product_extend.tpl

-rw-r--r-- 1 LKEELER Domain Users  875 Apr 15 16:31 CMDB.SNMPManagedDevice_ComputerSystem_augment_CTI.tpl

-rw-r--r-- 1 LKEELER Domain Users  819 Apr 15 14:53 CMDB.SoftwareCluster_Cluster_augment.tpl

-rw-r--r-- 1 LKEELER Domain Users 1113 Apr 15 15:39 CMDB.SoftwareComponent_ApplicationService_augment.tpl

-rw-r--r-- 1 LKEELER Domain Users  857 Apr 15 15:26 CMDB.SoftwareComponent_ApplicationService_augment_CTI.tpl

-rw-r--r-- 1 LKEELER Domain Users 1172 Apr 15 14:56 CMDB.SoftwareInstance_ApplicationSystem_augment.tpl

-rw-r--r-- 1 LKEELER Domain Users 1180 Apr 15 15:29 CMDB.SoftwareInstance_ApplicationSystem_augment_CTI_2.tpl

-rw-r--r-- 1 LKEELER Domain Users 1023 Apr 15 14:57 CMDB.SoftwareInstance_Detail_EOL.tpl

-rw-r--r-- 1 LKEELER Domain Users  752 Apr 15 16:19 CMDB.SoftwareInstance_Product_extend.tpl

-rw-r--r-- 1 LKEELER Domain Users 5637 Apr 15 16:19 CMDB.SoftwareInstance_Product_override.tpl

-rw-r--r-- 1 LKEELER Domain Users  761 Apr 15 15:00 CMDB.SoftwareInstance_SoftwareServer_augment.tpl

-rw-r--r-- 1 LKEELER Domain Users 1018 Apr 15 15:37 CMDB.SoftwareInstanceDetail_SoftwareServer_augment.tpl

-rw-r--r-- 1 LKEELER Domain Users  921 Apr 15 19:19 CMDB.StorageDevice_changes.tpl

-rw-r--r-- 1 LKEELER Domain Users  911 Apr 15 15:04 CMDB.StorageDevice_Cluster_augment.tpl

-rw-r--r-- 1 LKEELER Domain Users  713 Apr 15 16:32 CMDB.StorageDevice_extend.tpl

-rw-r--r-- 1 LKEELER Domain Users  926 Apr 15 16:38 CMDB.StorageSystem_ComputerSystem_extend.tpl

-rw-r--r-- 1 LKEELER Domain Users  484 Apr 15 14:39 CMDB.Tags_extend.tpl




Here is a screenshot showing those same patterns in my Manage->Knowledge page after I uploaded the entire zip file:


Of course, you should not upload the entire zip file.  I uploaded the zip file to make sure that all the stubs compile OK in 11.3.

Next, I will be deleting all the syncmapping stubs I had uploaded so that they don't affect my testing system.


I hope these syncmapping stubs are helpful to you!



Helix Support: Discovery custom patterns discussion

Getting Started creating a CMDB Syncmapping Extension pattern

Lisa Keeler

Share This:

I had a conversation with a customer this week who as running on CentOS 6, and was not aware of the need to start planning a migration. This is just a reminder to read past my whimsy here and get to the point: you need to be on CentOS 7 by end Nov this year.

Share This:

BMC Discovery provides monthly Technology Knowledge Updates (TKU). These updates include:

  • Support for new software products
  • Enhancements and fixes for existing software products
  • New integrations for Network Devices
  • Enhancements and fixes for existing Network Devices
  • New and updated patterns for Cloud Discovery and Storage Discovery
  • New product content and fixes


Here are some relevant doc references:


With Helix Discovery, these updates are done automatically. Therefore, the following information applies primarily to on-premise BMC Discovery, although Use Case #3 could be helpful in either environment.


Note: It is always recommended to do a backup prior to updating a TKU.


Use Case #1

Problem: During a TKU upgrade, errors like the following occur:

"Change to module <module name> failed because imported name <name> version <version1> from <name> does not match required version <version2> at line <line number>”


Note: The following message is for information only and is not an error:

"Change to module had warning Deactivating to use newly activated module"


Root Cause #1: The TKU uploaded was for the wrong Discovery version. For example, a TKU for Discovery 11.1 was uploaded on an 11.3 appliance.


Solution #1: Upload the correct TKU.



Root Cause #2: The modules flagged as "failed" are custom patterns. For example:

"Change to module BAI_Application_aug_sync failed because Imported name 'BAI_Application' version 2.1 from CMDB.BAI_Application does not match required version 1.4 at line 3."

"Change to module CMDB.Extension.ComputerSystem_Augment failed because Imported name 'Host_ComputerSystem' version 2.0 from CMDB.Host_ComputerSystem does not match required version 1.8 at line 15."


These custom patterns have import dependencies on TKU patterns whose version has changed.


Solution #2: Update the custom patterns to use the correct versions of the modules they are importing.



Root Cause #3: The modules flagged as "failed" are Storage TKU patterns. For example:

"Change to module NetApp_Storage failed because Imported name 'ConversionFunctions' version 1.1 from ConversionFunctions does not match required version 1.2 at line 12."


Solution #3: This could happen in the following cases:


a) The Storage TKU was applied before the core TKU of the same month. In this case, perform the knowledge updates in the following sequence:

-Update core TKU first (BMC Discovery Technology Knowledge Update)

-Update Storage TKU next (BMC Discovery for Storage)

-Update EDP (Extended Data Pack)


b) The appliance previously had a very old Storage TKU version. In this case, the solution is to deactivate and delete the old Storage TKU.


c) An incomplete download of the core TKU causes a number of core TKU patterns to be missing. To correct this, re-download and reapply the core TKU, then reactivate the Storage TKU modules.


Use Case #2

Problem: While upgrading TKU, the message "Changes failed because Problem setting pattern state" appears


Solution: The cause of these errors is difficult to determine and the problem is frequently not reproducible. The following workarounds have proven effective:


1/ Do the following:

- Restart the Discovery services

- Go to Manage > Discovery and "stop all scans"

- Go to Manage > Knowledge and make sure "Auto Cleanup" is checked

- Try to upload the TKU again.


2/ Stop the reasoning service and restart it with the option to deactivate all patterns. See KA 000104293 for details. Once this is done, the patterns for the most recent TKU can be re-activated, followed by any needed custom patterns.



Use Case #3

Problem: Attempts to deactivate some TKU or custom patterns fail because of dependency relationships


Patterns commonly have dependency relationships with other patterns. In some cases, an attempt to deactivate or delete a pattern may fail with a message that some other pattern is dependent on it. Trying to deactivate or delete these dependent patterns then may fail with similar messages for still other patterns.


Solution: It is possible to stop the reasoning service and restart it with an option to deactivate all patterns. See KA 000104293 for details. Once this is done, the desired patterns can be deleted or re-activated as appropriate. For Helix Discovery, contact Customer Support.



Use Case #4

Problem: A TKU upgrade fails with a message like the following:


Change to module xxxxxx failed because TPL version 1.xx is not supported in file at line n.


Root Cause 1: Incompatibility between versions of BMC Discovery and TKU. For example, customer has BMC Discovery 11.2 and is applying the TKU for Discovery 11.3.


Solution 1: Download and apply the correct TKU version for the Discovery version.


Root Cause 2: The TPL version defined in a custom pattern is not supported by the Discovery version being used. For example, customer has BMC Discovery 11.2 (which supports TPL 1.14) and is uploading a pattern with TPL 1.15 defined.


Solution 2: The supported TPL version can be seen in the Manage > Knowledge page. The solution is to revise the TPL version in the pattern to be equal to or less than the supported version.


Root Cause 3: The Discovery version being used does not support the TPL version in the TKU upgrade. For example, customer is using Discovery 11.0 (with no patch) and tries to upgrade to a TKU version >= March 2016.


Solution 3: The TKU release notes would document this with something like "If you are running BMC Discovery version 11.x you must upgrade to 11.x0.1 (or later)". The solution is to upgrade Discovery as directed before applying the TKU.


Use Case #5

Problem: A TKU upgrade fails with a message like the following:


Change to Module <Module_Name> failed because Pattern <Pattern_Name> is deprecated.


Root Cause: This could happen if a TKU pattern was customized (or a beta pattern was provided by BMC Support) in the past, where pattern version > current pattern version defined in TKU. It could also happen if a pattern module from the wrong Discovery version was mistakenly uploaded.

Solution: Try the following steps:

- Search for the problematic pattern module. It should show a version different than the current TKU pattern.

- Deactivate / delete the incorrect module version

- Activate the new TKU module.

Nick Smith

cat ghost > /dev/null

Posted by Nick Smith Employee Mar 6, 2020
Share This:

Just a quick note about a new Tomcat vulnerability that appeared, called Ghostcat: CVE-2020-1938. Of course it has a cute logo.


It affects any Tomcat application server that is running the AJP connector, which is on port 8009 by default. If an attacker has access to this port, then it can be "can be exploited in ways that may be surprising". That is, without authentication, read any file on the server or servlet container and obtain config files or source code. Further, if the server allows file uploads: execute arbitrary code. Yes, that would be surprising.


Versions: 9.0.0.M1 to, 8.5.0 to 8.5.50 and 7.0.0 to 7.0.99 are affected


You may want to start looking in your estate with a basic query such as:


search SoftwareInstance where type = 'Apache Tomcat Application Server'

show version, listening_ports, listen_tcp_sockets, as 'Running on',  #RunningSoftware:HostedSoftware:Host:Host.#DeviceWithAddress:DeviceAddress::IPAddress.#DeviceOnSubnet:DeviceSubnet:Subnet:Subnet.ip_address_range as 'Subnet'


to get an idea of what servers are out there. You could them put extra conditions on the versions and listen ports/sockets. And perhaps look at what networks they are on: focusing on less trusted ones first.


Note that although the port may be open on a non-localhost socket, it may still be blocked by a firewall - as is the case for the Discovery appliances. So then things are more complicated: do you trust all local users? In the Discovery appliance case, the local tideway user as access to everything anyway so accessing the AJP port is of no extra advantage. Unless you have created additional local limited-rights OS users for some reason.


Keep an eye on the OSU for updates to the Discovery appliances.

Share This:

BMC Discovery is capable of scanning a wide variety of SNMP devices. When successful, these usually are modeled as Network Devices, SNMP Managed Devices, or Printers. However, it’s not uncommon to encounter some problems when scanning these devices. This posting will hopefully give you some tools to troubleshoot these problems, as well as some root causes and solutions for specific use cases.


The following information applies to both Helix Discovery and on-premise BMC Discovery, although some references (for example, doing a command line snmpwalk) are relevant only to on-premise BMC Discovery.


Section 1: How to troubleshoot problems with a scan, credential test, or device capture of an SNMP-enabled device?


Discovery sometimes experiences access problems when processing an SNMP-enabled device. The most common situation is when a device capture, credential test, or scan fails with "ERROR: SNMP++: SNMP request timeout" or "Device skipped - no SNMP access".


Here’s an example from a device capture:


Note that there are two ways to get a device capture (see

  • from the Discovery Access page
  • from the Device Info page (which is reached from the Discovery Access page)


In some cases, doing a capture from a Device Info node may result in a blank screen. When clicking the browser "back" button, it returns to the Device Info page and briefly shows a green banner that says "Device skipped (no SNMP access)", which then fades out after a few seconds:


Here's an example of a timeout message from a credential test:



For a scan, the Discovery Access page will typically have a result of “Skipped (Device is an unsupported device)”. The session result page will show “SNMP++: SNMP request timed out”.


There are many possible reasons for this. Here are some possible causes and things to check:

  • Make sure a SNMP credential is present and that the IP range includes the address being discovered (a valid credential is needed for device capture)
  • Run a credential test. What is the result?
  • Increase the timeout in the SNMP credential to 100 seconds and retry.
  • What is the SNMP version (v1, v2c, v3) on the credential? Is the device configured to respond on that SNMP version?
  • If the device supports SNMP versions other than the one specified in the credential, change the version in the credential and retry.
  • For SNMP v1 and v2c, make sure the community string in the SNMP credential is correct. An invalid community string can cause a "Unable to get the deviceInfo: TRANSIENT" error.
  • Ask the device administrator:
    • if there might be an Access Control List (ACL) or some other configuration on the device that prevents responses to the Discovery appliance.
    • if the device is configured to use the default SNMP port (161). Run nmap to confirm the port is open (see below).
  • On the Discovery Access page, click on any links for "script failure" or "xx Session Results related" to look for clues.
  • In the case of a timeout during a device capture, check the log in /usr/tideway/var/captures for additional clues
  • In the case of a timeout during a scan, turn DEBUG logging on for Discovery, run the scan again, and check the tw_svc_discovery.log for clues. Remember to turn DEBUG logging off!
  • In one case, the customer made corrections to the IP range and mask on the device, then was able to discover the device.


  • From the Discovery command line, as user tideway, run the following commands and check the results:

    1/ Check connectivity from the appliance to the endpoint:

                             ping [device_ip_address]

                             traceroute [device_ip_address]


     2/ Check the port status of the device by running nmap. For example:


    /usr/bin/nmap --privileged -sT -sU -p T:22,U:161 [device_ip_address]


The expected result is that port 161 would have a state of "open" or "open|filtered" :


      3/ Do a snmpwalk to the device. For example:


/usr/tideway/snmp++/bin/snmpWalk [device_ip_address] -v2c -cpublic > /usr/tideway/snmpwalk.out


Change the SNMP version and community string as needed. If using SNMP v3, other parameters need to be specified. To see the usage notes with a list of available options, run snmpwalk with the "--help" option.


If snmpwalk also fails, please consult the device administrator.


If the problem persists, please contact Customer Support and provide the results to all the questions / checks above.



Section 2: Specific Use Cases


Use Case #1

Symptom: A scan of a supported SNMP device fails with Skipped / Unsupported device. The Discovery Access page shows a NoAccessMethod result in getMacAddresses (or other methods such as GetPortInfo).

The related Script Failure page may show the error:  SNMP++: SNMP request timed out

A device capture may also fail, and the last thing written in the UI is:

Dumping range: Start of the MIB to End of the MIB



ERROR: SNMP++: SNMP request timed out


A credential test may succeed.

This problem can occur on many different devices, and has been observed on routers, load balancers, and some Lexmark printers.


Root cause:

By default, Discovery asks for large chunks of data at one time from the device, using the "Use GETBULK" option. Some devices may be unable to transfer so much data at one time without hitting a timeout. In other cases, the cause may be a problem with the SNMP agent on the device.



The best solution is that the problem with the device or SNMP agent is corrected. As a workaround, it is possible to disable "Use GETBULK", by editing the appropriate SNMP credential and unchecking the "Use GETBULK" option.


Use case #2

Symptom: A scan of an unsupported network device returns NoAccess instead of Skipped/Unsupported.

A test of the SNMP credential is successful.

The discovery debug log shows that:

- Discovery detects that the sysobjectid is unsupported

discovery.devices: DEBUG: no SysObjectId found in MODELS

- Discovery reports that it can get the sysdescr, but it is UNKNOWN

api.audit: DEBUG: snmp.getSysDesc(): Got system description status = SUCCESS

api.classifier: DEBUG: classify(): processing 'WS5100 Wireless Switch, Revision WS. MIB=01a'

discovery.heuristics.snmp: DEBUG: identifyDevice: sysDescr is UNKNOWN


Root cause: The scan takes too much time trying other credentials (such as SSH) and hits the reasoning timeout of 30 minutes before trying the SNMP credentials.

This can occur when the system description does not contain a known keyword like "cisco" that indicates the endpoint is a network device.

To confirm the root cause, set the Discovery logging to DEBUG and run the scan again. In the discovery log, look for traces like this related to the device:

no SysObjectId <the sysobjectid of the device> found in MODELS

sysDescr is UNKNOWN


Solution: Open a support case to request that the device be integrated in Discovery. The SNMP credentials are used when the device is supported.


Use Case #3:

Symptom: An SNMP scan fails with " Unable to get the deviceinfo: TIMEOUT " after 30 minutes. The Discovery log has " credential failed: SNMP++: SNMP request timed out ".

The correct SNMP credential is at the bottom of the credential list.

The Discovery log shows that the scan had 14 SNMP credentials to try, and the first 12 failed. The 13th credential was still being tried when the scan ended.


The 14th SNMP credential (not listed in the discovery log) was actually the correct one for the device and it was at the bottom of the credential list. When this credential was moved to the top of the list, the scan was successful.


Root Cause: The 13th credential (with uuid of b6c7a4337c564c71870a0a4a50983b4d) did not timeout. To identify the 13th credential, the following was run:


-> replacing <scanner> with the actual Discovery scanner hostname or IP address, and using the uuid from the Discovery log.


Looking at the credential, it was found that the timeout was set to 9000 seconds, which exceeds the default reasoning timeout of 30 minutes. This is why the scan timed out.


Solution: The timeout on this credential was lowered to the default value.



Use Case #4:

Symptom: A scan of a supported SNMP device fails with Skipped / Unsupported device. The Discovery Access shows that getDeviceInfo, getMACAddresses, getIPAddresses, getNetworkInterfaces, and getNames all have status "OK. The getDeviceInfo method has a script failure with message "Ambiguity in determining device kind - falling back to unsupported device".


Root Cause: In the Discovery UI, on the Administration-> Discovery Configuration page, one or more of the following options have been modified to have a value of "No" :

  • Use SNMP SysDescr to identify OS
  • Always try "public" community when using SNMP to identify OS
  • Use Open ports to identify OS


Solution: Change the above options to a value of "Yes", and the network devices will be discovered successfully.



Use Case #5:

Symptom: When scanning a Cisco Nexus device, getNetworkInterfaces fails on TIMEOUT_CallTimedOutOnClient after 30 minutes.


Root Cause #1:  Cisco defect CSCtw72949. See To work around this, Discovery always uses the getNext method instead of getBulk to scan these particular devices. This method is slower and can lead to the reported timeout.

Solution #1: Upgrade the Cisco OS. Cisco defect CSCtw72949 is fixed in Cisco NX-OS Release 5.2(1)N1(4) and above.


Root Cause #2: Same symptoms, however the device has been upgraded to a firmware version that includes the bug fix (for example "7.1(4)N1(1c)").  In this case, the root cause is a huge amount of VLANs on the device. To get edge connectivity information, Discovery is requesting info using all these VLANs and is not able to complete this before the reasoning timeout.

Solution #2: Two previous RFEs (DRDC1-10658 and DRDC1-11888) were submitted and changes were included in the September 2018 TKU.  However, this may not correct the problem in all cases. An additional RFE (DRDC1-11973) has been submitted to find another way to gather this information in less time. However, as of February 2020, there is no ETA for this request.

The only known workarounds for root cause #2 are:

  1. Disable edge connectivity. To do this, on the Discovery Configuration page, change "Discover neighbor information when scanning network devices" to NO. Please note that on subsequent scans, all existing host-switch connections will be deleted. Reference:
  2. The scan fails because it exceeds the reasoning request timeout. It is possible to increase this timeout, however caution should be used, as doing so will force discovery to wait longer for the end of a scan, even if the scan can't finish. This could impact the performance of some scans, but there is no way to quantify this in advance.

The reasoning timeout can be increased with the command below:

tw_options -u system REASONING_REQUEST_TIMEOUT=3600000

When prompted, provide the password for the UI 'system' account.

In this example, the timeout (30 mins by default) is increased to 1 hour. It is not recommended to increase the reasoning timeout to more than 2 hours. A restart of the Discovery services is required for this option change to take effect.


Section 3: SNMP v3 specific use cases


Use Case #6:

Symptom: An SNMP v3 scan of a supported network device fails with “Skipped (Device is an unsupported device)”, or possibly a timeout in getMACAddresses.

A credential test fails with "SNMP request timed out". Increasing the timeout to 100s does not help.

An snmpwalk from the Discovery command line is successful.

Other SNMP devices are discovered by the appliance using the same credentials.

After a restart of the Discovery services (or all the services on all cluster members), the credential test succeeds, and the device is discovered successfully.


Root cause 1: Defect DRUD1-25505 - Two or more network devices present the same EngineID, which is supposed to be unique. Discovery scans the first one successfully, but then the second one fails until the cache is flushed (by the service restart) - at which point a rescan of the first would fail, and so on.

To confirm the root cause:

  • If the scan works with SNMP v2 and fails with SNMP v3, the root cause is probable.
  • If the SNMP v3 scan (or the credential test) fails and then works after an appliance restart, the root cause is confirmed.
  • It is also possible to confirm the problem with the query below:

search NetworkDevice show name, type, vendor, model, #InferredElement:Inference:Associate:DiscoveryAccess.endpoint as 'Scanned via', #InferredElement:Inference:Associate:DiscoveryAccess.end_state as 'End State', #InferredElement:Inference:Associate:DiscoveryAccess.#DiscoveryAccess:DiscoveryAccessResult:DiscoveryResult:DeviceInfo.snmpv3_engine_id as 'SNMP v3 Engine Identifier'

If two Network Devices have the same snmpv3_engine_id, the problem is confirmed.  Otherwise, restart the appliance, rescan the devices,  then re-execute the query above. This is needed because NetworkDevice nodes are only created after a successful scan (which is not possible until the appliance is restarted in this case).

This query will only show the snmpv3_engine_id that Discovery was able to find. If workaround #1 below (service restart) was not used, the issue may occur even if the query above does not return anything wrong.

If the following command is executed from the appliance:

sudo tcpdump -i any -s0 host <ipAddress> -w /tmp/snmp_issue.cap

The dump may show the elements below. This is not enough to confirm the cause but it is compatible with it.


     Discovery send get-request

     Device send report (usmStatsUnknownEngineIDs)

     Discovery send get-request with EngineID

     Device send report (usmStatsWrongDigests)


Workaround 1:

1A- Restart the Discovery services of a standalone appliance (or the Discovery services of all members of a cluster) before scanning any of the devices that are using a duplicate engine id. Each restart will allow Discovery to scan a single one of the N devices with duplicate engineIDs. If the services are restarted once or twice a day, it could allow Discovery to scan the devices affected by this issue with a reasonable probability of success.

1B- Rescan with SNMP v2

1C- Upgrade to a version that resolves DRUD1-25505. As of January 2020, this is still in progress. When available, this change will allow the scans and credential tests to succeed even when the SNMP engine ids are duplicated.


Note that workaround 3B below (root cause 3, SNMP_USE_ENGINE_ID_CACHE) will not help if root cause 1 is confirmed.


Solution 1: Change the SNMP v3 engineID of the scanned device and make it unique. This is recommended for security reasons.

For Cisco Devices, it is possible to make it unique using MAC addresses:  see

It may be possible to execute a similar procedure for other vendors, such as HP.

Note this solution is not suitable when pairs of master/standby devices share the same engineid (see root cause 2 below).


Root cause 2: Some devices (such as Cisco firewalls, Brocade load balancers, or Juniper devices) can be configured with an Active/Backup setup (also referred to as master/standby). This means that the active and backup devices are two different physical devices but they share internal configurations to support failover.  As they share configurations, they also share SNMP v3 engineIDs.  It is an SNMP v3 security standard that SNMP v3 engine IDs should be unique per device.

Workaround 2: Use the workarounds provided for root cause 1.



Root cause 3:  A new network device was found, then replaced (on the same IP, i.e. was installed with a new MAC address and SNMP v3 EngineID), and rescanned.

Workaround 3:  See workarounds 1A and 1B above

Solution 3:

A)  Upgrade to a version that resolves defect DRUD1-25505.

B)  If not already done, upgrade to Discovery version 11.2 or and execute the command below:


(enter system password)

Please note that this solution could have an impact on appliance performance in theory.



Use Case 7:

Symptom: When using SNMP V3, a scan of a supported SNMP device fails with various “USM” error messages


Problem: SNMP V3 scan fails with "SNMPv3: USM: Authentication failure". In some cases, the device can be discovered using SNMP v2c, but fails when using SNMP v3.

Solution: Try the following suggestions:

  1. The error indicates an authentication problem (for example, the digest being invalid). Please check the credential, making sure it is valid for the specified device.
  2. Verify that the authentication and privacy passwords are correct. Check with the device administrator.
  3. Test the credential by running snmpGet from the appliance command line, using SNMP V3 parameters. Run "/usr/tideway/snmp++/bin/snmpGet" to see usage notes. If snmpGet also fails, please consult the device administrator.


Problem: SNMP V3 scan or credential test fails with "SNMPv3: USM: Unknown SecurityName".

Solution: This error means that the SNMPV3 security name being used is unknown to the device. To confirm, run snmpwalk using the same SNMPV3 parameters as the Discovery credential. If snmpwalk reports the same error, consult with the device owner about the correct security name to use.

It's also possible to check the security name from the command line by running 'tw_vault_control -S'. The security name will appear (when applicable) like this:

          snmp.v3.securityname = '<the value that you set>'

Check for any extra spaces or unprintable characters at the end of the security name.


Problem: SNMP V3 scan fails with Skipped / Unsupported device. A device capture fails with "no SNMP access". A snmpWalk from the appliance command line reports “SNMPv3: USM: Decryption error”.

Solution: A decryption error typically indicates that there is some problem with the Network Device security configuration. Please check with the device administrator and/or network team to confirm that these SNMP V3 values on the credential are valid for the device:

  • Authentication Protocol
  • Authentication Key
  • Privacy Protocol 
  • Private key


Problem: SNMP V3 scan fails in getMACAddresses with "SNMPv3: USM: Message not in TimeWindow”. Running snmpWalk from the Discovery command line succeeds, and device MAC addresses can be found in the snmpWalk result. This indicates that the configured SNMPv3 credential has the required permissions to retrieve MAC addresses from the device.

Solution: The probable cause is that the device's SNMP agent is not able to properly process discovery GETBULK requests. As Discovery can't find the output for the getMACAddresses method in the defined time window, it reports "SNMPv3: USM: Message not in TimeWindow"

To confirm this, create a separate SNMPv3 credential just for this device and uncheck "Use GETBULK". Move this credential to the top and temporarily deactivate the original credential. Re-scan the device. If the scan completes, contact the device owner/support and ask them to check why the SNMP agent is not able to process the GETBULK requests.


Filter Blog

By date:
By tag: