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:
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.
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!
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)
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!
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!
“Das einzig sichere System müsste ausgeschaltet, in einem versiegelten und von Stahlbeton ummantelten Raum und von bewaffneten Schutztruppen umstellt sein.”