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 )

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.

Dem kann ich nur zustimmen

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

Das Isses :) Habt recht herzlichen Dank für Eure Geduld, Eure Mühe und selbstverständlich für die "passende Lösung"

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:

...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

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

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

\Sysvol und \NTDS

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.

..worauf Du Dich verlassen kannst !!

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

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 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

:confused: ..auf einem DC ? ..im AD Benutzer und Computer ?

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.

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

Nein ist bei allen Clients raus