macleod
Goto Top

Verbindungsverhalten zu WSUS Server Win7 (8.1, 2012r2) vs. Windows10 (Server2019)

Hallo
Folgendes Szenario: Im Hauptbetrieb einer Firma läuft ein wsus Server. Dieser ist über wsus.headquarter.com über DNS aufgelöst. Alle Computer, egal welches OS, connecten einwandfrei.
Nun sind weitere Nebenstellen per VPN angebunden. Die VPN Leitung ist jeweils ein eigener Router mit eigener Internetverbindung, bzw. dark fiber. Dort wird der entsprechenede DNS Range von Headquarter ebenfalls repliziert. Alle Clients in den Nebenstellen können wsus.headquarter.com problemlos auflösen und der ping, tracert geht direkt über die VPN Leitung ohne Umwege. Egal welches Betriebssystem. Win7, 8.1, 2012r2 verbinden sich mit dem wsus und ziehen problemlos ihre updates. Win10 Clients haben immer Verbindungsprobleme gemeldet, trotz gleichen Routings, gleicher GPO.
Zum Test wurde der Wsus auch mal über das Internet aufgemacht und ist ebenfalls unter wsus.headquarter.com von extern erreichbar. Siehe da, auf einmal connecten die Win10, Server 2019 und ziehen ihre updates.
Kurzum: Alte Betriebssysteme gehen direkt über VPN, Windows 10 will bei gleicher Einstellung den Weg über das Internet gehen. Alle Win 10 Clients kommen mit der externen IP des Standardrouters Warum dieser Unterschied? Kann das jemand erklären? Kann man das einfach, etwa über GPO, lösen?

Vielen Dank,
Conner

Content-ID: 598828

Url: https://administrator.de/contentid/598828

Ausgedruckt am: 21.11.2024 um 17:11 Uhr

certifiedit.net
certifiedit.net 23.08.2020 um 21:48:00 Uhr
Goto Top
Schau mal, ob die Ihre DNS Settings von extern beziehen (DNS über TLS o.ä) und darüber gehen. Aber da hast du wohl die Hausaufgaben nicht gemacht dies zu reglementieren?
MacLeod
MacLeod 23.08.2020 um 22:07:40 Uhr
Goto Top
DoT ist standardmäßig deaktiviert und erklärt auch nicht dieses Verhalten. Tritt mit DHCP und mit fester IP, festem DNS genauso auf. Unzählig andere Anwendungen die über die Route und DNS Replikation laufen verhalten sich vollkommen normal. VLMCS, Endpoint Mangement etc. gehen direkt über DNS und die interne Route auch wenn sie synchron über das Internet erreichbar sind (testweise). Es ist nur WSUS.
certifiedit.net
certifiedit.net 23.08.2020 um 23:12:47 Uhr
Goto Top
Das solltest du sagen. Ist dort irgendwas an der Hierarchie anders? Das gilt es dann heraus zu finden.
MacLeod
MacLeod 24.08.2020 um 10:25:31 Uhr
Goto Top
Ich vermute, es ist irgendeine Änderung zwischen den Versionen von Windows 10 gemacht worden. Um das nachzuvollziehen beginne ich gerade mit einem neuen Win10 1507 VMware Client im Netzwerk. Mal sehen ob der noch den alten Weg geht. Dann werde ich stufenweise upgraden und berichten.
LukasD
LukasD 24.08.2020 um 12:06:39 Uhr
Goto Top
Hi,
Poste bitte mal den Registry Schlüssel "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate". Steht da der WSUS drin?

Habe ich dich richtig verstanden, dass Windows im Internet nach Updates sucht und nicht über den WSUS geht? Zeigt Windows Update irgendwelche Fehler an?
Außerdem bitte mal folgendes in Powershell ausführen:
$MUSM = New-Object -ComObject "Microsoft.Update.ServiceManager"
$MUSM.Services | select Name, IsDefaultAUService
Das zeigt an, woher aktuell die Updates bezogen werden.

Mit welcher IP melden sich die Win 7 und 10 Clients jeweils? Alle mit der externen Adresse?
MacLeod
MacLeod 24.08.2020 um 12:59:14 Uhr
Goto Top
Hallo
In der Registry steht natürlich der Wsus drin. Als Wsus und als Stat Server. Wird alles per GPO verteilt. GPO Vorlage ist auf Stand 1909. Das Cmdlet zeigt den Windows Server Update Services als Default mit True, alle anderen als False.
Es geht auch nicht primär darum, woher die Clients die Updates selbst beziehen. Ich kann sie aus dem Internet ziehen lassen aber auch vom WSUS, der mit 0,9TB voll bestückt ist. Je nachdem wie ich die Option im WSUS setze.

Es geht darum, daß die Windows 10 (1809/1903/1909) Clients beim update saugen und reporten IMMER den Weg über das Internet gehen, auch wenn die lokale route steht und gepingt wird. Folglich erscheinen die mit der externen IP der Niederlassung. Server 2012r2, Win7 etc. nehmen die interne route und kommen mit der internen IP an.
LukasD
LukasD 24.08.2020 um 13:28:10 Uhr
Goto Top
Evtl. mal versucht direkt die IP des WSUS zu setzen?
Außerdem mal das Windows Update Log checken.
MacLeod
MacLeod 24.08.2020 um 14:20:51 Uhr
Goto Top
Setze ich die IP direkt, dann nehmen alle die interne Route. Wie zu erwarten. Muss ja so sein. Da aber in dieser Firma mal aufgeräumt und alles vernünftig über DNS umgesetzt werden soll ist das etwas kontraproduktiv. Gerade weil diverse Server noch migriert/neu erstellt werden müssen.
Wenn alles im DNS geregelt ist muss bei einer Migration im Hauptbetrieb nur dort Im DNS und in der Firewall gefummelt werden. Und nicht in den GPO der Niederlassungen.
LukasD
LukasD 24.08.2020 um 14:24:11 Uhr
Goto Top
Klar, das ist natürlich verständlich. DNS ist selbstverständlich die bessere Lösung.
Aber dann muss es ja ein Problem bei der Auflösung geben?

Wie wird DNS realisiert? Vermutlich über Split DNS?
MacLeod
MacLeod 24.08.2020 um 14:33:52 Uhr
Goto Top
Steht alles in meinem ersten Post.
MacLeod
MacLeod 24.08.2020, aktualisiert am 25.08.2020 um 13:16:41 Uhr
Goto Top
Update: Jetzt wird es spannend: Ein Windows 10 1507 kommt bei exakt gleicher GPO über die interne Adresse am Wsus an. Nun werde ich diesen Schrittweise upgraden.
Win 10 1511 - interne route
support-m
support-m 25.08.2020 um 14:08:59 Uhr
Goto Top
Hast du bei der GPO folgende Einstellungen gesetzt?
Keine Richtlinien für Updaterückstellung zulassen, durch die Windows Update überprüft wird
https://www.escde.net/blog/windows-update-richtlinien-und-dual-scan
https://getadmx.com/?Category=Windows_10_2016&Policy=Microsoft.Polic ...
und
Keine Verbindung mit Windows Update-Internetadressen herstellen
https://getadmx.com/?Category=Windows_10_2016&Policy=Microsoft.Polic ...

Windows 10 zieht sonst trotz WSUS Konfiguration Updates über Microsoft.

MfG
MacLeod
MacLeod 25.08.2020 um 15:28:13 Uhr
Goto Top
Vielen Dank
Das könnte eventuell am Problem beteiligt sein. Um 100% sicher zu gehen werde ich den Testclient weiter schrittweise upgraden und berichten. Es sollte ja dann beim Schritt von 1603 auf 1607 auftreten.