Vor einer Weile rief mich ein Kollege an mit folgender Situation:

Bei einem seiner Kunden hatte ein Verschlüsselungstrojaner zugeschlagen, d.h. der Server, die Arbeitsplätze, alle für den Schädling erreichbaren Daten verschlüsselt. Da der Kunde vergessen hatte regelmässig die USB-Festplatte zu wechseln, auf die täglich die Datensicherung läuft, war das letzte verfügbare Backup gut ein halbes Jahr alt.

Soweit also ein Zustand quasi kurz vor grande inferno.

Kurzerhand wurde der Server, ein Windows Small Business Server, aus der Datensicherung wiederhergestellt, allerdings wollte dieser nicht so recht. Beim Starten gab es bereits Unstimmigkeiten, der angepeilte reguläre Betrieb klappte ebenfalls nicht.

Beim Wiederherstellen von „älteren“ Backups von Domänen-Computern, ganz gleich ob Domänen-Mitglied oder Domänencontroller, muss man immer bedenken, das sich inzwischen die Computer-Kennwörter geändert haben. Diese werden automatisch generiert und aktualisiert, je nach Windows-Version und ggf. eigener Konfiguration geschieht dies i.d.R. alle 30 Tage.

An dieser Stelle der Hinweis, das die folgende Vorgehensweise nur für einzelne bzw. alleinige Domänencontroller funktioniert! Hat man zwei oder mehr Domänencontroller im Einsatz sollte davon abgesehen werden, diese wieder ins Netz zu bringen (Stichwort: USN Rollback, dieses sollte unbedingt vermieden werden)!

Mein Vorschlag lautete, den Server vom Netzwerk zu trennen, allerdings muss die Netzwerkkarte mit einem Switch verbunden sein, damit ein „Link up“ vorhanden ist, dann im BIOS das Datum z.B. auf einen Tag nach der letzten erfolgreichen Sicherung stellen und erst dann die Wiederherstellung durchführen.

Hintergedanke dieser Vorgehensweise ist, das nach der Wiederherstellung das System erstmal sozusagen in einem bekannten Zeitrahmen ist. Wenn das soweit geklappt hat, aus Windows heraus das Datum ändern, damit das Betriebssystem „bewusst“ den Zeitwechsel mitbekommt. Erst dann wieder den Server ans reguläre Netzwerk anschließen.

Lange Rede, kurzer Sinn: Das hat soweit funktioniert, ist allerdings die Kurzfassung. Alle Details was zuvor und danach noch gelaufen ist, habe ich nicht mehr im Kopf. Wichtig war mir an dieser Stelle, den Kern der Lösung zu dokumentieren.

Bei einem wenige Tagen altem MDaemon Server vielen mir etliche Fehler im Ereignisprotokoll-System von dieser Art auf:

Protokollname: System
Quelle:        Schannel
Datum:         16.11.2017 15:56:12
Ereignis-ID:   36888
Aufgabenkategorie:Keine
Ebene:         Fehler
Schlüsselwörter:
Benutzer:      SYSTEM
Computer:      srv02.domain.local
Beschreibung:
Es wurde eine schwerwiegende Warnung generiert und an den Remoteendpunkt gesendet.
Dies kann dazu führen, dass die Verbindung beendet wird.
Die schwerwiegende Warnung hat folgenden für das TLS-Protokoll definierten Code: 20.
Der Windows-SChannel-Fehlerstatus lautet: 960.

Kurz beim Support nachgefragt, kam der Tipp zurück, zum einen den Webserver via

https://www.ssllabs.com/ssltest/

zu prüfen, was so out-of-the-box ein eher schlechtes Ergebnis liefert, sofern nicht schon etwas getan wurde oder z.B. ein Reverse Proxy, Security Gateway o.ä. vor den Webserver geschaltet wurde. Als weiterer Hinweis kam, man solle mit folgendem Tool die best practice in Sachen SSL/TLS anwenden und neustarten:

IIS Crypto (Download)

Wie hängt das nun mit dem MDaemon zusammen?

Die Antwort darauf liefert alt-n in seinem Blog:

The encryption protocol and cipher used by MDaemon and SecurityGateway
depend on the operating system and can be configured via the registry.
You can use the free IIS Crypto tool to set the appropriate registry keys.
More information can be found here:
https://www.nartac.com/Products/IISCrypto

Quelle: SecurityGateway 4.5.1 – With Integrated Encryption, Tracking & E-Sign with RMail!

Bevor man nun Blindlinks IIS Crypto laufen lässt, sollte man sich darüber im Klaren sein, was alles von SSL/TLS abhängig ist. Dabei spielt eine Rolle ob, was alles auf dem Server läuft. Lesenswert dazu ist dieser Artikel von Rob Willis:

RobWillis.info – Hardening SSL & TLS connections on Windows Server 2008 R2 & 2012 R2

Danksagung

Vielen Dank an den Support von EBERTLANG für die schnelle Antwort und die Tipps.

Update 16.11.2017 – 20:29

Bei einer Prüfung mit Qualys SSL Server Test gegenüber einem Kerio Connect-Server der auf einem Windows Server läuft erhält man man out-of-the-box die Note A (sofern man ein öffentliches Zertifikat verwendet). Verwendet man ein selbst-signiertes Zertifikat, erhält man ein T mit dem Hinweis, wenn man dies ignoriert, es ein A wäre.

Daraus kann man gut Erkennen, das es darauf ankommt, ob Windows-Bordmittel verwendet werden oder ob der jeweilige Webserver eigene Komponenten und Konfiguration benutzt.

Bei (frisch installierten) Windows Server 2016 kann es durchaus sehr lange dauern, bis die eigentliche Installtion der Updates nach dem Download startet bzw. durchläuft.

In den vergangenen Tagen habe ich zwei Windows Server 2016 installiert. Nummer eins war eine OEM-Installation auf einem neuen Terra Miniserver, Nummer zwei eine virtuelle Maschine.

Bei der ersten Runde in Sachen „Windows Update“ lieferte der Miniserver den Fehler 0x800705b4. Ein weiterer Versuch klappte ebenfalls nicht, weswegen ich dann auf „sconfig“ auswich, da man dort (zumindest theoretisch) die Möglichkeit hat, das Update-Verhalten zu ändern und einzelne Updates auszuwählen.

Für den Anfang und weil’s bei früheren Versionen von Windows schnell ging, wurde erstmal das Defender-Update ausgewählt.

Aber nichts da mit schnell, weder in der Eingabeaufforderung noch in der Oberfläche der Einstellungen war ein Fortschritt zu erkennen. Die Ereignisprotolle lieferten ebenso wenig etwas brauchbares. Genauso war es mit „Get-WindowsUpdateLog“ in der PowerShell (dem neueren Pendant zum „WindowsUpdate.log“). Bei Blick in den Ressourcenmonitor offenbarte viel Aktivität bei „C:\Windows\Logs\CBS\CBS.log“:

Dieser Vorgang nahm über eine Stunde in Anspruch. Danach war keine Aktivität mehr festzustellen. „sconfig“ stand immer noch auf „Updates werden installiert“, unter „Einstellungen“ wurden nur die verfügbaren Updates aufgelistet. Erst ein Blick in den Updateverlauf zeigte, das entgegen der Auswahl bei „sconfig“ alle verfügbaren Updates installiert wurden und ein Neustart gefordert ist.

Nach dem Neustart standen keine Updates mehr zur Verfügung. Mal sehen, was nächsten Monat dann los ist.

Bei der virtuelle Maschine klappte die erste Runde der Windows Updates ohne Fehlermeldung, aber dennoch ackerte sich der Windows Server sich zunächst am „CBS.log“ ab, bevor nach einer Stunde die Updates installiert und der Server außerhalb der Nutzungszeit automatisch neu gestartet wurde.

Seltsames Neustartverhalten

Uneins ist sich Microsoft wohl auch was das Neustarten außerhalb der Nutzungszeit angeht. Während der Miniserver manuell neu gestartet werden musste, so machte dies die virtuelle Maschine von selbst. Bei ersterem lag das möglicherweise an der Fehlersituation.

Man ist wohl nicht alleine

Schaut man sich diesen Thread an, wird schnell klar, das man mit diesem Schwierigkeiten nicht alleine ist:

MS TechNet Forum – what’s with the really slow windows updates on 2016?

Bleibt zu hoffen, das Microsoft dies in den Griff bekommt und hoffentlich beim generellen Handling der Updates wieder auf das alte System zurückschwenkt, so das man ohne Umwege wieder einzelne Updates auswählen, installieren und dann neustarten kann, wann es passt (und nicht wann es Microsoft passt).

Schlussbemerkungen

Grundsätzlich bin ich persönlich weder bei Windows 10 noch Windows Server 2016 kein Freund davon, das diese automatisch irgendwann in einem 12-Stunden-Fenster neu starten. Problematisch dürfte dies sein bei unangekündigten Überstunden wie auch bei Umgebungen mit Mehrschichtbetrieb.

Das aktuell unberechenbare Updateverhalten kann darüber hinaus zum Problem werden, wenn man nur überschaubare Zeitfenster für die Wartung hat.

Zum Durchspielen einer Migration bietet es sich an, eine Datensicherung der Produktivumgebung in einer virtuellen Umgebung einzuspielen und dann Schritt-für-Schritt zu testen.

Diesen Plan wollten wir auch für einen abzulösenden Small Business Server 2008 verfolgen. Nach dem Restore als virtuelle Maschine auf einem Hyper-V Server 2012 R2 war zunächst die Überraschung groß, das der Exchange Server 2007 nicht rund lief. Genauer ausgedrückt wurden die Datenbanken nicht bereitgestellt. Im Ereignisprotokoll fanden sich Meldungen wie z.B. diese:

Im Zuge der Fehlerdiagnose mittels der bekannten eseutil-Befehle stießen wir dann bei „eseutil /r …“ (aka soft recovery) auf „Operation terminated with error -546 (JET_errLogSectorSizeMismatch, the log file sector size does not match the current
volume’s sector size) after 0.230 seconds.“

Ja wie, Probleme mit der Sektorgröße?! Daraufhin recherchiert fand sich dieser Blog-Beitrag:

Nano Tera Network Solutions – Exchange server 2007, log file sector size mismatch

Kurzfassung: Das Problem besteht darin, das neuere Festplatten und VHDX eine Sektorgröße von 4 Kilobyte, „klassische“ Festplatten und VHD 512 Byte, verwenden. Offensichtlich beziehen sich die Transaktionsprotokolle der JET-Datenbank (worunter z.B. Exchange und andere wie z.B. die DHCP-Server-Datenbank fallen) auf die Sektoren. Stimmt die Größe nicht mehr überein, gibt es Schwierigkeiten.

In diesem Fall, also virtuelle Umgebung, war es leicht eine neue VHD (ohne X) anzulegen und den Restore erneut durchzuführen. Bei physikalischen Laufwerken gilt bei Anschaffung auf die richtige Sektoregröße zu achten.

Alternativ soll es wohl möglich sein, das man zunächst zusieht, das alle Transaktionsprotokolle in die Datenbank geschrieben wurden, so das es keine Protokolle mehr gibt und dann den Exchange umzieht.

Der Recherche nach kann es diese Probleme auch mit Exchange Server 2010 geben. Ob weitere neuere Versionen ebenfalls davon betroffen sein können, wurde nicht nachgeschaut.

Nachfolgend ein paar Notizen und Links zum Windows Server 2016 (mit Desktop):

Windows Defender deaktivieren oder entfernen

Ab Windows Server 2016 liefert Microsoft den eigenen Virenschutz Defender auch für den Server mit. Dieser ist sozusagen ab Werk installiert und aktiv. Wer diesen nicht benötigt, kann ihn entweder über die GUI oder PowerShell deaktivieren oder über letztgenanntes ganz deinstallieren:

Windows Pro – Defender in Windows Server 2016 installieren und konfigurieren

Thomas Maurer – How to disable and configure Windows Defender on Windows Server 2016 using PowerShell

Nach der Deinstallation ist ein Neustart notwendig. In den Einstellungen bleibt der „Windows Defender“-Eintrag erhalten, ist allerdings ausgegraut und verweist auf die Verwaltung durch die Organisation (gemeint ist wohl der bzw. die Admin(s)).

Xbox-Dienste und Aufgaben deaktivieren

Warum auch immer haben zwei Xbox-Dienste und Aufgabe Einzug in den Windows Server gehalten. Diese kann und sollte man deaktivieren:

msitproblog – Disabling Xbox Services & Tasks in Server 2016 during OSD with ConfigMgr

Microsoft TechNet – Microsoft Security Guidance blog – Guidance on Disabling System Services on Windows Server 2016 with Desktop Experience

Windows Updates besser steuern

Statt über die GUI kann man über die Eingabeaufforderung mit dem Befehl „sconfig“ das Verhalten der Windows Updates besser kontrollieren und statt alle Updates nur bestimmte zur Installation auswählen.

Aber Achtung: Der Text „Nur Downloads“ ist nicht ganz zutreffend. Dieser Modus ist voreingestellt und läd nicht nur die Updates herunter, sondern installiert diese auch und führt den automatischen Neustart außerhalb der Nutzungszeit durch. Von daher ist die Einstellung „Manuell“ je nach Anspruch vielleicht die bessere Wahl.

Quelle: Tim Anderson’s ITWriting Disabling automatic update restarts in Windows Server 2016

Ein Nachteil wenn man via „sconfig“ die Updates herunterläd und installiert ist der fehlende Status. So lässt sich schlecht beobachten oder abschätzen, wie lange es noch dauert (oder überhaupt etwas gemacht wird). Einzig wenn die Installation abgeschlossen und ggf. ein Neustart notwendig ist, bekommt man dieses angezeigt:

Im Updateverlauf in den Einstellungen sieht man dies auch.

Als Abkürzung zum Suchen und Installieren der Windows Updates kann folgendes Skript verwendet werden:

@echo off

title Windows Update
cd "%windir%\System32\de-DE"
cscript WUA_SearchDownloadInstall.vbs

So spart man sich den Aufruf von „sconfig“ und das Drücken von „6) Updates herunterladen u. installieren“.

Automatischen Neustart außerhalb der Nutzungszeit verhindern

Es ist zwar nett gemeint, das man ein Zeitfenster, in der der Server verwendet wird angeben kann und außerhalb dieser Zeit Dieser automatisch nach der Installation von Updates neu gestartet wird. Je nach Umgebung oder Umstand kann dies allerdings unpassend sein. Um diesen Neustart zu verhindern, muss man die entsprechende Aufgabe ändern und den Befehl durch irgendwas anderes ersetzten. Ein Löschen oder Deaktivieren der Aufgabe nützt nichts, da diese dann wieder neu angelegt wird.

Aufgabenplanung - Microsoft - Windows - UpdateOrchastrator - Reboot

Quelle: MS TechNet Blog – Microsoft Update Product Team Blog – How to change Windows Update settings using SCONFIG. (Kommentar von Buckethead
April 5, 2017 at 12:46 am)

Alternativ die genannte Aufgabe (sofern vorhanden) löschen und einen leeren Ordner unter

C:\Windows\System32\Tasks\Microsoft\Windows\UpdateOrchestrator

anlegen. Dies soll verhindern, das eine neue Aufgabe mit dem Namen „Reboot“ erstellt wird, in Folge wird kein automatischer Neustart durchgeführt.

Quelle: Microsoft Partner Network – How to really manage Windows Update & reboot (Server 2016) for production environment?

Startmenü

Wem das neue Startmenü nicht zusagt, der kann wie zuvor bei Windows 8.x, Server 2012 w/o R2 und Windows 10 z.B. auf die Classic Shell zurückgreifen.

Stand-alone Terminalserver (aka Remote Desktop Session Host)

Der schnellste und einfachste Weg aus einem Windows Server 2016 einen stand-alone Terminalserver (ohne Domäne und Schnickschnack) zu machen besteht (imho) darin, den RDP Wrapper zu verwenden. Alternativ kann man es auch anderst zurechtbasteln:

DigitalBamboo’s Blog – Deploy Remote Desktop Services in a Workgroup or Domain Easily!

Es muss nicht immer Outlook oder Thunderbird sein: Mit Sylpheed gibt es einen kompakten, leicht einzurichteten und schnellen E-Mail-Client für SMTP, POP3 und IMAP.

Auf der Suche um schnell mal den Zugriff auf ein Postfach zu testen ohne etwas installieren zu müssen, bin ich via PortableApps.com auf Sylpheed gestoßen. Dort steht das Programm als Portable-Version zur Verfügung. Die reguläre Setup-Datei findet sich auf der Homepage des Machers. Und sogar bei Wikipedia gibt’s einen kleinen Eintrag dazu.

Sylpheed steht für Windows, MacOS und Unix-Derivate (BSD, Linux) zur Verfügung.

Klassischerweise verwendet man unter Windows (Client als auch Server) die Computerverwaltung um sehen zu können, wer gerade mit welcher Freigabe verbunden ist und welche Dateien geöffnet hat.

Wenn es manchmal zu Schwierigkeiten kommt, kann man den Zugriff beenden bzw. den Nutzer abbmelden. So weit, so gut. Leider gibt es Dinge, die sich scheinbar nie ändern. Seit vielen Windows-Versionen beobachte ich das Problem, das beim Zugriff auf

Computerverwaltung - System - Freigegebene Ordner - Sitzungen

die MMC hängt oder gar abstürzt. So auch aktuell auf einem Windows Server 2016. Manchmal tritt dies direkt beim Aufruf auf, manchmal erst nach einer gewissen Zeit. Ärgerlich ist es in jedem Fall.

Um Sitzungen in der Eingabeaufforderung anzuzeigen kann man

net session

verwenden. Das Äquilvalet für geöffnete Dateien ist

net file

Alternativ kann auch

openfiles

verwendet werden. Via Parameter „/disconnect“ (net session und openfiles) oder „/close“ (net file) können Sitzungen und Zugriffe beendet werden.

Wer es grafisch jenseits der Bordmittel haben möchte, kann einen Blick auf NetworkOpenedFiles von Nir Sofer (aka Nirsoft) werfen.

Kommt es auf einem Windows Server 2016 zu folgenden Fehler:

Protokollname: System
Quelle:        Service Control Manager
Datum:         24.11.2017 10:31:14
Ereignis-ID:   7023
Aufgabenkategorie:Keine
Ebene:         Fehler
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      srv02.domain.local
Beschreibung:
Die Beschreibung für die Ereignis-ID "7023" aus der Quelle "Service Control Manager" wurde nicht gefunden. Entweder ist die Komponente, die dieses Ereignis auslöst, nicht auf dem lokalen Computer installiert, oder die Installation ist beschädigt. Sie können die Komponente auf dem lokalen Computer installieren oder reparieren.

Falls das Ereignis auf einem anderen Computer aufgetreten ist, mussten die Anzeigeinformationen mit dem Ereignis gespeichert werden.

Die folgenden Informationen wurden mit dem Ereignis gespeichert:

Datenfreigabedienst
%%3239247874

Kann man diesen durch die folgenden zwei Befehle ausgeführt in einer Eingabeaufforderung mit erhöhten Rechten umgehen:

sc config ualsvc type=own
sc config dssvc type=own

Quelle:

NeighborGreek – Data Sharing Service crashes on Windows Server 2016 – Event ID 7023

Manchmal hat man Glück im Unglück: Während der Migration eines Windows SBS 2008 zu Windows Server 2016 Standard mit MDaemon Messaging Server starb die Securepoint UTM bei einem Kunden.

In Folge des Ausfalls klappte zunächst nicht die Zustellung bzw. der Abruf von Mails, da die UTM als Mail-Relay (SMTP-Versand als Smarthost) und Mail-Connector (Abruf von POP3-Konten) fungierte. Da die eigentliche Mail-Server-Migration schon durch war, d.h. der Exchange Server 2007 war bereits weg, dafür lief ein MDaemon Messaging Server, war das kein größeres Problem. Es wurde fix der Smarthost und MultiPop im MDaemon konfiguriert und schon liefen die Mails mit einem „Otto-Normal-Firewall-Router“ als Leihgerät zur defekten UTM wieder.

Mit Exchange hätte zwar der Versand per SMTP funktioniert, aber ein Abruf von POP3-Konten beim Provider ging mit den Bordmitteln des SBS schon lange nicht mehr und ein vom vorigen IT-Service verwendeter POPcon lief ebenfalls seit einiger Zeit nicht mehr.

Der Vollständigkeit halber sei erwähnt, das eine direkte SMTP-Anbindung beim Kunden bislang nicht möglich war (soll in Zukunft kommen). Die zusätzliche Sicherheit durch die Filter der UTM fehlt zwar aktuell, da aber Panda Adaptive Defense 360 zum Einsatz kommt, ist das (imho) zu verschmerzen.

Die UTM wird wieder, da noch nicht so alt, Instandgesetzt und wird dann wieder eingebunden.

Wer servergespeicherte Profile zusammen mit Outlook und MDaemon’s Outlook Connector einsetzt, sollte bei großen Postfächern den Cache auf eine Netzwerkfreigabe legen.

Hintergrund ist, das die Datei „LocalCache.db“ und der dazugehörige Ordner „Attachments“ recht umfangreich ausfallen kann, wenn man z.B. ein Postfach mit mehreren tausend Nachrichten oder eine umfangreiche öffentliche Ordner-Struktur hat.

Damit nicht bei jedem Arbeitsplatzwechsel der Cache zum und vom Server synchronisiert werden muss, bietet es sich an, diesen auf eine Netzwerkfreigabe zu legen. So bleibt das eigentliche Benutzerprofil schlank, An-/Abmelden bleibt damit zügig.

Der Pfad kann in den Eigenschaften des Outlook Connectors des jeweiligen Outlooks unter „Verschiedene Einstellungen – Einstellungen zum lokalen Cache – Benutzerdefinierter Speichertort“ geändert werden. Daraufhin beginnt ein neuer Abgleich.

Nebenbei bemerkt: Ein Ändern der Pfade in der „config.xml“ funktioniert nicht, da diese vom Outlook Connector überschrieben werden.

Quelle

alt-n – Outlook Connector for MDaemon – Guidelines

Outlook Connector for MDaemon
| How To Quick Start Guide – Optimal Performance and Installation Guide (PDF)

Es könnte so einfach sein, aber irgendwie haben wir mit Treibern von HP schon öfters kein Glück gehabt. So aktuell beim Servertausch bei einem Kunden.

Bislang und bei vielen anderen Druckern (und Servern) lief es bislang in der Regel so ab, das der neue Server eingerichtet wurde, die Druckertreiber installiert und die Drucker freigegeben wurden. Anschließend wird die Druckerverbindung auf den Arbeitsplätzen aktualisiert (d.h. alte Verbindung trennen, neue Verbindung herstellen).

Diesmal lief es aber anders: Nach dem Trennen der alten Verbindung und dem Versuch die Neue herzustellen stürzte die Druckwarteschlange auf den Windows 7-Arbeitsplätzen ab. Mehrmalige Versuche führten immer zum gleichen Ergebnis.

Startete man die Druckwarteschlange neu und versuchte über die Druckservereigenschaften den vorigen Treiber zu entfernen, erhielt man lediglich die Meldung, das dieser in Verwendung sei.

Folgende Schritte führten dann zum Erfolg, gemeint ist, die neue Verbindung herstellen zu können:

• Die Druckwarteschlange beenden (sofern noch nicht abgestürzt).
• Die Druckertreiber-Dateien unter „C:\Windows\System32\spool\drivers\x64\3“ die „HP*.*“, „M*.*“ und „XPS*.*“ enthalten löschen.
• Ggf. in der Registry unter „hkcu\printers\connectios“ die alten Verbindungen löschen.
• Die Druckwarteschlange starten.
• Über die Druckservereigenschaften den neuen Treiber manuell hinzufügen. Der Drucker steht zu diesem Zeitpunkt zwar schon bzw. noch in der Liste, da man die Treiberdateien allerdings per Hand gelöscht hat, funktioniert Dieser nicht mehr.
• Dann erst über „\\<Servername>\<Druckerfreigabename>“ die neue Verbindung herstellen.

Evtl. hilfreich, wenn auch bislang nicht getestet könnte folgendes sein:

tinte24.de – Drucker komplett deinstallieren – Windows 7 (siehe „Treiber-Deinstallation für Fortgeschrittene“)

TechRepublic – Discover the power of Windows 7 hidden VBScript print utilities

Glück im Unglück hatte eine Kundin, die versehentlich am Stecker ihrer USB-Festplatte hängen blieb und diesen anknackste. Genauergesagt war die Platine im Gehäuse angebrochen und die Pads (Lötanschlüsse) der USB-Buchse waren abgelöst. Da es sich um eine USB 3.0-Festplatte handelte, konnte durch Anlöten der nötigen Adern eine Verbindung mittels USB 2.0-Anschluss relativ einfach hergestellt und so die Daten kopiert werden.

Da vor gut zwei Jahren bereits die Vorgängerfestplatte am kaputtgehen war (fehlerhafte Sektoren) sollte nach dem jetzigen Vorfall eine Lösung her, damit die Daten dieser USB-Festplatte automatisch gesichert werden, sobald diese mit dem PC verbunden wird. Mein erster Gedanke war dabei Bvckup 2, da dieses schnell, einfach und günstig das gewünschte Vorhaben umsetzten kann.

Soviel zur Vorgeschichte, nun zum eigentlichen Thema: Bvckup 2-Aufgaben können in Echtzeit, nach Zeitplan oder manuell (und per Befehl/Skript) gestartet werden. Damit nur beim Anschluss einer bestimmten USB-Festplatte die Sicherung ausgeführt wird, muss man zunächst einen Job anlegen, der manuell gestartet wird:

Dank Fingerprint kann nicht versehentlich das falsche Laufwerk mit gleichem Buchstaben die Aufgabe auslösen, das nur am Rande.

Nun über rechte Maustaste auf die Aufgabe mittels „Open folder – Configuration & logging“ den Ordner öffnen in dem sich die Konfigurationsdatei befindet und wie folgt vorgehen:

• Bvckup 2 beenden (Programm oder Dienst, je nach Konfiguration).
• Die Datei „settings.ini“ im zuvor geöffneten Ordner editieren. Alternativ kann eine Datei mit dem Namen „override.ini“ mit der nachfolgenden Änderung erstellt werden. Beim Neustart von Bvckup 2 wird die Änderung automatisch in die „settings.ini“ übernommen.
• Den Eintrag „conf.run_on_device_arrival“ suchen und von „0“ auf „1“ ändern.
• Bvckup 2 wieder starten.

Das Programm zeigt nun an, das auf das Quellgerät, also die USB-Festplatte, gewartet wird:

Der umgekehrte Fall, also den PC sichern, wenn die Datensicherungsplatte angeschlossen wird, sollte mit der gleichen Änderung ebenfalls funktionieren. Das Ganze funktioniert seit Version 78.9 vom 19. Oktober 2017 und neuer.

Vielen Dank an Alex Pankratov, dem Macher von Bvckup 2, für die Infos und natürlich das tolle Programm.

Zahlen, bitte

Auf unserem Testgerät, einem alten Notebook mit Intel Core2Duo, dauerte nach dem ersten Kopieren die Prüfung auf geänderte Dateien nur 9 Sekunden (für 50GB via USB 2.0, Prüfsummen sei dank). Da kann man glaub‘ ich nicht meckern.

Quellen:

Bvckup 2 – Support – Forum – Running backup when a drive is plugged in

Bvckup 2 – Support – Forum – Release 78

Update 08.12.2017

Kleine Ergänzung:

Ist die USB-Festplatte angeschlossen, wenn der PC gestartet wird, erfolgt ebenfalls eine Sicherung.

Der Securepoint SSL VPN Client in Version 1.0.3 leistet nach wie vor gute Dienste, ist aber freilich nicht mehr auf der Höhe der Zeit. Vor allem in Verbindung mit Windows 10 und den halbjährlichen („Zwangs-„)Upgrades gibt es immer Schwierigkeiten mit der Groß-/Kleinschreibung beim TAP-Treiber (siehe hier).

Abhilfe und zudem eine modernere Optik und mehr Funktionen (in Verbindung mit einer Securepoint UTM) verspricht die Version 2.x. Diese kann wahlweise im Partner-Bereich beim Anbieter (erfordert eine Anmeldung) oder auf der Sourceforge-Seite heruntergeladen werden.

Vor der Installation sollte die vorige Version deinstalliert werden. Wichtig: Die Verbindungseinstellungen werden nicht übernommen, d.h. alle benötigten VPN-Verbindungen müssen neu angelegt bzw. importiert werden.

Das Setup ansich ist nahezu wie von älteren Versionen her gewohnt. Nachdem die erste Verbindung eingerichtet oder importiert wurde, kann es aufgrund der noch vorhandenen älteren Version der TAP-Schnittstelle zu Schwierigkeiten kommen. Am einfachsten lässt sich diese über folgende Schritte aktualisieren:

• Den Securepoint SSL VPN Client öffnen.
• Auf das Zahnrad-Symbol klicken und „Client-Einstellungen“ auswählen.
• Auf der Registerkarte „Allgemein“ der Reihe nach auf die Schaltflächen „TAP entfernen“ und „TAP hinzufügen“ klicken. Die Meldungen zwischen den beiden Klicks bestätigen.

Nun sollte der Verbindungsaufbau (wieder) klappen.

Durch die Aktualisierung wird der TAP-Treiber von einer 2012er auf eine 2016er Version aktualisiert.

Nutzt man Firefox ab Version 56 über eine Remotedesktopverbindung oder als RemoteApp, so wird trotz entsprechender Konfiguration der Verbindung kein Audio wiedergegeben. Andere Anwendungen und Browser hingegen können Klänge, Musik oder Videos korrekt wiedergeben.

Allem anschein nach blockiert die neue Sandbox-Technik die Wiedergabe. Durch eine kleine Änderung klappts wieder mit dem Ton:

• Firefox starten
• In der Adresszeile

  security.sandbox.content.level

  eingeben und den Wert von „3“ auf „2“ ändern.

• Firefox neustarten.

Quelle:

Firefox Support – I can’t play audio on a Remote Desktop Connection

Während der Fehlersuche auf zwei Windows Servern (2012 R2 als auch 2016, jeweils Standard) viel nebenbei folgender Fehler im Ereignisprotokoll auf:

Protokollname: Application
Quelle:        Microsoft-Windows-Perflib
Datum:         12.12.2017 17:28:51
Ereignis-ID:   1008
Aufgabenkategorie:Keine
Ebene:         Fehler
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      srv02.domain.local
Beschreibung:
Die Open-Prozedur für den Dienst "BITS" in der DLL "C:\Windows\System32\bitsperf.dll" war nicht erfolgreich. Die Leistungsdaten für diesen Dienst sind nicht verfügbar. Die ersten vier Bytes (DWORD) des Datenbereichs enthalten den Fehlercode.

Als Schnellschuss kann man versuchen, diesen wie folgt zu lösen:

• Eingabeaufforderung mit erhöhten Rechten öffnen.
• „lodctr /e:bitsctrs.ini“ eingeben und ausführen.

Quellen:

Microsoft TechNet – Event ID 1008 — Performance Library Availability

XTURE – Rebuild Performance Counters

Seit den Windows Updates von Oktober oder November 2017 beobachten wir vermehrt das vor allem bei Domänencontrollern auf Basis von Windows Server 2012 R2 Standard nach einem Neustart die Netzwerkkategorie von „Domänennetzwerk“ zu „Öffentliches Netzwerk“ (oder schlicht „Öffentlich“) wechselt.

In wie weit andere Versionen und Editionen von Windows davon betroffen sein können, kann aktuell nicht sicher ermittelt werden. Auffällig war jedenfall die Kombination, d.h. es gibt mehrere Domänencontroller und meist „scheitert“ ab dem zweiten Domänencontroller die Ermittlung der richtigen Netzwerkkategorie nach dem Neustart (z.B. nach Windows Updates).

Der Vollständigkeit halber sei erwähnt, das die Domänencontroller nicht gleichzeitig, sondern der Reihe nach neu gestartet wurden und zudem immer gewartet wurde, bis der jeweils andere Server wieder vollständig gestartet war.

Mögliche Lösungswege

Bei verschiedenen Kunden haben verschiedene Methoden geholfen. Leider bislang immer nur in Verbindung mit einem Neustart.

I.d.R. genügt ein normaler Neustart. Als Schnellschuss, wenn der Server gerade nicht neu gestartet werden darf, kann es schonmal helfen die Netzwerkkategorie auf „Privates Netzwerk“ zu ändern (siehe hier), damit die meisten Dienste wieder normal erreichbar sind oder die Windows-Firewall vorübergehend zu deaktivieren.

Zuletzt, d.h. gestern, hat bei einem Kunden nur geholfen erst die Windows-Firewall für alle Kategorien zu deaktivieren und den Server neuzustarten. So wurde die Netzwerkkategorie richtig erkannt und die Firewall konnte wieder aktiviert werden.

Was bei manchen Kollegen der Lesart nach ebenfalls (ohne Neustart) geholfen haben soll wäre folgendes:

• Den Dienst „NLA (Network Location Awareness)“ (Dienstname: „NlaSvc“) neu starten.
• Via PowerShell die Netzwerkkategorie auf „Domänennetzwerk“ ändern:

  set-netconnectionprofile -interfaceindex <NR> -networkcategory DomainAuthenticated

Seit den Windows Updates vom November 2017 beobachten wir auf manchen Windows Server 2012 R2 Standard-Terminalserver, das keine RDP-Verbindungen aufgebaut werden können. Meist aber nicht ausschließlich tritt dies bei getrennten Sitzungen auf, die wiederhergestellt werden sollen.

Es kommen (sinngemäss) Meldungen wie „Terminaldienste ausgelastet“ oder es bleibt ewig bei „Willkommen“ oder „Windows wird vorbereitet“ stehen. Mitunter hilft es ein paar Minuten zu warten und dann die Verbindung erneut zu versuchen aufzubauen bzw. wiederherzustellen. Manchmal helfen nur weitere Massnahmen:

Als erstes und einfachstem (nach Warten) kann helfen den Benutzer vom Terminalserver abzumelden. Funktioniert diest nicht, kann man versuchen die entsprechenden Dienste „Remotedesktopdienste“ und „Anschlussumleitung für Remotedesktopdienst im Benutzermodus“ neu zu starten. Letzgenannter Dienst ist von „Remotedesktopdienste“ abhängig und wird über die Diensteverwaltung (wenn man die MMC/GUI) verwendet automatisch mit beendet und gestartet.

Achtung: Dabei werden alle aktiven Sitzungen getrennt!

Kommt man mittels Remotedesktopverbindung gar nicht mehr erst auf den Server (auch nicht als Admin), kann man die Dienste z.B. via psexec neu starten:

psexec \\<Server> -u admin -p cmd

net stop UmRdpService
net stop TermService

net start TermService

Mit dem Start von „TermService“ wird automatisch „UmRdpService“ mitgestartet.

Ob diese Schwierigkeiten evtl. mit den Windows Updates vom Dezember 2017 bereits behoben sind, kann aktuell noch nicht gesagt werden, da es bislang an Erfahrungswerten fehlt.

Es gibt einige Wege festzustellen, wann Windows zuletzt gestartet wurde. Vor Jahren blieb bei mir folgender Befehl im Gedächtnis hängen:

systeminfo | find "zeit"

Die Ausgabe sieht dann so aus:

Systemstartzeit: 13.12.2017, 19:58:23
Virtueller Arbeitsspeicher: Zurzeit verwendet: 10.231 MB

Zugegeben, die zweite Zeile ist dann eher Nebensache. Wenn man statt „zeit“ „startzeit“ verwendet, ist das Ergebnis treffender.

Ein Blick in den Task-Manager verrät einem, wie lange Windows bereits läuft:

Es gibt noch mehr Möglichkeiten, eine recht nette Lösung neben weiterer Beispielen findet sich hier:

superuser – How can I find out when Windows was last restarted?

Konkret geht’s um die Antwort von Max vom 24. Mai 2016. Anbei dessen Skript mit etwas Aufschlüsselung:

@echo off

rem Startzeit von Windows auslesen ("wmic...") und auf den Wert ("find...") begrenzen

 for /f %%a in ('WMIC OS GET lastbootuptime ^| find "."') DO set DTS=%%a

rem Format umwandeln

 set BOOTTIME=%DTS:~0,4%-%DTS:~4,2%-%DTS:~6,2% %DTS:~8,2%:%DTS:~10,2%

rem Ausgabe

 REM echo DTS : %DTS%
 echo BOOTTIME : %BOOTTIME%

echo.
pause

Die Ausgabe sieht so aus:

BOOTTIME : 2017-12-13 19:58

Durch ändern des Skripts kann man die Ausgabe bequem anpassen. Z.B.:

Startzeit: 13.12.2017 19:58

Die geänderten Zeilen dazu:

set BOOTTIME=%DTS:~6,2%.%DTS:~4,2%.%DTS:~0,4% %DTS:~8,2%:%DTS:~10,2%
echo Startzeit: %BOOTTIME%

Die Windows Server Update Services (WSUS) bieten im Microsoft-Netzwerk eine recht bequeme und zuverlässige Möglichkeit, Aktualisierungen für die Produkte aus Redmond zu verteilen. Grundsätzlich lässt sich dieser Dienst auch zum WAN hin betreiben um z.B. Außendienst-Mitarbeiter anzubinden.

Leider unterstützt der Windows Update-Client keine Authentifizierung, so das seitens der verwendeten Internet Information Services (IIS) theoretisch die Möglichkeiten über die Computeranmeldung oder Client-seitige Zertifikate bliebe. Erstgenanntes funktioniert nur in der Domäne, letztgenanntes setzt eine Zertifizierungstelle (CA) und die Verteilung von Zertifikaten voraus.

Microsoft TechNet – Secure WSUS 3.0 Deployment

Liest man zur Nutzung der Zertifikate allerdings das Kommentar von Lawrence Garvin kommen einem schnell Zweifel, ob das funktioniert:

"At a minimum you'd need to use some form of reverse-proxy with authentication,
or client-side SSL certificates -- the WUAgent in combination wiht WinHTTP
does support authenticated proxy connectivity.
The SSL certs scenario is a theoretical solution,
I've not actually heard of anybody who has successfully implemented
client-side SSL certificates in a WSUS environment."

Quelle: Microsoft TechNet Forum – WSUS updates for external users

Wie Lawrence schreibt, könnte auch ein Reverse Proxy mit Authentifizierung verwendet werden. Leider habe ich dazu keine detailierten Informationen gefunden und ob es überhaupt auf die Dauer stabil läuft. Der Lesart über verschiedene Treffer via Suchmaschine nach scheint es da gerne Schwierigkeiten zu geben.

Ein weiterer Ansatz kann sein, den Zugang über VPN zu realisieren. Das setzt wiederum neben der nötigen Infrastruktur voraus, dass regelmässig oder automatisch eine VPN-Verbindung hergestellt wird und es zu keinen Konflikt mit den verwendeten IP-Netzen kommt. Noch eine Möglichkeit, und das ist sozusagen des Pudels Kern dieses Beitrags, bietet stunnel an. Dies geht zum einen mittels Zertifikaten oder schneller und einfacher ab Version 5.09 mit Pre-Shared Key (PSK).

stunnel-Server einrichten

Die Server-seite von stunnel kann, muss aber nicht auf dem gleichen System wie der WSUS laufen. Für diesen Beitrag wurde stunnel auf dem gleichen System installiert.

Zunächst die Installationsdatei herunterladen, diese Ausführen und dem Assistenten folgen. Da es gerne zu Schwierigkeiten kommen kann, wenn nach „C:\Program Files (x86)“ installiert wird, sollte dies zu „C:\stunnel“ geändert werden. Beim Erstellen des Zertifikats kann irgendetwas eingetragen werden, dieses wird im weiteren Verlauf nicht verwendet.

Direkt nach der Installation wird stunnel als Anwendung gestartet und kann durch einen Rechtsklick auf das Infobereichssymbol und „Exit“ beendet werden. Die Desktop-Verknüpfung „stunnel AllUsers“ startet dieses wieder als Anwendung und sollte im weiteren Verlauf nicht verwendet bzw. besser entfernt werden.

Bevor mit der eigentlichen Konfiguration begonnen wird, kann man den Stand nach der Installation zunächst sichern. Dazu einfach den Ordner „C:\stunnel\config“ kopieren. Man könnte nun die vorhandene „stunnel.conf“ anpassen. Einfacher und übersichtlicher ist es, eine eigene „stunnel.conf“ zu erstellen:

; *** Logging ***
debug = info
output = stunnel.log

; *** Services ***
[WSUS-http]
accept = 8532
connect = 127.0.0.1:8530
ciphers = PSK
PSKsecrets = secrets.txt

[WSUS-https]
accept = 8533
connect = 127.0.0.1:8531
ciphers = PSK
PSKsecrets = secrets.txt

PSK erzeugen

Den Pre-Shared Key kann man manuell oder per Befehl bzw. Skript erzeugen. stunnel bringt für letzteres alles benötigte mit, so das sich mit einem kleinen Skript dies einfach handhaben lässt:

@echo off

set openssl_conf=C:\stunnel\config\openssl.cnf
set RANDFILE=C:\stunnel\config\.rnd

echo.

C:\stunnel\bin\openssl.exe rand -hex 32

echo.
pause

Der PSK kann zusammen mit einem Benutzernamen dann bequem in die „secrets.txt“ eingefügt werden:

BENUTZERNAME:PSK

Auf der Server-seite befinden sich alle Benutzernamen samt PSK in dieser Datei, auf der Client-seite nur der jeweilige Benutzer mit seinem PSK. Damit der neue oder geänderte Benutzer übernommen wird, entweder einmal die Konfigurationsdatei neu laden (entweder um das Startmenü oder „stunnel.exe -reload“) oder den Dienst „stunnel TLS wrapper“ (Dienstname „stunnel“) neustarten.

Dienst installieren und starten

Aus dem Startmenü „stunnel Service install“ anklicken um den Dienst einzurichten. Über „stunnel Service start“ kann der Dienst gestartet werden.

In einer Eingabeaufforderung geht dies mittels

stunnel.exe -install
stunnel.exe -start

Firewall konfigurieren

Je nach Konfiguation bzw. Anspruch benötigt der WSUS per Vorgabe die Ports 8530/tcp für http und 8531/tcp für https (sofern konfiguriert). Entsprechend der Konfiguration bei stunnel müssen die entsprechenden Ports, 8532/tcp für http bzw. 8533/tcp für https, oder schlicht die „stunnel.exe“ in der Firewall freigeschaltet bzw. weitergeleitet werden.

In der Windows-Firewall werden automatisch bei der Installation des WSUS die Standard-Ports eingerichtet. Soll dieser nun nur noch via stunnel erreicht werden können, sollte man die entsprechenden Regeln deaktivieren. Parallel dazu kann man im IIS einstellen, das z.B. nur auf „localhost“ („127.0.0.1“ bzw. „::1“) gelauscht wird.

stunnel-Client einrichten

Die stunnel.conf auf der Client-Seite kann z.B. so aussehen:

; *** Services ***
[WSUS-http]
client = yes
accept = 127.0.0.1:8530
connect = <Server/IP>:8532
ciphers = PSK
PSKsecrets = secrets.txt

[WSUS-https]
client = yes
accept = 127.0.0.1:8531
connect = <Server/IP>:8533
ciphers = PSK
PSKsecrets = secrets.txt

Der Client liese sich ebenso einrichten, wie der Server, d.h. Setup herunterladen, ausführen usw. Praktischer kann sein, alle benötigte Dateien zusammenzustellen und ggf. per Skript zu verteilen bzw. zu installieren.

Windows Update auf dem Client konfigurieren

Die notwendigen Einstellungen lassen sich per lokale oder domänen-weite Gruppenrichtlinie oder in der Registry vornehmen. Anbei die minimalsten Änderungen für die Registry:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"WUServer"="http://127.0.0.1:8530"
"WUStatusServer"="http://127.0.0.1:8530"
"TargetGroupEnabled"=dword:00000001
"TargetGroup"="TEST"
"DoNotConnectToWindowsUpdateInternetLocations"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU]
"UseWUServer"=dword:00000001

Dem Client wird so mitgeteilt, das der WSUS als Updatequelle dient, die restlichen Einstellungen entsprechen den Vorgaben von Microsoft. Einzige Abweichungen sind:

"TargetGroup"="TEST"

Die Client-seitigen Zuordnung des Clients zu einer Gruppe im WSUS, sofern dies auf dem Server aktiviert ist. Ansonsten kann man diese Zeile weg lassen und schiebt den Computer per Hand in die passende Gruppe.

"DoNotConnectToWindowsUpdateInternetLocations"=dword:00000001

Seit Windows 8.x kann man damit regeln, ob jenseits vom WSUS auch direkt bei Microsoft nach Updates gesucht wird. Ein Equivalent zu anderen Windows-Versionen existiert ebenfalls, siehe dazu das MSDN-Link in den Quellen.

Quellen

stunnel: Authentication

Microsoft – MSDN – Configure Automatic Updates using Registry Editor

WSUS.DE – HowTo > AU-Client Registry Key

Windowspage – Tipps – Windows-Update – Keine Verbindung zu Update-Internetdiensten bei Intranetserver erlauben

Im wesentlichen unterscheidet sich die Installation und Handhabung eines WSUS unter Windows Server 2016 nicht von den bisherigen Versionen. Früher oder später stolpert man allerdings über ein paar Kleinigkeiten. Anbei ein paar Notizen.

Installation

Die Installation erfolgt wie z.B. von Windows Server 2012 gewohnt über den Server-Manager. Hierzu gibt es nichts besonderes zu erwähnen.

Fehlende Komponenten für die Berichterstellung installieren

Leider fehlen nach dem grundlegenden Setup die Komponenten damit Berichte erstellt werden können. Nach einem Doppelklick auf einen Computer oder ein Update erhält man zunächst eine Meldung, die auch gleich die Lösung mit anbietet. Danach fehlt allerdings immer noch etwas, unglücklicherweise ohne Hilfestellung.

• Microsoft Report Viewer 2012 herunterladen und installieren.
• Microsoft System CLR Types for SQL Server 2012 herunterladen und installieren. Scheinbar reicht die 32-bit Version aus:
  Direkte Downloads: 32-bit / 64-bitAlternativ: Microsoft® SQL Server® 2012 Feature Pack– Auf „Anweisungen zur Installation“ klicken.

  – Zu „Microsoft® System-CLR-Typen für Microsoft® SQL Server® 2012“ wechseln und das gewünschte Paket herunterladen.

Definitionsupdates automatisch genehmigen lassen

Verwendet man Defender, Exchange oder Outlook, kann es Sinn machen, die Definitionsupdates automatisch genehmigen zu lassen:

Windows: Nur Definitionsupdates für Windows Defender und Microsoft Security Essentials im WSUS automatisch genehmigen

Fehlende Updates oder Hauptversionen importieren, Windows 10-Updates und – Upgrades zur Verfügung stellen

Der WSUS liefert meist nur Aktualisierungen für bereits installierte Software aus. Möchte man z.B. Internet Explorer 11 oder .NET Framework 4.7 verteilen, so muss dies vorher importiert werden:

Allgemein:

• In der „Windows Server Update Services (WSUS)“-MMC den Servernamen anklicken.
• Aus der rechten Spalte bei „Aktionen“ „Updates importieren…“ anklicken.

Es öffnet sich der Internet Explorer. Beim ersten Mal muss zunächst die Installation einer ActiveX-Erweiterung („Microsoft Update Catalog“) bestätigt werden. Danach kann nach Updates gesucht und diese zum Auswahlkorb hinzugefügt werden. Aus dem Auswahlkorb heraus kann man diese dann in den WSUS importierten.

Wichtig: Den Internet Explorer verwenden (am besten als Standard-Browser belassen), da sonst nur ein Download ohne Import-Möglichkeit angeboten wird.

Internet Explorer 11:

Microsoft Windows IT Pro Center – Installieren von Internet Explorer 11 (IE11) mit Windows Server Update Services (WSUS)

.NET Framework 4.7:

Microsoft MSDN – .NET Blog – Microsoft .NET Framework 4.7 is available on Windows Update, WSUS, and MU Catalog

Windows 10:

Microsoft Windows IT Pro Center – Bereitstellen von Windows10-Updates mit Windows Server Update Services (WSUS)

Windows-FAQ – Windows 10 Creators Update per WSUS verteilen (Die Links am Ende des Beitrags beachten, diese behandelt dann z.B. auch 1607).

Serverbereinigung

Ein wenig Pflege des Datenbestands kann sicherlich nicht Schaden. Vor allem dann nicht, wenn sich im Laufe der Zeit abgelaufene oder ersetzte Updates ansammeln und so langsam aber sicher immer mehr Speicherplatz belegt wird.

Per Hand kann man auf dem WSUS aus den „Optionen“ heraus den „Assistent für die Serverbereinigung“ starten und laufen lassen:

WSUS – Serverbereinigung nicht vergessen

Um den Vorgang zu Automatisieren gibt es mehr oder weniger verschiedene Ansätze:

Die (imho) einfachsten Skripte findet man bei WSUS.DE:

WSUS Serverbereinigung mit Powershell #1 (für mehrere Server)

WSUS Serverbereinigung mit Powershell #2 (mit E-Mail-Report)

Tipp: Um eine Authentifizierung für den E-Mail-Versand im letztgenannten Skript reinbasteln zu können, ist dieser Beitrag interessant:

Phil Erb – Sending mail with PowerShell

Dann gibt’s z.B. noch weitere „Putz-Ansätze“:

Bents Blog – Automatische WSUS Serverbereinigung mit Tasks und Skripten

Bents Blog – Windows Server Update Services (WSUS) auf Windows Server 2012 mit automatischer Bereinigung

xenappblog – How To Clean Up WSUS

Datensicherung

Last, but not least sollte auch der WSUS gesichert werden, denn im Falle eines Crashes alle Einstellungen, Genehmigen und die Updates erneut setzen und herunterladen zu müssen ist eine unschöne Aufgabe. Man kann gezielt alle WSUS-relevanten Teile oder schlicht den ganzen Server mit geeigneten Mitteln, das schließt VSS für die konsistente Sicherung der Datenbank mit ein, sichern.

Microsoft TechNet – Backing Up Windows Server Update Services (bezieht sich noch auf ntbackup, von daher sind lediglich die Pfade interessant)

Microsoft TechNet – Forums – WSUS Backup with Windows Server Backup on 2012 R2 (Antwort von Mary Dong, d.h. die Datenbank mit SQL Management Studio sichern, die Dateien wie gehabt)

The ITbros – How to backup WSUS database

Quellen

RootUsers – Configure WSUS reporting in Windows Server 2016

serverfault – Install SQL CLR types & Report Viewer 2012 on Sql 2008 server

Microsoft TechNet – Using the Server Cleanup Wizard