WSUS Datenbank umziehen

Wer einen Windows Server Update Services (WSUS) Server installiert, könnte aus Bequemlichkeit bei der Installation wählen, dass die interne Windows-Datenbank (WID) für den WSUS genutzt werden soll. Das hat meiner Erfahrung nach verschiedene Nachteile:

  • Der benötigte Speicherplatz für die WID könnte irgendwann recht groß werden. Standardmäßig ist diese unter C:\Windows\WID gespeichert.
  • Die WID ist leistungsmäßig unterirdisch und macht in verschiedenen Szenarien immer wieder Probleme (bspw. wenn die WID schon etwas größer geworden ist)

Deshalb sollte man sich, wenn man einen WSUS installieren möchte, zunächst einen SQL Server installieren. Standalone oder – in den meisten Fällen sinnvoller und auch ausreichend – SQL Express auf dem gleichen Server.

Ist das Kind schon in den Brunnen gefallen (wie bei meinem Szenario, wo eine mehr als 10 GB große WID für Probleme sorgte), lässt sich das aber zum Glück relativ einfach nachträglich ausbessern. Ich habe mich dabei an dem How-To von Microsoft orientiert, das allerdings etwas verwirrend ist: https://technet.microsoft.com/de-de/library/dd939918(v=ws.10).aspx

Zunächst installiert man einen SQL Express Server bzw. legt eine neue Instanz an. Ich nenne sie WSUS. Der Server hat „MGMT-SRV“ als Hostname, so dass die Instanz nun unter „MGMT-SRV\WSUS“ erreichbar ist. Beim Erstellen der Instanz habe ich Windows-Authentifizierung gewählt und dem Konto „NT-Autorität\Netzwerkdienst“ den Zugriff gestattet.

Weiterhin ist es nötig, das Microsoft SQL Server Management Studio zu installieren, um den Umzug zumindest komfortabler zu gestalten (grundsätzlich sollte das alles auch über die Kommandozeile gehen).

Im nächsten Schritt habe ich die Dienste „IIS-Verwaltungsdienst“ sowie „WSUS-Dienst“ beendet.

Danach habe ich in der klassischen Eingabeaufforderung folgende Befehle eingegeben:

sqlcmd -S np:\\.\pipe\MICROSOFT##WID\sql\query
use master
alter database SUSDB set single_user with rollback immediate
go
sp_detach_db SUSDB
go

Achtung: bei Server 2008 R2 und älter ist die interne Datenbank MSSQL$MICROSOFT##SSEE (statt MICROSOFT##WID).

Wenn man jetzt möchte, kann man die Datenbank an einen anderen Speicherplatz verschieben. Ich habe die Dateien SUSDB.mdf und SUSDB_log.ldf auf ein anderes Laufwerk verschoben, auf dem sich auch die übrigen WSUS-Daten befinden. Die Dateien befinden sich unter Windows Server 2012 (R2) im Verzeichnis C:\Windows\WID\Data.

Mit dem SQL Management Studio habe ich nun die neue Instanz MGMT-SRV\WSUS geöffnet und einen Rechtsklick auf „Datenbanken“ gemacht. Dort habe ich mit dem Punkt „Anfügen“ die Datenbankdatei SUSDB.mdf hinzugefügt.

Anschließend sollte man nochmal prüfen, ob alle Berechtigungen stimmen:

  1. Unter Sicherheit\Anmeldungen sollte das Konto „NT-Autorität\Netzwerkdienst“ aufgeführt werden.
  2. Unter Datenbanken Rechtsklick auf SUSDB und Eigenschaften wählen. Unter Berechtigungen sollte ein Eintrag für „NT-Autorität\Netzwerkdienst“ vorhanden sein.
  3. Unter Datenbanken\SUSDB\Sicherheit\Rollen\Datenbankrollen Rechtsklick auf webService und Eigenschaften wählen. Dort sollte bei „Mitgliedern dieser Rolle“ auch „NT-Autorität\Netzwerkdienst“ eingetragen sein.

Nun habe ich regedit.exe gestartet und im Schlüssel HKLM\SOFTWARE\Microsoft\UpdateServices\Server\Setup den Eintrag SqlServerName auf MGMT-SRV\WSUS geändert. Also: [Servername]\[Instanzname]

Danach habe ich die Dienste „IIS-Verwaltungsdienst“ und „WSUS-Dienst“ wieder gestartet und zur Sicherheit auch noch den WWW-Publishingdienst sowie den Dienst „Interne Windows-Datenbank“ neugestartet.

Zuletzt habe ich mit dem Start der WSUS Verwaltung erfolgreich geprüft, ob wieder alles läuft.

Windows 10 Roaming Profile V5

Es gibt eine unschöne Erfahrung in Bezug auf Windows 10 zu teilen, die insbesondere für Admins von Windows-Netzwerken interessant sein dürfte. Und zwar habe ich festgestellt, dass es ein Problem mit servergespeicherten Profilen bei Windows 10 gibt: Statt nur den Roaming-Ordner auf dem Server zu speichern, wird der gesamte Profilordner kopiert.

Weiterlesen

[Tech-Tipp] Windows Server 2012 Firewall und Linux Server LDAP-Abfrage

Ausgangssituation: In unserer Serverumgebung haben wir als Domain-Controller Windows Server 2012 im Einsatz. Einige Dienste (bspw. Confluence, Jira, Fisheye) laufen auf Linux-Servern und rufen die User-Credentials per LDAP-Anbindung von den Domain-Controllern ab. In den Log-Dateien der Linux-basierten Dienste haben wir regelmäßig Timeouts bzw. fehlgeschlagene LDAP-Verbindungen gefunden. Außerdem war es häufiger nötig, die Linux-Dienste neu zu starten, damit eine Benutzeranmeldung (wieder) möglich war.

Lösung: nach einiger Recherche bin ich darauf gestoßen, dass die Firewall der Windows Server seit Windows Server 2008 einen so genannten Stealth-Mode besitzt. Soweit ich das verstanden habe, werden dadurch Verbindungen von Clients zum Server kurz verzögert oder bei zu vielen Anfragen (automatisierte Anfragen) abgelehnt. Dieser Stealth-Mode kann nur über eine Änderung an der Registry ausgeschaltet werden. Weitere Infos: http://technet.microsoft.com/en-us/library/dd448557%28WS.10%29)

HKLM\SOFTWARE\Policies\Microsoft\WindowsFirewall\DomainProfile

Hier einen neuen DWORD-Eintrag mit dem Namen „DisableStealthMode“ (Groß- und Kleinschreibung beachten) und dem Wert „1“ anlegen. Nach einem Neustart des Servers ist der Stealth-Mode für das Domänen-Profil der Firewall deaktiviert. Unter Umständen kann es notwendig sein, dass auch in den anderen Firewall-Profilen (falls angelegt und in Benutzung) dieser Eintrag gemacht werden muss.

Fazit: Seit der beschriebenen Änderung an den Domain-Controllern kommt es zu keinen Fehlermeldungen mehr und keiner der Linux-Server bzw. Linux-Dienste musste seitdem neugestartet werden.

Tech-Tipp: DHCP Failover unter Windows Server 2012

Wenn man von einem Windows Server 2008 die DHCP-Einstellungen auf einen neuen Windows Server 2012 migriert hat, kann es vorkommen, dass ein DHCP Failover nicht konfiguriert werden kann. Im Dialogfenster „Failover konfigurieren“ bleibt die Auswahl leer.

Failover konfigurieren

 

Die Lösung des Problems: auf den migrierten Bereich (Scope) rechtsklicken und „Eigenschaften“ auswählen. Im Reiter „Erweitert“ stellt man dann von „Beiden“ auf „DHCP“ um, da der Failover nicht mit BOOTP-Adressvergabe funktioniert.

Anschließend ist die Konfiguration des DHCP Failovers möglich.