olc

Hi, Vielleicht liege ich hier falsch - aber mir wäre der Sinn der Festlegung nicht ganz klar. Was soll damit erreicht werden? Setzt man diese Umgebungsvariable, ist die Authentifizierung des Benutzers schon erledigt. Zusätzlich dürfte man es nicht nur in einer normalen CMD festlegen, da die Festlegung der Variable sonst nur in der entsprechenden CMD gilt. Außerdem ist es so, wie Du auch richtig sagtest: Das macht in dem Szenario keinen Sinn. Wenn man das schon durchführen möchte, dann sollte mit DNS Prioritäten gearbeitet werden. Aber auch dies ist bei der Fragestellung des TO sicher nicht zu empfehlen. Also ich werde das Gefühl nicht los, daß Du kein Problem hast. ;) DNS arbeitet standardmäßig mit Round Robin, d.h. die DCs werden "zufällig" wiedergegeben bzw. zirkulär. Von daher paßt das zu Deiner Beobachtung. Außerdem hast Du immer noch nicht die Fragen oben beantwortet. Von daher stochern wir hier im Dunkeln... [EDIT] Achso, noch ein Nachtrag: Wenn Du das NLTEST /DSGETDC Kommando ausführst, nutze die /force Option. Sonst wird der Cache verwendet. Hatte ich vergessen zu erwähnen... [/EDIT] Viele Grüße olc

;) Hauptsache man lernt daraus und ist nicht lernresistent. :) Schön, daß es letztendlich dann doch geklappt hat. :) Viele Grüße olc

Hi Alveran, Ok. Nein, Du hattest es das erste Mal in dem zitierten Abschnitt "erwähnt", daher die Nachfrage. "Aber egal". ;) Hast Du denn schon einmal wie angesprochen nach den Diensten geschaut und die Account Lockout Tools (siehe oben) eingesetzt? Das ist in jedem Fall besser als das Process Tracking. Falls Du es trotzdem unbedingt versuchen möchtest: Audit process tracking: Security Configuration Editor; Security Services Viele Grüße olc

Hi, ok - jetzt gehst Du also wieder zum Urspungsthema über. Nicht sonderlich übersichtlich. :wink2: Ich wiederhole mich bei dem Thema hier im Board immer wieder (siehe auch oben) - aber Rechtsklick --> Eigenschaften auf den Ordner ist keine zuverlässige Art und Weise, die replizierte Datenmenge zu bestimmen. Dein Problem bestätigt das einmal mehr... :D Danke für Deine Rückmeldung und Gruß olc

Hi, ich habe die Standard Intervalle für die Veröffentlichungsintervalle nicht im Kopf ;) - also schau doch auf der Stamm-CA einmal nach, wie sie eingestellt sind (Rechtsklick auf die CA, dann in den Eigenschaften nachschauen). In jedem Fall sind die HTTP-Verteilungspunkte nicht erreichbar, das solltest Du prüfen. Da aber die Verteilungspunkte bzw. Zertifikate über LDAP erreichbar sind, liegt hier meines Erachtens nicht das Hauptproblem (es kann aber mal eins werden, also schau trotzdem mal drüber). Da jedoch die Stamm-CA abgeschaltet wird, können die CRLs / Delta CRLs nicht ausgegeben und im AD veröffentlicht werden. Da liegt wahrscheinlich das Problem. Die Clients haben zumindest standardmäßig so etwas wie eine "grace period" nach dem Ablauf einer CRL / Delta CRL, jedoch können Sie nach Ablauf dieser Zeitspanne nicht mehr validieren. Dann kommt es höchstwahrscheinlich in Deiner Umgebung zu dem Fehler. Ich würde nicht die Zeitspanne anpassen, sondern die Stamm-CA online nehmen und ggf. die Veröffentlichungsintervalle der CRL und Delta CRL anpassen. Dann hast Du mehr Zeit, bis Du die CA hochfahren mußt. Grundsätzlich ging es mir nicht um die Betriebssyteme (Standard oder Enterprise Version), sondern um die Installationsart ;), siehe Types of certification authorities: Public Key . Viele Grüße olc

Hallo, Hast Du es noch einmal geprüft? Schau doch einfach einmal, ob a) die beiden DCs beide in der selben, korrekten Site in der _msdcs DNS-Zone eingetragen sind. Falls ja prüfe b) ob die Prioritäten und Gewichtungen der DNS Einträge gleich sind. Nur um sicher zu gehen :) : Das bedeutet, daß die Client Subnetze auch den korrekten Sites zugeordnet sind (schau einmal in den Standorten und Diensten). Genau das ist doch der Punkt. ;) Nur für das Verständnis möchte ich noch einmal explizit sagen, daß es grundsätzlich erst einmal keine Rolle spielt, welcher DNS Server als 1. DNS Server bei den Clients eingetragen ist. Solange die DNS Partitionen auf den DC korrekt repliziert werden, ist das "egal". Du gibst damit ja nicht an, welcher DC genutzt werden soll - Du gibst damit an, von welchem DNS Server sich die Clients zuerst versuchen sollen, die DC-Informationen zu ziehen. Welcher DC dann zurückgegeben wird, ist eine andere Sache. How Domain Controllers Are Located in Windows Eine kleine Korrektur noch zu meinem Beitrag gestern: Der DC, zu dem vom Client der sichere Kanal aufgebaut wurde, ist nur der bevorzugte DC bei NTLM. Für Kerberos gilt das nicht, daher auch nicht für normale Benutzeranmeldungen unter XP / 2003. Hast Du denn einmal die anderen NLTEST Kommandos ausgeführt (insbesondere "NLTEST /DSGETDC:domain.tld")? Bekommst Du immer denselben DC oder verteilt sich das auf die beiden DCs? Ok, also wir sollten hier schon sicher sein, daß Du auch wirklich ein Problem hast. ;) Laß Dir über ein Logon Script der Benutzer einfach einmal den LOGON Server in eine Textdatei schreiben und schaue, ob es immer derselbe DC ist. Gibt sicher auch andere Varianten das heraus zu finden, aber diese ist schnell erledigt. Wenn dann nicht nur ein DC drin steht oder das Verhältnis stimmt, reden wir hier über Phantomprobleme... ;) Viele Grüße olc

Guten Abend, Nein, es kommt nicht darauf an, "wer schneller antwortet", sondern welcher DC über DNS zurückgegeben wurde - im Normalfall wird der LOGON Server genutzt, der beim Computerstart genutzt wurde (secure channel). Sollte der erste zurückgegebene DC nicht antworten, werden die nächsten DCs herangezogen, die vom DNS zurückgegeben wurden (entweder in der Site oder in den globalen DNS Einträgen). Daher wäre zuerst einmal interessant, ob an den Prioritäten / Gewichtungen der DNS Einträge der DCs geschraubt wurde oder ob die Clients als auch die DCs korrekten Sites zugeordnet sind. Hast Du die Subnetze entsprechend den Sites zugewiesen bzw. sind überhaupt mehrere Sites vorhanden? Ggf. könntest Du einmal NETLOGON Logging einschalten (Client und Server) als auch die DNS Einstellungen noch einmal prüfen. Enabling debug logging for the Net Logon service Ein Netzwerktrace während eines Computerneustarts eines Clients oder während eines "NLTEST /SC_RESET:domain.tld" kann auch schon einige interessante Informationen liefern. NLTEST kannst Du auch nutzen, um zu schauen, ob tatsächlich immer der stärker belastete DC bei einem DsGetDCName verwendet wird: "NLTEST /DSGETDC:domain.tld". Bekommst Du immer denselben DC zurückgeliefert? Es kommt immer darauf an, was genau genutzt wird. Für reine "DC-Funktionen" / "DC-Dienste" sollte es keine Probleme machen, einen der beiden DCs abzuschalten. Wichtig dabei wäre, daß auf den DCs selbst auch die beiden DNS Server eingetragen sind. Sollten natürlich andere Dienste auf den DCs laufen, kommt es vielleicht zu Problemen. Vor dem Abschalten eines DCs solltest Du meines Erachtens erst einmal die Punkte oben prüfen / loggen. Zusätzlich wäre auch die Ausgabe eines DCDIAG / NETDIAG relevant. How Domain Controllers Are Located in Windows Viele Grüße olc

Hi, ich habe gerade erst gelesen, daß Du die Stamm CA AD-integriert als offline CA betreibst. Das ist so vom Design her nicht wirklich korrekt - eine offline Root CA betreibt man im Normalfall als Stand-Alone CA ohne Domänen-Mitglied zu sein, um Probleme bei der Domänenmitgliedschaft und der langen offline Zeit zu vermeiden. Das aber nur am Rande. Die Ausgabe des certutil-Befehls sollte im Normalfall noch mehrere Punkte umfassen, nicht nur die von Dir angegebenen. Aber in dem Export von Dir oben ist zu sehen, daß auf die HTTP CDP nicht zugegriffen werden kann. Das solltest Du einmal gegenprüfen. Das Stamm-CA Zertifikat sollte ebenfalls in der AD verfügbar sein sowie die CRLs und Delta. Das Problem dabei ist jedoch, daß die Pafde in dem Zertifikat der Untergeordneten CA enthalten sein müssen, damit diese die Zertifikatkette korrekt vervollständigen kann. Ich vermute, Du hast den Intervall für das veröffentlichen der Delta CRL auf der Stamm-CA auf einen Tag gesetzt? Damit würde sich erklären, warum ab dem zweiten Tag Probleme auftreten - die Delta CRLs fehlen schlichtweg und unter Umständen Ihr Zugriffspunkt. Sind denn die Delta CRLs als auch die normalen CRLs der Stamm CA auch im AD veröffentlicht? Ist die Stammzertifizierungsstelle eine Enterprise CA (dann sollte das automatisch passieren) oder eine Stand-Alone CA, die halt nur ein Domänen-Mitlgied ist? In letzterem Fall müßtest Du AIA (also Zertifikat der Stammzertifizierungsstelle) als auch die CDP (CRLs / Delta CRLs) selbst im AD veröffentlichen. Viele Grüße olc

Hi, hast Du die Firewall des Quell- und Zielsystems entsprechend angepaßt? Welche Fehlermeldung bekommst du genau? Wie greifst Du genau auf das Share zu (bzw. versuchst es)? Viele Grüße olc

Hi, Du solltest die Dienste auf keinen Fall "einfach abdrehen". Damit klemmst Du die WMI vom System ab, was heftige Probleme nach sich ziehen kann. Viel eher wäre interessant, warum die WMI Datenbank / das Repository so stark ausgelastet ist. Einen ersten Ansatz findest Du vielleicht mit dem WMI Error Logging: Turn WMI error logging on or off: Windows Management Instrumentation (WMI) . Viele Grüße olc

Hi, Schau einmal mittels Start --> Ausführen --> "control keymgr.dll", ob etwas hinterlegt ist. Mh, habe ich das überlesen oder hattest Du es gar nicht geschrieben? War ja auch erst einmal ein Ansatz, nicht die Komplettlösung... ;) Sehe ich im Grunde auch so - ist nur leider in solchen Umgebungen oftmals nicht so "einfach". Wobei man hier dann abwägen sollte, wie teuer und aufwändig ein Schädlingsbefall langfristig werden kann (Produktionsausfall, Schadenersatz, Haftung etc.). Aber gut, das entscheidet der TO selbst. :wink2: Einen Ansatz findest Du in dem oben verlinkten Artikel - die Account Lockout Tools. Ansonsten kann man es mit dem Process Tracking versuchen, aber ich denke, das solltest Du für den Moment lassen; das ist nicht ganz so einfach und vielleicht gar nicht notwendig. Prüfe auch einmal alle Dienste, ob einer oder einige davon unter dem Administrator Account laufen - ggf. ist hier nach dem Kennwortwechsel also auch Handarbeit angesagt. Viele Grüße olc

Hi, welche "GPOs" bzw. welche Aktionen ausgeführt werden, hängt von der Anordnung der GPOs innerhalb Deiner Strukur ab und kommt ggf. auf die Client Side Extension an, die Einstellungen verarbeiten soll. Generell ist natürlich Anzahl der wirksamen GPOs, Anzahl der GPOs die gelesen werden, Einstellungen innerhalb der GPOs, Startup Scripts, Filterungen etc. relevant. Es kann also viele Ursachen haben. Am besten Du schaust grundsätzlich erst einmal mit einem GPMC "Group Policy Results" HTML Report, welche Einstellungen für den Computer per GPO gesetzt wurden. Vielleicht siehst Du hier schon mögliche Problemquellen. Falls nicht, kannst Du testweise einmal das UserEnv Debug Logging aktivieren und schauen, ob Du irgendwelche Zeiträume siehst, zu denen nichts passiert. Das, was um diesen Zeitpunkt herum (besonders vorher) passiert, gibt Dir dann einen Ansatz: How to enable user environment debug logging in retail builds of Windows . Ansonsten könntest Du überprüfen, ob Du Fehlermeldungen in den Event Logs findest, ob Du die korrekten DNS Einträge auf den Clients gesetzt hast etc. Viele Grüße olc

Guten Abend, es macht sich in solchen Fällen immer ganz gut, wenn man einen neuen Thread zu dem neuen Problem öffnet - im Grunde hat das ja nun wenig mit der Ausgangslage bzw. dem ursprünglichen Problem zu tun. ;) Das, was Du geschrieben hast, ist grundsätzlich möglich. Die Clients suchen sich bei eingeschaltetem Site-Costing und aktiviertem "Bridge all site links" standardmäßig einen Server am eigenen Standort. Nutzt Du also DFSN-Ziele für die Profile, ist das so machbar. Distributed File System: Frequently Asked Questions Gerade in Bezug auf DFSR lauern da aber einige Fallstricke - so mußt Du sicherstellen, daß die Replikation der Benutzerdaten definitiv zum anderen Standort repliziert wurde, wenn der Benutzer "wandert". Sonst bekommst Du schlimmstenfalls massive Probleme mit den Profilen aufgrund der inkonsistenten Daten (bezieht sich auf Romaing Profiles). Hast Du dann noch Ordnerumleitungen aktiv (etwa für Eigene Dateien etc.), dann läufst Du auch in starke "Sharing Violations", also dem Versuch von DFSR Dateien zu replizieren, die exklusiv für den Zugriff der Applikation geblockt sind (z.B. Access oder Excel Dateien). Das muß kein Problem darstellen, denn DFSR versucht es später wieder - kann aber zum Problem werden, wenn es sich um sehr viele Dateien mit den Zugriffsverletzungen handelt und setzt ggf. die Replikationsperformance herunter. Auch hier wäre zu beachten, daß die Benutzer immer Ordnungsgemäß Ihre Client-Systeme herunterfahren, um nicht dauerhafte Locks auf Dateien zu haben, die dann wiederum nicht repliziert werden können. Bei guter Planung kann das jedoch gut funktionieren. Lies Dir den Thread einmal komplett durch - dann siehst Du, daß das nicht das Problem war. Die Initialreplikation benötigt natürlich einiges an Staging Speicher, von daher wurde der Fehler geloggt. Die Initialreplikation wurde jedoch laut Logs auch abgeschlossen, weshalb das Problem (falls es denn eins gibt) an anderer Stelle zu suchen ist. ;) Aber grundsätzlich hast Du natürlich vollkommen Recht - die Staging-Quotas sind ein kritischer Punkt einer DFSR Infrastruktur. Viele Grüße olc

Jau, da hast Du Recht. Habe beim Schreiben nicht darüber nachgedacht, daß die Script CSE ja ersetzend und nicht ergänzend ist. Aber gut, dann müßte man die Flags und gPLink Attribute etc. pp. ebenfalls mit einbeziehen, um ggf. keine falschen GPOs mit auszugeben. Na ja - wenn die Scripts auf dem Benutzerprofil "verankert" sind, ist es das geringste Problem die Daten herauszubekommen. Falls nicht, können wir hier ja noch einmal ansetzen. ;) Viele Grüße olc

Hi, sollte das Script tatsächlich in den Benutzereigenschaften eingetragen sein, kannst Du neben dem genannten José beispielsweise auch "dsquery / dsget" nutzen. In etwa so: dsquery user | dsget user -samid -loscr Wenn Du die Scripts per GPO einsetzt, wird es wahrscheinlich schwierig(er) es zentral für jeden einzelnen Benutzer zu dokumentieren. Man könnte (neben der GPMC) Anmeldescripts hinterlegen, die ein "gpresult" wegsichern - dort solltest Du sehen können, welche Scripts in den entsprechenden GPOs hinterlegt sind. [EDIT] Da war Daim wohl schneller... :) [/EDIT] Viele Grüße olc

Hi, Kann ich verstehen. :D Also standardmäßig sind nur "*.bak", "~*" und "*.tmp" Dateien geblockt, siehe Windows Server How-To Guides: Teil 5 - Zugelassene Dateitypen - ServerHowTo.de . Fotos sollten also durchgehen. Wie gesagt, schau erst einmal, welche Daten denn genau nicht angekommen sind und wo diese liegen. Ggf. Health Report prüfen. Welches Service Pack ist auf dem Windows Server 2003 installiert und welche DFSR Hotfixes hast Du ausgerollt? Ok, also wahrscheinlich mit nun zusätzlichen 5GB Staging Daten gefüllt. Viele Grüße olc

Hi, welche Sperrliste verwendet wird, bestimmt im Grunde das Zertifikat selbst. D.h. öffne einmal das Zertifikat per Doppelklick (oder dumpe es per certutil auf der Kommandozeile) und schaue, welche CRL / Sperrliste geprüft wird. Du kannst es auch direkt mit "certutil -verify -urlfetch ZERTIFIKAT.cer" überprüfen - dann bekommst Du angezeigt, ob die notwendigen Verteilungspunkte erreichbar sind. Viele Grüße olc

Hi, hast Du Dir schon einmal den PerfMon angeschaut? Windows Server 2003 Performance Counters Reference: Core Services Ohne es konkret getestet zu haben würde ich vermuten, daß Du damit Dein Ziel erreichst. Viele Grüße olc

Hi, hast Du unter Umständen vor einiger Zeit (zu Beginn des Fehlers) einmal das Kennwort des Administrators geändert? Sind eventuell Dienste oder Programme installiert worden? Ist im Credential Manager vielleicht ein falsches Kennwort für den Administrator hinterlegt? Sollte das nicht der Fall sein, könnte es im schlimmsten Fall ein kürzlich ausgebrochener Wurm sein, siehe Aktives Verzeichnis Blog : Diverse Benutzerkonten haben plötzlich einen Account Lockout Prüfe das doch einmal zur Sicherheit gegen. Ist wie gesagt nur der Extremfall - es gibt eine ganze Menge anderer möglicher Gründe für eine solche Meldung. Sind vielleicht Fehlermeldungen in den Eventlogs (Application / SYSTEM) zu finden? Viele Grüße olc

Hi, hast Du es einmal mit "Invoke" anstatt "InvokeSet" versucht? Viele Grüße olc

N'Abend, was Du schreibst (von den Events her) sieht soweit ja erst einmal gut aus bzw. nicht grundsätzlich "schlecht". :) Was für Daten liegen denn in dem zu replizierenden Ordnern? Sind vielleicht Dateitypen geblockt? Wie setzen sich die Dateien / Ordner zusammen? Vielleicht kannst Du einmal prüfen, welche Daten denn nicht repliziert wurden. Wie "errechnest" Du die 6GB Daten? Rechtsklick auf den Ordner und Eigenschaften? Das ist ggf. nicht sonderlich zuverlässig, da in dem Ordner standardmäßig ja auch die Staging / ConflictedAndDeleted Daten liegen. Grundsätzlich kannst Du über das Deaktivieren und erneutes Aktivieren des "Slave"-Servers ein neues initial sync einleiten. Dabei werden die Daten des "Slaves" dann nicht autorativ erneut repliziert. Sollten auf dem "Slave" in der Zwischenzeit Änderungen stattgefunden haben, werden diese abber ggf. gelöscht / in den ConflictedAndDeleted / PreExisting Ordner verschoben. Die Frage ist, ob das Ergebnis das gewünschte sein wird. Ggf. ist es das selbe wie im Moment, wenn Du ein eventuell vorhandenes Problem nicht behebst. ;) Was sagen denn die Health Reports für die Replikationsgruppe? Viele Grüße olc

Hi IxxZett, wie genau ist denn Dein CA und Client Setup und wie bist Du zum Beantragen vorgegangen? Vielleicht als ersten Ansatz: Windows Server How-To Guides: Teil 2 – Anfordern und Installieren der Zertifikate - ServerHowTo.de . Viele Grüße olc

Hi Andreas, DFSR ist auch nicht für "Hochverfügbarkeitsnetze" konzipiert, dafür gibt es beispielsweise Cluster. Die Zielgruppe ist schlichtweg eine andere. Viele Grüße olc

Hi, grundsätzlich hättest Du die alte CA mittels Backup bestenfalls wiederhergestellt, siehe How to move a certification authority to another server . Aber wenn das nicht mehr möglich ist, kannst Du die entsprechenden Punkte aus dem folgenden KB-Artikel befolgen: How to decommission a Windows enterprise certification authority and how to remove all related objects from Windows Server 2003 and from Windows 2000 Server . Bei Fragen einfach melden. :) Viele Grüße olc

Nein, nicht logoutTime, sondern Lockout-Time Attribute (Windows) . ;) Gern geschehen. :) Viele Grüße olc