departure69
Goto Top

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

Content-ID: 568020

Url: https://administrator.de/contentid/568020

Ausgedruckt am: 21.11.2024 um 20:11 Uhr

emeriks
Lösung emeriks 27.04.2020 aktualisiert um 14:57:10 Uhr
Goto Top
Hi,
Zitat von @departure69:
Wir verwenden immer noch die klassischen Logon-Skripte im SYSVOL der Domäne.
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.
tomolpi
Lösung tomolpi 27.04.2020 aktualisiert um 15:46:19 Uhr
Goto Top
Hi,
ich schließe mich @emeriks an, das kannst du problemlos so machen. Der DNS kommt damit klar face-wink.
Testen geht ja auch einfach mit nslookup -> FQDN des Servers.

Grüße

tomolpi
departure69
departure69 27.04.2020 um 15:57:14 Uhr
Goto Top
Danke Euch. Kurz und schmerzlos. Wenn's doch immer so wär'! face-wink

Viele Grüße

von

departure69
STITDK
Lösung STITDK 27.04.2020 aktualisiert um 16:45:58 Uhr
Goto Top
Außer du hast DATEV dann in der Freigabe kein FQDN :/


Grüße

STITDK
departure69
departure69 28.04.2020 um 07:51:29 Uhr
Goto Top
@STITDK:

Ah, siehste! Doch ein Beispiel. Es geht nichts über eigene Erfahrung aus erster Hand. Danke Dir.

Bei uns zum Glück kein Datev im Einsatz.


Viele Grüße

von

departure69