NilsK

Moin, ich wollte nicht in Abrede stellen, dass deine Gründe valide sind. Und als ich meinte, du musst die angehen - erstens weißt du das ja, und zweitens ist auch klar, dass das nicht so einfach in deiner Macht liegt. Davon solltest du dich aber nicht hindern lassen, den Teil, den du kontrollieren kannst, für dich sinnvoll zu bauen. Das eine tun, ohne das andere zu lassen. Ich rate dabei aber, nicht zu viel auf einmal zu wollen. Sonst wirst du nie fertig, und du baust dir deine eigene Überforderung. IT-Sicherheit kann man immer noch mal besser machen, aber genau das ist der Punkt: Es ist ein Prozess. Mach Dinge Schritt für Schritt. Viele Risiken, die es grundsätzlich gibt, sind in einer konkreten Situation gar nicht relevant oder recht unwahrscheinlich, die muss man dann auch nicht im ersten Schritt ausschalten. Nein, würde man nicht. Das sind unterschiedliche Netze. Die Hosts haben ein eigenes Betriebssystem und einen eigenen Netzwerkstack, der mit denen der VMs nichts zu tun hat. Da das in Hyper-V leider nicht besonders übersichtlich gebaut ist und da auch viele Internet-Quellen das nicht gut darstellen, hab ich das mal selbst beschrieben. Das ist im Detail zwar nicht mehr ganz aktuell, die Grundzüge sind aber noch dieselben. [Hyper-V und Netzwerke | faq-o-matic.net] https://www.faq-o-matic.net/2012/04/23/hyper-v-und-netzwerke/ Gruß, Nils

Moin, wenn du schon auf der Ebene nachdenkst und argumentierst - was sinnvoll ist -, dann solltest du in Betracht ziehen, einen separaten Infrastruktur-Forest für deine Host-Umgebung einzurichten. Dort hast du dann die Vorteile der Domänenverwaltung und kannst die Domäne getrennt von deiner Produktionsdomäne absichern. Sollte es dort dann ein Problem geben, ist der andere Forest nicht automatisch mit korrumpiert. Ich stimme aber auch Jan zu - das Niveau, das du erreichen willst, ist mit den "Gründen", die du nebulös anführst, nicht vereinbar. An die wirst du auch ran müssen. Gruß, Nils

Moin, dann ist das Skript vom Prinzip her ziemlich einfach: BACKUP DATABASE MyDatabase TO DISK = 'D:\Pfad\Datei.mdf' DROP DATABASE TestDatabase RESTORE DATABASE TestDatabase FROM DISK = 'D:\Pfad\Datei.mdf' Der Code ist aus dem Gedächtnis und ungetestet, sollte aber im Wesentlichen so gehen. Gruß, Nils

Moin, Wiederherstellung auf demselben System? Oder auf einem anderen? Grundsätzlich lässt sich sowas per T-SQL-Skript und SQL Server Agent gut machen, alternativ auch per Windows-Taskplaner. Die wichtigen Kommandos dazu sind BACKUP DATABASE und RESTORE DATABASE, das ist im Prinzip nicht weiter schwer. Gruß, Nils

Moin, Drucker im AD war mal eine Schnapsidee aus den Neunzigern, die sich nicht durchgesetzt hat. Braucht man nicht, macht man nicht. Also so, wie du vermutest. Das ist eine verbreitete Angewohnheit in der IT. Viele reden auch von "die Storage", sogar "die Switch" ist mir schon untergekommen (und es war kein Nintendo gemeint, sondern Cisco, Aruba et al.). Gruß, Nils

Moin, Ah, okay. Gruß, Nils

Moin, @Kaltes_Wasser, ich lasse jetzt mal die Nachfragen wegen der Lizenzen außen vor. Etwas windig klingt das für mich schon. Windows 10 kann man nicht auf Windows Server 2022 aktualisieren. Da Windows 10 aber auch als Server gar nicht geeignet ist, wäre ein Umstieg auf eine neue Server-VM sicher ein passender Weg. Wenn die neue VM denselben Namen hat wie die alte, wirst du wahrscheinlich die zugreifenden Applikationen nicht umkonfigurieren müssen. Da SQL Server den nachträglichen Wechsel des Servernamens nur mit zusätzlichem Aufwand akzeptiert, wäre ein schrittweises Vorgehen mit Downtime also insgesamt am einfachsten. Vom Prinzip her: Datenbanken auf der alten VM sichern (Backup). Alte VM herunterfahren. Neue VM mit demselben Namen installieren. SQL Server dort installieren. Datenbanken aus dem Backup in der neuen SQL-Installation wiederherstellen. Mit etwas Glück war es das dann im Wesentlichen schon. (Ja, das ist das, was Dukel auch vorgeschlagen hat, nur noch mal in übersichtlich.) Gruß, Nils

Moin, alle Einwände, die du machst, musst du mit Strato diskutieren, nicht mit uns. Wir definieren die SLAs ja nicht. Wir kennen sie auch nicht. Aber vielleicht gestattest du mir den Einwand, dass es sehr riskant ist als "Fast-Laie" eine Server-VM im Alleingang bei einem Hosting-Discounter zu betreiben. Du hast jetzt eine Seite der Risiken selbst kennen gelernt, nämlich die der Betriebsstabilität - von den wesentlich höheren Risiken auf Ebene der IT-Sicherheit schweigen wir hier mal, weil nicht Thema des Threads. Gruß, Nils

Moin, die 10 Stunden liegen zwischen dem ersten und dem zweiten Zurücksetzen. Nicht zwischen dem zweiten und dem dritten - dreimal ist nicht nötig. Der Zeitabstand dient dazu, dass in einer Nicht-Angriffs-Situation genügend Zeit bleibt, dass auch eine verteilte und AD-replizierte Infrastruktur unterbrechungsfrei weiter arbeiten kann. Gruß, Nils

Moin, dafür müsste der Patch ja auch eingespielt worden sein. Darüber wissen wir hier nichts, soweit ich sehe. Gruß, Nils

Moin, dafür müssten wir jetzt sehr weit ausholen, um die Zertifikats-Basics zu diskutieren, fürchte ich. Wäre vielleicht etwas viel für ein Forum. In aller Kürze: statt eine CA einzurichten, erzeugst du auf "irgendeinem" System mit einem lokalen Tool dein Root-Zertifikat. Mit diesem Root-Zertifikat stellst du mit demselben Tool das gewünschte Server-Zertifikat aus. Das Root-Zertifikat importierst du in die "Vertrauenswürdigen Zertifizierungsstellen" auf den beteiligten Systemen. Das Server-Zertifikat bindest du in den Dienst ein, der es nutzen soll. Da du ja nur Zertifikate brauchst und keine PKI, ist das für "kleine" Zwecke erheblich einfacher und sicherer. Gruß, Nils

Moin, na, und noch so ein Missverständnis, das wir ausräumen können. Für einzelne Server-Zertifikate brauchst du ja keine CA bzw. PKI. Im Gegenteil, für so einen Zweck würde ich sogar entschieden davon abraten. Es geht normalerweise darum, dass Zertifikate vorliegen, denen die Systeme vertrauen. Das kann man mit minimaler Infrastruktur einrichten, für die man keine komplexen und anfälligen Systeme braucht. Exemplarisch habe ich das hier mal skizziert: [LDAPS in einer Windows-Domäne ohne PKI | faq-o-matic.net] https://www.faq-o-matic.net/2024/06/18/ldaps-in-einer-windows-domne-ohne-pki/ Gruß, Nils PS. PKI ist böse.

Moin, das hat jetzt aber schon was davon, das Haar in der Suppe zu suchen. Auf zwei Nicht-AD-Hosts kannst du auf beide genannten "Nachteile" ja gut verzichten. Auch ein lokales Adminkennwort muss man nicht per se regelmäßig wechseln, wenn es ausreichend stark ist. Der Witz an LAPS ist doch primär, dass man von massenweise verwendeten identischen Adminkennwörtern weg will - das kann man für den Use Case doch problemlos organisatorisch sicherstellen. Ähnlich bei Protected Users - die meisten Maßnahmen, die das umsetzt, kommen bei lokalen Systemen ja gar nicht in Betracht, und vom Rest lässt sich ein Großteil organisatorisch abfangen. Wenn ich mir ansehe, wie freimütig die meisten VMware-Systeme in der freien Wildbahn so eingerichtet sind, sehe ich da wirklich keinen grundsätzlichen Nachteil ... Gruß, Nils

Moin, nein, DCs sind Tier-0. Falls diese DCs auf einem VM-Host laufen, dann ist dieser VM-Host auch Tier-0, auch dann, wenn der Host selbst nicht dem AD angehört. (Und, der Vollständigkeit halber, dann ist auch das Storage Tier-0, das dieser Host nutzt.) Laufen keine Tier-0-VMs auf einem Host, dann ist der Host nicht Tier-0, auch nicht, wenn er selbst AD-Mitglied ist. Und, wie Evgenij schon betonte, das gilt für alle Hypervisoren, wäre also mit VMware, Proxmox et al. nicht anders. Gruß, Nils

Moin, also ... die einfache Antwort ist: Nur weil es "Cluster" heißt, ist das heute nix Wildes mehr. Richtet sich einfach ein, lässt sich einfach verwalten - jedenfalls solange wir von so kleinen Umgebungen reden. Und ein automatisches Failover für VMs ist auch gleich mit drin. Ich würd da nicht lange nachdenken. Nur weil VMware die besseren Verwaltungstools hat, ist Hyper-V noch lange nicht schlecht. Einfach mal überwinden und machen, dann sieht man, dass man damit auch gut klarkommt. Gruß, Nils