當您需要重新配置現有 Cognos 環境以使用不同的外部安全源（例如 Active Directory、LDAP 等）時，您可以採用多種方法。 我喜歡稱他們為“好的、壞的和醜的”。 在我們探索這些好的、壞的和醜陋的方法之前，讓我們先看看一些常見的場景，這些場景往往會在 Cognos 環境中推動身份驗證名稱空間的變化。
常見的業務驅動因素:
更新硬件或操作系統 – BI 硬件/基礎設施的現代化可能是一個常見的驅動因素。 雖然 Cognos 的其餘部分可能會在您時尚的新硬件和現代 64 位操作系統上像冠軍一樣運行，但祝您將 2005 年左右版本的 Access Manager 遷移到該新平台上好運。 Access Manager（首次隨系列 7 發布）是許多 Cognos 客戶過去的寶貴遺產。 這是許多客戶保留 Windows Server 2003 的舊版本的唯一原因。Access Manager 的文章已經被擱置了很長時間。 它是遺留軟件。 越早擺脫它越好。
應用標準化– 希望將所有應用程序的身份驗證整合到一個集中管理的公司目錄服務器（例如 LDAP、AD）的組織。
併購– 公司 A 購買了公司 B 並需要公司 B 的 Cognos 環境指向公司 A 的目錄服務器，而不會對他們現有的 BI 內容或配置造成問題。
企業剝離– 這與合併方案相反，公司的一部分被分拆為自己的實體，現在需要將其現有的 BI 環境指向新的安全源。
為什麼命名空間遷移會很混亂
將 Cognos 環境指向新的安全源並不像添加具有相同用戶、組和角色的新命名空間、斷開舊命名空間的連接那麼簡單，瞧！-新命名空間中的所有 Cognos 用戶都與他們的內容。 事實上，你的手上經常會弄得一團糟，這就是為什麼......
所有 Cognos 安全主體（用戶、組、角色）都由稱為 CAMID 的唯一標識符引用。 即使所有其他屬性都相同，一個用戶的 CAMID 現有 身份驗證命名空間將與該用戶的 CAMID 不同 新 命名空間。 這可能會對現有的 Cognos 環境造成嚴重破壞。 即使您只有幾個 Cognos 用戶，您也需要意識到 CAMID 引用存在於內容存儲中的許多不同位置（甚至可以存在於內容存儲之外的框架模型、轉換器模型、TM1 應用程序、多維數據集、規劃應用程序等） ）。
許多 Cognos 客戶錯誤地認為 CAMID 僅對我的文件夾內容、用戶首選項等重要。這與事實大相徑庭。 這不僅僅是您擁有的用戶數量的問題，而是您需要關注的 Cognos 對象的數量。 僅 Content Store 中就有 140 多種不同類型的 Cognos 對象，其中許多可能有多個 CAMID 引用.
例如：
- Content Store 中的單個計劃具有多個 CAMID 引用（計劃所有者的 CAMID、計劃運行的用戶的 CAMID、每個用戶的 CAMID 或分發列表應將生成的報告輸出通過電子郵件發送到， 等等。）。
- Cognos 中的每個對像都有一個安全策略來管理哪些用戶可以訪問該對象（想想“權限選項卡”）。 掛在 Cognos Connection 中該文件夾的單個安全策略具有該策略中指定的每個用戶、組和角色的 CAMID 參考。
- 希望你明白這一點——這個列表還在繼續！
一個相當大的 Content Store 包含數万個 CAMID 引用的情況並不少見（我們已經看到一些包含數十萬個的大型引用）。
現在，計算一下里面有什麼 Cognos 環境，您可以看到您可能正在處理成群的 CAMID 引用。 這可能是一場噩夢！ 切換（或重新配置）您的身份驗證命名空間會使所有這些 CAMID 引用處於無法解析的狀態。 這不可避免地導致 Cognos 內容和配置問題（例如不再運行的計劃、不再像您認為的那樣保護內容、不再正確實現數據級別安全性的包或多維數據集、丟失我的文件夾內容和用戶偏好等）。
Cognos 命名空間轉換方法
現在，知道 Cognos 環境可能有數以萬計的 CAMID 引用，這些引用需要在新的身份驗證名稱空間中查找、映射和更新到相應的新 CAMID 值，讓我們討論解決這個問題的好、壞和醜方法。
善: 用 Persona 替換命名空間
第一種方法（命名空間替換）利用 Motio的 人格智商 產品。 採用這種方法，您現有的名稱空間將被一個特殊的 Persona 名稱空間“替換”，該名稱空間允許您虛擬化向 Cognos 公開的所有安全主體。 預先存在的安全主體將使用與以前完全相同的 CAMID 向 Cognos 公開，即使它們可能由任意數量的外部安全源（例如 Active Directory、LDAP 甚至 Persona 數據庫）提供支持。
這種方法的美妙之處在於它需要對 Cognos 內容進行零更改。 這是因為 Persona 可以維護預先存在的委託人的 CAMID，即使它們有新來源的支持。 那麼……您的內容存儲、外部模型和歷史立方體中的所有這些數以萬計的 CAMID 引用？ 他們可以保持原樣。 無需工作。
這是迄今為止風險最低、影響最小的方法，可用於將現有 Cognos 環境從一個外部安全源轉換到另一個。 它可以在一小時內完成，Cognos 停機時間大約為 5 分鐘（Cognos 唯一停機時間是在您配置 Persona 名稱空間後重新啟動 Cognos）。
壞: 使用 Persona 進行命名空間遷移
如果簡單、低風險的方法不適合您，那麼 is 另外一個選項。
Persona 還可用於執行命名空間遷移。
這涉及在您的 Cognos 環境中安裝第二個身份驗證名稱空間，將（希望）所有現有安全主體（從舊名稱空間）映射到新名稱空間中的相應主體，然後（這是有趣的部分），查找、映射和更新每個Cognos 環境中存在的單個 CAMID 引用：您的內容存儲、框架模型、轉換器模型、歷史多維數據集、TM1 應用程序、規劃應用程序等。
這種方法往往會帶來壓力和流程密集型，但如果您是那種需要腎上腺素飆升才能感覺活力的 Cognos 管理員（並且不介意深夜/清晨的電話），那麼也許…… Free Introduction 是您正在尋找的選項嗎？
Persona 可用於幫助自動化此過程的某些部分。 它將幫助您創建舊安全主體和新安全主體之間的映射，自動執行內容存儲中內容的蠻力“查找、分析、更新”邏輯等。什麼 Persona 可以自動執行這裡的一些任務，很多這種方法的工作涉及“人員和過程”而不是實際技術。
例如，編譯有關每個 Framework Manager 模型、每個 Transformer 模型、每個 Planning / TM1 應用程序、每個 SDK 應用程序、誰擁有它們的信息，以及規劃它們將如何更新和重新分發可能需要大量工作。 協調您希望嘗試遷移的每個 Cognos 環境的中斷以及您可以嘗試遷移的維護時段可能涉及規劃和 Cognos“停機時間”。 在遷移之後提出（並執行）一個有效的測試計劃也可能是一個負擔。
您希望首先在非生產環境中執行此過程也很正常 之前 在生產中嘗試它。
雖然使用 Persona 進行命名空間遷移確實有效（並且它比下面的“醜陋”方法要好得多），但與命名空間替換相比，它更具侵入性、風險更大、涉及更多的人員並且需要更多的工時來執行。 通常遷移需要在“下班時間”完成，而 Cognos 環境仍然在線，但最終用戶對錶單的使用受到限制。
醜陋的: 手動命名空間遷移服務
醜陋的方法涉及一種不令人羨慕的方法，試圖 手動 從一個身份驗證名稱空間遷移到另一個身份驗證名稱空間。 這涉及將第二個身份驗證名稱空間連接到您的 Cognos 環境，然後嘗試手動移動或重新創建大部分現有 Cognos 內容和配置。
例如，使用這種方法，Cognos 管理員可能會嘗試：
- 在新命名空間中重新創建組和角色
- 在新命名空間中重新創建這些組和角色的成員資格
- 手動將我的文件夾內容、用戶首選項、門戶選項卡等從每個源帳戶複製到每個目標帳戶
- 查找內容存儲中的每個策略集，並將其更新為引用新命名空間中的等效主體，其方式與引用舊命名空間中的主體完全相同
- 重新創建所有計劃並使用相應的憑據、收件人等填充它們。
- 重置 Content Store 中所有對象的所有“所有者”和“聯繫人”屬性
- [Content Store 中大約有 40 件您會忘記的東西]
- 收集所有具有對像或數據級別安全性的 FM 模型：
- 相應地更新每個模型
- 重新發布每個模型
- 將修改後的模型重新分發給原作者
- 針對原始命名空間保護的 Transformer 模型、TM1 應用程序和規劃應用程序的類似工作
- [還有很多]
雖然一些 Cognos 受虐狂可能會為在 Cognos Connection 中點擊 400,000 次的想法暗自竊喜，但對於大多數明智的人來說，這種方法往往極其乏味、耗時且容易出錯。 然而，這並不是這種方法的最大問題。
這種方法的最大問題是它幾乎 時刻 導致遷移不完全。
使用這種方法，您（痛苦地）查找並嘗試映射您知道的那些 CAMID 引用……但往往會留下您所知道的所有 CAMID 引用 不知道.
一旦你 認為 你已經完成了這種方法，你通常沒有 真 完成。
您的內容存儲庫中的對像不再像您認為的那樣受到保護……您的計劃沒有按照過去的方式運行，您的數據不再像您想像的那樣受到保護確實如此，而且您甚至可能會在某些操作中遇到無法解釋的錯誤 你真的不能把你的手指放在上面.
糟糕和醜陋的方法可能可怕的原因：
- 自動命名空間遷移給內容管理器帶來了很大壓力。 內容存儲中每個對象的檢查和潛在更新通常會導致對 Cognos 的數以萬計的 SDK 調用（幾乎所有這些調用都通過內容管理器）。 這種異常查詢通常會導致內存使用/負載激增，並使內容管理器在遷移過程中面臨崩潰的風險。 如果您的 Cognos 環境中已經存在任何不穩定性，您應該非常害怕這種方法。
- 命名空間遷移需要相當大的維護窗口。 Cognos 需要啟動，但您不希望人們在遷移過程中進行更改。 這通常需要在沒有其他人工作時開始命名空間遷移，假設在周五晚上 10 點。 沒有人願意在周五晚上 10 點開始一項壓力大的項目。 更不用說，在一個項目中，你的智力可能不會在最佳的工作之夜和周末 不 要求你敏銳！
- 我已經提到命名空間遷移是時間和勞動密集型的。 這裡有更多的內容：
- 內容映射過程應該精確完成，這需要團隊協作和大量工時。
- 需要多次試運行來檢查遷移的錯誤或問題。 典型的遷移在第一次嘗試時並不完美。 您還需要一個有效的 Content Store 備份，以便在這種情況下可以恢復。 我們已經看到許多組織沒有可用的良好備份（或者他們沒有意識到備份是不完整的）。
- 你需要確定一切 校外 可能受到影響的內容存儲（框架模型、轉換器模型等）。 此任務可能涉及多個團隊之間的協調（尤其是在大型共享 BI 環境中）。
- 您需要一個好的測試計劃，其中涉及對您的 Cognos 內容具有不同程度訪問權限的代表性人員。 此處的關鍵是在遷移完成後不久驗證一切是否已完全遷移並按預期運行。 驗證所有內容通常是不切實際的，因此您最終會驗證您希望的具有代表性的樣本。
- 你必須有 broad Cognos 環境和依賴它的事物的知識。 例如，如果您採用 NSM 路線，則必須重建具有自定義視圖的歷史立方體。
- 如果您或您將命名空間遷移外包的公司忘記了某些東西，例如……SDK 應用程序，該怎麼辦？ 一旦你打開了開關，如果它們沒有正確更新，這些東西就會停止工作。 您是否進行了適當的檢查以立即註意到這一點，還是在症狀開始出現之前幾週/幾個月？
- 如果您經歷了多次 Cognos 升級，則您的 Content Store 中可能會有處於不一致狀態的對象。 如果您不使用 SDK，您將無法看到哪些對象處於此狀態。
為什麼命名空間替換是最佳選擇
使用 Persona Namespace Replacement 方法時，我剛剛概述的關鍵風險因素和耗時步驟將被消除。 使用命名空間替換方法，您有 5 分鐘的 Cognos 停機時間，並且您的任何內容都不必更改。 “好”的方法對我來說似乎是一種干脆的“不費腦子”。 週五晚上是為了放鬆，而不是因為您的內容管理器剛剛在命名空間遷移過程中崩潰而感到壓力。
