Exchange 2016: 451 4.7.0 Temporary server error. Please try again later. PRX2

Vor längerer Zeit hatte ich schon einmal auf den folgenden Fehler hingewiesen, hier in Zusammenhang mit Exchange 2013:

Wenn E-Mails nicht zugestellt werden können und Exchange den Fehler “451 4.7.0 Temporary server error. Please try again later. PRX2” in den Warteschlangen anzeigt, kann dies aber noch einen weiteren Grund haben. Dies gilt sowohl für Exchange 2013 als auch für Exchange 2016/2019.

Ursache des Fehlers sind nahezu immer Probleme mit dem DNS und zwar nicht immer zwingend am DNS-Server selbst, wie im oben verlinkten Artikel beschrieben, sondern auch an den DNS Einstellungen des Exchange Servers.

Gerade in sehr kleinen Umgebungen findet sich oft die folgende DNS Konfiguration auf Servern und Clients:

Exchange 2016: 451 4.7.0 Temporary server error. Please try again later. PRX2

In sehr kleinen Umgebungen gibt es beispielsweise nur einen Domain Controller, welcher auch als DNS Server genutzt wird. In diesem Beispiel hat der DC die IP 192.168.100.1 und ist als bevorzugter DNS Server eingestellt. Da es keinen weiteren DC als DNS Server gibt, wird hier häufig ein DNS Forwarder als alternativer DNS-Server eingetragen, hier in diesem Beispiel der Router.

Der Grund warum hier beispielsweise ein Router als alternativer DNS-Server angegeben wird: Wenn der DC ausfällt, habe ich wenigstens noch eine Namensauflösung und kann beispielsweise im Internet surfen. Wenn natürlich der einzige Domain Controller ausfällt, hat man allerdings trotzdem ein Problem: Ohne DNS und Active Directory funktioniert auch Exchange nicht mehr. Im Internet kann man dann vielleicht noch surfen, viel mehr geht aber nicht mehr.

Mit dieser Konfiguration hat Exchange aber ein Problem. Exchange benutzt alle konfigurierten DNS-Server, nicht nur den bevorzugten DNS Server. Dies macht ja auch Sinn, denn so erreicht man auf sehr einfache Weise eine einfache Lastverteilung über alle konfigurierten DNS Server.

In den meisten kleinen Umgebungen kann aber beispielsweise der Router nicht die DNS-Zonen des Active Directory auflösen. Router und diverse andere alternative “Nicht-DC-DNS-Server” leiten DNS-Abfragen zwar an DNS-Server im Internet weiter, können aber mit DNS-Abfragen an die “Underscore Zones (Bsp: _msdcs)” nichts anfangen und liefern ein NX-Domain (Domain oder Eintrag existiert nicht) zurück.

In diesem Beispiel würde also eine DNS-Abfrage für “gc._msdcs.frankysweb.local” gegen den bevorzugten DNS-Server (Domain Controller) erfolgreich sein und die IP Adresse des Domain Controllers liefern. Die gleiche DNS-Anfrage an den Router würde jedoch mit “non-existent domain (NX-Domain)” beantwortet werden:

Exchange 2016: 451 4.7.0 Temporary server error. Please try again later. PRX2

Hier ist auch der Grund für den Fehler “451 4.7.0 Temporary server error. Please try again later. PRX2”, Exchange findet seinen Domain Controller nicht mehr, bzw. kann relevante DNS-Einträge nicht auflösen.

Lösung:

In solch kleinen Umgebungen kann auf den alternativen DNS Server für Exchange Server verzichtet werden. Fällt der Domain Controller aus, hat man eh ein Problem und den Exchange Server wird eh niemand zum surfen benutzen.

Exchange 2016: 451 4.7.0 Temporary server error. Please try again later. PRX2

Bei einigen Routern ist es möglich DNS-Weiterleitungen zu konfigurieren. Beispielsweise lässt sich konfigurieren, dass alle Anfragen an _msdcs.frankysweb.local an den Domain Controller weitergeleitet werden. Hilft bei nur einem Domain Controller natürlich auch nur bedingt (bedingt im Sinne von “gar nicht”)…

Dieses Problem kann übrigens auch in Umgebungen mit zwei oder mehr Domain Controllern auftreten, denn auch hier müssen alle konfigurierten DNS-Server in der Lage sein, die “Underscore Zones” aufzulösen.

11 thoughts on “Exchange 2016: 451 4.7.0 Temporary server error. Please try again later. PRX2”

  1. Ich hab ein paar Exchange Server zur Betreuung „geerbt“.

    Bei der Suche nach Informationen bin ich relativ oft auf Deiner Website gelandet, die Toolbox hat mir gerade geholfen, einen Fehler zu beheben, der sich nach Neuaufbau einer Exchange VM eingeschlichen hat.

    Vielen Dank.

    Reply
  2. Vielen Dank (!!!) für die Info, hat mir geholfen einen Exchange der plötzlich nicht mehr ging wieder auf die Beine zu helfen.
    Veralteten DNS Eintrag eliminiert und den Exchange nur noch mit dem einzigen richtigen DNS eingestellt.
    Sehr gut beschrieben :-)

    Reply
  3. Besser konnte man es nicht erklären. Nach einem Netztotalausfall mit Recovery und Neukonfiguration hat sich genau der Fehler heute eingeschlichen. Keine Mails mehr rein, keine mehr raus, trotz laufender Dienste.
    Hat mir den Abend gerettet. Wie schon oben erwähnt, frankysweb.de hat schon häufig bei Exchange Fehlern geholfen.
    Danke für den tollen Artikel, hat das Problem sofort behoben.

    Reply
  4. Hallo Frank,
    noch ein Tipp: auf dem Exchange nie den dyndns-Updaterclient verwenden. Der setzt nämlich ungefragt zwei Oracle-DNS-Server an den Anfang der DNS-Auflösung. Hat mich gerade 2 Stunden Fehlersuche an einem Exchange 2013 gekostet…

    Reply
  5. Mich hat diese Anleitung hier gerettet. Wobei bei mir das Problem in Kombination Popcon aufgetreten ist.

    https://anishjohnes.wordpress.com/2021/11/03/error-451-4-7-0-temporary-server-error-please-try-again-later-prx2/

    Also falls diese Anleitung hier von Frank (vielen Dank nochmals hierfür) bei euch nicht hilft. Kann es gut sein, das wie bei mir die UUID der Netzwerkkarte sich geändert bzw. falsch eingetragen ist. Bei mir hat es mit der UUID (00000000-0000-0000-0000-000000000000) wieder funktioniert.

    Reply
  6. Ich will ja nicht zugeben, dass ich auf einem Exchange 2016 rumfuhrwerke aber ja: Der Artikel hat genau mein Problem gelöst.

    Habe meinen Win Server 2016, auf dem ich Exchange laufen habe, als ADS und DNS Manager eingerichtet also muss ich natüüüüüüüüüürlich die DNS Einstellung auch auf sich selbst setzten. *hand an Stirn klatsch*

    MAGIC

    Wahnsinn.
    Franky deine Seite ist der Wahnsinn. Bin über die Jahre so oft hier gelandet.
    Danke.

    Reply
  7. Danke für den Artikel.

    „Exchange benutzt alle konfigurierten DNS-Server, nicht nur den bevorzugten DNS Server“

    Nutzt Exchange wirklich selber die Einstellungen des DNS Setups der IP Einstellungen für Abfragen oder gib die Exchange Applikation dies an den DNS Resolver des Betriebssystems weiter, der dann den DNS Cache => Host File => DNS Lookup gegen 1.DNS Server => DNS Lookup gegen 2.DNS Server für Abfragen nutzt?

    Der zweite DNS Server im Netz muß natürlich auch die Antworten des 1. DNS Servers kennen (im Cache oder auflösen), ansonsten kann Exchange natürlich nicht arbeiten. Exchange ohne AD geht nicht!

    Reply
  8. „Exchange benutzt alle konfigurierten DNS-Server, nicht nur den bevorzugten DNS Server.“ Das war mir garnicht bewußt. Gut zu wissen, danke!

    Reply
    • Dem kann ich mich nur anschließen.
      Router raus aus den DNS-Einträgen und alles gut.

      Eigentlich hatte ich den Ablauf der Namensauflösung so erwartet wie Erik ihn beschreibt.

      Reply
  9. Danke für den aufschlussreichen und klar verständnlichen Artikel.

    Da könnten etliche Knowledge Base Artikel resp. deren Verfasser etwas lernen… ;-)

    Reply

Leave a Comment