olc

Hallo Gulp, nein, das ist nicht korrekt - der Dependency Walker zeigt die Dateien an, die von der EXE-Datei referenziert sind bzw. die Bibliotheken / Module etc. für die Funktion des Programmes bereithalten. Du siehst damit nicht, auf welche Dateien eine EXE-Datei (bzw. deren Prozess) während der Arbeit zugreift. Jedoch ist Dein Hinweis nicht verkehrt, da ich den TO so verstanden hatte, daß er den Zugriff während der Laufzeit auslesen wollte. Es können natürlich auch die Abhängigkeiten / Referenzen gemeint gewesen sein. Viele Grüße olc

Hi Sascha, Du kannst beispielsweise folgende Tools verwenden: 1. Handle 2. FileMon for Windows Willst Du noch mehr Informationen (z.B. Registry Zugriffe etc.), kannst Du anstatt 2. folgendes Tool verwenden: 3. Process Monitor Viele Grüße olc

Hi Bits, schön, daß es funktioniert. Wer weiß, vielleicht wird das noch gefixt - denn das wird sicherlich nicht nur Dir Probleme bereiten... :D Als Konsequenz aus solchen (immer wieder auftauchenden) Problemen kann man wahrscheinlich nur einmal mehr betonen, daß es durchaus trotz aller Language Packs und neuerdings der propagierten Sprachunabhängigkeit der Betriebssysteme weiterhin Sinn macht, zumindest im Serverbereich nur englische (en-US) Systeme zu verwenden. Viele Grüße olc

Hi, ich hoffe, das Problem richtig verstanden zu haben: Bitte entferne einmal bei den Benutzern den Haken unter "Terminaldienstprofile" bei "Terminalserveranmeldung zulassen". Das scheint ein heftiger Übersetzungsfehler zu sein, denn in der englischen Variante des 2008er Servers gibt der Haken an, die Anmeldung zu verweigern. Dazu solltest Du natürlich alle anderen Testeinstellungen vorher ggf. rückgängig machen. Viele Grüße olc

Öhm - freut mich zwar, daß Du das Problem lösen konntest und vielen Dank auch für Deine Rückmeldung. Aber die Lösung hättest Du schon vorher haben können - ich hatte aus diesem Grund mehrfach nachgefragt, wie die Aufteilung der Clients in die Subnetze aussieht. Daher auch die Bitte um die Ausgabe der oben genannten Befehle zur Feststellung der Clientzuordnung... :rolleyes: Na ja, hauptsache ist gelöst. Viele Grüße olc

Gerne. :) Für alle, die vielleicht einmal vor dem gleichen Problem stehen: Das Zurücksetzen des PDCe Kennworts gegen sich selbst war sicherlich nicht die Ursache und auch nicht die ganze Lösung des Problems. Im Grunde zeigten sich mehrere Fehlerquellen, die Schritt für Schritt abgearbeitet werden mußten. Man sieht auch am Verlauf des Threads, daß sich die Fehler bzw. die Fehlerbilder änderten. Es sieht eher so aus, als ob zu Beginn der Probleme schlicht die Netzwerkverbindung Probleme machte (daher auch bestimmte Connection Objects nicht vorhanden waren, obwohl die Site Links standen) - da auch eine Änderung der VPN-Verbindung im Raum stand, ist die Kerberos MaxPacketSize ein heißer Kandidat. Es konnte dann nicht mehr repliziert werden, was die Vermutung in die Richtung verstärkt, daß schlichtweg auch keine Universellen Gruppenmitgliedschaften repliziert werden konnten, so daß die Benutzer Anmeldeprobleme bekamen. Schlußendlich war auch das DNS noch ein wenig zu überprüfen, wo auch einige Kleinigkeiten geändert wurden. Der letzte Schritt war das Zurücksetzen des Computerkennworts des SBS, was ich persönlich noch nie erlebt habe: Der Befehl mußte ohne stoppen des KDC gegen sich selbst gefahren werden, also als Target der S1 angegeben werden. Wie das zur Problemlösung beigetragen hat, ist mir immer noch unklar. :D Ok, genug gelangweilt. Viele Grüße olc

...nur eine kurze Zusammenfassung, weil schon spät: Wir haben diverse Aktionen durchgeführt, bis hin zu den Klassikern wie An update to turn off default SNP features is available for Windows Server 2003-based and Small Business Server 2003-based computers , KerberosMaxPacketSize, Secure Channel der DCs zurückgesetzt, UPNs geprüft, Firewalls etc. pp. Am Ende: Das Computerkennwort des PDCe (SBS) selbst mußte zurückgesetzt werden, d.h. How To Use Netdom.exe to Reset Machine Account Passwords of a Windows 2000 Domain Controller gegen sich selbst gefahren werden. Unglaublich... Man lernt nie aus. :D Viele Grüße olc

Mhhhh, lag ich wohl falsch mit meiner Vermutung. Die SPNs scheinen korrekt registriert zu sein... :suspect: Also ohne einen Gesamtüberblick komme ich nun auch nicht mit Tipps weiter. Ich schicke Dir einmal eine PN... Gruß olc

Ok, also Site-Links sehen gut aus. Da die anderen beiden Dateien (ldifde Export) noch nicht freigeschaltet sind, stelle ich einmal folgende Vermutung auf: Aus irgendwelchen Gründen funktioniert die Replikation nicht mehr (unter Umständen fehlende SPNs auf dem SBS), daher kann das Universal Group Membership Caching die Benutzerdaten in den externen Seiten nicht vom SBS abrufen. Da hier ein Timeout gesetzt ist, der zyklisch die Daten abrufen soll, kam es mit den Anmeldungen zu Problemen, da die Caches nicht aktuell gehalten werden können. Wie gesagt, ist eine Vermutung. Die Frage ist dementsprechend, wie man die Replikation wieder zum Laufen bekommt. Wenn auf dem SBS SPNs fehlen, kann man diese wieder manuell nachtragen. Wird sich zeigen, ob danach andere Fehler auftauchen - und wenn ja, was zu vermuten ist, welche. Sollte sich der andere DC danach wieder hochstufen lassen, wäre das gleiche Vorgehen für den RUM-S1 angesagt - das ginge am schnellsten. Ist das DCPROMO danach nicht möglich, schauen wir weiter. Wie gesagt, ich warte einmal auf die LDIFDE Exports oben. Viele Grüße olc

...ja, das Bild der Daten paßt zur Beschreibung. Sind zwar noch nicht alle Daten (die kommen vielleicht noch, aber ich bin jetzt mal so frech vorher zu schreiben ;) ), aber eine Nachfrage: Ist der von Dir heruntergestufte DC der "RUM-S1" oder war das ein anderer DC? Fall er es ist - kannst Du mittels NTDSUTIL prüfen, ob er noch in den Metadaten vorhanden ist? Siehe How to remove data in Active Directory after an unsuccessful domain controller demotion - falls auf dem SBS das SBS Server 2003 SP1 installiert ist, ist das recht schmerzlos. Die SPN Daten kannst Du entweder über ADSIEdit, LDP oder LDIFDE ziehen. Am schnellsten sind wir wahrscheinlich mit: ldifde -u -d "CN=S1,OU=Domain Controllers,DC=domain,DC=tld" -f C:\s1.txt Bitte passe den DN des Servers entsprechend Deiner Umgebung im Kommando an. Mal schauen, wie weit wir hier noch per Forum Kommunikation kommen. :D Viele Grüße olc

Dann ist scheinbar der Service Principal Name des Systems nicht korrekt registriert. Schau einmal mittels ADSIEdit o.ä. direkt auf dem Computerobjekt von "S1", was Du dort für Attributwerte für den SPN findest. Sind dort mindestens "host/s1.domaene.tld", "host/s1" und ggf. "cifs/s1.domaene.tld", "cifs/s1" angegeben? Wie gesagt, irgend etwas muß passiert sein, daß die Umgebung jetzt einige (sicherlich zusammenhängende) Probleme hat. Ferndiagnose ist da schwer. Dann scheint die Replikation schon eine ganze Weile nicht mehr geklappt zu haben, kann das sein? Führe auf dem SBS und jeweils auf den anderen DCs ein "repadmin /showrepl" und ein "repadmin /relsum" aus und poste den Export (bitte nicht als "QUOTE", sondern als "CODE" ;) ). Ok, ist also offensichtlich schon passiert. :D An welchen DC wendet sich der demotete DC, wenn er sich wieder promoten will? Schau einmal in das DCPROMO.LOG unterhalb von %SYSTEMROOT%\Debug nach einem DCPROMO-Versuch. Unter Umständen versucht der DC ja einen der Außenstellen-DCs zu erreichen, nicht den SBS. Die Site Links in den AD Sites and Services sind korrekt eingerichtet? Bitte mal als CODE ;) ein repadmin /showism /v posten. Viele Grüße olc

...als kleine Ergänzung: Eine gute Möglichkeit, um einen Einstieg in das Thema zu bekommen und das ganze ein wenig "plastisch" zu verfolgen ist, wenn Du einen Netzwerktrace vom Boot-Vorgang eines Clients ziehst. Dort filterst Du nach DNS Abfragen und kannst den Ablauf recht gut nachverfolgen. :) Viele Grüße olc

...auf keinen Fall den SBS demoten. Ich habe es so verstanden, daß die Fehlermeldung nicht beim Zugriff auf den SBS geloggt wird, sondern nur beim Zugriff auf einen der anderen DCs? Es ist immer ein wenig schwierig ein solches Problem mit nur wenigen Daten einzugrenzen. Von daher will ich hier auch keine "Allerweltstipps" geben, die unter Umständen das ganze noch verschlimmbessern. Die Security Events werden auf dem SBS geloggt? Es ist ausgeschlossen, daß das Kennwort falsch ist? Kannst Du Dich mit den Daten direkt am SBS anmelden? Läuft der KDC Dienst? Starte einmal den NETLOGON Dienst oder besser gleich den ganzen SBS neu, wenn Du ein Wartungsfenster dafür hast. Ich glaube man muß das ganze Szenario erst einmal ein wenig ordnen, bevor man vielleicht helfen kann. Viele Grüße olc

Hi Markus, na ja - durch "herumklicken" macht man es natürlich oftmals nur noch schlimmer... :wink2: Mal abgesehen davon, daß es ganz offensichtlich Probleme bezüglich der DNS-Registrierung des DCs gibt (was vielerlei Ursachen haben kann, so auch den zerbrochenen secure channel o.ä.), würde ich mich gar nicht lange damit aufhalten. Soll heißen: Ist es möglich, den DC neu zu promoten? Gruß olc

Hi brolek, das ist jetzt nicht böse gemeint - aber wo liegt das Problem? Mit ein wenig Aufwand kannst Du die Ausgabe in anderem Format anzeigen lassen, dazu mußt Du nicht das Script nehmen, es reicht Excel oder ähnliches. Hier im Forum wird im Normalfall gern geholfen, aber ein wenig eigene Arbeit von Dir muß schon kommen - sonst kann man auch einen Dienstleister bezahlen, der die hier kostenlose Hilfe dann berechnet... Zum Thema: Warum fragst Du nun nicht mehr die Verteilergruppen ab? Du hattest geschrieben, daß Du Verteilergruppen und keine Sicherheitsgruppen abfragen willst. Warum nutzt Du nun "-2147483640", also Universal Security Groups? Wenn Du die DSQUERY Ausgabe partout nicht umbauen kannst oder willst, kannst Du es mit folgendem PowerShell Script probieren: $category = "(&(objectcategory=group)(|(grouptype=8)(grouptype=4)(grouptype=2)))" $AD = [ADSI]"LDAP://DC=testdom,DC=intern" $properties = "member", "cn" $search = New-Object System.DirectoryServices.DirectorySearcher($AD,$category) $search.PageSize = 1000 foreach ($value in $properties) { $search.PropertiesToLoad.Add($value) } $result = $search.Findall() foreach ($res in $result) { write-host write-host write-host $res.properties.cn write-host ======================= write-host $res.properties.member } Es werden zwar immer noch die Gruppen hintereinander mit Leerzeichen getrennt im DN-Format ausgegeben, da die Gruppen alle im "Member" Attribut gelistet werden. Auf die Schnelle bekommt man jedoch keine andere Ausgabe ohne weitere Schleifen innerhalb des Scripts hin. Wenn Du also die Gruppen untereinander und im displayName Format haben möchtest, mußt Du "Sub-Schleifen" einfügen. Dies kann dann aber eine höhere Last auf den DCs erzeugen. Viele Grüße olc

Hallo Pete, welches Budget steht Dir zur Verfügung? Der MOM / SCOM bietet solche Möglichkeiten - ist aber recht teuer. Ansonsten fällt mir auch sponan nur der von Dieter vorgeschlagene Syslog Daemon ein - obwohl ich nicht weiß, ob man dort auch Windows Events "ablegen" / "hinsenden" kann. Letztendlich gibt es sicherlich einige Möglichkeiten, Logfiles "irgendwie" abzuholen. Was genau möchtest Du erreichen? Eher eine Archivierung oder eher eine Auswertung? Viele Grüße olc

Hallo, trifft das unter Umständen Dein Problem? You receive information for a different local group than you specified when you use the "net localgroup" command on a domain controller that is running Windows Server 2003 Warum läßt Du Dir die Gruppenmitgliedschaften beispielsweise nicht per dsquery / dsget anzeigen? Handelt es sich um eine Windows Server 2003 Umgebung - dann wäre dies die bessere Alternative. Viele Grüße olc

...vor allen Dingen wäre die Frage, was genau in diesem Zusammenhang an Cygwin und dessen Linux-Tools besser sein sollte? FINDSTR bringt auch eine Menge Regular Expressions mit - da sollte man fast immer zum Ergebnis kommen. Cygwin ist in diesem Zusammenhang meines Erachtens vollkommen unnötig. Viele Grüße olc

Hallo Markus, kannst Du bitte die Event IDs zu den Fehlermeldungen mit posten? Ich vermute, daß es sich bei den KCC Fehlern um 1311, 1566 und 1865 handelt? Sind die Replikationspartner denn per Ping / Tracert (auf den FQDN) erreichbar? Welche Connection Objects sind automatisch vom KCC angelegt? Ggf. könnte es Sinn machen, temporär manuelle Connection Objects einzurichten, bis die Replikation des Config NCs durchgelaufen ist. Danach sollte einer korrekten Topologiebildung nichts im Wege stehen - unter Umständen zieht sich der KCC jedoch auch selbst wieder aus dieser Situation. Vorausgesetzt die Netrzwerkverbindung als solches steht. Wurde an der Netzwerkverbindung oder den DCs irgendetwas verändert, bevor der Fehler auftrat? Grundsätzlich richtiger Ansatz, jedoch nützt dem TO das reine bestimmen des ISTG recht wenig. ;) Die Bestimmung geht ab Windows Server 2003 davon einmal abgesehen einfacher, als im Artikel beschrieben: "repadmin /istg" zeigt die ISTG aller Sites an. Viele Grüße olc

Hallo, sag mal, hast Du meinen Beitrag überhaupt richtig gelesen? Ich habe Dir die Antwort meines Erachtens schon gegeben... :rolleyes: Viele Grüße olc

Guten Abend, Und Du nutzt auch die R2 Dienste, also DFS-R? Das hört sich später in Deinem Post nämlich nicht so an. ...womit noch nicht geklärt wäre, ob Du die Rechte des Namespaces selbst oder die Rechte des Ordnerziels bearbeitet hast. Aber das hast Du später in Deinem letzten Post noch präzisiert. Nein, denn wie auch in Deinem Fall können im Zielverzeichnis schon Daten liegen. Es werden hier (bei DFS-R) nicht alle Daten noch einmal repliziert, sondern die vorhandenen Daten mit in den Prozess mit einbezogen. Bei FRS ist das nicht so - dort werden alle Daten repliziert. Hier redest Du wieder von FRS-Staging. Sieht also so aus, als ob Du nicht DFS-R, sondern FRS nutzt. Dann sieht die Antwort nämlich tatsächlich anders aus. Wie gesagt, bei DFS-R werden nur die ACLs repliziert, bei FRS werden in diesem Fall alle Dateien repliziert, nicht nur die Änderungen. Unter FRS wurden grundsätzlich keine Deltas repliziert, sondern nur ganze Dateien. Remote Differential Compression. Da es entgegen Deiner ersten Aussage scheinbar doch um FRS und nicht DFS-R geht, ist diese Technik in diesem Fall nicht relevant. Na ja... ;) Wie schon mehrfach gesagt: --> FRS: Die Dateien werden komplett repliziert, da keine Delta-Replikation möglich ist. --> DFS-R: Nur die ACLs werden repliziert, es sei denn RDC ist ausgeschaltet (nicht empfehlenswert). Viele Grüße olc

Hi, als Ersatz für Tapes sind Festplatten eher nicht geeignet, allenfalls als Ergänzung. Warum möchtest Du die Tapes denn ablösen? Viele Grüße olc

Hallo, ein Programm dafür kenne ich leider nicht, aber vielleicht hilft Dir folgender Ansatz weiter: Hey, Scripting Guy! How Can I Tell Whether a Group is a Security Group or a Distribution Group? Wie im Artikel aufgeführt stehen die "groupType" Attributwerte "2", "4" und "8" für Verteilergruppen (mit unterschiedlichem Group Scope). Du kannst dieses Attribut nun mit beliebigen LDAP-Tools abfragen. Am Beispiel der DSTOOLS: dsquery * -filter "(&(objectclass=group)(|(grouptype=8)(grouptype=4)(grouptype=2)))" -attr cn member Wie Du das dann formatierst, ist Dir überlassen. ;) Wenn Du diese Abfrage beispielsweise in der PowerShell abbildest, stehen Dir viele Formatierungsoptionen zur Verfügung. Viele Grüße olc

Hi Kashina, schon die MS KB-Artikel dazu durchforstet? site:microsoft.com NETLOGON 5774 - Google-Suche Zusätzlich den folgenden Hotfix installiert? An update to turn off default SNP features is available for Windows Server 2003-based and Small Business Server 2003-based computers Unter Umständen bringt Dich das ja schon weiter. :) Viele Grüße olc

Hallo Andi, das ist doch einmal ein klasse Feedback. Schön, daß alles gut geklappt hat. :) In der Tat erledigt ntdsutil ab der SP1 Version für Windows Server 2003 einiges gleich mit - so auch das Aufräumen der DNS Einträge. Funktioniert leider nicht immer 100%ig, zumindest jedoch meistens recht gut. Überprüfen schadet daher nichts. ;) Viele Grüße olc