olc

Hi Leute, sehe es ähnlich wie einige der Kollegen hier: Es sollte in regelmäßigen Intervallen geprüft werden, ob neue Firmware / Treiber vorhanden sind. Die Intervalle müssen ja keine Wochen sein, es sollte sich jedoch auch nicht um Jahre handeln. Oftmals verursachen die Updates nämlich keine Fehler, sondern schützen vor welchen. ;) Gerade die oben angesprochene RAID / HDD und NIC Firmware ist ein heißer Kandidat für Probleme (man siehe nur das MS SNP "Disaster", welches in den meisten Fällen mit aktuellen Treibern gar nicht zum Problem geworden wäre oder so einiges an Datenverlusten, weil der RAID Controller in bestimmten Situationen "schlecht" reagiert). Ist man sich unsicher, sollte man auf einem System vorher testen und dann Step-by-Step ausrollen. Ich habe damit auch noch nie schlechte Erfahrungen gemacht, eher im Gegenteil. Meine Meinung. :) Viele Grüße olc

Hallo, an der Stelle nochmal nachgefragt, ob Du den oben von mir verlinkten Artikel durchgegangen bist? Darin geht es genau um den SYSTEM-Kontext. Gruß olc

Hi, ich hatte an dieser Stelle auch einmal auf die Systemzeit getippt wie twiki, prüf das doch einmal. Die Kennwörter der Benutzer sind jedoch definitiv korrekt, ja? Ansonsten kannst Du ggf. noch einmal prüfen, ob die DCs replikationstechnisch korrekt laufen, also z.B. mittels "repadmin /showrepl" oder "repadmin /replsum" gegenprüfen. Starte einmal den KDC Dienst auf beiden DCs neu und prüfe, ob immer noch einer der beiden DCs die falschen Logons bemängelt. Viele Grüße olc

Hallo Claudia, kann es sein, daß die Clients über ein Image aufgesetzt wurden, ohne daß per SYSPREP die SIDs nach der Installation geändert wurden? Falls dem so ist, solltest Du SYSPREP ausführen. Die Version sollte auch bei XP funktionieren. NewSID wäre auch eine Möglichkeit, jedoch ist diese nicht von MS supportet. Also lieber SYSPREP verwenden. Viele Grüße olc

Hallo, was ist gemeint mit ? Heißt das, daß es sich um die gleiche Zertifikatstruktur, um die gleiche Domäne oder den gleichen Forest handelt oder ist es ein komplett verschiedenes Szenario? Kannst Du den Event-Text zur Event ID 5 einmal hier posten? Wo bekommst Du den Event? Viele Grüße olc

Hi, soweit ich weiß, ist das mit Windows-eigenen Mitteln nicht zu gewährleisten. Vielleicht helfen hier Drittprodukte wie SpecOps o.ä.? Viele Grüße olc

Hi, hast die Lösung ja nun schon gefunden -wir hatten das Thema hier schon einmal :) : https://www.mcseboard.de/windows-forum-scripting-71/ldifde-binaerwerte-131969.html Viele Grüße olc

Hi Mullfreak, schau Dir doch einmal NcFTP (explizit NcFTPPut) an: NcFTP Client Viele Grüße olc

Hi Uwe, ich glaube eher nicht, daß das Neuanlegen der DNS Zone etwas hilft. Das Problem ist, daß sich der Fehler schwer eingrenzen läßt, solange in der Umgebung scheinbar mehrere Dinge nicht in Ordnung sind - oder auch nur ein Fehler zu mehreren Problemen führt. Schau doch bitte noch einmal in den folgenden KB-Artikel, vielleicht hilft hier noch etwas: How to troubleshoot connectivity issues that are caused by RPC client protocol registry entries Ansonsten fällt mir momentan nichts mehr ein, was sich per Ferndiagnose lösen ließe, sorry. Viele Grüße olc

Hi KHG, da wäre XP-Fan dann nicht der einzige, denn Deine Problembeschreibung verdient den Namen "Problembeschreibung" nicht. :suspect: Wenn Du einen Root-Server einsetzt, wirst Du wahrscheinlich zur Verwaltung ein Management-Programm einsetzen, also Plesk o.ä. Ist das der Fall? Welche Konsole meinst Du mit der Verwaltung? Ein Remote Desktop (RDP) Fenster oder hast Du direkt eine Software zur Verwaltung der Maschine? Usw. usf. Versuch doch bitte einmal Dein Problem etwas verständlicher zu beschreiben, denn hier sind alle gern gewillt zu helfen, wenn man denn das Problem anhand der Beschreibung versteht. Viele Grüße olc

Hi Uwe, Also ich habe das Gefühl, daß da noch mehr nicht hinhaut. Auch hier wird nach dem "doppelten westfaliaworms" gefragt. Was ist denn mit der Umgebung passiert, bevor der Fehler erstmalig auftrat? Wurde irgendetwas umgestellt? Gruß olc

Optimal. :) Beste Voraussetzung, das Thema z.B. als Abschlußprojekt inkl. Evaluierung, Budgetplanung und Rollout zu behandeln. ;) Falls es Dich doch einmal packt und Du die Mittel für den R2 (oder später Windows Server 2008) zur Verfügung hast: Windows Server How-To Guides: Planung, Installation und Konfiguration des Distributed File System (DFS) unter Windows Server 2003 R2 - ServerHowTo.de Windows Server How-To Guides: Weiterführende DFS-R Konfiguration unter Windows Server 2003 R2 - ServerHowTo.de Viele Grüße olc

Hallo, schau doch einmal in die folgenden beiden Artikel, unter Umständen bringt es Dich weiter? Kerberos authentication is unsuccessful in the Local System security context when the computer account password has recently changed on a computer that is running Windows Server 2003 Active Directory Blog : Unusual Kerberos Failure...User to User to What? Gruß olc

Hi Uwe, ich möchte nicht kleinlich sein - es ist also wirklich nicht böse gemeint, wenn ich noch einmal frage; Aber Du hast einige meiner Fragen noch nicht konkret beantwortet, sondern nur allgemein gesprochen. Nur um sicher zu sein also nochmal die fehlenden Fragen (oder habe ich die Antworten überlesen?): a) Heißt "alles aus dem Artikel gemacht", daß alle im Artikel genannten Dienste korrekt laufen? b) Hast Du die Registry Keys aus dem Artikel geprüft bzw. ggf. die genannten Werte gesetzt? c) Ist folgender Hotfix installiert (ist optional, daher nicht im Windows Update standardmäßig dabei): An update to turn off default SNP features is available for Windows Server 2003-based and Small Business Server 2003-based computers ? d) Was sagen die Ereignisprotokolle (SYSTEM und Application Eventlog)? Neben den anderen Fehlern im DCDIAG Log finde ich folgendes auch ein wenig problematisch - aber das kann natürlich auch theoretisch durch den fehlenden RPC Zugriff kommen: Die NetDiag und DcDiag Exporte hast Du auf dem SBS selbst gezogen? Merkwürdig ist auch folgende Ausgabe: Wieso taucht dort 2x "westfaliaworms" auf? Die Domäne heißt "westfaliamoebel.de" und der Hostname "westfaliaworms" - 1x "westfaliaworms" zu viel. Hast Du das primäre DNS Suffix des Servers manuell verändert? Sollte die DNS Auflösung nciht korrekt klappen ist zumindest nachvollziehbar, warum DcDiag da meckert --> es sucht schlichtweg an der entsprechenden Stelle nach dem falschen Host. P.S.: Ist natürlich auch nicht unbedigt optimal bezüglich des Datenschutzes, die ganzen nutzerbezogenen Daten zu posten. ;) "Einfach" neu aufbauen geht eher nicht - ich denke auch nicht, daß das Sinn machen würde, da der Fehler ja scheinbar beim RPC-Zugriff zu suchen ist, also entweder mit RPC selbst etwas nicht stimmt oder die Netzwerkverbindung / der RPC-"Stack" Probleme macht. Viele Grüße olc

Hi blub, Ich denke da wird noch eine Menge passieren - Programmier- oder Scriptsprachen bzw. ganze Shells wie im Falle der PS setzen sich nicht von heute auf morgen durch. Schließlich gibt es in den Unternehmen eine Menge Bestandsscripts und einiges an Wissen, was die Admins nicht einfach "wegwerfen" können oder wollen. Längerfristig wird man nicht an der PS vorbeikommen - aber sicherlich wird es weiterhin auch andere Scriptsprachen geben. Mit zunehmenden CMDlets werden jedoch einige Admins umsteigen. Vor allen Dingen das Konzept hinter der PowerShell (alles ist ein Objekt, die CMDlets etc.) ist bisher (soweit ich weiß) einmalig und wird dafür sorgen, daß sie sich durchsetzt. Früher oder später. ;) Viele Grüße olc

Hallo Ju1ch3n, Nochmal nachgefragt: Wenn der Namespace domänenbasiert ist greifst Du also über \\domain.tld\namespace oder aber über \\domain.tld\namespace\targetshare zu. Beides sollte funktionieren. Nur der lokale Zugriff im Filesystem des Servers sollte nicht funktionieren, wenn Du direkt in den Namespace Ordner wechseln möchtest. Direkt auf den Server und das Share zuzugreifen funktioniert natürlich auch, nimmt Dir aber natürlich die Vorteile von DFS-N. :) Vor dem R2 wird FRS für die Replikation genutzt. Du hast vollkommen Recht, dies kannst Du über die MMC nicht einsehen / überwachen. Du kannst auf der Kommandozeile z.B. FRSDIAG, nutzen, um die FRS Replikation zu überwachen, siehe Download details: File Replication Service Diagnostics Tool (FRSDiag.exe) . Ansonsten fallen mir noch SONAR bzw. Ultrasound ein, siehe Download details: Sonar.exe: File Replication Service (FRS) Status Viewer und Download details: Ultrasound - Monitoring and Troubleshooting Tool for File Replication Service (FRS) . Aber ganz ehrlich: FRS ist oftmals wirklich ein "Nervtöter", also schau Dir das Thema gut an, bevor es Probleme im Laufbetrieb gibt. Oder aber investiert das Geld in Updates auf Windows Server 2003 R2 (oder ggf. gleich auf Windows Server 2008). DFS-R läuft meiner Meinung nach bei weitem stabiler und vor allen Dingen streßfreier. Ist natürlich eine Frage des Geldes. Viele Grüße olc

Hi, daß der Server R2 ist, sagt nichts aus. Standard bei R2 Auslieferung ist SP1. Aber Dein "Nachsatz" im letzten Post, daß alle Hotfixes installiert sind, schafft Klarheit. :) Ein "Downgrade" brauchst Du nicht angehen, in einer neueren Dateiversion sind alte Fixes mit dabei. Zumindest meist, es gab da wohl auch schon Ausnahmen. :D Die im KB-Artikel genannten Dienste laufen definitiv auch alle, ja? Die Registry Keys hast Du geprüft? Netzwerkkartentreiber sind aktuell und die Firmware ggf. ebenso? Ist folgender Hotfix installiert (ist optional): An update to turn off default SNP features is available for Windows Server 2003-based and Small Business Server 2003-based computers ? Im Moment fällt mir ansonsten auch nicht mehr sooo viel ein. Was sagen die Ereignisprotokolle? Sind relevante Fehler zu finden (insbesondere SYSTEM und Applicationslog)? Viele Grüße olc

Hi Uwe, soweit ich sehen konnte, bist Du auf die letzten Lösungsvorschläge der Kollegen nicht weiter eingegangen und hast hier neu gepostet. Daher mein Hinweis. Aber wie gesagt, herzlich willkommen - wir helfen trotzdem gern, wenn wir es können. ;) Ich habe das Problem bei einer kurzen Web-Suche oft im Zusammenhang mit ISA gefunden, vielleicht kannst Du hier ja einmal ansetzen. Welches Service Pack setzt Du auf dem SBS ein? Folgender Hotfix adressiert ein Problem Deiner Art - solltest Du SP2 nicht einsetzen, kannst Du einmal versuchen, den Hotfix zu installieren: FIX: A 0x6be exception may occur when you quickly make multiple remote procedure calls to a server that is running Windows Server 2003 Solltest Du gleich auf SP2 gehen wollen denk bitte daran, vorher ein valides Backup zu ziehen und das SP2 für den SBS zu verwenden, soweit ich weiß unterscheidet es sich vom normalen Windows Server 2003 Service Pack. Viele Grüße olc

Hallo Sabine, was heißt, Du konntest im UserEnv Log nichts auffälliges erkennen? Wenn es eine Verzögerung beim Anmeldeprozess gibt, dann siehst Du diese auch. ;) Oder tritt die Verzögerung erst nach dem Laden des Desktops auf? Ggf. kannst Du ja einmal die UserEnv.log ab der Benutzeranmeldung posten (als "Code"). Viele Grüße olc

Ok, freut mich zu hören. Dennoch solltest Du das noch einmal (vielleicht später in einem Wartungsfenster) wie oben beschrieben testen. Einen Grund für das Problem muß es ja geben - nicht, daß Du später einmal in ein Folgeproblem läufst, wenn Du an dieses Problem hier gar nicht mehr denkst bzw. keine Verbindung dazu herstellt. ;) Schönen Abend noch. Gruß olc

Hi Asgard, ich habe das gerade bei mir noch einmal nachvollzogen: Rechtsklick Arbeitsplatz --> "Eigenschaften" --> Reiter "Erweitert" --> Schalter "Umgebungsvariablen" --> im unteren Bereich "Systemvariablen" wird %SystemRoot% angegeben, in der CMD wird dies allerdings korrekt umgesetzt, also mit C:\WINDOWS angezeigt. Ist zwar auf einem Vista System getestet, aber ich denke es sollte unter XP / 2003 das gleiche sein. Setze doch bitte einmal im oben genannten Dialog die "Path" Variable für "%SYSTEMROOT%\system32" auf "C:\WINDOWS\system32", boote den Rechner danach neu und versuche es wieder mit "net.exe". Wenn das funktioniert hat, mach es wieder rückgängig, also setze in der GUI die Path-Variable auf %Systemroot%\system32, starte den Rechner neu und teste erneut. Vielleicht gab es ein Problem beim Absturz des Systems bzw. beim Eintragen neuer Pfade durch Deine Software, die das nun verursacht. Unter Umständen macht das temporäre Ersetzen das ganze wieder "heile". ;) Viele Grüße olc

Hi Asgard, kein Thema, war nur verwundert. Hast Du den Path manuell angepaßt und "%SystemRoot%" eingefügt oder ist das so bei Dir in der Ausgabe angegeben? Ich bin mir ehrlich gesagt nicht sicher, ob das an dieser Stelle korrekt aufgelöst wird. Teste doch einmal in einer CMD folgendes: Das "Set" gilt nur in dieser CMD, Du kannst diese ohne Bedenken danach wieder schließen. Läuft "net.exe" dann korrekt auch bei einem Aufruf von C:\ aus? Gruß olc

Hallo und willkommen, bist Du für die Einrichtung nach einer bestimmten Anleitung vorgegangen? Falls ja, poste doch einmal den Link dazu. Falls nicht: In Dein DFS-N Stamm domänenbasiert oder ein Stand-Alone Namespace? Wie hast Du die Berechtigungen auf den Stamm vergeben? Wenn Du versuchst direkt auf den Ordner zuzugreifen, der den Namespace darstellt, ist das normal. Dort kommst Du standardmäßig nicht hinein, sondern lediglich auf die Freigaben. Du mußt also entweder über den DFS-N Stamm zugreifen oder direkt in die Shares wechseln. Wenn Du von einem Client (oder einem der DCs) direkt über den Pfad "\\<Servername>\<DFS-Stamm>\<Ziel>" zugreifst, kommst Du dann auf die Freigaben? Was sagt ein "dfsutil /pktinfo" nach dem fehlgeschlagenen Zugriffsversuch? Viele Grüße olc

Hallo, kann es sein, daß die "PATH" Variablen durch den Absturz aus irgend einem Grund verändert / gelöscht wurden? Gib auf der Kommandozeile einmal "SET" ein und poste die Ausgabe hier bzw. prüfe, ob unter "Path=" auch "C:\WINDOWS\system32" aufgeführt ist. EDIT: Öhm , gerade eben stand in Deinem Post noch etwas anderes... Na ja, dann hat sich meine Antwort damit wohl erledigt. :suspect: Viele Grüße olc

Hallo, anbei noch ein zusätzlicher Link zu einigen RODC Aspekten, der erst vor kurzer Zeit veröffentlicht wurde und damit ein wenig aktueller ist als der ganz oben genannte ;): Microsoft Corporation Viele Grüße olc