0 Replies Latest reply on Dec 4, 2019 8:55 PM by Andrew Mark Shaw

    TKU key changes

    Andrew Mark Shaw
      Share This:



      We're looking for some inputs on how to best manage TKU key changes. We've recently migrated some of the larger asset teams to CMDB - including database, web services, etc. These teams relate support, ownership, and other records directly to the SoftwareServer CI. When a TKU key change is introduced, these manually created relationships are broken. In addition, a recent WebSphere Application Server key change also heavily impacted on our application models. Each model was reviewed and in many cases, the new SI had not been added into models that included the old SI. We have not yet enabled cloud discovery, and though we plan to onboard shortly, looking at December's TKU release, I'm grateful that we aren't having to work through the latest set of key changes:

      As a result, the keys of all CloudRegion and CloudService nodes, and many contained nodes will change, even if you only discover a single account. If you synchronize to a CMDB, the identities of the corresponding CIs will also change.

      I believe this would have delayed Dec TKU deployment by several months while we analysed impact and planned workarounds.


      My question is, do BMC have recommendations around how best to reduce the impact of key changes? Because, while I do understand the documented reasons for each, the impact does not appear to be factored in at all.