https://github.com/HaikoHertes/slides/tree/master/sqlDays2022

Viel Spaß damit! Die Videos werden noch ein paar Tage Zeit brauchen…

#sqlDays #Azure #Konferenz

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

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.

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:

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:

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!