Als ich heute den Runbook Designer startete, erhielt ich folgende Fehlermeldung:
Das konnte ich mir nicht erklären, da ich sicher war, die Lizenz korrekt eingegeben zu haben. Also gut, dann eben nochmal: Key eingegeben und schon die nächste Fehlermeldung: “Cannot complete this action at this time. Please make sure you can access the SQL server” – und Orchestrator lief weiter im Eval-Modus.
Eine Anfrage bei den Kollegen vom SQL Support brachte Klarheit: Die Orchestrator Datenbank läuft in einer SQL Server 2012 AlwaysOn Availability Group, was mit dem Service Pack 1 auch offiziell von Microsoft unterstützt ist. In der Nacht ist der SQL Knoten gestorben, auf dem die Orchestrator Datenbank ursprünglich erzeugt wurde. Nun muss man wissen, dass System Center 2012 Orchestrator Daten in der Datenbank verschlüsselt. Dafür verwendet Orchestrator sowohl den Database Key, der während der Installation erzeugt wird. als auch den Service Master Key des SQL Servers. Dieser wird automatisch erzeugt, sobald er das erste Mal benötigt wird. Schwenkt nun die Datenbank von einem SQL Knoten auf einen anderen, kann Orchestrator nicht mehr auf die Lizenzinformation zugreifen, die verschlüsselt in der Tabelle PRODUCTINFO gespeichert wird, weil auf dem Zielknoten der Service Master Key ein anderer ist (jedenfalls, wenn der SQL Admin nicht daran gedacht hat… – naja, SQL AlwaysOn ist ja noch ziemlich neu). Das Ergebnis ist oben genannte Lizenzwarnung.
Gottseidank ist das Problem relativ einfach in den Griff zu bekommen. Der Service Master Key des SQL Servers, auf dem die Orchestrator Datenbank erzeugt wurde, muss auf alle SQL Server übertragen werden, die an der AlwaysOn Availability Group beteiligt sind. Das macht man folgendermaßen (VORSICHT: Erst bis zu Ende lesen, dann ausführen):
Zuerst brauchen wir ein Backup des Service Master Keys des ersten SQL Servers:
BACKUP SERVICE MASTER KEY TO FILE = 'c:\temp\ServiceMasterKey'
ENCRYPTION BY PASSWORD = 'MyPx55w0Rd'
Die Datei wird auf die Zielknoten übertragen und dort als neuer Service Master Key eingespielt:
RESTORE SERVICE MASTER KEY FROM FILE = 'c:\temp\ServiceMasterKey'
DECRYPTION BY PASSWORD = 'MyPx55w0Rd'
Jetzt zum “VORSICHT”-Teil: Voraussichtlich wird beim Versuch, den Service Master Key neu zu setzen, eine Fehlermeldung kommen, die darauf hinweist, dass es da eine Orchestrator Datenbank gibt, die auf diesen Schlüssel angewiesen ist. Die korrekte Vorgehensweise wäre nun, die Datenbank aus der Availability Group herauszunehmen, die nicht mehr synchronisierte Kopie auf den Zielknoten zu löschen, dann den Key einzuspielen und dann die Datenbank wieder in die Availability Group aufzunehmen. Das kann man sich sparen, indem man das Restore-Kommando mit der zusätzlichen Option FORCE aufruft (ganz am Ende hinter dem Passwort). Dabei sollte man aber ganz sicher sein, dass der Befehl auf den richtigen SQL Knoten und Instanzen ausgeführt wird, und dass es keine anderen Datenbanken auf dem jeweiligen Knoten gibt, die SQL Verschlüsselung nutzen und evtl. auf den alten Wert des Service Master Keys angewiesen sind.
Vielleicht vorher erst mal prüfen, ob das Recovery eines SQL Servers sauber funktioniert 
Übrigens ergibt sich aus dieser Erkenntnis natürlich auch die Frage, wie die Orchestrator Datenbank auf einen anderen SQL Server verschoben werden kann. Sobald ich das mal ausprobiert habe, werde ich meine Erkenntnisse hier veröffentlichen.
Viele Grüße,
Friedrich