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.

Gerade geprüft, ist bereits auf 'AUS' auf beiden Maschinen.

Soweit ich sehen kann sind die Rechte richtig vererbt; wenn ich in dem entsprechenden Unterordner die Datei-Eigenschaften der EXE ansehe, sind dort unter Sicherheits alle gesetzen Berechtigungen korrkt durch Vererbung vergeben. Zur Sicherheit habe ich jetzt aber nochmal die Verwerbung erzwungen, wie du geschrieben hast. Bringt leider nichts, Problem weiterhin vorhanden. Smarte Idee, leider habe ich in den Datei-Eigenschaften auf beiden Maschinen keinen Bereich für 'Vertrauen'; also scheint die Datei vertrauenswürdig zu sein, gehe ich davon aus.

Hallo zusammen, danke für das Feedback. Ich habe gestern nochmal Zeit gefunden mich an das Problem zu setzen und habe mit mit ProcMon die Sache angesehen. Ich habe die Aufzeichnung gestartet bevor ich die Installation gestartet habe. Dann die Installation gestartet ('Als Administrator ausführen') und durchgeklickt bis zur Meldung 'Fehlende Windows-Rechte. Es wird automatisch ein neuer Versuch mit erhöhten Benutzerrechten gestartet. Bitte warten...' Da hier dann nichts mehr passiert, habe ich die Aufnahme beendet. Nun habe ich mir den Process-Tree angesehen. Hier gibt es den Installations-Prozess und ein Child-Prozess davon. Beide habe in in meinen Filter gepackt. Dann habe ich 'SUCCESS' und 'BUFFER OVERFLOW' aussortiert. Jetzt habe ich noch einen Teil des UNC-Pfads inkludiert (contains 'XXX-DC-01'). Nun habe ich nur noch 97 Einträge, das meiste ist 'File System' ein wenig ist 'Registry'. Das meiste ist 'NAME NOT FOUND' und dann noch die beiden (wahrscheinlich wichtigen) 'ACCESS DENIED' und 'FILE LOCKED WITH ONLY READERS'. Der Pfad beim 'ACCESS DENIED' ist jeweils der eigentliche Installer (.EXE) auf dem UNC-Pfad. Das hilft mir leider nicht weiter, da der Benutzer ('mfadmin') dort ja Vollzugriff hat. Ich habe mal einen Screenshot von Procmon angehangen. Hier noch Screenshots der Freigabe- und NTFS Berechtigungen (DFS-Daten auf dem DC). Hier noch ein Screenshot der lokalen Benutzer/Gruppen wegen lokalen Admin-Berechtigungen (auf dem WTS). Hat hier noch jemand eine Idee? Ich will natürlich dem Software-Hersteller auch nicht den schwarzen Peter zuschieben, es kann ja genauso an einer fehlerhaften Konfiguration meinerseits liegen. Ich habe auch nochmal Rückmeldung von den Entwicklern bekommen: ---------------------------------------------------------------------------------------------------------------- Die Installation besteht aus * Kopieren der Uninstall.exe nach <Programme>\XXXXXXX, also i.d.R. C:\Programme (x86) * Schreibender Zugriff auf die Registry HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths * Kopieren von Dateien nach <Dokumente> des Anwenders * Kopieren von Dateien in die gewählten Zielverzeichnisse Wenn bei einer Aktion ein Fehler auftritt wird eine Fehlermeldung gebracht und die Installation wird abgebrochen. AUSNAHME: Es wird von Windows der Fehler ERROR_ACCESS_DENIED oder E_ACCESSDENIED gemeldet. Dann nehmen wir an, dass es ein „normaler Benutzer“ oder „der eingeschränkte Admin“ ist. Der Prozess startet sich erneut „elevated“ (aka als Administrator ausführen) und versucht diese Aktion erneut. Natürlich kann dann immer noch der Zugriff verweigert werden. Ursache ist dann gerne der Virenscanner. Leider lässt sich Windows über die Ursache nicht aus. Bei Ihnen scheint es so zu sein, dass der lokale Administrator doch nicht (bzgl. der Aktionen des Installationsprogrammes) genügend Rechte besitzt. Deshalb bringt Windows weiterhin die „Zugriff verweigert“-Meldungen. ---------------------------------------------------------------------------------------------------------------- Alle 4 oben genannten Punkte kann ich mit diesem Benutzer (mfadmin) auf dem WTS/auf der DC-Freigabe manuell durchführen. Virenscanner läuft keiner und ich hatte die Installation bereits mit augeschaltetem Windows-Defender durchgeführt. Danke schonmal für die Hilfe. VG

Habe ich bereits gemacht, ist dem Kunden aber recht egal. Mit den Konsequenzen lebt er und mit dem Softwarehaus wird er nicht reden... also von meiner Seite aus habe ich fertig. Der Kunde weiß Bescheid, mehr kann ich nicht tun. Richtig! War ja auch keine Beschwerde. Ich habe allerdings (leider) eine gewisse Technik-'Ehre' und Interesse/Neugier mich mit einem Problem zu beschäftigen und es adequat zu lösen... das mag dumm sein, aber da bin ich zu sehr in meiner Berufung um das auf sich beruhen zu lassen. Auch wenn dann nochmal 2 Stunden am Wochenende versenkt werden.

Mir zumindest sagt er es nicht, bzw. nicht genauer. Hab ich soweit gemacht, dachte mir schon dass es ohne Filter sonst quasi unmöglich hier etwas zu finden, da ist ja zu viel los. Ich schau mir am Wochenende auch mal das Video an, bzw. dann auch nochmal die Installations-Prozesse etwas genauer. Dass ich im ersten Moment nichts auffälliges gefunden habe heißt ja erstmal nicht. Dazu kann ich recht wenig sagen, ich kenne die Firma nicht wirklich, weiß nur dass es quasi 1 Geschäftsführer und sein Programmierer ist. Ich bin selbst auch kaum bewandert in Programmierung an sich, deswegen lehne ich mich da auch mal nicht zu weit aus dem Fenster. Ja wenn ich Zeit finde werde ich wie gesagt nochmal genauer schauen, ich habe schon echt viel Zeit versenkt, was mir wieder keiner bezahlt weil dem Kunden ist es natürlich komplett egal ob da ein Nutzer mit Dom-Admin-Rechten rumgeistert. Da kann ich dann auch sagen was ich will. Verstehen viele dann immer erst wenn es knallt. Also ich bin im Prinzip immer erstmal der Freund von einer friedlichen, kommunikativen Lösung und habe eigentlich auch keine Lust auf so eine Schlammschlacht und dieses 'hin und her - Schuld zuweisen'. Ich habe kein Druckmittel, weil des meinem Kunden erstmal egal ist und wenn die Firma auf stur schaltet dann kann ich erstmal nicht viel machen. Ich verstehe was du meinst, aber hier in meinem Fall wohl nicht the way to go. Danke euch allen für die schnelle Hilfe, ich habe meine Info wegen dem Process Monitor und werde schauen wie und ob ich damit zu Rande komme. Am Ende des Tages liegt es ja an den Berechtigungen, nur wo und wer und mit dem Tool und genügend Zeit wird sich das schon ermitteln lassen. Merci und VG.

Die Software ist nicht wirklich geheim, aber eine arge Nischen-Lösung, ich denke nicht dass diese hier Forenweit jemand einsetzt. Ich will auch dem Hersteller nicht zu Nahe treten, darum wollte ich jetzt erstmal keine Namen nennen; ist ja meines Erachtens auch nicht zielführen. Nicht durchkommen lassen sagt sich einfach.. das ist ein Ein-Mann-Programmierer, der sagt er hält sich an die Spezifikationen von Windows und kopiert/überschreibt nur Dateien innerhalb des Netzwerk-Pfads. Ich bin hier gestern schon auf Granit gestoßen, als ich sagte, dass die Berechtigungen dann ja ausreichend sein sollten. Wollte er so nicht verstehen; zumal es ja mit dem Domain-Admin-Rechten klappt.. nur toll ist dieser 'Workarround' ja ehr nicht. Es laufen 2 Applikationen auf dem (Terminal-)Server, der Webserver und der Applikations-Server. Und auf diesem (Terminal-)Server ist der 'programm_admin' in der Gruppe Administratoren. Also ja; ich kann mit diesem Benutzer auf dem Terminal-Server auch ohne Probleme in den Windows-Ordnern schreiben/Dateien erstellen/löschen. Ich kämpfe gerade mit den Prozess-Monitor/Explorer, aber finde hier erstmal nicht auffälliges. Ich kenne mich damit aber auch quasi nicht aus. Soweit ich sehen kann will der Installer nur auf den UNC Pfad zugreifen oder auf den lokalen Server... aber wie gesagt, ich kenne mich auch nicht wirklich mit dem Sysinternals-Tools aus. VG

Ja hat er, ich dachte das war klar mit meiner Formulierung 'Freigabe- und Sicherheitsberechtigungen'. Also ja Freigabe- und NTFS-Berechtigungen hat er. Und jeweils sogar 'Vollzugriff', auch wenn 'Ändern' ja mMn eigentlich reichen würde/bzw. richtig wäre. Nein über den UNC-Pfad genauso wenig. Ich hatte schon einige Versuche und Kombinationen probiert, auch mit der UAC gespielt, verschiedene Benutzer, Gruppen, RUNAS, etc. Hat erstmal alles nichts geholfen. Danke euch beiden, ich schaue mal ob ich mit dem Process Monitor/Explorer weiter komme. VG

Hallo zusammen, ich habe ein Problem mit einem Applikations-Update bei einem Kunden. Der Großteil der Software liegt auf einem Netzlaufwerk 'X:' (UNC-Pfad: \\SERVER\FREIGABE). Dieses ist auf dem DC als DFS-Freigabe eingerichtet. Für die Software laufen ein Applikations- und ein Web-Server. Diese laufen als Applikation auf einem gesonderten (Terminal-)Server. Hier befindet sich auch der Rest der Software-Daten in der Festplatten-Verzeichnisstruktur (C:\Software\) Der Kunde macht für die Applikation regelmäßig Updates. Diese werden über eine Art Manager heruntergeladen (EXE-Datei) und dann aufgeführt/installiert. Damit der Kunde diese Updates auf dem Server durchführen kann, habe ich einen dedizierten Benutzer 'programm_admin' angelegt, welcher sich am Terminal-Server anmelden kann und die Updates durführen soll. Innerhalb dieses Nutzers laufen auf Applikations- und Web-Server. Dieser (Domain-)Benutzer 'programm_admin' ist auf dem (Terminal-)Server in der Gruppe der Administratoren. Zusätzlich hat der auf die Netzwerkfreigabe 'X:' Vollzugriff (in Freigabe- und Sicherheitsberechtigungen). Dieser Benutzer kann das Update allerdings nicht durchführen! Das Programm gibt zurück 'Keine ausreichenden Berechtigungen - Starte erneut mit Benutzer mit höheren Berechtigungen, bitte warten..'. Hier passiert dann allerdings nichts mehr; man kann die Installation nur noch abbrechen. Wenn ich die Update-Installation allerdings mit dem Domain-Administrator durchführe, oder dem Benutzer 'programm_admin' die Domain-Admin-Berechtigungen gebe bzw. die Administrator-Berechtigung des DC, dann geht es einwandfrei. Ich verstehe leider nicht, warum das so ist. Der Benutzer hat doch Admin-Rechte auf dem (Terminal-)Server und auf die Freigabe ('X:'). Dies ist meiner Meinung nach doch alles was er benötigt, um das Programm-Update auf dem Terminal-Server zu installieren. Ich hatte gesehen, dass die EXE-Datei in das Benutzer-Verzeichnis TEMP in APPDATA entpackt wird, wenn man die Installation startet und bei der Fehlermeldung direkt verschwindet. Allerdings hat der Benutzer ja volle Berechtigung auf sein Benutzer-Verzeichnis; sollte ja soweit passen. Der Software Hersteller kann mir leider nicht weiterhelfen, die Verweisen darauf, dass es ein Berechtigungs-Problem ist, da es mit dem Domain-Admin klappt und ich das Problem selbst lösen müsste. Hat hier einer noch eine Idee, was hier noch fehlen könnte an Berechtigungen, oder was das Problem ist? Kann man ggf. irgendwie nachvollziehen, was die Installation für Prozesse versucht bzw. was für Verbindungen auf den DC? Irgendwelche Ansätze? Danke schonmal für die Mühen. Viele Grüße.