Firewall und Spiegel Online

Dieser Artikel beschreibt ein Problem speziell mit Watchguard Firewalls und Spiegel Online (SPON). Vielleicht ist es aber auch bei anderen Firewall-Lösungen nützlich.

Wir hatten in den letzten Wochen bei einigen Kunden das Problem, dass sich bei SPON der Hinweis, dass man doch bitte den AdBlocker ausschalten solle, öffnete, obwohl kein AdBlocker installiert war. Die Ursache ließ sich relativ schnell auf den HTTP-Proxy-Dienst der eingesetzten Firewall (Watchguard) eingrenzen. Es hat aber dann tatsächlich noch etwas gedauert, bis klar wurde, was genau das Problem verursacht. Nachdem wir zunächst SPON in die Proxy-Ausnahmen eingetragen und auch testweise Virenscan und andere Dienste im Proxy deaktiviert hatten, war eine Analyse des Netzwerkverkehrs nötig, um festzustellen, dass bestimmte HTTP-Header-Informationen vom Proxy entfernt werden, die – wie sich herausstellte – für die Funktionalität des Anti-AdBlocker-Prüfscripts bei SPON nötig waren.

Letztendlich hat geholfen, das Pattern

Access-Control-Allow-Origin:*

bei den Response-Headern zu erlauben.

Interessanterweise hatten nicht alle Kunden mit Watchguard das Problem. Es ließ sich allerdings auf die Kunden eingrenzen, die schon vor dem Jahr 2016 auf Watchguard als Firewall-Lösung setzen. Möglicherweise hat Watchguard irgendwann mal in die Standard-Einstellungen für HTTP-Proxys den Header-Typ aufgenommen, weshalb bei neueren Watchguard-Kunden der Header bereits erlaubt wird. Wenn man aber bei alten Kunden die bestehende Konfiguration von alten Geräten auf neue Geräte importiert, wird die Standardeinstellung überschrieben und nur die veraltete Header-Typ-Liste wird verwendet.

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.

Veeam Backup & Replication – Error: VSSControl: Failed to prepare guest for freeze, wait timeout 900 sec

Bei einem Kunden funktionierte das Veeam Backup für eine VM nach der Installation eines Microsoft SQL Server 2016 Express nicht mehr. Fehlermeldung in Veeam:

Error: VSSControl: Failed to prepare guest for freeze, wait timeout 900 sec

Die von Veeam bereitgestelle KB1377 hat nicht geholfen. Bei der Überprüfung der Volumenschattenkopiedienste mit „vssadmin list writers“ wird der SQLWriter nicht aufgeführt. Die Anwendung von KB2095 von Veeam hilft allerdings auch nicht.

In den Ereignislogs des Servers findet sich folgende Fehlermeldung mit der Ereignis-ID 24583:

Sqllib-Fehler: OLE DB-Fehler beim Aufrufen von
                    IDBInitialize::Initialize. hr = 0x80004005.
                    SQLSTATE: HYT00, Native Error: 0
Source: Microsoft SQL Server Native Client 11.0
Error message: Anmeldungstimeout abgelaufen SQLSTATE: 08001, Native
               Error: -1
Source: Microsoft SQL Server Native Client 11.0
Error message: Netzwerkbezogener oder instanzspezifischer Fehler beim
               Herstellen einer Verbindung mit SQL Server. Der Server
               wurde nicht gefunden, oder auf ihn kann nicht
               zugegriffen werden. Überprüfen Sie, ob der Instanzname
               richtig ist und ob SQL Server Remoteverbindungen
               zulässt. Weitere Informationen erhalten Sie in der SQL
               Server-Onlinedokumentation.
SQLSTATE: 08001, Native Error: -1
Error state: 1, Severity: 16
Source: Microsoft SQL Server Native Client 11.0
Error message: SQL Server-Netzwerkschnittstellen: Fehler beim Suchen
               des angegebenen Servers/der angegebenen Instanz
               [xFFFFFFFF].
DBPROP_INIT_DATASOURCE: SRV003\SQLEXPRESS
DBPROP_INIT_CATALOG: master
DBPROP_AUTH_INTEGRATED: SSPI

Nachdem ich da nicht weiter wusste (diverse Dinge überprüft, wie bspw. die Zugriffsberechtigungen auf die Datenbank etc.), habe ich dann erstmal die SQL-Datenbanken in Veeam von der Sicherung ausgeschlossen. Ein Backup lief dann für den Server durch. Anschließend habe ich mir ein Script zur Datenbank-Sicherung erstellt, welches eigentlich als geplante Aufgabe täglich einmal durchlaufen sollte. Dazu habe ich die von Microsoft bereitgestellte Anleitung verwendet: https://support.microsoft.com/en-us/kb/2019698

Beim Testen des Scripts in der Testumgebung lief alles glatt. Auf dem Produktivserver erhielt ich dann aber die Fehlermeldung, dass die Instanz „.\SQLEXPRESS“ nicht gefunden wurde (obwohl sie lief). Das hat mir zu denken gegeben. Nachdem ich das Script so angepasst habe, dass die Instanz „SQLEXPRESS“ nicht mehr benannt wird (also nur „.\“), konnte ein Backup erstellt werden. Somit war mir klar, dass die Instanz quasi „unsichtbar“ ist. Nachdem ich mir dann die SQL-Server-Konfiguration im SQL Server Configuration Manager angeschaut habe, insbesondere bei den Server-Protokollen und dies mit der Konfiguration in der Testumgebung verglichen hatte, stellte ich fest, dass das Protokoll „Shared Memory“ nicht aktiviert war. Nachdem ich das Protokoll „Shared Memory“ sowie zur Sicherheit auch noch „Named Pipes“ aktiviert und den SQL-Server neu gestartet hatte, lief das Backup-Script auch mit der Benennung der Instanz. Eine Überprüfung der VSS-Writer mit „vsadmin list writers“ zeigte nun auch den SQL-Writer mit an.

Also habe ich die Ausnahme aus Veeam wieder entfernt und das Backup gestartet, welches dann erfolgreich durchgelaufen ist.

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

Windows 10 RSAT

In meinem vorigen Beitrag hatte ich ja schon erzählt, dass ich Windows 10 nun auf meinem Arbeits-PC installiert habe. Eine grundlegende Funktion für meinen Job als Systemadministrator für Windows-Netzwerke fehlt allerdings. Na ja, „grundlegend“ ist möglicherweise übertrieben. Aber es ist schon sehr nützlich, die Remote Server Administration Tools (RSAT) auf dem eigenen Rechner zu haben. Sonst muss man sich immer per RDP auf einen der Server aufschalten, um von dort aus die quasi täglichen Aufgaben zu erledigen.

Weiterlesen