Jump to content

olc

Expert Member
  • Gesamte Inhalte

    3.978
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von olc

  1. In diesem Fall solltest Du vorsichtshalber in jedem Fall Hotfix Distributed File System Replication in Windows Server 2003 R2 performs unnecessary replication when an antivirus application is installed installieren. Wie oben schon gesagt - damit hast Du die Erklärung für die Events. Du kannst mit FSRM, das beim R2 Server mit dabei ist, auch Dateitypen sperren. Ist aber aufgrund der oben genannten Hintergründe erst einmal nicht mehr "wichtig"... Windows Server 2003 R2 Simplifies Storage Management Ist - denke ich - nicht mehr notwendig. ;) Das bringt bei dem Fehlerbild jedoch nichts. Aber BTW: Woher hast Du diese Information? Würde mich interessieren, wie genau dieses Feature (distributed locking) implementiert werden soll... Gruß olc
  2. N'Abend, Dann hast Du damit die "Lösung" Deines Problems: Die Meldungen werden geloggt, wenn die Datei wegen Zugriffs gelockt ist. Das ist vollkommen normal und stellt, wenn diese Events nicht exzessiv geloggt werden, im Normalfall kein Problem da... Werden diese Events massiv geloggt, leidet darunter jedoch die Replikationsgeschwindigkeit / -performance. Hast Du Dir die Befehle angeschaut, die ich gepostet hatte? Damit kannst Du die IDs zuordnen. Wenn Du auf den Namespace zugreifst, z.B. "\\domain.tld\public", dann fragt der Client in der AD an, welche Namespaceserver verfügbar sind. Von diesen Namespaceservern erhält der Client dann die Verweise auf die Server, auf denen die Replikationsordner / Shares liegen. Schau mal in das HowTo auf Serverhowto.de, da wird darauf eingegangen. Das heißt also, daß der Client auf das Share zugreift, welches ihm am "nächsten" ist - im Normalfall ein Server an seinem Standort. Hierfür werden die Standorte der AD Sites & Services verwendet. Windows Server How-To Guides: Teil 1 - Verteilung von Namespaces auf verschiedene Server - ServerHowTo.de Ok, dann konntest Du die IDs der Replikationsgruppen also doch zuordnen. Nein, das haut so nicht ganz hin. Du mußt unbedingt unterscheiden zwischen den normalen Dateisperren, die halt auftreten, wenn mehrere Benutzer einen Datei öffnen wollen. Das ist unabhängig von DFS-N oder DFS-R. In Bezug auf DFS-R geht es ausschließlich um die Replikation, d.h. die Datei soll repliziert werden, ist jedoch gelockt. In diesem Fall versucht der DFS-R Dienst später wieder, die Datei zu replizieren. Dazu muß nur ein Benutzer die Datei geöffnet haben, kein zweiter Benutzer ist für dieses Verhalten "notwendig". Der dritte Punkt ist dann ein Konflikt beim Replizieren --> diese Thematik haben wir noch gar nicht bearbeitet, denn diese ist eine ganz andere Baustelle. Tritt ein solcher Konflikt auf, wird nicht das von Dir angegebene Event geloggt. Die Event ID lautet dann 4412 und die Event-Beschreibung ist (natürlich) eine andere... Windows Server How-To Guides: Teil 4 - Konflikterkennung bzw. Ablage von durch DFS-R gelöschter Dateien und Ordner - ServerHowTo.de ...unten geht es weiter...
  3. Hallo, was genau funktioniert denn nicht? Vielleicht kannst Du ein wenig genauer beschreiben, was Dein Problem ist...? Gruß olc
  4. Guten Abend, In diesem Fall kann die Lösung recht einfach sein: Es treten auch Zugriffsverletzungen auf, wenn temporäre Dateien geöffnet sind oder Dateien, die den Zugriff locken, wenn man sie öffnet - so z.B. Excel Dateien. Das wäre dann alles kein Problem, denn nachdem die Dateien nicht mehr gelockt sind, werden diese wieder repliziert. Wie oft treten denn diese Fehlermeldungen auf? Ordne den UIDs der oben genannten Datei doch einmal einen Dateinamen zu, indem Du die im Event genannte UID in den Backlogs Deines Servers suchst. Die Backlogs findest Du unter %SYSTEMROOT%\Debug\Dfsr####.log bzw. alte Dateien *.gz. Dann sehen wir, was das für Dateien bzw. insbesondere Dateitypen sind. Wenn Du an den DFS-N Einstellungen nichts geändert hast, dann greift der Client immer auf die Server seines Standortes zu, solange diese verfügbar sind. Man kann dieses Verhalten jedoch auch bearbeiten, indem man an den Prioritäten etwas ändert. In der AD liegt die Konfiguration unterhalb Deines Domain NC --> System Container --> DFSR-GlobalSettings. Du kannst neben ADSIEdit oder LDP auch einen Export der DFS-R AD-Daten machen, indem Du folgenden Befehl auf der CMD eingibst: dfsrdiag dumpadcfg Am bequemsten exportierst Du die GUIDs jedoch über: dfsradmin rg list /attr:all Um noch einmal auf meine Fragen von oben zurückzukommen: - Wie lautet die Event ID der Fehlermeldungen? Ich nehme an 4302? - Setzt Ihr Virenscanner auf dem Server ein, auf dem die Events geloggt werden? - Werden zum Zeitpunkt der Meldungen Backups gezogen? - Was für Daten liegen auf den DFS-R Shares, um welche Dateitypen handelt es sich? - Habt Ihr irgendwelche FRSM Filescreens am laufen, also die Sperrung von bestimmten Dateitypen (neben den DFS-R eigenen)? ...die wir hoffentlich gelöst bekommen. ;) Gruß olc
  5. olc

    Alternative zu DFS-R

    Hi, wenn Ihr direkt mit MS Kontakt hattet, muß doch etwas herausgekommen sein. Ich kann mir kaum vorstellen, daß das Thema mit "geht halt nicht" von MS beendet wurde oder? Aber gut, wenn Du keine weiteren Grundsatzdiskussionen möchtest, kann ich wohl nichts weiter beitragen... ;) Viele Grüße olc
  6. Hallo, Du solltest nicht mehr als 1024 Gruppenmitgliedschaften haben, siehe When you try to log on to a Windows Server 2003-based domain by using a domain user account, the logon request fails In der Praxis empfiehlt sich jedoch so oder so, einen Benutzer nicht so vielen Gruppen zuzuordnen. Gruß olc
  7. Hallo, Schau mal in den folgenden Beitrag vom IPCop Forum, da wird darauf eingegangen: www.ipcop-forum.de :: Thema anzeigen - dhcp suchlisten-option ==> es war also die Option 119. Sorry für den Fehler im ersten Post. Schau Dir unbedingt die Angabe der Werte in dem Post an, da ist scheinbar einiges zu beachten... Nein, nicht unbedingt. Das kommt auf Diene Einstellungen am Client an. Die Frage ist hierbei auch, ob Du bei Dir einen DNS-Server laufen hast - ist ja nicht unbedingt bei jedem "Privatmensch" der Fall ;) ... Letzteres ist der Fall: Wenn die Geräte in der gleichen Workgroup sind, werden Sie auch beim Netzwerkbrowsing in der gleichen Struktur angezeigt. Sind sie in verschiedenen Workgroups, werden "Unterordner" für jede Workgroup in der Netzwerkumgebung angezeigt. Siehe Link oben. Und bist mit mir einer Meinung das die Option so richtig definiert ist : In welcher Datei ist das definiert? Verwundert mich sehr. Aber sag mal, heißen Deine Arbeitsgruppen etwa "Net, Wifi.Net und VPN.Net"? Bis auf das erste wären dies im Grunde DNS-Format. Vielleicht kommt es daher zu dem beschriebenen Effekt - das wäre ja einmal sehr interessant... Gruß olc
  8. olc

    Alternative zu DFS-R

    Hi bLUEaNGEL, Das sollte im Normalfall in den Eventlogs stehen. Event IDs lauten 4202, 4204, 4206 und 4208. Wichtig ist, auf allen Servern die Eventlogs zu durchsuchen, da die Events immer nur lokal geloggt werden. Einen sehr guten Startpunkt bei jedweden DFS-R Problemen bietet Ask the Directory Services Team : Top 10 Common Causes of Slow Replication with DFSR . Mit den beschriebenen Vorgehen lassen sich so einige bekannte Fehlerquellen aufdecken und beheben. Da muß ich Dir widersprechen ;) : DFS-R bietet neben den Ereignisprotokollen sogar eine ganze Reihe Möglichkeiten, in den aktuellen Status zu schauen (siehe auch den Link oben). Wenn Du beispielsweise in "Echtzeit" sehen möchtest, was gerade passiert, solltest Du Dir einmal die sog. "Backlogs" anschauen. Du findest diese unter %SYSTEMROOT%\Debug\DfsrXXXXX.log bzw. die älteren Logs gepackt als *.gz. Hier kannst Du sozusagen "live" schauen, was gerade passiert. Sind Dir das zu viele Informationen, schaust Du Dir die Backlogs "gekürzt" an, in dem Du folgende Kommandozeile anpaßt und ausführst: dfsrdiag backlog /rgname:<deine_replicationgroup> /rfname:<dein_replicatedfoldername> /sendingmember:<dein_quelleserver> /receivingmember:<dein_zielserver> Dir werden dann nur die aktuell im Backlog liegenden Dateien angezeigt, ohne die Zusatzinformationen der Logfiles. Außerdem geben das StagingFolder und COnflictedAndDeleted oftmals guten Aufschluß über den derzeitigen Status. Ein weiteres Problemfeld sind die Schedules bzw. die Verfügbarkeit der Netzwerkanbindung. Hier solltest Du auch prüfen, ob alles korrekt eingestellt / verfügbar ist. Als letzten allgemeinen Punkt fallen mir noch die Hotfixes ein: Halte Deine DFS-R Systeme immer mit den aktuellen DFS-R Hotfixes auf dem neuesten Stand. Hier gibt es in der Zwischenzeit auch einige Hotfixes nach SP2 für Windows Server 2003. Gruß olc
  9. Hi CaIvin, kann es sein, daß in Eurer Domäne per GPO die Aufforderung, das Kennwort des Administrators in der UAC einzugeben wenn eine Evaluation erforderlich ist, nicht abgefragt werden soll? Zieh mal einen RSOP Report für Dienen Rechner inkl. Deines Rechners und schau, was in folgenden Policies gesetzt ist: Windows Settings --> Local Policies --> Security Options, dort die Optionen: - User Account Control: Detect application installations and prompt for elevation - User Account Control: Behavior of the elevation prompt for standard users Ist dort angegeben, daß der evaluation prompt nicht gezeigt werden soll, muß dies für Deinen Account geändert werden. Viele Grüße olc
  10. olc

    Alternative zu DFS-R

    Hallo, es gibt in dem Bereich einige Alternativen, so z.B. WAFS Boxen. Verschiedene Hersteller, so auch Cisco, bieten diese an. Ich habe (leider) bisher noch nicht solche Geräte im Einsatz gesehen, kann also auch nichts zu deren Leistungsfähigkeit sagen. Aber laß Dir an dieser Stelle die Frage gestatten, wo genau Dein DFS-R Problem liegt? DFS-R hört nicht "einfach so" auf zu replizieren. Meist ist bei DFS-R (und sicherlich auch bei anderen Applikationen / Diensten) das Problem nicht das System, sondern eine fehlerhafte Konfiguration. Das "einfach so aufhören zu replizieren" hört sich für mich stark nach einem bekannten Problem mit den StagingFolder Quota-Grenzen an, siehe Windows Server How-To Guides: Teil 3 - Staging-Folder / Quotas - ServerHowTo.de. Vielleicht kann man ja erst einmal ansetzen das Problem zu beheben, als die ganze Technik zu verteufeln und viel Geld für neue Technik auszugeben... ;) Gruß olc
  11. Hi, ich hoffe ich habe Deine Anforderungen richtig verstanden. Du kannst im IPCop beliebige DHCP Optionen im entsprechenden DHCP Range mitgeben. Ich bin mir nicht sicher, aber ich denke daß Die Option 15 die DNS-Suffixe definiert. Trägst Du also manuell eine Option 15 ein und definierst als Werte die gewünschten Suffixe, sollte das klappen. Ich denke jedoch nicht, daß Du die Geräte in der Netzwerkumgebung sehen wirst: Die Netzwerkumgebung basiert auf NetBIOS Namen der entsprechenden Systeme. Da NetBIOS sich im Normalfall über Broadcasts "verständigt" (es sei denn Du setzt WINS Server ein), was die Namen der Maschinen betrifft, wirst Du also Probleme bekommen: Broadcasts werden nicht geroutet, es sei denn, Du stellst es explizit ein. Ob man das beim IPCop machen kann, ist mir nicht bekannt. Ich denke eher nicht. Da Du zwischen den beiden Interfaces routen mußt, wird hier standardmäßig nichts durchkommen... Diese NetBIOS Namen der Netzwerkumgebung haben also nichts mit den DNS Suffixen zu tun. Gruß olc
  12. Hi holunder, Gut, das ist die halbe Miete. :) Bitte poste einmal die gesamte Meldung, inkl. der Event ID, der Zeit und der Pfade. Ggf. kannst Du aus Datenschutzgründen die Pfadnamen bei vertraulichen Namen ja ändern, solange Du konsistent die gleichen Bezeichnungen wählst. Anders kann man das Event kaum auswerten... Was mich verwundert ist, daß die Dateien scheinbar wirklich Staging Dateien sind - zumindest läßt der Name dies vermuten. Werden diese Events an allen Standorten geloggt oder nur an einigen? Nutzt Ihr Virenscanner auf den Systemen, die auch die Replikationsordner scannen? Was für eine Backup Lösung nutzt Ihr? Mir persönlich sind keine Lösungen bekannt, die ein solches Szenario (also das Locking von Dateien an mehreren Standorten, sollte ein Benutzer an einem anderen Standort die gleiche Datei bearbeiten) abdecken würden - es sei denn, der Zugriff der Benutzer erfolgt direkt über das Netz hin zu zentralen Systemen. iSCSI oder ähnliches wäre in diesem Fall auch denkbar - aber auch das setzt eine ordentliche Konnektivität voraus. In diesem Fall also m.E. eher ungeeignet. Nichts zu danken - ich hoffe es bringt Dich weiter. Gruß olc
  13. Hallo, wie genau rufst Du denn die gespeicherte MMC auf? Probiere einmal folgende Syntax (bitte passe die Daten nach Deinen Wünschen an): runas /USER:DOMAIN\DomainChef "mmc Console.msc" Das sollte funktionieren. Gruß olc
  14. olc

    Schottky-TTL Technik frage

    Off-Topic: Kennt Ihr diese Lautsprache, bei der die nur "geklickt" wird? Klingt für mich genauso wie das, wovon Ihr da redet. :D
  15. Hallo holunder, Ok. Also so, wie vermutet. :) Im Staging Folder liegt diese Datei nicht - wenn tatsächlich "sharing violations" auftreten, dann landet die Datei gar nicht im Staging Folder --> der Zugriff wird ja verweigert. Die Datei muß also - wenn es sich tatsächlich um gelockte Dateien handelt - im normalen Replikationsordner liegen. Bitte bedenke dabei auch, daß nicht alle Dateitypen bzw. Programme im geöffneten Zustand ein "lock" auf die Datei setzen. Textdateien tun dies beispielsweise nicht. D.h. DFS-R kann die Daten trotzdem replizieren, während dessen unter Umständen ein Benutzer die Meldung bekommt, daß ein anderer Benutzer in der Datei arbeitet. Welche Ereignisse bekommst Du denn im DFS-R Eventlog? Ja, das macht dann auch Sinn. Im Normalfall werden sich die Clients auf den Server / einen der Server Ihres Standord verbinden. Ist dieser beispielsweise aufgrund von Netzwerproblemen nicht erreichbar oder gar nicht online, ziehen sich die Clients über die Namespaceserver ein anderes Ziel - und versuchen dabei den "billigsten" Netzwerkpfad zu wählen. Die Frage ist, was Du lösen willst. Die Netzwerkprobleme solltest Du in jedem Fall lösen. ;) Daß Zugriffsverletzungen beim Zugriff auf ein und dieselbe Datei auftreten, kannst Du nicht ändern. Das ist ja auch sinnvoll so und nicht nur bei DFS-N bzw. DFS-R der Fall... Wenn es Dir darum geht eine Datei auf allen Replikationsordnern zu sperren, wenn an irgend einem Standort ein Benutzer darin arbeitet, muß ich Dich enttäuschen - das geht nicht. Das wäre auch nicht sinnvoll, denn dann nützt die verteilte Datenhaltung recht wenig. Eine Möglichkeit, alle Benutzer auf einen bestimmten Ordner zu leiten (sofern dieser verfügbar ist), wäre mit (DFS-N)Prioritäten zu arbeiten. Aber dann würden die Remote-Benutzer in Deiner Umgebung - wenn ich Dich richtig verstanden habe - immer über das (Inter-)Netz zugreifen, was sicherlich nicht gewünscht ist. Grundsätzlich auch noch einmal der Hinweis, daß es mit Vorsicht zu genießen ist, an verschiedenen Standorten gleichzeitig an gleichen Daten zu arbeiten. Davon kann man in der Praxis eigentlich nur abraten. In jedem Fall mußt Du in einer solchen Konstellation einen sehr guten Reviewprozess für die Eventlogs einrichten, um alle Konfliktvorgänge auf dem Schirm zu haben. Sonst kommt es irgendwann einmal zu einer wirklich unschönen Situation... :rolleyes: Gruß olc
  16. Hallo, "ntdsutil" ist ab Windows Server 2003 SP1 meist besser geeignet als ADSIEdit, da es die von grizzly999 genannten zusätzlichen Einträge des zu entfernenden DCs unter "CN=File Replication Service" und "CN=Domain System Volume" gleich mit entfernt. Mittels ADSIEdit muß man dies manuell tun. Aber wenn man es nicht vergißt, kann man natürlich auch ADSIEdit nutzen. Je nach dem, ob man Mausschubser ist oder nicht. :p Viele Grüße olc
  17. Hallo, leider ist Deine Beschreibung nicht ganz eindeutig. Ist an jedem Standort ein Replikationsordner vorhanden? Da die Replikation keine File-Locks repliziert, sondern im Moment eines File-Lockings die Datei gar nicht repliziert (das nennt sich dann "sharing violation" und verlangsamt die Replikation insgesamt unter Umständen sehr stark), kann die Zugriffsverweigerung bzw. "nur lesen" Situation nur auftreten, wenn zwei Clients tatsächlich auf die gleiche Datei auf dem gleichen Server zugreifen. D.h. greifen zwei Benutzer auf die gleiche Datei auf zwei verschiedenen Servern / Replikationszielen zu, kann der jeweils andere Client nichts davon bemerken. Greifen jedoch (weil beispielsweise ein Replikationsordner eines Standorts nicht verfügbar ist) zwei Clients auf die gleiche Datei des gleichen Servers zu, bekommst Du ggf. die Fehlermeldung. Vielleicht kannst Du Deine Situationsbeschreibung ja noch einmal ein wenig genauer ausführen. Gruß olc
  18. Hallo, Soweit ich weiß geht das nicht. Das dafür verantwortliche ActiveX Plugin läuft nur im Internet Explorer. Oder Du nutzt alternativ "certreq.exe" oder ähnliches. Viele Grüße olc
  19. Hallo, ja, aber diesen Request hattest Du beim ersten Mal nicht verlinkt. ;) In beiden Requests wird SASL verwendet. Daher auch die LDAP-Abfragen. Vielleicht kannst Du darüber noch etwas herausbekommen. Meiner Meinung nach steht Kerberos zu diesem Zeitpunkt noch nicht zur Debatte - Kerberos Authentifizierung wird erst nach dem erfolgreichen PEAP Login möglich sein - wenn überhaupt. Aber wie gesagt, meine Meinung ist kein Maßstab. Gruß olc
  20. Hallo, ich bin leider kein "Profi" in diesem Gebiet - aber vielleicht ein, zwei Punkte dazu: Ich denke nicht, daß die SIDs der Maschinen oder Benutzer "wild durch die Gegend" gesendet werden. Vielmehr sollten diese erst ausgetauscht werden, wenn die Authentifizierung schon stattgefunden hat bzw. der Paketaustausch ggf. schon verschlüsselt stattfindet. Dies ist z.B. auch bei Kerberos etc. der Fall, wenn ich mich nicht irre. Du filterst in dem Capture nur nach LDAP-Traffic - höchstwahrscheinlich sind jedoch auch andere Protokolle an dem Authentifizierungsvorgang bzw. Austausch der für Dich relevanten Daten beteiligt. Ich würde das also nicht beschränken... Im Capture ist nicht der SPN zu sehen, sondern der DN ("CN=TESTRECHNER,CN=Computers,DC=<domain>,DC=<tld>") und zusätzlich der sAMAccountName ("TESTRECHNER$"). Ein SPN sieht in Deinem Fall (wie oben schon geschrieben) so aus: HOST/machine.domain.tld Wenn ich mir den folgenden Text anschaue, sehe ich mich bestätigt: Weiter unten steht dann auch, daß beispielsweise der Computername ausgetauscht wird. Wahrscheinlich würde ich mich nun in Ruichtung "EAP Type" erkundigen - in die Richtung scheint es zu gehen, wenn es um den Datenaustausch geht... Aber wie gesagt, ich weiß fast nichts darüber. Vielleicht kennt sich hier ja jemand anderes damit besser aus und gibt Dir bessere / weitere Infos...? Gruß olc
  21. N'Abend, unter Umständen lag es an dem fehlenden Leerzeichen zwischen dem "="-Zeichen und den Pfaden. Aber da Du es nun anders gelöst hast... ;) Siehe Windows Server How-To Guides: Applikationen als Dienste einrichten - ServerHowTo.de unterer Bereich "[Ergänzung]". Gruß olc
  22. Hallo, ich hoffe, daß ich die Frage richtig verstanden habe: Wenn Du Benutzer in einer verschachtelten OU-Struktur anlegen / bearbeiten / löschen etc. möchtest, kannst Du einfach die gewünschten OUs in der entsprechenden Strukturreihenfolge mit im Befehl angeben. In Deinem Beispiel wäre es dann etwa: "CN=user,OU=Testuser1,OU=Testuser,DC=domain,DC=tld" Wichtig dabei ist, daß Du dich vom Benutzerobjekt "nach oben hangelst", d.h. die Reihenfolge der OUs, DCs etc. korrekt einhältst. Gruß olc
  23. N'Abend, DFS-R löst das Problem mit der Bandbreite / Stabilität recht gut. Schau mal hier, vielleicht ein Startpunkt bezüglich DFS-R: 1. Windows Server How-To Guides: Planung, Installation und Konfiguration des Distributed File System (DFS) unter Windows Server 2003 R2 - ServerHowTo.de 2. Windows Server How-To Guides: Weiterführende DFS-R Konfiguration unter Windows Server 2003 R2 - ServerHowTo.de Wenn es mit der Hardware kein Problem ist, stell Dir den Storage Server oder einen richtigen Windows Server 2003 R2 bzw. bald Windows Server 2008 hin (oder brauchst Du bestimmte Funktionalitäten des Storage Servers?) und kein NAS. Der Erfahrung nach gibt es innerhalb kürzester Zeit neue Wünsche, für die dann das Betriebssystem ein limitierender Faktor sein kann. Aber ich will das jetzt nicht pauschalisieren - sicherlich gibt es auch durchaus Szenarien, in denen ein kleines NAS ausreicht. Das mußt Du halt vorher evaluieren... Gruß olc
  24. Hallo, worum geht es Dir denn genau? Einen schnellen Überblick über die Eigenschaften bzw. Attribute von Benutzerobjekten oder Computerobjekten kannst Du Dir verschaffen, wenn Du mittels ADSIEdit, LDP o.ä. ein entsprechendes Objekt anschaust. Einen Export kannst Du beispielsweise mittels ldifde erreichen: ldifde -d CN=<objekt>,OU=<organisationseinheit>,DC=<domain>,DC=<tld> -f C:\TEMP\objekt.ldf und dann vergleichen. Die Definition der verschiedenen Attribute für diese Objekte erfolgt über das Schema. Letztendlich gibt es eine Menge Gemeinsamkeiten zwischen Benutzer- und Computerobjekten, aber natürlich auch einige essentielle Unterschiede - daher meine Frage, worum es Dir genau geht. Bei der Authentifizierung eines Computers mittels 802.1x wird beispielsweise der SPN (HOST/machine.domain.tld) des Kontos gesendet und sein Zertifikat. Somit läßt sich eine Zuordnung vornehmen, die für die Authentifizierung notwendig ist. Gruß olc
  25. olc

    DFS Replizierung

    Hallo, grundsätzlich ist das möglich, jedoch müssen dabei ein paar Dinge beachtet werden: Wie möchtest Du die Daten austauschen, d.h. wie überträgst Du die Daten von Italien nach Deutschland? Bei jedweder Art des Backups müssen die ACLs der Daten mit kopiert werden - egal ob über spezielle Backup Software oder z.B. mittels robocopy. Übrigens scheint es derzeit noch einen Bug zu geben, wenn man NTBackup nutzt, um die Daten zu übertragen. Ggf. hier noch einmal testweise prüfen, ob in Deiner Umgebung alles korrekt funktioniert - mit einer kleinen Datenmenge. ;) Viele Grüße olc
×
×
  • Neu erstellen...