puma7000
Goto Top

Srv2k8R2 als StandaloneSrv mit HyperV - kein Zugriff auf die Freigaben möglich

Hallo Forum,
bin hier brandneu registriert, habe aber in der Vergangenheit schon des öfteren von den Tip´s und Anregungen dieses Forums partizipiert. Toll.

zu meinem aktuellen Problem:
Ich habe einen 2k8R2 als Standalone Server (befindet sich damit in der Arbeitsgruppe "Workgroup" und wird im nachfolgenden als Host bezeichnet) aufgesetzt. Er ist ans Netz einer Domäne angeschlossen und hat auch eine statische IP (x.x.1.6) dieser - noch von einem 2k3R2 (x.x.1.10) kontrollierten Domäne.
Auf dem Host habe ich nun den Hyper-V aktiviert und es läuft auch bereits eine VM mit einem weiteren 2k8R2 (x.x.1.16), der später den alten 2k3R2 DC ersetzen soll.
Soweit funktioniert auch alles, kann vom Netzwerk aus auch auf den virtuellen 2k8R2 und dessen Freigaben zugreifen.

Nun möchte ich auf dem Host (Standalone 2k8R2) ebenfalls eine Freigabe für diverse Daten einrichten, die nur ich als Admin benötige.
Leider kann ich aber weder die "Workgroup" noch den HostSrv innerhalb der Netzwerkumgebung finden.
Ping und RDP funktionieren, aber alle Suchfunktionen nach dem Hostserver bzw. der Workgroup scheitern - egal ob mit Browser oder CMD-Shell.

Die Rolle Dateidienst habe ich auf dem Host aktiviert und testweise mal die gesamte FW deaktiviert.
Auch die Permissions für die Freigabe sind auf SHARE JEDER(Full) und NTFS JEDER (Full) gesetzt.
Natürlich sind auch die Netzwerkprotokolle aktiviert.

Meine Admin-Clients sind ein Win7Pro (Domainmember) und ein XP Pro (Guest bzw. Mitglied einer anderen Domäne).

Was mach ich falsch bzw. was fehlt um vom Intranet auf den Host zugreifen zu können.
Bin für jeder Vorschlag / Rat dankbar.

MfG
Siegie

Content-Key: 205940

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

Printed on: April 23, 2024 at 17:04 o'clock

Member: DerWoWusste
DerWoWusste May 02, 2013 at 11:33:59 (UTC)
Goto Top
Hi.

Leider kann ich aber weder die "Workgroup" noch den HostSrv innerhalb der Netzwerkumgebung finden.
...und \\servername geht auch nicht, wenn eingegeben in die Adresszeile des Explorers? Welche Meldung kommt dann? Schon mit telnet geprüft, ob der benötigte Port offen ist?
telnet servername 445
Member: falscher-sperrstatus
falscher-sperrstatus May 02, 2013 at 11:36:58 (UTC)
Goto Top
Die Firewall ist aus?
Member: Puma7000
Puma7000 May 02, 2013 at 11:53:11 (UTC)
Goto Top
Hallo,

ping auf IP geht, ping auf \\Servername = konte \\Server nicht finden.
Habe den Host auch im alten DNS der Domäne auch mal einen eigenen HostA Eintrag angelegt - hilft auch nichts.

Ja, die FW ist aus.

Wie gesagt, ich kann bereits von meinen Admin-Clients auf die Shares auf dem virtuellen 2k8R2 zugreifen, obwohl der sich noch nicht in der Domäne befindet, sondern auch in der Arbeitsgruppe (wird erst später der DOM hinzugefügt). Jetzt habe ich aber mal von der VM aus eine Netzwerksuche nach meinen Clients gestartet, und die zeigt mir nur den HOST und den Router an.
Auf meine Clients kann ich damit nicht zugreifen. Komisch.

Muss ich hier eventuell Vertrauensstellungen zur Domäne einrichten?
Member: falscher-sperrstatus
falscher-sperrstatus May 02, 2013 at 11:55:49 (UTC)
Goto Top
Ein Ping wird nicht gehen, wenn du ein \\ voranstellst.

Ist der Hyper-V ein Vollwertiger S2008R2 oder nur ein Hyper-V?
Member: Puma7000
Puma7000 May 02, 2013 at 12:09:13 (UTC)
Goto Top
naja, den Ping bekomme ich schon richtig hin face-wink kommt ja auch eine positive Antwort.

Der Host ist ein vollwertiger 2k8R2 Ent, auf dem aber nur die Hyper-V Rolle aktiviert ist. Zum Austesten auf die Shares habe ich aber noch die Dateidienste aktiviert.
Member: falscher-sperrstatus
falscher-sperrstatus May 02, 2013 at 12:16:07 (UTC)
Goto Top
Du sagst die Freigabe sei eingerichtet? Die MS Firewall ist komplett aus? In der DOmäne ist er nicht? (GPOs, die greifen?) Ist eine AV/IS Software installiert? Ist eine (HW) Firewall zwischen den beiden physischen Geräten?

\\[$host]\c$ ergibt was?
Member: Puma7000
Puma7000 May 02, 2013 at 12:26:52 (UTC)
Goto Top
Jo..
- die Share \\Hostname\ISO ist RICHTIG eingerichtet, die Freigabe und NTFS Rechte auch
- der Host ist domainless in der Workgroup!Damit greifen auch keine eventuellen restriktiven GPO´s
- AV oder FW Software gibt´s noch keine
- die WinFW (auf allen Netzwerkprofilen Domäne/Privat/Öffentlich) ist deaktiviert.
- als Router/Gateway fungiert eine FB6360, auf der die FW z.Z. auch deaktiviert ist.
- \\hostname\c$ ergibt Systemfehler 53 - Netzwerkpfad konnte nicht gefunden werden.

Jetz habe ich die VM mal in die Domäne eingebunden - stand sowieso an - und hier funktioniert nun alles prima. Sehe alle Clients / Server und auch meinen XP Client, der einer anderen Domäne angehört aber sich nun im selben Netzwerksegment befindet.

Auf dem Host laufen auch alle notwendigen Dienste und die Netzwerkerkunnung ist auch aktiviert.

Eigentlich sollte es so funzen.
Aber warscheinlich sehe ich irgendwo den Wald vor lauter Bäumen nicht.
Member: falscher-sperrstatus
falscher-sperrstatus May 02, 2013 at 12:28:50 (UTC)
Goto Top
Was funktioniert denn nun noch nicht? Hier scheint es eher ein IP/DNS Problem gewesen zu sein? [Vermutung]
Member: Puma7000
Puma7000 May 02, 2013 at 12:45:43 (UTC)
Goto Top
Ich skizziere mal die Struktur:

a) domainless WinServer 2008R2Ent (DL308G5, 32GB RAM, 1TB RAID5, 2xQuadcore) als HOST für Hyper-V aufgesetzt.
HostIP 192.168.1.6

b) VS1 als virtueller Srv2k8R2Std (4GB RAM, 200 GB, 2 Cores) aufgesetzt und mittlerweile als einfacher Member an die Domäne angebunden = pass.
VS1 IP 192.168.1.106 (noch über DHCP vom DC )

c) aktiver DC (Srv2003R2) mit IP 192.168.1.10 = pass

d) etliche Domänenclients (XP und Win7, IP über DHCP) = pass

Failed:

Netzwerkzugriff auf den HOST (egal von wo aus) = failed
Ping auf HOST 192.168.1.6 = pass
Ping auf \\Host = failed
Im DNS der Domäne habe ich den Host in der Forward und Reverse Zone eingetragen

Problem:
Ich möchte von meinem Netzwerkclient auf die Freigabe ISO auf den HOST zugreifen = failed mit Systemfehler 53 (Der Netzwerkpfad wurde nicht gefunden)

Hinweis: Die virtuelle NIC des VS1 ist richtig an die HOST-NIC angebunden und funktioniert.

Bloß gut das ich kein Latein kann, sonst würde ich jetzt sagen - ich bin damit am Ende face-smile
Member: falscher-sperrstatus
falscher-sperrstatus May 02, 2013 at 13:05:43 (UTC)
Goto Top
Ich konnte mal Latein, hilft in den Sachen aber kaum ;)

OK, Fehler: DNS face-smile Warum auch immer scheint da irgendwas nicht so zu funktionieren, wie du das willst face-smile

Gib bitte mal die ausgaben von ipconfig /all von HOST und VS und $randomDomPC an.

Nochmals auf den Ping bezogen \\host = Hostname? das \\ irritiert mich face-smile
Member: Puma7000
Puma7000 May 02, 2013 at 13:35:12 (UTC)
Goto Top
Sorry, hat jetzt etwas gedauert.

Ja zum Ping: \\host = Hostname

Die Ergebnisse der Pingabfragen (vom XP Client aus)
ping -a 192.168.1.6 (= statische IP des Host: VCORE13)

Ping vcore13.vflnet.local [192.168.1.6] mit 32 Bytes Daten:
Antwort von 192.168.1.6: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.1.6: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.1.6: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.1.6: Bytes=32 Zeit<1ms TTL=128

Man erkennt, das der DNS die Namensauflösung schon hinbekommt.

So, nun mal Ping vcore13.vflnet.local
Ping vcore13.vflnet.local [192.168.1.6] mit 32 Bytes Daten:

Antwort von 192.168.1.6: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.1.6: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.1.6: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.1.6: Bytes=32 Zeit<1ms TTL=128

Der Ping unter Angabe des FQDN geht, aber ein
Ping vcore13 - bringt
Ping-Anforderung konnte Host "vcore13" nicht finden. Überprüfen Sie den Namen, und versuchen Sie es erneut.

Korrektur:
Habe jetzt mal den VCORE13 (HOST) statisch in den WINS des DC eingetragen, wo er sich bis dato noch nicht befand.
Jetzt erhalte ich auf "Ping vcore13" wenigstens ein positives Ergebnis, im Browsersuchdienst weiterhin negativ.

Die IPCONFIG des VCORE13 (HOST)
Windows-IP-Konfiguration

Hostname . . . . . . . . . . . . : VCore13
Prim„res DNS-Suffix . . . . . . . :
Knotentyp . . . . . . . . . . . . : Hybrid
IP-Routing aktiviert . . . . . . : Nein
WINS-Proxy aktiviert . . . . . . : Nein

Ethernet-Adapter ViLAN-Ext: ( = virtuelle NIC)

Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Virtuell Extern
Physikalische Adresse . . . . . . : 00-23-7D-56-B3-1E
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
Verbindungslokale IPv6-Adresse . : fe80::29fe:d4af:21c5:2682%20(Bevorzugt)
IPv4-Adresse (Auto. Konfiguration): 169.254.38.130(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.0.0
Standardgateway . . . . . . . . . :
DHCPv6-IAID . . . . . . . . . . . : 352330621
DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-19-0B-71-D7-00-23-7D-56-B3-1C
DNS-Server . . . . . . . . . . . : 192.168.1.1
192.168.1.10
NetBIOS ber TCP/IP . . . . . . . : Aktiviert

Ethernet-Adapter ViLAN-Int: (= Virtuelle NIC)

Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Virtuell Intern
Physikalische Adresse . . . . . . : 00-15-5D-01-10-00
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
Verbindungslokale IPv6-Adresse . : fe80::3d0e:6992:1b99:b29d%17(Bevorzugt)
IPv4-Adresse (Auto. Konfiguration): 169.254.178.157(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.0.0
Standardgateway . . . . . . . . . :
DHCPv6-IAID . . . . . . . . . . . : 402658653
DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-19-0B-71-D7-00-23-7D-56-B3-1C
DNS-Server . . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
NetBIOS ber TCP/IP . . . . . . . : Aktiviert

Ethernet-Adapter LAN-01: ( physische NIC )

Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : HP NC373i Multifunction Gigabit Server Adapter #44
Physikalische Adresse . . . . . . : 00-23-7D-56-B3-1E
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
Verbindungslokale IPv6-Adresse . : fe80::85b6:eaac:1e02:e878%12(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 192.168.1.6(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : 192.168.1.1
DHCPv6-IAID . . . . . . . . . . . : 318033478
DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-19-0B-71-D7-00-23-7D-56-B3-1C
DNS-Server . . . . . . . . . . . : 192.168.1.1
192.168.1.10
NetBIOS ber TCP/IP . . . . . . . : Deaktiviert

Ethernet-Adapter LAN-02:

Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : HP NC373i Multifunction Gigabit Server Adapter #45
Physikalische Adresse . . . . . . : 00-23-7D-56-B3-1C
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja

Tunneladapter isatap.{A67D0681-61B2-49D4-B918-759523CFB2EE}:

Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter
Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja

Tunneladapter isatap.{2B37EA0F-9BE6-4CBD-A2E8-8E0930511613}:

Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #2
Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja

Tunneladapter Teredo Tunneling Pseudo-Interface:

Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja

Tunneladapter isatap.{27AFE70A-E157-46BF-9227-AE0F07746A37}:

Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #3
Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja

Tunneladapter isatap.{E84F95BC-96C1-44BF-8AE4-59C2C14BBFEF}:

Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #4
Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja


Die IPCONFIG des VS1 (virtueller Server)
Windows-IP-Konfiguration

Hostname . . . . . . . . . . . . : VS1
Prim„res DNS-Suffix . . . . . . . : VfLNet.local
Knotentyp . . . . . . . . . . . . : Hybrid
IP-Routing aktiviert . . . . . . : Nein
WINS-Proxy aktiviert . . . . . . : Nein
DNS-Suffixsuchliste . . . . . . . : VfLNet.local
VfLNet

Ethernet-Adapter LAN-Ext:

Verbindungsspezifisches DNS-Suffix: VfLNet
Beschreibung. . . . . . . . . . . : Netzwerkkarte fr Microsoft Virtual Machine-Bus
Physikalische Adresse . . . . . . : 00-15-5D-01-10-01
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
Verbindungslokale IPv6-Adresse . : fe80::d839:adbc:f58:9fe%11(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 192.168.1.106(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Lease erhalten. . . . . . . . . . : Donnerstag, 2. Mai 2013 14:12:14
Lease l„uft ab. . . . . . . . . . : Freitag, 10. Mai 2013 14:12:14
Standardgateway . . . . . . . . . : 192.168.1.1
DHCP-Server . . . . . . . . . . . : 192.168.1.10
DHCPv6-IAID . . . . . . . . . . . : 234886493
DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-19-11-6B-39-00-15-5D-01-10-01
DNS-Server . . . . . . . . . . . : 192.168.1.10
192.168.1.1
Prim„rer WINS-Server. . . . . . . : 192.168.1.10
NetBIOS ber TCP/IP . . . . . . . : Aktiviert

Tunneladapter isatap.VfLNet:

Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix: VfLNet
Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter
Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja

Tunneladapter LAN-Verbindung* 2:

Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
Member: falscher-sperrstatus
falscher-sperrstatus May 02, 2013 at 13:39:55 (UTC)
Goto Top
OK, demnach ist dein Problem schonmal isoliert
1. Deine Namensauflösung funktioniert nur mit FQDN - check mal deinen DNS.

Was sagt nslookup unter dem DomPC?

2. Funktioniert die Freigabe mit der IP?
Member: Puma7000
Puma7000 May 02, 2013 at 13:58:57 (UTC)
Goto Top
NET USE mittels IP und mittels FQDN geht nicht = Systemfehler 64 !
Ping mittels IP und FQDN funktioniert.

nslookup vom DC auf den Host VCORE13 bringt die richtige Auflösung mit der korrekten IP
Member: falscher-sperrstatus
falscher-sperrstatus May 02, 2013 at 14:03:55 (UTC)
Goto Top
Jetzt muss ich mich leider ausklinken, da es zu sehr ans raten geht.

Evtl hilft ja die folgende Google Anfrage: https://www.google.de/search?q=systemfehler+64+net+usw&ie=utf-8& ...

Sorry, aber für weitere Hilfestellungen würde ich Zugriff auf die Server etc benötigen.
Member: Puma7000
Puma7000 May 02, 2013 at 14:08:57 (UTC)
Goto Top
Danke dir bis dahin.

Wenn jetzt alle Stricke reissen, hänge ich den Host mal in die Domäne (was ich eigentlich nicht wollte) dann geht´s sicher.

Danke nochmal und Servus
Siegie
Member: Puma7000
Puma7000 May 02, 2013 at 14:52:02 (UTC)
Goto Top
So, Problem gelöst ( kurz bevor ich narrisch wurde)

Die Ursache lag an der IP Verbiegung die der Hyper-V mit seinen virtuellen Nic´s macht.

Der Host bekam von mir bei der Installation die IP x.x.1.6 auf seine physikalische NIC.

Beim Hyper-V Setup werden virtuelle NICs erstellt und per Protokoll an die physikalischen NIC´s gebunden.

Bei der Erstellung einer VM wählt man die gewünschte virtuelle NIC aus und vergibt dann ebenfalls eine IP (bei mir die x.x.1.16)für die VM.

Und hier lag "der Hund begraben".
Irgendwie hat der Hyper-V die IP x.x.1.6 auch der virtuellen NIC zugewiesen. Damit hatten 2 NICs im Netz dieselbe IP und die physikalische NIC zog dabei den kürzeren.
Nachdem ich nun die HOST IP abgeändert habe, geht das auch so, wie es soll.
Alle Zugriffe auf den in einer Workgroup befindlichen HOST sind nun möglich und auch die Netzwerkbrowserdienst funktionieren wie gewollt.

Vielen Dank für dein Mitwirken
Siegie