Skip navigation
1 2 3 Previous Next

Discovery / ADDM

116 posts

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.




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.


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.


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


Hello Everyone,


I am pleased to announce BMC Discovery 11.3 is now generally available.  This release is a true testament to our ability to introduce features and content that align with the ever changing new technologies introduced in the market while also having an ear to the ideas coming directly from customers.


A discovery webinar on What's New with BMC Discovery 11.3 is scheduled for April 5, 2018 where we will go into detail on the features briefly explained in the next section.  Below is a link to register to the webinar, more details on the What's New webinar can be found at the end of this post.


Register now


Below is a brief guide on some of the major features implemented in version 11.3:



BMC Discovery 11.3 - What's New


Container Infrastructure Discovery

BMC Discovery 11.3 expands discovery capabilities to container management solutions like Kubernetes, OpenShift, and CloudFoundry and their supporting compute on public cloud, private cloud, traditional datacenter, and hyper-converged infrastructure such as Nutanix.  Container management software has previously been discovered and modeled as Software Instances using TKU patterns. The introduction of container discovery with BMC Discovery 11.3 extends this to discover the containers that the management software is controlling. Discovery of containers is triggered by the creation or update of an SI representing the container management software, and then additional patterns query the container management software to determine the containers it is running.


Related Idea:  Support of MultiCloud - OpenShift Discovery



Direct REST API Discovery

With BMC Discovery 11.3 we will begin to introduce content that is driven by direct discovery through REST APIs.  This will address the trends we are seeing with major storage and network infrastructure vendors to provide more discovery and dependency mapping information via their REST APIs.  An example of a storage device that can only be discovered by using direct REST API calls is Nimble storage devices.


When a Nimble storage device is discovered as part of a discovery scan, a Storage System node is created. TKU patterns then trigger to deeply discover the details of the storage system. For custom extensions, you can write a pattern which triggers on the storage system representing the Nimble device, and the pattern can then query the device using its REST API using the enhanced discovery.restfulGet TPL function.


The 11.3 release ships with a new credential type to enable you to discover Nimble storage devices using their REST APIs. Further new credential types will be provided in future knowledge updates without requiring a new product release.



Model Changes

The following major changes have been made to the BMC Discovery model:


Software Container

On upgrade to BMC Discovery 11.3, existing Detail and Virtual Machine nodes that represent containers are converted to the new Software Container node kind.


Hardware Container

The new Hardware Container node represents a single physical device which contains multiple hosts, network devices and other components. For example, a blade enclosure which is discovered via a management controller, or a hyper-converged device containing compute and storage. The Host Container node is used to represent a computer that is logically partitioned into a number of hosts, as opposed to containing physically separate devices. On upgrade to BMC Discovery 11.3, existing HostContainer nodes that were used to represent physical devices containing hosts, network devices and other components are converted to the new Hardware Container node kind.


Related Ideas:

Discovery of Nutanix serial number via vCenter API

Nutanix Prism Software - Need TKU Pattern



Remedyforce CMDB Sync

CMDB synchronization is now extended to BMC Remedyforce with simple UI-based configuration in BMC Discovery.  With the enhanced integration between Remedyforce and BMC Discovery, devices, components, services and relationships that are discovered in BMC Discovery can be automatically imported into and synchronized with Remedyforce CMDB. This integration no longer requires Pentaho. The configuration is done within the solutions and the data mappings and transfers are achieved with APIs.



CentOS 7 Migration Options

The OS has been updated to CentOS 7 for new installs, and remains CentOS 6 for upgrades. An easy backup/restore option is available to migrate appliances to CentOS 7.


The replacement of earlier OS versions with CentOS 7 ensures continued support for the appliance OS during its lifetime, and provides support for newer hardware where you choose to install on hardware. It also provides SMB 2 support, and Apache Web Server version 2.4.



Additional Features Introduced from Community Ideas

Stacked switches

BMC Discovery 11.3 now fully discovers stacked switches. Previous versions discovered stacked switches, but were unable to differentiate the stack master and members. Stacked switches now have the attribute stack to indicate whether it is part of a stacked switch, and the stack master has the attribute stack_master. Network device node pages for stacked switches also provide a list of, and links to other members of the stack. For more information, see Viewing a network device.

Discovery of stacked and virtual switches

Virtual network devices

BMC Discovery 11.3 now fully discovers virtual network devices. Previous versions could identify the network device, but not that it was virtual. Virtual network devices now the attribute virtual to indicate whether it is virtual. Network device node pages for virtual network devices also show and link to the virtual machine containing the device. For more information, see Viewing a network device.

ADDM: Discover and Sync IsVirtual flag for Network Devices


On CentOS 7 appliances, the open source open-vm-tools utility replaces VMware's VMware Tools. This is in line with VMware's recommendation that open-vm-tools be used on Linux hosts in preference to VMware Tools.

add vmtools installation to the gui



More Information

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

Read more in the Release Notes


Discovery Webinar:  What's New with BMC Discovery 11.3

Please join us as we share our knowledge on the newest feature to come to BMC Discovery 11.3


For this session we will focus on the following topics:


  • Overview of v11.3 Themes
  • Deep Dive into What's New with v11.3
  • Q&A


Register now


Date and Time:

Thursday, April 5, 2018 10:00 am, Central Time Zone (Chicago, GMT-06:00)

Thursday, April 5, 2018 11:00 am, Eastern Time Zone (New York, GMT-05:00)

Thursday, April 5, 2018 8:00 am, Pacific Time Zone (San Francisco, GMT-08:00)

Thursday, April 5, 2018 4:00 pm, Europe Time (Paris, GMT+01:00)

Thursday, April 5, 2018 3:00 pm, UK Time (London, GMT)


Duration: 1 hour


If you cannot attend at that time, a link to watch the recording will be sent after the event.


I saw Tool in 2007 at Brixton Academy; great show. Somewhat less enjoyable (depending on your musical taste, I suppose) is having to install VMware Tools on VMware-deployed appliances. We document the procedure here.


So far, so good. Unfortunately, whenever a new kernel is installed (product version upgrade or OSU) VMware tools needs the modules recompiled for the new kernel. After you have rebooted, you will see a red baseline icon like this:



which you can click through, and observe the warning that it's not running:


However, you are not given any information as to why, and you may miss this completely if you are not in the habit of monitoring and correcting all major baseline events. So for the moment, you will just have to keep in mind that you should re-run the


install script after an OSU upgrade. Note: you can use the "-d" flag to take all the defaults without being prompted.


For reference, we have DRUD1-22356 to try and make the user experience better in this regard.


[Note: edited, after discussion with Kerryn Wood]


I wish to draw your attention to a problem applying 2018-01 TKU on an appliance earlier than 11.2: an upstream package naming problem leads to a failure and a non-working appliance *if* this is subsequently upgraded to 11.2.X. This is not good.


To reiterate: the 2018-01 OSU will install fine on 11.1, and you might want to do that for Meltdown/Spectre mitigations. But you should not attempt an upgrade to 11.2.X on a 11.1.X / 2018-01 OSU appliance. I expect we will issue a new OSU you will need to install on 11.1.X before upgrading to 11.2.X in this situation. [UPDATE: New OSU is now available on EPD and replaces the previous one]


It would be fine to take an 11.X appliance on a pre-2018-01 OSU, upgrade to 11.2.X and apply 2018-01 OSU to it.


While OSUs are normally very easy to apply (UI upload; wait a bit; reboot) this reminds us that no change is completely without risk, and updates should always be applied on UAT first - before considering a production upgrade.


For reference, this is tracked as defect DRUD1-22350.


I admit it: we don't get many issues around OpenVMS,


Although I can't say I have really used it, I get vaguely nostalgic for the dusty old MicroVax that sat next to me for a while at the University of Nottingham. And even earlier I think I remember seeing Jodrell Bank using them for telescope control. So in contrast to the usual periodic Apple, Microsoft or Linux (and now Intel) security vulnerabilities, this problem caught my eye.


If you work in a large organisation, you might still have a few of these machines refusing to get replaced, and/or have very specialised uses. You might want to check you are comfortable with the risks, and not assume they are completely impenetrable. Find them with something like:


  • search Host where os_type matches regex "OpenVMS"


Note we also End-of-Life data for the OS up to 7.3-2 in EDP module SupportDetail.OS.HP.OpenVMS. I am going to talk to the TKU team about getting this table updated for later versions; it appears that the current version 8.4-2 is supported into 2021.


If you have any experiences with this OS, I would be interested to hear from you.


For a long time, the TKU Extended Data Pack has been able to mark software end-of-life, such as this for one of my ESX servers:



However it may have gone unnoticed to you (I certainly had missed it, until a customer question prompted me to check) that the EDP now supports some hardware end-of-life data, for example:




2018-Jan EDP has some data for different kinds of hardware:


No doubt, this list will expand over time. If you have an EDP license, you might want to check how the current list covers your estate, and log important missing devices with Support as RFEs. For example, to find Hosts that have no EOL data, try this query:


search Host where not virtual and vendor and model and not nodecount(traverse ElementWithDetail:SupportDetail:HardwareDetail:SupportDetail) show vendor, model processwith countUnique(0, 0)


Hello Everyone,


I am pleased to announce that we have expanded our support for deployment of the BMC Discovery virtual appliance to include many popular virtualization and cloud platforms.  Please review the following documentation to get details on what platforms are supported and the steps involved in converting the OVF image to run on the platform of choice:


Supported virtualization platforms - BMC Discovery 11.2 - BMC Documentation


Your friendly product manager,




UPDATE 2/1/2018:


We have further updated the OSU packages which contain fixes from Red Hat which addresses previous issues we reported with Xen and AWS based virtual guests.




This OS Update (OSU) contains fixes and mitigations for the Meltdown and Spectre vulnerabilities. As a single-use restricted appliance, the risk of these vulnerabilities to BMC Discovery is low, but to follow security best practices we would recommend applying the update in most cases.

This update also contains the Red Hat fix for the issue, noted in the previous (23 January 2018 on CentOS 6 and 22 January 2018 on RHEL 6)OSU where a paravirtualized guest on XEN, including AWS and other cloud platforms, could be rendered unbootable.

For more information on this OSU, please reference the following documentation:

For Discovery appliances on v11.1 or earlier:  25 January 2018 on RHEL 6 - BMC Discovery OS upgrades - BMC Documentation

For Discovery appliances on v11.2:  27 January 2018 on CentOS 6 - BMC Discovery OS upgrades - BMC Documentation




Hello BMC Discovery Community,


We would like to make you aware that the underlying OS used by BMC Discovery is affected by the spectre and meltdown vulnerabilities.  Red Hat have published a kernel update (version 2.6.32-696.18.7)  to mitigate some aspects of the ‘Meltdown’ and ‘Spectre’ CPU vulnerabilities. We had planned to roll this into an extra OS update.


However, as we prepared this update we learnt that this kernel update had rendered some systems unbootable. This only applies to certain hypervisors and certain VM build types, but given the serious consequences we could no longer publish the update in its current form. We are now working with Red Hat in pursuit of an early resolution to the fault.


Although these CPU vulnerabilities are high profile at present, the risk to the BMC Discovery appliance is low. All variants of the vulnerabilities apply to locally-executing code gaining improper access to memory. As an appliance, the Discovery system should not be running any unapproved software, and perimeter security remains the main line of defense for the BMC Discovery appliance.


We will of course provide updated operating system packages when we believe it is safe to do so.


For more information on the vulnerabilities see the following pages:



CVE-2017-5754 - Red Hat Customer Portal



CVE-2017-5715 - Red Hat Customer Portal

CVE-2017-5753 - Red Hat Customer Portal




As many of you may be aware we released in the November 2017 TKU the ability to discover OpenStack environments using the cloud scan capabilities introduced in BMC Discovery 11.2.


OpenStack provides open source cloud software used to create public or private clouds. OpenStack software enables you to have virtualized computing platforms, as public clouds, private clouds hosted by a cloud provider, or in your own data center. At this initial release, BMC Discovery of OpenStack enables you to discover Compute (nova), Block storage (cinder), Load balancers (neutron and octavia), Orchestration (heat), and Shared file systems (manila) services running in OpenStack. Please visit the OpenStack documentation page for more information.


Discovering OpenStack - BMC Discovery 11.2 - BMC Documentation


We are very excited to be able to offer these types of content updates via TKU and look forward to hearing from you on how these new cloud resources are working in your environment as well as get any feedback on where you think we should go next with cloud discovery!




Your neighborhood product manager,




Dnsmasq is "a lightweight DNS, TFTP, PXE, router advertisement and DHCP server. It is intended to provide coupled DNS and DHCP service to a LAN". A number of vulnerabilities have been found that allow remote code execution and denial of service attacks.


Discovery is not vulnerable. Only one of the vulnerabilities, CVE-2017-14491, applies to RHEL/CentOS 6 and exists in the dnsmasq, dnsmasq-debuginfo and dnsmasq-utils packages - which we do not install on the appliance.


Much better wordsmiths than I have covered this on many sites, for example arstechnica and theregister, and covered quite comprehensively by Red Hat.


CVE-2017-14491 (CWE-122): RHEL6 is affected, we do not ship the dnsmasq packages.

CVE-2017-14492 (CWE-122): RHEL6 not affected.

CVE-2017-14493 (CWE-121): RHEL6 not affected.

CVE-2017-14494 (CWE-125): RHEL6 not affected.

CVE-2017-14495 (CWE-400): RHEL6 not affected.

CVE-2017-14496 (CWE-190->CWE-125): RHEL6 not affected.

CVE-2017-13704 (CWE190): RHEL6 not affected.


I think we should take the opportunity to come up with a codename too - in the comments section below.


We've had a number of questions about the permissions that BMC Discovery requires to fully discover Storage resources in Microsoft Azure, so I thought I would try and explain the situation.


Like every other system we can discover, BMC Discovery only needs read access to resources in Microsoft Azure. Helpfully, Microsoft provides a Reader role which gives read only access to all resources. Excellent, that's exactly what we need ...


However, in turns out that some Azure Storage values we would like to collect aren't directly available via the Azure Resource Manager API, specifically the size and encryption (D@RE) parameters for virtual hard disks (VHDs). For VMs which use VHDs (not Managed Disks) we have to query the Blob properties directly from Azure Storage. To do this, we must properly sign the request and that requires a Storage Key.


The Azure Resource Manager API provides a method to retrieve the keys, but this isn't covered by the Reader role, so Discovery needs the Microsoft.Storage/storageAccounts/listKeys/action permission. These keys provide Full Access to the storage resources so, in theory, these could be used to modify or even delete Storage Blobs. However, like any other credential, Discovery does not expose these keys to the user: there is no way to retrieve and use them in a pattern for example. Internally, Discovery retrieves the key when certain Azure Storage read operations are needed.


Microsoft's approach to this problem is to use Shared Access Signatures (SAS). However, for this to work for Discovery, we would need a SAS token for each Storage Account, which is a large configuration burden.


So, to sum up:


We need the Storage Keys to get size and encryption (D@RE) values for VHDs used by VMs. If you don't grant this permission (i.e. just use the Reader role), then the values will be missing. Discovery will still perform all other Azurescanning. You ONLY need to grant the permission if size and D@RE for VHDs is important to you.


If you are using Managed Disks, then BMC Discovery does not need the Microsoft.Storage/storageAccounts/listKeys/action permission - the Managed Disk API allows us to read all the values we want.


I hope this helps clarify the situation.


Hello Everyone,


We have introduced a patch to BMC Discovery 11.2 to address an upgrade issue found concerning customers who have integrated CyberArk with Discovery.  This issue has been corrected in patch 1 and we encourage all CyberArk users to use this patch for upgrade.  Full details can be found here.


Upgrading to Version 11.2 patch 1

It is very important that, for clustered deployments, all the members of the cluster are functioning prior to upgrade.


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


Downloading BMC Discovery Product Releases

All above Product releases are available from the BMC Electronic Product Distribution (EPD) site where they all replace their respective current GA files.


Thanks and enjoy!


The BMC Discovery Team

Filter Blog

By date:
By tag: