Side-by-Side Upgrade with Custom Authentication and SDK Extensions
A regional insurer runs Cognos Analytics 11.1.7 on three Windows servers: one gateway and two dispatchers. The content store is Oracle 19c, and the environment supports 4,200 named users, 350 concurrent users at month-end, and 180 scheduled reports. A custom Java authentication provider maps legacy employee IDs to an Active Directory namespace, and two SDK-based portal extensions are deployed. The business wants Cognos Analytics 12.0.7 live in 10 weeks for a regulatory dashboard launch. A pre-upgrade scan finds that the authentication provider was compiled against an older SDK, one extension calls an API that is not supported in v12, and the content store holds 14,000 report output versions. The infrastructure team proposes an in-place upgrade of all three servers over one weekend, reusing the existing content store and keeping the same hostnames. Security requires a tested rollback and no more than four hours of downtime.
1. Assess the proposed in-place upgrade and recommend an upgrade and rollback strategy.
Read the worked answer
The in-place proposal concentrates risk. The custom authentication provider and an SDK extension are already known to be incompatible, and the content store schema upgrade is effectively one-way: once v12 opens the content store, reverting to 11.1.7 against that same database is not a supported rollback. A weekend in-place upgrade also makes it hard to test authentication, extensions, schedules, and month-end concurrency before users arrive.
A safer approach is side-by-side deployment. Build a separate v12.0.7 environment, clone the Oracle content store to a new database, and let v12 upgrade the clone while the 11.1.7 production content store stays untouched. Recompile the authentication provider and both extensions against the v12 SDK in an isolated test environment. Validate sign-in, nested group resolution, scheduled credentials, portal behavior, and representative reports. For cutover, switch the gateway or DNS to the v12 environment and keep 11.1.7 intact but read-only. The four-hour window can then be used for cutover and smoke testing rather than a full software upgrade. For rollback, point traffic back to 11.1.7 and its original content store; any content created in v12 after cutover must be exported or recreated, so freeze content authoring during the switch or plan a small deployment archive.
2. What validation sequence should be used for the authentication provider, extensions, and scheduled credentials before cutover?
Read the worked answer
Validate from the outside in. First, install the recompiled authentication provider in an isolated v12 environment with a test Active Directory namespace. Test simple binds, nested group membership, disabled accounts, and large group resolution. Confirm that Cognos group membership maps correctly and that capability assignments behave as expected for representative users. Second, test the SDK extensions against the v12 portal: rendering, navigation, session handling, and any server-side calls. An extension that merely loads is not sufficient; exercise the workflow that depends on it.
Third, test scheduled credentials. Schedules run under the credentials of the owner or the configured run-as identity, not necessarily the recipient. Verify that schedules owned by service accounts still authenticate after the provider change, and that a schedule created by a restricted user cannot access data beyond that user's rights. Fourth, run a regression set of reports that covers each package, data source, and delivery method. Finally, perform a small pilot with real users in the v12 environment before the production cutover. Record each test result so that rollback decisions are based on evidence rather than on how quickly the installer completed.
3. How should the 14,000 report output versions and the content store be handled before and after the upgrade?
Read the worked answer
Do not delete rows directly from content store tables. The content store is a proprietary schema, and direct deletion can break references, leave orphaned objects, or void support. Treat the 14,000 versions as a content-management problem first. Inventory which outputs are business records, which are transient, and which are duplicates. Use supported report output cleanup and version-retention settings to reduce unnecessary history, and export any outputs that must be retained as evidence into a deployment archive or an approved records repository.
Before the upgrade, take a full database backup of the original content store and test a restore. Clone that backup for the v12 environment. After the v12 environment is running, configure output version limits and a cleanup schedule so the problem does not recur. If the content store is large, also review whether audit data is in the same database, because audit growth can dominate backup time. The rollback plan should include both the original content store backup and the deployment archive of any content changed after cutover.