Zusätzlicher Serveralias (netdom)

[-nin 11]

Hallo zusammen,

 

ich habe eine Test-Win2019 VM namentlich in der AD: VM-SRV-FS-TMP.domain.loc registriert.

Der habe ich mit

netdom computername VM-SRV-FS-TMP.domain.loc /add:fileserver1.domain.loc

einen zusätzlichen Computernamen registriert.

Der taucht nun auch im DNS auf als A-Record auf.

 

Freigaben auf diesem Server erreiche ich im Windows-Explorer aber nach wie vor nur über

\\VM-SRV-FS-TMP oder eben als FQDN.

 

Ich habe in der Registrierung auf VM-SRV-FS-TMP das

"DisableStrictNameChecking" mit 1 deaktiviert,

"BackConnectionHostNames" Fileserver1 Fileserver1.domain.loc

 

eingetragen und neu gestartet.

 

Dennoch komme ich von einem Client nicht auf dessen Freigaben geschweige denn auf den Server selbst mittels

\\Fileserver1 bzw. Fileserver1.domain.loc

 

Da kommt folgende Fehlermeldung:

Zitat

Auf \\Fileserver1 kann nicht zugegriffen werden. Sie haben eventuell keine Berechtigung, diese Netzwerkressource zu verwenden. Wenden Sie sich an den Administrator des Servers, um herauszufinden, ob Sie über Berechtigungen verfügen. Der Zielkontoname ist ungültig.

Könnt Ihr mir helfen?

 

Danke, -nin

[testperson 1.728]

Hi,

 

was hast du denn vor? Warum möchtest du den Server mit einem Alias ansprechen?

 

Gruß

Jan

[-nin 11]

Also prinzipiell ist das nur ein Test, mit dem Hintergedanken, einen alten Netbios-Namen eines vergangenen Fileservers wieder erreichbar zu machen, weil evtl. noch alte Word-Dokumente auf dessen UNC-Pfad mittels Hyperlink verweisen z. B. \\Fileserver1\Freigabe\Dokumente\xyz.docx.

[testperson 1.728]

Hi,

 

dann ist das meiner Meinung nach "Pfusch am Bau". Hier würde ich in Betracht ziehen, die Shares in einem DFS-N bereitzustellen (und einmal die Arbeit machen / die Anweisung geben die Word-Dokumente anzupassen). AFAIK gibt es auch Tools die sowas übernehmen können. Ob die funktionieren und was die Kosten kann ich dir nicht sagen. :)

 

Gruß

Jan

[-nin 11]

Die Dokumente anzupassen, ist für mich keine Option, das sind tausende von Dokumenten und das über eine Software automatisiert machen zu lassen, halte ich für zu riskant, dass die Dokumente zerstört oder unkontrolliert verändert werden.

 

Wofür soll das mit den alternativen Computernamen dann gut sein, wenn nicht dafür?

 

Den Server darüber anpingen zu können hilft keinem.

 

Ich habe das Vorhaben gerade versucht über einen CNAME-Eintrag im DNS zu lösen und mit netdom den Alias wieder entfernt.

Aber die Fehlermeldung von oben bleibt. Ich kann den Server nicht über dessen Alias via \\Fileserver1 erreichen.

bearbeitet 11. Januar 2021 von -nin

[zahni 558]

Office versucht Verknüpfungen i.d.R. selbst zu reparieren, d.h. es sucht unterhalb der der Datei die Ordner nach den Verknüpfungen ab, selbst wenn der Baum verschoben wurde.

UNC verwendet Office intern kaum noch. Ich meine, wir hatten zuletzt mit Office 97 das Problem, dass externe Verknüpfungen immer als UNC abgespeichert worden sind.

Was Du machen könntest: auf den neuen Fileserver migrieren, auf dem alten Server die Schreibrechte komplett entfernen (per Freigabe / NTFS). Nach der Migration kannst Du auf dem alten Server nun prüfen, ob noch Dateien geöffnet werden und dort nachsteuern. Wenn der alte Server abgeschaltet wird, ist es wichtig dessen DNS-/WINS-Namen zu löschen. 

Wir haben schon Fileserver migriert und keine wesentlichen Probleme gehabt.

bearbeitet 11. Januar 2021 von zahni

[NilsK 2.968]

Moin,

 

vor 3 Minuten schrieb -nin:

Wofür soll das mit den alternativen Computernamen dann gut sein, wenn nicht dafür?

bestenfalls als Workaround. Aber eigentlich: das ist gar nicht gut.

Selbst wenn du es zum Laufen bekommst (ich hab es lange nicht mehr probiert, kann durchaus sein, dass das nicht mehr oder nicht ohne Weiteres geht), verschiebst du das Problem ja nur in die Zukunft. In drei Jahren kommt der nächste Name dazu, dann noch einer ... das ist nicht nur organisatorisch ein Alptraum.

 

Gruß, Nils

 

 

[zahni 558]

vor 8 Minuten schrieb -nin:

 

Wofür soll das mit den alternativen Computernamen dann gut sein, wenn nicht dafür?

 

 

PS: Ich kann kann mir gut vorstellen, dass Du in einer Session nicht gleichzeitig auf die gleiche Ressource mit unterschiedlichen DNS-Namen zugreifen kannst. Das mag bei NTLM noch funktioniert haben, bei Kerberos (SMBv2/3) habe ich da meine Zweifel. Also Entweder die richtige Name ODER der Alias. Ist aber nur eine Vermutung. Nichts, was ich implementieren würde.

[tesso 375]

Ich habe im Hinterkopf, man muß für SMB2/3 noch einen SPN hinzufügen.

[zahni 558]

vor 32 Minuten schrieb tesso:

Ich habe im Hinterkopf, man muß für SMB2/3 noch einen SPN hinzufügen.

Das soll Netdom wohl machen.

[cj_berlin 1.342]

vor 17 Minuten schrieb zahni:

Das soll Netdom wohl machen.

Dann kontrolliere es doch  

[tesso 375]

vor 17 Minuten schrieb zahni:

Das soll Netdom wohl machen.

Da bin ich mir nicht sicher. Kann man zur Sicherheit ja überprüfen.

[zahni 558]

vor 3 Stunden schrieb tesso:

Ich habe im Hinterkopf, man muß für SMB2/3 noch einen SPN hinzufügen.

Der Wichtig-Kasten:

 

https://docs.microsoft.com/de-de/troubleshoot/windows-server/networking/dns-cname-alias-cannot-access-smb-file-server-share

[-nin 11]

Guten Morgen zusammen,

 

also in Anbetracht dessen, dass wir einen DFS-N bereits nutzen, sollte das Problem mit dem Server-Namen tatsächlich kein Problem mehr sein.

 

Ich hatte da noch einen alten Fehler meiner vorletzten Migration im Hinterkopf. Damals hatte ich den DFS-N nicht über die Domäne, sondern über den Servernamen angesprochen und als Netzlaufwerk gemapped. Laufwerk X ging also auf \\SERVERNAME\DFSFREIGABE.

Word z. B. hatte dann natürlich immer schön \\SERVERNAME\DFSFREIGABE... als Pfad verwendet.

 

Aktuell ist mein Laufwerk X über \\domäne.loc\DFSFREIGABE gemapped. Das spiegelt sich dann auch beim Verlinken in Word wieder.

Verlinkt man ein Dokument über X:\Ordner\xyz, dann macht Word daraus \\domäne.loc\DFSFREIGABE\Ordner\xyz.

Damit kann ich natürlich leben