none
Exchange Server 2013 damaged after installing CU5 (ReceiveConnectorRoleConflictException) RRS feed

  • Frage

  • Hi there,

    today I tried to install Exchange 2013 CU5 on a CU4 installation, but the setup stopped because of an error in my receive connector. Now I neither can connect to Exchange via EAC nor via PowerShell. The installation is incomplete! :-((

    Rerunning the Setup doesn't help, because the same error appears and stops the setup process. Because I cannot connect to Exchange, I cannot deactivate or delete the receive connector "EXCH2013GHUE\OMO@QSTS" (which would be a minor problem for me).

    Has anyone an idea to repair my Exchange or to deactivate/delete my receive connector outside EAC/shell??

    Greetings, George

    This appears in the setup:

    Fehler:
    Der folgende Fehler wurde generiert, als "$error.Clear(); 
              $connectors = Get-ReceiveConnector -Server $RoleFqdnOrName;
              foreach($connector in $connectors) { if($connector.MaxLocalHopCount -gt 1) { Set-ReceiveConnector -Identity $connector.Identity -MaxLocalHopCount 5 } };
            " ausgeführt wurde: "Microsoft.Exchange.Management.SystemConfigurationTasks.ReceiveConnectorRoleConflictException: Die von Ihnen angegebenen Werte für die Parameter "Bindings" und "RemoteIPRanges" stehen im Konflikt mit den Einstellungen für den Empfangsconnector "EXCH2013GHUE\OMO@QSTS". Empfangsconnectors, die auf einem einzigen Server verschiedenen Transportrollen zugewiesen sind, müssen an eindeutigen, lokalen IP-Adressen und Portbindungen lauschen.
       bei Microsoft.Exchange.Configuration.Tasks.Task.WriteError(Exception exception, ErrorCategory category, Object target, Boolean reThrow, String helpUrl)
       bei Microsoft.Exchange.Configuration.Tasks.Task.WriteError(Exception exception, ErrorCategory category, Object target)
       bei Microsoft.Exchange.Management.SystemConfigurationTasks.SetReceiveConnector.InternalValidate()
       bei Microsoft.Exchange.Configuration.Tasks.Task.<ProcessRecord>b__b()
       bei Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed)".
    
    Fehler:
    Der folgende Fehler wurde generiert, als "$error.Clear(); 
              $connectors = Get-ReceiveConnector -Server $RoleFqdnOrName;
              foreach($connector in $connectors) { if($connector.MaxLocalHopCount -gt 1) { Set-ReceiveConnector -Identity $connector.Identity -MaxLocalHopCount 5 } };
            " ausgeführt wurde: "Microsoft.Exchange.Management.SystemConfigurationTasks.ReceiveConnectorRoleConflictException: Die von Ihnen angegebenen Werte für die Parameter "Bindings" und "RemoteIPRanges" stehen im Konflikt mit den Einstellungen für den Empfangsconnector "EXCH2013GHUE\Default Frontend EXCH2013GHUE". Empfangsconnectors, die auf einem einzigen Server verschiedenen Transportrollen zugewiesen sind, müssen an eindeutigen, lokalen IP-Adressen und Portbindungen lauschen.
       bei Microsoft.Exchange.Configuration.Tasks.Task.WriteError(Exception exception, ErrorCategory category, Object target, Boolean reThrow, String helpUrl)
       bei Microsoft.Exchange.Configuration.Tasks.Task.WriteError(Exception exception, ErrorCategory category, Object target)
       bei Microsoft.Exchange.Management.SystemConfigurationTasks.SetReceiveConnector.InternalValidate()
       bei Microsoft.Exchange.Configuration.Tasks.Task.<ProcessRecord>b__b()
       bei Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed)".
    
    

    This appears while starting the EAC:

    Serverfehler in der Anwendung /owa.
    --------------------------------------------------------------------------------
    
    
    Konfigurationsfehler 
      Beschreibung: Fehler beim Verarbeiten einer Konfigurationsdatei, die für diese Anforderung erforderlich ist. Überprüfen Sie die unten angegebenen Fehlerinformationen, und ändern Sie die Konfigurationsdatei entsprechend. 
    
     Parserfehlermeldung: Die Datei oder Assembly "Microsoft.Exchange.Clients.Strings, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden.
    
    Quellfehler: 
    
    
    
    Zeile 46:                 the compiler.  All assemblies in the GAC and owa\bin are referenced automatically.
    Zeile 47:                 -->
    Zeile 48:           <add assembly="Microsoft.Exchange.Clients.Strings, Version=15.0.0.0, Culture=neutral, publicKeyToken=31bf3856ad364e35" />
    Zeile 49:           <add assembly="Microsoft.Exchange.Data.Directory, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
    Zeile 50:           <add assembly="Microsoft.Exchange.Clients.Common, Version=15.0.0.0,Culture=neutral, publicKeyToken=31bf3856ad364e35" />
      
    
     Quelldatei:  D:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\web.config    Zeile:  48 
    
    Überwachung beim Laden der Assembly: Mit folgenden Informationen kann bestimmt werden, warum die Assembly Microsoft.Exchange.Clients.Strings, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 nicht geladen werden konnte.
    
    
    
    WRN: Protokollierung der Assemblybindung ist AUS.
    Sie können die Protokollierung der Assemblybindungsfehler aktivieren, indem Sie den Registrierungswert [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) auf 1 festlegen.
    Hinweis: Die Protokollierung der Assemblybindungsfehler führt zu einer gewissen Leistungseinbuße.
    Sie können diese Funktion deaktivieren, indem Sie den Registrierungswert [HKLM\Software\Microsoft\Fusion!EnableLog] entfernen.
    
      
    
    
    --------------------------------------------------------------------------------
    Versionsinformationen: Microsoft .NET Framework-Version:4.0.30319; ASP.NET-Version:4.0.30319.18447 

    Mittwoch, 28. Mai 2014 12:09

Antworten

  • Moin,

    adsiedit habe ich als "Plan B" in der Hinterhand gehalten und bin den PowerShell-Weg gegangen: Mit

    Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn

    habe ich mich unsupported mit Exchange verbunden und habe mit

    remove-ReceiveConnector "OMO@QSTS"

    meinen Connector entfernt. Den muss ich später wieder anlegen...

    Get-ReceiveConnector "OMO@QSTS" | Set-ReceiveConnector -Enabled $false -whatif

    konnte ich nicht verwenden, da hierbei die ReceiveConnectorRoleConflictException wieder auftrat. Jetzt startete ich das Setup erneut und es blieb nicht mehr mit einer ReceiveConnectorRoleConflictException hängen. Prima!

    VIELEN DANK für die schnelle und kompetente Hilfe! Den Schweiß kann ich aber noch nicht von der Stirn wischen, da jetzt das Setup mit http://social.technet.microsoft.com/Forums/exchange/de-DE/728a728f-66d6-471a-88e7-2040acd56145/installationsfehler-exchange-2010-sp2 abbricht. Da muss ich noch mal ran. Wer hat bloß CU5 getestet? :-(( Viele Grüße, Georg

    Freitag, 30. Mai 2014 07:03

Alle Antworten

  • Moin,

    da wir im deutschen Forum sind, mache ich mal deutsch weiter.

    Du kannst die Connectoren auch mit ADSIEDIT anfassen. Ist zwar offiziell nicht supported, aber kaputt ist das System ja schon.

    Verbinde Dich mit dem Namenskontext "Konfiguration" und geh an die folgenden Stelle:

    CN=SMTP Receive Connectors,CN=Protocols,CN=SERVER_NAME,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Exchange,CN=Microsoft Exchange,CN=Services,CN=Configuration

    (Der Pfad ist in dem Fall rückwärts zu lesen).

    Darin findest Du Deine Connectoren. Laut Setup haben die beiden hier einen Konflikt:

    OMO@QSTS
    Default Frontend EXCH2013GHUE

    Dich Interessieren in den Eigenschaften die Felder msExchSmtpReceiveBindings und msExchSmtpReceiveRemoteIPRanges.

    In diesen Feldern müssen als Triplett (lokale IP + Port + Remote IP) alle Werte eindeutig sein und dürfen nicht doppelt vorkommen (mit anderen Connectoren auf diesem Server).

    Du solltest hierbei nicht den Port ändern, sondern nur die lokale IP, bzw. die Remote IP. Die Werte für den "Default Frontend" sind im Standard:

    msExchSmtpReceiveBindings  = 0.0.0.0:25 und [::]:25

    msExchSmtpReceiveRemoteIPRanges = ::-ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff und 0.0.0.0-255.255.255.255

    ACHTUNG: ADSIEDIT ist ein Lowlevel-Tool! Du kannst damit sehr viel falsch machen, bis zum Totalverlust von Exchange oder AD! Wenn Du Dir nicht sicher bist, dann hol Dir bitte einen Fachmann ins Haus.


    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Mittwoch, 28. Mai 2014 14:26
  • Evt funktioniert es auch die normale Powershell zu starten und dann die Exchange Snapins zu laden. Anschließennd die Connectoren  löschen/bearbeiten.

    Grüße

    Jörg

    Mittwoch, 28. Mai 2014 14:36
  • Ja, könnte auch gehen. Eventuell bringt man da auch heraus, welche Einstellungen genau im Konflikt stehen.

    Eine manuelle Shell ist zwar auch unsupported, aber das ist dann auch egal.


    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Mittwoch, 28. Mai 2014 14:38
  • Moin,

    adsiedit habe ich als "Plan B" in der Hinterhand gehalten und bin den PowerShell-Weg gegangen: Mit

    Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn

    habe ich mich unsupported mit Exchange verbunden und habe mit

    remove-ReceiveConnector "OMO@QSTS"

    meinen Connector entfernt. Den muss ich später wieder anlegen...

    Get-ReceiveConnector "OMO@QSTS" | Set-ReceiveConnector -Enabled $false -whatif

    konnte ich nicht verwenden, da hierbei die ReceiveConnectorRoleConflictException wieder auftrat. Jetzt startete ich das Setup erneut und es blieb nicht mehr mit einer ReceiveConnectorRoleConflictException hängen. Prima!

    VIELEN DANK für die schnelle und kompetente Hilfe! Den Schweiß kann ich aber noch nicht von der Stirn wischen, da jetzt das Setup mit http://social.technet.microsoft.com/Forums/exchange/de-DE/728a728f-66d6-471a-88e7-2040acd56145/installationsfehler-exchange-2010-sp2 abbricht. Da muss ich noch mal ran. Wer hat bloß CU5 getestet? :-(( Viele Grüße, Georg

    Freitag, 30. Mai 2014 07:03
  • Hier noch die Einstellungen der Empfangsconnectoren, die im Konflikt standen:

    OMO@QSTS: 
    Bindings                                : {<IPv4-Adresse meines Exchange-Servers>:25}
    RemoteIPRanges                          : {<IPv4-Adresse meines Monitoring-Servers>}
    
    Default Frontend EXCH2013GHUE:
    Bindings                                : {<IPv4-Adresse meines Exchange-Servers>:25, [::]:25, 0.0.0.0:25}
    RemoteIPRanges                          : {::-ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff, 0.0.0.0-255.255.255.255}
    

    Freitag, 30. Mai 2014 07:05
  • Das mit dem Konflikt ist lustig, weil das eigentlich keiner ist. Die speziellere Remote-Adresse von OMO@QSTS wird automatisch als Ausnahme der Range des Default-Connector betrachtet.

    Das, was Du da oben hast, habe ich dutzende Male bei Kunden konfiguriert. Allerdings bei 2010.

    Ich vermute, er stört sich an der IP-Adresse des Servers in den Bindings. Die ist bei dem Default-Connector eigentlich doppelt. Bevor Du den speziellen Connector wieder anlegst, würde ich die aus dem Default entfernen und im speziellen Connector die Bindings genauso einstellen, wie im Allgemein. 


    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Freitag, 30. Mai 2014 07:24
  • Zum zweiten Setup-Fehler.

    Das ist allerdings mal kein Problem in Exchange, sondern in Deinem AD. Du siehst ja im Link auch, dass das schon seit 2010 SP 1 auftritt und wie es behoben wird.

    Exchange ist ein komplexes Produkt und nimmt nur wenig Rücksicht auf Fehler, die Admins an anderer Stelle machen (z.B. im AD). Das merkt man dann spätestens beim nächsten Exchange Update.


    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Freitag, 30. Mai 2014 07:36
  • Habe das Discovery-Postfach mit delete-mailbox gelöscht (disable-mailbox reicht nicht). Danach lief das Setup für CU5 ENDLICH durch und es hat dabei auch das Discovery-Postfach neu angelegt.

    Im Empfangsconnector "Default Frontend EXCH2013GHUE" habe ich die Bindung auf "<IPv4-Adresse meines Exchange-Servers>:25" entfernt und den "OMO(at)QSTS" mit den gleichen Bindungen wie den "Default Frontend EXCH2013GHUE" neu angelegt. Dieses SMTP-Gateway rennt jetzt auch wieder.

    Super!

    Bis zum nächsten Abenteuer.

    Viele Grüße,

    Georg

    Freitag, 30. Mai 2014 11:48
  • Das "disable" nicht reicht, war klar, weil ja das AD-Objekt defekt war und das wird dabei nicht gelöscht. Erst nach "delete" war der AD-User weg und wurde dann neu angelegt.

    Und danke für die Bestätigung der Vermutung mit der IP-Adresse in den Bindings. Muss ich bei Gelegenheit mal mit 2010 ausprobieren, ob das da auch schon streng war.


    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Freitag, 30. Mai 2014 12:15
  • Vielen Dank euch allen, ihr seid meine Helden!

    Hatte heute das Problem bei der Installation von CU10 für Exchange 2013 und konnte es dann mittels der Methode über die PowerShell und das manuelle hinzufügen der Exchange - SnapIns (und dem Löschen des Connectors) lösen.

    Hatte vorher einen kleinen Herzinfarkt als die Fehlermeldung bei der Installation auftrat, GSD gibts euch!

    LG

    Michael

    Dienstag, 6. Oktober 2015 17:56
  • Hallo Zusammen,

    vielen herzlichen Dank.

    Bin ebenfalls bei der Installation CU10 für Exchange 2013 über den Fehler gestolpert und konnte dank Eurer Tipps den Connector löschen und die Installation erfolgreich zu Ende bringen.

    LG

    Christine

    Donnerstag, 26. November 2015 14:02
  • Diese Lösung mit ADSIEDIT klappt also auch bei CU15. Wäre schön, wenn so Sachen im Voraus überprüft würden.

    Danke allen die hier diesen Beitrag geschrieben haben.

    Adrian

    Mittwoch, 26. April 2017 20:38