Skip navigation
1 2 3 Previous Next


127 posts
Share This:

Customers frequently ask for help with custom patterns in the Community.


Here is some general information to help you get started.


TPL - Template Pattern Language.  Some users use the terms "TPL" and "pattern" interchangeably.

A module (contained inside a TPL file) contains one or more pattern or syncmapping statements.




There are 2 types of TPL customization for the BMC Discovery product:

  1) Discovery patterns typically add and/or modify Discovered information.

         There are many OOTB Discovery patterns (defined by the TKU).

         There may also be custom Discovery patterns.

         The keyword "pattern" is used to define a pattern.


  2) syncmappings define the behavior of the CMDB Sync process.

         There are many OOTB syncmappings (defined by the TKU).

         There may also be custom syncmappings.

         The keyword "syncmapping" is used to define a syncmapping.



Best Practices:


Should I edit the OOTB patterns and syncmappings?


If you edit the OOTB pattern, the edits will be lost with the next TKU update.


How can I change the behavior since I should not edit the OOTB patterns and syncmappings?

1) To modify the behavior of Discovery patterns, there are  2 methods:


  • Preferred method: add an additional (custom) Discovery pattern

     Each discovery pattern has a trigger statement.  If the trigger succeeds, then the pattern body is executed.

                 Example of Discovery pattern:


  • Discovery Override pattern
    Sometimes, an Override pattern is required to modify the OOTB Discovery pattern behavior.
    Only use this method when absolutely required.

         An Override pattern is only to be used when an Extension can not provide the desired functionality.

         An Override pattern redefines the entire OOTB pattern, with special additional syntax to Override the base pattern.



2) To modify the behavior of the CMDB syncmappings, you can add one of these 2 types of custom patterns:


  • Syncmapping Extension (also called "augment")

                   Syncmapping extensions can add new data to the CMDB, and/or modify data in the CMDB.

                   Example: if you wish to add the age_count information for a Host to the CMDB, use an Extension.


                   Features of Syncmapping Extensions:

      • Extensions can add new attributes or modify attribute values in the CMDB. However, they can not delete attributes.
      • Extensions can add new relationships to the CMDB.  However, they can not delete or modify relationships.


                   Limitations of Syncmapping Extensions:

      • Extensions can not delete attributes from the CMDB.
      • Extensions can not delete or modify relationships in the CMDB.


                   Examples of Syncmapping Extensions:


  • Syncmapping Override

                   Sometimes, a Syncmapping Override is required to modify the OOTB behavior because of limitations of Syncmapping Extensions.

                   Always use a Syncmapping Extension when possible.

                   An Override is only to be used when an Extension can not provide the desired functionality.

                   An Override redefines the entire OOTB syncmapping, with special additional syntax to Override the base pattern.


                   Example of CMDB Syncmapping Override pattern:


Writing a custom pattern is like writing a small software program.

Here are some best practice steps for writing/testing a pattern:

    1) Write the pattern on your laptop using a text editor.

         Or, try the experimental IDE:  Experimental development IDE for TPL


    Hint:  It is less confusing to always edit the pattern from your text editor or IDE instead of editing the pattern directly in the UI.

    Hint:  Add statements while you are debugging your pattern.  Later, you can change those from to log.debug.

    Hint:  Put an identifier (such as your name) in each statement so that you can easily identify that it is your log statement.

    Hint:  It may be helpful to number each log statement so you can easily find it in the pattern.


          "LISA 1: Pattern was triggered.  Here I am in the pattern body.  Host");

          "LISA 2: Inside the 'for each fsmount' loop.  fsmount=%fsmount.mount%");


    2) Upload the pattern from the Manage->Knowledge page
          The Upload action checks for syntax errors in the pattern, and if there are no syntax errors, then it Activates the pattern.

    3) Fix syntax errors in your text editor or IDE, and then Upload again in the UI until there are no more syntax errors

    4) If you added new attributes (which are needed by your CMDB Syncmapping) to your CMDB,

        then do this after adding the new attributes one time:  Restart the Discovery Services

    5) Test the pattern / Fix the pattern / Test / Fix until you are happy with the pattern


          2 ways to test Discovery patterns:

               A) Create a Manual Group and the "Run Pattern" feature:

                    Executing patterns manually - Documentation for BMC Discovery 11.3 - BMC Documentation

                   With "Run Pattern", you will see the and log.debug statements on the UI page easily.

                   The "Run Pattern" tells you if any of the nodes in the Manual Group triggered your pattern.


                   If your pattern triggers on a SoftwareInstance, then you must have a SoftwareInstance in your Manual Group.

                   If your pattern triggers on a Host, then you must have a Host node in your Manual Group.

                   And so on.


               B) Run the Discovery of the Host/Device which should trigger your pattern.

                   Look for your log statements in this log file:  /usr/tideway/log/tw_svc_eca_patterns.log


               Make sure your Discovery pattern gets triggered

               The Discovery patterns have a "triggers" statement.  The trigger statement is very important to define correctly.

               If the trigger statement does not succeed, then the pattern body will not be executed.

               Example of a trigger statement:


                       on process := DiscoveredProcess created, confirmed where

                                             cmd matches regex "(?i)CouchDB\S+\\w?erl\.exe"  or cmd matches unix_cmd 'beam'

                end triggers;


           4 ways to test CMDB Syncmappings:

               A) Pick a pertinent Device and choose Actions->CMDB Sync (from the Consolidator)

               B) With Continuous Sync running, Scan the Device (from the Scanner)

               C) Perform a Resync from the Consolidator (This is long-running.  Only do this when necessary).

               D) Pick a Host/Device and choose Actions->CMDB Sync Preview (from the Consolidator)

                    If your syncmapping syncs to a new class such as BMC_FileSystem, then check the preview visualization for the new class.

                    If your syncmapping only changes/adds attributes, you will not see any change in the preview visualization.


                 All of the above actions will log data to this log file:  tw_svc_cmdbsync_transformer.log


                 Actions A,B,C will change the data in the CMDB.

                 Action D will not change the data in the CMDB.  It is only a Preview.  But, it logs the messages to the log file.


                Hint:  If the CMDB Sync Preview does not work, then there is something very wrong with your pattern.



Resources to help with custom patterns.

1) The Discovery UI:


       The Discovery UI has some information about creating SoftwareInstance patterns magically through the UI:

        Manage->Knowledge->Creating Patterns


       At the top, there is specific information about modeling a SoftwareInstance in Discovery.

       If you wish to have a custom pattern to create an SI, be sure to read that section, as well as the documentation that it points to.



Also, in the Discovery UI are some sample templates:

      Manage->Knowledge->Creating Patterns


Sample SI pattern templates:


Sample "location" pattern templates:



Sample pattern template to create a SQL Integration Point:


Sample pattern template which adds addition SQL calls:


Sample Mainframe pattern templates:


Sample External Event pattern template:


Sample CMDB Syncmapping templates:


To utilize one of these pattern templates, perform the following steps:

A) Download the pattern, and save it to your laptop

B) Use an editor on your laptop to edit and save the pattern.

        Names surrounded by double dollar signs like $$pattern_name$$ should all be replaced with values suitable for the pattern.

C) Upload your pattern on the Manage-Knowledge page to see if there are syntax errors.

      If not, Edit / Upload until the compile errors are gone.

D) Test your Discovery pattern using a Manual Group and the "Run Pattern" feature:  Executing patterns manually - Documentation for BMC Discovery 11.3 - BMC Documentation

    With "Run Pattern", you will see the and log.debug statements for your pattern.

    If you run Discovery without "Run Pattern", you will need to look for your log statements in this log file:  tw_svc_eca_patterns.log

E) To test your CMDB Syncmapping, you can add statements into the pattern, upload the pattern, run CMDB Sync,

      and then check for the log statements in this log file:  tw_svc_cmdbsync_transformer.log



2) The Community


Visit the Discovery community link:  Discovery

Click on "Patterns" as seen below:


You will find sample patterns which are made freely available by other customers, and by the BMC Discovery support team and developers.


3) Look directly at the OOTB patterns that are found in the TKU


    You can look at the patterns in the UI.

    And/Or, you can unzip the TKU zip file, and review the abundance of patterns.


    To view the patterns in the UI, you can look on the Manage->Knowledge page.


     You will find the Syncmapping patterns here on the page:  (Under BMC Discovery Operation -> CMDB Sync):



4) Training

    The Advanced Discovery training course has information about Discovery patterns and custom Discovery patterns.

    To this date, the course does not teach about the CMDB Syncmappings.


5) Customer Support can help with certain questions

       Support will not write custom patterns or custom syncmappings for you.  But, Support may be able to help with specific questions or problems.

       Support has access to some samples that may not be in the community.  Certain sample patterns are attached to internal KA's.


         See:   BMC's Customization Policy


6) BMC Consulting or BMC Professional Services

Greg DeaKyne

October TKU Released!

Posted by Greg DeaKyne Employee Oct 4, 2019
Share This:

Hello Community!


This past Wednesday, if you are subscribed to TKU release announcements, you would have received an email from me announcing the latest TKU availability.  As a reminder to the timing changes from this summer, the TKU and OSU releases will be made available on EPD on the first Wednesday of the month.  SaaS customers on BMC Helix Discovery will have the latest TKU applied to their Development environment on the first Wednesday of the month and their Production environment on the second Wednesday of the month.


We have a lot of exciting new content to announce and the details can be found on the October 2019 TKU Release page.  Highlights include several new patterns for software products, enhancements to existing software patterns, and general bug fixes.  In this latest release, we also introduced 38 new network devices, details can be found on the TKU October 2019 Network Devices page.  In addition, we have introduced 4 new cloud services across Azure and Google Cloud.  To find out more about the cloud providers and services within those providers that we can discover, visit Supported Cloud Providers.


We look forward to your feedback on the content that we are delivering via the monthly TKU releases.  Drop a comment below or reach out to me directly.


Have a good weekend everyone!


Greg DeaKyne

Product Manager, BMC Discovery

Nick Smith

Forward your log

Posted by Nick Smith Employee Sep 5, 2019
Share This:

Just a quick note on syslog forwarding from the Discovery appliance.


While the Discovery appliance (physical or virtual) is based on a fairly standard CentOS build, we are careful to control the packages and configurations to ensure the OS layer is reliable and predictable for the application. Thus although it is tempting for an experienced Linux administrator to want to configure things to their liking, this urge should be avoided, and limited to only those things that are explicitly documented to avoid problems in future, and potentially voiding support.


One often-requested configuration was to forward OS syslogs to a remote syslog collector. Since we hadn't officially described it in the docs, it wasn't officially supported. I am please to say we now have, here.


It's very simple to setup, and now if your organisation's policies require/recommend it, you can do so while being fully with the appliance support rules.

Share This:

As part of Premier Support, I was recently on-site at a customer for a few days, doing some "mini consultancy" work, mainly looking at extending Network Device discovery. Here, I want to make some notes to highlight some defects/surprising behaviour, and some of the things I was able to help the customer with.


Standard Network Device discovery


Many customers deploy SNMP credentials to discover Network Devices, and are quite happy with the coverage of supported devices, and/or the turnaround of adding new ones in monthly TKU updates after submitting a new device capture. Typically, Discovery is used for basic inventory recognition (being synced to CMDB) and importantly the discovery of the connection between a switch and the Host nodes it is connected to. However, the customer I was working with wanted to dig deeper into the data...


Problems and Gaps Identified


No Linkage between interfaces and IPs


In contrast to Host nodes, the interfaces and IPs of a Network Devices are not shown in a unified table. Instead they are displayed separately, and by default there is no connection in the UI or data model between an IP and the interface it is connected to. It turns out that if you turn on virtual interface discovery (see Managing network device virtual interface discovery), a side effect is that you do get a link from IP to interface and vice-versa. I logged defect DRUD1-25944 for this.


Further, I my customer wanted a more unified UI for the network interface table, like we provide for Hosts. DRUD1-272124 is logged for this. In the meantime, I was able to provide my own "hotfix" to the core code to get a just-acceptable display.


Incomplete documentation


We document how to enable virtual interfaces: Managing network device virtual interface discovery, however IMHO this document is lacking in several ways. It only mentions how it controls virtual interface discovery. It doesn't mention interface-IP linkage as a side effect. Why does it have to be controlled on the command line, not a UI option? Why would you not want it on by default - are there any downsides? If yes, what are they? I created docs defect DRUD1-26743 to improve this.


Not all network interfaces discovered


By turning on virtual interface discovery, more interfaces are discovered (see above). However, core code maintains a whitelist of "interesting" interface types:


0   # unknown

6   # ethernet csmacd

7   # iso88023 csmacd

8   # iso88024TokenBus

9   # iso88025TokenRing

15  # fddi

62  # fastEther

69  # fastEtherFX

71  # ieee80211

117 # gigabitEthernet

54  # propMultiplexor

161 # IEEE 802.3ad Link Aggregate


and drops any that don't match this list. This list was added a long time ago and is no longer appropriate IMHO; this was logged as defect DRUD1-26655, planned for fix in FF release, tentatively targetted for 2010-02. As part of Premier Support, I was able to provide the customer a temporary update to remove the filter until then.


Cisco firmware image file not discovered


A simple custom pattern was written to extract this from OID and populate the Network Device node, by calling the discovery.snmpGet() function. RFE DRDC1-13530 was logged to request this OOTB, and this Idea (feel free to vote on it) was raised on request of Engineering.

Interface statuses not discovered


A custom pattern was written to extract interface status from OID using the discovery.snmpGetTable() function and populate two new attributes:


Chassis and cards are only in Directly Discovered Data

As part of core discovery, we create DiscoveredCard and DiscoveredChassis nodes, but these are not visible from the main Network Device page. Also - ultimately, information will need to be consumed in the CMDB, and it is not recommended to attempt to write a sync mapping directly from DDD. So, I wrote a custom pattern to copy the data from the DDD into a couple of lists of Detail nodes, for each type, and created links from the cards to their corresponding containing Chassis:

This has been logged as an improvement, DRUD1-26654 with a tentative fix date targetted around 2019-11.


DiscoveredCard nodes missing descriptions


While looking at the data for the above point it was found that most DiscoveredCard nodes have no description. We think there is more data available in the MIB than we are pulling; this was logged as improvement DRDC1-13628.


Protocol Data


My customer was interested in extracting specific entries for different network protocols that may be configured: BGP, OSPF, and the Cisco-specific EIGRP. It was fairly simple matter to write a custom pattern to pull entries from the 3 SNMP tables and create 3 lists of Detail nodes that corresponded to these entries.


Future Work


This additional data that is now in Discovery needs to be populated into the CMDB, so I shall need to write some custom sync mappings.

Share This:



The BMC Discovery documentation looks a little different today. We have applied a new presentation layer for the content. It provides:

  • A responsive design to handle mobile and desktop users.
  • A version picker on all pages, in a drop down above the page tree. This replaces the original versions banner that we had for many years in BMC Discovery.
  • A table of contents on the right hand side of each page that stays visible when you scroll.
  • "Next page" and "previous page" navigation.
  • "Was this page helpful" buttons on every page.


One of my personal favorites is the improved look of tables.


Do please continue to comment on the documentation, like or dislike pages, and let us know how we can improve it.


Thanks, Duncan.

Greg DeaKyne

July TKU Released

Posted by Greg DeaKyne Employee Jul 3, 2019
Share This:

Greetings Community!


This past Monday, if you are subscribed to TKU release announcements, you saw that July is our first month of our new cadence for TKU release.  As a reminder to the timing changes, the TKU and OSU releases wll be made available on EPD on the first Wednesday of the month.  SaaS customers on BMC Helix Discovery will have the latest TKU applied to their Development environment on the first Wednesday of the month and their Production environment on the second Wednesday of the month.


We have a lot of exciting new content to announce and the details can be found on the July 2019 TKU release page.  Highlights include several new patterns for software products, enhancements to existing software patterns, and general bug fixes.  In this latest TKU release, we have included 29 new network device definitions.


If you are discovering cloud resources, we have introduced a new cloud inventory capability with essential information about those cloud services and in the July TKU we have started with roughly 15 new AWS products.  In addition, we are still focused on providing deeper discovery on patterns for cloud services and we are now making that available for Amazon ElasticSearch and Amazon Elastic Container Services for Kubernetes (EKS).


The July TKU is certainly packed with a lot of good additions to the Discovery portfolio.  We look forward to your feedback on what is advancing the impact of your Discovery data and what is missing and key that we can include in future TKU updates.


Greg DeaKyne

Product Manager, BMC Discovery

Share This:

Greetings Community!  Greg here, Product Manager for Discovery (intro post from April).


We have recently released a new Distributed Storage model for Discovery via the May TKU (Release Notes).  The Distributed Storage Model is a set of multiple physical systems where storage capacity and computing power are grouped together to behave as one single storage system (cluster).  We have this new model available across multiple storage systems from vendors such as EMC, NetApp, & Nimble.  For more information on the Distributed Storage model, the new dedicated page on these technologies can be found here.





After you've had a chance to try out the May Storage TKU with some of these storage systems, we'd love to hear your feedback on how it's improving the discovery of your datacenter.  Feel free to post below and let us know your thoughts!

Share This:

When importing root node keys from a large environment, tw_root_node_key_import may run for many hours before completing. If it is not run using 'screen', the session may timeout, and the import may fail without error or notification. As a result, not all of the root node keys may be imported.


BMC now recommends to run "screen" before running tw_root_node_key_import to prevent this session timeout failure. See

Share This:

I would like to take this opportunity to introduce myself to this very active and engaging community.  My name is Greg DeaKyne.  I was born and raised in Indiana and escaped the cold winters for sunny Charleston, South Carolina almost 8 years ago.  When I’m away from the keyboard, I’m staying busy running around town with my two daughters (4 & 6) between ballet practice, gymnastics, guitar practice, soccer practice, and hopefully a few trips to the beach.  Before kids, I used to spend my free time on the golf course, but my game has gotten pretty rusty over the past 6 years. 


I started using BMC software as a customer over 10 years ago but will be frank with you that I haven’t had the opportunity to touch it in a few years. I led the team that rolled out ADDM, CMDB, BladeLogic, and Atrium Orchestrator.  We were utilizing the toolset during a transformation of our IT teams as we integrated many acquisitions, datacenter consolidation, increased security posture, and enabled front line support via tools and automation.


I have spent the majority of the past 15 years leading multiple IT teams delivering many global SaaS offerings across multiple colo, managed service, and public cloud environments.  I was managing teams responsible for all aspects of the datacenter including compute, storage, database, operating system, application, and networking. 


I have seen the power that Discovery can provide any size organization and I look forward to working with you all (y’all for my Charleston neighbors) as we improve this product through one of the most active communities at BMC.


Today is the start of my third week at BMC and so you will start to see me interacting more in the coming weeks as I continue to learn more about what we are currently working on and sharing with you what the future of BMC Helix Discovery will be.



Share This:

The December OSU updates many packages, and upgrades the operating system to CentOS 7.6. Included in the upgrade to 7.6  is an update to the sudo package.


The change in sudo includes: “PAM account management modules are now run even when no password is required.” [See the Red Hat documentation for more information]


For some processes in BMC Discovery, the tideway user uses sudo to run certain system level programs. Where user passwords expire, the changed processing of the PAM modules would request users to change the password, which in turn would have caused automated sudo usage to fail. This would be particularly problematic for customers that have strict expiry policies (STIG) on the appliance command line users.


The update to sudo-1.8.23-3.el7 (and only sudo) has been excluded from the December OSU while the we determine the full extent of the changes required.


Update: 8th April 2019. The April OSU will now contain any updates to sudo.

From the Aprill 2019 OSU, Discovery will utilise the module in the PAM sudo stack against a specific list of users (pam_localuser).

Share This:

Hi Everyone!


Our community expertise and interaction is our strength and we want to make sure we are capturing the wealth of knowledge our customers obtain while using our products.

Screen Shot 2018-11-20 at 17.27.26.png

You can now provide comments and feedback on Discovery knowledge articles.

Share This:

Hello Discovery community!


If you have been browsing and are following BMC social media you will notice a lot of buzz around Helix Discovery.  Marketing and sales were too excited to wait and are shouting out the availability of Helix Discovery.  The cat is out of the bag on the worst kept secret in the industry   I would like to officially announce the launch of BMC Helix Discovery, our cloud native service offering.  More technical details to come in the coming weeks as well as a technical deep dive in early December.


I encourage you to take a look at the new web page and marketing content here:


Helix Discovery - BMC Software


Worth noting, the on-premise version, "BMC Discovery" is alive and well, there is no plans to deprecate this offering and we see many valid use cases for customers choosing to continue to use the on-premise version.  We intend to align functionality and features between the two solutions.  For example capabilities like TPL pattern development and application modeling will be the same in both SaaS and on-premise.  Please feel free to post any questions you may have, we look forward to your comments.



Share This:

Greetings Community,


We have released a patch update across all our supported versions of BMC Discovery to address important defects, including security fixes.


The files are available for download on the BMC Electronic Product Distribution (EPD) site and we encourage you to patch your environment at your earliest opportunity.


Follow the links below to release notes on the various patches:


In addition, in 11.3 patch 1, Discovery now provides capabilities that help administrators address the personal data protection and privacy requirements associated with the General Data Protection Regulation (GDPR). The GDPR is a set of rules and principles governing the handling of personal data of individuals located in the European Union (EU). Find out more here.


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

Share This:

For several years, Discovery has had an integration with RSA SecureID for 2 factor authentication to the appliance. However, at 11.3 it has been deprecated, and I cannot recommend its use because:


  • It has only ever been tested with Authentication Agent V7.1 for Apache
  • This version is old and no longer supported by the vendor
  • It is not supported on the current appliance OS
  • BMC has no RSA infrastructure to perform regression or other tests.


In the 11.3 docs we instead recommend RSSO. Unfortunately, it is not possible to use RSSO (it was in ASSO but the feature was not carried over to RSSO). I have logged a defect to get the docs updated, but it means anyone currently using the integration will have to think about how they can move off this mechanism.


If you are currently using this integration, or would want to in the future if there was a fully supported implementation, please contact me directly. I want to collate responses and pass to Product Management.

Share This:

Details of a critical vulnerability in the dhcp clients shipped on RHEL, and CentOS, 6.x and 7.x have been released and designated CVE-2018-1111. This affects all currently supported versions of the Discovery appliance. We have decided to bring the release of the May OSU forward to accommodate and will release ASAP. We strongly recommend that customers update, particularly in environments that use DHCP.


CVE details:


Red Hat security errata:




The vulnerability allows a malicious DHCP server to manipulate a NetworkManager integration script (shipped with the dhcp clients) to run arbitrary commands as root when the interface in question has DHCP enabled and is managed by NetworkManager.


The 6.x May OSU contains updates for the kernel (CVE-2018-8897), the dhcp client update and a timezone update.

The 7.x May OSU is substantial, and moves the base OS from CentOS 7.4 to 7.5 – and includes the kernel and dhcp client updates listed above.


Update: 22nd May 2018
The OSU should now be available on EPD. For those interested, updates for CVE-2018-3639 (Spectre/Meltdown variant) are *not* included in this update. We will shortly release the May monthly OSU which will contain those fixes.


Update: 23rd May 2018

Please note, I refer to the May OSU in the blog post and then, in the update, say "we will shortly release the May monthly OSU". We chose to bring the May OSU forward but then the Spectre/Meltdown variants were announced and patches made available. There is another May OSU coming (e.g. 6.18.05.xx where xx is later than the 16th) that contains these fixes (and one or two other updates) but will be released at the "usual" time in tandem with the TKN.


Apologies for the confusion

Filter Blog

By date:
By tag: