NilsK

Moin, so ist der Plan. Da die Aufzeichnungen i.d.R. noch nachbearbeitet werden, kann das ein paar Tage dauern. Gruß, Nils

Moin, dann wäre es vielleicht mal an der Zeit, über eine Verdrängungsarchivierung nachzudenken. Früher nannte man sowas auch HSM. Gruß, Nils

Moin, da "Ransomware" (man hört, dass es da mehr als ein Produkt gibt und man dort auch über v1.0 hinaus ist) schon seit langem auch in der Lage ist, Schattenkopien zu zerstören und Online-Backup-Lokationen zu erkennen und ebenfalls zu verschlüsseln, wird sie natürlich auch so etwas Simples wie ein eingebundenes OneDrive, Dropbox et al. mit verschlüsseln. Man braucht ein Backup, das im Normalbetrieb nicht erreichbar ist und das mehr als eine Version vorhält. Ist ja nun nix Neues. Gruß, Nils

Moin, die Frage ist prinzipiell berechtigt, aber es könnte sich ja auch um einen Agenten handeln. Gruß, Nils

Moin, wenn es eine Neuinstallation ist, also noch nie funktioniert hat, dann gibt es leider auch keinen Support durch Microsoft. Nur als Anmerkung. Gruß, Nils

Moin, Ich weiß von einem Buch über Hyper-V, in dem gerade die Themen Backup und - vor allem - Recovery sowie das Netzwerk-Design sehr ausführlich erklärt werden. Das ist zwar für die Version 2016 und neu nur noch als E-Book zu haben, aber trotzdem noch aktuell. Just saying. Gruß, Nils

Moin, SMB wäre ja kein Block Storage. Ist der Gigabit-Link wenigstens exklusiv für iSCSI? Gruß, Nils

Moin, also zweistufig. Backup to File, File to Tape. Wäre ja meist ohnehin das, was man will. Gruß, Nils

Moin, gemeint ist vor allem eine funktionale Trennung von Adminkonten. Ein Client-Adminkonto darf nicht genutzt werden, um auf einem Server zu administrieren. Und ein Serveradmin soll nicht das AD manipulieren. Umgekehrt soll sich ein AD-Admin gar nicht auf einem Client anmelden können usw. Vor allem Letzteres ist relevant: Keine Admins höherer Sicherheitsbereiche auf Rechnern niedrigerer Stufen - heißt: keine Anmeldung für deren Konten. Ein Weg dazu kann LAPS sein, wobei ich es insgesamt nicht so sehe, dass das der einzige Weg dazu wäre (zumal LAPS so toll nun auch wieder nicht ist). Schau mal nach "Administrative Tiering" und "ESAE". Gruß, Nils

Moin, Was meinst du mit inkrementell? Und warum willst du den Hypervisor sichern? Das macht man eigentlich nicht, das ist ja ein simples Blech, das normalerweise in einer halben Stunde neu installiert ist. Gruß, Nils

Moin, Es gab nur den einen DC? Das Problem hängt mit großer Sicherheit nicht mit dem Storage zusammen. Wäre das der Fall, dann würde eher die ganze VM nicht starten. Oder hast du am Ende die AD-Datenbank woanders gespeichert als in den Standardpfaden? Die gemeldeten Fehler deuten eher auf DNS-Probleme bin. Was sagt denn dass Ereignisprotokoll? Bloß jetzt nicht wild irgendwas ausprobieren. Gruß, Nils

Moin, Warum deklarierst du die ganzen Variablen, wenn du sie nicht verwendest? Deine Anforderung klingt so, als könntest du sie mit einem simplen SELECT mit JOIN lösen. Rein syntaktisch sieht das nicht verkehrt aus, aber mehr kann man dazu nicht sagen. Um sowas zu entwickeln, solltest du immer eine Testmöglichkeit haben. So theoretisch hat man Code in den Sechzigern gebaut, das macht man heute nicht mehr. Gruß, Nils

Moin, grundsätzlich geht das, es gibt aber ein paar Stolperstellen. Mit Suchbegriffen wie "hyper-v dedicated replication network" findest du eine ganze Menge dazu. Die Frage wäre jetzt eher die nach den Anforderungen und dem Konzept. Die Anforderung, dediziert über eine "Glasfaserstrecke" zu replizieren, klingt nach sehr viel Traffic. Typischerweise deutet sowas darauf hin, dass Replica nicht die richtige Lösung ist. Also: Was willst du denn erreichen? Gruß, Nils

Moin, um hier noch mal positiv beizutragen : Dazu musst du dir überlegen, was "volle Funktionalität" für dich bedeutet. "Ein AD" kann sehr unterschiedliche Dinge bezeichnen. Beispiel: Sind für dich die Dateiserver dabei? Die Berechtigungen? Applikationen, die per ADSI oder LDAP Daten aus dem AD nutzen? Gruppenrichtlinien auf unterschiedlichen Client-Versionen? usw. Ein sehr wichtiges Tool hast du ja schon genannt: dcdiag. Es gibt eine Reihe weiterer typischer Standard-Tools. Ein paar davon habe ich vor ein paar Jahren mal in eine Halb-Automatisierung gebracht, vielleicht bringt dich das schon mal weiter: [Angelo 1.3: AD-Meta-Reporting | faq-o-matic.net] https://www.faq-o-matic.net/2016/07/04/angelo-1-3-ad-meta-reporting/ Gruß, Nils

Moin, das ist auch keine Kunst. Das liegt nicht am HRZ, sondern am Credential Caching. Genau das ist die Nebelkerze: Natürlich funktioniert in dem Szenario DNS weiterhin, sodass die Clients auch ins Internet oder auf Hochschulressourcen kommen. Sie können dann aber nicht mehr auf die Institutsressourcen zugreifen, die über das AD gesteuert werden. Ob das noch ein sinnvolles Arbeitsszenario ergibt, müsst ihr euch überlegen. Drehen wir es mal um: Bei den Clients sind üblicherweise zwei DNS-Server eingetragen. Wenn die beim HRZ ausfallen - was geht dann noch? Vermutlich gar nichts mehr, nur noch die Anmeldung am Client. Keine internen Ressourcen, keine Hochschulressourcen, kein Internet. Nun kommt die Gretchenfrage: Das HRZ würde nun ziemlich sicher sagen: Ja, aber wir sind das HRZ. Unser DNS fällt nicht einfach komplett aus. Aus über 20 Jahren Erfahrung kann man mit Fug und Recht behaupten: Auch in einer kleinen Domäne fällt das DNS, das auf DCs läuft, nicht restlos aus. Und wenn doch - dann liegen Probleme vor, bei denen ein separat laufendes DNS auch keine Hilfe mehr wäre. Ihr habt die beiden DCs heruntergefahren - klar, dann kein AD mehr. Aber den gleichzeitigen Ausfall aller DCs kann man mit einfachen und zuverlässigen Mitteln so unwahrscheinlich machen wie den Ausfall zentraler HRZ-Systeme. Und dann kommt die Retourkutsche: Wenn das HRZ keine Zonen delegiert, weil sie selbst die Kontrolle über DNS haben wollen - warum delegieren sie dann ausgerechnet das Anlegen und Pflegen der eigentlichen DNS-Einträge? Die sind es doch, die man wirklich braucht und die die Funktion sicherstellen. Mit dem aktuellen Konstrukt, so könnte man begründet sagen, vermindert das HRZ nicht den Supportaufwand, sondern erhöht ihn. Das nur für die Fakten. Dass die Argumentation für ein Uni-Institut nicht einfach ist, weiß ich und verstehe ich. Aber das ist zu ungefähr 90 Prozent politisch, nicht technisch. Gruß, Nils

Moin, Nun ja, die Antwort vom HRZ ist zu Teilen korrekt, aber eigentlich eine Nebelkerze. Dass die Clients weiter arbeiten könnten, ist nicht die Leistung des HRZ. Aber lassen wir das. Schön, dass es jetzt geht, danke für die Rückmeldung. Gruß, Nils

Moin, das wurde schon in der ersten Antwort in diesem Thread vorgeschlagen. Angesichts der fehlenden Erfahrung des TO würde ich das aber auch bleiben lassen. Gruß, Nils

Moin, Ist da jetzt noch eine Frage dabei? Gruß, Nils

Moin, freut mich. Gruß, Nils

Moin, auch wenn ich mich wiederhole ... dann könnte der Vorschlag, dass das HRZ DNS-Zonen bzw. Subdomains an Institute delegiert, doch helfen. Minimaler Aufwand für das HRZ, hoher Nutzen für die Institute. Dann können die Institute ihr AD-DNS selbst betreiben und es gibt an der Stelle keinen weiteren Supportbedarf für das HRZ. Schwieriger dürfte da das Firewallthema sein, das nach deiner jüngsten Schilderung wohl eher der Kern des Problems ist. Gruß, Nils

Moin, ui, sowas heute noch in VBS zu machen ... ich sage mal voraus, dass dir hier einige zur PowerShell raten werden. Ich hab's nicht mehr genau im Kopf, aber es kann sein, dass das FileSystemObject keine Filter bei der Dateiauswahl kennt. Du müsstest das also selbst prüfen. Dazu hast du ja auch schon eine Zeile in deinem Code: If LCase(objFSO.GetExtensionName(objFile.Name)) = "xml" Then Hier könntest du die Bedingung mit AND um deine zweite Vorgabe zum Dateinamen ergänzen, vermutlich mit Instr(objFile.Name, "deine-Zeichenkette") > 0 Ist ungeprüft, versuch damit mal rum. Puh, VBS war schon gruselig. Gruß, Nils

Moin, [AD-Adressen im Sekretariat bearbeiten lassen | faq-o-matic.net] https://www.faq-o-matic.net/2008/06/23/ad-adressen-im-sekretariat-bearbeiten-lassen/ Keine Webseite, aber nah dran. Und das Prinzip ist übertragbar. Gruß, Nils

Moin, ganz abwegig ist dein Vorhaben nicht. Wenn es aber ordentlich, handhabbar und sicher funktionieren soll, braucht das ein gerüttelt Maß an Planung und an Kooperation. Ich empfehle, für die Konzeption erfahrene Unterstützung hinzuzuziehen. Wenn man sowas mit "mal gucken" aufbaut, geht es meist in die Hose. Dafür sind Domain Local Groups da. Das meine ich mit Konzeption - Berechtigungssysteme sind in so einem Konstrukt etwas spezieller. Gruß, Nils

Moin, um das noch mal zusammenzufassen: Active Directory ist auf funktionierende DNS-Auflösung angewiesen. Das gilt für alle Clients und alle Server, die Mitglieder sind. Das DNS kann durchaus "separat" laufen. Das erfordert dann aber erheblich mehr Aufwand und Mitarbeit der DNS-Administratoren. Es gibt eine ganze Reihe von Möglichkeiten, zu einer Koexistenz beider "Welten" zu kommen. Das funktioniert erfahrungsgemäß auch in großen Hochschulnetzen sehr gut. Natürlich protokolliert Windows Fehler, sehr ausführlich sogar. In komplexen Fehlersituationen kann es aber hohen Aufwand erfordern, die Logs auszuwerten und zu interpretieren, um den Fehlern auf die Spur zu bekommen. Das gilt für alle Betriebssysteme. Wir sind hier in einem Forum und können daher nur begrenzt unterstützen. Meiner Interpretation nach liegt dein Problem bei Punkt 2. Das kommt an Unis (leider) oft vor, aber erfahrungsgemäß ist es meistens möglich, von Punkt 2 zu Punkt 3 zu kommen. Reden hilft, unterstützen kann dabei jemand, der die technischen Hintergründe kennt und darstellen kann. Gruß, Nils

Moin, wenn es eigentlich um die Daten geht, ist das Kopieren der Dateien der einfachste Weg. Für Einzelfälle hatte sich für vollständige Profile in der Vergangenheit dies hier bewährt, scheint auch für Windows 10 zu gehen: [Benutzerprofile an neue Benutzer übertragen | faq-o-matic.net] https://www.faq-o-matic.net/2010/02/07/benutzerprofile-an-neue-benutzer-bertragen/ Gruß, Nils