none
DPM 2012 SP1: Agent nach kurzer Zeit nicht mehr erreichbar RRS feed

 > 

  • Allgemeine Diskussion

  • Discussion
    Anmelden
    0
    Anmelden

    Hallo miteinander,

    ich habe ein seltsames Phänomen mit meinen beiden DPM-Servern. Hier erst mal meine Konstellation:

    DPM01 sichert Hyper-V-Host 01

    DPM02 sichert Hyper-V-Host 02

    DPM02 verliert nach einer erfolgreichen Sicherung der VMs auf Host 02 den Kontakt zum Agent (Der Agent ist nicht erreichbar; DPM Alert im Log: ID 3122, Dienst antwortet nicht)

    Dieser Zustand bleibt so lange bestehen, bis ich den Agent auf Host 02 manuell deinstalliere und danach neu von DPM02 ausrolle. Dann sichert er wieder 1x komplett, um danach wieder auszusteigen.

    Das Seltsame: Verbinde ich Host 02 mit DPM01, funktioniert die Sicherung wochenlang ohne Probleme.

    Und noch seltsamer: DPM02 sichert noch einen separaten Server, zu dem verlor er seit Monaten noch nie den Kontakt.

    Heute habe ich noch das aktuellste Updaterollup 5 für DPM installiert (auch die Agents wurden aktualisiert), aber es ändert sich nichts.

    Somit schließe ich, dass es an der Konfiguration (Firewall etc.) von Host 02 nicht liegen kann, da ja der DPM01 problemlos sichern kann. An einer grundsätzlich fehlerhaften Konfig auf DPM02 kann es aber auch nicht liegen, da er ja den separaten Server problemlos sichert. Was könnte es also dann noch sein?

    Danke vorab für jegliche Hilfe.

    Donnerstag, 30. Januar 2014 12:54
    |

Alle Antworten

  • Discussion
    Anmelden
    0
    Anmelden

    Hallo,

    ein paar Fragen, die vielleicht bei der Eingrenzung helfen können:

    Wie sieht es mit der Netzkonfiguration aus? Gibt es Firewalls oder Router zwischen den Systemen?

    Gibt es auf den Switches Auffälligkeiten?

    Sind Firmware und Treiber der NICs aktuell? (Host und DPM)

    Läuft der DPM als VM oder auf 'Blech'?

    Werden Hardwaresnapshots genutzt?

    Gibt es Fehler der VSS Writer auf dem problematischen Host? 'vssadmin list writers'

    Gibt es im Ereignisprotokoll des Hosts oder DPM Warnungen oder Fehler im fraglichen Zeitraum?

    This posting is provided >AS IS< with no warranties.

    Donnerstag, 30. Januar 2014 14:25
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Die beiden DPM-Server sind VMs (Win2012), die auf dem jeweils gegensätzlichen Host laufen, also DPM01 liegt auf Host 2, DPM02 auf Host 1. Beide Hosts sind auch Win2012 und laufen auf identischer Hardware, die zeitgleich aufgesetzt wurde. Entsprechend sind Treiber, Firmwares etc. identisch.

    An den Hosts hängt je 1 NAS (direkt per 10G, kein Switch dazwischen), auf die die DPMs per iSCSI zugreifen.

    Firewalls sind per Domänenprofil abgeschaltet, keine Router dazwischen. Hardwaresnapshots verwende ich keine.

    Die Sicherung hat einige Zeit (Okt-Dez) funktioniert, bis er irgendwann den Kontakt zum Agent erstmalig verloren hat. Ab da gings los.

    Im Ereignisprotokoll ist folgendes interessant:

    1. Alle 30 Minuten versucht der Host, mit dem DPM zu kommunizieren, schreibt aber ins Anwendungsprotokoll die ID 85, die sinngemäß lautet, dass er den DPM nicht erreichen konnte. Man solle eine etwaige Firewall kontrollieren. Error code: 0x167d5b0 (dieser wechselt aber bei jedem Eintrag)

    Gleichzeitig fällt auf, dass der DPMRA-Dienst auf dem Host aus ist. Starte ich ihn manuell und versuche vom DPM aus, den Agent zu aktualisieren, klappt das auch. Starte ich die verpassten Wiederherstellungspunkte, synchronisieren diese. Nachdem alle Haken wieder grün sind, verliert er aber wieder irgendwann den Kontakt. Starte ich den DPMRA kurzfristig neu, bringt das aber nichts. Erst wenn ich am nächsten Morgen den dann wieder inaktiven Dienst starte, funktioniert die Kommunikation wieder für eine kurze Zeit.

    Freitag, 31. Januar 2014 09:24
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo,

    dass der DPMRA Dienst nicht permanent läuft ist normal. Der wird bei Bedarf per DCOM vom DPM Server aus gestartet.

    Du könntest die Kommunikation von DPM zu Host durch lokale Firewall für alle Profile erlauben bzw. Prüfen, ob so eine Regel existiert. Nomalerweise sollten dafür bei der DPM Agent Installation oder bei 'Set-DPMServer' zwei Regeln erstellt werden (dpmra und DPMRA_DCOM_135). Manchmal funktioniert die NLA nicht zuverlässig und die Netzwerke werden als 'unbekannt' oder 'öffentlich' identifiziert und die Firewall macht dicht. Eventuell auch mal das Firewall-Log einschalten und prüfen, ob etwas geblockt wird.

    Ein weiterer Ansatz wäre das DPMRA Log auf dem Host. Die Protokolle findest Du unter 'C:\Program Files\Microsoft Data Protection Manager\DPM\Temp'. DPMRACurr.errlog ist das aktuelle.

    Mit CMTrace aus dem SCCM-iso oder einem anderen Logparser solltest Du recht schnell herausfinden können, ob und welche Fehler oder Warnungen auftreten.

    This posting is provided >AS IS< with no warranties.

    Freitag, 31. Januar 2014 10:21
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Das betreffende Netzwerk ist als Domänennetzwerk erkannt, die Firewall ist sicher abgeschaltet.

    Im Log auf dem Host erscheinen folgende Fehler:

    27E0    3D24    01/31    10:30:02.205    05    genericstatus.cpp(1256)    [00000000017073D0]    A6C6E53C-97E0-408F-8902-E2D1BDC96083    NORMAL    Wait for CallUpdateQfesInstalledRegKey succeeded. Returning m_QfesInstalled = 31
    27E0    3D24    01/31    10:30:02.205    03    schannelutils.cpp(129)        A6C6E53C-97E0-408F-8902-E2D1BDC96083    WARNING    Failed: Hr: = [0x80070002] : Error trying to open RegKey [HKLM\Software\Microsoft\Microsoft Data Protection Manager\Agent\2.0\Certificates\DE266030VS0004.DE25445X.local]
    27E0    3D24    01/31    10:30:02.205    05    genericstatus.cpp(1662)    [00000000017073D0]    A6C6E53C-97E0-408F-8902-E2D1BDC96083    NORMAL    majorVerNum[4], minorVerNum[1], buildNum[3426], hotfixNum[0]
    27E0    357C    01/31    10:30:45.355    04    cmdproc.cpp(2046)    [000000000149E590]    A6C6E53C-97E0-408F-8902-E2D1BDC96083    WARNING    Failed: Hr: = [0x800706ba] CCommandProcessor::CCIE failed on server DE266030SDPM02.DE25445X.local, mqi.hr = 0x800706ba, will retry
    27E0    357C    01/31    10:31:33.591    04    cmdproc.cpp(4191)    [000000000149E590]    A6C6E53C-97E0-408F-8902-E2D1BDC96083    WARNING    Failed: Hr: = [0x800706ba] CCommandProcessor::IsRetryRequired, Aborting retry as dwTicksElapsed > CMDPROC_RETRY_LIMIT_TICKS. sm_bIsShutdownReqd: 0
    27E0    357C    01/31    10:31:33.591    04    cmdproc.cpp(2054)    [000000000149E590]    A6C6E53C-97E0-408F-8902-E2D1BDC96083    WARNING    Failed: Hr: = [0x800706ba] CCommandProcessor::CCIE failed on server DE266030SDPM02.DE25445X.local, mqi.hr = 0x800706ba, No further retry
    27E0    357C    01/31    10:31:33.591    04    cmdproc.cpp(1878)    [000000000149E590]    A6C6E53C-97E0-408F-8902-E2D1BDC96083    WARNING    Attempted CreateInstance failed (fUseSpnWithRealm=false). Now retrying with SPNWithRealm
    27E0    357C    01/31    10:32:15.712    04    cmdproc.cpp(2046)    [000000000149E590]    A6C6E53C-97E0-408F-8902-E2D1BDC96083    WARNING    Failed: Hr: = [0x800706ba] CCommandProcessor::CCIE failed on server DE266030SDPM02.DE25445X.local, mqi.hr = 0x800706ba, will retry
    27E0    357C    01/31    10:33:03.823    04    cmdproc.cpp(4191)    [000000000149E590]    A6C6E53C-97E0-408F-8902-E2D1BDC96083    WARNING    Failed: Hr: = [0x800706ba] CCommandProcessor::IsRetryRequired, Aborting retry as dwTicksElapsed > CMDPROC_RETRY_LIMIT_TICKS. sm_bIsShutdownReqd: 0
    27E0    357C    01/31    10:33:03.823    04    cmdproc.cpp(2054)    [000000000149E590]    A6C6E53C-97E0-408F-8902-E2D1BDC96083    WARNING    Failed: Hr: = [0x800706ba] CCommandProcessor::CCIE failed on server DE266030SDPM02.DE25445X.local, mqi.hr = 0x800706ba, No further retry
    27E0    357C    01/31    10:33:03.823    04    cmdproc.cpp(2066)    [000000000149E590]    A6C6E53C-97E0-408F-8902-E2D1BDC96083    WARNING    Failed: Hr: = [0x800706ba] : Encountered Failure: : lVal : hr
    27E0    357C    01/31    10:33:03.823    04    cmdproc.cpp(2665)    [000000000149E590]    A6C6E53C-97E0-408F-8902-E2D1BDC96083    WARNING    CCommandProcessor::SendOutboundCommand this:[000000000149E590], ServerName: DE266030SDPM02.DE25445X.local
    27E0    357C    01/31    10:33:03.823    04    cmdproc.cpp(2765)    [000000000149E590]    A6C6E53C-97E0-408F-8902-E2D1BDC96083    WARNING    Logging event for error: 536871171, detailed: 0x16fd9c0
    27E0    2D7C    01/31    10:33:03.823    04    cmdproc.cpp(2066)    [000000000149E590]    A6C6E53C-97E0-408F-8902-E2D1BDC96083    WARNING    Failed: Hr: = [0x800706ba] : Encountered Failure: : lVal : hr
    27E0    2D7C    01/31    10:33:03.823    04    cmdproc.cpp(1890)    [000000000149E590]    A6C6E53C-97E0-408F-8902-E2D1BDC96083    WARNING    Failed: Hr: = [0x800706ba] : CreateInstance Failed (fUseSpnWithRealm=true) : lVal : hr
    27E0    2D7C    01/31    10:33:03.823    04    cmdproc.cpp(2420)    [000000000149E590]    A6C6E53C-97E0-408F-8902-E2D1BDC96083    WARNING    Failed: Hr: = [0x800706ba] : Encountered Failure: : lVal : CreateInstance( strCmdTarget, clsidTarget, hrDLS, (IUnknown **)&pAgentCommand, (pCommand->GetSenderToken() == 0), pCommand->IsNonDomainAgent(), fIsNonADMachine, cmdTargetIP )
    27E0    2F40    01/31    10:35:02.214    03    runtime.cpp(1429)    [00000000013A4EF0]        NORMAL    CDLSRuntime::ProcessIdleTimeout

    Ich hoffe, man kann damit was anfangen. Allerdings liegt für mich immer noch das Problem eher auf der Seite des DPM-Servers. Schließlich lässt dich der Host ja problemlos von einem anderen DPM-Server sichern (wenn man die Agent-Verbindung auf diesen umstellt). Nur hilft mir das nicht viel, da dann ja ein Host sich selbst sichert.

    Ich habe allerdings zwei andere Ideen, wären die sinnvoller:

    1. Ich kopiere den funktionierenden DPM01, nenne ihn z.B. DPM03 und ersetze damit testweise den DPM02. Kann man den Servernamen von DPM im laufenden Betrieb umbenennen, oder gibt es da etwas zu beachten (außer der SID-Neugenerierung für die Domäne)?

    2. Ich tausche die Server durch, also den DPM01 auf Host01 und den DPM02 auf Host02. DPM01 sichert dann Host02 und DPM02 sichert Host01. Das dürfte über die ohnehin stattfindende Replikation per geplantem Failover ja problemlos möglich sein, oder? Dann sehe ich zumindest, ob das Problem dann mit dem DPM02 mitwandert oder beim Host02 bleibt. Denn die Kombi DPM02 sichert Host01 habe ich noch nicht getestet.

    Freitag, 31. Januar 2014 11:09
    |
  • Discussion
    Anmelden
    1
    Anmelden

    Es sieht so aus, als ob es ein Problem mit dem Zertifikatsaustausch zwischen DPM und Host gibt.

    Vielleicht Dir der Troubleshooting Guide hier weiter:

    http://blogs.technet.com/b/dpm/archive/2012/07/23/dpm-certificate-troubleshooting-part-1-general-troubleshooting.aspx

    http://blogs.technet.com/b/dpm/archive/2012/07/24/dpm-certificate-troubleshooting-part-2-registry.aspx

    This posting is provided >AS IS< with no warranties.

    Freitag, 31. Januar 2014 11:31
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo,

    bist Du hier weitergekommen?

    Gruss,
    Raul

    Raul Talmaciu, MICROSOFT 
    Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.

    Montag, 3. Februar 2014 09:47
    |
  • Discussion
    Anmelden
    0
    Anmelden
    Sorry, dass ich mich erst jetzt melde. Ja, der Guide hat geholfen.
     Vielen Dank!
    Mittwoch, 6. Dezember 2017 07:50
    |