IV62836: ACTIVATED AN ANALYSIS GLOBALLY, NOW WEB REPORTS BASED ON THAT ANALYSIS ARE BROKEN

APAR status

• Closed as program error.

Error description

• The customer is experiencing an issue they have an analysis that
  we activated locally.  They recently activated the analysis
  globally.  There are six (6) Web Reports and related scheduled
  tasks (that e-mail the reports) that are based on this analysis.
  All 6 reports are now "broken", no longer work, show that the
  analysis is not activated - even though it is).  They want to
  know how to fix this without re-creating all of the web reports
  and assocaites scheduled tasks from scratch.
  
  The analysis in question is a custom analysis that was created
  in April, 2012.  It is a relatively simple analysis that has 6
  properties.  Since the time of creation, there have also been 6
  web reports that are populated based on the   analysis, as well
  as 6 corresponding scheduled tasks that e-mail the results of
  those web reports.  The specific change that was made to the
  analysis was simply to activate it Globally (using a Master
  Operator account).  Until now,
  it was always activated locally by a console operator account.
  As soon as they changed the activation status from Local to
  Global, all 6 web reports and scheduled tasks broke.
  
  This is not the first time this has happened.  In the past,
  there have been at least 3 other examples they can recall, all
  involving other analysis and related reports / scheduled tasks,
  where any kind of a change to the analysis breaks the related
  web reports and scheduled tasks.
  
  The customer also provided the following clarification:
  
  +++ Start Customer Clarification +++
  
  Before I activate extended logging, I want to provide more
  background
  information so the issue is very clear.  The analysis in
  question is a
  custom analysis that was created in April, 2012.  It is a
  relatively
  simple analysis that has 6 properties.  Since the time of
  creation,
  there have also been 6 web reports that are populated based on
  the
  analysis, as well as 6 corresponding scheduled tasks that e-mail
  the
  results of those web reports.  The specific change that was made
  to the
  analysis was simply to activate it Globally (using a Master
  Operator
  account).  Until now, it was always activated locally by a
  console
  operator account.  As soon as we changed the activation status
  from
  Local to Global, all 6 web reports and scheduled tasks broke.
  
  This is not the first time this has happened.  In the past,
  there have
  been at least 3 other examples I can recall, all involving other
  analysis and related reports / scheduled tasks, where any kind
  of a
  change to the analysis breaks the related web reports and
  scheduled
  tasks.
  
  The last time this happened, our AVP (Aram  Eblighatian) got
  involved
  and took a close look at what was happening.  He determined that
  although the breaking of the web reports and scheduled tasks was
  not the
  desired or expected behavior, it definitely did happen, and the
  cause
  was an underlying unique ID (at the BES Database level) that is
  assigned
  to each analysis.  Essentially, each analysis has a unique
  identifier in
  the database.  When web reports are associated with that
  analysis, the
  web reports reference that unique ID.  Whenever a change is made
  to the
  analysis, the unique ID is changed / modified, behind the
  scenes, and as
  a result, all of the web reports immediately break, because they
  are
  still pointing at the old unique ID associated with the
  analysis.
  Ideally, they should update automatically, but they do not.  In
  any
  case, the fix involved logging into the BES Web Reports database
  using
  SQL Query Analyzer and running an update query to make all of
  the web
  reports reference the new unique ID of the analysis that was
  changed.
  
  This was a few years ago, and I would expect by now, that this
  behavior
  would be a well known artifact at BigFix support, with a
  documented
  procedure to resolve it.
  
  Please let me know if this helps you help me resolve the
  problem, or if
  you still need web reports debug logging activated to proceed
  with
  
  +++ End Customer Clarification +++
  
  I have been informed me that it has indeed been  fixed in 8.2,
  but only for new reports and the fix will not address older
  reports.  The PMR states that the customer is running 8.2.0.  So
   testing a v9 instance seems to corroborate that it is indeed
  fixed for new reports.
  
  I have also been informed that the SQL statements to correct
  this in older reports unfortunately wouldn't be 'generic' and
  that they'd have to be tweaked to work specifically with your
  IDs to address the issue.
  
  Even though there are only a few reports involved, the customer
  stated it is extremely arduous, difficult, and time consuming to
  re-create the reports from scratch.  They also stated that if it
  were truly a simply and quick matter to resolve, they would have
  just done that and not bothered to open a ticket with IBM
  support.  So the customer is insisting that we provide them a
  means to resolve this problem without having to re-create all of
  the reports from scratch.
  
  In addition they stated that if this problem has been resolved
  in TEM 8.2 and any new reports created going forward will not
  have this issue, then I am wondering is there a process to
  pro-actively retrofit all of our existing reports (created in
  TEM / BigFix versions prior to 8.2) with the 8.2 fix, so they
  will never have this issue in the future?
  
  As this issue is getting hot, any assistance you can provide on
  correcting these six web reports for the customer would be
  greatly appreciated.
  
  Please see Bugzilla tickets 63602 and 54915 for additional
  information on this issue.
  

Local fix

• N/A
  

Problem summary

• Fixed in IBM Endpoint Manager 9.2 (fixpack 5)
  
  
  General availability End of Q2 2015 (release schedule subject to
  change).
  

Problem conclusion

• This is resolved in:
  IBM Endpoint Manager 9.2 (fixpack 5)
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  TV EP MG WB RPT

• Fixed component ID

  5725C43WR

Applicable component levels

• R920 PSY

     UP