Haikos Blog Blog von Haiko Hertes zu allen Themen rund um Microsoft und Datacenter

10Jun/150

SCDPM meldet “Der Schutz kann nicht konfiguriert werden” wenn SQL Server gesichert werden soll

Bei der Version 2012 R2 des System Center Data Protection Managers gibt es ein Problem mit der Sicherung von SQL Servern der Version 2012. Es wird nach Erstellen der Schutzgruppe bzw. beim Versuch der Erstellung eines Replikates die Meldung “Der Schutz kann nicht konfiguriert werden” ausgegeben (Im Englischen: “Unable to configure protection”).

scdpm_sql_00

(Leider hab ich vom Fehler selbst in der Produktiv-Umgebung keinen Screenshot gemacht und ich wollte ihn nicht nochmal nachträglich provozieren – daher ein Shot aus einer englischen Umgebung)

Dieses Problem ist scheinbar bei Microsoft bekannt und auch im TechNet dokumentiert:

https://technet.microsoft.com/de-de/library/dn281948.aspx

Die Lösung ist auch recht einfach, da der Grund ebenso einfach ist: Der Schutz-Agent hat keine SA-Rechte auf der Datenbank, also müssen diese noch vergeben werden!

Dazu startet man auf dem zu sichernden Zielserver einfach das “SQL Server Management Studio”:

scdpm_sql_01

Dort kann man dann in dem Bereich “Sicherheit”, unter “Anmeldungen” das Konto von “NT-AUTORITÄT\SYSTEM” mit einem Rechtklick und der Auswahl von “Eigenschaften” öffnen. Hier muss dann die Rolle “sysadmin” zusätzlich mit ausgewählt werden.

scdpm_sql_03

Danach sollte sich die Sicherung via DPM auch problemlos einrichten und durchführen lassen:

scdpm_sql_04

16Dez/130

SCOM: Probleme beim Setup von SCOM 2012 R2 – hier: Reporting Server

Die Installation von SCOM (System Center Operations Manager) 2012 R2 ist eigentlich nicht sehr schwer – jedoch gibt es einige potentielle “Stolpersteine”, wenn man die Reporting-Komponente nutzen möchte. Selbst bei installiertem SSRS (SQL Server Reporting Service) können diverse Fehler auftreten, die ich hier mit samt ihrer Lösung vorstellen möchte.

Zunächst einmal kann folgende Fehlermeldung auftauchen, die verschiedene Gründe haben könnte:

scom2012ssrs1

Mögliche Fehler:

  • SSRS sind nicht installiert (trivial)
  • Reporting Services Webdienst-URL ist nicht konfiguriert (Durchaus denkbar, direkt nach dem Setup)
  • Keine SSRS-Datenbank angelegt (kann nach dem Setup auch gut möglich sein)
  • Keine Berichts-Manager-URL konfiguriert (vor allem wenn noch keine Webdienst-URL gesetzt wurde normal)

Ob einer der Fehler vorliegt lässt sich recht einfach mit Hilfe des “Konfigurations-Manager für Reporting Services” prüfen:

Hier ist beispielsweise keine Webdienst-URL gesetzt (zweiter Fall):

scom2012ssrs2

Das Ganze sollte so aussehen (wenn dies erst gerade geschehen ist, sollte die rot markierte Meldung zu sehen sein):

scom2012ssrs3

Dritter Fall: Keine Datenbank. Das sieht dann so aus:

scom2012ssrs4

Durch einen Klick auf “Datenbank ändern” kann man mit Hilfe von “Neue Berichtsserver-Datenbank erstellen” und der Standardwerte eine neue DB samt TempDB anlegen. Das sollte am Ende so aussehen:

scom2012ssrs6

Vierter Fall: Berichts-Manager-URL ist noch nicht konfiguriert; sieht so aus:

scom2012ssrs7

Durch “Anwenden” lässt sich dies korrigieren und sieht danach so aus:

scom2012ssrs8

Zurück im Setup das SCOM2012R2 kann man nun erneut sein Glück versuchen, jedoch könnte nun folgender Fehler auftauchen, dessen Meldung man nur sieht, wenn man mit dem Mauszeiger über das rote Kreuz fährt:

scom2012ssrs9

Die Meldung ist zum Glück sehr aussagekräftig, so dass ein Blick in services.msc (Dienste) recht schnell Klarheit bringt:

scom2012ssrs10

Der SQL Agent Dienst sollte auf Autostart stehen und muss zum Zeitpunkt der Installation laufen, also so:

scom2012ssrs11

Das sind nun also die häufigsten Fehler und ihre eigentlich recht einfache Lösung; ich hoffe, das Ganze ist für die Problemlösung hilfreich.

31Mai/132

SCCM2012: Durch SEDO dauerhaft gesperrte Tasksequenzen entsperren

SEDO (Serialized Editing of Distributed Objects) soll im SCCM2012-Umfeld möglich machen, dass mehrere Admins gleichzeitig arbeiten, ohne sich gegenseitig in die Quere zu kommen. Wenn unter SCCM2007 ein Admin eine Tasksequenz bearbeitet hat, die noch bei einem anderen Admin zur Bearbeitung geöffnet war, dann "gewann" derjenige, der zuletzt gespeichert hat, was mitunter sehr ärgerlich war.

Unter SCCM 2012 werden nun Tasksequenzen, die zum Bearbeiten geöffnet sind, gesperrt. Diese an sich sehr nützlich Funktion kann aber auch zu einem Problem werden. Die Sperre sollte nach 30 Minuten "Inaktivität" automatisch aufgehoben werden. Da dies aber ein Vorgang ist, den die SCCM-Konsole durchführt, kann es passieren, das eine gesperrte Tasksequenz dauerhaft gesperrt bleibt, wenn z.B. die Konsole abgestürzt ist.

Für die Sperrung ist die SQL-Tabelle SEDO_LockState zuständig.

Gesperrte Tasksequenzen kann man z.B. mit folgendem SQL-Statement abfragen:

1
SELECT * FROM SEDO_LockState WHERE LockStateID != 0

TS_Screen2

Das eine Tasksequenz gesperrt ist, wird auch beim Versuch, diese zu bearbeiten angezeigt:

TS_Error

Um nun eine Entsperrung zu erzwingen, ist folgendes SQL-Statement geeignet:

1
2
3
4
5
6
7
8
9
UPDATE [CM_LPZ].[dbo].[SEDO_LockState]
SET [LockStateID] = 0
,[AssignedUser] = NULL
,[AssignedObjectLockContext] = NULL
,[AssignedMachine] = NULL
,[AssignmentTime] = NULL
 
WHERE [LockStateID] = '1'
GO

(das "LPZ" in "CM_LPZ" ist durch den Sitecode zu ersetzen)

Aber Achtung: Microsoft unterstützt das manuelle Ändern der SQL-Datenbank nicht - ihr solltet also genau wissen, was ihr da tut!

TS_Lösung