NilsK

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

Moin, puh, komm mal wieder runter ... Kann man versuchen, aber ich würde weder darauf warten noch darauf hoffen. Es gibt eine ganze Reihe von Indizien, dass "Microsoft" bei solchen optischen Dingen geringe Prioritäten sieht. Daher meine Anregung, nach Wegen zu suchen, die eigentliche Anforderung zu lösen - es geht ja hier nicht um das Startmenü, das ist nur ein Werkzeug. Es geht darum, Programme unterschiedlich aufrufbar zu machen. Das alte Werkzeug funktioniert nicht mehr - ich würde dann nach einem anderen suchen. Kann man aber so halten, wie man das selbst will. Gruß, Nils

Moin, naja, ob deshalb das OS nicht zu gebrauchen ist ... Mögliche Workarounds, die mir spontan einfallen: Die Links auf den Desktop tun, die Links in einen Ordner tun, der auf dem Desktop liegt, ein separates Programm als Startmenü-Ersatz nutzen (gibg ja genügend). Gruß, Nils

Moin, abseits von Failover-Szenarien ist Teaming oder Multichannel dann interessant, wenn es mehrere Netzwerkstreams gibt, wie ich in meiner ersten Antwort sowie in dem dort verlinkten Thread ja auch schon ausgeführt habe. Also etwa zwei VMs auf einem Host, die jeweils einen Stream unterhalten. Gruß, Nils

Moin, der Hinweis auf SMB3 war jetzt nur aus der Ecke des Hinterkopfs. Vermutlich würde das in dem Szenario auch nichts bringen. Siehe die Diskussion hier: https://social.technet.microsoft.com/Forums/windows/en-US/07088d19-b9a9-4820-af1e-5ffbbcfb4efa/smb-3-multichannel-file-transfer-speeds-between-multiple-gbit-links-and-one-10gbe-link?forum=winserver8gen Allgemein sollte man immer im Kopf behalten, dass mehrere Netzwerkkarten nicht automatisch höheren Durchsatz bedeuten, weder mit Teaming noch mit sonstigen Protokollen. Es ist immer eine Frage des konkreten Szenarios. Gruß, Nils

Moin, ich kann es aus dem Kopf nicht genau sagen, aber ohne SMB3 wäre es in dem Szenario vermutlich so, dass der Durchsatz nicht steigt. Gruß, Nils

Moin, beachte dabei, dass zwei Gigabit-Karten nur in bestimmten Fällen "zwei Gigabit" als "Bandbreite" ergeben. Das klappt nur dann, wenn der Typ des Netzwerktraffics eine Parallelisierung zulässt. Gruß, Nils

Moin, korrekt, man braucht sie und sie werden neu erzeugt. Damit das aber vorhersagbar funktioniert, sollte man die Alteinträge vorher manuell löschen. Gruß, Nils

Moin, bevor man Windows Server 2019 als DC einsetzt, sollte man prüfen, dass alle Applikationen damit klarkommen. Typischer Problemfall ist Exchange. Abgesehen davon, ist das auch eine Lizenzfrage - DC unter 2019 heißt, alle CALs müssen für 2019 sein. Ansonsten ist das Verfahren aus dem ersten Post machbar, aber nach dem Herunterstufen und Umbenennen des Alt-DCs sollte man noch die Metadaten in DNS manuell bereinigen und prüfen, ob die Metadaten im AD korrekt entfernt wurden. Gruß, Nils