IBM Cognos v12 Admin common mistakes
IBM Cognos v12 Admin · Understand the traps and how to avoid them.
Treating the Cognos Analytics server as a single install and assuming the dispatcher, content store, and gateway all run in one process, then answering topology questions as if adding a dispatcher automatically adds a gateway.
The single-server install used in labs hides the separation between the gateway (web tier), dispatcher (request routing and batching), application tier services, and content store. Candidates memorize install steps but never build a mental model of which component owns which responsibility.
What to do instead
Draw the tiers explicitly before answering: browser -> reverse proxy/gateway -> dispatcher -> application services -> content store database. For each topology question, ask which tier is being scaled or moved and whether the gateway, dispatcher, or database must change too. Note that multiple dispatchers share one content store and require a shared gateway configuration.
Planning an upgrade as a straight in-place overwrite of the existing installation without exporting content, verifying the content store schema, or checking that the old and new versions can coexist on the same host.
Candidates conflate 'install the new version' with 'upgrade'. They skip the pre-upgrade content store backup, forget the schema/version compatibility check, and miss that a side-by-side install plus export/import is often the safer path and sometimes the required one.
What to do instead
Sequence upgrade answers as: back up the content store and configuration, confirm supported source and target versions and schema state, install the new version (side-by-side where supported), point it at a copied or upgraded content store or export/import content, then validate reports, schedules, and security. State explicitly that the content store must be backed up before any schema change.
Answering authentication questions by describing what users can see in the portal, rather than distinguishing the authentication provider (namespace) from authorization (Cognos groups, roles, and permissions).
The two concepts look similar in the UI because namespaces, groups, and roles all appear in the same administration area. Candidates also assume directory groups automatically grant capabilities, when capability access is governed by Cognos roles and explicit permissions.
What to do instead
Use a fixed test: authentication answers 'who are you' and is configured per namespace (LDAP, Active Directory, SAML, OIDC, custom Java provider); authorization answers 'what may you do' and is evaluated through Cognos groups, roles, and secured entries. When a question mentions sign-in, SSO, or trust, answer with the namespace; when it mentions capabilities, folders, or data, answer with groups, roles, and permissions.
Assuming a user's effective permissions are simply the permission set on the object they are opening, ignoring inherited permissions, group nesting, and the interaction between capability grants and object-level security.
Candidates read the object's access list and stop. They forget that permissions flow down the folder hierarchy, that a user accumulates permissions from every group they belong to, and that a denied capability can block access even when the object permission allows it.
What to do instead
Evaluate access top-down: identify every group and role the user belongs to, resolve inherited permissions from the parent chain, then check whether the required capability (for example, report consumption or authoring) is granted to those groups or roles. Remember that removing a user from a group is usually cleaner than adding explicit denies, and that a deny at a higher level can override a grant lower down.
Diagnosing a slow report or dashboard by proposing more RAM or a bigger application server before checking the query, the data source, and the cache.
Performance questions invite hardware answers, and candidates skip the cheap diagnostic steps: is the report hitting the database each run, is a cached result available, is the query poorly formed, is the data source connection pool exhausted, or is the bottleneck actually the content store?
What to do instead
Work the layers in order: report/query design (filters, aggregation, unnecessary detail queries), data source responsiveness and connection pooling, caching behavior (report service cache, query result cache, session cache), dispatcher batching and queue depth, then JVM heap and host resources. Mention monitoring the dispatcher and service metrics and reviewing logs before recommending infrastructure change.
Configuring schedules and jobs without accounting for time zones, credentials, and delivery failure handling, then assuming a failed schedule will retry or notify someone automatically.
Candidates focus on the trigger (daily, weekly, cron-like) and forget the execution context: schedules run under stored credentials, use a time zone that may differ from the user's, and produce status you must monitor. Delivery failures (email size limits, SMTP configuration, burst report output) are treated as out of scope.
What to do instead
For every scheduling answer, state the trigger, the run-as credentials, the time zone, the output format and delivery target, and the failure path (status in the job/schedule view, notification, log entry). Note that burst reports split output per recipient group and that large outputs may need a different delivery method than email.
Creating a data source connection and declaring it working without validating sign-in, testing the connection, or considering where credentials are stored and who can see them.
The connection wizard accepts input and saves, which candidates read as success. They overlook sign-in options (use the signed-in user's credentials, a fixed set of credentials, or external namespace credentials), driver and JDBC URL correctness, and the security implication of embedding a privileged database account.
What to do instead
Treat a connection as complete only after testing it from the server, confirming the driver and URL, choosing the sign-in mode deliberately, and deciding who may use the connection. Prefer sign-in that passes through the user's identity where the database supports it, and flag embedded credentials as a security decision, not a convenience.
Treating the content store as a black box and answering metadata questions by describing what appears in the portal, without knowing that the content store is a relational database holding report specifications, schedules, security entries, and package metadata.
Candidates interact with content only through the interface, so they never form a model of what persists where. They then cannot answer questions about backup, migration, schema upgrades, or why certain objects survive a deployment and others do not.
What to do instead
Anchor on the content store as the system of record: it is a supported relational database, backed up with native database tools, upgraded through supported schema processes, and never edited directly. Distinguish content store data (specifications, security, schedules) from the external data sources that reports query, and from deployment archives used to move content between environments.
Troubleshooting by restarting services and re-running the failing action, without first identifying which log or diagnostic source would confirm the failing component.
Restarting sometimes works, which reinforces the habit. Candidates do not know the log categories or where each tier writes, so they cannot tell a gateway problem from a dispatcher problem from a database problem, and they lose the evidence a restart would have preserved.
What to do instead
Before changing anything, capture the symptom, timestamp, and affected user, then consult the log for the tier implicated: web server/gateway logs for connectivity and SSO, application logs for dispatcher and service errors, and database-side logs for content store or query failures. Increase log detail only for the relevant logger, reproduce once, then revert the log level.
Assuming administrative changes to the analytics interface (themes, portal tabs, extensions, default settings) apply globally and immediately to all users, without checking scope and session behavior.
Candidates generalize from their own admin session. Many interface customizations are scoped to a group, a role, or a namespace, and users may need to sign out or refresh before changes take effect; some settings are per-user preferences rather than system defaults.
What to do instead
For each interface change, state the scope (system, group, role, or user), how it is delivered (theme, extension, portal customization, capability), and when it takes effect (new session, cache refresh, or immediate). Verify with a test account that belongs to the target group rather than the administrator account.