olc

Hi, was hast Du denn gemacht, daß die Fehler nicht mehr auftauchen? Der NSLOOKUP "Fehler" ist lediglich darauf zurückzuführen, daß Du keine Reverse Lookup DNS Zone eingerichtet hast. Holst Du das nach, kann auch die IP-Adresse des 192.168.104.3 korrekt zu einem Namen umgesetzt werden. Das ist aber im Normalfall nicht kritisch, d.h. Du mußt es nicht machen, auch wenn es ab und an sinnvoll sein kann. Viele Grüße olc

Hi, das ganze kann viele Ursachen haben. Du mußt wahrscheinlich versuchen, das Problem Schritt-für-Schritt einzugrenzen. Der KDC-, RPC-, NETLOGON-Dienst etc. ist gestartet? Es würde definitiv auch keine alte VM zurück gesichert? Wie sieht es mit den Uhrzeiten auf den DCs aus - sind beide Zeiten synchron, die Zeitzone ist dieselbe? Was sagt ein NLTEST /SC_QUERY:light.jrw Kannst Du im SYSTEM Kontext des betroffenen DCs auf den anderen DC zugreifen (etwa auf das SYSVOL-Share)? Was sagt das Eventlog des anderen DCs? Es sind definitiv alle DNS Einträge für den DC vorhanden, so auch unterhalb von _kerberos._tcp.dc._msdcs.DnsDomainName? Im Eventlog des betroffenen DCs sind offenbar einige Fehlermeldungen zu finden, starte einmal mit denen. Ansonsten schau einmal hier hinein - die MaxPacketSize ist hier vielleicht wirklich relevant: Event ID 1925: Attempt to establish a replication link failed due to connectivity problem EDIT: Ist der Wert der "userAccountControl" auf beiden Computerkonten (der beiden DCs) gleich? Falls nicht poste einmal die Werte. Viele Grüße olc

:D :D :D DAS wollte ich doch mit meinem Herumgeheule nur provozieren. Man gönnt sich ja sonst nichts am Freitag Abend (außer dem "Tatort" natürlich). :D Das glaube ich nicht, Tim. :D

:D :D :D Nein, das war eher als "man" (oder "natürlich nur die Anderen") gemeint. ;) Ich merke schon - mit solch alten Geschichten kann ich hier nicht punkten. Was interessiert uns das Geschwätz (der Blog / Artikel) von gestern. :D Ich wünsche Euch trotzdem ein angenehmes Wochenende, auch wenn ich die beiden Tage nun allein in der dunklen Kammer über meine Steinzeitlinks nachdenken werde. Aber Ihr müßt Euch keine Gedanken machen - Ihr könnt natürlich nichts dafür, das habe ich mir selbst zuzuschreiben. :D

Muahaha, ja. Da hast Du natürlich Recht. Obwohl - wenn Du in der Pause mal eben mit Schema-Admin Berechtigungen an der Umgebung "herumspielst", ist schon an anderer Stelle ordentlich etwas schief gegangen. :D

Ok, zugegeben. ;) Habe ihn aber durch Zufall gerade erst gefunden und fand das Script echt Klasse. Schneller Überblick, wenn man mal eben in der Pause das Schema browsen will. :D Viele Grüße olc

Hi zusammen, das ist doch mal was nettes: Durchsuchen von Active Directory mit Windows PowerShell Nicht, daß man die Informationen nicht auch anders bekommen könnte - nur so schön aufbereitet und fertig zur Weiterverarbeitung hat man es meist nicht. :) Viele Grüße olc

Hi, grundsätzlich gibt es soweit ich weiß die Möglichkeit, die Signaturüberprüfung dauerhaft abzuschalten. Ein wenig Suchmaschinenarbeit bringt Dich hier weiter. Ohne es böse zu meinen schreibe ich das Vorgehen an dieser Stelle jedoch nicht hier hinein - denn es ist meines Erachtens der vollkommen falsche Weg, diesen Schritt zu machen. LSI ist meines Wissens keine "Krauterbude", die sollten entsprechend signierte Treiber anbieten können. Unter Umständen schaust Du bei deren Supportseite einmal vorbei oder rufst dort an, unter Umständen gibt es ja schon einen entsprechenden Treiber. Viele Grüße olc

Hi Simon-Timothy, klasse, vielen Dank für Deine Rückmeldung. :) Viele Grüße olc

Hallo und herzlich willkommen, :) seit wann existiert der Fehler bzw. wurden davor irgendwelche Aktionen durchgeführt? Wurde unter Umständen ein Image oder ein VM-Snapshot zurückgesichert? Falls der DC "LIGHTDC2V" auch ein DNS Server ist, trag diesen einmal in den TCP/IP Einstellungen von "LIGHTDC1" als primären DNS Server ein. Was sagt ein "nslookup light.jrw"? Viele Grüße olc

Hi, was genau möchtest Du erreichen? Wenn der Schedule offen ist, werden Dateien "sofort" bei Änderungen repliziert, es sei denn, es müssen vorher noch andere Dateien repliziert werden (Stichwort Backlog). Checken kannst Du den Replikationsstatus bzw. das Backlog mit "dfsrdiag backlog", zusätzlich gibt es die Health Reports. Viele Grüße olc

Hi richardsch, Du könntest den Dienst und dessen Einstellungen zum Beispiel in der Registrierung unterhalb von HKLM\SYSTEM\CurrentControlSet\SNMP\Parameters\TrapConfiguration abfragen. Dort hast Du die möglichen Parameter. Ist der Schlüssel nicht vorhanden, ist der Dienst auch nicht installiert. Die Registrierung abzufragen sollte sich auch remote recht problemlos bewerkstelligen lassen. Außerdem müßtest Du SNMP über WMI abfragen können, die Provider liegen unterhalb von root\snmp\localhost. Da WMI auch remote ansprechbar ist, ist das sicher auch kei größeres Problem. Networking Script Center - Monitoring SNMP Viele Grüße olc

Hi, daß Winlogon ein Handle offen hat, sollte nach meinem Verständnis grundsätzlich erst einmal korrekt sein - schließlich ist Winlogon ja auch für das Löschen der Datei zuständig. Schau Dir UPHClean einmal im Logging / Callstack Logging Modus an, vielleicht findest Du ja noch einen anderen Prozess, der blockiert: UPHClean and other profile ramblings : Call stack logging: what it is and where does it go? Ansonsten würde ich hier einmal hinein schauen, scheinbar gibt es so einige Punkte, die für ein Fehlschlagen der index.dat sorgen können: site:microsoft.com roaming profile unload index.dat - Google-Suche Viele Grüße olc

Hi Stefan, danke der Rückmeldung - schön, daß es wieder funktioniert. Es wurde also aller Wahrscheinlichkeit nach ein (virtuelles) Image zurückgesichert? Das ist auf DCs eine ganz schlechte Idee. ;) Viele Grüße olc

Hi Stephan und herzlich willkommen, :) meines Wissens gibt es keine Möglichkeit, den "Ziel-Zertifikatspeicher" beim Autoenrollment zu ändern. Es sei denn, Ihr scheibt Euch ein eigenes Exit Modul, damit könnte es nach meinem Verständnis möglich sein. Aber da mag ich mich irren. In welchem Zertifikatspeicher erwartet der XP WLAN Client denn die Computerzertifikate? Wenn Ihr diese manuell dorthin kopiert / verschiebt, funktioniert die Authentifizierung mittels Zertifikat und Windows-eigener Software korrekt? Viele Grüße olc

Hi Frank, kopiere testweise doch einmal von einem "frischen System" oder von Download details: Group Policy ADM Files die System.adm auf das betroffene System. Du solltest dann bestenfalls eine neue GPO erstellen und schauen, ob es damit geht. Somit umgehst Du den Abgleich zwischen lokaler ADM-Datei und der ADM-Datei im Sysvol, da zu diesem Zeitpunkt bei neuen Policies (klick auf Administrative Vorlagen) die Dateien erst ins Sysvol hochgeladen werden. Wenn das keine Änderung bringt, würde ich versuchen, die gptext.dll neu auf dem System zu registrieren: 1. regsvr32.dll /u gptext.dll 2. regsvr32.dll gptext.dll Bringt auch das nichts, könntest Du einmal in das gpedit-Logging schauen, ob etwas auffälliges zu finden ist: Enabling Logging for Group Policy Editor Kannst Du auf einem anderen System die Policies bearbeiten oder tritt das Problem auf allen Clients / Servern auf? Viele Grüße olc

Hi, schau einmal hier hinein, vielleicht hilft es Dir ja weiter: https://www.mcseboard.de/windows-forum-ms-backoffice-31/event-id-1054-neuem-2k3-dc-150473.html Falls nicht ist ein UserEnv Log zumindest ein Ansatz, es muß ja einen oder mehrere Fehler bei der Abarbeitung geben, den man gegenprüfen kann. Viele Grüße olc

Hi, Doch, indirekt ist der Schlüssel wichtig für den WSUS, nur fehlt unterhalb des "Safer" in der Auflistung oben wahrscheinlich der eigentliche Schlüssel, nämlich "AuthenticodeFlags". Neben anderen Diensten nutzt der WSUS Dienst diesen Key soweit ich weiß, um die Code Signaturen der Pakete gegenzuprüfen. Ist hier ein falscher Wert gesetzt, kann es vielleicht zu den Problemen kommen. Ich würde einmal mittels RSOP prüfen, ob unter Umständen der Wert über eine Gruppenrichtlinie oder ein Logonscript geändert wird - das würde erklären, warum der Fehler erst nach dem 2. Anmelden auftritt. Certificate Revocation and Status Checking Viele Grüße olc

Hi Frank, Du hast neben dem Kopieren der ADM-Datei in den lokalen %windir%\inf Ordner auch per Rechtsklick auf die Administrative Templates --> "Add / Remove Templates" das System.adm wieder in der betroffenen GPO eingefügt? Ist nur eine GPO betroffen oder alle, die Du auf dem Server / DC bearbeiten möchtest? Viele Grüße olc

Hi Mario, sorry, habe überlesen, daß es sich um Windows Server 2008 DFSR Systeme handelt. Der Fallback Hotfix greift zwar für XP / 2003, aber offene Dateihandles werden damit meines Wissens nicht wie unter Vista / 2008 zurück übertragen. D.h. ist eine Datei geöffnet, bleibt der XP / 2003 Client auf dem alten Ziel und geht nicht zurück. Das kann dann Probleme mit sich bringen... Bezüglich der AV Software: Nimm in jedem Fall auf allen DFSR Laufwerken "\System Volume Information\DFSR" + alle "DfsrPrivate" aus dem Scan aus. Ab 2008 liegen diese als Junction Point in "System Volume Information" vor. Von daher würde ersteres ausreichen, wenn die AV-Applikation damit zurecht kommt. Zur Überprüfung, warum die Dateien Konflikte erfahren, schalte das Security Logging für ausgewählte Ordner ein und prüfe des ändernden Benutzer. Ggf. sind es ja Administratoren oder Service Benutzer (etwa die Backup Applikation). Treten die Konflikte unter Umständen (bei komplett geöffnetem Schedule) immer zur selben Zeit auf oder verteilt auf den Tag? Viele Grüße olc

Hi, soweit ich weiß gibt es keine derartige Gruppenrichtlinie. Du kannst das ganze jedoch mit den Group Policy Preferences erledigen, wenn es sich um XP / 2003 Clients aufwärts handelt: Download details: Group Policy Preferences Overview Alternativ kannst Du auch den entsprechenden Registry Schlüssel per Script setzen. Viele Grüße olc

Hi, Grundsätzlich sicher nicht verkehrt der Gedanke - ich würde mir das jedoch noch einmal überlegen. Man sollte dabei jedoch beachten, daß es einen Client Cache gibt, so daß es ggf. etwas dauert, bis die Clients Notiz von dem neuen Ordnerziel nehmen. Außerdem kannst Du nach dem umschalten auf den zweiten Server nicht mehr so einfach "sicher" zurück auf das alte Ziel umschwenken, d.h. die Clients sollten nach Möglichkeit bis zum nächsten Ausfall lieber komplett auf dem "neuen" Server bleiben. Bei Vista / 2008 hat sich das Verhalten meines Wissens geändert - dort gibt es ein "sauberes" Fallback inkl. der Dateihandles. Welchen Hotfix-Stand hast Du auf den DFSR Systemen? Ich tippe spontan auf den folgenden, fehlenden Hotfix: Distributed File System Replication in Windows Server 2003 R2 performs unnecessary replication when an antivirus application is installed Wenn Du schon dabei bist, Deine Systeme zu aktualisieren, dann nimm den hier gleich mit ;) : When you try to update a file that has a newer version on a Windows Server 2003 R2-based DFSR server, the operation fails, the original file is deleted from the replication partners, and event 4412 and event 4502 are logged Ansonsten können auch Administratoren Änderungen vornehmen, ggf. Backup Applikationen, Scripts etc. Sollten die Hotfixes das Problem nicht beheben, würde ich es einmal mit Sicherheitsüberwachung versuchen... Ggf. kannst Du die Eventlogs ab einem gewissen Status archivieren und dann auf den DFSR Systemen selbst löschen. Dann sollten die Reporte bis zum nächsten Fehler wieder sauber sein. Viele Grüße olc

Hi, ich weiß nicht, ob ich das Problem vielleicht falsch verstanden habe, aber folgender Gedanke: Du deaktivierst die Offline Dateien. Du konfigurierst eine Orderumleitung etwa vom Desktop auf einen Unternehmensserver. Nun haben die Benutzer keinen Zugriff auf das Unternehmensnetzwerk. Wenn kein Zugriff auf das Netzwerk existiert, wie sollen die Benutzer dann Daten auf dem Dateiserver ablegen, auf den sie per Ordnerumleitung zugreifen sollten? Ich bin mir im Moment nicht 100% sicher, ob es einen weiteren "Fallback" Mechanismus gibt. Aber ich vermute bei abgeschalteten Offline Dateien / CSC eher nicht, denn das ist ja genau die Versicherung, daß bei fehlendem Netzwerk noch gearbeitet werden kann. Viele Grüße olc

Hallo, Du mußt für den SharePoint Server einen SPN erstellen, scheinbar fehlt "HTTP/SQLSERVER.domain.local" (trage Deinen MOSS HTTP / IIS Servernamen dort ein). Das ganze kannst Du etwa mittels SETSPN erledigen. Im Prinzip funktioniert das so: How to Configure an SPN for SQL Server Site Database Servers Viele Grüße olc

Hi, leider verstehe ich Deine Frage nicht. Was genau möchtest Du erreichen bzw. wo möchtest Du es einstellen? Ist das eine Datev bezogene Frage oder geht es um lokale Benutzer / Computerzertifikate? Viele Grüße olc