NilsK

Moin, wie dir das Board mitgeteilt hat, ist der Thread sehr alt, konkret dreieinhalb Jahre. Lass so einen alten Thread künftig doch bitte einfach ruhen. Gruß, Nils

Moin, und man könnte evtl. über ein Client-OS nachdenken ... Gruß, Nils

Moin, ich will die Sache ja jetzt nicht kompliziert machen und den Thread unnötig verlängern, aber ... ... das ganze Gelöt für EINEN User? Lässt sich das nicht sinnvoller lösen? Warum braucht man für einen User, der ein CRM nutzen will, einen Server mit der ganzen Mimik drauf? Gruß, Nils

Moin, gern, danke für die Rückmeldung. Gruß, Nils

Moin, im Task Manager auf dem "Host" siehst du nur das, was der "Host", also das Management OS macht. Die VMs sind ja absichtlich davon getrennt. Für eine Überwachung "aller" Ressourcen ist der Task Manager nicht geeignet, der soll nur einen schnellen Blick bieten (auch wenn es nicht um Hyper-V geht). Deine Fragen könntest du mit dem Performance Monitor beantworten, nimm dir dafür aber Zeit, das ist unübersichtlich und nicht trivial. Es gibt auch Drittanbieterprogramme, z.B. den Hyper-V Manager von 5Nine. Gruß, Nils

Moin, kann sein, dass mein Beispiel eine Ebene zu viel enthält. Ich mach selbst nur noch wenig mit DFS, weil ich nicht für den Betrieb zuständig bin. Gruß, Nils

Moin, vielleicht liegt dasselbe Missverständnis vor wie in dem Thread, auf den du dich beziehst. DFS Namespace funktioniert so, dass du mehrere Shares unter einem gemeinsamen Überordner bereitstellen kannst. Diese bilden dann aber weiter zwei getrennte Ordner. \\domain.tld\dfs-root\Daten\Buchhaltung (das ist der Share Buchhaltung auf Server A) \\domain.tld\dfs-root\Daten\Vertrieb (das ist der Share Vertrieb auf Server B) DFS ist nicht dafür gedacht, aus mehreren Shares einen einzigen Ordner zu machen. Man kann da zwar etwas tricksen, wenn es nötig ist, aber dazu muss man genau wissen, was man tut - und gemeint ist es so eben nicht. Es geht um einen gemeinsamen Baum zur Navigation, nicht um das Zusammenführen getrennter Ordner. Wenn du für denselben DFS-Ordner mehrere Quellen (Ordnerziele) angibst, dann ist das als eine Art Redundanz gedacht. In dem Fall müssen die Inhalte von ShareA und ShareB identisch sein, was man über DFS-R oder andere Mechanismen erreichen kann. Der Client verbindet sich immer nur mit einem der Ordnerziele - was meist dafür genutzt wird, dass Clients an Standort A sich mit dem Share/Server an Standort A verbinden und Clients an Standort B eben mit dem am Standort B. Da das eine ganze Menge von Folgeproblemen aufwirft, ist das nur für wenige Szenarien geeignet. Gruß, Nils

Moin, naja, wie gesagt ... dann such an der richtigen Stelle und nicht um die Ecke. Gruß, Nils

Moin, laut c't ist es technisch möglich. Lizenzrechtlich ist das mindestens eine Grauzone, weil Microsoft das kostenlose Upgrade-Angebot nicht mehr hat und auch keine öffentliche Aussage dazu trifft, ob es noch erlaubt ist. Solange dir Microsoft also nicht direkt etwas anderes sagt (du könntest dort fragen), würde ich davon ausgehen, dass es nicht OK ist. Gruß, Nils

Moin, hier (Windows 10 v1809) funktioniert es mit Localhost auch als Skript. Anscheinend sind bei Localhost keine Adminrechte (mehr) für die Admin-Freigabe nötig. Ich meine, dass das früher nicht so war. Du willst in der Praxis doch wohl auch kaum die lokale administrative Freigabe mappen, oder? Teste das Skript mal so, wie es tatsächlich laufen soll. Gruß, Nils

Moin, kann es sein, dass das Skript nicht mit den nötigen Rechten ausgeführt wird? Eine Verbindung zu Admin-Shares wie C$ erfordern Administratorrechte auf dem Zielsystem. Gruß, Nils

Moin, es ist eine prinzipielle Frage. Wie oben schon angemerkt, ist ein Fingerabdruck schlicht ein anderes Merkmal als ein Kennwort. Einen Fingerabdruck hinterlässt man überall, wo man was anfasst. Er ist aber trotzdem als solcher eindeutig zu einer Person zuzuordnen, zumindest ausreichend eindeutig für viele Zwecke. Ein "Kompromittieren" des Merkmals gibt es daher nicht. Die polemisch angeführte Aussage, man könne einen Fingerabdruck nicht ersetzten wie ein Kennwort, ist daher nichts als das: Polemik. Ob ein Fingerabdruck als Authentifizierungsmerkmal in der Praxis geeignet ist, steht auf einem anderen Blatt. Vorhandene Technik lässt sich für viele Sicherheitsanforderungen zu leicht austricksen. Für andere Zwecke reicht sie schon jetzt aus. Es ist immer eine Frage der Abwägung. Genauso kann man durchaus berechtigt zu dem Schluss kommen, dass Kennwörter grundsätzlich ein nutzbarer Mechanismus sind. Die Technik ist z.B. sehr leicht zu implementieren und stellt geringe technische Anforderungen an das authentisierende Gerät. Für Kennwörter gelten aber eben spezifische Bedingungen - wie für jeden anderen Mechanismus auch. Gruß, Nils

Moin, das war vor zehn oder fünfzehn Jahren aber nicht anders. Ein "SAN" ist halt nix von der Stange wie eine Jeans. Gruß, Nils

Moin, das könnt ihr beenden. Solche Geschichten kann man von jedem Hersteller erzählen. Gerade von Cisco ... bringt also nix. Gruß, Nils

Moin, was soll das werden? "Ich will aber" ist keine gute Diskussionsgrundlage. Sieh es so: Hast du dein Backup nur in der Cloud, bist du für jedes Restore vom Internet abhängig. Das gibt in den meisten realen Umgebungen keinen sinnvollen Ansatz. Ansonsten bin ich jetzt hier raus und verweise auf meinen Beitrag zwei weiter oben. Gruß, Nils

Moin, wie du gerade feststellst, kannst du ohne Gesamtkonzept kein sinnvolles Backup aufbauen. Also solltest du dir jetzt Gedanken um ein Konzept machen. Das ist eine durchaus umfangreiche Aufgabe. Kernfrage: Was muss ich in welcher Situation in welcher Qualität wiederherstellen können? Nicht das Backup ist das Thema, sondern das Recovery. Wichtig: "Was" ist in den seltensten Fällen ein Element, sondern die Frage muss man für verschiedene Elemente separat stellen. Um noch eine Antwort zu der Host-Frage zu geben: Meist braucht man den nicht zu sichern, weil eine Host-Umgebung i.d.R. auf Basis vorhandener Dokumentation neu eingerichtet wird. Da es hier um Hardware mit zahlreichen Abhängigkeiten geht, die eigentliche Konfiguration aber typischerweise eher überschaubar ist, verzichtet man meist auf ein Backup. Gruß, Nils

Moin, hm, ich finde das gerade nicht besonders zielführend. Ich bin mir nicht mal sicher, ob überhaupt die Option besteht, das Cloud-Backup als erste Instanz zu machen. Zumindest gehen sowohl Veeam als auch Azure (wie vermutlich auch alle anderen) von Lokal-Remote aus. Ja, natürlich haben wir auch schon VMs aus der Cloud wiederhergestellt. Mangels Desaster war das ein Test, aber das funktioniert. Alles weitere muss man dann schon am konkreten Szenario betrachten. Gruß, Nils

Moin, deine Internetleitung hat eine Gigabit-Bandbreite? Dann kannst du darüber nachdenken, die erste Kopie in die Cloud zu schreiben. In den vielen Fällen, in denen das nicht der Fall ist, macht man es umgekehrt. Bedenke dabei auch den Rückweg: Meist braucht man das letzte Backup. Spielst du das um 10 Uhr vormittags über die Internetleitung zurück? Oder ist es dann sinnvoller, es lokal zu haben? "Lokal zuerst" heißt ja auch nicht Tape. Nicht umsonst arbeitet man auch bei Tape-Backups seit vielen Jahren mit einer Erstkopie auf Platten und nutzt das Tape als zweite Stufe. Im wesentlichen dieselbe Argumentation. Abgesehen davon, geht auch Veeam Cloud Connect von genau dieser Zweistufigkeit aus: erst lokal auf Platten, dann in die Cloud. Und ja, Erfahrung mit Azure Backup ist vorhanden. Wenn das Szenario passt, ist das eine gute Sache. Gruß, Nils

Moin, der Weg ist normalerweise andersrum: Primäres Backup lokal (typischerweise "on disk"), sekundäres Backup in der Cloud. Das ist schon deshalb sinnvoll, weil das Backup in die Cloud technisch bedingt viel länger dauert. Der Azure Backup Server ist übrigens nicht besonders komplex und eignet sich durchaus für Kunden mit einer geringen Anzahl an VMs. Gruß, Nils

Moin, du führst ein häufig genutztes Argument an, das aus meiner Sicht an der Sache vorbeigeht. Das biometrische Merkmal ist nicht kompromittiert. Dieses Denken setzt ein solches Merkmal mit einem Kennwort gleich. Kompromittiert ist die Überprüfungsmethode, weil sie nicht ausreichend sicher zwischen dem Original und einer Nachbildung unterscheidet. Wenn ein Pförtner eine Person reinlässt, die er nicht reinlassen dürfte, weil er sie mit einer anderen Person verwechselt - ist dann die reale Person kompromittiert? Wohl eher nicht. Es hat sich dann die Prüfung durch den Pförtner als nicht ausreichend trennscharf erwiesen. Auf einer anderen Ebene spielt sich die Sache ab, wenn man die technische Umsetzung einer biometrischen Prüfung betrachtet. Und da kann man eben sehr wohl abwägen. Und man muss auch unterscheiden zwischen verschiedenen Sicherheitsbedarfen und Angriffsszenarien. Dann ist etwa der Fingerabdruck am Handy plötzlich wesentlich sicherer als eine PIN-Eingabe oder ein Wischmuster. Gruß, Nils

Moin Martin, pfiffitsch. Merk ich mir. Gruß, Nils

Moin, wobei man auf der Ebene schon eine Gesamtbetrachtung machen muss. Jedes Authentifizierungsverfahren ist angreifbar. Deshalb aber pauschal bei Kennwörtern zu bleiben, von denen seit Jahrzehnten bekannt ist, wie schlecht die Lösung ist, ist zu kurz gesprungen. Gruß, Nils

Moin, genau. Wie auch der erste Vorschlag schon sagte. Genauer: Eine Gruppe, die das kann. Und in diese Gruppe einen separaten Admin-User für jeden Mitarbeiter, der das können soll. Separat zum normalen Account. Gruß, Nils

Moin, dann würde ich für diesen Spezialfall nicht groß recherchieren, wenn es eigentlich keine Probleme gibt. Was DNS betrifft, prüfe noch mal dies: [Was muss ich beim DNS für Active Directory beachten? (Reloaded) | faq-o-matic.net] https://www.faq-o-matic.net/2007/01/09/was-muss-ich-beim-dns-fuer-active-directory-beachten-reloaded/ Gruß, Nils

Moin, warum ist es wichtig, das herauszufinden? Reicht es nicht, das Objekt im AD in so einem Fall zu löschen? Falls es einen plausiblen Grund gibt, das zu lösen, braucht man die genaue Fehlermeldung, keine sinngemäße Beschreibung. Gruß, Nils