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)
wir hatten ja letztes Jahr einen Outlook-Patch, der uns viel Kummer bereitet hat!
Damals haben wir uns manuell auf die Deinstallations-Runde gemacht, hätten das aber leichter haben können.
Ich bin heute wieder darüber gestolpert, als ich den WSUS für Stadelhofen vorbereitet habe.
Man kann ein Update anklicken und für eine Gruppe gezielt „Zur Entfernung genehmigen“.
Hier mal ein Beispiel:
So einfach hätte die Welt sein können! ?
…das nächste Mal wissen wir es und das nächste Mal kommt bestimmt…Danke Microsoft! ?
Sollte der Fehler dann noch immer bestehen, dann gehen Sie bitte wie folgt vor:
1.) Öffnen Sie eine Eingabeaufforderung mit Admin-Rechten
2.) Führen Sie hier der Reihe nach folgende Befehle durch
net stop wuauserv
net stop cryptSvc
net stop bits
net stop msiserver
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 catroot2.old
net start wuauserv
net start cryptSvc
net start bits
net start msiserver
3.) Das Windows Update testen und danach die zwei mit .old benannten Ordner löschen.
WSUS 3.0 Migration von Windows Server 2003 auf Windows Server 2008 (R2)
Auf dem alten Server
1.) WSUS API Samples and Tools downloaden: WSUS API Samples and Tools (Sie finden die Installationsdatei auch am Ende des Artikels)
2.) In den Ordner C:\Program Files\Update Services 3.0 API Samples and Tools\WsusMigrate\WsusMigrationExport wechseln
3.) Ausführen von wsusmigrationexport.exe settings.xml
4.) Die MSDE Instanz stoppen, Update Dienst stoppen
5.) WSUS Verzeichnisse sichern (z.B.: NTBACKUP) Achtung: Nur Windows Server 2008 unterstuetzt das separat herunterzuladende Windows NT Restore Utility (NTBACKUP read only). Windows Server 2008 R2 unterstuetzt das nicht mehr
Auf dem neuen Server
1.) WSUS 3.0 SP2 ueber den Servermanager installieren (Rolle hinzufügen) (inkl. WMDE)
2.) Erstkonfigurationsassistent nicht ausführen
3.) WSUS Dienst und MSDE Dienst stoppen
4.) WSUS Verzeichnisse zurückkopieren (inkl. WSUS DB)
5.) In den Ordner C:\Program Files\Update Services 3.0 API Samples and Tools\WsusMigrate\WsusMigrationImport wechseln
6.) Ausführen von wsusmigrationimport.exe settings.xml All None
Danach ist die alte WSUS Konfiguration inkl. aller Updates verfügbar!
ACHTUNG: Anschliessend in den GPO-Einstellungen noch den Pfad zum WSUS Server anpassen!
Hier gibt es den "Hardcore-Button" Force Patching. Damit wird die Verbindung erzwungen!
Folgende Vorgehensweise hat bis jetzt immer zum Erfolg geführt:
- Reset Client ID
Erstellt eine neue WSUS-Client-ID für den Rechner und schreibt diese unter HKLM\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate
- Force Patching
Hier werden ein paar Registry-Keys gesetzt. Dadurch wird die Kommunikation zwischen WSUS-Server und Client erzwungen.
- Report now
Hiermit wird der aktuelle Statusbericht an den Server gesendet – z.B. installierte Patches, OS etc.
Die heruntergeladenen Updatefiles nehmen beim WSUS schnell ein paar Gigabytes mehr in Anspruch als ursprünglich eingeplant.
Wie verschiebt man nun die Content-Datenbank des WSUS 3 Servers auf ein neues, größeres Laufwerk?
Lösung:
Dies ist mit dem WSUSUTIL möglich:
Neben anderen Optionen zur Wartung des WSUS-Servers bietet das Utility WSUSUTIL.EXE (im Pfad %drive%\Program Files\Update Services\Tools) den Parameter movecontent.
Mit WSUSUTIL movecontent [Pfad zum Zielverzeichniss] [logfile] werden sämtliche heruntergeladenen Updates auf das neue Laufwerk verschoben, und der WSUS-Server für den neuen Contentpfad konfiguriert.
Das Logfile nach erfolgter Aktion sollte so aussehen:
2007-05-11T12:53:43 Successfully stopped WsusService.
2007-05-11T12:53:43 Beginning content file location change to e:\wsus
2007-05-11T12:57:58 Successfully copied content files.
2007-05-11T12:57:58 Successfully copied application files.
2007-05-11T12:57:59 Successfully changed WUS configuration.
2007-05-11T12:58:00 Successfully changed IIS virtual directory path.
2007-05-11T12:58:00 Successfully removed existing local content network shares.
2007-05-11T12:58:00 Successfully created local content network shares.
2007-05-11T12:58:00 Successfully changed registry value for content store directory.
2007-05-11T12:58:00 Successfully changed content file location.
2007-05-11T12:58:02 Successfully started WsusService.
2007-05-11T12:58:02 Content integrity check and repair...
2007-05-11T12:58:02 Initiated content integrity check and repair.
“Das einzig sichere System müsste ausgeschaltet, in einem versiegelten und von Stahlbeton ummantelten Raum und von bewaffneten Schutztruppen umstellt sein.”
