Sunny61

Überrascht dich das? Ist der gleiche Fehler wie beim Update. Hast du denn das mit DISM nochmal versucht oder willst Du gleich neu installieren?

Welche der aufgeführten .Net Framework Versionen hast Du denn bereits installiert? Du kannst natürlich auch mal versuchen Windows zu reparieren: https://learn.microsoft.com/de-de/windows-hardware/manufacture/desktop/repair-a-windows-image Wenn Du noch einen laufenden Windows Server 2019 hast, kannst Du via \\name2019funktioniert\c$\windows das funktionierende laufende Windows einbinden und hoffen dass es klappt. Ansonsten Windows neu installieren.

Hast Du das hier schon probiert? In einer Admin Commandline das hier eingeben: dism /online /cleanup-image /startcomponentcleanup Und anschließend neu starten und wieder probieren.

Und an was genau hat es denn gelegen? Lass uns hier nicht ohne Wissen zurück. ;)

Habe ich tatsächlich auch schon anders gehabt, deshalb der Hinweis.

Neben den anderen Vorschlägen kannst Du auch mal in GPEDIT.MSC auf dem Server nachsehen ob der WSUS darüber eingetragen wurde. Weshalb will man denn einen WSUS entlasten? Habt ihr über halbe Million Clients/Server die auf den WSUS zugreifen?

Dann nimm doch einfach mal eine Entwicklungsumgebung, entweder die ISE oder Visual Studio Code mit den passenden AddOns. Vermutlich fehlt das wichtigste, das AD. In welcher PS führst Du das Script aus? Auf einem normalen Client/Server oder auf einem DC in der PS für das AD?

Dafür ist ein Dom Admin das falsche Userobjekt. Leg dir dafür einen Testuser an. Und ja, das ist verwerflich, sowas macht man nicht.

Versuch es doch mal einfach, den Teil des New-ADUser in ein Script packen und aufrufen, wird das ausgeführt? Auf die Art kann man sich langsam vortasten und Fehler eingrenzen.

Man kann ein neues Outlook Profil anlegen und auch ein neues Benutzerprofil ausprobieren, wenn es mit dem Outlook Profil nicht hilft. BTW: Weshalb hat der Domain Admin auf dem RDS ein Outlook Konto?

Wähle Aktualisieren, alles andere fällt dir auf die Füße. Ab- und angemeldet hat sich der User? Liegt das Userobjekt auch im Verwaltungsbereich des GPO? Wo die Gruppe liegt ist dabei egal. Alternativ kann auch ein Reboot nicht schaden. Dürfen denn die Computerobjekte das GPO auch lesen? Siehe: https://www.gruppenrichtlinien.de/artikel/sicherheitsfilterung-neu-erfunden-ms16-072-patchday-14062016

Der BITS konnte und kann immer noch, z.B. die Windows Updates, holen. Dabei wird AFAIK komprimiert und ein Teil (10%) der LINK-Geschwindigkeit benutzt. Die Geschwindigkeit kann man auch via GPO konfiguriereb bzw. einschränken. In W10 wird der BITS in Sachen Windows Update über die Übermittlungsoptimierung gesteuert, die Einstellung 100 sorgt dafür dass alles über den BITS geht. Und wie @daabm angemerkt hat, gibt es evtl. 2 Policies mit unterschiedlichen Settings. Zusätzlich kann man mit Hilfe des BITS und der PS Dateien auf die Clients bringen. Das hat den Charme es läuft im Hintergrund ab und stört nicht so sehr wie andersrum.

SetACL von Helge Klein benutzen, dann geht das in einem Aufwasch. https://helgeklein.com/setacl/examples/managing-file-system-permissions-with-setacl-exe/ SetACL.exe -on "Pfad_zum_Ordner" -ot file -actn setprot -op "dacl:np;sacl:nc" -rec cont_obj -actn setowner -ownr "n:domain1\user1"

LESEN: dir /AH

In einer Admin Commandline: dir /AH Dann siehst Du schon mal $Recycle.Bin, dann je nach User weiter hangeln und mit takeown oder SetACL (von Helge Klein) den Besitz übernehmen und löschen.

Danke für die Rückmeldung. ;) In https://www.privacy-handbuch.de/handbuch_21w1.htm wird empfohlen das media.peerconnection.enabled auf true zu setzen.

Kann das etwas damit zu tun haben? https://support.mozilla.org/de/kb/privacy-preserving-attribution?as=u&utm_source=inproduct

Jepp, so ungefähr. GPEDIT.MSC nicht vergessen.

Doch, SYSPREP ist in der Domäne möglich. Fast sehr gut gewesen, nur lösche ich bei sowas den kompletten Registry Zweig, das wird sowieso alles neu erstellt, also weg damit. Glaub ich dir, ich kontrolliere das in der WSUS-Konsole, da sieht man sofort wer noch einen Reboot möchte und wer in Ordnung ist. ;) Schau auch über GPEDIT.MSC in den lokalen Richtlinien nach, manchmal findet man was. ;) EDIT: Alternativ kann man sich auch mit Ansible beschäftigen. ;)

Hmm, es könnte natürlich sein, dass das Template nicht mit SYSPREP bearbeitet wurde, dann hast Du u.U. eine SUSClientID drin, die es schon öfter gibt. Der Server kommt dann nicht als neuer Client in die Konsole, sondern ist schon mit einem anderen Namen da und aktualisiert nur den Statusbericht. Falls das so ist, sieht man das in der Konsole nur an der Uhrzeit an der sich der Server zuletzt gemeldet bzw. einen Bericht abgeliefert hat. Als Alternative kannst Du die SUSClientID (aus dem Template) auch in der SQL Serverdatenbank des WSUS suchen. In der Tabelle tbComputerTarget im Feld ComputerID findest Du sie, merk dir die dazugehörige TargetID. Dort dann den Datensatz löschen und auf der Maschine diesen Zweig in der Registry löschen: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate Wirklich den TEil komplett löschen, nicht nur Teile. In der Tabelle tbComputerTargetDetail suchst Du dann die TargetID und löscht auch diesen Datensatz. Zusätzlich auch noch in der Registry überprüfen ob auch wirklich alles richtig drin steht, nicht dass es noch irgendeine alte GPO irgendwo gibt mit einem falschen Servernamen. Starte auch GPEDIT.MSC und überprüfe den Teil in Windows Update manuell. Hatte ich auch schon dass hier ein Server drin stand, den es nicht mehr gab. HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate %windir%\softwaredistribution noch löschen und den Server neu starten. Nach dem Neustart in einer Admin Commandline nur wuauclt /resetauthorization /detectnow mehrmals laufen lassen und zum Schluß noch ein wuauclt /reportnow. Wenn die Gruppe Phase1 existiert, dann sollte der Server nach 5-10 Minuten in der Gruppe auftauchen. BTW: Wenn die SUSDB auf dem WSUS in der Windows Internal Database installiert ist, kommst Du mit Hilfe eines SQL Server Management Studios recht einfach rein. SSMS undbedingt als Admin starten und diesen Verbindungsstring verwenden: \\.\pipe\Microsoft##WID\tsql\query Windows-Authentifizierung verwenden. Download vom SSMS: https://learn.microsoft.com/de-de/sql/ssms/download-sql-server-management-studio-ssms?view=sql-server-ver15#available-languages EDIT: Das hier solltest Du auch noch auf Disabled setzen: https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policies.WindowsUpdate::DisableDualScan&Language=de-de

Weshalb muss man das so oft machen? Das läuft doch mittels GPO ganz von allein, maximal einmal manuell in die passende Gruppe aufnehmen, fertig. Sehr dubios, wir haben zur Zeit ~160 W2016 im Einsatz, ein paar W2022. Aber nie hatte ich solche Probleme mit der Installation von Updates. Evtl. liegts ja am GPO, zeig doch mal die Einstellungen komplett, Namen/Bezeichnungen kannst Du ja anonymisieren. Das einzige was manchmal vorkommt ist, dass ein Server keinen Reboot ausführen, obwohl es im GPO so konfiguriert ist. Manchmal weil noch jemand angemeldet ist (das ist dann auch korrekt), manchmal weiß man das nicht. Das betrifft allerdings nur 5-10 Server pro Patchday maximal. Einen Unterschied zwischen 2016 und 2022 kann ich an der Stelle nicht festellen. EDIT: Welche Updates werden denn als fehlerhaft auf dem WSUS angeziegt? .Net CUs oder Windows CUs? Der WSUS kann überhaupt nichts dafür, das liegt NUR an den Servern/Clients. BTW: Das von mir zitierte VB-Script liegt ist bei jeder Windows Server Installation dabei, die kann man sich an der Stelle ausleihen und ein klein wenig anpassen. ;)

Schau dir meine Lösung an: Ein VB-Script das von einer Batch zu einem geplanten Zeitpunkt aufgerufen werden kann. Natürlich müssen die Updates zu diesem Zeitpunkt auch für die Gruppe der Server freigegeben sein, aber grundsätzlich funktioniert das ganz wunderbar. Hier noch der Inhalt der Batch: REM Softwaredistribution leeren, zuerst Dienst WUAUSERV beenden, SoftwareDistribution leeren, Dienst wieder starten C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -Command Stop-Service "WUAUSERV" -Force C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -Command while ((Get-Service "WUAUSERV").Status -ne 'Stopped'){Sleep 1} timeout /T 5 /nobreak rd /s /q %windir%\softwaredistribution timeout /T 5 /nobreak net start wuauserv timeout /T 5 /nobreak REM Updates am WSUS antriggern wuauclt /resetauthorization /detectnow REM Sicherheitshalber 5 Sekunden warten timeout /T 5 /nobreak REM Updates am WSUS antriggern wuauclt /reportnow REM Sicherheitshalber 5 Sekunden warten timeout /T 5 /nobreak REM Das eigentliche Script starten c:\windows\system32\cscript.exe /nologo C:\_Install\WU\WUA_SearchDownloadInstall.vbs<c:\_Install\WU\input.txt Die Batch über einen geplanten Task aufrufen, am besten mit SYSTEM-Rechten, dann funktioniert das genau zum gewünschten Zeitpunkt. Wichtig ist z.B. das /resetauthorization /detectnow, damit wird der WSUS angetriggert und der Client erneuert/refresht seine Gruppenmitgliedschaft. Natürlich könnte man auch in der SQL DB vom WSUS den Server in die richtige Gruppe verschieben und danach erst das Sript laufen lassen. Anschließend wieder retour.

Vermutlich wäre es schneller und zielführender den Server neu zu machen und die Postfächer zu migrieren.

Und auch in der Exchange Powershell ausgeführt? Ganz sicher?

Starte den/die RDP-Server täglich neu durch und wenn sich jemand beschwert... :)