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