NilsK

Moin, ja, auf heise.de gibt es eine ganz gute Übersicht der bisherigen Erkenntnisse. Sieht schon ziemlich "state-sponsored" aus bei dem Aufwand. Gruß, Nils

Moin, es ist ja auch aufgefallen, aber eben erst hinterher. Vermutlich nicht so wild wie damals bei Heartbleed, aber schon eine harte Nummer. Am Ende ist der Punkt, dass moderne Software so komplex ist, dass man solche Angriffe gar nicht wirksam verhindern kann. Weder durch Closed noch durch Open Source. Mir schwant, dass das "mit KI" nicht besser wird, aber das würde dann jetzt wohl den Stammtisch eröffnen (hicks). Gruß, Nils

Moin, es klingt wie "ätsch", aber bei solchen Meldungen stelle ich immer wieder fest, wie wenig das typische Open-Source-Argument zutrifft, dass der offene Entwicklungsprozess ja automatisch für Sicherheit sorge, weil niemand unbemerkt eine Beckdorf einschleusen könne. Abgesehen davon - schätze ich es richtig ein, dass das nur Linux betrifft? Gruß, Nils PS. ich lasse die Autokorrektur Mai gewähren.

Moin, für ein "Zweitangebot" würde ich mich ohnehin nicht hergeben. Der 365-Teil ist trivial, die "Datenübernahme" ist trivial, wenn man sie schlecht macht, und aufwändig, wenn sie sinnvoll sein soll. Ehemals lokal selbst betriebene Anwendungen in VMs in der Cloud zu übertragen, ist in erster Linie teuer. Entweder lokal weiter betreiben oder durch SaaS ersetzen. Wenn man als Dienstleister sich damit nicht auskennt, dann verbrennt man sich die Finger dran. Das Know-how aufzubauen, ist machbar, aber das sollte man nicht mit einem Kunden machen, mit dem man gegenseitig gar nicht mehr arbeiten will. Gruß, Nils

Moin, Maßeinheit ist eigentlich nicht ganz richtig, es war eher ein Bezugspunkt, so wie "Normalnull". Ein Witz konnte über oder unter Kaczenski sein, wobei "unter" sehr selten vorkam. Gruß, Nils

Moin, zwei DCs ist Minimum, mehr nur bei Bedarf. Das ist primär eine Frage des Gesamtdesigns. In mittelständischen Umgebungen ist das normalerweise keine Ressourcenfrage. Gruß, Nils

Moin, früher an der Uni gab es eine Maßeinheit für die Flachheit von Witzen. Sie hieß "Kaczenski". Gruß, Nils

Moin, oh, da befürchte ich rechtliche Probleme ... Gruß, Nils

Moin, es geht mir nicht um die Ressourcen, sondern um die Bedeutung des AD und das Ausfallrisiko. Eine Client-Hardware ist nicht für Dauerbetrieb gemacht und hat daher schon rein technisch ein höheres Ausfallrisiko als ein Server. Das will man bei einem DC nicht haben. Eine einfache Serverhardware, die grundlegende Ansprüche an Dauerbetrieb erfüllt, ist kein ernsthafter Kostenfaktor in einen Netzwerk mit dreistelliger Anwenderzahl. Wer das anders sieht, rechnet falsch. Wir sind nicht mehr in den Neunzigern, die Zeit der Bastel-IT ist lang vorbei. Ich habe damit nicht angefangen. Gruß, Nils

Moin, Ich möchte das mal relativieren. Billige Client-Hardware ist nur als Notlösung geeignet, um einen DC zu betreiben. In einem Netzwerk mit 300 Usern und 60 Servern darf es schon was Ordentliches sein. Nicht dass das noch als Best Practice aufgefasst wird. Gruß, Nils

Moin, sehr gut. Bei Detailfragen melde dich gern wieder. (Beim AD-Recovery gibt es leider eine ganze Menge Details, an denen es nervig werden kann.) Gruß, Nils

Moin, am Ende ist die geschilderte Idee ja auch nicht neu und ebenso wenig "provokant". Es ist das, was VM-Backup-Tools eben tun. Also ACK, dass man das im Prinzip so machen kann ... ... aber: der relevante Punkt ist, um Evgenij zu zitieren (im AD-Zusammenhang geht das ja): Da das AD für viel, viel Weiteres in einem Netzwerk die Grundlage ist, sollte man auch mehrere Optionen zur Wiederherstellung haben. Und da rate ich schon seit etwa 20 Jahren dazu, nicht nur mehrere Backups (im Sinne von: das AD von mehreren DCs aus sichern) zu haben, sondern auch mehrere Techniken parallel zu nutzen. Ich würde in so einem Gesamtkonzept immer ein AD-Backup mit Bordmitteln dabei haben, weil es das einzige AD-Backup ist, das vom AD-Hersteller vollständig supportet wird. Und: "einfach" ist im Zusammenhang mit Datensicherung ein schlechtes Hauptkriterium. Es kann ein Aspekt sein, aber ich würde vor allem vom Recovery her denken, und da wird es in der Regel leider nicht einfach. Gruß, Nils

Moin, Wenn du sowieso separate Hardware hast, installiere zwei neue VMs auf dem neuen Host. Stufe die eine hoch zu einem zusätzlichen DC der bestehenden Domäne. Kopiere die Dateiserver-Daten per RoboCopy auf den neuen Dateiserver. Exportierte die Freigaben aus der Registry des alten Dateiservers und importiere sie auf dem neuen. Dann entferne den 2012-DC v aus der Domäne, danach ebenso den alten Dateiserver. Wenn gewünscht, ändere den Namen des Dateiservers so, dass er wie der alte heißt. Auf die Weise hast du zwei "frische" VMs statt zwei teils renovierte uralte Installationen. Falls die Domäne mehr als zehn User hat, solltest du einen zweiten DC hinzufügen. Gruß, Nils

Moin, ich habe es gerade mal nachvollzogen. Das Fensterverhalten von Windows 11 scheint sich tatsächlich gegenüber Windows 10 in der beschriebenen Weise verändert zu haben - aber es gibt nun ja eben, wie du selbst ja sagst, schon vordefinierte Zonen in Windows 11. Die kannst du ja auch noch viel einfacher nutzen, nämlich indem du bei dem gewünschten Fenster den Mauszeiger einen Moment lang auf dem "Maximieren"-Button verweilen lässt. Da ist eine 50:50-Aufteilung dabei. Das ist viel weniger fummlig als das Fenster zum Rand zu ziehen, finde ich. Fancy Zones benutze ich trotzdem gern, weil es noch mehr Optionen ermöglicht (und weil ich damit noch einfacher Fenster von einem Bildschirm auf den nächsten schubsen kann). Gruß, Nils

Moin, Schau dir mal die PowerToys an, da gibt es ein Tool namens "Fancy Zones", mit dem du sehr genaue Zuweisungen vornehmen kannst. Gruß, Nils

Moin, ich würde das bei einer Neukonzeption ändern, aber ohne nähere Kenntnis der Situation würde ich vermuten, dass das kein vordringliches Problem ist. Sehr wahrscheinlich wird die Energie zu Beginn eines solchen Wegs an anderen Stellen besser investiert sein. Gruß, Nils

Moin, okay, das ist eine Größenordnung, wo ein gewisser Aufwand sinnvoll ist. Wichtig dabei, wie du ja schon selbst feststellst: Planung. Nicht einfach losrennen, auch scheinbare Quick-wins sollte man zumindest einschätzen und einordnen. Zum Thema "Tiering" ist in den letzten zehn Jahren auch viel geschrieben worden, was in mittelgroßen Netzwerken eher unsinnig ist. Konkrete Fragen gern hier. Mit einem Inventar der Admin-Konten und ihrer Verwendung anzufangen, ist jedenfalls eine gute Idee. Gruß, Nils

Moin, das mag sein, aber glaubt ihr, dass der TO mit den Hinweisen etwas anfangen kann? Anscheinend ist er in HTML und CSS ja nicht besonders firm. Beispiele oder wenigstens Links könnten da hilfreich sein ... Gruß, Nils

Moin, Naja, ist doch bekannt: Exchange on-prem ist nur noch dazu da, um die Leute zu Exchange Online zu treiben. Gruß, Nils

Moin, fangen wir doch mal vorne an - wie groß ist denn das Netzwerk überhaupt? Jede Maßnahme muss ja auch angemessen sein. Gruß, Nils

Moin, Blöde Auto-Korruption. Gruß, Nils

Moin, Ich glaube, du denkst in die falsche Richtung. Das wurde im Verkauf des Threads schon aufgeklärt. Gruß, Nils

Moin, Mit Leerzeichen habe ich im AD kaum jemals Probleme mitbekommen. Schrägstriche vor- und rückwärts hingegen sind sehr schnell eine Quelle origineller Probleme. Aber ich stimme zu, im Zweifel vermeidet es Ärger, an solchen Stellen etwas konservativer zu sein. Gruss, NIL~1.TXT

Moin, das wurde im OP zumindest implizit gesagt: der Hersteller hat anscheinend in neuen Versionen den Namen geändert. Gruß, Nils

Moin, zum O365-Angebot ohne Teams hat die EU Microsoft gezwungen, damit es ein Office-Angebot gibt, das Teams-Konkurrenten nicht von vornherein ausschließt. Bei den Business-Plänen kann man direkt zwischen "mit" und "ohne" auswählen, bei den E-Plänen kann man Teams dazubuchen. Scroll auf der E5-Seite mal runter, dann siehst du das. Gruß, Nils