NilsK

Moin, suche nach "PowerShell Environment Variable". Gruß, Nils

Moin, laut den Fundstellen im Web gibt es eine ganze Menge an Ursachen für das Phänomen. Als Workaround könntest du einen geplanten Task einrichten, der den Dienst neu startet. Um das Problem dann zu lösen, würde ich einen Call beim Hersteller in Erwägung ziehen. Gruß, Nils

Moin, ich bin mir sicher, dass du mit einer Suche nach dynamischen Verteilergruppen in Exchange ausreichend Material findest. Gruß, Nils

Moin, und auf welchem der DCs besteht das Problem mit dem DFS-Dienst? Besteht das Problem auch, wenn du die Datensicherung temporär abschaltest? Was wurde genau unternommen, als das DFS "repariert" wurde? Gruß, Nils

Moin, wie wird die Datensicherung denn ausgeführt? Gruß, Nils

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

Moin, üblicherweise schreiben wir hier keine vollständigen Skripte. Wir helfen dir gern aufs Pferd, aber Reiten musst du selbst. Da ich gerade Lust drauf hatte, hier ein Skriptschnippsel, der dir die Ordnerstruktur auf einer lokalen Platte erzeugt. Wie du das in S3 umsetzt, musst du selbst sehen. Das Kopieren musst du dann auch noch einbauen. $FolderPath = 'C:\Quelle\Pfad' $TargetPath = 'E:\Ziel\Pfad\' $Folder = Get-ChildItem -Path $FolderPath -Filter *.gz foreach ($File in $Folder.GetEnumerator()) { $Name = $File.Name $Parts = $Name.Split('_') if(!(Test-Path -Path ($TargetPath + $Parts[0]) )){ New-Item -ItemType directory -Path ($TargetPath + $Parts[0]) } if(!(Test-Path -Path ($TargetPath + $Parts[0] + '\' + $Parts[1]) )){ New-Item -ItemType directory -Path ($TargetPath + $Parts[0] + '\' + $Parts[1]) } } Gruß, Nils

Moin, wird man nicht brauchen. An der SID-Zuordnung ändert sich ja nix. Gruß, Nils

Moin, der einfachste Weg wäre, die DMZ als AD-Site zu definieren und in dieser Site nur einen DC zu haben. Dann das Subnet der DMZ dieser Site zuordnen. Dadurch würden die Server aus der DMZ immer primär diesen DC anzusprechen versuchen. Allerdings hat das den Nachteil, dass dieser DC im Normalbetrieb von keinem anderen Client verwendet wird. Wird man also kaum wollen. Grundsätzlich kann man auch per Registry spezifische DCs vorgeben - meine ich zumindest. Da ich das allerdings für einen sehr schlechten Weg halte, recherchiere ich das nicht weiter. Das müsstest du dann selbst suchen. Ändere das Design. Alles andere ist Murks. Gruß, Nils

Moin, dein Problem ist, dass das Konstrukt nicht besonders sinnvoll ist. Ein Rechner in der DMZ hat typischerweise nichts in der Domäne im LAN zu suchen. Umgekehrt sind solche Gateways heute typischerweise nicht mehr in der DMZ lokalisiert, sondern werden über Konstrukte wie Reverse Proxies angesprochen. Ob das bei einem RDS-Gateway auch gilt, kann ich mangels Fachschwerpunkt an der Stelle nicht sagen. Da dein RDS-Gateway normales Domänenmitglied ist, nutzt es die normalen Kommunikationswege zum AD, also alle verfügbaren DCs. Das einzuschränken, wäre wenig sinnvoll, denn dann würde der Ausfall eines DCs zum vollständigen Funktionsverlust des Gateways führen. Gruß, Nils

Moin, die Konten- und Rollentrennung ist ein sinnvoller Ansatz. Sinn ergibt das aber nur, wenn man es ordentlich plant und organisatorisch verankert. Ein erster Schritt besteht darin, die Rollen ausführlich zu definieren und davon abzuleiten, welche Berechtigungen tatsächlich nötig sind. Man kommt dann i.d.R. schnell zu der Einsicht, dass man fast keine Domänen-Admins braucht, weil kaum eine Aufgabe das wirklich braucht. Eine Erweiterung des Ansatzes ist "Administrative Tiering", in dem man Server und Clients in mehrere Sicherheitszonen einteilt (gängiger Aufbau sind drei Zonen) und über Berechtigungen, Anmeldebschränkungen usw. sicherstellt, dass ein Admin-Account sich immer nur in einer bestimmten Zone anmelden kann. Wer Arbeiten in mehr als einer Zone zu erledigen hat, braucht dann pro Zone einen separaten Account. (Ich nehme mal an, dass Dukel sowas auch meint.) Ich verstehe es hoffentlich richtig, dass hier von Rollen die Rede ist, nicht von gemeinsam genutzten Accounts? In so einem Konstrukt darf man nur mit personalisierten Konten arbeiten, niemals mit gemeinsam genutzten Konten. Sonst kann man sich den ganzen Aufwand sparen. Gruß, Nils

Moin, dieser Skriptschnipsel teilt die Dateinamen eines Ordners beim Unterstrich als Trennzeichen auf. foreach ($File in $Folder.GetEnumerator()) { $Name = $File.Name $Prefix = $Name.Split('_')[0] # hier passiert was } Hinterher steht der Teil vor dem ersten Unterstrich in $Prefix. Da der zweite Teil bei dir die Personalnummer ist, kannst du den mit $Name.Split('_')[1] in eine Variable stecken. Eleganter wäre es natürlich, die Teile in ein Array zu schreiben, deren Elemente du dann in ähnlicher Form direkt ansprechen kannst, das erspart den mehrfachen Aufruf der Split-Methode (wobei das kaum ins Gewicht fällt). Dann nimmst du die beiden Variablen, um die Ordner anzulegen, falls sie noch nicht existieren. Dort kopierst du dann die Datei hin. Gruß, Nils

Moin, dir ist bewusst, dass es in dem Szenario zu Datenverlusten kommen kann? User A ist mit Server 1 verbunden und ändert dort Text.docx. User B ist zur selben Zeit mit Server 2 verbunden und ändert ebenfalls Text.docx. Da es sich um getrennte Server handelt, gibt es keine Sperre des anderen Users. Nun speichert User A das Dokument, das er auf 100 Seiten erweitert hat. Fünf Minuten später speichert User B das Dokument mit 5 Seiten. Und jetzt kommt dein Sync ... So ein Problem lässt sich nur durch organisatorische Regeln lösen. Wenn das bei dir gegeben ist, ist der Aufbau evtl. brauchbar. Kannst du es nicht garantieren, solltest du die Finger davon lassen (genau wie von jeder anderen Replikationslösung). Gruß, Nils

Moin, wenn Quick Migration funktioniert, Live Migration aber nicht, ist es unwahrscheinlich, dass die VM-Konfiguration das Problem darstellt. Möglicherweise ist was zwischen den Hosts nicht okay: Netzwerktreiber, Netzwerkkonfig, Jumbo Frames ... Gruß, Nils

Moin, mit dem Alter der beteiligten CPUs hat die Option nichts zu tun. Das ist korrekt, aber wie immer eine Frage der Anforderungen. Wenn man die erweiterten Kommandos nicht oder nur selten braucht, kommt es auf die Option nicht an. Wenn doch, muss man eben abwägen, was wichtiger ist. Hyper-V lässt das Setzen der Option nur zu, wenn die VM abgeschaltet ist. Gruß, Nils

Moin, geben die Eventlogs mehr her? Insbesondere die unter Dienst- und Anwendungsprotokolle. Sonst kann auch eine Suche nach der ID und Quelle Anstöße geben: https://www.google.de/search?q=event+id+21111+hyper-v-high-availability Die CPU-Kompatibilitätsmaske ist "fest", d.h. sie blendet alles aus, was "zu neu" ist. [Was die Prozessorkompatibilität in Hyper-V wirklich tut | faq-o-matic.net] https://www.faq-o-matic.net/2013/09/23/was-die-prozessorkompatibilitt-in-hyper-v-wirklich-tut/ Gruß, Nils

Moin, sechs Stunden Recherche sind zum Aufbau einer AD-Struktur ja nicht besonders viel. Insbesondere, wenn man sich auch gleich noch mit Spezialitäten wie Änderungen in der Infrastruktur beschäftigt. Nimm dir mehr Zeit, wenn du einen Lernerfolg haben willst. Und fang nicht gleich mit den großen Dingen an. Die Fehlermeldungen, die du erhalten hast, sind in der Situation alle normal und erwartbar. Im Kern sagen sie alle nur aus, dass der eine DC nicht erreichbar ist (natürlich nicht, er ist ja auch aus). Sofern das AD ansonsten korrekt konfiguriert ist, würden Clients es nicht bemerken, wenn einer der DCs nicht da ist. Der Gruppenrichtlinien-Editor ist da ein Sonderfall, weil er von sich aus immer versucht, auf den PDC-Emulator zuzugreifen. Sagt man ihm, dass er einen anderen DC nehmen soll, dann kann er auch arbeiten. Die zitierten Fehlermeldungen deuten alle nicht auf ein grundlegendes Problem hin. Das Ändern der IP-Adresse eines DCs erfordert in den meisten Umgebungen keine große Downtime und auch keinen Neustart. Trotzdem ist das natürlich eine Änderung, die man in einem produktiven Netzwerk nicht "mal eben" machen würde. In der Regel ist jeder DC auch GC. Die FSMO-Rollen sind für den Normalbetrieb nahezu egal, man braucht sie nur in speziellen Situationen. Wichtig ist vor allem die korrekte DNS-Konfiguration. [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/ [AD: Betriebsmaster-Ausfall – was tun? | faq-o-matic.net] https://www.faq-o-matic.net/2010/09/09/ad-betriebsmaster-ausfall-was-tun/ Gruß, Nils

Moin, handelt es sich um Exchange? Dann wäre eine dynamische Verteilergruppe sicher sinnvoller. Gruß, Nils

Moin, das Ding ist noch im Werden. In den Vorabversionen waren kaum sinnvolle Tests möglich. Auch die Doku war bislang wenig erschöpfend. Bevor man das einsetzt, sollte man also Zeit in Forschung und Entwicklung investieren. Für einfache Standardszenarien könnte es aber eine Erleichterung sein. Ich gehe aber davon aus, dass man auch Dateien migrieren kann, auf die der Zugriff eingeschränkt ist. Dafür gibt es in Windows seit ca. 1993 passende Mechanismen. Gruß, Nils

Moin, würde ich auch sagen. Folgeprodukt: net send NG. Gruß, Nils

Moin, *lol* Du könntest das jetzt noch erweitern auf Rechner, die sich in den letzten X Tagen angemeldet haben (lastLogonTimestamp). Und die dann anpingen. Gruß, Nils

Moin, hier im Board über 3500 Suchergebnisse zum Thema. Und eine Antwort, die sich durchzieht: Nicht verwenden. Die Funktion ist aus den Achtzigern und war für sehr kleine Netzwerke gedacht. Schon dort war sie aber nie zuverlässig. Gruß, Nils

Moin, was "warum"? Wonach fragst du? Gruß, Nils

Moin, nein, ich meine ein separates Produkt, das die Daten aus der Journal-Mailbox in ein Archiv überführt. Die Journal-Mailbox ist nur als temporärer Container gedacht. Gruß, Nils

Moin, was ja auch nicht von der Hand zu weisen ist ... nur muss man dann eben zu der richtigen "einmaligen" Lizenz greifen, nicht zur falschen. Gruß, Nils