Reingucker
-
Gesamte Inhalte
397 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von Reingucker
-
-
Client mit folgender Konfiguration
IP: 192.168.200.1
Subnet: 255.255.255.0
Gateway: 200.34.66.4
Mit falschem Gateway, also Gateway ist in einem anderen Subnet. Er findet das Gateway nicht und schickt deswegen nichts raus.
PS C:\Users\Administrator> ping 8.8.8.8
Ping wird ausgeführt für 8.8.8.8 mit 32 Bytes Daten:
Antwort von 192.168.200.1: Zielhost nicht erreichbar.
Antwort von 192.168.200.1: Zielhost nicht erreichbar.
Antwort von 192.168.200.1: Zielhost nicht erreichbar.
Antwort von 192.168.200.1: Zielhost nicht erreichbar.
Ping-Statistik für 8.8.8.8:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),Sieht dann auf dem Kabel so aus.
Und hier wenn gar kein Gateway eingetragen ist
PS C:\Users\Administrator> ping 8.8.8.8
Ping wird ausgeführt für 8.8.8.8 mit 32 Bytes Daten:
Allgemeiner Fehler.
Allgemeiner Fehler.
Allgemeiner Fehler.
Allgemeiner Fehler.
Ping-Statistik für 8.8.8.8:
Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
(100% Verlust),Da geht auch nix aufs Kabel dann. Der Rechner mit dem Wireshark sitzt in der gleichen Broadcastdomäne (genau genommen am anderen Ende vom Kabel).
-
Muss da nicht noch der Accountname hinten dran? Also "\\Server\Verzeichnis\Accountname"?
-
Also so schlimm ist KVM nicht. Bzw. ist Qemu nicht. Man kann damit sogar ne cisco ASA virtualisieren wie man in GNS3 sehen kann. Allerdings stört mich dieses bridge-design bei nics und vlans ect.
-
Offtopic
Man kann noch einen drauf packen: Software-iSCSI über SMB3 ^^
scnr
-
Danke für den Link. :-) Warten wir mal was der TO bei VMWare erreicht.
Bitte, gern geschehen.
-
Vielleicht ist der ipk den ihr habt für Server 2008 kms und nicht 2016?
-
So wie es aussieht kann man in Veeam die Grundfunktionen für storage latency control auch ohne Enterprise Lizenz einstellen
http://blog.vmjoes.com/2015/04/veeam-backup-io-control-storage-latency.html
-
Ja, das macht dann wieder "Sinn". Allein über die Prio/Max-Einstellung für den Prozess bekommt man es ja nicht geregelt.
-
Ja, sieht so aus als wenn Veem beim remove da nochmal ohne Rücksicht zulangt und alle Resourcen greift
-
Liegt der Zeuge in einer Freigabe auf dem Server der da gerade gesichert wird?
-
Workfolders über ADFS wäre hier auch interessant...wenn auch mit Kanonen auf Spatzen bei einem Ordner. Aber falls noch mehr gegeseitig zugreifen hinzu kommt wäre schon mal Grundstein da. Z.B. könnte man es auch auf andere Firmen, mit welchen man Geschäfte macht und Dateien ect.austauscht, erweitern.
-
So, hab mir das mal angeschaut und Filmchen gemacht. Der User dummxftp ist nur dazu da um im AD die FTP-Attribute der sich anmeldenden User abzufragen. Ich weiß jetzt nicht genau wie deine APP funktioniert, aber ich denke das Filmchen erklärt einiges. Falls was fehlt...sagen.
Edit:
Ah ja, deine User sind ja hardcoded. Sollte aber gehen wenn du nur eine Domäne abdeckst. Hab ich jetzt nicht probiert. Wenns ohne "@domäne.suffix" nicht geht, dann probier mal unter ftp-authentifizierung die Standardanmeldung zu bearbeiten und dort die die standarddomäne einzutragen.
Edit:
Ja, geht auch ohne domainsuffix. Also ist es egal was deine APP für Pfade ansteuert, Hauptsache es gibt den User, z.B. "Name2" im AD und der wird dann entsprechend den Einträgen bei seinen Attributen in das gewünschte Verzeichnis geschoben.
-
Ich teste das mal am WE aus. Wenn man so manche Kommentare im Netz liest muß das gehen. Mal schauen.
-
-
Also die Option ist an. Aber wie du schon sagst müsste was laufen tut aber nicht ich hab die ganzen Dienste runter geschmissen.
Es sind ja nicht nur die Dienste. Da werden ja auch Kerneltreiber installiert und die sind wahrscheinlich noch da und die erkennt der Hyper-V. Oder die "Switches" bzw. virtuelle Netzwerkkarten die da noch installiert werden, die werden manchmal auch nicht deinstalliert.
-
Also Virtualisierung kann deine CPU und wenn die auf dem Board (falls es die Option dort überhaupt gibt) nicht aktiviert wäre, dann müsste es eigentlich eine andere Fehlermeldung vom Hyper-V geben. Zumindest könnte dann ein anderer Hypervisor auch nicht laufen und nach der Fehlermeldung von Hyper-V läuft da aber einer.
-
Immer noch die gleiche Meldung? Hmm, ich glaube mich zu erinnern daß da bei VirtualBox 5.x irgendwas es mal ein Problem mit einem Update gab und es da dann auch mit der deinstallation Probleme gab. Wäre aber schon Fuddelarbeit jetzt da alles abzusuchen wo es noch drin steht. Wenn sonst nichts auf dem Server drauf ist, dann installiere ihn doch einfach neu. Teamviewer mache ich ungern.
-
Und Neustart brauchste auch danach.
-
Hatte noch keinen drauf nur jetzt am ende halt Vmware player und VirtualBox zum testen aber kein erfolg
Genau. Und einer davon scheint noch drauf zu sein oder Teile davon welche beim Serverstart noch gestartet werden. Und da es nur immer einen Hypervisor pro host geben kann, verhindern die die Installation des Hyper-V. Mußt mal schauen ob du die ganz deinstalliert bekommst. Die VMs von denen, falls du da schon welche erstellt hast, kannste ja konvertieren ins Hyper-V Format und dann dort laufen lassen.
-
Ah, ok. Dachte schon. Also dann nochmal die Frage: Hast du oder hattest du schon mal einen anderen Hypervisor auf diesem Server installiert? Z.B. VirtualBox oder andere? Dann mußt du diese am Besten erst komplett deinstallieren bevor du Hyper-V installieren kannst.
Edit:
Bei VMWare-Player ist es auch soweit ich mich erinnere.
-
Ah, dann stimmt die Überschrift nicht?
"hyper-v kann nicht installiert werden da bereits ein hypervisor ausgeführt wird"
-
Hast du schon mal einen anderen Hyperviser installiert? Z.B. Virtualbox oder andere?
-
Hmm, ja, an das habe ich gar nicht gedacht. Genau genommen war mein erster Gedanke das Schattenkopievolume in einen Ordner zu mounten und dort dann zu schauen.
-
Windows Netzwerk und Subnetting
in Windows Forum — LAN & WAN
Geschrieben
Nachdem nun klar ist was "normaler Weise" auf dem Kabel passiert, kommt jetzt das gleiche Szenario, also gleiche Rechnereinstellungen, nur diesmal mit dem falschen Gateway in der gleichen Broadcastdomäne.
Hier sieht man daß wie auch zuvor der Rechner einen Arp raus aufs Kabel schickt um das falsche Gateway, welches ja in einem anderen Subnetz ist, zu finden - und bekommt auch eine Antwort weill der Arp es ja erreicht (Farbe Rot). Darauf hin schickt der Rechner die Pakete an dieses Gateway, bekommt aber hier in meinem Szenario natürlich vom Gateway nur "not found" weil das Gateway keine Routen nach woanders hin hat (Farbe Grün). Das Gateway aber, welches die Pakete ja weiter schicken möchte, fängt jetzt selbst an mit Arp (da keine routen vorhanden) nach der 8.8.8.8 in dieser Broadcastdomäne zu suchen (Farbe Gelb). Fals jetzt ein Rechner mit der 8.8.8.8 in dieser Broadcastdomäne vorhanden wäre, dann bekäme das Gateway antwort und würde die Pakete vom Ursprungsrechner weiter leiten und zurück (normaler Weise, abhängig von den Gateway/Router Einstellungen)
Und das ist der Grund warum in dem Szenario des TO er trotzdem eine Verbindung bekommt, obwohl das Gateway zwar im falschen Subnet ist, aber in der gleichen Broadcastdomäne.