Keine Netzlaufwerke mehr unter Windows 8.1 seit kurzer Zeit

[Sunny61 809]

Bei den W10 Rechnern ist UAC an- oder abgeschaltet? Kannst Du mal testweise Netzlaufwerke mit GPP auf einem W10 mounten lassen? Funktioniert das auch im Adminkontext? Gibt es bei den Benutzern evtl. einen Kartenleser, der jetzt die Buchstaben in Anspruch nimmt?

[Wisi 12]

Ich werde mir den Spaß auch mal bei der 8.1 Version machen:

 

- zuerst mal ohne UAC (ich erwarte, dass das dann problemlos funktioniert)

- Zuweisung via GPP mit UAC an (erwarte, dass auch das funktioniert)

- ein Update nach dem anderen aus Oktober deinstallieren (darauf deutet es ja derzeit hin)

 

Dann müsste ja irgendein Ergebnis raus kommen und wir wissen was noch geht und was nicht und v.a. was es auslöst.

 

Aber gut, dass wir jetzt schon mal einen Ansatz haben und dass auch noch jemand anders seit den Oktober Updates Probleme hat.

[ZoppoTrump 0]

Update: Bei uns betrifft das "nur" DFS Shares.

 

Hier eine Beschreibung in EN, wie das funtkioniert mit dem EnableLinkedConnections:

 

After you enable EnableLinkedConnections parameter of the registry, LanmanWorkstation and LSA will check if there is the second access token associated to the session of the current user. If this token is found, the list of the mounted network drives will be copied from one token to another. Thus, the network drives mounted elevated will be seen in the standard mode, and vice versa.

[Wisi 12]

Das war mir soweit eigentlich schon klar was da passiert. Frage ist nur, warum funktioniert es jetzt NICHT mehr...

[Wisi 12]

So, das erste Update ist schon mal gefunden: KB3192392. Allerdings ist es das wohl nicht alleine. Bei mir ist das Problem vorhanden sobald installiert und weg nachdem deinstalliert. Beim Kollegen ist das Problem aber nach Deinstallation noch vorhanden.

 

Edit: da gibts mit dem Update derzeit wohl auch noch deutlich mehr Probleme, siehe http://www.borncity.com/blog/tag/kb3192392/

Edit2: auch das andere Update KB3185331 was dort genannt wird, erzeugt das Problem

 

Fazit für mich: die beiden Updates sind derzeit nicht zu empfehlen. Jedes von den beiden für sich alleine reicht um das Problem hervorzurufen. Test beim Kollegen ebenso erfolgreich abgeschlossen. Die beiden runter und alles passt.

 

Edit3: Unter Windows 7 installieren wir das entsprechende KB3192391 aber - ohne Probleme. KB31292393 wiederum unter 2012 genau das gleiche Thema wie unter 8.1 (war aber fast zu erwarten).

 

Edit4: Nachdem ich schon dabei bin: KB3192403 für Windows 7 geht, KB3192404 und KB3192406 selbes Spiel -> Finger weg

bearbeitet 25. Oktober 2016 von Wisi

[Wisi 12]

Puh, ganz toll, das nächste Update, welches den Fehler hervorruft (eigentlich klar, weil kumulativ). Hatte gehofft Microsoft hätte das in der Zwischenzeit geklärt.

 

Dann mal die Frage: wo genau kann ich das eigentlich melden, bisher sind die Fehler immer von selbst behoben worden oder das Update wurde sowieso zurückgezogen...

 

Betroffenes Update bei uns: November 2016 – monatliches Sicherheitsqualitätsrollup für Windows 8.1 für x64-basierte Systeme (KB3197874)

[Wisi 12]

Wie zu erwarten: auch im Dezember Update kein Fix. Wann endlich wird das gefixt?

[lefg 276]

Moin,

 

wurde schon einmal erwogen, mit der Systemwiederherstellung zurück vor den Updates?

 

Wurde erwogen, Netzlaufwerke neu zu verbinden mit dem Explorer rechte Maustaste auf Netzwerk?

 

Edit Ich möchte niemanden W10 aufschwatzen, gibt es für die Verwendung von W7 und 8 besonderen Gründ? Spricht etwas dafür und gegen W10?

bearbeitet 15. Dezember 2016 von lefg

[Wisi 12]

Hallo,

 

ich teste das ja auf meinem Client zuerst. Das Problem tritt übrigens auch auf 10/2012 R2 auf. Da stört es mich aktuell nur nicht, weil keine Arbeitsworkstation bei uns damit vorhanden ist. Insofern also auch keine Lösung.

Es lässt sich ohne Systemwiederherstellung ganz einfach lösen indem man die Patches deinstalliert, soweit funktioniert der Prozess zumindest sauber.

 

Problem dabei: da es kumulativ ist, fehlen dir zig Updates in der Zwischenzeit, weil du ja nicht den einen Problempatch rausnehmen kannst wie früher.

[lefg 276]

Nun, die Systemwiederherstellung wäre ein Experiment, gäbe es eine Bestätigung, könnte man erneut Updates durchführen. Ich verstehe aber, im Job gibt es keine Zeit für solche Experimente, der Ausgang wäre auch unbestimmt.

 

Wie ist es denn aber mit dem Versuch, die Netzlaufwerkverbindung mit dem Explorer herzustellen? Zuvor, kommt der angemeldete User mit dem Explorer z.B. über die Netzwerkumgebung auf die Freigabe? Ist die Freigabe, ist der Server erreichbar? Kommt man glatt auf die Freigabe, in das Verzeichnis oder kommt die Aufforderung zum Eingeben von Benutzername und Kennwort? Und kommt man damit weiter?

 

Falls das Ziel also erreichbar, dann sollte das Einrichten einer Netzlaufwerkverbindung mit dem Explorer doch möglich sein und auf Skript und net use verzichten.

 

Falls auf das Zielverzeichnis nicht zugegriffen werden kann, stimmen denn da Zugriffsberechtigungen noch?

bearbeitet 15. Dezember 2016 von lefg

[Wisi 12]

Manuell kannst du alles machen. Nur beim Logon gehts halt nicht. Wenn ich dasselbe Skript noch mal ausführe, ist auch alles gut.

Schau dir mal meine Screenshots vorne an, dann siehste was passiert. Die Laufwerke werden im erhöhten UAC Kontext gemappt...

 

Und Systemwiederherstellung bringt ja nichts, weil du das alles problemlos mit den Updates "regulär" reproduzieren kannst. Ganz ohne Wiederherstellung. Patch drauf -> geht nicht. Patch deinstallieren -> geht. Auf demselben System. Mehr brauchts nicht um festzustellen, dass in den Patches ein Problem drin ist.

 

Naja, trauriges Fazit: nachdem es Microsoft nicht fertig bringt, ist die erste Handlung Anfang nächsten Jahres die Umstellung auf GPP in allen Domänen. Dafür müssen wir das ganze Anmeldethema überarbeiten. Sehen wir es positiv, die vor kurzem durchgeführte Bereinigung macht die Umstellung leichter und transparenter.

[lefg 276]

 

Manuell kannst du alles machen. Nur beim Logon gehts halt nicht. Wenn ich dasselbe Skript noch mal ausführe, ist auch alles gu

 

Dann wird die Geschichte deutlicher, da gibt es einen Klassiker, Windows ist sehr schnell bereit zum Eingeben der Benutzerdaten, die Netzwerkverbindung ist aber noch nicht fertig. Testen kann man es, indem man mit dem Einloggen wartet, ich sag mal so ein, zwei Minuten, man probiere es mal aus.

 

Abgestellt wurde das klassisch durch die Gruppenrichtlinie "Bei Neustart des Computers und bei Anmeldung immer auf das Netzwerk warten". Damit wartete Windows auf das Anmelden bis das Netzwerk verbunden war. Diese Gruppenrichtlinie wird wohl nicht mehr wirken durch eines der Updates (ich hab vergessen welches, ich komme da auch nicht mehr drauf), das Thema wurde hier am Board mehrmals abgehandelt. Mit dem Updatea wurden Berechtigungen für das Lesen Richtlinie geändert.

 

Diese Richtlinie ist global einstellbar, also domänenweit, es geht aber auch lokal im RechnerOS (gpedit).

 

Und dann gibt es noch eine Richtlinie mit HotStart oder NoHotStart, die könnte auch betroffen sein, eventuell Einfluss haben, ich weiss es nicht sicher.

 

Ich denke mal, mit den Hinweisen könntest Du weiterkommen.

bearbeitet 15. Dezember 2016 von lefg

[Wisi 12]

Hi, leider nicht dieses Problem. Dann würde das Skript ja gar nicht ausgeführt werden (das kannte ich auch schon...). Es wird aber ausgeführt und es funktioniert an sich auch. Nur wird der erhöhte Adminkontext nicht mit dem niedrigeren Userkontext verknüpft. Das ist ja der Sinn von EnableLinkedConnections.

 

Schau mal vorne in den Screenshots, dann siehst du was gemeint ist. Nach dem normalen Anmelden sind die Laufwerke ja gemappt worden, nur im falschen Kontext.

 

Wenn du die UAC abschaltest, dann hast die Laufwerke auch wieder (weil es keine verschiedenen Kontexte mehr gibt).

[lefg 276]

Ok,

 

und wie ist es, die Netzlaufwerke mittels Explorer zu verbinden und auf Skrit und net use zu verzichten?

 

Ansonsten, ob hilfreich ist http://www.windowspage.de/tipps/021296.html

bearbeitet 16. Dezember 2016 von lefg

[Wisi 12]

Statische Laufwerke halte ich für keine sinnvolle Idee in einer Umgebung mit 500 Clients ;) Wäre natürlich aber möglich.

Aber wie gesagt, wir bauen jetzt um und dann muss ich mich nicht mehr ärgern...