Keine Netzlaufwerke mehr unter Windows 8.1 seit kurzer Zeit

[Wisi 12]

Hi,

 

war heute seit einigen Tagen das erste Mal wieder im Büro und hatte plötzlich nur noch die Drucker verbunden, aber nicht mehr die Netzlaufwerke. Also dachte ich, dass irgendwas in Richtung GPO nicht mehr stimmt, also alles durchgetestet und -geschaut. Aber kein Fehler erkennbar. Und dagegen spricht auch, dass die Windows 7 Clients funktionieren wie immer. Vorteil: hab noch ein paar Dinge in Sachen Performance verbessern können (Skriptverzögerung etc.), also wenigstens nicht umsonst.

 

Dann mal die Anmeldung im Detail angeschaut und die Ereignislogs und RSOP, alles wunderbar. Wir benutzen ein Netlogon Script (ganz klassisch Batch mit net use). Wenn ich das per Hand ausführe ist auch alles gut. Also auch da kein Fehler eingeschlichen in der Zwischenzeit.

 

Kollegen gefragt: hat das gleiche Problem mit seinem 8.1 Client, also auch nicht mein Client das Problem (sind die zwei einzigen Clients mit 8.1 im Haus, Rest 7).

 

Dann ist mir das Stichwort EnableLinkedConnections noch eingefallen, also geprüft, aber das ist sowohl als GPO gesetzt, als auch verarbeitet (geprüft mit RSOP und regedit) und eingetragen.

 

Da ich schon bei dem Stichwort war, hab ich dann mal die Console mit der UAC angehoben und siehe da, in der Administrator Console sind die Laufwerke da und werden bei jeder Anmeldung einwandfrei gemappt.

Also hängt es irgendwie damit zusammen, dass das im falschen Kontext abläuft.

 

Was habe ich die letzten Tage verändert, bevor das Problem jetzt aufgetreten ist:

 

- Windows 8.1 Client Updates wurden eingespielt (habe heute auch noch manuell online geschaut nach Updates und diese eingespielt, nicht dass da noch ein Bugfix dabei ist -> nada)

- Bestehende ADMX Dateien gegen aktuellere von Windows 10 1511 ausgetauscht im Central Store (testen in virtuellen Maschinen mit Windows 10 in unserer Umgebung), die von 2016 hab ich wohl übersehen dabei, die sind ja noch neuer

- Point and Print Restrictions umgestellt, damit User die Drucker hinzufügen können und keine Meldungen bezüglich der Treiber kommen (haben ein paar neue Drucker mit neuen Treibern in die Umgebung implementiert) - die Drucker werden ebenso über die Batch mit con2prt gemappt (ich weiß alt, aber funktionierte bisher einwandfrei)

 

So und jetzt bin ich mit meinem Latein am Ende. Verstehe das Problem nicht, weiß aber zumindest was passiert und habe fast die Befürchtung, dass Microsoft irgendwas geändert hat, aber vielleicht habt ihr ja eine Idee.

 

 

bearbeitet 19. Oktober 2016 von Wisi

[tesso 360]

Wie lange hast du nach der Anmeldung gewartet?

 

Mir fällt das 5 Minuten Delay seit Windows 8.1 ein. Suche mal nach "logon script delay", kannst du mit gpo setzen.

[Wisi 12]

Hi,

 

das meinte ich mit Skriptverzögerung oben. Die Regel hatte ich vorher auf 1 Minute, jetzt ganz deaktiviert. Das ist also nicht das Problem. Lässt sich aber auch alleine deswegen schon als Problem ausschließen, weil die Drucker und Laufwerke ja da sind, also ist das Skript auch ausgeführt worden.

 

Das ist ja das Dillema: das Skript wird ausgeführt, aber trotz "EnableLinkedConnections" werden die Laufwerke im Elevated Bereich gemappt und nicht im User Kontext.

[Wisi 12]

Noch mal weiter geschaut heute, aber immer noch nichts gefunden was das auslöst. Keine nennenswerten Änderungen hier ansonsten.

Keiner von euch mehr eine weitere Idee oder Ansatzpunkt für mich?

[lefg 276]

Moin,

 

ist bekannt das GPO

 

"Bei Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten"?

 

Das ist ein Klassiker.

 

Konfigurieren entweder global am DC oder auch als lokales GPO mit dem gpedit.

 

Computerkonfiguration, Administrative Vorlagen, System, Anmelden.

[Wisi 12]

Hi, japp, und auch die synchrone Ausführung von Skripten. Wie gesagt, das Skript wird ja weiterhin völlig problemlos ausgeführt. Die Drucker sind da und auch die Netzlaufwerke, aber eben halt nur in der UAC-"Administratorumgebung".

[blub 115]

Entweder "Domain Computers" oder "Authenticated Users" müssen Read-Rechte auf das betreffende GPO-Object haben. Kontrollier das mal und zieh es ggf. gerade.

[Wisi 12]

Hi, jipp, keine Änderungen vom Standard. Sowohl der Registry Eintrag wird gesetzt, als auch das Skript ausgeführt am Client. Greifen also auch. Getestet auch schon mit RSOP, alle notwendigen GPO werden geladen und umgesetzt.

Leider... :/

[blub 115]

schau bitte am PolicyObject direkt nach!

GPO -> GPOName -> Rechte Maustaste -> Properties -> Security.

Haben dort entweder "Domain Computers" oder "Authenticated Users" das Read-Recht ?

 

Alles andere ist uninteressant. (außer das RSOP Asbach ist - https://technet.microsoft.com/en-us/library/cc772175(v=ws.11).aspx

[massaraksch 39]

Hi,

 

bau doch mal in das Batch-Sript nach dem/den "net use" ein "Pause" ein, damit du siehst, was der Befehl für eine Meldung bringt.

 

Oder Umleitung der Erfolgs/Errorausgabe in Logfile, z.B.

 

net use x: \\server\share 1> "\\server\logs\%username%.txt" 2>&1

 

Damit müßte man erstmal nachvollziehen können, ob "net use" überhaupt ausgeführt wird und was es "sagt".

bearbeitet 21. Oktober 2016 von massaraksch

[Wisi 12]

Hallo, wie gesagt, beteiligte GPO Objekte alle mit Standardeinstellungen und dort haben "Authentifizierte Benutzer" Leserechte.

 

Möglich, dass Asbach, aber erfüllte meinen Zweck, werde ich mir dennoch anschauen!

 

 

Edit: das Skript wird definitiv ausgeführt ohne Fehlermeldung, denn die Laufwerke sind ja auch da.

 

Wenn ich "cmd" als Administrator ausführe und dort "net use" schaue sind alle via Batch Datei gemappten Laufwerke da , im Benutzerkontext selbst ist nur das User Laufwerk . Sprich der net use Befehl wird aus irgendeinem Grund im Adminkontext und nicht im Benutzerkontext ausgeführt.

 

Das ist alles reproduzierbar (wenigstens etwas)! Die Drucker im gleichen Skript werden auch gezogen und sind dann im Benutzerkontext auch sichtbar.

 

Das bedeutet ja zwingend:

 

1. Er hat die Logon GPO gelesen

2. Er hat das Skript ausgeführt bei Anmeldung

 

Rahmenbedingung:

 

1. In der Registry ist EnableLinkedConnections gesetzt

2. Unter Windows 7 funktioniert das genau so alles problemlos mit demselben Benutzer

 

Zur Verdeutlichung die Bilder

bearbeitet 21. Oktober 2016 von Wisi

[ZoppoTrump 0]

Hi, ich habe ein ähnliches Problem seit dem letzten kumulativen Update KB3194798 auf Windows 10. Deinstalliere ich das Update und starte durch funktioniert es wieder.

 

--> Vielleicht einfach mal die Patches nach und nach vom Oktober 2016 entfernen.

 

[Wisi 12]

Nur interessehalber, was ist dein Problem in Windows 10?

 

Die Befürchtung hatte ich ja schon, dass es daran liegen muss, hab aber immer im Netz nichts dazu gefunden.

[ZoppoTrump 0]

Nur interessehalber, was ist dein Problem in Windows 10?

 

Die Befürchtung hatte ich ja schon, dass es daran liegen muss, hab aber immer im Netz nichts dazu gefunden.

 

Wir haben MMC´s auf Netzlaufwerken liegen. Versucht man die MMC zu öffnen, bringt diese einen Fehler, so sinngemäß falsche Version der MMC oder keine Berechtigung zum Öffnen. Wir hatten das damals schon bei Windows 7 und mit dem Regkey konnten wir das beheben. Seit dem Patch klappt das mit dem Regkey "EnableLinkedConnections" bei Windows 10 nicht mehr.

 

Kopiert man die MMC lokal, lässt sie sich öffnen.

bearbeitet 22. Oktober 2016 von ZoppoTrump

[lefg 276]

Moin

 

Wurde schon mal der letzte Wiederherstellungspunkt angeschaut?