AndreP

Hallo, ich versuche mal das Szenario zu beschreiben, ohne zuviel mit Details zu verwirren. Bei bedarf kann ich einzelne Punkte ausführlicher erläutern. das SAN ist von EuroStore (ES-8700). (genaugenommen sind es 2, die geclustert sind; wurde von einem Dienstleister eingerichtet) SAN Ein Netzport geht an einen Switch "SAN-1" Ein Weiterer geht an den Switch "SAN-2" Ein Weiterer geh an den Switch "Donänen-LAN" FileServer Ein Netzport geht an einen Switch "SAN-1" Ein Weiterer geht an den Switch "SAN-2" Ein Weiterer geh an den Switch "Donänen-LAN" Das iscsi Taget habe ich entsprechend der mit MPIO eingerichtet. Auf dem Fileserver habe ich eine DFS-Replikation der Abteilungs- und Home-Verzeichnisse zu 2 Backupserver laufen. Auf den Backupserver sichere ich dann die Daten von dem "Echtzeitreplikat" weiter weg, um nicht des Produktivsystem zu belasten. Ich hoffe ich konnte die Situation halbwegs verständlich beschreiben. PS: Backups oder Snapshots laufen keine auf dem SAN

Hallo zusammen, ich brauche mal ein paar Anregungen zu o.g. Problem. Folgende Situation: Fileserver (2012R2) nativ SAN-Speicher (SSD Platten) via iscsi und MPIO angebunden auf dem Speicher liegen die Abteilungs- und Home-Laufwerke der User und es werden Teile des Profils in das Home umgeleitet Immer wieder kommt es vor, dass die Zugriffe auf Dateien in Home und Abteilungen recht träge sind (öffnen von Officedateien, etc.). Bei einem Blick in den Ressourcenmonitor fällt auf, dass sich die Datenträgerwarteschlange des Laufwerks immer wieder linear aufstaut, wie bei einem Sägezahn (siehe Bilder). Ich habe im Moment keine Idee, wo ich bei der Problemsuche ansetzten soll und wäre für ein paar Denkanstöße dankbar. LG Andre P

Hallo und noch ein frohes Neues. Das Zurücksetzen der DDP hat soweit funktioniert, noch mal Danke für die Infos! Jetzt ist mir aufgefallen, dass in der neu erzeugten DPP ein Zertifikat zur Dateiwiederherstellung installiert wird, welches 2007 abgelaufen ist. (siehe Anhang) Der Eintrag war auch schon in der verbastelten DDP vorhanden und ich hatte erwartet, dass er nach dem Zurücksetzen weg, bzw aktuell ist. Was hat es mit diesem Zertifikat auf sich? Kann das raus oder muss da ein neues ausgestellt werden?

Vielen Dank für die Infos!! Das mit der DDP ist noch eine Erbsünde. Was ich noch bedenklicher finde ist die Tatsachen, dass die originale DDP " {31B2F340-016D-11D2-945F-00C04FB984F9}" verbastelt & deaktiviert ist und nur eine verbastelte Kopie aktiv ist. Das ist doch sicherlich "suboptimal" :confused: Vor den Feiertagen pack ich jetzt aber nicht in den Nadelhaufen. Hab keine Lust auf Bereitschaftseinätze :schreck: Reicht es, wenn ich die Einstellungen in der DDP bis auf die 3 Standards raus schmeiße? Habe ehrlich gesagt ziemlich Respekt vor dcgpofix.exe, da wir auch 3 Exchange Server in der Domäne haben. Gruß & und schöne Weihnachtstage AndreP

Hallo, ich habe nur WSUS und ein paar "kosmetische" Sachen via Computer GPO eingestellt (siehe Anlage). Eine User GPO habe ich noch nicht gemacht. Manchmal hilft es aber schon, wenn man nur drüber redet. :thumb1: Während ich Deine Antwort gelesen habe, viel mir ein, dass nur noch die "Default Domain" GPO als mögliche Ursache ins Speil kommen kann. Also habe ich die mal deaktiviert.... und siehe da ... Taschenrechner, Kalender starten. Jetzt muss ich mal die Default Domain schrittweise zerlegen, um die Fehlerquelle zu finden. Die Default Domain Policy wurde zu Urzeiten (2000er Domäne) mal verbastelt und seit dem immer mitgeschleppt. Gruß AndreP

Hallo, ich kämpfe gerade gegen Windows 10. Ich möchte Win10 (Professional 1709) Clients in unserer Domäne (2012R2) laufen lassen. Dazu habe ich mir eine kleine Testumgebung aufgebaut und eine neue Computer-GPO erstellt. Benutzer GPO kommt im nächsten Schritt. Jetzt scheitere ich aber schon an ganz pisseligen Dingen... Wenn ich einen lokalen Benutzer (ohne Admin Rechte) anmelde, kann ich z. B. lokale Standardprogramme wie den Taschenrechner, Kalender etc. starten. Wenn ich einen Domänen Benutzer anmelde, Wird der Eintrag im Startmenü (oder die Kachel) Grau und unterstrichen. In beiden Fällen wird nur die Computer GPO ausgeführt und beide haben nur User Rechte. Habe ich hier etwas grundlegendes übersehen? Ich zweifle gerade an meinem Verstand... Gibt es vielleicht einen Best Practice Leitfaden für das integrieren von Windows 10 in eine Unternehmensdomäne? LG Andre P

Hallo, ich habe einen Sicherungsserver, der über DFS-R einen Datenstand vom Produktivsystem bekommt. Von diesen Replikat kopiere ich derzeit mit RoboCopy den Stand auf eine Festplatte im Wechselrahmen, um eine zusätzliche "externe" Sicherung zu haben. Jetzt ich hab mir RichCopy als alternative zu RoboCopy angesehen, da der Kopierprozess teilweise sehr lange dauert. Leider habe ich es nicht geschafft, in einem Testszenario die Dateiberechtigungen, Eigentümerinfo, etc. mit zu kopieren. Die Entsprechenden Felder in den Optionen (Information to be Copied -> Security Information) habe ich natürlich angehakt. Trotzdem habe die Schalter keine Auswirkung auf die kopierten Dateien. Das Ziel hat ausschließlich die geerbten Rechte der übergeordneten Verzeichnisses. Hatte schon mal jemand ähnliche Schwierigkeiten? Gruß Andre P

Hallo Doso, VIELEN DANK!!!! Genau das ist der Fehler. Das Update deinstalliert, Replikationsgruppen neu eingerichtet und siehe da, er läuft durch. Hier der Vollständigkeit halber noch der Link zur MS Doku des KB3156418, in dem Microsoft das Problem mit dem DFSR Dienst auch nennt: https://support.microsoft.com/en-us/kb/3156418 Noch mal vielen Dank für die Hilfe! Problem ist damit gelöst. Gruß Andre P.

Hallo, wir haben diverse Abteilungs-/Gruppenverzeichnisse, auf denen die entsprechenden User via Gruppenzugehörigkeit Vollzugriff haben. Damit sollen die User die Möglichkeit haben eigene Unterstrukturen anzulegen und ggf. die Rechte selber weiter einschränken können für "sensiblere" Daten. Leider und offensichtlich scheitert es aber an den Fähigkeiten und dem Verständnis der Vererbungslehre... Der DFS Dienst ist diese Nacht wieder hängen geblieben, obwohl er den kompletten Datenbestand selber kopieren musste. Also gehe ich jetzt mal davon aus, dass die Ursache in der Quelle (SERVER A) zu suchen ist, obwohl der Dienst auf Server B & C stirbt. Ich sterb auch bald...

Hallo Weingeist, Danke für Deine Antwort! Das Robocopy diese Probleme nicht hat, habe ich auch schon gelesen und gemerkt. Ich hatte zuvor mit Robocopy den Pre-seed gemacht -ohne Probleme. Ein Dienstkonto würde wahrscheinlich nicht helfen. Die User sind hingegangen und haben die Vererbung in einigen Verzeichnissen ausgeschaltet und die übergeordneten Rechte nicht kopiert, sondern eigene (einzelne User) eingetragen. Damit waren dann SYSTEM und Administrator weg. Oder kann man irgendwie gewisse Konten/Gruppen "erzwingen"? Zu den IOs, wie kann ich die moitoren/analysieren? Ist jetzt zwar ein anderes Thema, aber die Auslastung am Fileserver würde mich mal interessieren. Gruß Andre P.

Hallo, ich habe in den letzten Tagen diverse Szenarien ausprobiert, aber das Ergebnis ist immer wieder das Gleiche: der DFSR Dienst bleibt irgendwann mit 100% CPU Auslastung stehen. Selbst das löschen und Neuanlegen der Replikationsgruppe brachte keinen Erfolg. Aktuell lasse ich den DFSR Dienst den Datenbestand zum Replikationsziel kopieren (ohne Pre-seed). Mal sehen, was daraus wird... Bei der Recherche in den Logs, ob er immer an bestimmten Files hängen bleibt, ist mir folgendes aufgefallen: Eine Menge Verzeichnisse/Dateien überschreiten die Pfad-Länge von 255 Zeichen und auf einigen Verzeichnissen habe die User die Berechtigungen "angepasst" und dabei sowohl SYSTEM, als auch den ADMINISTRATOR entfernt. Kann das den Dienst absterben lassen? Dann stellt sich mir auch noch die Frage, wie haben die User es überhaupt geschafft so lange Verzeichnisstrukturen anzulegen, dass die Länge von 255 Zeichen überschritten werden konnten? Hat keiner einen Tipp, wie ich dem Fehler auf die Spur komme? Oder kennt jemand jemanden, der einen kennt, der DFSR Profi ist? :shock: Gruß Andre P.

Hallo zusammen, ich habe in unserer Domäne auf einem Server 2012 den KMS laufen. Jetzt möchte ich auch Windows 10 Clients aktivieren. Wenn ich den Win10-Key aus unseren Customer Support – Volume License Service Center in den KMS Server eintrage erhalte ich die Meldung, dass der Key nicht gültig sei oder von der Version des VAMT nicht unterstützt wird. Das KB3058168 ist bereits installiert. Hatte jemand ähnliche Schwierigkeiten oder hat einen Tipp für mich, wo es hakt? Gruß Andre P.

Hallo zusammen, ich habe gerade ein Problem mit meiner DFS Replikation. Der Dienst bleibt bei der Initialen Replikation nach einiger Zeit mit 100% CPU Last hängen. Aber hier erst mal mein Szenario: SERVER A - Produktivsystem Ist ein Cluster, gebildet aus "Server A1" & "Server A2", beide auf VM. SERVER B - Backup Ist nativ, hat ein DFS Replikat, von dem dann Backups gezogen werden. SERVER C - Backup Ist nativ, hat ein DFS Replikat, von dem dann Backups gezogen werden. Die Kombi lief bereits ohne Probleme. Nachdem die DFSR Datenbank auf B & C irreparabel beschädigt war, habe ich folgendes gemacht: Alle Mitglieder der DFSR Gruppe deaktiviert DFSR Dienst auf B & C beendet Datenbank und DFSRPrivate auf B & C gelöscht DFSR Dienst auf B aktiviert Server A in der DFSR Gruppe aktiviert und gewartet bis er sich als Primärer meldet "Ereignis ID 4112" Server B in der DFSR Gruppe aktiviert Server B startet auch brav die Erst-Replikation (ID 4102) und initialisiert das Laufwerk (ID 2002). Ansonsten gleicht er einen Haufen Dateien ab (ID 4412). Nach einigen Stunde steht dann der DFSR Dienst bei 100% und es passier nichts mehr. Die Gegenstelle, Server A, meldet irgendwann dann einen Fehler bei der Kommunikation mit der Gegenstelle (ID 5002). Ich habe bereits verschiedene Szenarien ausprobiert, immer mit dem gleichen Ergebnis. Hat vielleicht jemand eine Idee, was dem Automaten fehlen könnte? Schon mal Danke für Eure Mühen & Gruß Andre P Das hier sind die letzten Einträge des DFS-Logfiles von Server B: 20160601 22:43:27.262 1496 MEET 6356 Meet::LocalDominates Remote version dominates localgvsn:{A75068D7-1A92-4CEE-B522-255E30BF3A5E}-v279540 updateName:MZ-3312.jpg uid:{16345316-A1C6-4DC3-982E-8C2BF0239749}-v33198684 gvsn:{16345316-A1C6-4DC3-982E-8C2BF0239749}-v33198684 connId:{15F710BB-9C4A-49B2-BA29-B941511710F6} csName:Abteilungen 20160602 06:47:37.781 3252 DOWN 1290 [WARN] WrapRpcInitializeFileTransferAsync RPC Async call is taking a long time rpcAsyncState:000000F1804FDB60 20160602 06:47:37.781 2420 DOWN 1290 [WARN] WrapRpcInitializeFileTransferAsync RPC Async call is taking a long time rpcAsyncState:000000F1809FD530 20160602 06:47:42.859 256 DOWN 1290 [WARN] WrapRpcInitializeFileTransferAsync RPC Async call is taking a long time rpcAsyncState:000000F1802FDC90 20160602 06:47:42.859 3136 DOWN 1290 [WARN] WrapRpcInitializeFileTransferAsync RPC Async call is taking a long time rpcAsyncState:000000F180BFD810 20160602 06:47:44.890 164 DOWN 1290 [WARN] WrapRpcInitializeFileTransferAsync RPC Async call is taking a long time rpcAsyncState:000000F18107D520 20160602 06:47:44.890 2188 DOWN 1290 [WARN] WrapRpcInitializeFileTransferAsync RPC Async call is taking a long time rpcAsyncState:000000F180E7D5B0 20160602 06:47:47.937 1372 DOWN 1290 [WARN] WrapRpcInitializeFileTransferAsync RPC Async call is taking a long time rpcAsyncState:000000F1806FD6C0 20160602 06:48:43.688 1104 DOWN 1290 [WARN] WrapRpcInitializeFileTransferAsync RPC Async call is taking a long time rpcAsyncState:000000F180D7D910 20160602 06:48:44.703 1492 DOWN 1290 [WARN] WrapRpcInitializeFileTransferAsync RPC Async call is taking a long time rpcAsyncState:000000F18047D600 20160602 06:48:49.735 2412 DOWN 1290 [WARN] WrapRpcInitializeFileTransferAsync RPC Async call is taking a long time rpcAsyncState:000000F180FFD6B0 20160602 06:49:04.922 3528 DOWN 1290 [WARN] WrapRpcInitializeFileTransferAsync RPC Async call is taking a long time rpcAsyncState:000000F180B7D4E0 20160602 06:49:13.016 412 DOWN 1290 [WARN] WrapRpcInitializeFileTransferAsync RPC Async call is taking a long time rpcAsyncState:000000F18067D580 20160602 06:49:16.063 1496 DOWN 1290 [WARN] WrapRpcInitializeFileTransferAsync RPC Async call is taking a long time rpcAsyncState:000000F18097D590 20160602 07:06:33.682 2452 DOWN 1290 [WARN] WrapRpcInitializeFileTransferAsync RPC Async call is taking a long time rpcAsyncState:000000F18037DBB0 20160602 07:06:41.682 680 DOWN 1290 [WARN] WrapRpcInitializeFileTransferAsync RPC Async call is taking a long time rpcAsyncState:000000F1807FDAB0 20160602 07:06:42.682 1696 DOWN 1290 [WARN] WrapRpcInitializeFileTransferAsync RPC Async call is taking a long time rpcAsyncState:000000F1827BD9B0