IBM Cognos v12 Admin cheat sheet

IBM Cognos Analytics 12.x runs on a Java servlet container; supported stacks include IBM WebSphere Liberty (bundled default) and Apache Tomcat - confirm the exact supported version matrix for the release before planning.

Installation is driven by an interactive or silent response file; the silent installer consumes a generated options file, which is what makes repeatable multi-node builds possible.

A distributed install separates the Application Tier (servlet container + Cognos binaries) from the Content Store database and the optional external components (gateway web server, OpenID Connect provider, SMTP).

Upgrade path requires the source release to be within the supported upgrade matrix; direct jumps across multiple major versions are not supported - intermediate upgrade or export/import is required.

Deployment export/import packages content (folders, reports, schedules, data source definitions, security references) as a deployment archive; it is not a substitute for a content store database migration.

Pre-upgrade checklist items: back up the content store, export security namespace configuration, record customized configuration parameters, inventory custom Java extensions and JDBC drivers.

Same-version coexistence and side-by-side installs allow parallel validation; the new instance must use a distinct content store schema and distinct ports.

License and component selection (e.g., whether dynamic query or legacy query mode components are installed) is decided at install time and affects later behavior, so plan it before running the installer.

Disk and memory sizing must account for the content store, the temp directory used by report processing, and the audit database if auditing is enabled.

Tier model: Web Gateway (reverse proxy / web server) → Application Tier (dispatcher + report/query/batch services) → Data Tier (content store database, data source databases, optional audit store).

The dispatcher is the entry point for requests inside the application tier; it registers services, routes requests, and maintains the service registry shared through the content store.

Service types include Report Service, Batch Report Service, Query Service (dynamic query), Presentation Service, Job Service, Content Manager, and the dispatcher itself; each runs in a JVM process group.

A server group / dispatcher routing model lets multiple application-tier nodes share work; the content store is the coordination point, so all nodes must reach the same schema.

Horizontal scaling = adding application-tier nodes behind the gateway; vertical scaling = increasing JVM heap and CPU on existing nodes. Content Manager is the typical write-contention bottleneck.

The gateway is the only component that must be exposed to end users; application-tier ports should be firewalled from clients in a hardened topology.

Report data service and dynamic query mode require the Java-based query engine plus appropriate JDBC drivers; legacy query mode uses the compatible query engine against the same sources.

High availability requires removing single points of failure at every tier: multiple gateways behind a load balancer, multiple application nodes, and a resilient content store database.

Authentication namespaces (LDAP, Active Directory, custom Java providers, OpenID Connect, Cognos-native) are configured per namespace; a user identity is namespace-qualified, so the same short name in two namespaces is two distinct users.

Cognos groups and roles are stored in the content store and layered on top of namespace groups; membership can be nested, and effective capability is the union of direct and inherited grants.

Authorization is capability-based: entries in the secured function/feature tree (e.g., report authoring, scheduling, administration) are granted to users, groups, or roles with allow/deny. Deny overrides allow at the same level.

Object-level security on folders, packages, and reports is set through the object's permissions; traversal permission on the parent folder is required to reach a secured child.

Data-level security is achieved through framework/model filters and session parameters, not through report-level permissions alone - report permissions control who runs it, model filters control what rows they see.

Roles such as System Administrator, Directory Administrator, and Report Administrator are predefined groups; assigning a user to System Administrators grants full administrative capability.

Single sign-on options include gateway-based trusted authentication (e.g., header injection), Kerberos/SPNEGO, SAML, and OpenID Connect; the chosen method must be consistent end-to-end through the gateway.

Anonymous access requires an explicit anonymous user entry and deliberate capability grants; it is disabled by default and should be audited before enabling.

The content store is a relational database (e.g., Db2, Oracle, SQL Server, PostgreSQL) holding report specifications, folder structure, security objects, schedules, and the service registry - it holds metadata, not report result data.

Content store schema is created and upgraded by the Content Manager during startup or by a supplied script; the schema version must match the installed release.

Configuration is layered: bootstrap files (e.g., the startup configuration file on each node) define how a process starts, while most runtime parameters are administered centrally and persisted in the content store.

Parameters changed in the administration interface are read by services per their documented read behavior; some require a service restart, others take effect on next request.

Content Manager is the sole writer to the content store; direct SQL modification of content store tables is unsupported and can corrupt referential integrity.

Content maintenance includes orphaned-object cleanup, deployment archive import/export, and content store backup/restore procedures; schedule backups consistently with the database's own tooling.

Configuration of multiple application-tier nodes must be kept consistent; drift between nodes causes intermittent routing and authentication failures.

Memory tuning is per-JVM: set the heap on the application server process group, not globally; the Report/Batch/Query services and Content Manager each have their own process and heap profile.

Report caching stores rendered output keyed by report, parameters, user identity, and data; a change to any of these misses the cache. Cache scope and expiry are configurable.

Query result caching and the dynamic query engine's metadata cache reduce database round trips; metadata cache refresh is needed after model or schema changes, otherwise stale metadata persists.

Database-side tuning (indexes, statistics, connection pooling) usually dominates end-to-end report time; the connection pool size per data source must be sized against database connection limits.

Monitoring sources: built-in audit logging (to a database), application server logs, JVM garbage collection logs, and database performance views. Auditing must be enabled and its database provisioned.

Scheduling concentration is a common performance fault: many jobs firing at the same minute saturate the batch report service. Stagger start times and cap concurrent batch processes.

Long-running or runaway reports should be identified via audit reports and terminated; set query timeouts at the data source and report level to bound resource consumption.

Baseline before tuning: capture response time, concurrent user count, and database time for a representative report set, then change one variable at a time.

The portal/home experience is configurable per user or group: default entry page, visible tabs (e.g., team content, recent, search), and available authoring tools are governed by capabilities.

Themes, branding, and extension customization are deployed as web content artifacts; they are version-specific and must be revalidated after each upgrade.

Capabilities control which UI features appear (e.g., dashboard authoring, data module creation, story authoring); hiding a feature is done by denying its capability, not by editing the UI.

Content organization uses folders, team content, and My content; personal content is per-user and is not a substitute for governed team content.

Default preferences (locale, time zone, number format, output format) can be set at the system level and overridden per user; locale affects report rendering and date formatting.

The administration console exposes system-wide settings: security, data source connections, distribution, and logging; access to it is itself a capability.

Mobile and portal appearance settings should be validated against the supported browser matrix; unsupported browsers degrade the authoring experience even when viewing works.

A schedule is attached to a report, job, or other object; a job is a container that can sequence multiple steps (reports, other jobs) with shared schedule and settings.

Trigger types include time-based (once, daily, weekly, monthly, cron-style), and event-based triggers; a schedule's time zone is explicit and can differ from the server's default.

Delivery options: save to the content store (output versions), email with attachment or link, print, and save to a shared file system location. Each requires its corresponding service to be configured (e.g., SMTP settings for email).

Output version retention controls how many saved outputs are kept per report; unlimited retention is a common cause of content store growth.

A job step can be configured to run only if the prior step succeeded, or to continue regardless; this governs failure propagation across a multi-step job.

Schedule ownership and credentials matter: the schedule runs with the owner's credentials and data access, so a departed owner's schedules can fail or expose data. Reassign ownership during offboarding.

Missed schedules are handled per the schedule's setting (run at next opportunity vs. skip); the behavior affects catch-up load after an outage.

Distribution lists and burst reports split a single scheduled report into per-recipient or per-group outputs; burst keys must map to values present in the data.

A data source connection object is created in the administration console and referenced by packages and reports; credentials can be stored in the content store, prompted, or passed through from the signon.

Signon objects separate the connection definition from credentials; multiple signons per data source allow different credential sets for different consumers.

Dynamic query mode requires a supported JDBC driver deployed to the application tier and a supported database version; unsupported driver/DB combinations fall back or fail.

Connection pool settings (min/max connections, timeout) are per data source; the sum across all data sources must stay under the database's connection limit.

Framework Manager models publish packages to the content store; the package binds to a data source at publish time, and republishing is required after model changes.

Data source access can be restricted by capability and by object permissions on the connection; users need traverse/execute on the connection to use dependent reports.

Test the connection from the administration console after any driver, network, or credential change; a stored-password change requires updating the signon, not just the connection.

For cloud/warehouse sources, verify network egress, TLS certificates, and any required driver properties before assuming a model defect.

Logging is configured per component (dispatcher, Content Manager, report service, query service) with levels such as ERROR, WARN, INFO, DEBUG; raising to DEBUG globally degrades performance, so scope it to the failing component.

Log destinations include files on each node and a database appender; in a multi-node topology, correlate by timestamp and node name across logs.

The audit database records user activity, report execution, and errors; audit reports themselves are the first stop for 'who ran what and when' questions.

Common failure signatures: dispatcher cannot reach content store (schema/credentials/network), service fails to register (port conflict, stale registry entry), report fails with data source error (driver/credential/query).

IBM support data collection includes log files, configuration exports, version/build information, and, when requested, the content store schema version - gather before opening a case.

Reproduce with the smallest possible artifact (single report, single user, single data source) and capture the exact timestamp to isolate the log window.

Stale service registry entries after an unclean shutdown can leave phantom services; verify registered services in the administration console before assuming a code defect.

Certificate, SSO, and gateway errors typically surface as authentication loops or 401/403 at the gateway; check gateway logs before application logs for these symptoms.