Sunny61

mstsc /console sollte helfen.

Das liest sich auch nicht gut, da fehlen wohl die ganzen CUs: https://sqlserverbuilds.blogspot.com/2017/01/sql-server-2017-versions.html Evtl. ist das ja etwas für die Zukunft. Ab 5 Clients und 1 Server rentiert sich das für mich auf jeden Fall.

Was ist der Unterschied zwischen den Ordnern? Schau doch mal die Freigabeberechtigungen der Ordner an.

Wenn da ein SQL Server drauf läuft und der Server schon seit Ende 2019 nicht aktualisiert ist, sieht der SQL Server vermutlich nicht besser aus, welche Version ist denn davon installiert? Welche Build? Kriegt man mit SELECT @@Version in einer leeren Abfrage im SSMS raus. Dann am besten gleich einen aktuellen SQL Server installieren und die Datenbank moven. Mit dem Hersteller sprechen auf welche Ebene die Kompatibilitätsstufe für die Datenbank gesetzt werden kann/soll.

Wenn wir nichts von der VM wissen, können wir auch keinen Guide angeben. ;) Neue VM mit aktuellem OS aufsetzen, Windows Updates installieren und dann die Anwendung migrieren. ;) Habt ihr einen WSUS im Einsatz?

Ein Inplace Upgrade würde ich persönlich nicht machen, vermutlich geht es gar nicht, weil auch die neue Installation eine Basis braucht, die du nicht liefern kannst. Mach es neu, dann hast Du Ruhe.

Sicher? Start > Ausführen cmd [ENTER] > ver [ENTER]. Dann ist der Server auf dem Stand aus September 2019: https://support.microsoft.com/de-de/topic/10-september-2019-kb4512578-betriebssystembuild-17763-737-695c1350-93dc-40dc-72c3-5af9743c6340 Wie schafft man es 4 Jahre lang keine Updates zu installieren? Wie sieht denn dann der SQL Server aus? Du kannst es einmal mit einem Update aus 2019 probieren, evtl. geht es damit weiter, du musst dir eines suchen: https://catalog.update.microsoft.com/Search.aspx?q=windows+server+2019+kumulatives+update

Du kannst jetzt nochmal probieren den Defender temporär mit der Powershell zu deaktivieren und manuell ein Update installieren. Set-MpPreference -DisableRealtimeMonitoring $true Ansonsten, falls der Tipp von @Alith Anar nicht hilft, den Server neu aufsetzen und den SQL zu moven. Den Umzug gleich dokumentieren, dann ist es fürs nächste mal einfacher. ;) BTW: Welche esakte Build hat der Server 2019 jetzt?

Probier doch bitte die hier gen. Schritte aus: https://www.windows-faq.de/2023/04/05/windows-fehler-0x800706be/ Nach Möglichkeit zuerst einen Neustart durchführen, erst dann loslogen. @q617 ist der Forentroll, einfach igonieren.

Probier es aus, das wird AFAIK ignoriert. EDIT: Du kannst den Stichtag ja auch mal auf einen Samstag legen, den Rechner dann erst am Montag einschalten. Evtl. wird ja gleich vor oder kurz nach dem Login neu gestartet.

Solltest Du mehr Software auf dem Weg verteilen, bietet sich auch der WSUS in Kombination mit dem WSUS Package Publisher an, falls ein WSUS bereits existiert.

Kannst Du denn das Paket manuell auf einem Testrechner installieren? msiexec /i Pfad_zum_MSI

SSM mittels Rechtsklick > Ausführen als Administrator starten.

Dann probier das mit dem Stichtag, da kann man auch eine Uhrzeit angeben:

Als der betroffene User in einer cmd ein whoami /groups aufrufen, was wird ausgegeben?

Dann dürften diese MA doch eigentlich keinen PC bedienen, wenn sie schon das nicht schaffen. Stimmt so nicht, es gibt genügend Umgebungen in denen das funktioniert, eine davon ist unsere. Es liegt nicht an der Technik, bei euch versagt der Mensch. Und noch eine Korrektur: Der WSUS installiert nichts, gar nichts, der Client holt vom WSUS ab und der Client installiert. Bezüglich ohne Userinteraktion, probier das doch einfach mal mit ein paar Testclients in einer Testgruppe. Wenn Du ein Update genehmigst, kannst Du dafür auch einen Stichtag festlegen, an dem wird das Update installiert. Und vermutlich wird auch neu gestartet, so war es zu Zeiten von W7 noch. Da gab es keinen Hinweis auf den Neustart, das hatten nicht alle so gewollt.

Man sieht ja im WSUS welcher Rechner nach einem Reboot verlangt, bei uns hat es schon geholfen, Spezialisten gezielt anzusprechen, danach kam das nicht mehr vor. ;)

Evtl. ist dort ja UAC deaktiviert. :)

Funktioniert bei uns im großen und ganzen recht gut. Am besten auch den Usern mitteilen dass z.B. heute Updates freigegeben worden sind und man bitte beim Herunterfahren an die Updates denken soll. Hab ich auch noch nicht probiert, aber wird vermutlich nicht anders sein, als bei W7 oder XP. Harter Neustart. ;)

Weißt Du seit wann schon? Mir ist es tatsächlich erst dieses Jahr aufgefallen. Sorry, Arbeitszeit ist die Nutzungszeit. ;) Ist bei uns exakt so im Einsatz. Windows Updates beim Shutdown dürften die User schon selbst hinkriegen, ist normalerweise nur einmal im Monat. ;)

Nein, nein und nochmal nein. Hier nichts einstellen, da klappt dann nichts mehr. MSFT geht davon aus, dass die Rechner immer alle eingeschaltet sind und sie deshalb die Updates außerhalb einer festgelegten Nutzungszeit installieren können. Also musst Du noch eine Nutzungszeit konfigurieren. Und eine Arbeitszeit von Anfang bis Ende. ;) Wenn Du dir die Description zu dieser Einstellungen anschaust, wirst Du feststellen, dass die gar nicht mehr wirkt. ;) Das hier hab ich noch im Angebot: Warnbenachrichtigungszeitplan für den automatischen Neustart zur Updateinstallation konfigurieren Aktiviert Geben Sie den Zeitraum für Warn-/Erinnerungsbenachrichtigungen über den automatischen Neustart an: Erinnerung (in Stunden): 4 Geben Sie den Zeitraum für Warnbenachrichtigungen über einen bevorstehenden automatischen Neustart an: Warnung (Min.): 30 Du könntest die Rechner in der Nacht aufwecken und dann die Updates installieren lassen. Anschließend wieder herunterfahren. Das ist für Workstations natürlich doof, für Benutzer von Mobil Devices ist es schöner die Auswahl zu haben, ansonsten sitzt man ein paar Minuten da und wartet auf das Ende der Installation. BTW: Wenn ich das jetzt richtig mitbekommen habe, gibt es fast keinen Unterschied mehr, zwischen Herunterfahren und Aktualisieren und Neustart und Aktualisieren. Beide male wird neu gestartet, beim Herunterfahren wird auch fast bis zum Login gestartet um dann wieder abzuschalten. Ist das noch jemandem aufgefallen?

Das ist erst dann so richtig sinnvoll, wenn Du dir ein passendes Script mit Abfrage der variablen Daten erstellst. Viel lässt sich hart voreinstellen.

Me too. ;) @Nobbyaushb Die Updates werden für eine Gruppe im WSUS freigegeben, ein paar Testserver in die Gruppe verschoben. Die Standard GPO Einstellung heißt 03 Uhr Installation und genau das passiert in der Nacht um 3 Uhr. Wenn niemand angemeldet ist, wird anschließend neu gestartet und fertig ist die Laube. Am nächsten Tag der nächste Schwung. @brickmaker Mach auf dem betroffenen Server eine Admin Commndline auf und gib das hier ein: wuauclt /reportnow gefolgt von einem [ENTER]. Nach 5 Minuten die WSUS-Konsole aktualisieren, jetzt sollte sie grün sein. Notfalls den Befehl wiederholen und/oder auch mal auf Updates suchen klicken. Manchmal braucht der Server etwas Zeit um den Status an den WSUS zu melden.

Lässt sich zeitlich eingrenzen, wann das angefangen hat? Hast Du mehrere RDP-Server zur Verfügung? Falls ja, passiert das bei allen Servern? Welches OS haben die Server?

3 x Ex 2016 ebenfalls problemlos.