11
Daten verschwinden aus Namespace
Hallo Kollegen,
ich habe ein Problem bei dem ich aktuell nicht weiter komme:
Um die Anzahl und die Struktur unserer Netzlaufwerke zu bereinigen haben wir uns entschlossen einen DFS Namespace aufzusetzen und die alten Netzlaufwerke durch Verknüpfungen im RootDFS zu ersetzen. Zugriffsbasierte Aufzählung ist aktiv, damit User Verknüpfungen nicht sehen, wenn keine Berechtigung besteht.
Wir haben in den Shares alle Arten von Dateien. Von PDFs, DOCs, bis hin zu kleinen Datenbanken für eine Anwendung mit vier Nutzern. Soweit funktioniert das alles auch.
Nun berichten die Leute von Problemen, dass die Verknüpfungen und die Ordner zwar verfügbar sind, aber manchmal darin keine Dateien zu finden sind.
Bsp: Ich habe das Home-Laufwerk über \\firma.local\abteilung\profiles$\%username% im Benutzerkonto eingebunden. Einige Leute haben darin PST-Dateien. Nun stürzt Outlook regelmäßig ab, da die PST-Dateien wohl nicht mehr verfügbar sind. Binde ich den Basisordner über \\servername\profiles$\%username% ein, gibt es keine Probleme.
Die DFS Namespaces werden von einen 2012R2 DC und einem 2019 DC bereitgestellt. Eine Replikation der Daten auf einen anderen Server finden nicht statt..
Hat jemand eine Idee? Ich bin mittlerweile echt am verzweifeln.
Cheers
MettGurke
EDIT: Ich weiß, dass die Frage sehr schwammig formuliert ist. Wenn Infos fehlen oder etwas unklar ist liefere ich gerne nach.
ich habe ein Problem bei dem ich aktuell nicht weiter komme:
Um die Anzahl und die Struktur unserer Netzlaufwerke zu bereinigen haben wir uns entschlossen einen DFS Namespace aufzusetzen und die alten Netzlaufwerke durch Verknüpfungen im RootDFS zu ersetzen. Zugriffsbasierte Aufzählung ist aktiv, damit User Verknüpfungen nicht sehen, wenn keine Berechtigung besteht.
Wir haben in den Shares alle Arten von Dateien. Von PDFs, DOCs, bis hin zu kleinen Datenbanken für eine Anwendung mit vier Nutzern. Soweit funktioniert das alles auch.
Nun berichten die Leute von Problemen, dass die Verknüpfungen und die Ordner zwar verfügbar sind, aber manchmal darin keine Dateien zu finden sind.
Bsp: Ich habe das Home-Laufwerk über \\firma.local\abteilung\profiles$\%username% im Benutzerkonto eingebunden. Einige Leute haben darin PST-Dateien. Nun stürzt Outlook regelmäßig ab, da die PST-Dateien wohl nicht mehr verfügbar sind. Binde ich den Basisordner über \\servername\profiles$\%username% ein, gibt es keine Probleme.
Die DFS Namespaces werden von einen 2012R2 DC und einem 2019 DC bereitgestellt. Eine Replikation der Daten auf einen anderen Server finden nicht statt..
Hat jemand eine Idee? Ich bin mittlerweile echt am verzweifeln.
Cheers
MettGurke
EDIT: Ich weiß, dass die Frage sehr schwammig formuliert ist. Wenn Infos fehlen oder etwas unklar ist liefere ich gerne nach.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 571431
Url: https://administrator.de/forum/daten-verschwinden-aus-namespace-571431.html
Ausgedruckt am: 22.12.2024 um 13:12 Uhr
11 Kommentare
Neuester Kommentar
Hi,
am Rande, es hilft nicht für Dein Problem:
Benutzer-Basisverzeichnisse unter einem Ordner Namens "profiles$" abzulegen, halte ich für taktisch sehr unklug. Der Begriff "Profil" ist in diesem Kontext schon durch etwas anderes belegt und Benutzer-Basisverzeichnis ist ungleich Benutzer-Profil. Irgendwann kommt da mal irgendwer komplett durcheinander, und sei es nur ein hinzugeholter Dienstleister.
Sind auf beiden Stammservern jeweils in deren Freigabe für den DFS-Stamm die Links zu den DFS-Ordnern erstellt worden?
E.
am Rande, es hilft nicht für Dein Problem:
Benutzer-Basisverzeichnisse unter einem Ordner Namens "profiles$" abzulegen, halte ich für taktisch sehr unklug. Der Begriff "Profil" ist in diesem Kontext schon durch etwas anderes belegt und Benutzer-Basisverzeichnis ist ungleich Benutzer-Profil. Irgendwann kommt da mal irgendwer komplett durcheinander, und sei es nur ein hinzugeholter Dienstleister.
Sind auf beiden Stammservern jeweils in deren Freigabe für den DFS-Stamm die Links zu den DFS-Ordnern erstellt worden?
E.
Hi emeriks,
danke für das Feedback:
danke für das Feedback:
Benutzer-Basisverzeichnisse unter einem Ordner Namens "profiles$" abzulegen, halte ich für taktisch sehr unklug. Der Begriff "Profil" ist in diesem >Kontext schon durch etwas anderes belegt und Benutzer-Basisverzeichnis ist ungleich Benutzer-Profil. Irgendwann kommt da mal irgendwer >komplett durcheinander, und sei es nur ein hinzugeholter Dienstleister.
Die Benutzerprofile werden nicht mit dem Server synronisiert. So viel Platz habe ich leider nicht. Aber danke für das Feedback. Ich werde das in Zukunft in Betracht ziehen.Sind auf beiden Stammservern jeweils in deren Freigabe für den DFS-Stamm die Links zu den DFS-Ordnern erstellt worden?
Meinst du die DFSRoots unter "C:\DFSRoots"? Die gibt es nur auf dem 2012DC. Meinst du, dass ich die Links auf dem 2019DC manuell erstellen sollte? Ein Versuch ist es wert. Ich würde das dann einmal versuchen.
Nein, nichts manuell erstellen!
Aber das erklärt.
Den 2019' hast Du als zweites Ziel dem DFS-Stamm hinzugefügt?
Und er hat auf dem 2019' nicht diese Links erstellt? Vielleicht sind diese bloß versteckt? Oder Du hast dort im Ordner andere Berechtigungen eingetragen als auf dem 2012'?
Aber das erklärt.
Den 2019' hast Du als zweites Ziel dem DFS-Stamm hinzugefügt?
Und er hat auf dem 2019' nicht diese Links erstellt? Vielleicht sind diese bloß versteckt? Oder Du hast dort im Ordner andere Berechtigungen eingetragen als auf dem 2012'?
Hi Emeriks,
Ich habe den DC2019 über "Namespaceserver hinzufügen" als weiteres Ziel eingetragen. Der Ordner DFSRoots wurde automatisch erstellt. Auch die Verknüpfungen in den Namespaces wurden automatisch erstellt.
MettGurke
Ich habe den DC2019 über "Namespaceserver hinzufügen" als weiteres Ziel eingetragen. Der Ordner DFSRoots wurde automatisch erstellt. Auch die Verknüpfungen in den Namespaces wurden automatisch erstellt.
MettGurke
Ach nun doch. Na dann vergiss diesen Ansatz.
Ich bin mir aber unsicher, ob das wirklich der Auslöser ist, da der zweite DFS-Namespace Server erst seit letzter Woche besteht, die Probleme aber schon früher angefangen haben.
Auch wieder am Rande, hat nichts speziell mit DFS zu tun.
Meines Wissens ist es von Microsoft explizit genannt, dass PST über LAN nicht unterstützt werden, weil eben sehr fehleranfällig.
Du könntest versuchen, die Offlinefiles zu aktivieren. Das Homedirectory sollte dann standardmäßig automatisch in dieses aufgenommen werden. Damit würde Outlook immer mit der lokalen Kopie arbeiten.
Meines Wissens ist es von Microsoft explizit genannt, dass PST über LAN nicht unterstützt werden, weil eben sehr fehleranfällig.
Du könntest versuchen, die Offlinefiles zu aktivieren. Das Homedirectory sollte dann standardmäßig automatisch in dieses aufgenommen werden. Damit würde Outlook immer mit der lokalen Kopie arbeiten.
Hi emeriks,
Cheers
MettGurke
Meines Wissens ist es von Microsoft explizit genannt, dass PST über LAN nicht unterstützt werden, weil eben sehr fehleranfällig.
Das denke ich mir auch. Das generelle Abschaffen von PST-Files steht auch noch auf dem Plan. Komischerweise macht es keine Probleme, wenn ich das Home Directory über die direkte Freigabe auf dem Server mounte.Du könntest versuchen, die Offlinefiles zu aktivieren. Das Homedirectory sollte dann standardmäßig automatisch in dieses aufgenommen werden. Damit würde Outlook immer mit der lokalen Kopie arbeiten.
Um Outlook geht es mir primär nicht. In dieser Abteilung werden ca. 5 verschiedene Anwendungen verwendet. Die Datenbank liegt auf dem Share. Die Anwendungen schmieren mehrmals täglich ab weil nicht auf die Speicherorte zugegriffen werden kann. Sobald ich das Laufwerk über den Servernamen statt über den Namespace einbinde, hören die Probleme auf. Ich kann mir das beim besten Willen nicht erklären was da los ist.Cheers
MettGurke
OK. Noch ein Ansatz:
Du schreibst, der 2019' hat nichts geändert, es war vorher schon so. Vielleicht ist der 2012' das Problem? Nimm diesen doch mal für ne Weile aus dem Stamm.
Du schreibst, der 2019' hat nichts geändert, es war vorher schon so. Vielleicht ist der 2012' das Problem? Nimm diesen doch mal für ne Weile aus dem Stamm.
Zitat von @emeriks:
OK. Noch ein Ansatz:
Du schreibst, der 2019' hat nichts geändert, es war vorher schon so. Vielleicht ist der 2012' das Problem? Nimm diesen doch mal für ne Weile aus dem Stamm.
OK. Noch ein Ansatz:
Du schreibst, der 2019' hat nichts geändert, es war vorher schon so. Vielleicht ist der 2012' das Problem? Nimm diesen doch mal für ne Weile aus dem Stamm.
Einen Versuch ist es wert. Ich habe den DC2012 mal entfernt und warte auf Feedback.
Sonst noch jemand eine Idee?
EDIT: Nach einigen Tagen in der Beobachtung kann ich sagen, dass der DC2012 scheinbar das Problem war. Die Namespaces liegen jetzt ausschließlich auf dem DC2019. Seit dem gibt es keine Probleme mehr. Erklären kann ich mir das zwar nicht, dennoch DANKE @emeriks
