SQL Express – Sicherung mit der Powershell

11.11.2016 Anleitung für die Aufgabenplanung ergänzt

15.12.2017 Link zum Skript geändert

Die SQL Express Edition erfreut sich gerade für kleine Anwendungen großer Beliebtheit da sie keine Lizenzkosten verursacht. Diese Beliebtheit dürfte sogar noch steigen seit dem Microsoft mit dem Service Pack 1 für den SQL Server 2016 viele Funktionen der Standard und sogar Enterprise Edition nun auch in der Express Edition verfügbar macht.

Nun stehen hier auch viele der InMemory Features und Sicherheitsfunktionen wie AlwaysEncrypted auch in der Express Edition bereit. Weiterlesen

Advertisements

Powershell Befehle über Aufgabenplaner ausführen

Wie die meisten Administratoren stehe auch ich immer wieder mal vor der Aufgabe Powershell Befehle zeitgesteuert auf seinen Systemen ausführen zu lassen.

Für umfangreiche Aufgaben schreibt einfach ein Powershell Skript und erstellt einen neuen Task in der Aufgabenplanung. Dieser Task startet die Powershell und übergibt als Argument einfach die Skriptdatei.

Sobald die Aufgabenplanung den Task startet wird damit das Skript ausgeführt. Soweit so gut.

Was macht man aber wenn man nur einen einzigen Befehl ausführen möchte?

Für jeden Befehl eine neue Skriptdatei anlegen wird auf Dauer sehr unübersichtlich und man könnte auch schnell durcheinander kommen wenn die Tasks in der Aufgabenplanung nicht zu den Namen der Skriptdateien passen.

Will man tatsächlich nur einen Powershell Befehl direkt ausführen lassen, so kann man diesen auch direkt als Argument angeben.

Beispiel: Täglicher Neustart

Aufgabenplanung 1

Aufgabenplanung 2

AlwaysOn Verfügbarkeitsgruppen – geplanter Failover

Nützlich ist diese Möglichkeit wenn man zum Beispiel Nachts einen geplanten Failover einer AlwaysOn Verfügbarkeitsgruppe durchführen möchte. Hier muss man als Argument einfach den folgenden Befehle übergeben.

Switch-SqlAvailabilityGroup -Path SQLSERVER:\SQL\[SERVER]\[INSTANZ]\AvailabilityGroups\[AGNAME]

Powershell Befehl zum anlegen eines neuen Tasks

$action = New-ScheduledTaskAction -Execute 'Powershell.exe' -Argument '"restart-computer -force"'
$trigger = New-ScheduledTaskTrigger -Daily -At 0am
Register-ScheduledTask -Action $action -Trigger $trigger -TaskName "Neustart" -Description "Neustart um Mitternacht" -User system -RunLevel Highest

SQL Server – Verbindungsfehler 4064

Möchte man sich mit einem SQL Server über das SQL Server Management Studio verbinden, wird automatisch auch eine Verbindung mit der Standarddatendank des Benutzers hergestellt.

Dies ist auch erstmal nicht problematisch solange die Standarddatenbank auch verfügbar ist. Zum Problem kann es aber werden wenn für einen Benutzer eine Datenbank angegeben ist welche, entweder nicht mehr vorhanden oder Offline geschaltet ist.

02 DB Offline

Will sich ein Benutzer nun mit dem  SQL Server Management Studio (SSMS) auf einen SQL Server verbinden wenn die Standarddatenbank Offline ist, wird die Anmeldung fehlschlagen.

03 Verbindungfehler

 

Der Versuch sich mit einer nicht verfügbaren Standarddatenbank zu verbinden wird mit dem Fehler 4064 quittiert und der Anmeldeversuch scheitert.

Da man sich nicht mit dem Server verbinden kann, kann man auch nicht die Standarddatenbank ändern um sich wieder anmelden zu können.

Schnelle Lösung

Zum Glück kann man in den Optionen der Anmeldung im SSMS eine andere Standarddatenbank definieren um dieses Problem zu umgehen. Die Einstellung gilt zwar nur für die aktuelle Verbindung aber damit ist es möglich, das Problem mit der Datenbank zu lösen oder seine Standarddatenbank zu ändern.

04 Standard DB ändern

Die Verbindungseigenschaften findet man über den Button Optionen auf dem Login Bild des SSMS. Dort trägt man von Hand eine andere Datenbank, wie die Master Datenbank, ein und kann sich anmelden.

 

Standarddatenbank ändern

Standardmäßig ist als Standarddatenbank die Master DB eingestellt. Diese Einstellung sollte auch nur aus gutem Grund geändert werden.

01 Neuer Nutzer

Man findet die Einstellungen zur Standarddatenbank in den Eigenschaften des Logins auf Serverebene.

Im Reiter „Allgemein“ findet man ganz unten den Eintrag Standarddatenbank. Diese Einstellung kann über das Dropdown Menü auf eine andere Datenbank ändert werden. Durch ein Klick auf OK wird die Einstellung ab der nächsten Anmeldung des Nutzers angewendet.

 

MSSQL Server – Das Copy-Only Backup

Wer sich mit dem Thema Backup im Microsoft SQL Server beschäftigt ist mit ziemlicher Sicherheit schon über das Copy-Only Backup (zu Deutsch: Kopie Sicherung) gestoßen. Was dieser Backup Type bedeutet und wo man ihn einsetzten kann/sollte gehen die Meinungen auseinander. Aus diesem Grund möchte ich den technischen Hintergrund und die Unterschiede zwischen „Normalen“ Backups und den Copy-Only Backups vorstellen und anschließend zeigen wann man diese sinnvoll einsetzen kann. Weiterlesen

Testumgebungen sinnvoll aufsetzen

Die Testumgebung

Wer IT-Umgebungen sicher (Hier sowohl als safety & security zu verstehen) betreiben will, kommt an einer Testumgebung nicht vorbei. Eine Testumgebung ist sowohl für neue Produkte wie auch bei Änderungen an bestehenden Systemen von enormer Bedeutung. Letztendlich habe ich nur so einen Chance alle Auswirkungen meiner Änderungen zu entdecken bevor ich sie am produktiven Systemen umsetzten muss.

Notwendige Bedingung

Damit ich aber Rückschlüsse von meiner Testumgebung auf mein produktives System ziehen kann, muss eine Bedingung zwingend erfüllt sein.

Das Testsystem muss dem Produktivsystem so Identisch wie möglich sein.

Diese Voraussetzung ist so gut wie nie zu 100% erfüllbar, aber dennoch sollte man Abweichungen so gering wie möglich halten.

Die Realität

Leider findet man in wirklichen Leben und auch in der Schulung oft einen anderen Zustand. Hier wird vereinfacht wo es nur geht da man mit dem Produktivsystem ja schon genug zu tun hat.

Typische Vereinfachungen sind:

  • lokale Firewalls deaktiviert
  • alle Nutzer haben Domänen Admin Rechte
  • Dienste laufen mit Domänen Admin Rechten
  • Alle benutzen sowieso den selben Account der auch noch Domänen Admin ist
  • Alle Server befinden sich im gleichen Netzsegment
  • Freigaben und NTFS Rechte lauten „Jeder“ hat „Vollzugriff“

Dem Tester freut dieses Vorgehen da er/sie nie auf natürliche Hindernisse stößt und somit fröhlich testen kann.

Die Ergebnisse eines solchen Tests haben aber keine Aussagekraft für das Produktivsystem. Der arme Admin der nun den Auftrag hat die Änderung im Produktivsystem einzurichten wird nun mit Problemen überschüttet, von denen im Vorfeld nie die Rede waren.

Typische Fehlersituationen

  • Dienste können nicht auf den Fileserver zugreifen weil sie dort keine Lese/Schreibrechte haben oder den Fileserver wegen einer Firewall gar nicht erst erreichen.
  • Nutzer können Anwendungen nicht starten wegen fehlender Rechte
  • Dienste und Nutzer können nicht auf die Datenbank zugreifen weil sie dort kein Login haben

Die Liste ließe sich noch beliebig fortsetzen.

Fazit

Auch wenn es viel Arbeit macht, sollte man gerade bei einer Testumgebung auch so arbeiten wie es das (spätere) Live-System auch tut. Nur so kann ich sehen ob irgendwelche Berechtigungen fehlen oder mir eine Firewall den  Weg versperrt.

Mache ich dies nicht, dann werde ich bei dem Live-System auf einmal viele Probleme haben welche im Test-System nie aufgetreten sein. Hier muss ich dann schnell irgendwelche Lösungen finden welche mir später das Leben unnötig schwer machen können.

Backup und Restore Tests

Oder: Vertrauen ist gut, Kontrolle ist besser!

Welcher Windows Administrator kenn diese Situation nicht? Man ist zwar eigentlich kein Datenbankadministrator (DBA) aber zur der Anwendung gehört halt ein SQL Server und einen echten DBA gibt es halt nicht. Also muss man sehen, dass die Datenbank läuft. Genau so wichtig wie ein laufender Server ist gerade bei Datenbanken, dass man die Daten im Notfall auch wiederherstellen kann. Dabei muss man immer wieder feststellen, dass das Backup noch recht gut überwacht und kontrolliert wird aber die Wiederherstellung so gut wie nie getestet ist.

Es gilt der Spruch:

Was interessiert mich das erfolgreiche Backup, der erfolgreiche Restore ist mir viel wichtiger!

Weiterlesen

SQL Server Express – Public vs. Sicherheit

In den letzten Jahren hat Microsoft immer mehr Features der kostenpflichtigen SQL Server Editionen in die kostenlose Express Edition aufgenommen. Somit können Entwickler immer mehr Anwendungen  mit der SQL Express Edition bereitstellen. Leider gibt es seit langer Zeit einen Unterschied zwischen der Express Edition und der Standard/Enterprise welche nicht so offensichtlich ist und Auswirkungen auf die Sicherheit haben kann.

Wie ist es in den anderen Edition?

Will man sich mit einer SQL Server Instanz der Standard, Developer oder Enterprise Edition verbinden, benötigt man zunächst einen Login für die Instanz. Dieser Login kann entweder über einen Windows Account oder eine Windows Gruppe erfolgen welcher im SQL Server berechtigt wird oder man erzeugt einen SQL Server Login (falls der gemischte Modus aktiv ist). Generell gilt: Nur wer einen gültigen Login besitzt darf sich am Server anmelden und ist damit Mitglied der Serverrolle „Public“ Weiterlesen

SSMS – Über TCP Port Nr. verbinden

Wenn man sich über das SSMS (SQL Server Management Studio) mit einer bestimmten Instanz verbinden will, kann man dies standardmäßig über die Kombination Server\Instanznamen tun. Bei benannten Instanzen wird hier im Hintergrund ein dynamischer Port für die benannte Instanz geöffnet und der Dienst SQL Browser führt die Zuordnung zwischen Instanznamen und dynmischen TCP Port durch.

Oder falls man nicht den SQL Browser nutzen will/kann, kann man auch Servernamen,TCP Port angeben. Voraussetzung hierfür ist, dass man im Vorfeld einen festen Port in der Netzwerkkonfiguration definiert hat.

Der Vorteil bei statischen TCP Ports auch für nicht Standardinstanzen liegt in der einfacheren Verwaltung von Netzfirewall Regeln. Netzfirewalls tun sich schwer mit Regeln auf dynamischen Ports.

SSMS-TCP

Durch die Angabe des TCP Ports kann man auch direkt testen ob die Zuweisung des statischen Ports in der Netzwerkkonfiguration des SQL Servers funktioniert hat.

 

Anlegen von Warnungen per Powershell

Wie auch sonst in der IT ist auch ein Datenbankserver nicht frei von Fehlern oder Problemen. Um schnell auf Fehler reagieren zu können ist es notwendig zeitnah über Probleme informiert zu werden. Innerhalb des SQL Server übernimmt der SQL Server Agent (nicht in der Express Edition vorhanden) diese Aufgabe.

Vorbereitungen

Damit der SQL Server Agent Benachrichtigungen versenden kann ist es erforderlich das Datenbank-Mail eingerichtet ist. Weitere Informationen zu Einrichtung von Datenbank Mail findet man im Technet unter https://technet.microsoft.com/de-de/library/ms175887(v=sql.105).aspx Weiterlesen

https://www.faq-o-matic.net/

Heute ist mein Blog Beitrag zum Thema Sicherheit im Active Directory auf dem gemeinsamen Blog unter https://www.faq-o-matic.net/ erschienen.

Warum dort?

Ganz einfach. Ich möchte hier nur über Themen berichten welche auch direkt den SQL Server betreffen. Da ich aber noch in anderen Bereichen aktive bin, habe ich mich dazu entschieden diese anderen Themen unter https://www.faq-o-matic.net/ zu veröffentlichen.

SQL Server Dienstkonten

Oder wie viel Rechte dürfen es sein?

Bei der Installation eines neuen SQL Servers wird man unter anderem nach den Account-Informationen der Dienstkonten gefragt. Leider geht die Frage in dem umfangreichen Installationsprozess etwas unter.  Hinter der Frage verbirgt sich aber ein sehr wichtiges Thema, über welches man sich unbedingt im Vorfeld Gedanken machen sollte.

Wie viele Berechtigungen gebe ich meinem SQL Server?

Oder anders gefragt:

Welche Berechtigungen benötigt der SQL Server eigentlich um seine Aufgaben korrekt und sicher zu erledigen? Weiterlesen