NilsK

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

Moin, nein, die Schlussfolgerung ist falsch. Ich würde mit dem Kunden in Ruhe sprechen und dabei auch das ganze Vorhaben zur Diskussion stellen, eine neue Domäne aufzumachen. Meist ist das technisch gar nicht nötig. Das Argument mit "alles neu, dann haben wir keine Altlasten" kommt in 100% der Fälle quasi aus der Pistole. Ich habe es aber in 0 Prozent der Fälle als umsetzbar erlebt. Spätestens wenn dem Kunden am Montag nach der Umstellung klar wird, dass sein Helpdesk vor lauter "ich kann nicht zugreifen" nicht mehr arbeiten kann, merkt er, dass das keine gute Idee war. Gruß, Nils

Moin, richtig beobachtet. Wenn man das geregelt haben will, braucht man zusätzliche Logik oder kommerzielle Tools, die sowas beherrschen. Bestimmte Dinge lassen sich aber auch nicht automatisieren - es gibt schon sehr viel, was Admins sich so einfallen lassen, was aber kein Toolentwickler auf dem Schirm hat. Gruß, Nils

Moin, klappt hier problemlos. Hast du dich neu angemeldet, nachdem du deinen Account den Hyper-V-Administratoren hinzugefügt hast? Kann es sein, dass du im Hyper-V-Manager den lokalen Computer noch nicht als zu verwaltenden Host hinzugefügt hast? Gruß, Nils