Sunny61

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... :)

Oje, soweit hab ich nicht geschaut. ;) Die rtf könnte sicherlich beim Erstellen einer Batch helfen. ;)

Gibt es immer noch im Download: https://www.microsoft.com/de-de/download/details.aspx?id=20934 Aber: Unterstützte Betriebssysteme Windows Vista, Windows XP

Aber weshalb war das aktiviert? In der Domain schaltet man so etwas doch per GPO ab, oder nicht?

Nimm das wieder zurück, das vergisst man schnell.

In der Zwischenzeit hättest Du es vermutlich schon zig mal erfolgreich ausgeführt, mach es oder lass es, aber frag nicht andauernd das gleiche.

Ich bin bei @Squire, Dienstleister einschalten.

Puh, du bist anstrengend. Auf dem neuen anmelden und dann die Befehle ausführen, Du willst die Roles auf den neuen sizen. Hast Du den alten schon abgeschaltet und vom Netz genommen?

Lies doch mal: In this example, we’ll seize the PDC Emulator to a domain controller called coho-chi-adc02. Type connect to server coho-chi-adc02 and press Enter. Und jetzt ersetzt Du den coho-chi-adc02 mit deinem neuen Servernamen, ok? Falls Du mit Englisch nicht klar kommst, nimm einen Übersetzungsdienst, deepl.com eignet sich dafür.

Du meldest dich auf dem neuen DC an und führst dort die Befehle in einer Admin CMD aus. Mit dem Tool ntdsutil macht man das so. Dein Server, auf den du dich verbindest, ist dann dieser hier: coho-chi-adc02

Ja, es gab aber auch mal ein Excel Sheet dazu. ;) Sollte ich es noch finden, häng ich es hier dran. ;)