Drücke "Enter", um den Text zu überspringen.

Schlagwort: SQL

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

Veröffentlicht 10. Juni 2015

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”).

(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”:

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.

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

Schreibe einen Kommentar...

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

Veröffentlicht 16. Dezember 2013

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:

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):

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

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

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:

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

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

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:

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

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

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.

Schreibe einen Kommentar...

SCCM2012: Durch SEDO dauerhaft gesperrte Tasksequenzen entsperren

Veröffentlicht 31. Mai 2013

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

Select * FROM SEDO_LockState WHERE LockStateID != 0

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

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

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!

2 Comments