Azure und insbesondere Azure SQL ist klasse – es nimmt einem viele Dinge der täglichen Verwaltung ab, einiges davon sogar automatisch. Klar, das hat seinen Preis, immerhin ist Azure SQL nicht ganz billig, aber wenn man es schon bezahlt, dann kann man auch seine Fähigkeiten nutzen. Eine davon ist, automatisch anhand der Nutzung einer Datenbank Empfehlungen für die Leistungsoptimierung zu geben. Diese kann man sich im UI bzw. dem Azure Portal anschauen. Dazu öffnet man entweder links im Blade den Punkt „Recommondations“ unterhalb von „Intelligent Performance“ oder den Punkt „Performance“ auf der Main-Page bei den Notifications:
Dort sieht man dann einige Empfehlungen aufgeführt (vorausgesetzt, Azure hat etwas gefunden, was wiederum eine regelmäßige Nutzung der Datenbank voraussetzt):
Diese Daten kann man sich auch automatisch abrufen und auf Wunsch dann z.B. an die Entwickler verteilen. Dazu bediene ich mich einfach der PowerShell:
Dieses Script wiederum kann man dann z.B. per Jenkins regelmäßig auslösen. Oder alternativ ein Azure Automation Runbook dafür anlegen… Viel Spaß beim Ausprobieren!
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.
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:
Insbesondere in kleinen und mittleren Unternehmen läuft der Windows Server Update Service (WSUS) nicht auf einem vollwertigen SQL-Server, sondern auf einer Windows Internal Database, welche bereits Bestandteil des Windows Server 2008 (R2) ist, und somit direkt bei der Installation von WSUS mitinstalliert werden kann.
Das Problem: Wenn es um Arbeitsspeicher geht, verhält sich die WID wie ein „großer“ SQL-Server – sie nimmt was sie bekommen kann.
Dieses Verhalten lässt sich beim regulären SQL-Server u.a. mit dem SQL Server Management Studio beeinflussen. Dieses Programm ist allerdings nicht Bestandteil der WID-Installation.
Auf einem Test-Server für eine System Center Configuration Manager 2012 Umgebung lief auch der dazu notwendige SQL-Server. Da die Hardware einen Defekt aufwies, musste ich das System auf eine neue Hardware umziehen. Problematisch: Alte und neue Hardware waren derart verschieden, dass hier Probleme zu erwarten gewesen wären, wenn ich die Platten einfach nur umgesteckt hätte. Also habe ich vorher einen Sysprep inkl. /generalize laufen lassen. Nach dem Umbau der Festplatten in den neuen Server startete dieser Anstandslos. Das Problem: Die SQL-Server-Dienste starteten nicht!
Problem:
Durch den SYSPREP sind die privaten Schlüssel für die SSL-Kommunikation verloren gegangen, da der alte User-Account ja danach nicht mehr vorhanden war. Dies war u.a. im Logfile „C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Log\ERRORLOG“ nachzulesen:
"The server could not load the certificate it needs to initiate an SSL connection. It returned the following error: 0x8009030d [...]"
Lösung:
Im „SQL Server Configuration Manager“ die Zuordnung zum alten Zertifikat löschen:
Nach einem Reboot des Servers generiert dieser ein neues Zertifikat und trägt dieses hier entsprechend ein (Es existieren dann 2 Zertifikate mit gleichem Namen, man kann sie aber u.a. am Ausstellungsdatum unterscheiden).
Dieses neue Zertifikat muss nun noch zu den „Vertrauenswürdigen Stammzertifizierungsstellen“ hinzugefügt werden bzw. evtl. den Clients als vertrauenswürdig bekanntgegeben werden. Danach sollte alles wieder funktionieren, im Logfile steht dann:
"A self-generaterd certificate was successfully loaded for encryption. [...]"