Post: How to Resolve Failed Cognos Schedules by Reassigning Credentials

In some situations employees leave companies and the organization has not fully prepared for their exit. One specific scenario when an employee leaves that causes a great deal of extra work on IBM Cognos administrators involves the ex-employee’s scheduled jobs, reports, etc.
Let’s say that Ed has configured many scheduled jobs and reports that go out to a number of people, but he has left the company. Shortly after Ed’s last day, several of these people are not receiving their scheduled Cognos reports. These employees contact their administrator. The administrator investigates and sees that these specific failed reports are attempting to use Ed’s account and since he has left the company, his account in LDAP is inactive, causing the reports to fail.

In IBM Cognos, schedules are associated with a “credential,” which is a security token that is associated with a Cognos user. In this case, Ed’s schedules execute and authenticate through his credential. His stored credential passes to the authentication source (e.g. LDAP, Active Directory, etc.) to get logged in. After an employee leaves, their account becomes inactive in LDAP, AD, or the like, and all of their many scheduled jobs and reports will fail. The Cognos admin is then tasked with figuring out how to find and then reassign all of the ex-employee’s schedules.

In Cognos, there is no easy way to do this. There is no search feature that allows you to find all schedules that use a specific Cognos user’s credential. In this scenario, it would take all of the recipients of Ed’s schedules to contact the administrator when they didn’t receive their expected reports. But, this doesn’t allow the administrator to know for certain if they have found every schedule using Ed’s credential. Think about the schedules that run once a month, or once a quarter, and so on…the scheduled reports that aren’t top-of-mind. These schedules that run infrequently will create an ongoing project that could actually be resolved in less than 5 minutes with some handy software, which we’ll get to in a bit.

Additionally, the administrator now needs to change the credentials on all of Ed’s schedules in order for them to execute. But in Cognos, credentials on schedules can only be changed one at a time.
That handy software I mentioned is MotioPI Pro, which provides a much simpler and faster way to manage this headache. The steps below show how to do it in MotioPI Pro.

1. Open a Schedule Panel.
2. Select Edit Filters (We will need to add a filter to only search for schedules whose credential property is set to Ed, the ex-employee).
3. Double click the Property Value filter from the available filters list (or you can highlight it and press the Add button).

4. From the Property Filter window, select the Credential property from the drop down list.
5. Enter the credential property of the ex-employee in the Value text area. In this example, we will enter Ed’s credential.
6. Press OK to finish defining the credential property filter.
7. Press Apply to add this filter to the Schedule panel’s list of filters.
8. Then press Submit to issue the query to Cognos to find all scheduled items that match ex-employee Ed’s credentials.

9. Now that MotioPI Pro has located all of Ed’s schedules, use the Change Access Credentials action button to change the credentials of Ed’s schedules.
10. The Change Credentials Options dialog will open. Use the Browse button to find the person to reassign all of Ed’s schedules to.
11. In the Security Directory, expand the namespace and find the user’s name who will take over the schedules.
12. Press the OK button to update the Access Credentials.
13. Press Change Credentials to perform the action across all of Ed’s schedules.

Voila! We found all of Ed’s schedules and reassigned them in less time it takes to finish a cup of coffee!
See what else you can do in MotioPI Pro. {{cta(‘f9d45cca-c1cf-4f1e-b890-5f0720a510bf’)}}

Scroll to Top
As the BI space evolves, organizations must take into account the bottom line of amassing analytics assets.
The more assets you have, the greater the cost to your business. There are the hard costs of keeping redundant assets, i.e., cloud or server capacity. Accumulating multiple versions of the same visualization not only takes up space, but BI vendors are moving to capacity pricing. Companies now pay more if you have more dashboards, apps, and reports. Earlier, we spoke about dependencies. Keeping redundant assets increases the number of dependencies and therefore the complexity. This comes with a price tag.
The implications of asset failures differ, and the business’s repercussions can be minimal or drastic.
Different industries have distinct regulatory requirements to meet. The impact may be minimal if a report for an end-of-year close has a mislabeled column that the sales or marketing department uses, On the other hand, if a healthcare or financial report does not meet the needs of a HIPPA or SOX compliance report, the company and its C-level suite may face severe penalties and reputational damage. Another example is a report that is shared externally. During an update of the report specs, the low-level security was incorrectly applied, which caused people to have access to personal information.
The complexity of assets influences their likelihood of encountering issues.
The last thing a business wants is for a report or app to fail at a crucial moment. If you know the report is complex and has a lot of dependencies, then the probability of failure caused by IT changes is high. That means a change request should be taken into account. Dependency graphs become important. If it is a straightforward sales report that tells notes by salesperson by account, any changes made do not have the same impact on the report, even if it fails. BI operations should treat these reports differently during change.
Not all reports and dashboards fail the same; some reports may lag, definitions might change, or data accuracy and relevance could wane. Understanding these variations aids in better risk anticipation.

Marketing uses several reports for its campaigns – standard analytic assets often delivered through marketing tools. Finance has very complex reports converted from Excel to BI tools while incorporating different consolidation rules. The marketing reports have a different failure mode than the financial reports. They, therefore, need to be managed differently.

It’s time for the company’s monthly business review. The marketing department proceeds to report on leads acquired per salesperson. Unfortunately, half the team has left the organization, and the data fails to load accurately. While this is an inconvenience for the marketing group, it isn’t detrimental to the business. However, a failure in financial reporting for a human resource consulting firm with 1000s contractors that contains critical and complex calculations about sickness, fees, hours, etc, has major implications and needs to be managed differently.

Acknowledging that assets transition through distinct phases allows for effective management decisions at each stage. As new visualizations are released, the information leads to broad use and adoption.
Think back to the start of the pandemic. COVID dashboards were quickly put together and released to the business, showing pertinent information: how the virus spreads, demographics affected the business and risks, etc. At the time, it was relevant and served its purpose. As we moved past the pandemic, COVID-specific information became obsolete, and reporting is integrated into regular HR reporting.
Reports and dashboards are crafted to deliver valuable insights for stakeholders. Over time, though, the worth of assets changes.
When a company opens its first store in a certain area, there are many elements it needs to understand – other stores in the area, traffic patterns, pricing of products, what products to sell, etc. Once the store is operational for some time, specifics are not as important, and it can adopt the standard reporting. The tailor-made analytic assets become irrelevant and no longer add value to the store manager.