NilsK

Moin, wenn man sich ansieht, wie das funktioniert, ist das nicht erstaunlich. Der ganze Ansatz ist von vorn bis hinten krank. Selbst wenn man bereit ist, den ganzen Aufwand mitzumachen, hat man am Ende nur die Hoffnung, dass man der anderen Seite vertrauen kann. Und selbst wenn man das tut, hat man hinterher das Problem, dass der eigene Datenbestand gefährdet ist, weil man vielleicht den einen Schlüssel verliert, mit dem man wieder rankommt. Und selbst ... ach ja. Gruß, Nils

Moin, die Frage ist durchaus knifflig und lässt sich nur beantworten, wenn man sich Gedanken um die Anforderungen und den leistbaren Aufwand macht. In dem Szenario, dass jemand die ganze Anlage klaut, werden dir sowohl die hostbasierte als auch die VM-basierte Festplattenverschlüsselung vor allem dann etwas bringen, wenn sie den Host bzw. die VM ohne Authentisierung am Starten hindern. Anderenfalls könnte ein Anlagendieb die Anlage einfach starten, alles liefe, und dann könnte er die laufenden Systeme angreifen, die dann ja entschlüsselt sind. Die Sicherheit hinge dann nur noch an den Kennwörtern und am Patchlevel (vereinfacht gesagt). Durch so eine Verschlüsselung (mit "Pre-boot Authentication") wird der Betrieb aber sehr umständlich: Bei jedem Reboot müsste ein Admin eingreifen, der den Startprozess freischalten kann. Das führt in kleinen Umgebungen dazu, dass man es schnell wieder abschaltet oder dass man sich Vereinfachungen schafft (z.B. indem man den Key auf einem Stick speichert, den man gesteckt lässt). Letzteres will man nicht, weil man damit die Sicherheit aushebelt. Vielleicht ist "Diebstahl der ganzen Anlage" aber auch gar kein relevantes Szenario. Das muss man prüfen. Wie bei jeder Risikobetrachtung steht die Frage im Mittelpunkt, welches Risiko denn zu behandeln ist. Gruß, Nils

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

Moin, für mich sieht es spontan so aus, als gebe es bei eurem VPN Zugriffsprobleme. Gruß, Nils

Moin, zunächst wäre die AD-Umgebung zu prüfen, ob Fehler gemeldet werden. Die Ausgabe von dcdiag /E > C:\pfad\dcdiag.txt ist da hilfreich. Typischerweise liegen Fehler bzw. Phänomene dieser Art an inkorrekten oder unvollständigen Site- und Subnetkonfigurationen. Ob etwa Subnets fehlen, lässt sich in den Eventlogs der DCs an Warnmeldungen sehen, zu denen eine Text-Logdatei gehört (ist in den Events benannt). Eine Auswertung der Site-Konfiguration kannst du z.B. hiermit machen: [Borg: AD-Standorte dokumentieren | faq-o-matic.net] https://www.faq-o-matic.net/2007/04/28/borg-ad-standorte-dokumentieren/ Die FSMO-Rollen haben nicht damit zu tun. Möglich (wenn auch wenig wahrscheinlich) wäre aber, dass dem DC an Standort B die Rolle "Global Catalog Server" fehlt. Zudem wäre die DNS-Konfiguration der Clients zu prüfen, die primär den DC des eigenen und sekundär den des anderen Standorts ansprechen sollten. Gruß, Nils

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

Moin, sieht so aus, als sei im DNS deiner Fritzbox die IP-Adresse mit der .14 für den Namen "nas5" eingetragen. Gruß, Nils

Moin, entweder man braucht die Domäne nicht. Dann weg damit, bevor noch Fehler in anderen Teilen der Umgebung entstehen. Oder man braucht sie - dann würde ich 300 Euro für einen MS-Call ausgeben, statt abzuwarten und in Foren zu stochern. Nur meine 0,02 EUR, Nils

Moin, Wenn dir die Daten im AD nicht ausreichen, dann kannst du mit deinem Kommando die Daten im Login-Skript auslesen und die Datei auf ein zentrales Share kopieren. Gruß, Nils

Moin, dies hier dürfte im Prinzip immer noch zutreffen: [Hyper-V Replica: Wie lizenziert man das? | faq-o-matic.net] https://www.faq-o-matic.net/2014/05/12/hyper-v-replica-wie-lizenziert-man-das/ Gruß, Nils PS. und da Norbert auch den technischen Teil anspricht - erstens ist Replikation natürlich kein Backup, zweitens passt so ein Szenario längst nicht immer, drittens gibt es technische Hürden und viertens können natürlich auch die Lizenzbestimmungen von Drittanbietern ins Spiel kommen.

Moin, na, wenn das so ist, löse die Subdomain auf ... das ist sowieso ein Konstrukt, das fast nie nützlich ist. Gruß, Nils

Moin, ein Tipp vorab: Vermutlich möchtest du die Angaben oben noch mal anonymisieren. Da steht ein Domänenname, der vermutlich Aufschluss über das Unternehmen gibt. Den Rest müsste ich mir genauer ansehen, dazu fehlt mir gerade die Zeit. Da man solche Fehler nicht will und es anscheinend nicht um eine 5-Leute-Umgebung geht, würde ich an deiner Stelle umgehend den MS-Support einschalten. Gruß, Nils

Moin, da man Backup-Probleme nicht will, würde ich nicht lange fackeln und einen Call bei Microsoft aufmachen. Gruß, Nils

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

Moin, die Meldung kommt eigentlich nur, wenn das dort genannte Phänomen auftritt: Es gibt bereits eine Session zu dem Server von dem Client aus unter anderem Benutzernamen. Daher mutmaße ich mal: Der Share liegt auf einem Server, auf dem ihr auch "normale" Daten ablegt, und von jedem Client aus hat der dortige "Hauptnutzer" bereits eine Session offen. Gruß, Nils

Moin, läuft Veeam auf demselben Rechner? Dann ist das der Grund, dort ist schon eine Session offen. Gruß, Nils

Moin, ach so. Da würde ich es mir einfach machen und per Logonskript den Namen des Rechners und des Users in eine zentrale Datei schreiben lassen. Nach ein paar Tagen hast du die Daten beisammen. Ansonsten wird diese Frage hier häufiger diskutiert, für weitere Lösungsansätze hilft also vielleicht auch eine Boardsuche. Auch der übliche Hinweis sei gegeben: Eine solche Auswertung kann mitbestimmungspflichtig sein bzw. einen Betriebsrat alarmieren, daher ggf. vorher abstimmen. Gruß, Nils

Moin, was ist denn das Ziel dahinter? Gruß, Nils

Moin, kommt drauf an. Das ist eine Anforderung, die sich so fast nur im Privatbereich stellt. Die meisten hier sind im Business-Bereich unterwegs. Zu dem Thema lässt sich die c't gern aus, das ist dort ein Steckenpferd von Axel Vahldieck. Ich würde da mal die Suche bemühen und den einen oder anderen Artikel für ein paar Cent erwerben. Spontan fiele mir als möglicher Ansatz ein, die zweite Installation nicht nativ zu machen, sondern in eine VHDX zu installieren. Das ist dann auch Dual Boot, könnte aber weniger Gehöddel mit dem Bootsektor geben. Gruß, Nils

Moin, korrekt. Die Programmdateien werden im Wesentlichen nur einmal angefasst, um sie zu starten. Vielleicht hier und da noch mal eine DLL, aber das ist irrelevant. In einer Datenbank, die mit vielen Änderungen unter Dampf ist, sollte vor allem das Transaktionsprotokoll auf schnellem Speicher liegen. Das kann sogar noch wichtiger sein als die Datenbankdateien selbst - aber das hängt sehr stark von der Art der Nutzung ab. Datenbanken sind sehr unterschiedlich; was bei der einen gut ist, kann bei der anderen völlig falsch sein. Gruß, Nils

Moin, deiner Beschreibung nach könnte es sein, dass der Hyper-V-Manager, als User gestartet, einfach nicht mit einem Host verbunden ist. Das sollte sich per Rechtsklick auf den das Icon "Hyper-V Manager" im linken Fensterteil ändern lassen. Gruß, Nils

Moin, dann ist das ja prima, dass es für euch passt und ihr zufrieden seid. Gruß, Nils

Moin, ist die Datei index.php als gültige Startseite hinterlegt? Vermutlich hast du damals an der Stelle den Dateinamen deiner Umleitungsseite angegeben. Mangels IIS kann ich gerade nicht nachsehen, wo die Einstellung genau ist, sollte sich aber finden lassen. Gruß, Nils

Moin, ja, was ich meine, ist schwierig auszudrücken ... also: typischerweise führe ich whoami auf meinem Client aus. Dann sehe ich die effektiven Mitgliedschaften - und Lokalen Gruppen - dieses Clients. Greife ich vom Client aus aber auf einen Dateiserver zu, dann kann es sein, dass ich auf dem Server auch Mitglied Lokaler Gruppen bin. Diese zeigt mir whoami logischerweise nicht auf meinem Client, sondern um das zu sehen, müsste ich whoami auf dem Server ausführen. Es bleibt in jedem Fall der Vorteil, dass whoami sehr schnell und effizient über die effektiven (d.h. vollständig in der Verschachtelung aufgelösten) AD-Gruppenmitgliedschaften Auskunft gibt, und das ohne Netzwerkzugriff. Gruß, Nils

Moin, okay, das ist ein valider Grund für eine neue Domäne. In dem Szenario würde ich auf keinen Fall mit SID History arbeiten, denn das würde der ausgegründeten Firma eine logische Verbindung zur Altdomäne verschaffen. Solche Informationen haben dort nichts zu suchen. Ebenso würde ich keine Berechtigungseinträge der Altumgebung übernehmen, denn dafür gilt dasselbe: Es geht die neue Firma nichts an, wer aus der "alten" Firma auf die Daten zugreifen konnte. Bleibt also nur der Neuaufbau. Man mache sich aber nichts vor: Berechtigungen neu aufzubauen, ist eine umfangreiche Aufgabe. Auch bei "nur" 50 Usern. Gruß, Nils