Weingeist

Da kann ich nur beipflichten Mehrwert gibts ja nur beschränkt. Eigentlich vor allem wenn man von wenig funktionalen Änderungen/Upgrades profitiert. Sprich im Produktionsumfeld. Auch die Anzahl Arbeitsplätze ist entscheidend, je mehr man hat, desto mehr Zeit kann man ins zurechtbiegen investieren. Je weniger, desto eher sind die paar Kröten egal, der Stundenansatz aber nicht.

Habe mich mal an die Analyse der Files gemacht. Dazu habe ich insbesondere die aktualisierten Files von Oktober 2024 bis Mai 2025 uter die Lupe genommen sowie die Unterschiede zwischen Januar 2026 und Dezember 2025 als das Client-System aus dem Update flog. Was von den Fragen für mich (immer) noch übrigen bleibt: Was zu der enormen Anzahl Änderungen an Standardfiles geführt hat? Schnittstellenerweiterungen für KI? Sonstiges? Bugfixes durch KI? Welche KI-Funktionen tatsächlich externe Ressourcen nutzen. (Zu?) Schön wäre natürlich, wenn die verbliebenen KI-Funktionen unter Server bereits "trainierte" Daten umfasst welche "fix" auf dem System sind und somit keinerlei externe Abfragen stattfinden. Oder das Training nur lokal stattfindet (index). Falls es jemand interessiert, es gab für mich folgende Erkenntisse aus der File-Analyse. Besonders viel (sinnvolles) kam nicht bei raus, aber ein paar Dinge schon. Es wurden tatsächlich Änderungen an mehreren 10 tausend Files vorgenommen oder kamen neu dazu. Im Vergleich zu Server 2022 sind trotz 3 Jahre weniger Laufzeit rund 3x soviel Files betroffen seit der Veröffentlichung. Selbst wenn man doppelte Files (versch. Versionen), Grafiken, GPO-Files etc. rausstreicht sind es immer noch ein paar Tausend mehr betroffene exe/dll. Nicht wenige Systemfiles die auch unter 2022 ein Update bekommen haben, sind in 2025 etwas grösser als unter 2022 (2026-03). Erweiterung? Verbesserung? Der Anteil an Files mit offensichtlichem KI oder Recall Bezug ist deutlich tiefer als erwartet (Client wie Server). Scheinen zudem gut gekapselt zu sein (Components). Recall fehlt komplett in Server 2025. Das mache ich daran fest, dass Update-Files mit offensichtlichem Recall-Bezug ab 2026 in den Updates vollständig fehlen. KI kam quasi als Light-Version in Server rein. MS nennt sie Nudges. z.B. Paint, Editor, PrintScreen und die Suche/Index wurde beglückt. Ob nur die AppX oder auch die klassische, muss ich noch näher prüfen. Selbst 2022 hat wohl einen Teil der AI-Light-Version bekommen. Müsste vor allem die Suche/Index betreffen. Gibt zumindest ein paar Files dazu. Eine Copilot.exe kam ebenfalls in die Updates-Files von Server 2025 rein. Allerdings ohne viel Beigemüse. Was es bewirkt, weiss ich noch nicht. Der ganze AIX Stack fehlt nach wie vor in Server Ausstehend ist noch der Vergleich von Core und DesktopExperience und ob man DE (fast) auf Core-Niveau runterstrippen kann bis nur noch der Desktop ohne Startmenü etc. funktioniert (Hilfreich für klassiche Apps die GUI-Funktionen brauchen). Inbesondere wenn man das Strippen reversibel auslegen möchte, ist das erfahrungsgemäss aufwendig. Vorläufiges Fazit: KI dürfte sich in Server 2025 auf einzelne Funktionen in Apps sowie auf Suche/Index/Cortana beschränken, welches sich grösstenteils mit GPO's steuern lassen. Ein Einsatz für mich daher in Ordnung. Sofern man sich die teilweise etwas eigene Update-Problematik antun möchte. Beim Startmenü wirds auch kaum einen Rollback mehr geben auf die richtige gute 21H2 Variante (RDS). Cool wäre, wenn MS bei Gelegenheit mal ein klassiches SP oder ausserplanmässiges R2 raushauen würde. Wird Wunschdenken sein. Was bei Server 2025 nicht vorhanden ist, dürfte sich auf Windows 11 vermutlich schadlos mit dism aus einem Repo entfernen lassen. Wenn man Glück hat, fehlt es standardmässig bereits bei Enterprise/LTSC Builds. (Muss ich noch prüfen). Mal sehen wann der Moment kommt, wo ich mir das antun muss. Index/Cortana/Suche war schon unter den Vorgängern etwas undurchsichtig. Hier stören mich über alle Versionen hinweg die automatisch erstellten, nichtkonfigurierbaren Firewall-Regeln welche eine Kommunikation nach und von aussen bieten. Gilt auch für weiteren "SystemApp" und AppX Bloatware die sich wie die Karnickel vermehren. Auch bei Server mit DE. Allerdings ziehen bei Enterprise Versionen die GPO's wenn man Cloud-Einbezug oder Upload von Handschrifterkennung etc. verhindert bis jetzt zuverlässig. Test unter 2025 steht noch aus, denke MS hält sich aber daran.

Punkto Telemetrie, Updates: No Way. Ausser da wurde grundlegend etwas verändert, was ich mir nicht vorstellen kann. Heisst aber nicht, dass man nicht selber Gegensteuer geben kann. So wie Du das auch gemacht hast mit Edge. Mir geht solcher Kram aber auf die Eier. MS lässt sich diesbezüglich immer wieder was neues einfallen. Mit LTSC/Enterprise ist es weniger. I know. Manche Einstellungen brauchen unter Pro aber schon die Brechstange. Im Detail weiss ich es nimmer auswendig, ist schon eine Zeit her als ich das Verhalten sowie vorinstallierten Kram von Pro/Enterprise/IoT und den LTSC-Derivaten unter W10 verglichen habe. Auf alle Fälle hat sich Pro für mich disqualifiziert gehabt.

Bei Pro wundert mich das ehrlich gesagt nicht. Das ignoriert wie Home sehr gerne GPO's, welche MS am liebsten durchgesetzt hätte. Übrigens auch punkto Telemetrie-Daten. Im Grunde ist Pro nicht tauglich für Unternehmen. Der Name ist ver****e. Bei Enterprise-Editionen ziehen die GPO's normalerweise. Wenn nicht grad wieder die Bedeutung der eingestellten Werte umgestellt wird, funktioniert das auch (So wie das eine Zeitlang gefühlt jedes halbe Jahr bei den Updatediensten vorkam). Eigentlich richtig abartig was sich MS beim Thema AI erlaubt wenn man die ganzen erfolgreichen Datenabzüge sieht. Den Task hatte ich überlesen und nur die Updatedienste bemerkt. Sorry.

Gilt das für auch für Enterprise oder sind das Pro Versionen? Bei IoT habe ich - bis jetzt - dieses Verhalten nicht festgestellt. Werde das mal näher prüfen. Die Dinger werden aber normal nicht Zwangsbeglückt. Die übliche Vorgehensweise von MS ist bei vielen Zwangsbeglückungen mittels einem Task gelöst. Da würde ich als erstes ansetzen. Schauen was sich da allenfalls verändert hat. Also einerseits unter Edge und andernseit bei allem was nach Copilot, AI, Recall, Cortana oder Azure klingt.

Habe ich schon so interpretiert, aber hätte ja sein können, dass Du das MS-Marketinggeschwafel bezüglich von KI erstelltem Code näher geprüft hast. Da wird aus Spass dann schonmal Ernst. Termin passt auch ungefähr, damit es grad keine Frühgeburt mehr war. *rofl* Irgendwie fehlt mir noch die vernünftige Entscheidungsgrundlage. Kann mich noch jemand erleuchten?

Danke für die Antworten. Interessant, dass es wenig Probleme zu geben scheint. Ausser bei den DC's. Wobei ich da schon teilweise davon ausgehe, dass wohl irgendwelche Altlasten - von MS oder Eigenverursacht - zu den Problemen führen, wenn Neuinstallation - angeblich - funktionieren. @NorbertFe Updategrösse: Meinst wirklich, Vibecoding kann als Ursache herhalten? Wenn das von einem Monat auf den anderen passiert? Möglichkeiten sind bei dem Umfang ja beschränkt auf zusätzliche Module/Funktionalität oder Änderung von bestehenden. Für letzteres müsste bei gleicher Funktionalität ja fast die Hälfte der Files ausgetauscht worden sein was nur Sinn macht, wenn neue KI-Schnittstellen hinzugekommen wären. *schulterzuck* Daher würde es mich eben schon interessieren ob die Änderungen Standard-Files betreffen, weil KI-Schnittstellen hinzugekommen sind und somit die Standard-Angriffsfläche massiv vergrössert wird, oder ob das Dinge sind - mutmasslich KI-Module -, welche zusätzlich installiert werden können, aber nicht müssen, die Updates aber natürlich mitgeschleppt werden. Irgendwie seltsam, dass das noch keine grösser Firma geprüft zu haben scheint und/oder keine Admin dies dann in nem Blog veröffentlicht hat. Oder ich bin unfähig, es zu finden. Das beziehst Du auf zwei Single-Host wo man selbst Live-Mig zum laufen bringt, statt einem Workgroup-Cluster oder? Jo sehe ich auch so.

Da war doch mal was mit zerschossenen User-Profilen mit Sysprep. Manche habens dann weggelassen und vergessen manuell nachzubearbeiten. Im Grunde nicht verkehrt wenn das (wieder?) besser geprüft wird. Ist ja auch ein gewisses Sicherheitsrisiko. Hat jemand MS-Kontakte der mal klären könnte, was den nun genau bewirkt hat, dass die Updates bei Server 2025 so gewaltig angewachsen sind? Anfangs (Mai 25, ca. 4.4GB) wurde das ja wegen den KI-Modulen auf Windows 11 geschoben (da gleiches Update). Wenn nun aber mittlerweile auch 2GB für den Server fällig sind, würde mich das schon immer noch interessieren ob das auch KI ist oder eben doch Härtungen welche dein Einzug in die Vorgänger nicht geschafft haben.

Bestätigt zumindest, dass die Anwendung für die KI-Auswertung fehlt. Offen ist, ob die KI-Komponenten tatsächlich fehlen oder eben nur die Auswertung. Und im Umkehrschluss, sollten sie da sein, diese aufgrund der viel zu kurzen Entwicklungszeit ein Sicherheits-Risiko bzw. eine massiv erhöhte Angriffsfläche/Möglichkeiten darstellen. Daher frage ich mich, ob ich mich aufgrund der Update-Grösse verrenne, ob allenfalls etwas dran ist oder sogar das Gegenteil der Fall ist, und eher Komponenten gehärtet wurden, diese aber nicht in Vorgängerversionen einfliessen. Gegen letzteres spricht, dass damals eilligst KI-Komponenten aus dem GA-Release entfernt wurden. Leider konnte ich nicht wirklich etwas (sinnvolles) in Erfahrung bringen mir selber fehlen Mittel eingehend zu prüfen an was nun genau herumgeschraubt wurde. OK. Wäre dann allenfalls eine unsupportete Variante die aber trotzdem funktionieren könnte. @Marco31 Gut zu hören.

Cluster: OK. Versuche die jeweils zu vermeiden. Auch separate separate Infrastruktur nur fürs Anmelden. Mal genauer anschauen wie das Workgroup funktioniert. Danke für den Hint. AI: OK. Von der Updategrösse her müsste da schon was reingekommen sein oder? Die Frage ist nur ob es aktiv ist oder "nur" Schnittstellen für später. "Nur" weil die ja dann theoretisch angesprochen werden könnten von z.B. Malware. Oder bin ich falsch? NVMe: Alles was der Latenz hilft, hilft eigentlich direkt sehr spürbar der Performance mit SP. Auch wenn ich da erst Benchmarks gesehen habe (weils eben 2025 ist und mir der Nerv bis jetzt immer noch fehlte, aber ist ja wieder ein Jahr vergangen.)

Danke für die Rückmeldung. Also in den letzten Monaten kein Ärger mit den Updates? Wie steht ihr zu den Sicherheitsbedenken bei den Member? KI Gedöhns gefunden, nur bei Desktop Experience oder gar nix da? Netzwerkänderung bin ich auf eine "Ente" reingefallen wo Neuerungen für 2025 in einem Blog-Eintrag angezeigt wurden. War wohl irgend ein KI-Rülpser. Die Änderungen die ich meinte, kamen bereits vorher *hust* Sorry für die Verwirrung. Bleiben für mich die Storage Verbesserungen und die AD-Less Live Migration.

Hallo Leute, Habe drei Anliegen zu Server 2025 1. Mich würde interessieren ob 2025 insbesondere im Zusammenhang mit Updates - tatsächlich so schwierig im täglichen Betrieb ist oder ob das einfach überproportional in Blogs und Foren aufschlägt. AD ist mir soweit klar (auch wenn ich mich noch nicht eingelesen habe warum). Sprich hat schon jemand hier geswitched und gut Erfahrungen gemacht? 2. Dann würde mich interessieren inwiefern KI eingezogen hat obwohl es das eigentlich nicht hat. 3. Wie sieht es mit HyperV aus? Laufen die Änderungen im Netzwerkstack vernünftig? Livemigration mit unabhängigen, nicht AD-gekoppelten Hosts? Hintergrund (wen es interessiert, sonst ignorieren) Zu 1: Bei 2022 waren meine Probleme der letzten Jahre eigentlich nur Eigenverschulden und nicht jene von MS. Hatte seit 2022 nie Ärger mit Updates. Exchange habe ich nicht. Nur mit der Vorbereitung auf die Updates. Das ist aber nur teilweise die Schuld von MS, weil deren Standardeinstellungen einfach seit Jahrzehnten Schrott sind. Sprich allen Ärger hätte ich vermieden, wenn ich so manches von Anfang an umgesetzt hätte wie man es seit 20 Jahren könnte. Insbesondere bezüglich FQDN statt Namen bei Printer, Netzwerkshares, Isnt. von Druckertreiber durch User. Da ich alles lange vor dem Force durch die Updates umgesetzt habe, dadurch alles gut mit Downtimes planbar war, Testläufe machen konnte etc., liefen die Umgebungen alle munter weiter als gefühlt das ganze Netz während Monaten auf MS rumhackte. Worauf ich hinaus will: Liegt der Ärger mit 2025 wirklich an MS oder einfach an Fehlkonfiguration, nichtumsetzen von Empfehlungen und nach wie vor grottigen Standardeinstellungen die einem dann beim Hardening/forcen von Sicherheitseinstellungen durch die Updates von MS auf die Füsse fallen oder sind die Updates bei 2025 Schrott? Zu 2: Trotz der Abkopplung der Updates vom Client OS sind die Updates immer noch sehr gross. 2022 hat nach nun 4.5 Jahren ~500MB. 2025 nach 1.5 Jahren schon knapp 2GB obwohl MS eigentlich sagt, dass kein KI im System ist. Ich gehe daher davon aus, dass die Systemkomponenten die ganzen notwendigen Änderungen für KI-Systeme aber durchaus bekommen haben, wozu sonst gäbe es so viele Änderungen nach dem Release. Nur einfach nicht alles für die tatsächliche Nutzung. Zusatzfrage: Ist das deswegen ein zusätzliches Sicherheitsrisiko gegenüber 2022? Zu 3: Die Änderungen im Netzwerkstack waren für mich ein Lichtblick. Fand Teaming/Failover oder iSCSI im Windows-Netzwerkstack schon immer grauselig/mühsam in der Konfig und der Fehlersuche. Darauf habe ich bewusst verzichtet und VmWare eingesetzt. Windows selbst habe ich damit nie (mehr) belästigt, weil VmWare das super gelöst hat. Grüsse und Danke

Das ist die Gretchenfrage. Was ist gut genug. Für meinen Geschmack ist die ganze Fernwarterei inklusive OS-Mangement "schwierig" für einen KMU und auch für den Dienstleister der die ganzen Hersteller im "Schach" halten soll. Objektiv gesehen ist das Risiko weder korrekt beurteilbar noch beherrschbar. Insbesondere bei x-Verschiedenen Ferwartungsvarianten und einem Sammelsurium an veralteten OS. Der Schlüsselschalter hilft wenig wenn der Hersteller etwas einschleppt. Ehrlich gesagt würde es mich sogar wundern, wenn die Hersteller von Fertigungsmaschinen nicht unterwandert sind. Früher habe ich die Kröten geschluckt, aber heute wo alles vernetzt ist, Datenaustausch stattfinden muss, die Software unausgereift daherkommt etc. hat das schlaflose-Nächte-Potential. Zumindest wenn einem nicht alles egal ist. Guacomole: Bis dato noch nicht damig beschäftigt. Halt wieder was mehr Danke für die Inputs!

@cj_berlin: Naja, eher Offline im Sinne von nicht permanent im Internet. Im Produktionsnetz hängt der Rechner schon, das hat kein Internet. Transfer von Dateien kann ich mich nicht mehr wehren, weil der Print/Rescan oft nicht mehr ausreicht und RAW-Messdaten zu den Kunden gehen müssen, diese das Messprogramm selber liefern etc. Also die USB-Sch** ist da auch unterwegs. Bei den Fernwartungen geht es normal um Anwendungssupport von Messmaschinen, CAD oder Maschinensteuerungen in Kleinfirmen ohne IT-Abteilung. Fand die Idee des Technikers auf Anhieb nicht verkehrt, nach näherem Nachdenken aber doch nicht so prickelnd. Die Old-School Vororttermine sind als KMU heute oft nur noch mit grosser Vorlaufzeit möglich. Fernwartung dagegen sofort. Diese ist zudem "inbegriffen" in den astronomischen Wartungsverträgen, der Vorort-Termin muss jeweils äusserst fürstlich zusätzlich bezahlt werden. Für Upgrades setze ich das durch, für minimalen Support ist das aber nicht zielführend. Objektiv betrachtet bin ich aber nicht in der Lage das irgendwie nach minimalen IT-Masstäben sicher zu halten. Maschinen die teilweisedie Neu bereits mit veraltetem OS kommen, wirft man aber auch nicht einfach so weg. Es ist mehr so ein Nicht-Immer-Internet = Risiko-Verkleinerung. IoT setzt sich zwar - sehr langsam - durch (bin immer am meckern), aber Pro mit abgedrehten Updates oft immer noch Standard. @teletubbieland: LTE Router, ja das gefällt mir besser als der WLAN-Stick. Habe ich teilweise so im Einsatz. Bis dato aber für stationäre Anwendungen mit Schlüsselschalter, nicht zum "wechseln". Ist nicht so extrem Anwenderfreundlich als mobile Variante, aber für jede Maschine ne eigenes Gerät ist auch aufwendig. Mich nervt der Wildwuchs von gefühlt 100 verschiedenen Fernwartungsanwendungen. Software, Hardware VPN und was es nicht alles so gibt.

Hallo Zusammen, Ein Hersteller möchte gerne WLAN-Sticks für temporäre Fernwartung auf Offline-Maschinen mit Windows-PC-Steuerung verwenden. Also sobald Fernwartung erwünscht ist, steckt man den Stick rein und baut z.B. über den Hotspot eines Mobilfunktelefons auf (wenn es sonst kein WLAN gibt). Was sollte man davon halten? So auf Anhieb finde ich es besser als eine permanente Verbindung. Aber WLAN deaktiviere ich normal aus Prinzip. Inklusive Dienste. Verschiedenste WLAN-Sticks bekeckern sich auch nicht unbedingt mit Ruhm, müssen zudem auch wieder aktuell gehalten werden. Auch die Firewall ist dann quasi "umgangen" auch wenn jeweils ebenso alles was möglich ist, abgedreht ist per Windows Firewall. Die Alternative wäre eine dedizierte Netzwerkkarte für den Internetzugang mit Schlüsselschalter. Das ist üblicherweise meine bevorzugte Variante. Grüsse und Danke

Hie ein Plus für detailliert. Auf die granulare Freigabe auf einzelne IP's/DNS-Namen kam ich aber aus den Gründen die Evgenij bereits gennant hat auch wieder weg. Hat er schon öfter darauf hingewiesen und fand ich schlüssig. Ist auch viel zu pflegebedürftig. Weniger im Betrieb selbst - da ändert sich nicht so viel - aber wenn man z.B. Migrationen fährt. Da drehst ab. Was ich beibehalten habe ist die granulare Freigabe was überhaupt raus darf. Das gilt für MS als auch fremde Dienste. Ein paar Gründe für Detailierung man sieht im Security-Log was überhaupt alles raus kommunizieren will. Das ist bereits für Windows recht interessant (sofern man es aktiviert) aber auch jede unscheinbare Software. Die In-Logs sind relativ überschaubar und können recht easy ausgewertet werden, weil die ganzen Kontaktaufnahmen anderer Clients wegfallen, weil sie gar nicht erst raus gehen. Gerade für die Fehlersuche ist das extrem angenehm wenn das ganze Grundrauschen weg ist. Windows Updates auf Produktionsmaschinen können sehr effektiv verhindert bzw. geplant werden ohne die Updatedienste zu deaktivieren. Die werden von Windows sowieso gerne wieder aktiviert. So kann man Updates zwar intern freigeben, aber damit sie die Clients bekommen, muss mit einem einfach Script die Firewall-Regel aktiviert werden (das Gegenscript wird automatisch alle paar Stunden ausgeführt wenn man es mal vergisst). Dafür braucht es noch etwas mehr, da der Dienst maskiert ist. IPv6 wird in letzter Konsequenz blockiert (wenn sich ein Dienst nicht an die IPv4 Order hält, entdecken von Kofigurationsfehler oder irgend eine Management-Karte sich verselbstständigt). Ich mag keine zwei Dinge zu pflegen, keine Zeit.

Die RAM-Auslastung ist für einen Spooler der keine Druckaufträge haben soll, auch sehr hoch. Also irgendwas macht das Teil. Hast wie vorschgeschlagen mal die Firewall-Logs geprüft? Also von dem Terminalserver und diesem Server? Der Server scheint allerhand sonstige Aufgaben zu haben ausser Printserver zu sein. Beim Printserver ist das äusserst unvorteilhaft weil nicht so einfach Tests mit Rollback gemacht werden können. Vielleicht generiert ja eine der Aufgaben ne Menge PDF's, Reports oder ähnliches welche die Spooler Engine benötigt. Am ehesten tippe ich aber auf sehr viel falsche Verbindungen (nicht FQDN) oder grottige Treiber. Malware natürlich auch immer möglich.

Stolperte grad drüber. Das stimmt so nicht. Wichtig ist, wie genau das installiert wird bzw. was als Quelle genommen wird. Das XML wechselt selber gar nichts, das erstellt man selbst. Im XML muss einfach zusätzlich die Product ID von Access hinzugefügt werden. Und der Produktkey. Zusätzlich zur Product-ID von Office Standard. Wird das Produkt aber als Bestandteil einer Office Pro Plus Auswahl installiert, begeht man einen Lizenzverstoss, auch wenn man keine andere Komponenten von Pro Plus installiert. Einfacher ist es natürlich, gleich ProPlus zu erwerben. Notwendig aber nicht.

Häufigste Ärger-Ursache seit MS-Security-Hardening: Verbinden mit Printserver-Name statt Print-Server FQDN. Das prüfe ich immer als erstes da alles an Fehlerbilder möglich ist. Dann würde ich noch das NTLM-Logging sowie Firewall-Logging auf Droped Pakete aktivieren sofern nicht bereits gemacht. Wenn z.B. NTLM systemweit deaktiviert wird, dann versuchen die Drucker sich nach Ablauf des Kerberos Tickets des Users sich permanent per NTLM zu verbinden. Was dann so halb funktioniert (aber nicht sollte) oder eben auch nicht (random). Das ist vor allem bei den Protected Users nach ~3h der Fall. Wenn das viele machen, könnte ich mir schon einen Anstieg der CPU-Last vorstellen. Ansonsten der beste Tipp den ich Dir punkto Drucker geben kann: Ausschliesslich die teure(re)n Business-Geräte der grossen Hersteller verwenden. Da passt auch das Treiberpaket inkl. Updates über viele Jahre. Dann: Printserver immer isoliert betreiben ohne anderen Krams. (einfache Rollbacks).

In Hinblick der ganzen Ransomware und Hypervisor-Sicherheitslücken (Hostübernahme durch VM) der letzten Jahre, bin ich recht skeptisch geworden mit der Sicherung in eine Storage bzw. Backupserver VM rein. Hatte einige schlaflose Nächte deswegen, da ich oft genau solche Konzepte für die aktuellen Backups benutzt habe. Ein paar Gedanken zu Backups (Fokus KMU-Umfeld) Die Backups selbst sollten möglichst immutable, also nicht löschbar sein. Mindestens ein Ziel, besser zwei und unterschiedliche Technik (z.B. NAS und Server) über die LAN-Verbindung ins produktive Netz bzw. die Verwaltungsebene nur das erlauben was für Übertragung notwendig ist. Verwaltung wieder über eigene Anschlüsse. Agentless Sicherung und ohne Hypervisor-VM Kommunikation kann man z.B. bewerkstelligen indem Applikations-Daten auf eine separate Fesplatte der produktiven VM gesichert werden. Die sind dann immer Konsistent wenn der Backup eine Kopie zieht. Bei einem Restore ist halt ein zusätzlicher Schritt notwendig. Erst VM zurück, dann Applikations-DB. Backup in die Cloud ist je nach dem unglaublich Bandbreitenintensiv. Kommt drauf an wie viel gesichert werden muss und vor allem was. Nur Nutzdaten oder wirklich die ganze Umgebung. Externe Backups Inkrementell zu sichern finde ich auch immer etwas speziell. Restore-Geschwindigkeit ist heute erschwinglich geworden. Sowohl 10gbit als auch SSD's. Sprich das Primäre Backup kann auch HighSpeed sein oder sogar auf der gleichen Maschine wo man dann die Platten in den zweiten Server steckt wenn nötig. (Hardware-Ausfällen, Update-Ärger oder Aus-Versehen-Löschungen) Bei Ransomware oder Totalausfall wegen Brand etc. spielt die Zeit (in einem KMU) oft eh nur noch eine untergeordnete Rolle. Also ob das dann von der Cloud oder einem lahmeren Repo kommt ist dann grad auch egal weil der Rest sowieso schon viel Zeit in Anspruch nimmt Ich mag zum Beispiel Files und Datenbanken-Sicherheits-Kopien als Kopie auf einer unabhängigen eigenen Maschine für diesen Zweck. Also Server oder NAS nicht innerhalb der Domäne und über eigenes VLAN. Der Kopiervorgang direkt von Filesystem zu Filesystem. Grund: Wird die VM-Disc z.B. zwei Monate vorher verschlüsselt und erst dann die Keys gelöscht, hat man mit etwas Glück trotzdem aktuelle Nutz-Daten.

Moin, ok, falsch verstanden. Das bezog ich darauf. Also Kommunikation mit zentralem KDC und LocalKDC selber spielen. Der Punkt wo ich auf dem Schlauch stehe ist der, wo aus Sicht des Clients der Unterschied ist, ob er nun gegen einen zentralen oder einen lokalen KDC authentifziert. Der Ablauf müsste für Ihn ja identisch sein, da gleiche Technik aber andere Maschine. Daher auch meine Missinterpretation Deiner Aussage oben. Aber ja eine gewisse Illusion spielt da sicher mit, da gebe ich Dir vollkommen recht!

Kleine Anmerkung am Rande: An sich ein sehr cooles Gerät mit kleineren Schwächen. Habe selbst mal eines geordert. Die Herkunft ist zumindest "interessant". Es wird einem suggeriert, dass es ein europäisches Produkt ist, aber es kommt vollständig aus China. inkl. der Software und auch dem Cloud-Anbindung. Auch konkrete Anfragen ergeben mitunter interessante Antworten. Gesunde Skepsis dürfte nicht verkehrt sein.

@cj_berlin Also jetzt stehe ich wirklich auf dem Schlauch bzw. verstehe nicht worauf Du hinaus willst. Wozu muss der Drucker ein LocalKDC haben? Er ist ja der "Client" und muss sich ein Ticket holen damit er etwas auf dem Fileserver ablegen kann. Andersum - also wenn ein Windows-Client etwas auf dem Drucker holen will - sieht das natürlich anders aus. Da sind es dann in der Regel Abteilungs-Pins die man eingeben muss. Sofern das überhaupt geht. Normal gibt man für ein Scan-Ziel einen User und einen Pfad pro Ziel an. Sprich man definiert worauf der Drucker zugreifen und mit welchem User/PW er sich anmelden soll. Das Ziel - der Fileserver - sagt ob das mit den User-Creds möglich ist. Wenn es zufällig der gleiche Computer ist, gut, wenn nicht, egal. Zumindest müste es ja so umgesetzt sein mit Kerberos. *hust* Schätze mit NTLM ist es wohl eher so, dass man auf die Ressource zugreifen möchte und die verlangt dann die User-Credentials. Den genauen Ablauf kenne ich nicht. Aber auch da kann man angeben ob es ein Lokales oder ein Domänen-Konto ist. Geht eigentlich immer beides egal ob der Filer in einer Domäne ist oder nicht. Einfach indem User@ComputerFQDN oder User@domäneFQDN angegeben wird. Aktuelle mache ich das so: Separater Scan-Fileserver der in der Domäne ist Lokales Dienst-Konto auf dem Fileserver welches im Drucker angegeben wird (ich mag für Dienskotos üblicherweise lieber lokale Konten, sofern möglich) NTLM für Domänenkonten AD-Weit gesperrt Ausnahme für NTLM auf diesem Fileserver Nur ein spezielles Admin-Konto das sonst nirgends verwendet wird, hat auf dem Filer Anmelderechte mit einem Domänenkonto, sonst niemand, also alle explizit verboten Heisst der Drucker greift mit einem Konto zu, dass nur auf dem Scan-Server existiert. Aktuell verwendet z.B. ein Canon Drucker NTLM um sich zu authentifizieren. Versucht sich jemand mit NTLM gegen ein Domänenkonto via dem Scan-Filer zu authentifzieren, schlägt es fehl obwohl der Filer selbst ein NTLM-Ausnahme hat. Verwendet er ein lokales Konto des Filers, ist es dagegen möglich. -->Schön wäre nun, wenn das ganze über den LocalKDC laufen würde und keine Ausnahme notwendig wäre. Inwiefern es tatsächlich ein Sicherheitsgewinn ist, keine Ahnung. Aber das NTLM nicht sicher ist, wurde bereits bewiesen. ;) Bei den Adresslisten die von einem Server gestellt werden, sieht das anders aus. Da geht oft Druckerweit nur eine Anmeldung an einem Verzeichnisdienst. Da können eigentlich auch alle Kerberos. Selbst Canon. Insofern wüssten die schon wie das geht.

@cj_berlin Sehe noch nicht ganz die Problematik. Entweder meldet man sich mit EINEM User an EIN Ziel und somit EINEN lokalen KDC an oder man verwendet EIN Domänenkonte wo die Authentifzierung gegen MEHRERE Ziele (DC's) möglich ist. In beiden Fällen liefert der DNS doch die entsprechenden IP's der bzw. des Anmeldeservers für einen externen Zugriff. Bedingt natürlich, dass der zugreifende User nicht einfach ein Username sondern eben der vollständige Anmeldename ist. Also "user@domänexy.xy" oder "user@computer.domäne.xy". Oder "User@computer.xy". Ist kein DNS vorhanden müsste man eben die IP händisch mit angeben. So wie auch für NTLM wo sie einfach via Broadcast oder auch mit DNS ermittelt wird. Mit der Ressource selbst hat das ja erstmal nichts zu tun, das ist ja immer eine separate Angabe. Oder stehe ich auf dem Schlauch? Wie die ganze Vortrauenssache aussieht damit überhaupt eine geschützte und sichere Authentifizierung vorgenommen werden kann, steht wieder auf einem anderen Blatt. Aber da wird ja MS schon eine Idee haben wenn sie das implementieren. Dazu habe ich mich noch zu wenig damit beschäftigt. Vielleicht weiss ja Du dazu mehr? Ansonsten bin ich mal gespannt wie lange es geht bis die Malware-Entwickler so kreativ werden und die integrierten KI-Funktionen gleich für den Angriff zu nutzen. Könnte "interessant" werden. Hat etwas von der Büchse der Pandora. Ich würde jedenfalls lieber die Lizenzgebühren für ein reines, stabiles, sicheres OS bezahlen. Vielleicht lässt es sich dann ja auch easy entfernen. MS hat ja mittlerweile eine sehr gute Kapselung der Komponenten.

Ja, sobald der geht, kannst im Grunde NTLM komplett in Rente schicken. Wie stark es tatsächlich ein Sicherheitsgewinn ist, kann ich nicht beurteilen, aber immerhin musst dann keine Ausnahmen mehr machen für NTLM. Zumindest solange andere Software-Hersteller zeitnah nachrüsten. Bis dahin kann bzw. sollte man es für Domänen-Konten deaktivieren und auf einzelnen Maschinen für lokale Konten zulassen.