Marcel Rechenbe

Fragliche Installationszeit war zw. 9 und 10 Uhr. netlogon-Fehler war um 15.27 Uhr und handelt von von folgendem: Die Sitzung konnte von Computer "R10" nicht eingerichtet werden, da kein Vertrauenskonto in der Sicherheitsdatenbank für diesen Computer vorhanden ist. Der Kontoname in der Sicherheitsdatenbank ist R10$. Wenn ich das richtig versteh, geht es hier um die fehlgeschlagene Anmeldung eines Clients und glaube daher nicht, das das mit unserem Installationsproblem (auch wegen der zeitlichen Abfolge) zusammenhängt. Aber ich weiss schon: glauben heißt nix wissen.... LG Markus

Hallo, vorweg sorry für meine Servicenummer-Anfrage. War als ehrliche Anfrage eines Unwissenden gedacht, ist aber wohl anders rübergekommen. Zu deinem Eventlog-Tipp: Es gibt keinerlei Besonderheiten. Zum den fraglichen Installationszeitpunkten (mehrmals versucht) gibt es keinerlei verdächtigen Einträge, auch ansonsten bis auf die üblichen Verdächtigen (Symantec-Antivirenwarnung, netlogon-Fehler, hie und da (1-3 x/Woche) mal ein Schannel-Fehler) alles im absolut grünen Bereich. LG Markus

Hallo, danke für die Info. Wie gesagt, schweigt sich MS über sonstige Vorbedingungen aus, "Weitere Infos" auf deren Homepage führen ins Leere. Leider haben wir kein Telefon-Support-Abkommen mit MS und Geld dafür zu bezahlen, um eine Frage zur Installation eines Reparaturteils beantwortet zu bekommen (also für etwas bezahlen, weil MS gepfuscht hat, sonst bräuchts ja den Patch nicht) bringen wir bei unsrem Chef nicht durch. Oder gibt´s inzwischen eine Server-Servicenummer "für die Allgemeinheit", die mir entgangen ist? Grüße Markus

Hallo, nach ausgiebiger Suche im Internet scheint es für folgendes Problem noch keine "öffentliche" Lösung zu geben: Wir haben von der MS-Download-Seite den Patch heruntergeladen. Nach dem Start per doppelklick beginnt das Entpacken und bleibt dann mit folgender Fehlermeldung hängen: Setup kann nicht fortgesetzt werden, weil mindestens eine Vorraussetzung für die Installation von Sicherheitsupdate[...] nicht zutrifft. Weitere Informationen erhalten sie in der Protokolldatei [...].log. In der Protokolldatei findet sich diese Fehlermeldung nochmal, und einige Zeilen darüber folgende Hinweise: - DoInstallation: GetProcAddress (InizializeCustomationDLL) Returned: 0x7f - CreateUserInterface: GetProcAdress for DefineInstallCustomUI failed: 0x7f - Exec Rollup.AndOp.Section: Result ValueName RollupMajorVersion not found for Key ..... -First Condition in Rollup.AndOp.Section Failed - Condition Check for Line 1 of Prerequisite returned FALSE Die Vorbedinungen hab ich gecheckt, alles erfüllt: Win2000Server mit SP4, Exchange2000 mit SP3 Wer kann helfen, da ich mit den zusätzlichen Infos aus der Log-Datei nicht wirklich viel anfangen kann, die MS-Homepage nicht weiterhilft und auch Google nichts brauchbars liefert?

Hallo Form, das Problem könnte gelöst sein. Vor 3 Wochen wurde bei uns im DFS-Stamm eine Änderung vorgenommen. Ein Kollege hat einen neuen Link aufgenommen, diesen aber nicht über eine Verzeichnisfreigabe, sondern über "\\Servername\D$\..." eingebunden gehabt. Über die administrative Freigabe hat natürlich niemand Zugriffrechte. Nachdem ich die Freigabe korrekt eingegeben habe, trat das Problem noch nicht wieder auf. :D Das ist dann aber ein ganz schöner Hammer. Immerhin waren durch einen falschen Link alle Freigaben auf diesem Server für Office-Produkte nicht mehr erreichbar, bzw. stand der gesamte Server nur mit Schreibschutz zur Verfügung. Ich bin gespannt, ob das Problem wiederkommt, oder ob es wirklich an der falschen Einbindung lag ;) . tschau, marsdiver

Hi, hab ganz vergessen, dass ich das gepostet hatte. Die Lösung waren tatsächlich Dateien, die in Temporary Internet Files abgelegt werden. Allerdings reicht es nicht aus, über "LW:\Dokumente und Einstellungen\User\Lokale Einstellungen\Temporary Internet Files\OLK2F" die Dateien zu suchen. MS hat irgendwo einen Filter eingebaut, so dass man nicht alle Daten sieht. Über "\\PC-Name\LW:\Dokumente und Einstellungen\User\Lokale Einstellungen\Temporary Internet Files\OLK2F" kann man die Filterung umgehen und dann alle Dateien löschen. Bei uns hat es geholfen. Das Grundproblem lag wohl daran, dass MS allen Dateien mit gleichem Namen einen Zähler nachstellt. Schaut dann so aus: "Dateiname[Zähler].Erweiterung". Irgendwann kann dann Windows keine Zahl mehr dranhängen und dann kommt die Fehlermeldung. Ich hoffe, bei dir läßt sich dass Problem auch so lösen. tschau, Marcel Rechenberg

Tja, was auch immer über Nacht passiert ist, die Meldungen kommen nicht wieder. Muss allerdings noch sagen, dass ich die Arbeitsgruppe des Server umbenannt habe, um die Usergroups mal sauber zu bekommen.

Tja, hat leider nichts gebracht. In der Winlogon steht immer noch folgendes drin: ----Benutzerrechte werden konfiguriert... Konfigurieren von XY.ITL.DE\Administrator. Fehler 1332: Zuordnungen von Kontennamen und Sicherheitskennungen wurden nicht durchgeführt. XY.ITL.DE\Administrator wurde nicht gefunden. Konfigurieren von S-1-5-32-544. Konfigurieren von S-1-5-32-551. Konfigurieren von S-1-5-21-790525478-1177238915-839522115-500. Konfigurieren von S-1-5-21-790525478-1177238915-839522115-1002. Konfigurieren von S-1-5-21-790525478-1177238915-839522115-1001. Konfigurieren von S-1-1-0. Konfigurieren von S-1-5-32-545. Konfigurieren von S-1-5-32-547. Konfigurieren von S-1-5-6. Konfigurieren von S-1-5-21-790525478-1177238915-839522115-1006. Konfigurieren von S-1-5-21-790525478-1177238915-839522115-501. Konfigurieren von S-1-5-21-790525478-1177238915-839522115-1000. Konfiguration der Benutzerrechte wurde fehlerhaft abgeschlossen. Laut der MS-Beschreibung sollte in der Datei auch gelöschte Account aufgeführt werden. Dafür gab es aber keine Einträge. Unter den Lokalen Sicherheitseinstellungen habe ich unter "Als Dienst anmelden" den Eintrag "XY.itl.de\Administrator" gefunden. Den hab ich durch "XY\Administrator" ersetzt. Im Ereignisprotokoll kam für diese Änderung wieder der Fehler 1202. Ich dreh mich hier irgentwie im Kreis.

Super, werd ich gleich mal checken.

Hi, ich hoffe, es findet sich irgendjemand, der uns helfen kann, denn uns sind alle Ideen ausgegangen. Unser Problem: Wir haben einen Single Server (W2k, SP4, alle MS-Sicherheitspatches), dem wir vor 3 Wochen einen 2 Prozessor eingebaut haben. Ob es damit zusammenhängt, keine Ahnung. Seit dem haben wir mehrmals am Tag die Fehlermeldung: Ereigniskennung: 1202 Die Sicherheitsrichtlinien werden mit Warnungen übermittelt. 0x534 : Zuordnungen von Kontennamen und Sicherheitskennungen wurden nicht durchgeführt. In dieser Fehlermeldung ist beschrieben, was wir tun sollen. 1. Identifizieren Sie Konten, für die keine SID aufgelöst werden konnte. Mit dem Befehl "FIND /I "nicht gefunden" %SYSTEMROOT%\Security\Logs\winlogon.log" den Benutzer suchen, der ein Problem verursacht. Unser Ergebnis: "Servername.itl.de\Administrator wurde nicht gefunden" 2. .Identifizieren Sie alle Gruppenrichtlinienobjekte, die einen nicht aufgelösten Kontonamen enthalten. Mit dem Befehl ""!FIND /I "Administrator" %SYSTEMROOT%\Security\templates\policies\gpt*.*" soll das passieren. Unser Ergebnis: Die Datei existiert nicht. Da wir uns nicht erklären können, warum die gpt-Datei fehlt, haben wir die von einem anderen Server in das Verzeichnis eingespielt. Danach haben wir in den Lokalen Sicherheitsrichtlinien eine Änderung vorgenommen, mit dem Ergebnis, dass die gpt-Datei wiederum weg war. Im Ereignisprotokoll haben wir dafür weiterhin den Fehler. Das, was mich an den Fehler wundert, ist folgendes: 1. Wir können uns nach wie vor als Administrator anmelden 2. Unser Server heißt XY und ist in der Arbeitsgruppe XY.itl.de 3. Wenn wir in den Gruppenrichtlinien unter "Zuweisen von Benutzerrechten" Benutzer hinzufügen wollen, enthält das Suchfeld die Suche in XY und extra aufgeführt XY.itl.de. In der Liste können wir sehen, das überall der Administrator von XY.itl.de steht und nicht von XY. Die Fehlermeldung sagt aber aus, das der Administrator von XY.itl.de nicht existiert. Da wir auf dem Server schon eine Applikation nicht aufrufen können, befürchten wir, dass uns der unter unseren Fingern verreckt. Bitte, bitte, weiß jemand Rat?

Hi, wir haben bei uns ein ziemlich komisches Problem mit Outlook XP auf einem W2k PC.: Eine Kollegin bekommt per E-Mail von einem Kunden Auftragsbestätigungen zugeschickt. Das Attachment heißt "Übersetzungsauftrag.doc" Bis letzte Woche konnte Sie die Word-Datei aus dem E-Mail heraus einfach öffnen oder abspeichern. Seit letztem Donnerstag funktioniert das nicht mehr. Beim Doppelklick oder Speicherversuch kommt stattdessen folgende Fehlermeldung: "Die Datei "Übersetzungsauftrag.doc" kann nicht erstellt werden. Klicken Sie mit der rechten Maustaste auf den Ordner, in dem Sie die Datei erstellen möchten, und klicken Sie dann auf "Eigenschaften", um Ihre Berechtigungen für den Ordner zu überprüfen." Wenn das Attachment z.B. "Übersetzungsauftrag_1.doc" heißt, geht das Öffnen oder Speichern wie gewohnt. Wir haben schon alle Temp-Verzeichnisse gelöscht und auch alle Dateien, die irgendwie Übersetzung heißen, hat aber alles nichts genutzt. Hat von euch jemand eine Idee, wie wir Outlook wieder dazu bringen können, genau diese Datei zu öffnen? tschau, marcel rechenberg

Danke für deine Antwort. Habe den Wert mal auf 1272 gesetzt, hat aber auch nichts gebracht. Wenn ich über VPN connecte, wird der virtuelle LAN-Adapter nicht auf aktiv gesetzt, sondern bleibt deaktiviert. tschau, marcel

Doch noch ne Frage. Habe festgestellt, dass beim VPN Connect die virtuelle LAN-Verbindung nicht von "deaktiviert" auf "aktiviert" gesetzt wird. Damit kann der VPN-Client natürlich nicht auf die Haupt-LAN-Verbindung zugreifen. Hast du da vielleicht noch ne Idee? tschau, marcel

OK, danke für deine Hilfe. tschau, marcel

Hallo Markus, hat leider nicht funktioniert. Wir haben das Phänomen mittlerweile in einer Testumgebung nachstellen können. Erst eine DFÜ-Verbindung eingerichtet, VPN gestartet, im "Dial-Up "Connect to Internet via dial-up" aktiviert, alles OK. Dann DFÜ-Verbindung deinstalliert, im Menü "Dial-Up "Connect to Internet via dial-up" deaktiviert, VPN connected, nichts passiert, Fehler 412 erscheint. Es ist schier zum verzweifeln. Danke und tschau, marcel