reinerk

Hallo und Guten Abend,

was geht denn da jetzt mit der MMC unter Vista ab bei mir ?

BS : Vista Business x64

- Rechner gestartet

- "Kontrollblick" ins Systemprotokoll....*.msc kann nicht geöffnet werden

aber wirklich nicht ein einziges Snap-In der MMC lässt sich öffnen

einfach so, und ohne erkennbaren Grund

Na und dann diese tolle Fehlermeldung :

Die Datei BlaBla.msc kann nicht geöffnet werden

Möglicherweise existiert die Datei nicht ( :D ),

ist keine MMC-Konsole ( aha ein Worddokument vermutlich )

oder wurde mit einer höheren MMC-version erstellt ( :confused: )

Es könnte auch sein, dass Sie nicht dazu berechtigt sind, auf diese Datei

zuzugreifen.

- sfc /scannow als "Erste Hilfe" brachte keine Fehler zum Vorschein

Hat das schon mal jemand erlebt ?

Übrigens ich habe das System nicht "kaputt optimiert" ;)

Es lief ja auch wirklich perfekt...bis eben.

Mal ganz ehrlich : solche Sch... kann man sich in einer produktiven Umgebung nicht leisten. ( Sorry, aber sowas macht mich jetzt echt stinksauer )

Hi,

 

ein Reinstall brachte auch keine Lösung?

Leider nicht, hatte ich schon probiert.

Tut mir Leid, daß ich das nicht gleich erwähnt hatte.

Nun können ja derartige Fehlermeldungen auch "irritierend" sein,

hatte aber trotzdem mal nachgeschaut, welche Treiber in den letzten 4 Wochen

aktualisiert worden sind...es war nur der NVidia Treiber für die GraKa.

Habe dann vorsichtshalber den vorherigen Treiber wieder installiert, aber

ohne daß sich da was geändert hatte.

Wäre auch irgendwie unerklärlich, oder ?:confused:

Guten Abend an Alle,

ich habe seit einigen Tagen in der Ereignesanzeige o.g. ID und Quelle UPHClean

mit folgender Fehlermeldung :

"User profile hive cleanup service was unable to load and start a required driver.

Insure that the account used to run the service has the load driver privilege and that this account can write to the directory where the service is installed.

See the diagnostics log for more information.

Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter...blabla"

Und da erhalte ich sie natürlich nicht und diesmal auch nur eine Antwort im EventID.Net.

Allerdings bezieht sich diese Antwort auf W2K und dieser "Fehler" ist lt. Microsoft seit XP behoben ( sprich Grössenbeschränkung der Registry).

Es ist nicht nachvollziebar für mich, um welchen Treiber es sich handeln könnte, der da angeblich nicht geladen werden kann.

Hat jemand schon mal mit diesem Fehler zu tun gehabt ?

BS ist XP-Pro/SP3 an Domäne.

Ansonsten gibt es keine "Unauffälligkeiten" auf diesem Client, läuft alles

problemlos.

<< -- Ich bleibe meinem LieblingsOS treu :)

 

Windows XP Pro bleibt die erste Wahl für mich. :thumb1:

 

Bei den Servern sind es durchweg 2003 Versionen.

Dem kann ich nur zustimmen

Hallo reinerk,

 

was war denn jetzt der Fehler / das Problem ?

Deine Batch hat geholfen,

vermutlich braucht dieses Netzlaufwerk erst einen Ping

um "aufzuwachen" :)

Hab's gestern Abend noch remote und eben gerade

vor Ort live überprüft.

Batchdatei in den Autostartordner geschoben, reboot...und es klappt!

Danke nochmals

Geh mal die Hinweise von XP-Fan exakt durch. Das klappt schon noch. ;)

Das Isses :)

Habt recht herzlichen Dank für Eure Geduld, Eure Mühe und

selbstverständlich für die "passende Lösung"

Hallo reinerk,

was hast du denn in der Batch stehen ?

Das Gleiche, was ich auch im Prompt eingebe

c:\windows\system32\ net use O: \\server\public

Befehlszeile funktioniert nicht als .bat im Autostart,

nicht im RUN Schlüssel in der Reg

aber wenn ich sie manuell starte

:confused:

Auf dem Client

Werde mich selbstverständlich wieder melden

...was ich jetzt hiermit getan habe

Es will nicht funktionieren

..GPO Einstellungen ( lokal am Client ) geändert wie hier beschrieben

..net use "per Hand" ausgeführt..es klappt

..net use als Batch oder Script..es klappt nicht

Ich glaube, ich geb's auf

Und wo ist der RUN-Wert definiert? Auf dem Client, dem Server?

Auf dem Client

Danke für die vielen Tips, kann sie allerdings auch erst in den nächsten Tagen "ausprobieren"

Werde mich selbstverständlich wieder melden

Ist bei der Anmeldung am Client, der Haken drin bei: Anmeldung über DFÜ-Verbindung herstellen. Wenn ja, dann sollte es so funktionieren, wenn nein, dann kannst Du es mittels Batch nach der Anmeldung am Client realisieren.

Hmm, danke erstmal für die prompte Hilfe.

Leider waren meine Aussagen vermutlich etwas zu "unvollständig" :

Also es ist so, daß 2 externe Mitarbeiter per VPN auf den Server gehen

Autoconnect erfolgt über Reg-Schlüssel HKLM\Software...etc.\run, was auch funktioniert.

Beide Mitarbeiter haben in der entsprechenden OU "Extern" einen UserAccount

Die Clients haben kein Computerkonto in der Domäne.

Demnach sollte die Einwahl, wie oben beschrieben :"Anmeldung über DFÜ-Verbindung herstellen" nicht so funktionieren , oder ?

Und wie verhält es sich mit dem "Net Use" Befehl ?

Bewirkt der nicht in diesem Fall genau das Gleiche wie die Aktivierung per Häkchen "Verbindung bei Anmeldung wiederherstellen " ?

Der externe Mitarbeiter startet eine Anwendung, die auf eine Datenbank, eben genau diese Freigabe " O:\" verweist, also auch zur Verfügung stehen muß.

Klappt die VPN Einwahl nicht, gibts ja auch die entsprechende Meldung nach dem Login, daß nicht alle Netzlaufwerke verbunden werden konnten.

Da aber die Verbindung sofort nach dem Login hergestellt wird, muß es doch auch so sein, daß diese Laufwerkszuordnung sofort aktiv ist, oder ?

Kann es damit zusammenhängen, daß diese Clients keine Computerkonten in der Domäne haben, und das Ganze somit nur innerhalb des Firmen-LAN's funktioniert ?

Guten Abend,

habe seit nunmehr einigen Wochen ein für mich unlösbares VPN Problem.

Folgende Situation :

- VPN Server W2K3

- externer Client XP Prof SP3

Verbindung beiderseits über 16 Mbit DSL Leitung..feste IP-Adresse

Der VPN Client wählt sich problemlos über EAP/IPSec im Firmennetzwerk ein.

Es wurde auf dem Client eine permanente Laufwerkzzuordung auf eine Freigabe auf dem Server ( LW O:\ ) eingerichtet,

die bei jeder Anmeldung wiederhergestellt werden soll,

wie es im internen LAN so "üblich" ist.

Nun ist es leider so, daß diese Verbindung nicht automatisch beim Anmelden hergestellt wird,

trotz "Häkchen" : "Verbindung bei Anmeldung wiederherstellen"

Der Client startet, die VPN Verbindung wird problemlos hergestellt, aber die

Netzwerkverbindung zu dem freigegeben LW wird nicht hergestellt,

sondern erst nach einem Doppelklick im Explorer auf dieses Netzlaufwerk.

Es soll ( und muß ) auch so sein, daß der externe Client sofort nach VPN

Einwahl eine aktive Netzwerkverbindung zu dieser Freigabe herstellt.

Ich bitte um Eure Hilfe und Denkanstöße

Sind die richtigen Verzeichnisse vom Scannen auf dem DC ausgenommen?

\Sysvol und \NTDS

Jetzt solltest Du nur noch die Ursache für das "verbiegen" finden. AV-Scanner? HDD-Probleme?

Ja da sollte ich "dran bleiben"

den AV-Scanner schließe ich aus (GData Business) läuft in meinem Netz

( Du erinnerst Dich die sind identisch )auch fehlerfrei.

HDDS sind meines Erachtens auch ok

System läuft als RAID1, da hätte sich sicherlich etwas "getan".

Nach dem Rückspielen des Backups läuft ( bisher !!! ) alles wieder rund.

Ich habe aber wie bereits gesagt, von diesem Problem schon des Öfteren gelesen, möglicherweise doch irgendwo ein Problem mit WSUS 3 SP1.

..@Sunny61

Es ist "vollbracht"

Zum Glück war auf dem Server noch ein "SystemState-Backup"

Verzeichniswiederherstellung gestartet...Backup zurück

Alles wieder in bester Ordnung !

In der Tat war das AD irgendwie "verbogen"

Mit ADSIEdit oder anderen ( zB von Sysinternals) AD-Tools kann man ja nun mal nichts bekennen, wenn die Datenbank online ist.

...Bitte berichte doch, wie es gelaufen ist, die Lösung ist evtl. für spätere Anfragen auch noch interessant. Ich drück dir die Daumen. ;)

..worauf Du Dich verlassen kannst !!

Sorry, ich kann dir hier nicht mehr weiterhelfen.

schon ok, zu diesem Problem gibt's seit 2007 unzählige Beiträge,

aber geholfen wurde da nicht so richtig.

Scheint die AD Datenbank im A... zu sein

Das Ganze sollte mit einer Verzeichnisdienstwiederherstellung klappen

( sicher bin ich da nicht ).

Danke Dir nochmals für deine Mühe

Auf einem Ordner oder Freigabe kannst Du aber den NETZWERKDIENST hinzufügen, oder geht das da auch nicht?

ja das klappt,

aber im AD Benutzer&Computer fehlen unter "ForeignSecurityPrincipals"

2 SID's :

1-5-18 und 1-5-6 also Dienst und System

will ich sie hinzufügen, ist "diese Gruppe bereits vorhanden"

au mann, ich denke das AD ist hier "verbogen".

Habs anders herum probiert :

Netzwerkdienst als "Mitglied von" : IIS_WPG aber ebenso erfolglos :

"AD Fehler: Ein neues Mitglied konnte nicht zu einer lokalen Gruppe hinzugefügt werden, da das Mitglied den falschen Kontentyp aufweist"

Hab ich was überlesen? Ich hab nix von einem DC in diesem Thread gelesen. :confused:

Kann es sein, daß der Server vorher mit installiertem WSUS ein Member war und dann einfach zum DC promoted wurde?

..hab vergessen den DC zu erwähnen.

Nein die Kiste ist von Anfang an ein DC un der WSUS kam erst später rauf.

"Netzwerkdienst" gibt's nicht zum hinzufügen.

habe es auch schon mit ADSiEdit versucht, ohne Erfolg

Doch die lassen sich hinzufügen. Du mußt den lokalen Computer auswählen, dann gehts. Habs grade gemacht. ;)

:confused:

..auf einem DC ?

..im AD Benutzer und Computer ?

....

Irgendeinen Grund muß und wird es auch dafür geben...

.... Kontrollier doch lieber mal die NTFS-Berechtigungen gem. diesen Dokumenten:

-----------------------------------------------------------------

Aber bitte Schritt für Schritt, nichts auslassen!

 

ok, war ein Stück Arbeit, das alles abzuchecken

Ergebnis : alles so wie es sein soll.

Das ist es ja eben, daß es sozusagen aus "heiterem Himmel nicht mehr funktioniert.

Das Update auf WSUS 3SP1 wurde gleich nach dem Erscheinen durchgeführt und lief problemlos.

Alle NTFS Berechtigungen sind ok, alle Einstellungen f. die virtuellen Verzeichnisse im IIS ebenfalls.

Ich glaube doch bald, daß es an dieser Gruppenmitgliedschaft in der Gruppe

"IIS_WPG" liegt :

Bei mir läuft ebenfalls der WSUS in der genau gleichen Konfiguration (selbst die

Verzeichnisnamen sind identisch) und auf meinem Server sind eben in dieser Gruppe IIS_WPG die Mitglieder "Dienst" "System" und "Netzwerkdienst" automatisch bei der Installation vom IIS hinzugefügt worden.

Auf diesem Problemserver fehlen die..und lassen sich ja auch nicht hinzufügen.

Irgendwie geht es jetzt nicht weiter.

Hallo an die Gemeinde,

förmlich "über Nacht" hat sich der WSUS auf einem Server 2003 "verabschiedet:

Ich wurde darauf aufmerksam, da im Systemprotokoll Event-ID's

12002, 12022, 12032, 12042, 12052, 13042 auftauchen.

EventID.Net und Microsoft "befragt", aber leider keine brauchbaren Lösungen

für dieses Problem gefunden.

WSUS deinstalliert und neu installiert : keine Besserung

IIS deinstalliert und neu installiert : ebenfalls negativ

Dann ist mir im Systemprotokoll des Servers aber aufgefallen, dass

dem Konto IUSR_Server der Zugriff verweigert wurde ( Aufruferbenutzername

"Netzwerkdienst" )

Die lokale Gruppe im AD "IIS_WPG" enthält nur ein Mitglied , nämlich den IUSR.

Es fehlen "Dienst" , "System" und "Netzwerkdienst", und ich denke, da liegt das Problem.

Aber wie bekomme ich die jetzt in diese lokale Domänengruppe ?

XP Prof mit SP3 ( Final, die heute am 30.04. wieder zurückgezogen wurde )

Anm.: SP3 Installation problemlos, nach Neustart völlig fehlerfrei also keine

Warnungen oder Fehler im Ereignisprotokoll

Ein weiterer Grund Vista nicht einzusetzen

IThome Du hattest Recht

habe nochmals mit dem betreffenden User telefoniert und siehe da,

was ich nicht wissen konnte, der hat sein Userzertifikat auf sein Notebook importiert und dort hat er ganz andere lokale Anmeldeeinstellungen sprich Name

und Kennwort....das war's also.

Danke für die schnellen Antworten und die Hilfe.

Melden sich denn einige VPN-Clients an ihren Rechnern mit Konten/Kennwörtern an, die auch in der Domäne existieren und andere eben mit Konten, die entweder so nicht existieren oder die ein anderes Kennwort in der Domäne haben ?

Das ist ja das Problem:

-Alle VPN User sind Mitglieder einer Sicherheitsgruppe "VPN"

-Alle VPN User haben ein gültiges Zertifikat und authentifizieren sich

per Zertifikat fehlerfrei am Server

-User A kann auf Verzeichnis A ohne erneute Authentifizierung zugreifen

-User B wird bei der Verbindung zu "seinem" Laufwerk B zur Eingabe von

von Benutzername und Password aufgefordert

-Auf allen XP Clients ist die gleiche Konfiguration für die VPN Verbindung

Beispiel :

1. Benutzer A ist Mitglied der Gruppe VPN und hat das Kennwort 123

2. Benutzer A fordert ein Zertifikat an, welches erfolgreich installiert wird

3. Benutzer A verbindet sich nur noch über EAP und L2TP/IPSec

4. Benutzer A verbindet sich mit \\Server\BenutzerA

Das war's

Punkt 1 bis 4 für Benutzer B identisch

Benutzer B muss sich dann jedoch beim Verbinden mit \\Server\BenutzerB

erneut mit Benutzername und Passwort authentifizieren.

Es spielt dabei keine Rolle,ob die lokalen Kennwörter auf dem Client

und das Kennwort des Users in der AD identisch sind oder nicht.

Irgendwie läuft da was mächtig quer und ich habe keinen Lösungsansatz

Ist der Haken bei allen Clients gesetzt oder nicht ?

Nein ist bei allen Clients raus