Windows 10 und Server: SMBv1 wieder aktivieren/deaktivieren

Problem:
Ab Windows 10 1709 wird das SMBv1-Protokoll nicht mehr standardmäßig installiert. Es stehen nur noch SMBv2 und v3 zur Verfügung. Da ich noch Drucker und NAS-Systeme habe, die leider außschließlich SMBv1 verwenden, musste ich das übergangsweise aktivieren.

Lösung:
Hier die Powershell-Befehl um SMBv1 abzufragen, zu akivieren und wieder zu deaktivieren:
Status abfragen:
Get-WindowsFeature FS-SMB1

Deaktivieren:
Disable-WindowsOptionalFeature -Online -FeatureName smb1protocol

Aktivieren:
Enable-WindowsOptionalFeature -Online -FeatureName smb1protocol

ACHTUNG: ES WIRD NICHT EMPFOHLEN SMBv1 DAUERHAFT ZU AKTIVIEREN AUFGRUND VIELER SICHERHEITSLÜCKEN IN DIESEM PROTOKOL!!!

Quelle: Microsoft Support: Erkennen, Aktivieren und Deaktivieren von SMBv1, SMBv2 und SMBv3 in Windows und Windows Server

Windows Server 2016 Update Fehler 0x8024500C und 0x8024401c mit WSUS 3.0

Problem:
Einige meiner Server 2016 melden beim Suchen nach Updates die Fehler 0x8024500C oder 0x8024401c. Scheinbar aber nicht alle? Die Server beziehen Ihre Updates von meinem WSUS 3.0 auf einem Server 2008R2.

Lösung:
Um das Problem zu lösen benötigt man einen Microsoft-WSUS-Patch, der unter KB4039929 geführt wird. In den Release Notes des Patches findet sich auch genau die Problembeshreibung:
WSUS update metadata processing can cause clients to time out and return a 0x8024401c error.

Nachdem ich diesen auf meinem WSUS 3.0 installiert hatte, haben die Server 2016 schön brav wieder Ihre Updates abgeholt!
Die neue WSUS Serverversion lautet: 3.2.7600.283
Quelle:
Microsoft Support: An update to improve the performance of update metadata processing on Windows Server Update Services
Microsoft Technet: High CPU/High Memory in WSUS following Update Tuesdays

Terminalserver 2016 (RDS): PDF-Dateien können nicht mit dem Adobe Reader DC geöffnet oder gedruckt werden

Problem:
Nach der Installation des Adobe Readers DC auf einem Terminalserver 2016 konnten die PDFs aus dem eigenen TEMP-Ordner geöffnet werden. Mein erster Verdacht waren die neuen VHD-Profiles.

Lösung:
Des Rätsels Lösung war ganz einfach. Es ist der "Geschütze Modus" (Potected Mode) des Adobe Readers. Scheinbar macht das schon immer Probleme auf einem Terminalserver. Man kann die Funktion testweise bei einem Benutzer mal auscahlten:
- Wählen Sie Bearbeiten > Voreinstellungen.
- Wählen Sie auf der linken Seite unter Kategorien die Option Sicherheit (erweitert).
- Deaktivieren Sie im Abschnitt Sandbox-Schutz die Option Geschützten Modus beim Start aktivieren.

Um das Problem für alle Benutzer zu lösen, kann man einen Registry-Key per GPP ausstreuen:
Keypath: HKLM\SOFTWARE\Wow6432Node\Policies\Adobe\Acrobat Reader\DC\FeatureLockDown
Value name: bProtectedMode
Value type: REG_DWORD
Value data: 0

Damit wird der "geschützte Modus" deaktiviert und das Öffnen und Drucken soltle problemlos funktionieren!

Quelle: FAQ-O-MATIC: Terminalserver: Den Protected Mode des Adobe Reader X abschalten

Windows 10 / Server 2016: Client bezieht seine Updates direkt von WU und nicht mehr vom WSUS (Dual Scan)

Problem:
Alle Windows 10 Clients und Windows 2016 Server haben sich plötzlich Ihre Updates nicht vom WSUS sondern direkt von Microsoft geholt. Da ich die Kontrolle über meine Updates haben wollte, habe ich mich mit dem Problem beschäftigt und fand auch die Ursache "Dual Scan". Hierbei handelt es sich um einen Update-Mechanismus von Microsoft, der mit Windows 10 1607 bzw. dem Cumulative Update KB4034658 vom August 2017 eingeführt wurde. Wie kann ich jetzt meine Updates wieder selbst kontrollieren?

Lösung:
Dualscan wird immer dann aktiviert, wenn man per GPO einen WSUS-Server den Clients zuweist und gleichzeitig Qualitäts- oder Feature-Updates zurückstellt.
Um das "Problem" zu kontrollieren benötigen Sie die GPOs von Windows 10 1607 und das obengenannte Update KB4034658 für Windows 10 und Server 2016. Wenn Sie die Updates und GPOs (zentrale GPOs bei einer AD) eingespielt haben
Danach finden Sie in den GPOs unter
"Computerkonfiguration => Richtlinien => Administrative Vorlagen => Windows-Komponenten => Windows Update" den Punkt ""Keine Richtlinien für Updaterückstellungen zulassen, durch die Windows Update überprüft wird" Diesen aktivieren Sie und danach wird der Client wieder seine Updates vom WSUS beziehen.
Sollte eine GPO nicht möglich sein, dann können Sie das Ganze auch über die Registry steuern:
Registry Path: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate
Value Name: DisableDualScan
Value Type: REG_DWORD
Values: 1 (Enabled) oder 0 (Disabled)

Quelle: Tchnet: Windows 10 Updates and Store GPO behavior with DualScan disabled and SCCM SUP/WSUS managed



Server 2012R2/2016: Event Error DCOM 10016 - APPID 9CA88EE3-ACB7-47C8-AFC4-AB702511C276 / F72671A9-012C-4725-9D2F-2A4D32D65169

Problem:
Nach der Installation meiner Windows 2012R2 und 2016 Server habe ich im Eventlog immer wieder folgende Meldungen gelesen:
Quelle: Microsoft-Windows-DistributedCOM
Ereignis-ID: 10016
Beschreibung:
Durch die Berechtigungseinstellungen für "Anwendungsspezifisch" wird dem Benutzer "NT-AUTORITÄT\SYSTEM" (SID: S-1-5-18) unter der Adresse "LocalHost (unter Verwendung von LRPC)" keine Berechtigung vom Typ "Lokal Aktivierung" für die COM-Serveranwendung mit der CLSID {D63B10C5-BB46-4990-A94F-E40B9D520160} und der APPID {9CA88EE3-ACB7-47C8-AFC4-AB702511C276} im Anwendungscontainer "Nicht verfügbar" (SID: Nicht verfügbar) gewährt. Die Sicherheitsberechtigung kann mit dem Verwaltungstool für Komponentendienste geändert werden.


Lösung:
Das Problem ist, dass der genannte Benutzer (hier: SYSTEM) keine Berechtigung zur Lokalen Aktivierung der DCOM-Komponente besitzt. Um dem Benutzer diese Berechtigung zu geben, müss man wie folgt vorgehen:

1.) regedit starten und zum Schlüssel "HKEY_CLASSES_ROOT\AppID\{9CA88EE3-ACB7-47c8-AFC4-AB702511C276}" navigieren
2.) Hier in den Berechtigungen den Besitzer auf "Administratoren" ändern (Default ist TrustedInstaller)
3.) Den Administratoren dann die Berechtigung "Vollzugriff" auf das Objekt gewähren
4.) Jetzt öffnet man die Komponentendienste mittels "dcompcfg"
5.) In der DCOM-Konfiguration zur entsprechenden APPID navigieren (Hierbei handelt es sich um den "RuntimeBroker")
6.) Den Reiter "Sicherheit" öffnen
7.) Im Abschnitt "Start- und Aktivierungsberechtigungen" auf den Button "Bearbeiten" klicken
8.) Dem Benutzer in der Event-Meldung (hier: System) hinzufügen und die Berechtigungen "Lokale Aktivierung" und "Lokaler Start" geben
9.) FERTIG - der Fehler sollte jetzt nicht mehr auftauchen

Ich hatte die Meldung auch nochmals mit der APPID "F72671A9-012C-4725-9D2F-2A4D32D65169" - hier genauso damit verfahren!

Quelle:
Wiki Butzhammer.de: DistributedCOM-Fehler 10016, APPID 9CA88EE3-ACB7-47C8-AFC4-AB702511C276

Server 2016: Aufgabenplanung führt Aufgaben nicht aus, wenn erste Startzeit in der Vergangenheit liegt!!

Problem:
Ich habe mich an den ersten Server 2016 Systemen versucht und bin gleich auf einen Bug in der "Aufgabenplanung" gestolpert.
Das Problem ist, dass ich versucht habe mehrere Aufgaben zu bestimmten Zeiten laufen zu lassen (Robocopy etc.)
Ein manuelles Starten des Tasks lief problemlos. Aber die Jobs wurden, beim erreichen der geplanten Zeit, nicht ausgeführt!
Nach langer Suche bin ich tatsächlich auf mehrere englische Foreneinträge gestoßen, die hier das gleiche Problem beschreiben.

Wenn Uhrzeit und Datum der ERSTEN Ausführung in der Vergangenheit liegen, dann läuft der Task nicht, wird aber immer wieder neu eingeplant - nur nicht ausgeführt! Man sieht auch, dass sich das Datum der letzten Ausführung nicht ändert!

Lösung:
Gegenwärtig (03.04.2017) habe ich hierfür keine Lösung gefunden!
Es gibt einen Workaround, dass man das Datum manuell in die Zukunft legt und dann läuft der Task auch - bis zum nächsten Neustart des Server - dann tritt das Problem wieder aus. Also wieder alle Tasks in die Zukunft verlegen und dann läuft das !
Ich werde mich erst Mal mit einem Server 2012 R2 begnügen, da das Problem hier nicht auftritt!

Quelle der Recherche:
serverfault: Task Scheduler in Server 2016 Datacenter Edition Doesn't Run Automatically
serverfault: Windows Server 2016 scheduled task schedule must be in future
“Das einzig sichere System müsste ausgeschaltet, in einem versiegelten und von Stahlbeton ummantelten Raum und von bewaffneten Schutztruppen umstellt sein.”
Gene Spafford (Sicherheitsexperte)