FQDN-Pfade im klassischen Logon-Skript, ist das problemlos möglich?
Hallo.
Wir verwenden immer noch die klassischen Logon-Skripte im SYSVOL der Domäne. Ich weiß, daß es längst effektivere und elegantere Methoden gibt, Netzlaufwerke zu verbinden (per GPO z. B.), aber unsere Skripte funktionieren grundsätzlich sehr gut, und ich hatte bisher keinen Grund, diese nicht mehr zu verwenden.
Nun, infolge Corona, und damit verbunden Home-Office, zeigt sich, daß die Netzlaufwerke nur dann verbunden werden, wenn anstatt
net use X: \\server\freigabe
net use X: \\server.domaene.local\freigabe
verwendet wird, also hinsichtlich des Hostnamens des Servers, der die Freigabe trägt, der FQDN nötig ist.
Hat wahrscheinlich mit dem Tunnel zu tun, anders kann ich es mir nicht erklären. Wir stellen die VPN-Tunnel mit Hilfe von MikroTik-Appliances her, das funktioniert grundsätzlich sehr gut, es funktioniert auch alles - bis auf das Verbinden der Netzlaufwerke. Netbios-Namen nein, FQDNs ja.
Einzige Frage:
Was geschieht bei den internen Verbindungen der Rechner (die also direkt im LAN stehen, ohne VPN-Tunnel)? Kommen die damit klaglos zurecht?
Einzelne Versuche hab' ich schon damit unternommen (u. a. mit meinem eigenen Logon-Skript), da war alles in Ordnung, ich will bloß sichergehen, daß danach nicht doch irgendwo irgendeine böse Überraschung auf mich wartet, denn mitunter werden über diese Netzlaufwerke auch verschiedenste Programme gestartet, die ich jetzt nicht alle sogleich testen kann.
Hat jemand eine Idee dazu oder Erfahrung damit?
Vielen Dank.
Viele Grüße
von
departure69
Wir verwenden immer noch die klassischen Logon-Skripte im SYSVOL der Domäne. Ich weiß, daß es längst effektivere und elegantere Methoden gibt, Netzlaufwerke zu verbinden (per GPO z. B.), aber unsere Skripte funktionieren grundsätzlich sehr gut, und ich hatte bisher keinen Grund, diese nicht mehr zu verwenden.
Nun, infolge Corona, und damit verbunden Home-Office, zeigt sich, daß die Netzlaufwerke nur dann verbunden werden, wenn anstatt
net use X: \\server\freigabe
net use X: \\server.domaene.local\freigabe
verwendet wird, also hinsichtlich des Hostnamens des Servers, der die Freigabe trägt, der FQDN nötig ist.
Hat wahrscheinlich mit dem Tunnel zu tun, anders kann ich es mir nicht erklären. Wir stellen die VPN-Tunnel mit Hilfe von MikroTik-Appliances her, das funktioniert grundsätzlich sehr gut, es funktioniert auch alles - bis auf das Verbinden der Netzlaufwerke. Netbios-Namen nein, FQDNs ja.
Einzige Frage:
Was geschieht bei den internen Verbindungen der Rechner (die also direkt im LAN stehen, ohne VPN-Tunnel)? Kommen die damit klaglos zurecht?
Einzelne Versuche hab' ich schon damit unternommen (u. a. mit meinem eigenen Logon-Skript), da war alles in Ordnung, ich will bloß sichergehen, daß danach nicht doch irgendwo irgendeine böse Überraschung auf mich wartet, denn mitunter werden über diese Netzlaufwerke auch verschiedenste Programme gestartet, die ich jetzt nicht alle sogleich testen kann.
Hat jemand eine Idee dazu oder Erfahrung damit?
Vielen Dank.
Viele Grüße
von
departure69
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 568020
Url: https://administrator.de/forum/fqdn-pfade-im-klassischen-logon-skript-ist-das-problemlos-moeglich-568020.html
Ausgedruckt am: 24.12.2024 um 19:12 Uhr
5 Kommentare
Neuester Kommentar
Hi,
Gut so!
E.
Gut so!
Ich weiß, daß es längst effektivere und elegantere Methoden gibt, Netzlaufwerke zu verbinden (per GPO z. B.),
Ach ja? Bei "andere" würde ich mitgehen.aber unsere Skripte funktionieren grundsätzlich sehr gut, und ich hatte bisher keinen Grund, diese nicht mehr zu verwenden.
Eben!Hat wahrscheinlich mit dem Tunnel zu tun, anders kann ich es mir nicht erklären.
Ich nehme an, die Clients haben im HO oder VPN-Tunnel einen anderen DNS-Suffix, als sie es im Firmen-LAN haben. Deshalb funktioniert dann die Auflösung des kurzen Namens nicht über DNS.Was geschieht bei den internen Verbindungen der Rechner (die also direkt im LAN stehen, ohne VPN-Tunnel)? Kommen die damit klaglos zurecht?
Ja, natürlich. Das ist streng genommen sogar besser so, weil eindeutiger.E.
Hi,
ich schließe mich @emeriks an, das kannst du problemlos so machen. Der DNS kommt damit klar .
Testen geht ja auch einfach mit nslookup -> FQDN des Servers.
Grüße
tomolpi
ich schließe mich @emeriks an, das kannst du problemlos so machen. Der DNS kommt damit klar .
Testen geht ja auch einfach mit nslookup -> FQDN des Servers.
Grüße
tomolpi