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



VSS Writer: Wie behebe ich VSS Writer Fehler ohne Serverneustart

Problem:
Wer kennt das nicht...ein VSS Writer steht nach dem Backup mit einem Fehler im System und Sie können den Server nicht neu starten, da dieser in Verwendung ist!

Lösung:

1.) Überprüfen Sie mit folgendem Befehl, welcher Writer im Fehler-Status ist:
vssadmin list writers

2.) Hier finden Sie alle VSS Writer und unter Status sollte "Stabil" stehen, ansonsten hat dieser einen Fehler
3.) Folgenden Dienst müssen Sie neu starten um den entsprechenden Writer wieder in den Status "Stabil" zu bekommen
(Achtung: Die Dienste sind in Englisch und könnten von Ihren Namen abweichen)


Quelle: datto: How to resolve VSS writer errors without rebooting (VShadow)

RDP: Wie setzt man eine RDP-Sitzung remote zurück (cmd - Session Reset)

Problem:
Ich hatte eine RDP-Session, die sich "verrannt" hat und ich konnte auch keinen weiteren Benutzer mehr anmelden.
Stattdessen lese ich folgende Meldung beim Anmeldebildschirm:
"Der angeforderte Vorgang konnte nicht ausgeführt werden, da die Remotedesktopdienste derzeit ausgelastet sind. Versuchen Sie es in einigen Minuten noch einmal. Andere Benutzer können sich normalerweise weiterhin anmelden."

Die Anmeldung mit einem anderen Benutzer ist ebenfalls nicht möglich.
Wie komme ich jetzt an den Server um die Session zurückzusetzen?

Lösung:
Man kann von einem anderen Server/Client aus die Session per Kommandozeile ermitteln und zurücksetzen.
WICHTIG: SIE BENÖTIGEN EINEN BENUTZER, DER ADMINISTRATOR-RECHTE AUF DEM BETROFFENEN SERVER HAT!

1.) Melden Sie sich mit dem administrativen Benutzer an einem anderen Server/Client an

2.) Führen Sie den Befehl "query session /server:" aus, wobei Sie für den Namen des betroffenen Servers eintragen.

3.) In der Ausgabe sollten sie die betroffene Session sehen - merken Sie sich die entsprechende SESSION-ID

5.) Nun setzen Sie die betroffene RDP-Sitzung mit folgendem Befehl zurück: "reset session >SESSION-ID> /server:"
Wobei die Session-ID und der Servername mit den jeweiligen richtigen Werten ersetzt werden müssen.

6.) FERTIG - Die Session wird nun zurückgesetzt - das kann einige Minuten dauern!

Sollte der Fehler häufiger auf Server 2008R2 auftreten, dann gibt es von Microsoft einen Hotfix.
Hier scheint es ein Problem zu geben zwischen dem Prozess csrss.exe und manchen Anwendungen.
Microsoft: KB2661332 - Sie können keine Remotedesktopdienste-Sitzung auf einem Windows Server 2008 R2-basierten Server wiederherstellen.

Quelle:
rodolfovaraujo: How to kill RDP sessions remotely

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

Microsoft BitLocker: Ständige Frage nach Recovery-Key nach BIOS-Update

Problem:
Ich habe ein BIOS-Update bei einem Bitlocker-geschütztem System durchgeführt (sehr leichtsinnig!) und nun verlangt Windows immer den sehr, sehr langen Recovery-Key.

Lösung:
Manchmal ist man ja etwas leichtsinnig und ich habe beim BIOS-Update überhaupt nicht an Bitlocker gedacht...hmmm!

Korrekte Vorgehensweise um ein BIOS-Update bei Bitlocker durchzuführen wäre:
1.) Systemsteuerung > System und Sicherheit > Bitlocker-Laufwerksverschlüsselung
2.) Hier wählt man "Schutz anhalten" (NICHT DEAKTIVIEREN)
3.) Nun kann man das BIOS-Update durchführen
4.) Nach dem Update aktiviert man den Schutz wieder
5.) Fertig

Was macht man, wenn man das vergessen hat?
1.) Man startet den Rechner und gibt den Recovery-Schlüssel (Vorher hoffentlich gesichert?!)
2.) Nun hält man den Schutz ebenfalls an, wie oben beschrieben
3.) Nun aktiviert man den Schutz wieder und damit ist alles gut!
4.) Fertig - nach einem Neustart ist alles beim Alten!

Quelle der Recherche:
Winboard: BitLocker: BIOS-Update - "suspend" vergessen
“Sicher ist, dass nichts sicher ist. Selbst das nicht.”
Joachim Ringelnatz