bigthe

Hallo Zusammen, ich weiss nicht ob es der Neustart war den unsere Server heute aufgrund der Crowdstrike Geschichte bekommen haben oder ob es an der GPO liegt die mir @Sunny61 empfohlen hatte und ich umgesetzt hab aber nun melden mir die 2016er Server plötzlich nicht mehr 100% sondern den tatsächlichen Status! Yuhu! Danke an alle für eure Hilfe und das teilen eures Wissens! LG und ein schönes Wochenende.

Dein Vorschlag mit der GPO hab ich schon umgesetzt :) .Bzw hab mich dazu nochmal belesen, dass wird oft empfohlen auch bei dem Problem was ich habe das in der WSUS Konsole das die meisten 2016er immer 100% anzeigen. Eventuell hat das schon geholfen? Naja den Rest werde ich dann stück für stück umsetzen. Eventuell bau ich mir ein Skript und lass das per GPO verteilen. Es wird aufjedenfall umgesetzt und ich halte dich/euch auf dem laufenden. Das die Server lokal etwas konfiguriert haben, hatte ich stichprobenweise geprüft und da war nix zu finden. Vielen dank erstmal @cj_berlin sry das ich nochmal Frage aber bitte stell mir doch dein PS Skript zur Verfügung. LG

Sry Missverständnis. Die Kollegen meinte das eine VM ohne SYSPREP in einer Domänen gar nicht funktionieren würde, wegen Domain ID etc. Also ich könnte das wohl ausschliessen das der SYSPREP eventuell vergessen wurde. In meiner WSUS Konsole sind leider ca. 90% der 2016er immer auf 100% Die SUSID aus dem 2016er Template ist nicht in der WSUS Datenbank enthalten, habe das gerade überprüft. 1. Also wäre jetzt das vorgehen auf allen 2016er in der Registry das Windows Update zu löschen 2. Die Server aus der WSUS Konsole entfernen 3. DB kann ich mittels meines Skriptes bereinigen 4. Auf dem Server den Softwaredistributions Ordner löschen 5. Server wieder mit detect now etc wieder zum WSUS hinzufügen. 6. Abwarten :)

Das hatte ich ebenfalls vermutet. Auf meine Nachfrage bei Kollegen und Vorgesetzten gab es dazu nur Schulterzucken bzw. die Aussage das das in einer Domänenumgebung sowas nicht möglich wäre weil es dann noch diverse andere Probleme geben würde. Mit meinem Skript oben hatte ich das auf eigentlich jedem 2016er ausgeführt. Das Template wird nicht weiter verwendet aktuell haben wir ein 2022er Template im Einsatz. Das ist ein richtig guter Tipp! Das werde ich direkt mal versuchen. Danke. Wenn du das empfiehlst werde ich das natürlich sofort umsetzen :). Solche Tipps sind Gold wert für mich. Dennoch verstehe ich nicht wie manche 2016er Server automatisch ein Update installiert haben. Auch verstehe ich nicht wie es sein kann das nur teilweise das passiert ist und nicht bei allen in der Phase 1 zb. Oder das nur manche Server den reboot gefahren haben und das dies nicht im Monitoring aufgetaucht ist. Das ist irgendwie merkwürdig.

Hallo Sunny, ich weiss es auch nicht. es gibt 2 2016er Server die ich egal wie nicht in die Console bekomme. Der Vorgesetzte meinte auch mal das etwas an den 2016er Template sein könnte, ist sich aber nicht sicher. Absolut. Ich kann diese Verhalten auch nicht nachvollziehen, zumal es den Monat davor absolut Fehlerfrei lief. Ok verstehe. Da muss ich dort ansetzen.

Hallo Sunny, danke für diese Lösung! Ich muss kurz etwas ausholen... Ich bin neu in diesem Unternehmen. Vorher wurde jeden Monat manuell gepacht von den Kollegen. Dann habe ich vor mehr als 2 Monaten das ganze wie beschrieben automatisiert. Letzten Monat lief das perfekt durch ohne Probleme, klar hat man immer wieder unter den 2016er Einzelfälle. Die Server zu WSUS Console neu hinzugefügt hatte ich schon mehrfach auf diese Art: Stop-Service -Name BITS, wuauserv -Force # Wenn Dienst nicht stoppen will takskill ausführen Remove-ItemProperty -Name AccountDomainSid, PingID, SusClientId, SusClientIDValidation -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\ -ErrorAction SilentlyContinue Remove-Item "$env:SystemRoot\SoftwareDistribution\" -Recurse -Force -ErrorAction SilentlyContinue Start-Service -Name BITS, wuauserv wuauclt /resetauthorization /detectnow (New-Object -ComObject Microsoft.Update.AutoUpdate).DetectNow() Heute habe ich nochmals mir Zeit genommen und bin alle 2016 Server durchgegangen. Es ist etwas merkwürdig. Ca. 80% haben das Update erhalten am Montag aber keine Neustart (einige davon auch zu einer unplanmässigen Zeit). 10% Haben Updates erhalten und einen Neustart (interessant ist dabei auch das unser Monitoring nicht angeschlagen hat!). 10% haben weder Update noch einen Neustart durchgeführt. In der WSUS Console werden mir die 2016er zu 90% fehlerhaft angezeigt. Also im WSUS wird angegeben das diese Server kein Update benötigen, auf dem Server wird aber ein Update benötigt. Ich habe schon einige WSUSs gemacht aber sowas noch nicht erlebt. Ist das Sabotage? Das Verhalten des Systems kommt mir unwillkürlich vor. LG Robin Hallo, könntest du mir bitte diese PS Skript zur Verfügung stellen? Mit VBS kenne ich mich überhaupt nicht aus. LG

Die Windows 2016er haben die Option mit den unterschiedlichen Wochen nicht und somit wird dann jeden Montag die Updates installiert? Diese Option kam erst mit 2019. Aber das ist nur eine Vermutung eigentlich haben wir ja das aktuelle Policy Set auf dem Domänencontroller. Updates wurden planmässig zu der konfigurierten Uhrzeit installiert nur eben zum falschen Montag. Wie stehts du zu inplace Upgrade? Das wollte ich sowieso mal Fragen. Grundsätzlich rät ja jeder davon ab aber warum gibt es dann diese Option?

hahahah, ja da hast du wohl recht, heute schaffe ich das nicht mehr ca. 45 Server abzulösen. Hast du noch eine andere Idee dazu? LG

Hallo Zusammen, ich habe mal eine Frage zu folgendem Sachverhalt. Mittels WSUS 2019 und mehreren GPOs lasse ich zu unterschiedlichen Tagen und Uhrzeiten, automatisch Updates installieren. Es sind unterschiedliche OS Varianten von Windows Server 2016-2022 im Einsatz. Bei den 19 und 22 Varianten klappt alles reibungslos wie konfiguriert. Bei den 2016er die installieren jeden Montag obwohl konfiguriert ist jeden 4. Montag. Interessant ist auch das nicht alle 2016er Server automatisch neu starten, nachdem sie das Update erhalten haben. Ich habe hier mal ein Beispiel hinzugefügt. Man sieht das die GPO richtig beim Server ankommt. Dennoch wurde am 15.07 auf den 2016er Server das Update am 15.07 installiert obwohl die erst hätte am 22.07. passieren sollen. Kennt jemand das Problem? Was wäre hierfür die Lösung? LG

Hallo Zusammen, ich hatte letzte Woche die Lösung und zwar nehme ich ein Domänen Zertifikat, dann muss ich nur die Root CA den DMZ Servern mitgeben. Das Domänen Zertifikat kann ich leicht erneuern. Die Root CA ist ja etwas länger gültig. LG

Ich bin ein Freund der Automatisierung. Ich muss mal mit dem Vorgesetzten reden, noch bin ich nicht lange genug in der Firma um das einschätzen zu können ob die Server in der DMZ wirklich so streng getrennt sein müssen. Eventuell wäre es eine Möglichkeit diese mittels proxy(load balancer und LDAPs zu verbinden. Dann hätte ich dieses Problem gar nicht. Die andere Lösung das Zertifikat eben länger auszustellen fände ich auch erstmal zum Übergang die richtige. Eventuell klärt sich alles oder eben nicht dann muss ich dokumnetieren und alle Jahre wieder ran, was ich nicht so cool finden würde. Vielen Dank fürs zuhören und eure Tipps :)

Mit angepasster Host Datei läuft es, thx :) Was ich nicht so elegant finde ist das das Zertifikat nach 1 Jahr abläuft. Das hiesse das ich allen 12 Servern jedes Jahr ein neues Zertifikat zuweisen müsste. Das hatte ich auch überlegt aber wegen 12 Servern und es müsste überhaupt erstmal eine DNS Zone eingerichtet werden. Aktuell stehen alle Server als Standalone in workgroups

Hallo Zusammen, es handelt sich um 12 Server in der DMZ diese sind nicht verbunden mit dem DNS und nutzen einen öffentlichen DNS. Bin neu in der Firma und kannte das so auch nicht. Wäre es eventuell sinnvoller mit einen Load Balancer zu arbeiten und über LDAPs die Server mit dem AD/DNS zu verbinden?

Hallo Zusammen, ich habe einen WSUS umgestellt auf SSL. Funktioniert auch mit allen Servern innerhalb der Domäne. Der WSUS ist in der Domäne Mit den Servern in der DMZ gibt es leider Probleme. Ich habe das Self Signed Certificate was ich auf dem WSUS für SSL erstellt habe auf den Servern in der DMZ in die Ordner "Trusted Root Certificate Authority" und "Trusted Publishers" installiert. Dennoch scheint es Zertifikatsprobleme zu geben. 0x800b010f dieser Fehler wirft das Update. DNS funktioniert leider bei uns in der DMZ nicht. Das zertifikat ist auf FQDN augestellt, weshalb ich denke das es damit Probleme gibt. Gibt es eine Möglichkeit den Servern in der DMZ den FQDN vom WSUS mitzuteilen? Known Hosts zb? Wie würdet ihr hier vorgehen? Ich würde mich über Ratschläge/Tipps freuen. Vielen Dank.

Um genau zu sein war es das ARP Caching durch CISCO Switches verursacht. Auf einigen CISCO Switches war das sog. IPDT aktiviert. Auf den Switches konnte ich mittels "ip device tracking probe delay <seconds>" und 10 Sekunden das verzögern das es keinen Konflikt mit Windows DAD gibt. Eventuell werden wir später das IPDT komplett ausschalten.

Das war es. Doppeltes ARP. Problem gelöst.

Es sind Windows Clients. Das Gerät mit der IP ist eine von mir erstellte VM in einem Scope um das Problem zu analysieren.

Welche Infos benötigst du? Nein, die WLAN scopes sind nicht betroffen. Die lease time zu verändern wird das Problem leider nicht lösen.

Naja dann laufen wir in Gefahr keine freien IPs zu haben. Weil immer mehr Bad adresses dazu kommen. Klar die löschen sich auch nach der lease time von 8 Tagen. Das Problem ist aber nicht das, sondern warum kommen die Bad adresses. In einem 22er Netz haben wir nach ca. 2 Wochen ca. 60 Bad adresses. Jeder Tipp dazu wäre ich sehr dankbar. LG und einen schönen Abend euch.

Händisch die Bad Adresses aus der DHCP Konsole bzw den Scopes gelöscht

Richtig, sind beide so konfiguriert.

Hallo Norbert, Konflikterkennungsversuche ist auf 1 gestellt. Die Logs sind allerdings zu gross um sie hier hochzuladen, deswegen habe ich nur den Auszug, was mir auffiel, eingestellt. Die Leases sind default auf 8 Tage gestellt. Es sind ziemlich grosses Scopes und wir laufen auch nicht in Engpässe, wenn wir alle zwei Wochen manuell löschen. Ohne Change kann ich das auch ohne weiteres nicht ändern.

Hallo, das würde in meinem Fall über Rogue Server bzw. Wireshark auffallen, das es mehrere DHCP Server im Netz gibt.

Guten Morgen in die Runde, ich hoffe ihr hattet ein paar angenehme Feiertage und es geht euch gut. Ich bin seit ein paar Monaten in einer neuen Firma und habe dort eine Aufgabe zugewiesen bekommen. Und zwar geht es um DHCP Bad Adresses. Wir haben aktuell zwei DHCP Server im Failover konfiguriert. Diese schauen auf ca. 60 verschiedenen Scopes. Wir haben seit 4 Wochen nun dieses Bad Adress Problem auf 8 dieser Scopes. Konfiguration habe ich mit Angehangen Ich habe bereits in einem betroffenem Scope nach unautorisierten DHCP Servern gesucht und nur unsere zwei DHCP-Server gefunden, weiter habe ich mit Wireshark im betroffenem Scope die NIC überprüft und das Verhalten bei IP /release und /renew und auch nichts ungewöhnliches festgestellt (Abb. unten). Ich bin aktuell etwas ratlos und hoffe ihr könnte mir weiterhelfen. LG auszug DHCP Logs.txt

Hallo, danke für den Tipp. Ich habe es jetzt doch über eine für mich passende GPO geregelt. User Configuration\Administrative Template\System custom User interface und habe dort meinen Google Chrome mit Kioskmodus hinterlegt. Soweit so gut. Wenn Benutzer zb. mit ALT+F4 Google schließen, dann haben diese einen schwarzen Bildschirm. In diesem Falle suche ich eine GPO die Windows Neustartet oder abmeldet, wenn der Benutzer die Anwendung schließen sollte.