Cisco CDR

Updating your scheduled AXL search when you update to 7.2

February 16th, 2024

We never require manual migration!  (well... almost never. there are some easy steps you have to do for 7.2)

Hello to all of our customers who use our ​“Supporting App For AXL”.

In Cisco CDR 7.2 we’re happy to say that fixed a longstanding issue that affected some large deployments. However, and this is regardless of whether that issue was affecting you, there is a little change that you or your admins will have to make, on the same day that you update the Cisco CDR app to 7.2 or higher. 

Our apologies for this — for most migration issues we write code in the app itself to ​“fix things” automatically right when the app is restarted after an update. However this is one of those rare cases where that approach wasn’t viable. As always feel free to reach out to us for assistance or questions, but here below are the steps to follow:

First, you’ll add two lines to your scheduled search

Follow these bullets below to add one line to the existing scheduled search that regenerates your devices lookup every night. 

  1. Click Settings at the top, then Searches, Reports and Alerts
  2. Change to ​“all” apps, change the ​“owner” field to ​“nobody” or ​“All”.
  3. Next look for a search that is most likely called ​“get_​devices_​for_​axl”. Use the ​“filter” field if you need to, to filter for ​“axl”, or perhaps ​“get_​devices”.
  4. Once you find it, edit that search. One way of checking you have the right one is that it should end with ​“outputlookup devices” and it should be enabled and scheduled.
  5. Towards the end of the SPL there will be this line:
    | stats values(*) as * BY name axlHost
  6. replace that one line with these three lines (essentially we’re just adding the second and third lines)
    | stats values(*) as * BY name axlHost 
    | lookup clusters axlHost output clusterId 
    | eval lastUpdated=now()

If your AXL app only connects to a single publisher, you can actually stop here, skip the second step, and you will be fine. On the other hand if you have multiple clusters or if you just like to go for that extra-correct config, proceed to the next step.

Next, updating your Clusters to associate each one with the correct axlHost value

  1. In the Apps dropdown, navigate to the Supporting App for AXL
  2. click Update credentials in the navigation bar
  3. You’ll see the existing AXL credentials listed. We wont change anything! Just need to make a note of the IP addresses or FQDN’s that you are using here.
    For example if the page shows you two stanzas: [10.10.20.30:8443:user1] and [foo.example.com:8443:user1] , then your two axlHost values to remember are ​“10.10.20.30” and ​“foo​.exam​ple​.com”.
  4. Now, in a separate window open the Cisco CDR app, click Settings in the navigation bar and then Define Clusters and Locales.
  5. Switch to the Edit/​Delete Clusters tab.
  6. For each of the clusterId values shown there, note that there is an ​“axlHost” field at the end that will be set to *.
  7. You may have to have a colleague help you map these two sets of values together, but for each clusterId, there will be one appropriate axlHost value. Paste that value in replacing the “*” entirely.
    (eg: following our example above, you might paste in 10.10.20.30)
  8. NOTE that you have to submit each row individually — the form is a little strange and only lets you update one row at a time.


That’s it. With the above changes done, the next time your scheduled search runs, it will generate the devices lookup with the correct columns that are needed in 7.2 and up.

Why was this necessary?

Before this, when two or more publishers had devices with the exact same device name, the devices lookup’s output fields like origDeviceDescription would be populated incorrectly. Instead of the device description field being populated correctly for that device from its cluster, it would instead get a multivalued-value of ALL of the descriptions from all of the N devices that happened to have that same name across all clusters. 

Furthermore, customers with geographically distributed clusters had a difficult time picking one single ​“non business hours” time to run a single monolithic ​“update” search, and have been asking for a way to decouple the updates to run int he middle of the night for each region. Although our docs don’t walk you through how to do this, if you reach out to us at Sideview Support we can help and we now have a reliable way for you to do this.

Thanks for reading. As always reach out with questions !

Related

The finalMobileCallingPartyNumber field is critical to SNR analysis, but it also illustrates the importance of looking beyond the more familiar fields.

December 30th, 2025

If you are running Cisco Unified Communications Manager (CUCM), you know how critical it is to your business.  However if toll fraud started happening on your system today, would you know right away? 

September 22nd, 2025

What to do when the RTMT installer just quietly fails on you every time.

September 3rd, 2025

Practical steps to investigate and diagnose audio issues in CUCM, including one-way audio, from sanity checking your ports and configuration, to using Sideview's app as your command center. 

June 19th, 2025

Download a 60-day free trial & work with your own live data

Start My Free Trial

By submitting this form, I agree to Sideview's Trial Internal Use License Agreement and Privacy Policy.