21
RPC-Dienst funktioniert vermutlich nicht
Hallo zusammen,
ich betreibe Privat ein Netzwerk mit einem DC + Hyper-V für WSUS (S1) und einem Hyper-V-Host (S2).
Seid Sonntag funktioniert mein BackUp mit Veeam (Veeam Backup & Replication) nicht mehr.
Heute wollte ich mal überprüfen was das Problem ist
Dabei ist mir aufgefallen, das in der Hyper-V Console nicht mehr auf den jeweils anderen Server zugreifen kann.
Auch im Server Manager (S1) können alle Server nicht mehr aktualisiert werden.
Könnt Ihr mir kurz einige Tipps geben. Wo der Fehler sein könnte.
Gruß,
Nicolaas
ich betreibe Privat ein Netzwerk mit einem DC + Hyper-V für WSUS (S1) und einem Hyper-V-Host (S2).
Seid Sonntag funktioniert mein BackUp mit Veeam (Veeam Backup & Replication) nicht mehr.
Heute wollte ich mal überprüfen was das Problem ist
Dabei ist mir aufgefallen, das in der Hyper-V Console nicht mehr auf den jeweils anderen Server zugreifen kann.
Auch im Server Manager (S1) können alle Server nicht mehr aktualisiert werden.
Könnt Ihr mir kurz einige Tipps geben. Wo der Fehler sein könnte.
Gruß,
Nicolaas
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 342395
Url: https://administrator.de/contentid/342395
Printed on: April 18, 2024 at 12:04 o'clock
21 Comments
Latest comment
Moin,
Fehlermeldung im Veeam? Was steht am Host/in der VM im Eventlog? Notfalls die ganze Anlage mal durchbooten.
lg,
Slainte
Fehlermeldung im Veeam? Was steht am Host/in der VM im Eventlog? Notfalls die ganze Anlage mal durchbooten.
lg,
Slainte
Hallo Slainte,
Veeam:
Failed to call RPC function 'StartAgent': Ein Socketvorgang konnte nicht ausgeführt werden, da dem System Pufferspeicher fehlte oder eine Warteschlange voll war. Cannot connect to socket.
Eventlog:
DCOM konnte mit keinem der konfigurierten Protokolle mit dem Computer "S1.ad.burleigh.de" kommunizieren; angefordert von PID d18 (C:\Windows\system32\mmc.exe).
Leider sagt mir dern Fehler aus dem Eventlog nichts
LG Nicolaas
Veeam:
Failed to call RPC function 'StartAgent': Ein Socketvorgang konnte nicht ausgeführt werden, da dem System Pufferspeicher fehlte oder eine Warteschlange voll war. Cannot connect to socket.
Eventlog:
DCOM konnte mit keinem der konfigurierten Protokolle mit dem Computer "S1.ad.burleigh.de" kommunizieren; angefordert von PID d18 (C:\Windows\system32\mmc.exe).
Leider sagt mir dern Fehler aus dem Eventlog nichts
LG Nicolaas
Hi,
normalerweise hat jeder Eintrag auch Informationen zur Event-ID (EreignisID). Wenn man im unteren Feld auf Details > XML-Ansicht geht, bekommst du sehr viel Informationen, von denen du einiges mehr erfährst.
Die kann man sogar in die Zwischenablage packen.
Gruß
normalerweise hat jeder Eintrag auch Informationen zur Event-ID (EreignisID). Wenn man im unteren Feld auf Details > XML-Ansicht geht, bekommst du sehr viel Informationen, von denen du einiges mehr erfährst.
Die kann man sogar in die Zwischenablage packen.
Gruß
Hi,
meinst du etwa das hier:
- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
<Provider Name="Microsoft-Windows-DistributedCOM" Guid="{1B562E86-B7AA-4131-BADC-B6F3A001407E}" EventSourceName="DCOM" />
<EventID Qualifiers="0">10028</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x8080000000000000</Keywords>
<TimeCreated SystemTime="2017-07-04T12:21:38.826168300Z" />
<EventRecordID>198405</EventRecordID>
<Correlation />
<Execution ProcessID="932" ThreadID="72688" />
<Channel>System</Channel>
<Computer>S2.ad.domain.de</Computer>
<Security UserID="S-1-5-21-4267654618-2133829342-1311147331-500" />
</System>
- <EventData>
<Data Name="param1">S1.ad.domain.de</Data>
<Data Name="param2">d18</Data>
<Data Name="param3">C:\Windows\system32\mmc.exe</Data>
Gruß
Nicolaas
meinst du etwa das hier:
- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
<Provider Name="Microsoft-Windows-DistributedCOM" Guid="{1B562E86-B7AA-4131-BADC-B6F3A001407E}" EventSourceName="DCOM" />
<EventID Qualifiers="0">10028</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x8080000000000000</Keywords>
<TimeCreated SystemTime="2017-07-04T12:21:38.826168300Z" />
<EventRecordID>198405</EventRecordID>
<Correlation />
<Execution ProcessID="932" ThreadID="72688" />
<Channel>System</Channel>
<Computer>S2.ad.domain.de</Computer>
<Security UserID="S-1-5-21-4267654618-2133829342-1311147331-500" />
</System>
- <EventData>
<Data Name="param1">S1.ad.domain.de</Data>
<Data Name="param2">d18</Data>
<Data Name="param3">C:\Windows\system32\mmc.exe</Data>
Gruß
Nicolaas
meinst du etwa das hier
Genau das.
Und dann suchst du über eventid.net nach dem Source DCOM und der EventID 10028, was dir dort als mögliche Ursache angeboten wird.
Gruß
Hallo,
Was hat dein Blech an CPUs, RAM, Platten, RAID Kontroller, LAN Karten usw?
Was haben deine VMs zugewiesen an CPUs, RAM usw.
Was sagen deine Logs und welche Event IDs?
Gruß,
Peter
Zitat von @Nicolaas:
ich betreibe Privat ein Netzwerk mit einem DC + Hyper-V für WSUS (S1) und einem Hyper-V-Host (S2).
Hmmm, was ist denn wie aufgebaut? Einen DC mit Hyper-V und dort als VM einen Server 20XX fpr WSUS (S1) und dann noch einen Hyper-V auf ein anderes Blech - dein Hyper-V Host (S2) ?!? Oder ists alles nur ein Blech mit nur des hyper-V und alles andere sind VMs mit deinen DC, WSUS, und Host?ich betreibe Privat ein Netzwerk mit einem DC + Hyper-V für WSUS (S1) und einem Hyper-V-Host (S2).
Was hat dein Blech an CPUs, RAM, Platten, RAID Kontroller, LAN Karten usw?
Was haben deine VMs zugewiesen an CPUs, RAM usw.
Was sagen deine Logs und welche Event IDs?
Gruß,
Peter
HAllo Peter,
der Server Nr. 1 ist ein DC (Win2012 R2) + DNS, DHCP, WDS, Veeam und Hyper-V
Auf dem Hyper-V läuft nur eine VM (Win2012 R2 WSUS)
Server 2 ist ein HP ProLiant DL380 Gen7 der nur Hyper-V-Host ist. (auch W2012 R2)
Auf dem Laufen mehrere VMs mit z.B. Exchange, RDG, etc. und einem weiteren DC
Ich stelle mir gerade die Frage auf welchem Server der Fehler im EventLog stehen müsste.
Ich denke der Fehler müsste im DC1(S1) stehen, weil ich dort alle anderen Server auch nicht erreichbar sind.
Ist meine vermutung richtig?
Eimal durch Booten möchte ich den Hyper-V-Host (S2) nicht, weil dort auch die Sophos läuft.
Falls der Server nicht mehr richtig booten würde komme ich nicht mehr per remote drauf.
Gruß Nicolaas
der Server Nr. 1 ist ein DC (Win2012 R2) + DNS, DHCP, WDS, Veeam und Hyper-V
Auf dem Hyper-V läuft nur eine VM (Win2012 R2 WSUS)
Server 2 ist ein HP ProLiant DL380 Gen7 der nur Hyper-V-Host ist. (auch W2012 R2)
Auf dem Laufen mehrere VMs mit z.B. Exchange, RDG, etc. und einem weiteren DC
Ich stelle mir gerade die Frage auf welchem Server der Fehler im EventLog stehen müsste.
Ich denke der Fehler müsste im DC1(S1) stehen, weil ich dort alle anderen Server auch nicht erreichbar sind.
Ist meine vermutung richtig?
Eimal durch Booten möchte ich den Hyper-V-Host (S2) nicht, weil dort auch die Sophos läuft.
Falls der Server nicht mehr richtig booten würde komme ich nicht mehr per remote drauf.
Gruß Nicolaas
Hi Nicolaas,
ich hab genau das gleiche Problem und dreh mich seit ein paar Wochen damit im Kreis.
Struktur:
1 HyperV Host, auch VEEAM (Windows 2016 Std Server)
4 virtuelle Server im HyperV (DC/EXCHSRV/E-Mail Archive/TS)
Auf dem HyperV Host, läuft außer dem Backup nichts unternehmenskritisches.
Was ich bisher rausgefunden hab:
Wenn ich den HyperV Host neu starte, läuft alles ohne Probleme, .. nach ca. 20-36h ist dann wieder Ende.
- Ich komme über den Browser nicht mehr auf alle Seiten
- VEEAM knn keine Backups mehr durchführen, weil die Konsole den Server nicht findet
- im HyperV Manager kann ich die nicht mehr auf die Konsolenansicht der virtuellen Gastsysteme
- selbst interne Appliance auf die ich via Browser HTTP zugreifen möchte geht nichts mehr..!
Die Fehlermeldung springt mir bei verschiedenen Systemen immer wieder entgegen:
"ein Socketvorgang konnte nicht ausgeführt werden, da dem System Pufferspeicher fehlte oder eine Warteschlange voll ..."
Fehler bei der Anforderung zum Zuordnen einer kurzlebigen Portnummer aus dem globalen TCP-Portanschluss, da alle diese Ports derzeit verwendet werden.
Ich habe durch Dr. Google schon von Anfang an folgenden Workarround gefunden:
Link SupportForum Microsoft
Diesen Weg aber noch nicht ausprobiert, bisher alles Netzwerkseitige überprüft und aktualisiert, d.h. Treiber, Virtual Switch aufgelöst, neu erstellt usw.. und immer wieder nach 1 bis 1/2 Tagen geht nix mehr....
Ich wurschtel nicht gerne einfach so in der Registrierung rum, die HighPorts könnten schon Auslöser des Problems sein, was zumindest diese seltsame Tatsache erklärt dass einige Zugriffe absolut nicht gehen, andere schon. . .. (egal ob intern oder extern)
Was mich jetzt ein bissl irritiert ist, dass Du auch VEEAM einsetzt - denn mir wäre es lieber die Ursache zu finden, als irgend eine Lösung bei der ich nicht genau abschätzen kann was das in Zukunft genau bedeutet.
Neustarten hat also bisher eher eine "heilende Wirkung" allerdings hält dies nicht lange an.
besten Gruß - chriz
ich hab genau das gleiche Problem und dreh mich seit ein paar Wochen damit im Kreis.
Struktur:
1 HyperV Host, auch VEEAM (Windows 2016 Std Server)
4 virtuelle Server im HyperV (DC/EXCHSRV/E-Mail Archive/TS)
Auf dem HyperV Host, läuft außer dem Backup nichts unternehmenskritisches.
Was ich bisher rausgefunden hab:
Wenn ich den HyperV Host neu starte, läuft alles ohne Probleme, .. nach ca. 20-36h ist dann wieder Ende.
- Ich komme über den Browser nicht mehr auf alle Seiten
- VEEAM knn keine Backups mehr durchführen, weil die Konsole den Server nicht findet
- im HyperV Manager kann ich die nicht mehr auf die Konsolenansicht der virtuellen Gastsysteme
- selbst interne Appliance auf die ich via Browser HTTP zugreifen möchte geht nichts mehr..!
Die Fehlermeldung springt mir bei verschiedenen Systemen immer wieder entgegen:
"ein Socketvorgang konnte nicht ausgeführt werden, da dem System Pufferspeicher fehlte oder eine Warteschlange voll ..."
Fehler bei der Anforderung zum Zuordnen einer kurzlebigen Portnummer aus dem globalen TCP-Portanschluss, da alle diese Ports derzeit verwendet werden.
Ich habe durch Dr. Google schon von Anfang an folgenden Workarround gefunden:
Link SupportForum Microsoft
Diesen Weg aber noch nicht ausprobiert, bisher alles Netzwerkseitige überprüft und aktualisiert, d.h. Treiber, Virtual Switch aufgelöst, neu erstellt usw.. und immer wieder nach 1 bis 1/2 Tagen geht nix mehr....
Ich wurschtel nicht gerne einfach so in der Registrierung rum, die HighPorts könnten schon Auslöser des Problems sein, was zumindest diese seltsame Tatsache erklärt dass einige Zugriffe absolut nicht gehen, andere schon. . .. (egal ob intern oder extern)
Was mich jetzt ein bissl irritiert ist, dass Du auch VEEAM einsetzt - denn mir wäre es lieber die Ursache zu finden, als irgend eine Lösung bei der ich nicht genau abschätzen kann was das in Zukunft genau bedeutet.
Neustarten hat also bisher eher eine "heilende Wirkung" allerdings hält dies nicht lange an.
besten Gruß - chriz
Hi,
versuch mal, ob du mit TCPView von Microsoft-Sysinternals rausbekommen kannst, welches Programm oder welcher Dienst die TCP/UDP-Port belegt, evtl. kannst du damit einige schließen bzw. Sockets freigeben. Das kannst du online holen und auch starten: https://live.sysinternals.com/tcpview.exe
Gruß
Edit: Der Tipp gilt natürlich auch für den TO @Nicolaas
versuch mal, ob du mit TCPView von Microsoft-Sysinternals rausbekommen kannst, welches Programm oder welcher Dienst die TCP/UDP-Port belegt, evtl. kannst du damit einige schließen bzw. Sockets freigeben. Das kannst du online holen und auch starten: https://live.sysinternals.com/tcpview.exe
Gruß
Edit: Der Tipp gilt natürlich auch für den TO @Nicolaas
Hey huganotter,
bombe, danke für den Tipp!
Werde ich checken sobald der Fehler wieder auftritt, im Moment sehe ich natürlich viele Anwendungen und Dienste - noch funktioniert aber alles bestens.. (Weil ich heute Abend das System neu gestartet hab...
gruß chriz
bombe, danke für den Tipp!
Werde ich checken sobald der Fehler wieder auftritt, im Moment sehe ich natürlich viele Anwendungen und Dienste - noch funktioniert aber alles bestens.. (Weil ich heute Abend das System neu gestartet hab...
gruß chriz
Hi,
Vielen Dank schon mal für den Tipp :D
auf welchem Server sollte ich dann das Prüfen? Auf beiden?
Ich bekomme leider die EXE gerade nicht auf den Hyper-V-Host (S2), weil dieser nicht mal mehr eine Verbindung mit dem InternetExplorer aufbauen möchte.
Netzwerkfreigabe will er auch nicht mehr
Also vermutlich neustarten Exe kopieren und warten bis der Fehler wieder da ist. Richtig?
Gruß
Nicolaas
Vielen Dank schon mal für den Tipp :D
auf welchem Server sollte ich dann das Prüfen? Auf beiden?
Ich bekomme leider die EXE gerade nicht auf den Hyper-V-Host (S2), weil dieser nicht mal mehr eine Verbindung mit dem InternetExplorer aufbauen möchte.
Netzwerkfreigabe will er auch nicht mehr
Also vermutlich neustarten Exe kopieren und warten bis der Fehler wieder da ist. Richtig?
Gruß
Nicolaas
Habt ihr zufällig iSCSI Ziele bei euch? Bzw welche die nicht mehr vorhanden sind, aber der Client versucht sich immer noch damit zu verbinden? Ist zurzeit ein Fehler von einem Update, habe mich auch Totgesucht und endlich darauf gestoßen.
Auf diesem Server nicht - nur ein eingebundenes Netzwerklaufwerk der E-Mail Archivierungslösung (MSFT Virtual Disk)
Allerdings ist der von Dir angesprochene Fehler interessant, hast Du da nähere Infos? (hab mehrere Server mit ISCSI Anbindung laufen)
lg
Allerdings ist der von Dir angesprochene Fehler interessant, hast Du da nähere Infos? (hab mehrere Server mit ISCSI Anbindung laufen)
lg
Hier ein Link dazu iSCSI Fehler
Ich war davon betroffen. Trifft eben zu, wenn die iSCSI Ziele die ganze Zeit auf Reconnect stehen. Konnte mich nach einer Weile nicht mehr per RDP Anmelden etc.
Ich war davon betroffen. Trifft eben zu, wenn die iSCSI Ziele die ganze Zeit auf Reconnect stehen. Konnte mich nach einer Weile nicht mehr per RDP Anmelden etc.
1
Hi,
Ich würde mal mit dem anfangen, von dem du die XML aus dem Eventlog kopiert hast,
Gruß
Ich würde mal mit dem anfangen, von dem du die XML aus dem Eventlog kopiert hast,
Gruß
Ich denke auch dass NUR der Host das Problem hat. . . .
DC auf Host ist halt auch eher suboptimal - der wirkliche Vorteil einer Virtualisierung geht dabei irgendwie flöten
DC auf Host ist halt auch eher suboptimal - der wirkliche Vorteil einer Virtualisierung geht dabei irgendwie flöten
Nach einem Server neustart funktioniert der der Hyper-V-Host (S2) wieder.
mal sehen
Ich habe das letzte Update in verdacht, weil 2 Tage nach dem Updates die Probleme gekommen sind.
mal sehen
Ich habe das letzte Update in verdacht, weil 2 Tage nach dem Updates die Probleme gekommen sind.
Schönen guten Morgen,
nun ist es wieder soweit, der Server steckt wieder in diesem Problem fest, mit TCPView kann ich die Verbindungen sehen,
vom Status her sind sie aber meiner Meinung nach alle "ok"
Entweder LISTENING, ETABLISHED oder ab und an mal SYN_SEND
Mir fällt ansonsten nichts auffälliges auf, außer dass es 119 Endpoints sind mit der Option "Show unconnected Endpoints" - nehme ich hier den Haken weg sind es nur noch 15.
Kann es sein, dass die Ports nach und nach nicht mehr freigegeben werden?
Bin hier wirklich ratlos. . .
viele Grüße, c
nun ist es wieder soweit, der Server steckt wieder in diesem Problem fest, mit TCPView kann ich die Verbindungen sehen,
vom Status her sind sie aber meiner Meinung nach alle "ok"
Entweder LISTENING, ETABLISHED oder ab und an mal SYN_SEND
Mir fällt ansonsten nichts auffälliges auf, außer dass es 119 Endpoints sind mit der Option "Show unconnected Endpoints" - nehme ich hier den Haken weg sind es nur noch 15.
Kann es sein, dass die Ports nach und nach nicht mehr freigegeben werden?
Bin hier wirklich ratlos. . .
viele Grüße, c
Hi,
119 sollten problemlos verkraftbar sein, ich hatte auf meinem Desktop-System schon über 250 zusammen mit den unconneted
Kann sein, das kann ich aber nicht beurteilen, da ich nur ein Desktopsystem bediene. Normalerweise verschwinden die aber wieder, wenn der in der Registry konfigurierte Timeout abgelaufen ist. Ich hätte da einen Link zu den Einstellungen zur Hand, du könntest ja mal vergleichen:
https://msdn.microsoft.com/en-us/library/ms884977.aspx
Sorry, hatte den falschen Link erwischt, hier der richtige:
https://msdn.microsoft.com/en-us/library/dn167252.aspx
Bei den LISTENING Connections sind aber hier nur SYSTEM oder Systemdienste, die angezeigt werden, das dürfte normal sein. Achte mal auf die Local- und Remote-Address, die sollte 0 bzw localhost sein, und die verwendeten Ports sollten auch der Standardverwendung entsprechen.
Hier noch was zu den Sockets und dem dafür benötigten Speicher,
dort liegt ja wohl der Fehler lt. Fehlermeldung:
https://stackoverflow.com/questions/22025623/how-many-tcp-sockets-can-i- ...
Vielleicht findet noch hat noch jemand einen Lösungsvorschlag zur Hand, ich muss hier passen.
Gruß
Zitat von @sysobsysob13:
Mir fällt ansonsten nichts auffälliges auf, außer dass es 119 Endpoints sind mit der Option "Show unconnected Endpoints" - nehme ich hier den Haken weg sind es nur noch 15.
Mir fällt ansonsten nichts auffälliges auf, außer dass es 119 Endpoints sind mit der Option "Show unconnected Endpoints" - nehme ich hier den Haken weg sind es nur noch 15.
119 sollten problemlos verkraftbar sein, ich hatte auf meinem Desktop-System schon über 250 zusammen mit den unconneted
Kann es sein, dass die Ports nach und nach nicht mehr freigegeben werden?
Kann sein, das kann ich aber nicht beurteilen, da ich nur ein Desktopsystem bediene.
Normalerweise verschwinden die aber wieder, wenn der in der Registry konfigurierte Timeout abgelaufen ist. Ich hätte da einen Link zu den Einstellungen zur Hand, du könntest ja mal vergleichen:Sorry, hatte den falschen Link erwischt, hier der richtige:
https://msdn.microsoft.com/en-us/library/dn167252.aspx
Bei den LISTENING Connections sind aber hier nur SYSTEM oder Systemdienste, die angezeigt werden, das dürfte normal sein. Achte mal auf die Local- und Remote-Address, die sollte 0 bzw localhost sein, und die verwendeten Ports sollten auch der Standardverwendung entsprechen.
Hier noch was zu den Sockets und dem dafür benötigten Speicher,
dort liegt ja wohl der Fehler lt. Fehlermeldung:
https://stackoverflow.com/questions/22025623/how-many-tcp-sockets-can-i- ...
Vielleicht findet noch hat noch jemand einen Lösungsvorschlag zur Hand, ich muss hier passen.
Gruß
Ich glaube Du hast recht @geocast..! Zumindest war auf dem Server was, was eigentlich nicht sein durfte - ein Fragment von einer ISCSI Anbindung!, bin gespannt - nur noch zwei mal schlafen - wenn es dann noch läuft hast damit voll ins schwarze getroffen!
lg
lg
Yep, das wars..! Besten Dank @geocast für den Tipp - mein Problem hat sich damit gelöst...
