olc

Hi,

grundsätzlich gute Punkte von gysinma1, ich wäre jedoch nicht so leichtfertig alle Policies zurückzusetzen. ;)

Außerdem wurden einige der Fragen schon beantwortet.

Da wir nun erst einmal einige grundsätzlichen Dinge abgeklopft haben, kann man weiter machen. Vorher ist das Problem meist nur schwer möglich einzugrenzen (ob Client oder DC Problem).

Ich könnte mir auch vorstellen, daß es ein Problem mit den NTLM Einstellungen gibt. Prüf doch einmal die folgende Policy: "LAN Manager Authentication Level: Send NTLMv2 response only\refuse LM & NTLM" (siehe Microsoft Corporation)

Was ist dort eingestellt?

Bitte schaue auf einem Client, der Probleme beim Joinen hat, unterhalb von %SYSTEMROOT%\Debug nach der Datei "Netsetup.log". Bitte stell die einmal zur Verfügung. Dort kann man sehen, was während des Joins passiert - vielleicht ist etwas zu sehen.

Der Hinweis von blub bezüglich des Netzwerktrace ist auch gut, vielleicht kannst Du den Vorgang einmal tracen.

Bitte mach auch einmal einen LDIFDE Export des Client-Objekts, nachdem es mit einem roten X markiert ist, also deaktiviert (oder schau mittels ADSIEdit bzw. LDP) - hat der Client eine SID zugewiesen bekommen?

Ich gehe davon aus, daß der Benutzer, mit dem Du die Clients in die Domäne holst, Domain-Admin ist? In wie vielen Gruppen ist der Benutzer Mitglied? Geht es unter Umständen mit einem anderen Benutzer?

Als nächsten Punkt solltest Du folgenden KB-Artikel prüfen: You receive an error message when you join a domain with Windows XP

Wenn Du mit allem durch bist, melde Dich wieder. ;)

Viele Grüße

olc

...das hatte der TO oben schon beantwortet.

BTW: NewSID ist zum testen ganz nett - für den Produktiveinsatz jedoch nicht zu empfehlen, da es nicht von MS supported wird.

Gruß olc

Hi,

ok, DNS scheint also auch zu stimmen.

Vielleicht fällt ja jemandem auch noch was anderes ein, eher ich mir meine reellen Clients schrotte....

Wie gesagt, Du solltest auf jeden Fall einen nicht virtualisierten Client testen.

Vorher kannst Du (wie oben schon geschrieben) einmal versuchen, die VMWare Tools Komponente "Shared Folders" zu deinstallieren. Vielleicht hat das schon den gewünschten Effekt.

Viele Grüße und viel Erfolg ;)

olc

...jepp, das wäre auch meine nächste Frage gewesen. :)

Ggf. versuche auch einmal, die Shared Folder vom Client zu deinstallieren (Stichwort: VMWare Tools).

DCDiag und NetDiag sehen erst einmal gut aus. Was sagt ein "nslookup da.net" vom Client aus abgesetzt?

Gibt es nur den einen DC in der Umgebung? Hast Du den schon einmal neu gestartet (ggf. ist irgend ein Dienst nicht aktiv)?

Gruß olc

Hi Matthias,

was sagt ein "dcdiag /test:knowsofroleholders /v"? Kannst Du die Ausgabe einmal posten? Ggf. ist der RID-Pool ausgegangen, falls der RID-Master nicht korrekt läuft, oder vielleicht hat der PDCe ein Problem.

Sind denn im Eventlog des Clients als auch der DCs irgendwelche Fehler zu finden?

Was sagt ein komplettes Netdiag und Dcdiag, ausgeführt auf den DCs. Sind dort Fehler zu finden?

Hat sich in letzter Zeit (vor den Problemen) irgendetwas an Deiner Umgebung geändert (im Netzwerk, Hotfixes, Programme etc.)?

Viele Grüße

olc

Hi,

Na, besonders viel Aufwand ist das Ganze auch nicht wirklich.

Das muß am Ende des Tages jeder selbst entscheiden. Jeder Dienst frißt jedoch Brot und will gewartet werden. Da ist DFS-N keine Ausnahme.

Und gerade weil sich oftmals nicht richtig Gedanken gemacht wird, was für seine Umgebung optimal ist und was nicht, werden Consultingfirmen als auch dieses Forum (glücklicherweise) wohl nie Arbeitslos.

Viele Grüße

olc

Hi,

wie gesagt - ich war mir da nicht 100%ig sicher. Wenn Du dazu nichts gefunden hast, wird es wohl funktionieren. ;)

Nach einer kurzen Suche habe ich dazu auch nichts gefunden - vielleicht habe ich es mit DFS-R verwechselt.

Nichtsdestotrotz kann man die Terminal-Profile von Benzutzern per Script auch recht schnell in einer "Bulk-Aktion" ändern. Ich persönlich fände den Aufwand, eine DFS-N Struktur für einen File-Server (und dessen Ablösung weit in der Ferne) zu betreiben, gemessen am Nutzen eher zu hoch. Aber darüber läßt sich sicherlich streiten. ;)

Viele Grüße

olc

Hallo ela,

wenn Du die Daten zusammenführen willst und keine R2 Lizenzen hast (von FRS sehen wir an dieser Stelle einmal ab) kannst Du unter Umständen auch UNISON verwenden, siehe Unison File Synchronizer .

Viele Grüße

olc

...es sei denn, die Ordner lassen "SYSTEM" Zugriff per ACL zu, dann kannst Du per Robocopy / Xcopy Script mittels geplantem Task oder interaktiv im SYSTEM-Kontext die Dateien kopieren.

Viele Grüße

olc

Hi banani,

ich bin nicht 100%ig sicher, aber ich denke das sollte z.B. mit Robocopy machbar sein: Download details: Windows Server 2003 Resource Kit Tools

Viele Grüße

olc

Hi,

ich bin mir gerade nicht 100%ig sicher, aber ich habe im Hinterkopf, daß Userprofiles auf DFS-N / mit DFS-N Pfaden zu Problemen führen können bzw. nicht supportet sind (mal abgesehen von DFS-R). Vielleicht solltest Du das vorher noch einmal prüfen. Wenn ich ein wenig Zeit habe schaue ich auch noch einmal, ob ich dazu etwas finde.

Viele Grüße

olc

Hallo,

bei nur einem Server macht meines Erachtens DFS-N eher weniger Sinn. Es sei denn, spätere Änderungen sind dahingehend geplant, daß weitere Server hinzugefügt werden sollen und die Benutzer oder Applikationen über Namespaces auf die Server zugreifen sollen. In den meisten Fällen mappen jedoch Logon-Scripts direkt Laufwerke für die Freigaben, das ändert man dann zentral und benötigt nicht DFS-N.

Ich will damit nicht sagen, daß es keinen Sinn macht - es muß jedoch nicht immer Sinn machen, je nach Umgebung. Wenn man langfristig plant, kann es durchaus interessant sein - je nach Umgebung. Es gibt da keine grundsätzliche Aussage - vielleicht kannst Du ein paar mehr Details dazu geben.

Um die Daten später zu replizieren (obwohl da auch robocopy, ntbackup etc. ausreichend wären), brauchst Du kein DFS-N. Die DFS-R Replikation läuft auch ohne Namespaces, da beide Techniken vollkommen unabhängig voneinander sind.

Viele Grüße

olc

Hi,

noch ein anderer Einwurf zu dem Thema: Ist der Benutzer eine Person oder stellt der Account einen Service Account o.ä. dar?

Wenn der Benutzer eine reale Person ist, kann er sich mit Admin-Rechten auch weitere Accounts / Gruppen anlegen, die Du ebenfalls überprüfen müßtest.

Außerdem kann ein Benutzer auch verschachtelt über Gruppen in der Gruppe der Administratoren Mitglied sein - auch ein möglicher Schwachpunkt, nur die built-in Administratoren Gruppe auszulesen.

Sind verschiedene Sprachversionen in der Umgebung enthalten, hilft die Abfrage auf den Namen auch nicht weiter.

Die Varianten mit den Loginscripts finde ich persönlich nicht so optimal, da das Auslesen immer von der Anmeldung des Benutzers abhängig ist. Ich würde eher eine Remote-Lösung wählen, wie oben einige gepostet wurden.

Alles in allem gibt es also noch einige Fehlerquellen. Vielleicht kannst Du ja noch einmal ein wenig genauer schildern, was genau der Hintergrund ist.

Viele Grüße

olc

ein anderer zentraler Weg ginge so:

 

FOR /F usebackq %%a IN (`dsquery computer "ou=xpclients,dc=domain,dc=de" -o rdn`) DO (%%a >>admingroups.log

psexec \\%%a net localgroup administratoren>>admingroups.log

)

 

 

dazu muss allerdings das psexec von Windows Sysinternals: Documentation, downloads and additional resources verfügbar auf dem AbfrageClient sein und klar, die PCs müssen eingeschaltet sein.

Ok, dann ginge es auch einfacher (ohne PowerShell oder psexec), nämlich mittels WMIC. Angepaßt sähe das Statement dann so aus:

FOR /F usebackq %%a IN (`dsquery computer "ou=xpclients,dc=domain,dc=de" -o rdn`) DO (wmic /NODE:%%a /USER:"DOMAIN\user" /PASSWORD:"kennwort" /namespace:root\cimv2 useraccount) >> accounts_%%a.txt

Viele Grüße

olc

Hallo,

poste bitte einmal den Export folgender Befehlszeile:

icacls "C:\Program Files"

An welcher Stelle / bei welcher Aktion bekommst Du genau das "Access denied"?

Viele Grüße

olc

Hallo,

wie Christoph schon sagte, handelt es sich dabei um die CRL, die nicht abgerufen werden kann. Da Du scheinbar eine interne CA verwendest, brauchst Du keine Internetverbindung - Deine eigene CA ist ja authorisierend.

Wohin zeigt denn die CRL?

Ist der Pfad verfügbar, wenn Du direkt per Browser darauf zugreifst?

Wie hast Du Deine interne CA konfiguriert?

Hast Du die CAPolicy.inf bei der INstallation angepaßt / erstellt?

Viele Grüße

olc

Hallo cbarth,

Hab ich da einen Denkfehler?

Wenn ich das Problem richtig verstanden habe: Ja, ein Denkfehler. :)

Die Loopbackverarbeitung hat grundsätzlich erst einmal nichts mit der Default Domain Policy zu tun. Du gibst damit an, daß nicht die Benutzereinstellungen der Policies des Benutzers gezogen werden, sondern die Einstellungen, die in den Polcies oberhalb des entsprechenden Computerkontos definiert sind (mal abgesehen von den zwei unterschiedlichen Modi der Loopbackverarbeitung "merge" und "replace").

Wie der Name sagt, hängt die Default Domain Policy auf Domänenebene - das Verschieben der Server in eine andere OU kann also auch keinen Effekt in Bezug auf diese Policy haben. Denn in beiden Fällen (Loopback als auch verschieben des Computerobjekts) greift diese Policy in jedem Fall auf dem Server.

Der richtige Weg wäre also, die Einstellungen (Scripts) nicht in der Default Domain Policy zu setzen. Ist übrigens auch "Best Practice", für solche Einstellungen nicht die Default Domain Policy zu bearbeiten.

Oder habe ich die Frage falsch verstanden?

Viele Grüße

olc

Hi,

wie wäre es mit einer WMI-Abfrage? Die Rechner lassen sich vorher aus der AD auslesen o.ä. und dann an die Abfrage übergeben.

Ein Ansatz dafür wäre folgende Abfrage (PowerShell, geht aber auch mit normlem WMIC oder VBScript etc.):

Get-WmiObject -query "Select * from Win32_UserAccount" -namespace root\cimv2 -computername <COMPUTER>

Gruß olc

Hallo,

mit welchen Benutzerberechtigungen versuchst Du es denn? Bist Du als Administrator angemeldet?

Ist per GPO oder lokaler Policy etwas an den "Nachfrageoptionen" der User Account Control (UAC) geschraubt worden?

Viele Grüße

olc

Hi,

ich kann mich da Lian nur noch einmal anschließen: Nichts für Ungut bezüglich der Mühe von LukasB und gysinma1 - aber Ihr solltet nicht "per se" irgendwelche Techniken empfehlen, ohne überhaupt einen kleinen Überblick über das zu haben, was der TO oder der später Fragende eigentlich im Einsatz hat bzw. plant. Solche generischen Aussagen sind meist nicht unbedingt zielführend.

Besonders verwirrend ist dabei, daß der Thread hier gerade von "nurmalso" sozusagen "gekapert" wird. Ist auch nicht die feine Art.

Um das ganze nicht noch weiter abdriften zu lassen, schreibe ich an dieser Stelle nicht allzuviel zu der ganzen DFS-R Thematik - nur soviel: Diese von Euch beschriebenen Szenarien kann man zwar einrichten, jedoch entspricht das explizit nicht dem gedachten Einsatzzweck von DFS-R. Als "Cluster für Arme" ist das zwar recht nett, aber in den meisten mir bekannten Umgebungen führt das früher oder später zwangsläufig zu Problemen. Also nach Möglichkeit sollte es nicht so eingesetzt werden...

Viele Grüße

olc

auch die Useranzahl wäre interessant.

Jepp, deshalb hatte ich auch folgendes geschrieben:

und schreibe dann ein paar Beispiele gespickt mit Zahlen (z.B. Benutzer, Budget, Dienste)

Aber Dein Einwurf verdeutlicht das noch einmal. ;)

Gruß olc

Hi Rudy,

je nach Setup ist es möglich, das Objekt zu löschen. Stelle jedoch bitte vorher sicher, daß nicht kürzlich (im Rahmen von Eurem Replikationszyklus + ca. 1 Stunde) Änderungen in Bezug auf DFS-R stattgefunden haben - sonst zerhackst Du Dir unter Umständen die entsprechende Replikationsgruppe.

Du solltest darauf achten, daß das Objekt tatsächlich nur unter den DFSR-LocalSettings des entsprechenden Server vorhanden ist. Existiert ein Subscriber Object in den DfsrGlobalSettings im System-Container, solltest Du das Subscriber Object defintiv nicht löschen.

Um das Objekt zu prüfen, mußt Du die vorhandenen Replikationsgruppen in den GlobalSettings öffnen (CN=Topology,CN=Replikationsgruppe,CN=DFSR-GlobalSettings,CN=System,DC=domain,DC=tl) und unterhalb von Topology jedes Replikationsgruppenobjekts prüfen, ob dort eine entsprechende GUID des DFS-R Memberservers vorhanden ist (also die, die Du in der Fehlermeldung des Eventlogs findest).

Wie schon richtig von Dir geschrieben, sollten die falschen Subscriber keine Probleme in Deiner Umgebung auslösen - wenn das jedoch öfter auftritt, solltest Du einmal nach Ursachen prüfen.

Mit ADSIEdit.msc (aus den Support Tools), kannst du dich zu dem im Log referenzierten Objekt durchklicken und es entfernen.

Jepp, ADSIEdit ist wahrscheinlich die einfachste Lösung.

Ist vermutlich ein Restbestand vom vorherigen FRS.

Nein, die Fehlermeldung zeigt auf ein DFSR Subscriber Object - FRS hat einen eigenen Zweig. :)

Aber Vorsicht, man kann mit ADSIEDit auch, Schnipp, schnell was Falsches wegschneiden. Daher vorher Server sichern

Ja, kann man nicht oft genug betonen. :)

Viele Grüße

olc

Hallo Martin,

um welches Server Betriebssystem handelt es sich? Bei Windows Server 2003 R2 hast Du FSRM mit dabei - das sollte Dir die gewünschten Informationen bieten.

Falls es kein R2 ist - über welches Budget verfügst Du diesbezüglich?

Viele Grüße

olc

Hallo Mrichard28,

bevor man Dir eine konkrete Antwort geben kann, müssen einige Eckdaten bekannt sein. In erster Linie muß man wissen, welche Dienste die Server hosten. Vorher ist schlichtweg keine Aussage möglich - denn einen Exchange oder SQL-Server kann man ggf. anders absichern als einen Fileserver.

Außerdem stellt sich die Frage nach dem Budget: Cluster bieten in vielen Bereichen eine Möglichkeit, Ausfälle von Diensten bestenfalls zu verhindern. Das kostet aber neben der Anschaffng diverser Komponenten natürlich einiges an KnowHow und Pflege. Die Applikationen / Dienste müssen dafür ebenfalls ausgerichtet sein - nicht jede Applikation / nicht jeder Dienst ist zum Beispiel clusterfähig.

Defniere also zuerst Dein gewünschtes Schutzlevel und schreibe dann ein paar Beispiele gespickt mit Zahlen (z.B. Benutzer, Budget, Dienste) - danach kann man mehr dazu sagen. :)

Viele Grüße

olc

Hi xXMCPXx,

ja - warum nicht? Was willst Du denn genau erreichen bzw. was genau ist die Frage?

Viele Grüße

olc