JustTheNextUser

Hallo, kurzes Feedback. Nach ausgiebigen Tests scheint es nun wie gewünscht zu funktionieren. RSS/RSC/LSO deaktivieren hat wohl geholfen. Vielen Dank für die Unterstützung! Viele Grüße

Die physischen Karten des Hyper-V sind Broadcom Gigabit Ethernet BCM5720 (Treiber: Broadcom NeXtreme Gigabit); also 1GB. Verkabelung Kupfer; Switch ist der Zyxel GS1350-26HP (FW sollte recht aktuell sein). Also +1 für VMQ deaktivieren wie mir scheint. Aber nochmal, die Verbindung ist eigentlich Tip-Top; iperf bestätigt mir auch Gigabit. Es ist wirklich nur innerhalb der Anwendung Corel ein Problem (aber eben nur von den besagten VMs und nicht von der Hyper-V selbst oder von einem NAS).

1.-3.: Ja (sowohl alle beteiligten Server als auch die Stationen) 4.: In den Betriebs-Systemen müsste das schon so sein, werde ich dann aber nochmal nachprüfen; im BIOS kann ich das gerade nicht sagen; ich schau mal ob ich da was herausfinden kann. Wäre mir aber jetzt nicht bekannt, dass hier irgendetwas im Bezug auf Energie-Sparen einstellt wurde. 5.: Es sind 'nur' der Windows-Defender und dort sind die Ausnahmen korrekt gesetzt; bzw. hatte ich auch für eine Test-Stellung den Defender und die Firewall überall mal deaktiviert > keine Besserung. Puh .. das müsste ich mir erstmal im Detail ansehen; das Ganze ist ein Produktiv-System. Ich würde mich hier erstmal einlesen und das dann gezielt umsetzen. Hier stellt sich mir immer noch die Frage an welchen Maschinen und NICs genau (HV [NIC/TeamNIC/vSwitch], FS, Station). Ich würde das wohl zuerst mal testen, hier scheint der Aufwand der Umstellung sich ja doch in Grenzen zu halten (einzig der Neustart der VMs). VG

Ok, dann werde ich das mal so probieren; VM kann ich erst heute Nacht neu starten. Zur Sicherheit nochmal alle beteiligen Computer/VMs und deren Netzwerk-Adapter: (Hypervisor) NIC1: RSC (nicht vorhanden) LSO (AN) VMQ (AUS) NIC2: RSC (nicht vorhanden) LSO (AN) VMQ (AUS) Team-NIC (Microsoft Network Adapter Multiplexor Driver): RSC (AN) LSO (AN) VMQ (AN) vEthernet (Virtual Ethernet Adapter): RSC (AN) LSO (AN) VMQ (nicht vorhanden) (Domain-Controller/Fileserver) Ethernet: RSC (AN) LSO (AN) VMQ (nicht vorhanden) (Station) Ethernet: RSC (nicht vorhanden) LSO (AN) VMQ (nicht vorhanden) Hier wirklich an allen (möglichen) Stellen die Eigenschaften auf AUS stellen ? Oder nur bei Bestimmten? Sorry dass ich nochmal nachhake; will nichts falsch machen. Danke und VG

Da musste ich erstmal nachsehen was das überhaupt ist... Wo exakt meinst du, auf dem Hypervisor oder in der VM (DC/Fileserver) ? Und wenn Hypervisor, dann die Frage auf den physikalischen Karten oder dem virtuellen Ethernet Adapter oder dem Team-NIC (MS Network Adapter Multiplexer) ? Kann ich diese Eigenschaften (RSC, LSO und VMQ) einfach/sicher umstellen oder kann es da zu Problemen kommen ? VG

Sorry war am Wochenende unterwegs und konnte nicht schreiben; im Folgenden die Infos: Server: Windows Server 2019 Std. (HV + DC/Fileserver) Client(s): Windows Pro 10 21H2/22H2 Hardware ist sowohl bei den Clients als auch bei den Servern relativ aktuell, weil alles recht neu. Treiber sind auf aktuellem Stand. Auf dem Hypervisor Team-NIC eingerichtet mit 2 Netzwerk-Interfaces (beide Karten aktiv). Sonst eigentlich keine abgefahrenen Konfigurationen soweit ich weiß; ist halt ein Domain-Netzwerk wie erwähnt. VG

Hallo zusammen, ich schreibe das Thema jetzt mal hier, weil ich nicht weiß in welcher Richtung der Fehler/das Problem liegt: In einer Anwendung (CorelDraw) habe ich Probleme beim Öffnen/Speichern/Verarbeiten von Daten von File-Server (VM auf Hyper-V); es geht sehr langsam (bei 50MB Dateien ca. 20 Sekunden pro Vorgang). Öffne ich die gleiche Datei lokal an der Station funktioniert es normal (bei 50MB Dateien ca. 5 Sekunden pro Vorgang). Interessant: Vom NAS im gleichen Netzwerk oder vom HyperV selbst ist die Geschwindigkeit auch normal (ähnlich wie lokal). Wenn ich mit IPERF die Bandbreiten prüfe, dann ist es in jeder Konstellation und Richtung stabiles Gigabit; hier gibt es keine Auffälligkeiten. Auch wenn ich einfach große Dateien von A nach B kopiere, habe ich in jeder Konstellation und Richtung stabile 110MB/s. Das Problem ist also 'nur' bei der Verarbeitung im Programm Corel selbst. Ich habe mir beide Szenarien (Station <> Fileserver && Station<> NAS) mal im Process-Monitor angesehen. Hier sehe ich auch keine nennenswerten Unterschiede in der Verarbeitung der Dateien in Corel, nur dass beim Zugriff auf den File-Server natürlich länger R/W-Zugriff auf die Datei stattfindet. Sonst sehe ich hier keine Auffälligkeiten (bin aber auch kein Process-Monitor-Profi). Lege ich die Daten auf irgendeine andere VM auf dem Hyper-V ist es genauso langsam. Es ist also irgendwie ein Problem der Anwendung Corel mit dem Datenzugriff auf den VMs. Der Corel Support kann mir nicht wirklich weiter helfen; die meinen es sollte eigentlich schnell gehen und liegt halt dann irgendwie am Netzwerk. Ich selbst weiß nicht mehr wirklich woran es liegen, bzw. wie ich das Problem lösen kann. Hat vielleicht einer von euch eine Idee, was hier noch vorliegen könnte bzw, in welche Richtung ich noch weiter ermitteln/denken kann. Danke schonmal im Voraus. VG.

Ja war eine dumme Frage .. ich habe es gemerkt

Huch .. ja stimmt du hast Recht. Eben geprüft und man braucht auf jeden Fall administrative Rechte um einen lokalen Drucker frei zugeben. Ich nehm an, dass es dann keinerlei Möglichkeiten gibt, das per GPO zu unterbinden, falls der jewilige Benutzer ein lokaler Administrator ist (wäre auch komisch wenn ich so darüber nachdenke) ? Danke für die rasche Hilfe! VG

Hallo zusammen, ich hoffe ich bin in der richtigen Kategorie. Wir haben einen Kunden, der möchte, dass die Benutzer keine lokalen Drucker auf Ihren Clients freigeben können. Also es sollen nur die Drucker des Windows-Druck-Servers per Freigabe über die GPOs verteilt werden; eigene Drucker freigeben (vor allem eben lokale USB-Geräte) soll unterbunden werden. Habe schon ein bisschen gesucht, aber irgendwie nicht das richtige gefunden, bzw. geht scheinbar immer in andere Richtungen. Gibt es also die Möglichkeit die Freigabe von Druckern lokal per GPOs zu unterbinden? Danke schonmal für die Hilfe! VG

Hallo zusammen, das Problem ist nun gelöst, hier kurz als Feedback: Ich habe zusammen mit dem Kunden den Software-Hersteller dazu bekommen, dass er seine Installations-/Updates-Routine anpasst, so dass es A) ein Log/Debug-Ausgabe gibt und B) diese anzeigt an welcher Datei es explizit scheitert. War einiges hin und her aber letztendlich kam heraus, dass es an einer Teilapplikation der Softwaresammlung scheitert der 'Lohn.exe'. Hier war die Vererbung deaktivert und es waren gesonderte Berechtigungen vergeben; wohl weil es keine Benutzerverwaltung im Programm an sich gibt und es über die Windows-Berechtigungen geregelt wird, wer auf welche Programm-Teile zugreifen darf. Somit haben halt die Ordner-Berechtigungen nicht gegriffen. Ich habe mit dann mit den Sysinternal Applikationen AccessChk (CMD) und AccessEnum (GUI) dann alle einzelnen Dateien überprüft und eine weitere solche Datei entdeckt names 'Zeiterfassung.exe'. Die Berechtigung dieser Dateien habe ich also korregiert und schon klappen die Updates mit diesem dedizierten Benutzer. Das wurde bei der Installation vom Hersteller so eingerichtet zusammen mit einem Kollegen der nicht mehr im Unternehmen tätig ist; weder der Hersteller hatte darauf hingewiesen noch der Kollege hatte es dokumentiert. Absolut simpel und sobald man mal ein richtiges Log hat, kommt man dem Problem ja auch auf die Schliche. Hatte nur nicht damit gerechnet, dass die Zugriffsverwaltung der Applikation über Windows-Berechtigungen geregelt wird. Danke für eure Untersützung. VG

Nein ich weiß schon was du meinst. Wie ich schon geschrieben habe werde ich hier mal den Besitzer der Dateien anpassen, bzw. eine Neu-Installation mit dem 'mfadmin' durchführen. Ggf. führt das zum Ziel. Allerdings erst wenn ich/der Kunde Zeit finden. Die Installation wird von einem Benutzer vom Terminal-Server aus auf Selbigem durchgeführt; dort liegen teilweise die Programmdateien, teilweise liegen Sie auf der (DFS-)Datenfreigabe auf dem DC (wie schon im ersten Threat beschrieben). Und ja alle beteiligten Stationen (in diesem Fall der WTS und der DC) wurden vor der Installation durchgestartet. Weitere Clients sind nicht beteiligt, obwohl das sicherlich auch möglich wäre, aber eben nicht nötig da Terminal Server (WTS).

same. Ja, ich kann einen Neustart des Servers machen, dann direkt mit dem 'mfadmin' anmelden und die Installation starten, es geht aber trotzdem nichts. Denke schon, ich kann sowohl auf '\\XXX-DC-01\MF' als auch auf '\\XXX-DC-01.domain.local\MF'. In die andere Richtung auch (vom DC auf '\\XXX-WTS-01\' und auf '\\XXX-WTS-01.domain.local\' Der direkte Zugriff auf '\\XXX-DC-01.domain.local\E$\DFSDaten\MF' geht nicht, was meiner Meinung nach auch richtig ist, da keine berechtigte Freigabe, oder nicht? Ok, darüber weiß ich nichts. Müsste ich nochmal prüfen bzw. schauen was man hier einstellen kann. Kann ich gerne auch nochmal versuchen, aktuell wird gearbeitet. Das heißt dann also erst später erst oder dir Tage; ich werde Rückmeldung geben. Sind meiner Meinung nach korrekt gesetzt. Ich kann ja die vom Entwickler beschriebenen vom Installer durchgeführten Arbeiten alle ausführen, wenn ich es mit diesem Nutzer 'mfadmin' manuell probiere. Sprich ich kann auf diesem Registry-Pfad schreiben, in den Programm-Ordnern, in dem Datenstamm und in den eigenen Dateien. Hatte ich alles getestet. Ich habe nach einigen Gesprächen jetzt nochmal eine Rückmeldung vom Entwickler, der einen Installer zu Verfügung stellen möchte, der Zitat: 'bei „ACCESS_DENIED“ trotzdem eine Fehlermeldung bringt so dass zumindest erst einmal die Installations-Aktion erkennbar wird die Windows nicht zulässt.' Das hört sich doch erstmal gut an, ein Installer mit einem Log quasi, klingt für mich nach einem sinvollen Lösungsweg. Ich werde berichten..

Das kann ich nicht mehr genau sagen, ich glaube tatsächlich über den Domain-Admin. Eine Neuinstallation mit dem lokalen Admin wäre mal ein Versuch. Muss ich aber zeitlich abstimmen, bzw. selbst Zeit finden. Damit ist der Vorschlag wohl vom Tisch (ist aber generell ein interessanter Artikel, wie ich finde) Jawohl, dann geht das Update problemlos durch.

Auch das hatte ich ursprünglich schon getestet, leider das gleiches Ergebnis. Wobei ich diesen Vorgang nicht mit dem ProcMon analysiert hatte, sondern nur den Versuch über den UNC-Pfad.