olc

Na ja - die Fehlermeldung ist auf den ersten Blick ja recht eindeutig oder...? Viele Grüße olc

Hi, sprechen wir ausschließlich von Problemen mit der DFSR-Replikation oder auch von AD-Replikationsfehlern? Was sagt ein "repadmin /replsum"? Viele Grüße olc

Hi, aus meiner Sicht sind alle Ansätze, Administratoren einschränken zu wollen, von vornherein zum Scheitern verurteilt. Ich kenne die o.g. Software nicht, jedoch gibt es für Administratoren immer auch Möglichkeiten, sich alle notwendigen Rechte zu verschaffen, eine solche Software zu deaktivieren - und wenn es am Ende "nur" der abgesicherte Modus oder irgend ein SYSTEM Dienst ist, der mißbraucht wird. Wie oben schon vielfach angesprochen - schaut Euch nach einer Alternativsoftware um oder überdenkt das Konzept. Alles andere ist meines Erachtens nur Chimären, die Euch in Sicherheit wähnen, ohne es wirklich zu sein. Viele Grüße olc

Hi, habt Ihr noch die alten DCPROMOUI.log Dateien, um einen Blick hinein zu werfen, was schief gegangen sein kann? http://support.microsoft.com/kb/221254/en-us Sind ggf. "WAN Optimierer" (z.B. Riverbed o.ä.) im Einsatz? Viele Grüße olc

Hi, sind Firewalls auf den Systemen aktiv? Was sagt die Ausgabe von "nltest /dsgetdc:remote-domain.tld /force", ausgeführt auf beiden Seiten gegen den jeweiligen remote Forest? Viele Grüße olc

Hi, in vielen Unternehmen wird mehr und mehr auf "nicht identifizierbare / kryptische" Kontenbezeichner gesetzt, das heißt PII (Personally Identifiable Information) Daten sollen in der Regel nicht auftauchen. Damit hast Du auch gleichzeitig das "Problem" der Umbenennung elegant umgangen. Wenn es tatsächlich ausschließlich um das Umbenennen von Konten geht, würde ich vermutlich keine Maskierung durchführen. Der Mehraufwand und ggf. der Akzeptanzverlust, den die Benutzer beim Merken der "kryptischen" Anmeldedaten usw. haben steht meines Erachtens in keinem Verhältnis zu dem Nutzen, den Ihr bei seltenen Umbenennungen habt. Das sind nur zwei Argumente von vielen - definiert doch erst noch einmal Eure konkreten Anforderungen, dann können wir hier auch besser helfen. ;) Viele Grüße olc

Hi, was heißt die Server können sich ansonsten "problemlos erreichen"? Ist beispielsweise ein SMB-Zugriff möglich (Share)? Läuft auf einem der Server ggf. eine Firewall bzw. weichen die Firewall Einstellungen voneinander ab? Viele Grüße olc

Hi, nltest /dsgetsite Viele Grüße olc

Hi, solange sich der Benutzer an einem PC der eigenen Domäne anmeldet, ist der Anmeldeprozess genau der beschriebene. Ansonsten wird je nach Konstellation, also ob beispielsweise ein Benutzer der Domäne A auf einem PC der Domäne B angemeldet wird oder ob nur ein Ressourcenzugriff von Domäne A auf Domäne B erfolgt, zum Beispiel mit Ticket-Referrals (Kerberos, http://technet.microsoft.com/en-us/library/bb742516.aspx) oder "Kettenauthentifizierung" (NTLM, http://msdn.microsoft.com/en-us/library/windows/desktop/aa378749(v=vs.85).aspx) durchgeführt. Viele Grüße olc

Hi, was Du suchst sind Informationen über den "DC Locator" Prozess: http://support.microsoft.com/kb/314861/en-us Viele Grüße olc

Hi, im Kern hast Du die Antwort ja schon erhalten - woher weißt Du, daß DES nicht mehr genutzt wird? Hast Du das geprüft? Schneide einmal nach einem "klist purge" auf dem Windows 7 Client den Zugriff auf eine Ressource mit dem NetMon 3.4 oder WireShark mit. Der Ressourcenzugriff muß natürklich den Fehler nach sich ziehen, sprich Du mußt prüfen, welche Ressourcenzugriffe die Fehler verursachen. Dann schaust Du Dir wie im KB-Artikel auch gezeigt den Trace an, um zu prüfen, ob die Frage nach DES Verschlüsselung vom Client kommt oder vom DC angeboten wird. Das grenzt das Problem schon ein. Schau Dir auch noch einmal die beiden oben in meinem Post verlinkten Artikel an. Viele Grüße olc

Danke für Deine Rückmeldung und sorry für den "Fehlalarm". Läuft wieder. Klassischer Fall von Überreaktion bei Änderung einer Software, vor der ich sonst häufig selbst warne ;) : An ein paar Geräten von mir ist JavaScript nur nach expliziter Freigabe erlaubt - https://www.MCSEboard.de ist in den erlaubten Seiten, die neue Logon-Maske des Forums läuft jedoch auf http und nur die Übertragung der Anmeldedaten erfolgt mittels https. Das hat die Fehlermeldung zur Folge. Das Hinzufügen von http://www.mcseboard.de in die JavaScript aktivierten Seiten löste das Problem. Viele Grüße olc

Hi zusammen, Ich kann mich seit heute nicht mehr am Board anmelden. Fehlermeldung lautet: "Sorry, dafür hast Du keine Berechtigung." Nur auf einem System mit gesetzten Cookies (also einer bestehenden Anmeldung von gestern) klappt es weiterhin. Sind auch andere Logins betroffen? Viele Grüße olc

Hi, Jeder Betrieb von mehreren Server Funktionen auf einer Maschine führt zu Abhängigkeiten. Geht es nicht anders, musst Du Dich zwischen Pest und Cholera entscheiden. Sofern es anders geht, würde ich in der Regel immer Server Rollen trennen. Paradigma: Ein Server, ein Dienst. Viele Grüße olc

Hi gnoovy, Klar ist es "schöner" den Namespace bei Aufruf der Domäne sehen zu können, aber Du zahlst eben auch einen Preis dafür. Nämlich die Abhängigkeit des DFSN Dienstes in Bezug auf die DCs. Wenn Du zu Troubleshooting Zwecken einmal DCs demoten musst, Migrationen anstehen usw., kosten Dich diese Abhängigkeiten Zeit, Nerven und verursachen häufig Probleme. Ich würde es also eher nicht von der Sichtbarkeit von Namespace abhängig machen, sondern von der Integration in Eure Umgebung (=keine Abhängigkeiten schaffen). Bezüglich des Hintergrunds der Anfrage: Datenbanken mit DFSR replizieren zu wollen geht meist in die Hose, da DBs mit file-locks arbeiten, die für Blockaden bei der DFSR Replikation sorgen. Die Folge sind Replikationsprobleme als auch schlimmstenfalls Dateninkonsistenz, sofern auf beiden Seiten der Replikationsgruppe gearbeitet wird. Daher noch einmal explizit der Hinweis, dass Ihr das ganze Konzept noch einmal überdenken solltet. Die Boardsuche zum Thema DFSR sollte einiges dazu zu Tage fördern. Viele Grüße olc

Hi spalato, probiere einmal: Dfsradmin membership set /RGName:Backup_Servername /RFName:DFS_Backup /MemName:DOMAIN\Servername>/RO:true Viele Grüße olc

Hi gnoovy, das Vorgehen sieht auf den ersten Blick ganz gut aus. Du kannst überlegen, ob der DC wirklich auch DFSN Namespace Server sein soll. Es hat ggf. Sinn das auf die Member-Server zu legen - auf beide, um etwas Redundanz zu haben. BTW: Ist wirklich nur 1 DC in der Umgebung vorhanden? Falls ja: Es ist definitiv zu empfehlen, einen zweiten DC dort zu promoten. Die Frage, die sich mir stellt, ist was Du mit der DFS( R )-Replikation erreichen möchtest? Als "Cluster-Ersatz" ist DFSR mit Vorsicht zu genießen, auch wenn es häufig so genutzt wird. Die beiden vorgesehenen DFSR Nutzungsszenarien sind im Kern die Datenverteilung (etwa für WDS Images) und die Datensammlung (etwa für Backups). Alles andere kann Probleme in Bezug auf Datenaktualität, verteilte Datennutzung auf unterschiedlichen Systemen bis hin zum Datenverlust nach sich ziehen. Daher meine Rückfrage: Was ist das Szenario, für welches DFSN + DFSR genutzt werden soll? Viele Grüße olc

Hi gnoovy, Der Namespace ist genau genommen nur eine Freigabe - da Du Dich bei Eingabe von \\domain.tld nur auf einen DC verbindet, kann es keine Informationen geben, welche Namespaces es ggf. auf anderen Systemen gibt. Wenn der DC gleichzeitig Namespace Server ist, bietet er das Share gleich mit an und es wird Dir daher auch angezeigt. Ergo: Ja, das Verhalten ist normal. Was genau möchtest Du denn erreichen? Was ist der Hintergrund Deiner Frage? Viele Grüße olc

Hi, hast Du die Ausgabe von "Servername" (Parameter /MemName) hier angepaßt oder tatsächlich die CMD nicht an Deine Servernamen angepaßt? Die Fehlermeldung ist ja recht eindeutig. Viele Grüße olc

Hi, nein, nicht daß ich wüßte. Solange das Schema auf Windows Server 2008 oder höher ist, gibt es keine Abhängigkeiten zum Domain Functional Level >= 2003. Zumindest nicht für diese Funktion. Noch einmal nachgefragt: Wie sieht es mit der Kommandozeile aus? Der TechNet Artikel nennt auch weitere Anforderungen: Viele Grüße olc

Hi, es gibt diverse sogenannte "Mobile Device Management" PRodukte auf dem Markt - Du wirst die Produkte gegen Deinen Anforderungskatalog abgleichen müssen. "Mobile Iron" ist ein Beispiel, SCCM kann scheinbar mittlerweile in Verbindung mit Intune auch verschiede Geräte unterschiedlicher Hersteller verwalten. Viele Grüße olc

Hi, nein, es ist meiner Erinnerung nach verbindungsbezogen. Viele Grüße olc

Hi spalato, Du hast auch wirklich Windows Server 2008 R2 auf beiden Seiten? Wie sieht es mit der CMD aus dem TechNet Artikel aus? Dfsradmin membership set /RGName:<replication_group> /RFName:<replicated_folder> /MemName:<DOMAIN\Server>/RO:true Viele Grüße olc

Optimal, danke für Deine Rückmeldung! :) Viele Grüße olc

Hi, Du kannst a) den Global Catalog befragen (servername:3268 = Server + Port), jedoch ist mobilePhone meiner Erinnerung standardmäßig nicht Teil des GC. Das könntest Du aber noch einmal gegenprüfen. b) einfach die Befehle jeweils hintereinander gegen die Domains ausführen und ab dem zweiten Durchlauf hinter das "Export-CSV" ein "-Append" anhängen. ;) http://technet.microsoft.com/en-us/library/hh849932.aspx Das wäre aus meiner Sicht die schnellsten Lösungen. Wenn Du "cool" sein möchtest (und es richtig gut machen möchtest), baust Du Dir ein eigenes PowerShell Objekt, in das Du alle Ergebnisse übergibst und erst danach den Export-CSV Befehl gegen das Objekt ausführst. Das ist nicht schwer, aber vermutlich möchtest Du diese Baustelle gerade nicht auch noch aufmachen oder...? :) Viele Grüße olc