COM-Sicherheit für VSS - manuelle Einrichtung immer notwendig?

G

grefabu

Well-Known Member
May 23, 2018
252
18
58
51
Moin,

muss man bei der Installation des qemu Agent auf einem Windows System die COM-Sicherheit für den lokalen Netzwerkdienst jedesmal manuell einrichten?
Oder sollte das bei der Installationdes Agent automatisch gesetzt werden?

Bin nur mal wieder über die VSS Fehlermeldung gestolpert,...

Viele Grüße

Gregor
 
Was für eine Fehlermeldung hast du? Ich habe biser noch nie eine Fehlermeldung durch die Virtio Tools.
 
Ich meinte solche Sicherheitsmeldungen aus dem Gastsystem:
Code: 
Volume Shadow Copy Service error: Unexpected error querying for the IVssWriterCallback interface.  hr = 0x80070005, Access is denied.
. This is often caused by incorrect security settings in either the writer or requestor process.

Über einen Threat hier im Forum bin ich dann darauf gestoßen, dem Netzwerkdienst Rechte an der COM Schnittstelle zu geben.
Den Gast Agenten habe ich einfach über das virtio CDImage installiert.
 
Den VSS Fehler konnte ich bisher nicht beobachten und ich installiere immer einfach über die .exe auf dem iso.
 
Ich habe das gleiche Problem und konnte es nachstellen: Netzwerkservice hinzugefügt und es läuft (bzw. es kommen keine Meldungen mehr).

Ich nutze Server 2022 März sowie die aktuellste virt-io.iso. Ggf. wenn man das System sypreped?
 
Moin,

ich habe das noch mal getestet.
Ich vermutete erst, es wären nur die von Hyper-V migrierten Maschinen betroffen.
Gestern eine neue (englische) Windows Server 2022 aufgesetzt.
Da besteht das Problem ebenfalls.
Es handelt sich um die aktuellen stabilen virtio (0.1.240). werde es noch mal mit der 0.1.248 versuchen.

Grüße

Gregor
 
Habe das Problem ebenfalls: Sauber neu aufgesetzter Windows Server 2022 Standard (deutsch) mit VirtIO 0.1.248, und bei jedem Backup erscheinen im Eventlog vier kritische VSS-Events 8194 mit Dhcp Jet Writer und Systemwriter. Dem Netzwerkdienst in DCOM lokalen Zugriff zu erlauben, hilft nicht.

Auf VirtIO 0.1.262_2 upzugraden traue ich mich nicht, damit habe ich schon zu viele Server geschrotet.
 
kasto said:
Habe das Problem ebenfalls: Sauber neu aufgesetzter Windows Server 2022 Standard (deutsch) mit VirtIO 0.1.248, und bei jedem Backup erscheinen im Eventlog vier kritische VSS-Events 8194 mit Dhcp Jet Writer und Systemwriter. Dem Netzwerkdienst in DCOM lokalen Zugriff zu erlauben, hilft nicht.

Auf VirtIO 0.1.262_2 upzugraden traue ich mich nicht, damit habe ich schon zu viele Server geschrotet.
Click to expand...
Wie hast du denn die Server geschrottet?
Ich habe einige Kunden die schon auf 262_2 geupdatet haben und ich nutze die Version inzwischen auch und habe noch nicht einen Fehler gesehen.
 
Moin, ich kann das aber auch jedes Mal im Eventlog bei meinen Windows-VMs sehen – immer dann, wenn der PBS ein Backup der VM macht.
 
Hier das gleiche Problem. Frisch aufgesetzte Windows Server 2025 Version.
Die Rechtevergabe für die Netzwerkservice Gruppe bringt nichts.
 
macindy said:
Hier das gleiche Problem. Frisch aufgesetzte Windows Server 2025 Version.
Die Rechtevergabe für die Netzwerkservice Gruppe bringt nichts.
Click to expand...
Hast du die VM neu gestartet? Für mich wird das Problem durch den Eintrag gelöst. Habe es auf Server 2019 und Server 2025 VMs getestet. Allerdings wirkt die Einstellung bei mir erst nach VM reboot.
 
Ich lasse mal den Thread neu aufleben.
Mittlerweile habe ich nahezu alle meine Windows 2022 Maschinen von VMware zu PVE migriert (hoffentlich drehe ich nächste Woche den letzten esxi ab) und sichere die Maschinen mit

a) Veeam B&R V13 und
b) Proxmox Backup Server

Als virtio Treiber verwende ich die Version 0.1.271 da mir mit den 0.1.285 iSCSI um die Ohren fliegt.

Ich musste auf allen 2022 Maschinen über die dcomcnfg dem Netzwerkdienst die entsprechenden lokalen Rechte um den VSS Fehler (ID 8194), der während einer Sicherung mit dem Proxmox Backup Server auftritt, zu beseitigen.

Der Fehler tritt komischerweise nicht auf, wenn ich mit Veeam sichere und hier das application aware backup im Job aktiviert ist.

Nun zu meinen Fragen:
- warum wird während der Sicherung mit dem Proxmox Backup Server kein Fehler im Backup-Log selbst angezeigt. Derr VSS Freeze sieht im Server-Log fehlerlos aus, obwohl in der VM der Fehler mit ID 8194 geworfen wird
- wie füge ich bei einem Windows Server Core die entsprechenden Rechte (DCOM Netzwerkdienst) hinzu? dcomcnfg steht ja bei core Installationen nicht zur Verfügung und ich stehe gerade am Schlauch wie ich die Rechteänderung umsetzen soll

Vielen Dank schon mal
 
aL1aL7 said:
Ich lasse mal den Thread neu aufleben.
Mittlerweile habe ich nahezu alle meine Windows 2022 Maschinen von VMware zu PVE migriert (hoffentlich drehe ich nächste Woche den letzten esxi ab) und sichere die Maschinen mit

a) Veeam B&R V13 und
b) Proxmox Backup Server

Als virtio Treiber verwende ich die Version 0.1.271 da mir mit den 0.1.285 iSCSI um die Ohren fliegt.

Ich musste auf allen 2022 Maschinen über die dcomcnfg dem Netzwerkdienst die entsprechenden lokalen Rechte um den VSS Fehler (ID 8194), der während einer Sicherung mit dem Proxmox Backup Server auftritt, zu beseitigen.
Click to expand...
Kannst du mir diesen Fehler etwas näher beschreiben? Wie äußert sich der? Ich habe bei meinen Kunden mehrere Hundert 2022 VMs welche alle per PBS gesichert werden, aber mir ist noch kein Fehler aufgefallen.
aL1aL7 said:
Der Fehler tritt komischerweise nicht auf, wenn ich mit Veeam sichere und hier das application aware backup im Job aktiviert ist.

Nun zu meinen Fragen:
- warum wird während der Sicherung mit dem Proxmox Backup Server kein Fehler im Backup-Log selbst angezeigt. Derr VSS Freeze sieht im Server-Log fehlerlos aus, obwohl in der VM der Fehler mit ID 8194 geworfen wird
- wie füge ich bei einem Windows Server Core die entsprechenden Rechte (DCOM Netzwerkdienst) hinzu? dcomcnfg steht ja bei core Installationen nicht zur Verfügung und ich stehe gerade am Schlauch wie ich die Rechteänderung umsetzen soll
Click to expand...
Was genau änderst du denn da? Eventuell hilft das ja nachzuvollziehen und eventuell einen anderen Workaround zu schaffen.
 
Falk R. said:
Kannst du mir diesen Fehler etwas näher beschreiben? Wie äußert sich der? Ich habe bei meinen Kunden mehrere Hundert 2022 VMs welche alle per PBS gesichert werden, aber mir ist noch kein Fehler aufgefallen.
Click to expand...
In der Windows VM taucht zum Zeitpunkt des Freeze vom guest agent folgender Eintrag mit ID 8194 im Ereignisprotokoll auf:


Code: 
Volumeschattenkopie-Dienstfehler: Beim Abfragen nach der Schnittstelle "IVssWriterCallback" ist ein unerwarteter Fehler aufgetreten. hr = 0x80070005, Zugriff verweigert
. Die Ursache hierfür ist oft eine falsche Sicherheitseinstellung im Schreib- oder Anfrageprozess.

Vorgang:
   Generatordaten werden gesammelt

Kontext:
   Generatorklassen-ID: {e8132975-6f93-4464-a53e-1050253ae220}
   Generatorname: System Writer
   Generatorinstanz-ID: {53f37134-22c7-48fb-9427-8fa3aac3bdb0}

Im Betrieb der Maschine merke ich gar nichts davon. Ich bin mir nur nicht sicher ober der Freeze für ein application aware backup wirklich funktioniert hat und mein Backup wirklich konsistent ist. Wenn ich in der Windows Maschine mit dcomcnfg dem Netzwerkdienst lokale Rechte einräume und die Maschine neu starte ist der Fehler weg.


Falk R. said:
Was genau änderst du denn da? Eventuell hilft das ja nachzuvollziehen und eventuell einen anderen Workaround zu schaffen.
Click to expand...
Meinst Du was ich für das Veeam Backup ändere? Gar nichts, da tauchen die Fehler in der VM einfach nicht auf. Habe auch schon mit einem solchen Backup testweise einzelne Mails vom Exchange wieder zurück in die Postfächer restored - hat ohne Probleme funktioniert - diese Backups scheinen sauber zu sein.
 
Last edited:
aL1aL7 said:
In der Windows VM taucht zum Zeitpunkt des Freeze vom guest agent folgender Eintrag mit ID 8194 im Ereignisprotokoll auf:


Code: 
Volumeschattenkopie-Dienstfehler: Beim Abfragen nach der Schnittstelle "IVssWriterCallback" ist ein unerwarteter Fehler aufgetreten. hr = 0x80070005, Zugriff verweigert
. Die Ursache hierfür ist oft eine falsche Sicherheitseinstellung im Schreib- oder Anfrageprozess.

Vorgang:
   Generatordaten werden gesammelt

Kontext:
   Generatorklassen-ID: {e8132975-6f93-4464-a53e-1050253ae220}
   Generatorname: System Writer
   Generatorinstanz-ID: {53f37134-22c7-48fb-9427-8fa3aac3bdb0}

Im Betrieb der Maschine merke ich gar nichts davon. Ich bin mir nur nicht sicher ober der Freeze für ein application aware backup wirklich funktioniert hat und mein Backup wirklich konsistent ist. Wenn ich in der Windows Maschine mit dcomcnfg dem Netzwerkdienst lokale Rechte einräume und die Maschine neu starte ist der Fehler weg.
Click to expand...
Steht da auf welcher Partition der Fehler auftritt? Ich kenne den Fehler, wenn man per VMware Tools oder Virtio Tools ein konsistentes Backup macht, dann kann er keinen Snapshot der Windows Widerherstellungspartition machen. Das kann man ignorieren, viele löschen diese Partition auch nach der Windowsinstallation.
aL1aL7 said:
Meinst Du was ich für das Veeam Backup ändere? Gar nichts, da tauchen die Fehler in der VM einfach nicht auf. Habe auch schon mit einem solchen Backup testweise einzelne Mails vom Exchange wieder zurück in die Postfächer restored - hat ohne Probleme funktioniert - diese Backups scheinen sauber zu sein.
Click to expand...
Ich meine die Äderung mit dmconfig.
Du hast oben geschrieben, dass du lokale Rechte dem Netzwerkdienst gibst, das ist für mich jetzt nicht logisch, denn der sollte damit eigentlich gar nichts zu tun haben.
 
Falk R. said:
Ich meine die Äderung mit dmconfig.
Du hast oben geschrieben, dass du lokale Rechte dem Netzwerkdienst gibst, das ist für mich jetzt nicht logisch, denn der sollte damit eigentlich gar nichts zu tun haben.
Click to expand...
Hm, das steht aber auch so im Proxmox Wiki und hat auch dafür gesorgt dass die ID 8194 nicht mehr im Windows Protokoll auftaucht
https://pve.proxmox.com/wiki/VM_Backup_Consistency

Note: VSS Event 8194 Access Denied
If you check the Event Viewer → Windows → Application and filter for source VSS, you might see error events with the Event ID 8194.

To fix this, run the dcomcnfg tool via Start (right click) → Run. Go to Console Root → Component Services → Computers → My Computer (right click → Properties). In the tab COM Security in the Access Permission parts, edit the defaults and add the NETWORK SERVICE user and allow Local Access.

Reboot the VM for the changes to take effect.
Click to expand...
Falk R. said:
Steht da auf welcher Partition der Fehler auftritt? Ich kenne den Fehler, wenn man per VMware Tools oder Virtio Tools ein konsistentes Backup macht, dann kann er keinen Snapshot der Windows Widerherstellungspartition machen. Das kann man ignorieren, viele löschen diese Partition auch nach der Windowsinstallation.
Click to expand...

Nee, keine Ahnung auf welcher Partition das auftritt oder ob jeder betroffen ist.

Der Threadersteller und @SERvus hatten ja das gleiche Problem
 
Ich habe mal nachgelesen, der Fehler verhindert nur eine korrekte Kommunikation vom VSS Dienst zur Backupsoftware. Damit bekommt die Backupsoftware keine korrekte Antwort ob der VSS Snapshot erfolgreich war.
Den PBS interessiert das nicht, ich wüsste nicht das diese Information irgendwo abgefragt oder ausgewertet wird.
Veeam verlässt sich beim Konsistent Machen per VMware Tools (ohne Guest Interaction) auch auf den vSphere Status.
Daher ist das noch nie als echtes Problem bei mir aufgeschlagen.
Der VSS Snapshot ist ja trotzdem erfolgreich, was auch so im Eventlog steht.

Veeam mit Guest Interaction, führt einen lokalen Agent aus und nutzt daher auch keine Netzwerkkommunikation mit VSS.
 
Alles klar, Danke für Deine Hilfe.

Das mit Veeam wusste ich nicht, dachte für den VSS Snapshot nutzen die bei PVE-Backups auch den qemu-agent, das erklärt natürlich warum bei Veeam der Fehler mit ID8194 nicht im Windows Log auftaucht.

Für die Windows Maschinen ignoriere ich den Fehler jetzt mal, wenn der PBS ein Backup macht.
 
Auch auf vSphere werden die Tools nur genutzt, wenn man das aktiv anklickt und kein Application Aware aktiviert.
Bei Application Aware musst du ja Zugangsdaten zur VM angeben und Veeam verbindet sich direkt auf die VM und der Hypervisor macht dann gar nichts mehr mit VSS.
 
You must log in or register to reply here.
Top Bottom
Back