22
Mysteriös verbundenes Netzlaufwerk
Moin zusammen,
Es ist Freitag und da hat man mal Zeit sich um die nervigen Dinge zu kümmern. Also los geht's
In Diesem Beitrag habe ich ein PS Skript erstellt und ausgeführt. Das ganze funktioniert wunderbar. Aber auch dort habe ich geschrieben:
Ein anderer User (der sich mittlerweile gelöscht hat oder wurde) hat dort geschrieben:
Das war/ist in meinen Augen totaler Blödsinn, weil das Skript ja läuft. Stattdessen mich ich in den letzten Tagen sofern Zeit war mal der Meldung nachgekommen. Die Ursache für die Meldung ist/war ein unter dem Systemkonto verbundenes nicht verfügbares Netzlaufwerk. Bei meiner Recherche nach einer Lösung bin ich natürlich auf über PSEXEC gestolpert. Damit lässt sich das Problem zwar lösen, aber es ist ein Heidenaufwand, da unser Virenscanner PSEXEC anmeckert und ich dies für jeden Rechner wo ich es brauche separat freigeben müsste. Zumal ein bereinigen des Netzlaufwerkes nur temporäre Abhilfe schafft, da das Netzlaufwerk dann wiederkommt.
Also habe ich mich auf die Ursache begeben und konnte folgendes Feststellen:
Das Netzlaufwerk welches unter dem Systemkonto aufgeführt wird, ist vorhanden und erreichbar. Es ist keine verwaiste Freigabe sondern eine Freigabe die bei allen User per GPO gemappt wird. Andere Laufwerksmappings werden nicht durchgeführt. Das Verhalten ist an Windows 10 und Windows 8 Rechnern merkbar. Es tritt nicht bei allen Windows 10 Rechnern auf, obwohl alle über das gleiche Image installiert wurden. Selbst bei Anwendern die die gleichen GPOs zugewiesen haben und vom gleichen Win10 Image stammen, habe ich das Problem nicht bei allen Rechnern.
Laut MS Technet kann man einen registry-Wert ändern um als Admin auf das Systemkonto zuzugreifen. Das wird Laut MS aber nur als Workaround empfohlen. Beides hilft mir an der Stelle nicht weiter, da ich die Ursache finden will und nicht das Symptom behandeln möchte. Da die Laufwerke ausschließlich per GPO gemappt werden (und es nur eine GPO für alle Laufwerke gibt), kann ich auch den beschriebenen Error 85 nicht finden, da dieser vom Net use kommt. Ich finde zwar auf dem betroffenen Rechner ein Fehler 85, diese sind aber alle vom Oktober. Die Bereinigung mit PSEXEC war aber gestern. Kommen also für den Fehler ebenfalls nicht in Frage. Seitdem ich gestern das Laufwerk gelöscht habe (Und der Fehler dann weg war) ist das Laufwerk wie gesagt nach etwa einer halben Stunde wieder aufgetreten. Der Rechner hat seit meiner Löschung bis heute weder eine Warnung, noch einen Fehler protokolliert; lediglich Informationen.
Was will ich jetzt von euch? Ich weiß, dass niemand von euch mir eine Lösung für das Problem geben kann, aber vielleicht hat jemand eine Idee voran es liegen kann oder auch nach welcher Error-ID in welchem Protokoll ich suchen muss um irgendwie dem Grund für das Mapping zu finden.
Derzeit sind 17 von den um 08:00 Uhr angeschalteten 38 Rechnern davon betroffen. Bei der Skriptausführung bei der das Problem ursprünglich entdeckt wurde, lag die Quote bei etwa 33 % der Firmenrechner.
Gruß
Doskias
Es ist Freitag und da hat man mal Zeit sich um die nervigen Dinge zu kümmern. Also los geht's
In Diesem Beitrag habe ich ein PS Skript erstellt und ausgeführt. Das ganze funktioniert wunderbar. Aber auch dort habe ich geschrieben:
Wenn ich das Skript in dem Zustand ausführe, dann bekomme ich gelegentlich die Meldung:
Fehler beim Ausführen des InitializeDefaultDrives-Vorgangs für den Anbieter "FileSystem".
Ein anderer User (der sich mittlerweile gelöscht hat oder wurde) hat dort geschrieben:
Stichwort "Powershell Profil laden verhindern".
Das war/ist in meinen Augen totaler Blödsinn, weil das Skript ja läuft. Stattdessen mich ich in den letzten Tagen sofern Zeit war mal der Meldung nachgekommen. Die Ursache für die Meldung ist/war ein unter dem Systemkonto verbundenes nicht verfügbares Netzlaufwerk. Bei meiner Recherche nach einer Lösung bin ich natürlich auf über PSEXEC gestolpert. Damit lässt sich das Problem zwar lösen, aber es ist ein Heidenaufwand, da unser Virenscanner PSEXEC anmeckert und ich dies für jeden Rechner wo ich es brauche separat freigeben müsste. Zumal ein bereinigen des Netzlaufwerkes nur temporäre Abhilfe schafft, da das Netzlaufwerk dann wiederkommt.
Also habe ich mich auf die Ursache begeben und konnte folgendes Feststellen:
Das Netzlaufwerk welches unter dem Systemkonto aufgeführt wird, ist vorhanden und erreichbar. Es ist keine verwaiste Freigabe sondern eine Freigabe die bei allen User per GPO gemappt wird. Andere Laufwerksmappings werden nicht durchgeführt. Das Verhalten ist an Windows 10 und Windows 8 Rechnern merkbar. Es tritt nicht bei allen Windows 10 Rechnern auf, obwohl alle über das gleiche Image installiert wurden. Selbst bei Anwendern die die gleichen GPOs zugewiesen haben und vom gleichen Win10 Image stammen, habe ich das Problem nicht bei allen Rechnern.
Laut MS Technet kann man einen registry-Wert ändern um als Admin auf das Systemkonto zuzugreifen. Das wird Laut MS aber nur als Workaround empfohlen. Beides hilft mir an der Stelle nicht weiter, da ich die Ursache finden will und nicht das Symptom behandeln möchte. Da die Laufwerke ausschließlich per GPO gemappt werden (und es nur eine GPO für alle Laufwerke gibt), kann ich auch den beschriebenen Error 85 nicht finden, da dieser vom Net use kommt. Ich finde zwar auf dem betroffenen Rechner ein Fehler 85, diese sind aber alle vom Oktober. Die Bereinigung mit PSEXEC war aber gestern. Kommen also für den Fehler ebenfalls nicht in Frage. Seitdem ich gestern das Laufwerk gelöscht habe (Und der Fehler dann weg war) ist das Laufwerk wie gesagt nach etwa einer halben Stunde wieder aufgetreten. Der Rechner hat seit meiner Löschung bis heute weder eine Warnung, noch einen Fehler protokolliert; lediglich Informationen.
Was will ich jetzt von euch? Ich weiß, dass niemand von euch mir eine Lösung für das Problem geben kann, aber vielleicht hat jemand eine Idee voran es liegen kann oder auch nach welcher Error-ID in welchem Protokoll ich suchen muss um irgendwie dem Grund für das Mapping zu finden.
Derzeit sind 17 von den um 08:00 Uhr angeschalteten 38 Rechnern davon betroffen. Bei der Skriptausführung bei der das Problem ursprünglich entdeckt wurde, lag die Quote bei etwa 33 % der Firmenrechner.
Gruß
Doskias
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 651169
Url: https://administrator.de/forum/mysterioes-verbundenes-netzlaufwerk-651169.html
Ausgedruckt am: 22.12.2024 um 08:12 Uhr
22 Kommentare
Neuester Kommentar
Hallo,
Dann schmeiß den Virenscanner halt weg.
Gute Scanner blockieren nur Viren und lassen sich zudem zentral verwalten.
Gruß,
Jörg
da unser Virenscanner PSEXEC anmeckert und ich dies für jeden Rechner wo ich es brauche separat freigeben müsste
Dann schmeiß den Virenscanner halt weg.
Gute Scanner blockieren nur Viren und lassen sich zudem zentral verwalten.
Gruß,
Jörg
Hallo Jörg,
das ist nicht hilfreich.
Natürlich kann ich den Virenscanner zentral verwalten, aber selbst in der zentralen Verwaltung muss ich jeden Client einzeln genehmigen. Klar könnte ich PSEXEC auch generell als Ausnahme definieren, aber das steht im Widerspruch zu unserer Sicherheitspolitik, nur das freizugeben was auf den einzelnen Clients gebraucht wird und nicht pauschal für alle. Davon abgesehen schreibt selbst Microsoft in den Downloads:
welchen Scanner würdest du denn als "guten Scanner" empfehlen. Ich hab Spaßeshalber jetzt Watchguard Enpoint Antivirus, Kaspersky, Sophos Protection, Avast und Avira ausprobiert. Alle fünf schlagen bei PSEXEC Alarm. Deiner Aussage nach, ist also keiner davon gut?
Und nochmals: PSEXEC zu nutzen löst das Problem nicht sondern nur das Symptom. Was nützt es mir, wenn ich das Laufwerk entferne und es 10 Minuten später wieder da ist und der Fehler dann wiederkommt?
Gruß
Doskias
das ist nicht hilfreich.
Natürlich kann ich den Virenscanner zentral verwalten, aber selbst in der zentralen Verwaltung muss ich jeden Client einzeln genehmigen. Klar könnte ich PSEXEC auch generell als Ausnahme definieren, aber das steht im Widerspruch zu unserer Sicherheitspolitik, nur das freizugeben was auf den einzelnen Clients gebraucht wird und nicht pauschal für alle. Davon abgesehen schreibt selbst Microsoft in den Downloads:
Note: some anti-virus scanners report that one or more of the tools are infected with a "remote admin" virus. None of the PsTools contain viruses, but they have been used by viruses, which is why they trigger virus notifications.
welchen Scanner würdest du denn als "guten Scanner" empfehlen. Ich hab Spaßeshalber jetzt Watchguard Enpoint Antivirus, Kaspersky, Sophos Protection, Avast und Avira ausprobiert. Alle fünf schlagen bei PSEXEC Alarm. Deiner Aussage nach, ist also keiner davon gut?
Und nochmals: PSEXEC zu nutzen löst das Problem nicht sondern nur das Symptom. Was nützt es mir, wenn ich das Laufwerk entferne und es 10 Minuten später wieder da ist und der Fehler dann wiederkommt?
Gruß
Doskias
welchen Scanner würdest du denn als "guten Scanner" empfehlen.
Für externe Scanner gibt es mittlerweile keinerlei Gründe mehr:https://www.heise.de/select/ct/2019/3/1549002696073866
https://www.heise.de/newsticker/meldung/Virenschutz-im-Test-Reicht-der-W ...
Hallo,
ich kann dir leider keinen Virenscanner empfehlen.
Und ja: Die von Dir erwähnten Scanner halte ich ebenfalls für sehr schlechte Programme.
Ich würde ebenfalls die Ursache für den Fehler suchen.
Gruß,
Jörg
ich kann dir leider keinen Virenscanner empfehlen.
Und ja: Die von Dir erwähnten Scanner halte ich ebenfalls für sehr schlechte Programme.
Ich würde ebenfalls die Ursache für den Fehler suchen.
Gruß,
Jörg
Hallo,
lies mal PSEXEC-Dienst erlaubt, Systeme zu übernehmen
Vielleicht hilft ein Update von psexec auf die aktuelle Version.
Grüße
lcer
lies mal PSEXEC-Dienst erlaubt, Systeme zu übernehmen
Vielleicht hilft ein Update von psexec auf die aktuelle Version.
Grüße
lcer
Nein es ist die aktuellste Version von PSEXEC. Es sei denn es ist innerhalb der letzten 24 Stunden eine neue Version erschienen
Ich bin grade leider echt etwas enttäuscht. Warum? ganz einfach:
Ich habe mir die Mühe gemacht einen Text zu schreiben indem ich möglichst alles sage, was es zu sagen gibt und gefühlt wird nur PSEXEC und Virenscanner gelesen. Daher nochmal deutlich:
Es geht hier nicht darum, dass PSEXEC nicht funktioniert. Natürlich kann ich mit PSEXEC das Laufwerk löschen, es kommt dann allerdings wieder.
Es geht hier nicht darum, dass der Virenscanner schlecht, blöd oder unnötig ist. Fakt ist, dass es vorgaben gibt was die Virenscanner angeht. Selbst wenn ich mich an diese Vorgaben nicht halte, dann bringt mir PSEXEC nichts, weil das Laufwerk nach 10 Minuten wiederkommt. PSEXEC löst nicht die Ursache.
Eure Hinweise sind sicherlich gut gemeint, gehen aber am eigentlichen Thema, nämlich eine Möglichkeit zu finden wer oder was diese Laufwerke mappt zu finden, vorbei.
Gruß
Doskias
Ich bin grade leider echt etwas enttäuscht. Warum? ganz einfach:
Ich habe mir die Mühe gemacht einen Text zu schreiben indem ich möglichst alles sage, was es zu sagen gibt und gefühlt wird nur PSEXEC und Virenscanner gelesen. Daher nochmal deutlich:
Es geht hier nicht darum, dass PSEXEC nicht funktioniert. Natürlich kann ich mit PSEXEC das Laufwerk löschen, es kommt dann allerdings wieder.
Es geht hier nicht darum, dass der Virenscanner schlecht, blöd oder unnötig ist. Fakt ist, dass es vorgaben gibt was die Virenscanner angeht. Selbst wenn ich mich an diese Vorgaben nicht halte, dann bringt mir PSEXEC nichts, weil das Laufwerk nach 10 Minuten wiederkommt. PSEXEC löst nicht die Ursache.
Eure Hinweise sind sicherlich gut gemeint, gehen aber am eigentlichen Thema, nämlich eine Möglichkeit zu finden wer oder was diese Laufwerke mappt zu finden, vorbei.
Gruß
Doskias
Hallo,
es tut mir leid, dass Du enttäuscht bist.
Aber die Einzige nachhaltige Lösung ist nun mal, ein Problem gar nicht erst auftreten zu lassen.
Vermutlich habt Ihr eine Software gekauft, die herumzickt. Der Hersteller kommt nicht in die Puschen (vielleicht sogar weil das Geld für Wartungsverträge gespart wird) und Du versuchst jetzt verzweifelt, mit Halbwissen am Fehler vorbeizuscripten.
Ich kann mir vorstellen, dass so etwas Frust erzeugt. Letztendlich gibt es aber keine andere Lösung.
Noch einmal: Es tut mir sehr leid.
Gruß,
Jörg
es tut mir leid, dass Du enttäuscht bist.
Aber die Einzige nachhaltige Lösung ist nun mal, ein Problem gar nicht erst auftreten zu lassen.
Vermutlich habt Ihr eine Software gekauft, die herumzickt. Der Hersteller kommt nicht in die Puschen (vielleicht sogar weil das Geld für Wartungsverträge gespart wird) und Du versuchst jetzt verzweifelt, mit Halbwissen am Fehler vorbeizuscripten.
Ich kann mir vorstellen, dass so etwas Frust erzeugt. Letztendlich gibt es aber keine andere Lösung.
Noch einmal: Es tut mir sehr leid.
Gruß,
Jörg
Nein du verstehst du mich falsch und zwar völlig. Der Fehler ist bei einem Skript aufgetreten, das ist richtig, aber das Skript hat nichts mit dem Fehler zu tun. Ich versuche auch nicht am Fehler oder irgendwas vorbeizuscripten. Ganz im Gegenteil. Ich habe am Ende geschrieben.
Genau das ist das was ich im ersten Beitrag lang und breit (offenbar nur) versucht habe zu erklären.
Wenn dem nur so wäre. An SW läuft neben dem Virenscanner, ein ERP System und Office O365 auf den Rechnern. Bei manchen noch ein Programm zu Zeiterfassung oder CAD-Programm oder ähnliches. Aber auch diese Programme können dafür nicht ursächlich sein, denn der Fehler tritt auch auf Rechnern auf wo nur das ERP und O365 installiert ist. Aber auch hier tritt es halt nicht bei allen Rechner auf.
Gruß und schönes Wochenende
Doskias
Was will ich jetzt von euch? Ich weiß, dass niemand von euch mir eine Lösung für das Problem geben kann, aber vielleicht hat jemand eine Idee voran es liegen kann oder auch nach welcher Error-ID in welchem Protokoll ich suchen muss um irgendwie dem Grund für das Mapping zu finden.
Zitat von @117471:
Aber die Einzige nachhaltige Lösung ist nun mal, ein Problem gar nicht erst auftreten zu lassen.
Aber die Einzige nachhaltige Lösung ist nun mal, ein Problem gar nicht erst auftreten zu lassen.
Genau das ist das was ich im ersten Beitrag lang und breit (offenbar nur) versucht habe zu erklären.
Vermutlich habt Ihr eine Software gekauft, die herumzickt. Der Hersteller kommt nicht in die Puschen (vielleicht sogar weil das Geld für Wartungsverträge gespart wird) und Du versuchst jetzt verzweifelt, mit Halbwissen am Fehler vorbeizuscripten.
Wenn dem nur so wäre. An SW läuft neben dem Virenscanner, ein ERP System und Office O365 auf den Rechnern. Bei manchen noch ein Programm zu Zeiterfassung oder CAD-Programm oder ähnliches. Aber auch diese Programme können dafür nicht ursächlich sein, denn der Fehler tritt auch auf Rechnern auf wo nur das ERP und O365 installiert ist. Aber auch hier tritt es halt nicht bei allen Rechner auf.
Ich kann mir vorstellen, dass so etwas Frust erzeugt. Letztendlich gibt es aber keine andere Lösung.
Frust erzeugt bei mir nicht das Problem, sondern dass mein Eingangspost offenbar nicht in Gänze gelesen wird. Ja auch von dir. Sonst hättest du nicht geschrieben, dass ich versuche an etwas vorbeizuskripten. Wenn du dich auf das ursprüngliche Skript beziehst, welches ich in meinem Eingangsposting erwähnt habe: Da ging es um die Auswertung von einem Anmeldefehler am DC.Gruß und schönes Wochenende
Doskias
Hallo,
sry - ich hatte tatsächlich zuerst den einleitenden Satz "Wir haben in unregelmäßigen Abständen ein auftretendes Problem" gelesen und war davon ausgegangen, dass das auslösende Problem noch besteht.
Falls dem nicht so ist - mea culpa. In dem Fall habe ich Dich tatsächlich falsch verstanden, sry. Vergiss, was ich geschrieben habe.
Gruß,
Jörg
sry - ich hatte tatsächlich zuerst den einleitenden Satz "Wir haben in unregelmäßigen Abständen ein auftretendes Problem" gelesen und war davon ausgegangen, dass das auslösende Problem noch besteht.
Falls dem nicht so ist - mea culpa. In dem Fall habe ich Dich tatsächlich falsch verstanden, sry. Vergiss, was ich geschrieben habe.
Gruß,
Jörg
Hallo,
Deinen Text und die Verknüpfung auf das andere Thread habe ich jetzt 4xgelesen, und ich bin mir immer noch nicht sicher, worum es geht. Sorry. Ich glaube folgendes verstanden zu haben:
Für das Systemkonto wird ein Laufwerk gemappt, das aber für das Systemkonto nicht gedacht ist, und wegen fehlender Zugriffsrechte? entsteht ein Fehler.
Wenn man das Laufwerk unter dem Systembenutzer (per psexec) löscht, ist es bald wieder da.
Ich würde da spontan auf eine GPO/GPP tippen. Da Du das sicher schon überprüft hast, würde ich nochmal speziell folgende Fehler ausschließen:
Zweite Ursache für das Wiederauftauchen nach Löschung kann der Taskplaner sein. Dort würde ich die Aufgaben überprüfen .
Grüße
lcer
Deinen Text und die Verknüpfung auf das andere Thread habe ich jetzt 4xgelesen, und ich bin mir immer noch nicht sicher, worum es geht. Sorry. Ich glaube folgendes verstanden zu haben:
Für das Systemkonto wird ein Laufwerk gemappt, das aber für das Systemkonto nicht gedacht ist, und wegen fehlender Zugriffsrechte? entsteht ein Fehler.
Wenn man das Laufwerk unter dem Systembenutzer (per psexec) löscht, ist es bald wieder da.
Ich würde da spontan auf eine GPO/GPP tippen. Da Du das sicher schon überprüft hast, würde ich nochmal speziell folgende Fehler ausschließen:
- Werden die Gruppenrichtlinienobjekte auch wie erwartet angewendet? (rsop.msc/GPResult vs Gruppenrichtlinienmodellierung)
- Du solltest auch nachschauen, ob irgendwo Loopback-Processing aktiviert ist und auf die betroffenen PCs wirkt.
- Sind in den lokalen Gruppenrichtlineinobjekte lustige Dinge definiert? -> secpol.msc
Zweite Ursache für das Wiederauftauchen nach Löschung kann der Taskplaner sein. Dort würde ich die Aufgaben überprüfen
.Grüße
lcer
Zitat von @117471:
Hallo,
sry - ich hatte tatsächlich zuerst den einleitenden Satz "Wir haben in unregelmäßigen Abständen ein auftretendes Problem" gelesen und war davon ausgegangen, dass das auslösende Problem noch besteht.
Genau. Das war die Ursache des Skriptes, wo der Initial-Drive-Fehler aufgetreten ist. Das Event 8021 tritt bei einem Mehrfach vernetztem Hauptsuchdienst auf. Das haben wir identifizieren können. Ursache hierfür ist ein Update, welches laut WSUS keinen Neustart braucht und sofort installiert werden kann. In Wirklichkeit wartet der Fileserver aber auf einen Neustart und das Mapping funktioniert dann sporadisch nicht. Lösung an der Stelle: Die Client-Protokolle täglich abfragen ob der Fall auftritt, damit ich weiß ob der Fehler auftritt ohne das User sich melden und einen Neustart des File-Servers initiieren. Ja auch hier: Merkwürdiges verhalten beim Mapping. Hier hab ich tatsächlich ein Skript laufen, allerdings nicht um den Fehler zu beseitigen, sondern um den Fehler zu entdecken.Hallo,
sry - ich hatte tatsächlich zuerst den einleitenden Satz "Wir haben in unregelmäßigen Abständen ein auftretendes Problem" gelesen und war davon ausgegangen, dass das auslösende Problem noch besteht.
Falls dem nicht so ist - mea culpa. In dem Fall habe ich Dich tatsächlich falsch verstanden, sry. Vergiss, was ich geschrieben habe.
Kein Problem. Man kann alles lösen, wenn man drüber redet/schreibt ;)Gruß
Doskias
Moin
Es werden keine Objekte wie Secpol definiert. Es werden Drucker, Laufwerke gemappt, so wie Edge-Einstellungen vorgegeben. Wir sperren Wechselmedien via GPO, aber das kann eigentlich nicht das Problem sein.
1. Die genutzten UNC Pfade in den Aufgaben des Taskplaner passen nicht zu den fehlerhaften Laufwerken.
2. Der Fehler tritt nicht bei allen Rechnern auf. Ich habe mehrere Rechner die exakt die gleichen GPOs verwenden an dem sich die User mit exakt den gleichen Rechten anmelden. Es ist alles identisch bis hin zum Netzwerkdrucker. EInige Rechner haben das Problem, andere nicht.
3. Ich habe bislang mehrere (insgesamt jetzt 3) Netzwerkpfade identifizieren können, die unter dem Systemkonto gemappt sind. Dabei sind es allerdings stets Netzwerkpfade auf denen der angemeldete User Zugriff hat. Bei mir selbst zum Beispiel wurde heute das Laufwerk mit unseren Admin-Tools unter dem Systemkonto gemappt. Diese Freigabe ist bislang bei keinem andren Rechner (auch bei anderen Admins) aufgetreten.
Ich hatte schon überlegt ob die GPO zum Mappen der Netzlaufwerke im Hintergrund ursächlichd afür ist und mit den Optionen Ersetzem, Erstellen, Aktuallisieren herumgespielt. Das Verhalten bleibt allerdings identisch. Es ist auch so, dass bei uns alle Mitarbeiter 3-Standard Netzlaufwerke bekommen. Es wird stets nur eins davon als System fehlerhaft gemappt. Neben zwei von diesen 3 Laufwerken ist es das eben schon erwähnte Admin-Laufwerk was heute zum ersten mal aufgetreten ist.
Gruß
Doskias
Zitat von @lcer00:
Deinen Text und die Verknüpfung auf das andere Thread habe ich jetzt 4xgelesen, und ich bin mir immer noch nicht sicher, worum es geht. Sorry.
Ja ist schwer zu verstehen.Deinen Text und die Verknüpfung auf das andere Thread habe ich jetzt 4xgelesen, und ich bin mir immer noch nicht sicher, worum es geht. Sorry.
Ich glaube folgendes verstanden zu haben:
Für das Systemkonto wird ein Laufwerk gemappt, das aber für das Systemkonto nicht gedacht ist, und wegen fehlender Zugriffsrechte? entsteht ein Fehler.
Wenn man das Laufwerk unter dem Systembenutzer (per psexec) löscht, ist es bald wieder da.
Genau. Nach Recherchen soll die auftreten, wenn das Laufwerk versucht wird zu mappen, obwohl es schon da ist. Es gibt aber keine 2 GPos die Laufwerke mappen und auch kein Skript, welches das macht. Ich habe also (wissentlich) keine doppelten MappingsFür das Systemkonto wird ein Laufwerk gemappt, das aber für das Systemkonto nicht gedacht ist, und wegen fehlender Zugriffsrechte? entsteht ein Fehler.
Wenn man das Laufwerk unter dem Systembenutzer (per psexec) löscht, ist es bald wieder da.
Ich würde da spontan auf eine GPO/GPP tippen. Da Du das sicher schon überprüft hast, würde ich nochmal speziell folgende Fehler ausschließen:
GPO habe ich auch unter verdacht, weiß aber nicht wo ich noch bei der Suche ansetzen soll.* Werden die Gruppenrichtlinienobjekte auch wie erwartet angewendet? (rsop.msc/GPResult vs Gruppenrichtlinienmodellierung)
Ja werden Sie. Auf den entsprechenden Rechenrn werden exakt nur die GPOs angewandt, die sollen* Du solltest auch nachschauen, ob irgendwo Loopback-Processing aktiviert ist und auf die betroffenen PCs wirkt.
Nein Loopback ist nicht aktiviert. War es noch nie und sicherheitshalber habe ich bei einem anderen Problem den Loopback schonmal deaktiviert.* Sind in den lokalen Gruppenrichtlineinobjekte lustige Dinge definiert? -> secpol.msc
Nein nur ernste Dinge. Es werden keine Objekte wie Secpol definiert. Es werden Drucker, Laufwerke gemappt, so wie Edge-Einstellungen vorgegeben. Wir sperren Wechselmedien via GPO, aber das kann eigentlich nicht das Problem sein.Zweite Ursache für das Wiederauftauchen nach Löschung kann der Taskplaner sein. Dort würde ich die Aufgaben überprüfen .
Auch hier weiß ich nicht wo ich ansetzen soll. Natürlich habe ich die selbst erstellten Tasks geprüft. Diese werden alle via GPO verteilt. Hier werden gelegentlich UNC Pfade genutzt aber: .1. Die genutzten UNC Pfade in den Aufgaben des Taskplaner passen nicht zu den fehlerhaften Laufwerken.
2. Der Fehler tritt nicht bei allen Rechnern auf. Ich habe mehrere Rechner die exakt die gleichen GPOs verwenden an dem sich die User mit exakt den gleichen Rechten anmelden. Es ist alles identisch bis hin zum Netzwerkdrucker. EInige Rechner haben das Problem, andere nicht.
3. Ich habe bislang mehrere (insgesamt jetzt 3) Netzwerkpfade identifizieren können, die unter dem Systemkonto gemappt sind. Dabei sind es allerdings stets Netzwerkpfade auf denen der angemeldete User Zugriff hat. Bei mir selbst zum Beispiel wurde heute das Laufwerk mit unseren Admin-Tools unter dem Systemkonto gemappt. Diese Freigabe ist bislang bei keinem andren Rechner (auch bei anderen Admins) aufgetreten.
Ich hatte schon überlegt ob die GPO zum Mappen der Netzlaufwerke im Hintergrund ursächlichd afür ist und mit den Optionen Ersetzem, Erstellen, Aktuallisieren herumgespielt. Das Verhalten bleibt allerdings identisch. Es ist auch so, dass bei uns alle Mitarbeiter 3-Standard Netzlaufwerke bekommen. Es wird stets nur eins davon als System fehlerhaft gemappt. Neben zwei von diesen 3 Laufwerken ist es das eben schon erwähnte Admin-Laufwerk was heute zum ersten mal aufgetreten ist.
Gruß
Doskias
Zitat von @Doskias:
Es werden keine Objekte wie Secpol definiert. Es werden Drucker, Laufwerke gemappt, so wie Edge-Einstellungen vorgegeben. Wir sperren Wechselmedien via GPO, aber das kann eigentlich nicht das Problem sein.
Ich meine nicht die AD-Gruppenrichtlinien sondern die lokalen, die man ansehen kann, wenn man secpol.msc ausführt. Das sind nicht die GPOs vom DC.* Sind in den lokalen Gruppenrichtlineinobjekte lustige Dinge definiert? -> secpol.msc
Nein nur ernste Dinge. Es werden keine Objekte wie Secpol definiert. Es werden Drucker, Laufwerke gemappt, so wie Edge-Einstellungen vorgegeben. Wir sperren Wechselmedien via GPO, aber das kann eigentlich nicht das Problem sein.Grüße
lcer
Hallo,
derartige Probleme kenne ich tatsächlich auch. In dem Zustand (Updates eingespielt, kein Neustart erfolgt weil eigentlich keiner erforderlich) hängen sich auch gerne mal VSS Writer weg.
Gruß,
Jörg
derartige Probleme kenne ich tatsächlich auch. In dem Zustand (Updates eingespielt, kein Neustart erfolgt weil eigentlich keiner erforderlich) hängen sich auch gerne mal VSS Writer weg.
Gruß,
Jörg
Genau. Und dazu war das Ursprüngliche SKript, was tzäglich einmal an allen Clients die Logs durchgeht und nach der 8021 sucht. Das Skript funktioniet natürlich auch mit dem Fehler, aber ich empfinde es als gewisse Berufsehre der Sache auf den Grund zu gehen und den Fehler zu beseitigen anstatt es zu ignorieren. Irgendeinen Grund muss es ja haben.
PS: Neustart des File-Servers hat in dem Zusammenhang übrigens auch keine Änderung bewirkt
PS: Neustart des File-Servers hat in dem Zusammenhang übrigens auch keine Änderung bewirkt
Achso an die hatte ich jetzt garnicht gedacht, weil wir an der secpol.msc nichts lokal einstellen. Höchstens altlasten auf Windows 8, aber da die nach und nach auf Windows 10 migriert werden (saubere Neuinstallation, kein Upgrade), interessiert mich das PRoblem eigentlich nur bei Windows 10. Und an den Windows 10 wird alles ausschließlichj per GPO verteilt.
Hallo,
Grüße
lcer
Zitat von @Doskias:
Achso an die hatte ich jetzt garnicht gedacht, weil wir an der secpol.msc nichts lokal einstellen. Höchstens altlasten auf Windows 8, aber da die nach und nach auf Windows 10 migriert werden (saubere Neuinstallation, kein Upgrade), interessiert mich das PRoblem eigentlich nur bei Windows 10. Und an den Windows 10 wird alles ausschließlichj per GPO verteilt.
na ja, wenn alles korrekt nach Vorschrift funktionieren würde, gäbe es ja auch kein Problem - oder?Achso an die hatte ich jetzt garnicht gedacht, weil wir an der secpol.msc nichts lokal einstellen. Höchstens altlasten auf Windows 8, aber da die nach und nach auf Windows 10 migriert werden (saubere Neuinstallation, kein Upgrade), interessiert mich das PRoblem eigentlich nur bei Windows 10. Und an den Windows 10 wird alles ausschließlichj per GPO verteilt.
Grüße
lcer
Also in den lokalen Guppenrichtlinien konnte ich nichts entdecken. Ich habe nun die Einstellungen von meinem Rechner (heute kein Fehler), mit einem W8 und einem W10 verglichen. Einträge sind identisch. Allerdings ist mir auf dem Windows 8 Rechner folgendes aufgefallen. Der Fehler war da und ich habe via geplanten Task, einen Task als System ausführen lassen, der das eine Laufwerk entfernt hat. Das hat funktioniert. Um 7:52 war das Netzlaufwerk gelöscht, um 08:00 Uhr immer noch und um 8:11 Uhr war es wieder da. Die Logs sind an der Stelle unauffällig. Wie bisher: Keine critical, kein Error, kein Warning. Nur Informationen. Vergleiche ich diese Informationen mit einem Rechner wo es nicht auftritt, sind auch hier keine Auffälligkeiten zu finden. Es gibt zwar das Event 4634 welches ich zunächst in Verdacht hatte, denn dort steht
allerdings habe ich die Meldung an Rechner mit und ohne dem Fehler. Darüber hinaus greift das Konto (Dienstkonto für den Update des Virenscanners) auf kein Netzlaufwerk zu. Also habe ich weitere Versucht unternommen es weiter einzugrenzen, dabei habe ich einfach die ersten 5 Rechner genommen, bei dem ich unverbundene Netzlaufwerke gefunden habe und wollte wie beschrieben mittels geplanten Task die Laufwerke löschen. Das hat den Vorteil, dass der Virenscanner nicht meckert. Allerdings war bei den 5 Rechnern nun 2 Windows 8 und 3 Windows 10 Rechner dabei. Folgendes Ergebnis
2 von 2 Windows 8 erlaubten mir den geplanten Task einzurichten
1 von 3 Windows 10 Rechnern erlaubte mir den geplanten Task einzurichten
Die 2 wo das Einrichten des Tasks nicht gelang, sagten:
Das hat mich in sofern verwundert, da es Windows 10 ist. Bei der Einrichtung des geplanten Task kann ich unter Konfigurieren für auf besagten Windows 10 Rechner nur "Windows Server 2003, Windows XP oder Windows 2000" eingeben. Dies erklärt zwar die Fehlermeldung, wieso ich in der Auswahl allerdings so eingeschränkt bin verstehe ich nicht. Die alle 3 Windows 10 Rechner stammen vom gleichen Image und sind über den WSUS auf dem gleichen Patchstand. Wieso kann ich bei einigen davon nicht alle Option ausführen. Zum Vergleich:
Auswahl bei Rechner mit oben genannter Fehlermeldung:
Auswahl bei rechnern ohne oben genannter Fehlermeldung:
Allerdings habe ich auch Rechner mit dem nicht verbundenen Netzlaufwerk, bei dem ich alle 3 Auswahloptionen habe. Hier kann, aber muss meiner Einschätzung nach auch kein Zusammenhang bestehen. Verteile ich über eine GPO allerdings eine sofort auszuführende Aufgabe, in der ich das Skript (liegt lokal) zum löschen der Netzlaufwerke unter System ausführe, dann wird dieses Aufgabe und das Skript problemlos verarbeitet, wobei ich hier nochmal andere Auswahloptionen habe:
Den Rechner von heute morgen habe ich zwischendurch noch einmal das Laufwerk entfernt. Um 11:26 wurde es gelöscht und zwischen 12:20 Uhr und 12:25 kam es dann wieder. Das Event 4634 ist jedoch auch zwischen 11:26 und 12:20 aufgetreten, ohne dass das Netzlaufwerk falsch gemappt wurde. Auch die GP-Aktualisierung kann ich ausschließen. Diese ist zwischen 8:00 Uhr und 8:11 Uhr und 12:20 und 12:25 jeweils nicht erfolgt.
So langsam gehen mir die Anhaltspunkte für weitere Recherchen aus. Vielleicht hat einer von euch noch einen Tipp, eine Idee (egal wie abwegig sie scheinen mag) oder einen Link zu einem änlichen Problem. Zu gepostet Meldung aus der Aufgabenplanung unter Windows 10 bin ich in Google nicht fündig geworden.
Gruß
Doskias
Dieses Ereignis wird generiert, wenn eine Anmeldesitzung zerstört wird. Es kann anhand des Wertes der Anmelde-ID positiv mit einem Anmeldeereignis korreliert werden. Anmelde-IDs sind nur zwischen Neustarts auf demselben Computer eindeutig.
allerdings habe ich die Meldung an Rechner mit und ohne dem Fehler. Darüber hinaus greift das Konto (Dienstkonto für den Update des Virenscanners) auf kein Netzlaufwerk zu. Also habe ich weitere Versucht unternommen es weiter einzugrenzen, dabei habe ich einfach die ersten 5 Rechner genommen, bei dem ich unverbundene Netzlaufwerke gefunden habe und wollte wie beschrieben mittels geplanten Task die Laufwerke löschen. Das hat den Vorteil, dass der Virenscanner nicht meckert. Allerdings war bei den 5 Rechnern nun 2 Windows 8 und 3 Windows 10 Rechner dabei. Folgendes Ergebnis
2 von 2 Windows 8 erlaubten mir den geplanten Task einzurichten
1 von 3 Windows 10 Rechnern erlaubte mir den geplanten Task einzurichten
Die 2 wo das Einrichten des Tasks nicht gelang, sagten:
Das hat mich in sofern verwundert, da es Windows 10 ist. Bei der Einrichtung des geplanten Task kann ich unter Konfigurieren für auf besagten Windows 10 Rechner nur "Windows Server 2003, Windows XP oder Windows 2000" eingeben. Dies erklärt zwar die Fehlermeldung, wieso ich in der Auswahl allerdings so eingeschränkt bin verstehe ich nicht. Die alle 3 Windows 10 Rechner stammen vom gleichen Image und sind über den WSUS auf dem gleichen Patchstand. Wieso kann ich bei einigen davon nicht alle Option ausführen. Zum Vergleich:
Auswahl bei Rechner mit oben genannter Fehlermeldung:
Auswahl bei rechnern ohne oben genannter Fehlermeldung:
Allerdings habe ich auch Rechner mit dem nicht verbundenen Netzlaufwerk, bei dem ich alle 3 Auswahloptionen habe. Hier kann, aber muss meiner Einschätzung nach auch kein Zusammenhang bestehen. Verteile ich über eine GPO allerdings eine sofort auszuführende Aufgabe, in der ich das Skript (liegt lokal) zum löschen der Netzlaufwerke unter System ausführe, dann wird dieses Aufgabe und das Skript problemlos verarbeitet, wobei ich hier nochmal andere Auswahloptionen habe:
Den Rechner von heute morgen habe ich zwischendurch noch einmal das Laufwerk entfernt. Um 11:26 wurde es gelöscht und zwischen 12:20 Uhr und 12:25 kam es dann wieder. Das Event 4634 ist jedoch auch zwischen 11:26 und 12:20 aufgetreten, ohne dass das Netzlaufwerk falsch gemappt wurde. Auch die GP-Aktualisierung kann ich ausschließen. Diese ist zwischen 8:00 Uhr und 8:11 Uhr und 12:20 und 12:25 jeweils nicht erfolgt.
So langsam gehen mir die Anhaltspunkte für weitere Recherchen aus. Vielleicht hat einer von euch noch einen Tipp, eine Idee (egal wie abwegig sie scheinen mag) oder einen Link zu einem änlichen Problem. Zu gepostet Meldung aus der Aufgabenplanung unter Windows 10 bin ich in Google nicht fündig geworden.
Gruß
Doskias
So, da keine andere Antwortkette wirklich dazu passt. mach ich einfach mal eine neue Kette auf. @117471 hat irgendwo hier geschrieben, dass er vermutet, dass wir eine Software gekauft haben und ich versuche am Fehler vorbei zu skripten. Ich habe jetzt vermutlich die Ursache gefunden, die dazu führt das Netzlaufwerke gemappt werden und es zu dem Fehler
Und es scheint sich dabei tatsächlich um eine durch eine Software ausgelöste Auffälligkeit zu handeln. Ursächlich dafür ist offenbar ein Programm namens Excel. Klingt komisch ist aber so. Meine Analyse hat bislang folgenden ergeben:
Wenn eine Excel-Datei von einem Netzlaufwerk geöffnet wird, dann wird das Laufwerk manchmal (nicht immer) unter dem System erneut gemappt, ist aber nicht bereit. Wird Excel geschlossen bleibt die Verknüpfung. Ich konnte dieses Verhalten nun soweit eingrenzen, dass wenn ich eine Excel-Datei öffne, in etwa 1/3 der Fälle das Netzlaufwerk als System gemappt wird. In den anderen 2/3 der Fälle passiert einfach gar nichts. Es ist dabei auch völlig egal ob es eine Excel-Datei mit Mako ist oder nicht und ob es 30 Zeilen, 130 oder 200 sind. Ich kann auch 5 mal die gleiche Datei öffnen und dabei wird dann das Laufwerk dann 1 oder 2 mal gemappt. Das war zumindest meine Theorie, da wir viel mit Excel auf den Netzlaufwerken arbeiten. In einem exzessiven Test habe ich dann wahllos Dateien geöffnet und mir nach jedem öffnen die gemappten Laufwerke anzeigen lassen. Wenn ein Mapping stattgefunden hat, habe ich die Laufwerke gelöscht und den Test wiederholt.
Das Ergebnis Beim öffnen von Excel, Word oder PDF-Dateien tritt das Verhalten gelegentlich, aber nicht immer auf. Bei Video oder Bilddateien konnte das Verhalten bislang nicht reproduziert werden. Meine Anwender bestätigen mir, dass Sie "vor kurzem" eine der betroffenen Dateitypen von dem jeweils bei Ihnen angezeigten Netzlaufwerk geöffnet haben. Bislang konnte ich noch kein gemapptes Laufwerk finden in dessen zeitlicher Nähe nicht auch eine Datei vom Netzlaufwerk geöffnet wurde. Wieso und weshalb dieses Mapping nötig ist, kann ich nicht beurteilen. Vielleicht kann einer der Mitlesenden das Verhalten ja an seinem Rechner bestätigen. Ich habe dafür folgendes Skript vom DC ausgeführt (da ich nicht immer das Kennwort eingeben wollte):
Wenn die ersten Abfragen ein Netzlaufwerk als isready=False identifizieren und es mit net use nicht angezeigt wurde, dann habe ich es (mittels geplanten Task und/oder PSEXEC) gelöscht und den Test wiederholt.
Für mich ist die Sache durch. ich werde in das Thema keine weitere Zeit investieren.
Gruß
Doskias
Fehler beim Ausführen des InitializeDefaultDrives-Vorgangs für den Anbieter "FileSystem".
kommt.Und es scheint sich dabei tatsächlich um eine durch eine Software ausgelöste Auffälligkeit zu handeln. Ursächlich dafür ist offenbar ein Programm namens Excel. Klingt komisch ist aber so. Meine Analyse hat bislang folgenden ergeben:
Wenn eine Excel-Datei von einem Netzlaufwerk geöffnet wird, dann wird das Laufwerk manchmal (nicht immer) unter dem System erneut gemappt, ist aber nicht bereit. Wird Excel geschlossen bleibt die Verknüpfung. Ich konnte dieses Verhalten nun soweit eingrenzen, dass wenn ich eine Excel-Datei öffne, in etwa 1/3 der Fälle das Netzlaufwerk als System gemappt wird. In den anderen 2/3 der Fälle passiert einfach gar nichts. Es ist dabei auch völlig egal ob es eine Excel-Datei mit Mako ist oder nicht und ob es 30 Zeilen, 130 oder 200 sind. Ich kann auch 5 mal die gleiche Datei öffnen und dabei wird dann das Laufwerk dann 1 oder 2 mal gemappt. Das war zumindest meine Theorie, da wir viel mit Excel auf den Netzlaufwerken arbeiten. In einem exzessiven Test habe ich dann wahllos Dateien geöffnet und mir nach jedem öffnen die gemappten Laufwerke anzeigen lassen. Wenn ein Mapping stattgefunden hat, habe ich die Laufwerke gelöscht und den Test wiederholt.
Das Ergebnis Beim öffnen von Excel, Word oder PDF-Dateien tritt das Verhalten gelegentlich, aber nicht immer auf. Bei Video oder Bilddateien konnte das Verhalten bislang nicht reproduziert werden. Meine Anwender bestätigen mir, dass Sie "vor kurzem" eine der betroffenen Dateitypen von dem jeweils bei Ihnen angezeigten Netzlaufwerk geöffnet haben. Bislang konnte ich noch kein gemapptes Laufwerk finden in dessen zeitlicher Nähe nicht auch eine Datei vom Netzlaufwerk geöffnet wurde. Wieso und weshalb dieses Mapping nötig ist, kann ich nicht beurteilen. Vielleicht kann einer der Mitlesenden das Verhalten ja an seinem Rechner bestätigen. Ich habe dafür folgendes Skript vom DC ausgeführt (da ich nicht immer das Kennwort eingeben wollte):
invoke-command [Zielrechner]{
Get-PSDrive -PSProvider FileSystem
[System.IO.DriveInfo]::GetDrives() | Format-Table
Get-CimInstance -Class Win32_LogicalDisk
get-CimInstance -Class Win32_NetworkConnection
net use}Wenn die ersten Abfragen ein Netzlaufwerk als isready=False identifizieren und es mit net use nicht angezeigt wurde, dann habe ich es (mittels geplanten Task und/oder PSEXEC) gelöscht und den Test wiederholt.
Für mich ist die Sache durch. ich werde in das Thema keine weitere Zeit investieren.
Gruß
Doskias
Hallo,
Grüße
lcer
Für mich ist die Sache durch. ich werde in das Thema keine weitere Zeit investieren.
Gruß
Doskias
Spannend. Danke jedenfalls für den ausführlichen Post.Gruß
Doskias
Grüße
lcer
Hallo,
Fast
Ich habe versucht dich dazu zu motivieren, auf die Ursache zu schauen. Und letztendlich scheint das ja auch irgendwie zielführend gewesen zu sein - oder?
Gruß,
Jörg
Zitat von @Doskias:
@117471 hat irgendwo hier geschrieben, dass er vermutet, dass wir eine Software gekauft haben und ich versuche am Fehler vorbei zu skripten.
@117471 hat irgendwo hier geschrieben, dass er vermutet, dass wir eine Software gekauft haben und ich versuche am Fehler vorbei zu skripten.
Fast
Ich habe versucht dich dazu zu motivieren, auf die Ursache zu schauen. Und letztendlich scheint das ja auch irgendwie zielführend gewesen zu sein - oder?
Gruß,
Jörg
Hmm Ansichtssache. Da die Motivation die Ursache zu beseitigen von Anfang an da war, nur so zum Teil
