olc

Hi Annette, schön, daß es geklappt hat. :) Kam zwar spät, aber es war da. :D Läßt sich pauschal nicht sagen, macht in den meisten Fällen aber Sinn. :) Viele Grüße olc

Hi, Treffer 1 der Suchmaschine Deiner Wahl ;) : How To Delegate the Unlock Account Right Hier gibt es auch noch Informationen: Yusufs Directory Blog - Objektdelegierungen einrichten Über GPOs ist das nicht möglich. Viele Grüße olc

Der Zielclient war definitiv an und der Name / die IP korrekt? Firewall mit entsprechenden Ausnahmen konfiguriert? Die Fehlermeldung erscheint mir "merkwürdig" bei den letzten Fehlern. Kannst Du andere Clients / einen Testclient problemlos der Domäne joinen? Viele Grüße olc

Hi, kannst Du von dem Notebook aus auf andere Clients zugreifen (also explizit nicht den SBS)? Etwa NET USE X: \\clientname\c$ /USER: DOMAIN\Administrator ? Viele Grüße olc

Hi, das ging ja schnell. ;) Also soweit wie ich das jetzt auf die schnelle überblicke, sehen die Einstellungen soweit gut aus. Versuche es einmal mit Carstens Tipp: https://www.mcseboard.de/windows-forum-ms-backoffice-31/pc-winxp-geht-domaene-dienstidentifizierung-srv-146026.html#post898088 [EDIT] Ok, hast es nachgetragen. Geht nicht... [/EDIT] Mh, sind normale Zugriffe des Clients auf ein Share des SBS möglich (ggf. mußt Du die Benutzerdaten übergeben, wenn Du Dich verbinden willst, da der Client derzeit nicht Domänenmember ist)? Ja, nutze den [ CODE ] (ohne Leerzeichen) Parameter - kannst ihn auch anklicken im Rich Editor oben (das Nummernzeichen #). ;) Viele Grüße olc

Hi, ergänzend zu Carstens Fragen: Was sagt der XP-Client, wenn Du ein nslookup auf die Domäne FRANSRV.LOKAL absetzt, was sagt der DC bei gleichem Kommando? Bitte poste doch einmal diese Ausgabe und ein IPCONFIG /ALL vom Client als auch vom SBS. Bitte poste zusätzlich auch einmal die Einträge des DNS-Knotens "_ldap._tcp.dc._msdcs.FRANSRV.LOKAL". Ggf. gleich noch den Inhalt der Datei C:\WINDOWS\system32\config\netlogon.dns, wenn Du das datenschutztechnisch vertreten kannst. ;) Zusätzlich wäre ein "DCDIAG /V" (auf dem SBS ausgeführt) interessant, scheinbar laufen auf dem DC irgendwelche Dienste nicht: Viele Grüße olc

Hi, kann es vielleicht sein, daß für die Verschlüsselung ein schon vorhandenes Zertifikat verwendet wurde und nicht das neu beantragte? Oder bist Du ggf. als Recovery Agent angemeldet und das entsprechende Zertifikat inkl. privater Schlüssel liegt ebenfalls im Benutzerspeicher? Liegen die Daten lokal oder auf einem Netzlaufwerk? Sind die daten wirklich verschlüsselt? Vergleiche doch einmal die Dateiinformationen in Bezug auf den verschlüsselnden Benutzer und Data Recovery Agent z.B. mittels EFSDump und den Zertifikaten, die im Benutzerspeicher liegen. Viele Grüße olc

Hi, [EDIT] KB gefunden: How to restore the system/boot drive letter in Windows [/EDIT] Viele Grüße olc

Hi Larsson, paßt zwar nicht 100% auf Dein Problem, aber nutze trotzdem einmal die Anleitung zur Neuregistrierung der scm.mof: A Service Control Manager (SCM) event cannot be logged in the System event log on a Windows Server 2003-based computer Alternativ zu AT kannst Du auch "PsExec.exe \\computername -s cmd" nutzen, um in den Systemkontext zu kommen. Werden vielleicht irgendwelche anderen relevanten Events geloggt, die auf einen Fehler hinweisen? Viele Grüße olc

Hi, also wenn Du die folgende Fehlermeldung bekommen hast: dann war auf dem System mit hoher Wahrscheinlichkeit noch kein Vista SP1 installiert. Du schreibst, daß Du das SP1 für Vista noch einmal heruntergeladen und installiert hast. Danach hast Du den PC neu gestartet, die Vista SP1 RSAT Tools neu installiert und dann den folgenden Fehler bekommen: D.h. die Verwaltungstools werden nicht einmal installiert, ist das korrekt? Viele Grüße olc

Hi, wenn mich nicht alles täuscht mußt Du vor einem Reparaturkonsolen-FIXMBR in in dieser beschriebenen Konstellation zuerst die andere Platte als "aktiv" markieren, z.B. mit FDISK. Aber das habe ich zuletzt wahrscheinlich unter DOS (oder mal unter Linux) gemacht, also vielleicht ist das auch nicht mehr nötig. :D Viele Grüße olc

Hi, vielleicht einmal ein Schuß ins Blaue: Bevor Du jetzt an irgend einer Stelle weitermachst, würde ich empfehlen, testweise IPv6 einmal auf allen beteiligten Windows Server 2008 Systemen zu deaktivieren (für den Moment reicht es, einfach den Haken in den TCP/IP Einstellungen wegzunehmen), solltest Du IPv6 nicht einsetzen. Danach schau einmal auf den DNS Servern, ob IPv6 Adressen registriert sind. Wenn dort welche vorhanden sind und Du Dir sicher bist, daß Du IPv6 in Deinem Netz nicht nutzt, dann lösche diese und starte den NETLOGON Dienst auf den DCs einmal neu. Danach prüfe einmal, ob sich das Fehlerbild bzw. insbesondere die o.g. Fehlermeldungen in irgend einer Weise von den alten unterscheiden. Zu diesem zeitpunkt sollte natürlich sichergestellt sein, daß die IPv4 Adressen korrekt und ggf. richtig in den TCP/IP IPv4 Einstellungen als DNS Server etc. auf den Systemen vergeben sind. ;) Viele Grüße olc

Hi, der Vollständigkeit halber noch die Ergänzung, daß man nicht pauschal sagen kann "geht nicht". Wenn der DNS Name der neuen CA gleich der alten ist, funktioniert eine "Migration". Ansonsten müßte man mit CNAMEs die Struktur "hinfrickeln". Ob das empfehlenswert ist sei dahingestellt. Befinden sich die neue und die alte Domäne im selben Forest und die CA ist eine Enterprise CA, muß man im Grunde gar nichts tun. Dann läuft alles wie bisher, solange die Ursprungsdomäne nicht abgeschaltet wird. Da wir beide Punkte oben nicht weiter in Bezug auf die Ausgangssituation klären konnten dient dies nur als Hinweis. Zusätzlich ließen sich die alten Zertifikate als solches auch noch in eine neue Struktur mit übernehmen, nur wäre dann keine einzelne Revokation oder ähnliches möglich, so daß man davon im Grunde nur abraten kann. In diesem Fall kann man sich die CA auch sparen. Viele Grüße olc

Hi Pastors, schau Dir einmal ShellRunas an. Das sollte eine Lösung für Dich sein. Viele Grüße olc

Hi Norbert, ja - Du hast Recht. Da war doch was... :) Hatte ich nicht mehr auf dem Schirm, danke für den Hinweis. Viele Grüße olc

Hi, ergänzend sei vielleicht noch das Shared Computer Toolkit von MS genannt. Das deckt genau solche Anwendungsbereiche ab. Ich meine, daß es in den Links oben nicht weiterführend genannt wird. Shared Computer Toolkit für Windows XP Viele Grüße olc

Hi, wenn ich Deine Angaben richtig interpretiere, gibt es mehr als einen DC in der Umgebung, korrekt? Im Ereignisprotokoll sollten einige Fehlermeldungen zu finden sein, unter anderem sieht man schon in Deinem DCDIAG die beiden folgenden: 0xC0002715 = NELOG_NetlogonFailedToCreateShare Ok, das ist ja ganz offensichtlich der Fall, aber 0xC0002715 = EVENT_RPCSS_START_SERVICE_FAILURE sieht doch interessant aus. Ich würde einmal versuchen, den Remote Procedure Call Dienst zu starten bzw. die Ursache für die Probleme des Dienstes herauszufinden. Gibt es weitere Fehler im System oder Application Event Log? Viele Grüße olc

Hi, Du sollst es ja nicht als Alternative verstehen, sondern nur testen. ;) Damit kannst Du eingrenzen, ob es sich um ein generelles Problem handelt (zwischen Deinem XP Client und dem 2008er Server + Offline Files) oder um ein DFS-relevantes. Viele Grüße olc

Hi, schau einmal, ob der "RPCSS" Dienst gestartet ist (Remoteprozeduraufruf). Unter Umständen liegt hier ein Problem. Viele Grüße olc

Hi Nils, Gut - jetzt können wir noch Stunden so weiter machen ;) : Aber gerade in der Konstellation wird es zu Änderungen am Configuration-NC kommen. Denn hier sind auch unter anderem die Connection Objects enthalten - wurden in der Zwischenzeit mehrfach DCs aus und eingeschaltet, kann sich die Topologie oft ändern. Dann ein mehrmaliges Wechseln des Root-DCs, schon läufst Du in den Rollback. Für die Trusts als auch Kerberos Tickets müssen gemeinsame "geheime" Informationen zur Verfügung stehen, um die Nounces o.ä. zu verschlüsseln und zu validieren. Und genau die müssen auch ausgetauscht werden. Klar - nun kann man sich darüber "streiten", ob das nun genau in der kurzen Zeit passiert sein könnte. Ich gebe Dir diesbezüglich Recht, daß man hier einen genaueren Blick auf die Umgebung und ggf. Fehlermeldungen werfen müßte. Aber genau das bestätigt mich in meiner Empfehlung, das hier nicht im Board zu klären. Genau das ist der Punkt - das ist passiert, lies Dir noch einmal die Beschreibung oben durch. Also noch ein Punkt mehr lieber jemanden mit Tiefenkenntnis daran zu setzen. Aber Nils, laß uns an dieser Stelle mit der "Auseinandersetzung" der vielen "wenns und abers" Schluß machen. Ich weiß worüber ich spreche, Du weißt es auch. Der TO soll einfach selbst entscheiden, ob er die nötige Sachkenntnis mitbringt. Viele Grüße olc

Hi Nils, wie Du schon sagst - minimum der Configuration NC läuft sicherlich in einen USN Rollback (Schema wird ja hoffentlich in der Zwischenzeit nicht verändert worden sein). Weiterhin kannst Du Probleme mit den Computerkonten / Kennwörtern der DCs bekommen, damit NTLM und Kerberos Probleme etc. pp. - die Liste geht noch weiter. Man kann daran herumfrickeln, man kann schauen, ob man es irgendwie mit Backups hingebogen bekommt, z.B. mittels autorativer Wiederherstellung des Config NC und des Domänen NCs (oder schlimmstenfalls mittels eines kompletten Forest Recovery), man kann eine Domänenmigration durchführen (solange die Root- und Child-Domäne noch betriebsfähig ist) usw. - das ist nicht der Punkt. Wenn aber der TO (und das meine ich jetzt nicht böse) vom "Hochschrauben der USNs" spricht, dann sollte dort vielleicht erst einmal jemand drüber schauen, der die Abhängigkeiten kennt und die zugrunde liegende Technik in der Tiefe versteht. Weiterhin wurden scheinbar einige Aktionen durchgeführt, die nicht wirklich gut geplant waren. Und genau daher die Empfehlung oben von mir (und grizzly999) das hier nicht in einem Forum zu klären. Es handelt sich zwar scheinbar nicht um eine größere Umgebung - aber auch keine sehr kleine... Fällt etwas aus, weil wieder ein falscher Knopf gedrückt wurde, werden die Probleme nur noch größer. Meines Erachtens habe ich auch nicht von inkonsistent gesprochen, sondern von undefiniert. Das ist ein Unterschied zu "inkonsistent" - weiterhin vom Root DC, nicht den Child-DCs. Obwohl hier der Zustand auch nicht wirklich klar ist. Also ebenfalls undefiniert. Aber das entscheidet der TO dann sicher selbst und muß es notfalls auch intern verargumentieren. Von daher ziehe ich mich aus dieser Diskussion lieber einmal zurück. Viele Grüße olc

Hi, sollte ich mich so geirrt haben? Ich meine, daß das erst ab Vista / 2008 der Fall ist. Aber klar, der Service Control Manager kommt mir bekannt vor. :D Vielleicht ist der genau das Problem - ist der Service Control Manager auf dem betroffenen System gestartet bzw. wirft er Fehler? Basic Service Control Manager Operations Service Control Manager (Windows) Na ja, falls ich dermaßen daneben lag entschuldigt meinen Beitrag. Ich muß jetzt mal weg, um mich aufzuhängen. ;) Gruß olc

Hi, also ich versuche für mich das ganze hier gedanklich mal ein wenig zu sortieren, aber ich mir fällt es schwer die Aktionen nachzuvollziehen. Schauen wir mal... :D Der frühe Vogel frißt den Wurm. :D Wenn ich das ganze richtig verstehe, dann dürfte es in diesem Moment zu einem USN-Rollback gekommen sein. Der Windows 2000 DC der Root-Domain hätte also nicht mehr mit den anderen DCs replizieren dürfen (automatisch). P.S.: Einen einzigen DC (und dann noch Windows 2000) in der Root-Domain zu betreiben ist "sportlich"... :shock: Was genau meinst Du damit? Nein, der wirklich korrekte Weg wäre hier meines Erachtens ein Forest Recovery, sollten korrekte Backups vorhanden sein. ACK. Nein, ist er nicht. Er hat entweder wegen des USN-Rollbacks gar nicht mehr repliziert oder ist in einem undefinierten Zustand. Also sprich lieber nicht von "aktuell". ;) Gleiche Frage wie oben - was genau meist Du damit? Habt Ihr ein authoritative restore des DCs durchgeführt? Ja! Ja, laß die Finger davon! Abgesehen von der Idee als solches ist das technisch auch nicht möglich bzw. vorgesehen (bzw. nicht in der Art und Weise, wie Du Dir das überlegt hast; für den "Normalfall" erledigt eine autorative Wiederherstellung in den vorgegebenen Limitierungen das Ganze). <MEINE MEINUNG> Ganz ehrlich: Es ist nicht böse gemeint wenn ich sage, daß wir hier wahrscheinlich an den Grenzen eines Forums angelangt sind. Wenn Du Datenverlust und Produktionsausfall vermeiden möchtest halte jetzt lieber die Füße still, führe keine weiteren Aktionen durch und hole Dir einen kompetenten Dienstleister ins Haus. Ich mag mich irren, aber so wie das klingt, würde alles andere in einem noch größeren Problem enden... </MEINE MEINUNG> Viele Grüße olc

Hi, vielleicht erst einmal eine Gegenfrage: Was genau willst Du erreichen bzw. was ist der Hintergrund dafür? Einfach eine PKI "umziehen" ist nicht so einfach möglich. Aber vielleicht gibt es ja andere Ansätze, wenn Du Dein Anliegen bzw. den Hintergrund dafür etwas genauer erläuterst. Viele Grüße olc

Hi Larsson, wie ich finde eine interessante Frage, die Du da stellst... Soweit ich weiß, gibt es hierzu keine Möglichkeit. Aber vielleicht irre ich mich da auch und jemand anderes hat eine Idee. Im Normalfall geben die Dienste ja selbst den Trigger an das Eventlog bzw. sind programmatisch dazu angehalten, Einträge zu setzen oder eben nicht. Das überwacht nicht "das System". Ich denke Du kannst das auch nicht mittels normalem Auditing überwachen. Alternativ könntest Du jedoch vielleicht die Performance Counter so anpassen, daß Sie als Aktion einen Event kreieren, wenn ein überwachter Dienst beendet / neu gestartet wird. Jedoch wäre hierzu natürlich initial erst einmal ein Aufwand deinerseits / scripttechnisch notwendig. Alternativ bleiben natürlich alle Monitoring Lösungen (wie SCOM, Nagios etc.), die sozusagen als externe Instanz Statusveränderungen dokumentieren und melden können. Bin mal gespannt, ob noch andere Ideen kommen. Viele Grüße olc