Das „Send Popup“ Objekt von Opalis ist in Opalis 6.3 nur als ‚Legacy-‘Objekt verfügbar

Kein Wunder, Opalis 6.3  läuft jetzt auch auf Windows 2008 Servern, ganz gleich ob 32bit oder 64bit-Systeme. Auf Windows 2008 gibt es den Dienst „Messenger“ nicht mehr, den wir vielleicht früher noch kannten, weil dieser die „net send“-Nachrichten entgegen nehmen konnte. Also Pendant zu „net send“ gibt es das Kommando msg.exe, mit dem man ebenfalls Nachrichten schreiben kann.
Hierzu kann einfach eine Command-Line geöffnet und der Befehl msg.exe werden:

msg administrator /server: "Hello world!"

Dieses kleine Tool kann man sich nun in Opalis zunutze machen. Man nimmt ein „Run Program“-Objekt und greift innerhalb des Befehl-Pfades auch  auf ‚Published Data‘ oder Globale Einstellungen zurück. Alternativ kann man auch ein neues Objekt mittels QIK (Quick Integration Pack) schreiben, welches Opalis bereits mitbringt. Dazu ist es notwendig, das QIK zunächst in Opalis zu integrieren. Das Paket befindet sich unter: \Opalis 6.3\Quick Integration Kit\QIK.msi.

Zusätzlich muss noch das Integration Pack ‚Opalis Quick Integration Kit for Microsoft .NET  - meist unter: ("C:\Program Files (x86)\Opalis Software\Quick Integration Kit 3\Integration Packs\QIKNet30.oip") registriert und verteilt werden.

Nun kann man hierüber eine neue DLL erstellen und die msg.exe antriggern. Dazu muss die QIK CLI geöffnet werden (CLI = Command Line Interface).

Neuen Namen vergeben und neue DLL erstellen (Assembly File).

Nun müssen die Commands für die DLL festgelegt werden. Das erfolgt über den ADD Button. Namen vergeben und Parameter hinzufügen.

Als Parameter müssen die Optionen der msg.exe gesetzt werden. Es wird der Computername, User sowie die Message benötigt.

msg $(User) /server:$(Computer) $(Message)

Abschliessend die eigene eigene DLL erstellen.

In einer Opalis Policy kann man jetzt diese Dll mit dem „Invoke .NET“-Objekt nutzen:

Einmal starten und wir sehen das Ergebnis:

Adam Hall, Product Manager für Opalis, hat in diesem Blog weitere Details zu System Center Orchestrator veröffentlicht: http://blogs.technet.com/b/scorch/archive/2011/05/17/what-to-expect-in-the-system-center-orchestrator-beta.aspx

Bemerkenswert ist, dass:

• • • die allgenmeine Struktur gegenüber dem Vorgänger Opalis gleich bleibt und damit Ihre jetztigen Investitionen in Opalis geschützt werden.
    • System Center Orchestrator nach bisherigen Angaben ausschliesslich unter Windows 2008 R2 und SQL 2008 R2 unterstützt sein wird.
    • Der Import von Policies aus Opalis nach System Center Orchestrator unterstützt wird, der Import von System Center Orchestrator Exports aber nicht.

In der jetztigen beta Version von Microsoft System Center Orchestrator sind weder der "Legacy Mode" für Runbooks noch die "Legacy Objects" verfügbar. Die derzeitigen Aussagen von Microsoft lassen darauf schliessen, dass es auch in der RTM Version so sein wird.

Achten Sie daher jetzt schon beim Design neuer Policies (künftiger Name: "Runbooks") darauf, dass Sie keine "Legacy Objects" verwenden und dass Ihre Policies im "Pipeline Mode" laufen (können). Im "Pipeline Mode" werden ja bekanntlich mehrere Start-Objekte oder Schleifen zwischen Objekten (künftiger Name: "Activties") nicht unterstützt.

In der beta Version von Microsoft System Center Orchestrator sind derzeit noch keine Integration Packs enthalten.

Ein Registrieren, Verteilen, Konfigurieren und Benutzen der Integration Packs für System Center, die mit Opalis 6.3 ausgeliefert wurden, ist aber in dieser beta Version von Microsoft System Center Orchestrator möglich. Ebenfalls sind auch viele andere unter Windows 2008 R2 lauffähigen Integration Packs von Opalis 6.3 mit der beta Version von Microsoft System Center Orchestrator benutzbar.

Der Import von Opalis OIS_Export-Dateien ist in der beta Version von Orchestrator beta möglich. Microsoft hatte bereits angekündigt, dass es eine Möglichkeit gibt, Policies von Opalis nach Runbooks von Orchestrator zu übeführen. Es ist zu erwarten, dass es hier noch ein beschriebenes Verfahren vielleicht sogar ein Utilty für geben wird.

Schon jetzt können aber bereits Policies von Opalis per Export und Import in die beta Version Orchestrator überführt werden. Wichtig zum einen ist, dass Integration Packs der verwendeten Activities vor dem Import in Orchestrator bereits registriert sind, zum andernen dürfen für den Export keine Legacy-Objekte verwendet werden. Legacy-Mode und Legacy-Objekte sind in der aktuellen beta Version von Orchestrator nicht unterstützt!

In dem SCOrch Team-Blog listet Adam Hall die Standard Activities  der beta Version von Orchestrator auf:
http://blogs.technet.com/b/scorch/archive/2011/06/22/leveraging-the-power-of-the-orchestrator-out-of-box-standard-activities.aspx

Wenn man sich diese Standard Activities anschaut, fühlt man sich sehr stark an die Foundation Objects von Opalis erinnert. Die Abschnitte "System Activities", "Scheduling Activities", "Monitoring Activities", "File Management Activities", "Email Activities", "Notification Activities", "Utilities Activities" und "Text File Management Activities" enthalten die gleichen Activities in der derselben Aufteilung, wie wir es in den Foundation Objects von Opalis kennen.
Der Bereich „Runbook Control Activities“ lässt sich auch leicht zu dem Bereich „Workflow Control“ von Opalis zuordnen und die darin enthaltenden Objekte auch: "Initialize Data"

Der Abschnitt „Legacy Objects“ ist aber im Runbook Designer nicht mehr enthalten. Achten Sie deshalb schon jetzt beim Design Ihrer Policies darauf, dass diese keine Legacy Objects“ enthalten, wenn Sie planen, Ihre jetzigen Policies später als Runbooks in Orchestrator laufen zu lassen.

In dem System Center Orchestrator Team Blog sind die ersten beiden Integration Packs für Orchestrator 2012 angekündigt. Diese stehen bereits zum Download bereit:

• Orchestrator 2012 Integration Pack for VMware vSphere
• System Center Orchestrator 2012 Integration Pack for IBM Tivoli Netcool/OMNIbus

Wie wir heute in dem beta-Programm erfahren haben, wird zurzeit sehr viel Entwicklungsarbeit in Integration Packs von HP-Produkten gesteckt.

Ein Managementpack zur Überwachung von Orchestrator mit Operations Manager (SCOM) wird es wahrscheinlich nach der RTM von Orchestrator geben.

Sicher ist vielen die Möglichkeit bekannt, dass man mit Hilfe des "Run .Net Script" Objektes in Opalis-Workflows Powershell-Befehle einbinden kann. Eine sehr gute Möglichkeit, um Powershell-Befehle in seine Opalis-Workflows mit Variablen oder "Pulished Data" einzubinden!

Bei manchen Kunden besteht aber die Anforderung, dass

• die Powershell-Skripte auf einem anderen System als den Opalis Action Servern ausgeführt werden müssen.
• die Powershell-Skripte außerhalb von Opalis gepflegt werden sollen.

Hier liegt nahe, das "Run Program"-Objekt zu nehmen und dort das Powershell-Skript als Parameter aufzurufen, "powershell -file C:\temp\pscommand.ps1".

Leider wird das „Run Program“-Objekt dann von selbst nicht beendet.

Man muss in dem „Advanced“-Tab des „Run Program“-Objektes „Wait for the completion of the program -Terminate after n minutes“  konfigurieren.

Wenn man aber diese Behle am Endes des  Powershell-Skriptes setzt, wird das „Run Program“-Objekt erfolgreich beendet:
$objCurrentPSProcess = [System.Diagnostics.Process]::GetCurrentProcess();
Stop-Process -Id $objCurrentPSProcess.ID;

In einem früheren Blogeintrag hatten wir bereits darüber informiert, dass der sogenannte "Legacy Mode" und die sogenannten "Legacy Objekte" von dem Opalis-Nachfolger MS System Center Orchestrator 2012 nicht mehr unterstützt werden.

Wenn Ihre Opalis Policies auch später als Runbooks in Orchestrator laufen sollen, muss eventuell bei den Policies im "Legacy Mode" auch etwas am Design geändert werden.
Viele Kunden nutzen eine Schleife, um Aufträge geordnet nacheinander aus einer Textdatei auszulesen.
Eine Policy könnte also einen folgenden Aufbau haben:

Diese Policy wird in MS System Center Orchestrator 2012 nicht mehr lauffähig sein, weil eine Schleife zwischen mehreren Objekten im Pipeline Mode nicht möglich ist. Man muss die Policy umstellen.

Eine Möglichkeit ist, die (legacy) Policy in zwei Runbooks aufzuteilen.
Die Haupt Policy hat diese Struktur.

In dem "Internal Loop" bei dem "Invoke Runbook"-Objekt ("Trigger Policy") wird so lange das ausführende "Child Runbook" gestartet, bis diesse meldet, dass das Dateiende erreicht ist.

Die ausführende "Child Runbook" hat diesen Aufbau:

Zum Überführen Ihrer Opalis Policies zu Orchestrator Runbooks ist neben dem Austausch der "Legacy Objects"  auch mitunter ein Redesign von Policies nötig, wenn die Struktur  nicht vom "Pipline Mode" unterstützt wird.

Es kommt sehr selten vor, aber es kann passieren:  Eine nachfolgende Activtiy wir mehr als einmal  getriggert, obwohl die Activtiy, die vorher ausgeführt wurde, nur ein Ergebnis hat und auch ‚Flatten‘ aktiviert ist.
Grund dafür sind zwei Links zwischen  denselben Start und Ziel-Activities:

Dies kann z.B. in sehr seltenen Fällen passieren, wenn man Objekte kopiert.

Mit dieser Abfrage kann man diese identifizieren:

;WITH CTE
AS
(
SELECT DISTINCT SourceObject, TargetObject, Count(*) OVER(PARTITION BY TargetObject, SourceObject) AS CountDups
FROM LINKS INNER JOIN
                      OBJECTS ON LINKS.UniqueID = OBJECTS.UniqueID
WHERE (OBJECTS.Deleted IS NULL OR OBJECTS.Deleted = 0)
      AND (OBJECTS.Enabled = 1)
)

SELECT     FOLDERS.Name AS FolderName, POLICIES.Name AS PolicyName, OBJECTS.Name AS SourceObjectName, CTE.CountDups AS Number
FROM         CTE INNER JOIN
                      OBJECTS ON CTE.SourceObject = OBJECTS.UniqueID INNER JOIN
                      POLICIES ON OBJECTS.ParentID = POLICIES.UniqueID INNER JOIN
                      FOLDERS ON POLICIES.ParentID = FOLDERS.UniqueID
WHERE CTE.CountDups > 1 AND OBJECTS.Enabled = 1
            AND (FOLDERS.Deleted IS NULL OR FOLDERS.Deleted = 0)
            AND (POLICIES.Deleted IS NULL OR POLICIES.Deleted = 0)