Sunny61

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.

vor 34 Minuten schrieb bigthe:

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.

Doch, SYSPREP ist in der Domäne möglich.

vor 34 Minuten schrieb bigthe:

Mit meinem Skript oben hatte ich das auf eigentlich jedem 2016er ausgeführt.

Fast sehr gut gewesen, nur lösche ich bei sowas den kompletten Registry Zweig, das wird sowieso alles neu erstellt, also weg damit.

vor 34 Minuten schrieb bigthe:

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.

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

vor 4 Stunden schrieb bigthe:

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.

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

vor 42 Minuten schrieb bigthe:

Die Server zu WSUS Console neu hinzugefügt hatte ich schon mehrfach auf diese Art:

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.

vor 42 Minuten schrieb bigthe:

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.

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?

vor 42 Minuten schrieb bigthe:

Ich habe schon einige WSUSs gemacht aber sowas noch nicht erlebt. Ist das Sabotage? Das Verhalten des Systems kommt mir unwillkürlich vor.

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

vor 16 Stunden schrieb bigthe:

Updates wurden planmässig zu der konfigurierten Uhrzeit installiert nur eben zum falschen Montag.

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.

vor 5 Stunden schrieb MHeiss2003:

Ja, Rechtsklick als Administrator habe ich gemacht.

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

vor 2 Stunden schrieb Mortifer:

das war es.. oh Gott, kleine Haken, große Wirkung.

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

vor 56 Minuten schrieb Mortifer:

Ich hab den Domain User in die lokale Gruppe der Administratoren auf dem Notebook genommen und trotzdem kommt die Mitteilung.

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.

vor 27 Minuten schrieb pischel:

Es ist noch gar nichts gemacht. der alte ist noch da.

Ich bin bei @Squire, Dienstleister einschalten.

vor 51 Minuten schrieb pischel:

Mir ist nur nicht klar mache ich das auf dem alten DC wo die zwei Rollen als Fehler angezeigt werden oder mach ich das vom neuen DC aus?

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?

vor 43 Minuten schrieb pischel:

also es würde dann so aussehen.

Auf dem neuen DC2 CMD ntdsutil

Dann roles eingeben.

Dann connections eingeben.

Dann connect to server alterServer

Dann q eingeben

wenn ich dann ? eingebe wird mir Move gar nicht angeboten.

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

vor 1 Stunde schrieb testperson:

Du meinst diese Liste: Security guidelines for system services in Windows Server 2016 | Microsoft Learn

 

Was aktuelleres und offizielles gibt es AFAIK nicht.

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

vor 2 Stunden schrieb wznutzer:

Druckspooler: Ist das (Printnightmare mal außen vor) ein generelles Sicherheitsproblem?

Weniger ist mehr. Es gab mal ein Excel Sheet von MS mit den Diensten, die man abschalten kann, finde ich auf die Schnelle nicht mehr.

Alternativ: https://www.der-windows-papst.de/2019/12/01/windows-server-unnoetige-dienste-abschalten/

https://www.der-windows-papst.de/2020/12/15/windows-server-unwichtige-dienste-abschalten/

https://gist.github.com/GavinEke/abfc2a547aea74b9d74a2c0c598f3fd7

Das muss natürlich jeder selbst entscheiden, welche Dienste er deaktiviert.

Warum sollte es nicht funktionieren? Es kann natürlich sein, das weiß ich aber nicht, dass der Essential immer wieder herunterfährt oder Fehlermeldungen produziert, wenn er nicht mehr Chef im Ring ist.

Hier gibt es ein paar Hinweise: https://www.andysblog.de/windows-active-directory-migration-von-windows-server-2012-essentials-zu-windows-server-2019-standard

Alternativ kannst Du das Upgrade ja vorher in einer Testumgebung ausprobieren.

vor 5 Stunden schrieb wznutzer:

Im Prinzip will ich mich vor dem Szenario schützen, dass im schlimmsten Fall der Anwender böswillig handelt oder seine Zugangsdaten unvorsichtig weitergibt. Auch dann soll möglichst nichts passieren können.

Hatte ich doch im ersten Posting beschrieben, Account dauerhaft deaktivieren und nur aktivieren bei Benutzung. Es gibt auch Software, die während der Arbeit des DL/Externen alles aufzeichnet.

Zusätzlich zu den Hinweisen von Ja, alle 2 Tage die RD-Server in der Nacht neu starten. Dann sollten alle Sitzungen weg sein.

Anstatt Admin oder System wäre es besser, den angemeldeten User zu verwenden:

%userdomain%\%username%

Was ist das für ein Script? Batch, VB oder Powershell? Wenn PS, wie genau sieht der Aufruf des Scriptes aus?

vor 1 Stunde schrieb zahni:

Teams-Addin Proxies mit Kerberos SSO nicht unterstützt, bleibt ein Geheimnis von Microsoft. Teams selbst kann es.

Unterschiedlich Produktgruppen bei MS, die nicht miteinander sprechen. ;)