Wenn Sie eine vorhandene Cognos-Umgebung neu konfigurieren müssen, um eine andere externe Sicherheitsquelle (z. B. Active Directory, LDAP usw.) zu verwenden, können Sie verschiedene Vorgehensweisen anwenden. Ich nenne sie gerne „Das Gute, das Schlechte und das Hässliche“. Bevor wir uns mit diesen guten, schlechten und hässlichen Ansätzen befassen, werfen wir einen Blick auf einige gängige Szenarien, die tendenziell Änderungen des Authentifizierungs-Namespace in einer Cognos-Umgebung bewirken.
Gemeinsame Geschäftstreiber:
Aktualisieren von Hardware oder Betriebssystem – Die Modernisierung der BI-Hardware/-Infrastruktur kann ein häufiger Treiber sein. Während der Rest von Cognos auf Ihrer schlanken neuen Hardware und Ihrem modernen 64-Bit-Betriebssystem wie ein Champion laufen mag, viel Glück bei der Migration Ihrer circa-2005-Version von Access Manager auf diese neue Plattform. Access Manager (erstmals mit der Serie 7 veröffentlicht) ist für viele Cognos-Kunden ein ehrwürdiges Überbleibsel aus vergangenen Tagen. Dies ist der einzige Grund, warum viele Kunden an dieser beschissenen alten Version von Windows Server 2003 herumhängen. Die Schrift für Access Manager ist seit geraumer Zeit an der Wand. Es handelt sich um Legacy-Software. Je früher Sie davon abgehen können, desto besser.
Anwendungsstandardisierung– Organisationen, die die Authentifizierung aller ihrer Anwendungen gegen einen zentral verwalteten Unternehmensverzeichnisserver (zB LDAP, AD) konsolidieren möchten.
Fusionen & Übernahmen– Unternehmen A kauft Unternehmen B und benötigt die Cognos-Umgebung von Unternehmen B, um auf den Verzeichnisserver von Unternehmen A zu verweisen, ohne Probleme mit dem vorhandenen BI-Inhalt oder der Konfiguration zu verursachen.
Unternehmensveräußerungen– Dies ist das Gegenteil des Fusionsszenarios, ein Teil eines Unternehmens wird in eine eigene Einheit ausgegliedert und muss nun seine vorhandene BI-Umgebung auf die neue Sicherheitsquelle verweisen.
Warum Namespace-Migrationen chaotisch sein können
Das Verweisen einer Cognos-Umgebung auf eine neue Sicherheitsquelle ist nicht so einfach wie das Hinzufügen des neuen Namespace mit denselben Benutzern, Gruppen und Rollen, das Trennen des alten Namespace und VOILA! – alle Ihre Cognos-Benutzer im neuen Namespace werden mit deren Inhalt. Tatsächlich können Sie oft mit einem blutigen Durcheinander an Ihren Händen enden, und hier ist der Grund …
Auf alle Cognos-Sicherheitsprinzipale (Benutzer, Gruppen, Rollen) wird durch eine eindeutige Kennung namens CAMID verwiesen. Auch wenn alle anderen Attribute gleich sind, ist die CAMID für einen Benutzer in einem vorhandenen Authentifizierungs-Namespace wird nicht mit der CAMID für diesen Benutzer im neu Namensraum. Dies kann in einer vorhandenen Cognos-Umgebung verheerende Folgen haben. Selbst wenn Sie nur wenige Cognos-Benutzer haben, müssen Sie sich bewusst sein, dass CAMID-Referenzen an VIELEN verschiedenen Stellen in Ihrem Content Store vorhanden sind (und sogar außerhalb Ihres Content Stores in Framework-Modellen, Transformer-Modellen, TM1-Anwendungen, Cubes, Planungsanwendungen usw ).
Viele Cognos-Kunden glauben fälschlicherweise, dass CAMIDs wirklich nur für den Inhalt von My Folder, Benutzereinstellungen usw. wichtig sind. Dies könnte nicht weiter von der Wahrheit entfernt sein. Es kommt nicht nur auf die Anzahl der Benutzer an, sondern auch auf die Menge der Cognos-Objekte, mit denen Sie sich beschäftigen müssen. Allein im Content Store gibt es über 140 verschiedene Typen von Cognos-Objekten, von denen viele möglicherweise mehrere CAMID-Referenzen haben.
Beispielsweise:
- Es ist nicht ungewöhnlich, dass ein einzelner Zeitplan in Ihrem Content Store mehrere CAMID-Referenzen hat (die CAMID des Zeitplanbesitzers, die CAMID des Benutzers, unter dem der Zeitplan ausgeführt werden soll, die CAMID jedes Benutzers oder jeder Verteilerliste, an die die generierte Berichtsausgabe per E-Mail gesendet werden soll , etc.).
- Jedes Objekt in Cognos verfügt über eine Sicherheitsrichtlinie, die regelt, welche Benutzer auf das Objekt zugreifen können (denken Sie an die Registerkarte „Berechtigungen“). Eine einzelne Sicherheitsrichtlinie, die an diesem Ordner in Cognos Connection hängt, hat eine CAMID-Referenz für jeden Benutzer, jede Gruppe und jede Rolle, die in dieser Richtlinie angegeben sind.
- Hoffentlich verstehen Sie den Punkt – diese Liste geht weiter und weiter!
Es ist nicht ungewöhnlich, dass ein umfangreicher Content Store Zehntausende von CAMID-Referenzen enthält (und wir haben einige große mit Hunderttausenden gesehen).
Rechne jetzt nach, was drin ist Ihre Cognos-Umgebung und Sie können sehen, dass Sie möglicherweise mit Horden von CAMID-Referenzen zu tun haben. Es kann ein Albtraum sein! Das Wechseln (oder Neukonfigurieren) Ihres Authentifizierungs-Namespace kann all diese CAMID-Referenzen in einem unauflösbaren Zustand belassen. Dies führt unweigerlich zu Inhalts- und Konfigurationsproblemen von Cognos (z. B. nicht mehr ausgeführte Zeitpläne, nicht mehr so gesicherte Inhalte, wie Sie es sich vorstellen, Pakete oder Cubes, die die Sicherheit auf Datenebene nicht mehr korrekt implementieren, Verlust von My Folder-Inhalten und -Benutzer Vorlieben usw.).
Cognos-Namespace-Übergangsmethoden
Da wir nun wissen, dass eine Cognos-Umgebung Zehntausende von CAMID-Referenzen haben kann, die im neuen Authentifizierungs-Namespace gefunden, zugeordnet und auf den entsprechenden neuen CAMID-Wert aktualisiert werden müssen, lassen Sie uns die guten, schlechten und hässlichen Ansätze zur Lösung dieses Problems diskutieren.
Das gute: Namespace-Ersetzung durch Persona
Die erste Methode (Namespace Replacement) verwendet Motio's, Persona-IQ Produkt. Bei diesem Ansatz wird Ihr vorhandener Namespace durch einen speziellen Persona-Namespace „ersetzt“, mit dem Sie alle Sicherheitsprinzipale virtualisieren können, die Cognos ausgesetzt sind. Vorhandene Sicherheitsprinzipale werden Cognos mit genau derselben CAMID wie zuvor ausgesetzt, auch wenn sie von einer beliebigen Anzahl externer Sicherheitsquellen (zB Active Directory, LDAP oder sogar die Persona-Datenbank) unterstützt werden.
Das Schöne an diesem Ansatz ist, dass er NULL Änderungen an Ihren Cognos-Inhalten erfordert. Dies liegt daran, dass Persona die CAMIDs bereits vorhandener Principals beibehalten kann, selbst wenn sie von einer neuen Quelle unterstützt werden. Also… all die Zehntausenden von CAMID-Referenzen in Ihrem Content Store, externen Modellen und historischen Cubes? Sie können so bleiben, wie sie sind. Es ist keine Arbeit erforderlich.
Dies ist bei weitem der risikoärmste Ansatz mit den geringsten Auswirkungen, den Sie für die Umstellung Ihrer bestehenden Cognos-Umgebung von einer externen Sicherheitsquelle auf eine andere verwenden können. Dies kann in weniger als einer Stunde mit etwa 5 Minuten Ausfallzeit von Cognos durchgeführt werden (die einzige Ausfallzeit von Cognos besteht darin, Cognos neu zu starten, nachdem Sie den Persona-Namespace konfiguriert haben).
Das Schlechte: Namespace-Migration mit Persona
Wenn der einfache, risikoarme Ansatz einfach nicht Ihr Ding ist, dann gibt es hier is andere Option.
Persona kann auch verwendet werden, um eine Namespace-Migration durchzuführen.
Dies beinhaltet die Installation eines zweiten Authentifizierungs-Namespace in Ihrer Cognos-Umgebung, die Zuordnung (hoffentlich) aller Ihrer vorhandenen Sicherheitsprinzipale (aus dem alten Namespace) zu den entsprechenden Principals im neuen Namespace, dann (hier ist der lustige Teil), das Suchen, Zuordnen und Aktualisieren jedes einzelne CAMID-Referenz, die in Ihrer Cognos-Umgebung vorhanden ist: Ihr Content Store, Framework-Modelle, Transformer-Modelle, historische Cubes, TM1-Anwendungen, Planungsanwendungen usw.
Dieser Ansatz ist in der Regel stressig und prozessintensiv, aber wenn Sie die Art von Cognos-Administrator sind, die einen kleinen Adrenalinschub braucht, um sich lebendig zu fühlen (und Telefonanrufe am späten Abend / am frühen Morgen nicht stört), dann vielleicht… fehlen uns die Worte. ist die gesuchte Option?
Persona kann verwendet werden, um Teile dieses Prozesses zu automatisieren. Es wird Ihnen dabei helfen, eine Zuordnung zwischen den alten Sicherheitsprinzipalen und den neuen Sicherheitsprinzipalen zu erstellen, die Brute-Force-Logik "Suchen, Analysieren, Aktualisieren" für Inhalte in Ihrem Content Store zu automatisieren usw. Was Persona hier einige der Aufgaben automatisieren kann, viel der Arbeit bei diesem Ansatz umfasst eher „Menschen und Prozesse“ als die tatsächliche Technologie.
Zum Beispiel – das Zusammenstellen von Informationen zu jedem Framework Manager-Modell, jedem Transformer-Modell, jeder Planning-/TM1-Anwendung, jeder SDK-Anwendung, deren Eigentümer sie sind, und die Planung ihrer Aktualisierung und Neuverteilung kann eine Menge Arbeit sein. Das Koordinieren von Ausfällen für jede der Cognos-Umgebungen, in denen Sie dies versuchen möchten, und Wartungsfenster, in denen Sie die Migration versuchen können, können Planungs- und Cognos-Ausfallzeiten erfordern. Einen effektiven Testplan für die Zeit nach der Migration zu entwickeln (und auszuführen) kann ebenfalls ziemlich lästig sein.
Es ist auch ganz normal, dass Sie diesen Vorgang zuerst in einer Nicht-Produktionsumgebung durchführen möchten Bevor in der Produktion ausprobieren.
Während die Namespace-Migration mit Persona funktioniert (und weitaus besser ist als der „hässliche“ Ansatz unten), ist sie invasiver, riskanter, erfordert viel mehr Personal und erfordert viel mehr Arbeitsstunden als der Namespace-Ersatz. Normalerweise müssen Migrationen außerhalb der Geschäftszeiten durchgeführt werden, während die Cognos-Umgebung noch online ist, die Formularnutzung durch Endbenutzer jedoch eingeschränkt ist.
Das hässliche: Manuelle Namespace-Migrationsdienste
Die Ugly-Methode beinhaltet den wenig beneidenswerten Ansatz, zu versuchen, manuell von einem Authentifizierungs-Namespace in einen anderen migrieren. Dazu müssen Sie einen zweiten Authentifizierungs-Namespace mit Ihrer Cognos-Umgebung verbinden und dann versuchen, einen Großteil des vorhandenen Cognos-Inhalts und der vorhandenen Konfiguration manuell zu verschieben oder neu zu erstellen.
Mit diesem Ansatz könnte ein Cognos-Administrator beispielsweise versuchen:
- Erstellen Sie die Gruppen und Rollen im neuen Namespace neu
- Erstellen Sie die Mitgliedschaften dieser Gruppen und Rollen im neuen Namespace neu
- Kopieren Sie manuell den Inhalt meiner Ordner, Benutzereinstellungen, Portal-Registerkarten usw. von jedem Quellkonto in jedes Zielkonto
- Suchen Sie jeden Richtliniensatz im Content Store und aktualisieren Sie ihn so, dass er auf äquivalente Prinzipale im neuen Namespace genauso verweist, wie er auf Prinzipale aus dem alten Namespace verwiesen hat
- Erstellen Sie alle Zeitpläne neu und füllen Sie sie mit den entsprechenden Anmeldeinformationen, Empfängern usw.
- Setzen Sie alle „Eigentümer“- und „Kontakt“-Eigenschaften aller Objekte im Content Store zurück
- [Ungefähr 40 andere Dinge im Content Store, die Sie vergessen werden]
- Sammeln Sie alle FM-Modelle mit Sicherheit auf Objekt- oder Datenebene:
- Aktualisieren Sie jedes Modell entsprechend
- Jedes Modell neu veröffentlichen
- Verteilen Sie das modifizierte Modell zurück an den ursprünglichen Autor
- Ähnliche Arbeiten für Transformer-Modelle, TM1-Anwendungen und Planungsanwendungen, die gegen den ursprünglichen Namensraum gesichert sind
- [und viele mehr]
Während einige Cognos-Masochisten bei der Idee, 400,000 Mal in Cognos Connection zu klicken, insgeheim kichern mögen, ist dieser Ansatz für die meisten vernünftigen Leute in der Regel äußerst mühsam, zeitaufwendig und fehleranfällig. Das ist jedoch nicht das größte Problem bei diesem Ansatz.
Das größte Problem bei diesem Ansatz ist, dass es fast immer führt zu einer unvollständigen Migration.
Mit diesem Ansatz finden Sie (schmerzhaft) die CAMID-Referenzen, die Sie kennen, und versuchen, diese abzubilden weiß nicht über.
Sobald Sie think Du bist mit diesem Ansatz fertig, oft nicht wirklich Fertig.
Sie haben Objekte in Ihrem Content Store, die nicht mehr so gesichert sind, wie Sie denken … Sie haben Zeitpläne, die nicht mehr so laufen, wie sie früher ausgeführt wurden, Sie haben Daten, die nicht mehr so gesichert sind, wie Sie denken es ist, und Sie können sogar unerklärliche Fehler für bestimmte Operationen haben, die du kannst nicht wirklich den finger drauf legen.
Gründe, warum die schlechten und hässlichen Ansätze schrecklich sein können:
- Automatisierte Namespace-Migrationen belasten den Content Manager stark. Die Überprüfung und potenzielle Aktualisierung jedes einzelnen Objekts in Ihrem Content Store kann oft zu Zehntausenden von SDK-Aufrufen an Cognos führen (die praktisch alle über den Content Manager fließen). Diese anormale Abfrage führt in der Regel zu einem Anstieg der Speicherauslastung/-auslastung und birgt die Gefahr eines Absturzes des Content Managers während der Migration. Wenn Ihre Cognos-Umgebung bereits instabil ist, sollten Sie sich vor diesem Ansatz sehr fürchten.
- Namespace-Migrationen erfordern ein beträchtliches Wartungsfenster. Cognos muss aktiv sein, aber Sie möchten nicht, dass während des Migrationsprozesses Änderungen vorgenommen werden. Dies erfordert in der Regel, dass die Namespace-Migration beginnt, wenn sonst niemand arbeitet, beispielsweise um 10:10 Uhr an einem Freitagabend. Niemand möchte an einem Freitagabend um XNUMX Uhr ein stressiges Projekt starten. Ganz zu schweigen davon, dass Ihre geistigen Fähigkeiten wahrscheinlich nicht optimal sind, wenn Sie nachts und am Wochenende an einem Projekt arbeiten, das die verlangen, dass Sie scharf sind!
- Ich habe erwähnt, dass Namespace-Migrationen zeit- und arbeitsintensiv sind. Hier ein bisschen mehr dazu:
- Der Content-Mapping-Prozess sollte mit Präzision durchgeführt werden und das erfordert die Zusammenarbeit im Team und viele Arbeitsstunden.
- Zur Überprüfung auf Fehler oder Probleme bei einer Migration sind mehrere Probeläufe erforderlich. Eine typische Migration verläuft nicht auf Anhieb perfekt. Sie benötigen außerdem eine gültige Sicherung Ihres Content Stores, die in solchen Fällen wiederhergestellt werden kann. Wir haben viele Organisationen gesehen, die kein gutes Backup haben (oder ein Backup haben, von dem sie nicht wissen, dass es unvollständig ist).
- Du musst alles identifizieren aussen der Content Store, der potenziell betroffen sein könnte (Framework-Modelle, Transformer-Modelle usw.). Diese Aufgabe kann die Koordination über mehrere Teams hinweg beinhalten (insbesondere in großen gemeinsam genutzten BI-Umgebungen).
- Sie benötigen einen guten Testplan, der repräsentative Personen mit unterschiedlichem Zugriff auf Ihre Cognos-Inhalte einbezieht. Der Schlüssel hier besteht darin, kurz nach Abschluss der Migration zu überprüfen, ob alles vollständig migriert ist und wie erwartet funktioniert. Es ist normalerweise unpraktisch, alles zu überprüfen, sodass Sie am Ende überprüfen, was Sie hoffen, repräsentative Proben zu sein.
- Du musst b habenroad Kenntnisse über die Cognos-Umgebung und die davon abhängigen Dinge. Historische Cubes mit benutzerdefinierten Ansichten MÜSSEN beispielsweise neu erstellt werden, wenn Sie die NSM-Route wählen.
- Was ist, wenn Sie oder das Unternehmen, in das Sie die Namespace-Migration ausgelagert haben, etwas vergessen, z. B. SDK-Anwendungen? Sobald Sie den Schalter umgelegt haben, funktionieren diese Dinge nicht mehr, wenn sie nicht ordnungsgemäß aktualisiert werden. Verfügen Sie über geeignete Kontrollen, um dies sofort zu bemerken, oder wird es mehrere Wochen / Monate dauern, bis die Symptome auftreten?
- Wenn Sie zahlreiche Cognos-Upgrades durchlaufen haben, können sich möglicherweise Objekte in Ihrem Content Store in einem inkonsistenten Zustand befinden. Wenn Sie nicht mit dem SDK arbeiten, können Sie nicht sehen, welche Objekte sich in diesem Zustand befinden.
Warum Namespace-Ersetzung die beste Option ist
Die wichtigsten Risikofaktoren und zeitaufwendigen Schritte, die ich gerade beschrieben habe, werden eliminiert, wenn die Methode zum Ersetzen von Persona-Namespaces verwendet wird. Wenn Sie den Ansatz zum Ersetzen von Namespaces verwenden, haben Sie 5 Minuten Ausfallzeit von Cognos, und Ihre Inhalte müssen nicht geändert werden. Die „Gute“ Methode erscheint mir wie ein trockenes „Kinderspiel“. Freitagabende sind zum Entspannen da, ohne sich über die Tatsache zu stressen, dass Ihr Content Manager gerade mitten in einer Namespace-Migration abgestürzt ist.
