Server 2022 Freigabe nur noch über FQDN erreichbar - IPv6-Problem?

Moin zusammen!

Ich habe mir hier ein Test-Netzwerk mit einem Windows-Server 2022 aufgebaut, in erster Linie, um Praxiserfahrung mit IPv6 in Windows-Domänenumgebungen zu sammeln. Das klappt im Grunde soweit auch schon ganz gut; der Server ist Domain Controller und verfügt über feste Adressen (IPv4 und IPv6). Zwei virtuelle Win10-Clients hängen dran.

Ferner habe ich auf dem DC einen DHCP-Server für IPv4 UND IPv6 eingerichtet. Letzteres möchte ich gerne mal ausprobieren, mir ist bewusst, dass DHCP auf Windows für IPv6 auch in Domänen-Netzwerken optional ist (so zumindest hier gelesen, bitte korrigiert mich, wenn ich Unsinn schreibe). Die IPv6-Seite soll in diesem Szenario nur der internen Kommunikation dienen, Internet spielt keine Rolle.
DHCP IPv6 wollte zunächst nicht recht klappen, denn es wurden zwar korrekt Adressen verteilt, die Systeme konnten sich aber im LAN nicht über IPv6 erreichen. HIER brachte mich jemand auf die richtige Spur, ich musste im Router noch ein Gateway setzen.

Ergebnis ist ein Netzwerk, in dem PINGs sowohl über IPv4 als auch IPv6 sauber hin- und hergehen.

ABER.

Seit ich die IPv6-Konfiguration (nach meiner Meinung) sauber eingerichtet habe, können die Clients plötzlich nicht mehr über den Kurznamen auf die Freigaben des Servers zugreifen. Also im Explorer \\SERVER und Enter führt zu "Auf \\SERVER konnte nicht zugegriffen werden" - Fehlercode 0x80004005.
Das verwirrt mich insofern, als dass ein PING auf SERVER direkt umgewandelt wird zu einem PING auf server.domain.local - und dort wiederum kommt die korrekte Adresse, entweder als IPv4 oder via -6 als IPv6, und auch eine korrekte Antwort.

Um alles noch schlimmer zu machen: SPORADISCH klappt der zugriff via \\SERVER dann plötzlich doch! Und klar, ich weiß, wonach sich das anhört - irgendwo ein Problem, ein Fehler, eine Unsauberheit. Aber ich komme partout nicht dahinter, wo diese liegen könnte! DNS & Co. sollten sauber konfiguriert sein, der Domänen-Suffix ist ebenfalls korrekt eingetragen. Nameserver wird per DHCP übergeben, und wie gesagt - die reine Adress-Auflösung funktioniert ja auch zuverlässig.

nslookup server
Server: SERVER.domain.local
Address: fd90:717f:13a9:7f7::1
Name: server.domain.local
Addresses: fd90:717f:13a9:7f7::1
192.168.1.1

tracert server
Routenverfolgung zu SERVER.domain.local [192.168.1.1]
über maximal 30 Hops:
1 <1 ms <1 ms <1 ms SERVER.domain.local [192.168.1.1]

tracert -6 server
Routenverfolgung zu server.domain.local [fd90:717f:13a9:7f7::1]
über maximal 30 Hops:
1 1 ms <1 ms <1 ms fd90:717f:13a9:7f7::9
2 1 ms 1 ms <1 ms SERVER.domain.local [fd90:717f:13a9:7f7::1]

(fd90:717f:13a9:7f7::9 ist der Router).

ipconfig /all
Ethernet-Adapter Ethernet 2:
Verbindungsspezifisches DNS-Suffix: domain.local
Beschreibung. . . . . . . . . . . : Microsoft Hyper-V Network Adapter #2
Physische Adresse . . . . . . . . : 00-15-5D-01-02-02
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
IPv6-Adresse. . . . . . . . . . . : fd90:717f:13a9:7f7:6334:78a1:5297:91fa(Bevorzugt)
Lease erhalten. . . . . . . . . . : Samstag, 29. Juni 2024 09:12:02
Lease läuft ab. . . . . . . . . . : Donnerstag, 11. Juli 2024 09:12:01
Verbindungslokale IPv6-Adresse . : fe80::5373:5ec4:e823:dfea%7(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 192.168.1.120(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : 192.168.1.100
DHCPv6-IAID . . . . . . . . . . . : 251663709
DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-2A-A8-CB-E7-00-15-5D-01-07-04
DNS-Server . . . . . . . . . . . : fd90:717f:13a9:7f7::1
192.168.1.1
fd90:717f:13a9:7f7::1
NetBIOS über TCP/IP . . . . . . . : Aktiviert
Suchliste für verbindungsspezifische DNS-Suffixe:
domain.local
intern


Wo ist der Knoten im Hirn, wo kann ich noch nachschauen? Ich komme leider momentan gedanklich echt nicht weiter. Oder ist das beim Server 2022 "by design", dass man nur noch FQDN nutzen soll, und die alternativen Auflösungen (wie läuft das - über WINS?) rausfliegen? Unter Server 2019 lief die obige Konstellation noch problemlos mit dem "kurzen" Freigabenamen, ich bin ja schon froh, dass ich 2022 vorher ausprobiert habe...

Bin für jeden gedanklichen Anstoß dankbar!

Windows-IP-Konfiguration

   Hostname  . . . . . . . . . . . . : SERVER
   Primäres DNS-Suffix . . . . . . . : domain.local
   Knotentyp . . . . . . . . . . . . : Hybrid
   IP-Routing aktiviert  . . . . . . : Nein
   WINS-Proxy aktiviert  . . . . . . : Nein
   DNS-Suffixsuchliste . . . . . . . : domain.local
                                       intern

Ethernet-Adapter Ethernet 2:

   Verbindungsspezifisches DNS-Suffix: intern
   Beschreibung. . . . . . . . . . . : Microsoft Hyper-V Network Adapter #2
   Physische Adresse . . . . . . . . : 00-15-5D-01-02-00
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja
   IPv6-Adresse. . . . . . . . . . . : fd90:717f:13a9:7f7::1(Bevorzugt)
   Verbindungslokale IPv6-Adresse  . : fe80::9238:4f40:bed2:9a7b%2(Bevorzugt)
   IPv4-Adresse  . . . . . . . . . . : 192.168.1.1(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . : fd90:717f:13a9:7f7::9
                                       192.168.1.100
   DNS-Server  . . . . . . . . . . . : fd90:717f:13a9:7f7::1
                                       127.0.0.1
   NetBIOS über TCP/IP . . . . . . . : Aktiviert
   Suchliste für verbindungsspezifische DNS-Suffixe:
                                       intern