Danke für die vielen Antworten! :) Zunächst die gute Nachricht: Das Problem ist gelöst. Nun aber die schlechte Nachricht: Die Ursache ist unklar. Wie wurde das Problem gelöst? Ich habe den entsprechenden Windows-Benutzer gelöscht und neu eingerichtet (ich hatte ja nichts zu verlieren). Und plötzlich hat das Powershell User Logon Script Netzlaufwerke gefunden, konnte fehlende Netzlaufwerke persistent mounten, usw. Offenbar haben meine vielen Tests irgendetwas bei diesem Benutzer kaputt gemacht. In der Registry konnte ich z.B. unter HKCU\Network die Netzlaufwerke sehen, aber trotzdem waren sie für das User Logon Script "unsichtbar". Das galt inzwischen übrigens für *alle* Logon Scripte, also auch für die VB-Variante, die ja mal funktioniert hatte... Alles sehr merkwürdig, aber jetzt funktioniert es zum Glück. Einen Benutzer zu löschen und neu einzurichten kann in Zukunft natürlich nicht die erste Wahl sein... Nachfolgend antworte ich noch auf eure Vorschläge/Nachfragen.
Diese Einstellung finde ich hier nicht im Editor für lokale Gruppenrichtlinien unter Windows 10 Pro. Gibt es das nur im Windows Server oder suche ich an der falschen Stelle? Ich habe aber mal ausprobiert, ob es einen Unterschied macht, wenn ich "Start-Sleep -s 30" in mein Powershell Script einbaue – leider nicht, die Netzlaufwerke wurden dann zwar erst später gesucht, aber konnten trotzdem nicht gefunden werden.
Danke, das waren gute Anregungen. Im Powershell-Script konnte "net use" auch keine Netzlaufwerke sehen. Dann habe ich aus lauter Verzweiflung nochmal mein (als funktionierend bekanntes) VB-Script herausgekramt und – siehe da – auch damit hat es nicht mehr funktioniert. Das hat mich auf die richtige Spur geführt (siehe oben)...
Hier kommt FreeNAS zum Einsatz (also effektiv Samba für die Windows-Clients). Eine zentrale Userverwaltung gibt es bereits, das FreeNAS/Samba ist an einen LDAP-Server angebunden. Nur wird der bewusst nicht für die Windows-Clients verwendet. Ciao - fraenki