04.07.2017

8191

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

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 342395

Url: https://administrator.de/forum/rpc-dienst-funktioniert-vermutlich-nicht-342395.html

Ausgedruckt am: 22.12.2024 um 14:12 Uhr

21 Kommentare

Neuester Kommentar

Moin,

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

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ß

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

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,

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?
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

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

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

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

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

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

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.

Hi,

Zitat von @Nicolaas:
auf welchem Server sollte ich dann das Prüfen? Auf beiden?

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

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.

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

Hi,

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.

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:
~~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ß

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