none
[BUG im SP2 / SP3 Setup] - Probleme bei der Installation des SP2 für Exchange 2010 auf Windows SBS 2011 RRS feed

  • Frage

  • Hallo Kollegen,

    ich habe bei einem Bekannten ein Problem bei der Installation des SP2 für Exchange 2010 auf einen SBS 2011. Die Version des installierten Exchange ist 14.1 Build 218.15. Zusätzlich ist noch die Trend Micro Worry Free Advanced Suite installiert.
    (Nachtrag: Installation vom SP3 verursacht selben Fehler)

    Die Installation bleibt bei diesem Fehler stehen:

    Fehler:
    Der folgende Fehler wurde generiert, als "$error.Clear(); 
              Write-ExchangeSetupLog -Info "Set the default Accepted domain from the default recipient policy";
              $defaultEmailAddressPolicy = get-EmailAddressPolicy -Identity:"Default Policy";
              $defaultSmtpTemplate = $defaultEmailAddressPolicy.EnabledPrimarySMTPAddressTemplate;
              $index = $defaultSmtpTemplate.IndexOf("@") + 1;
              $eapAuthoritativeDomain = $defaultSmtpTemplate.Substring($index);
              $acceptedDomains = Get-AcceptedDomain;
              $defaultDomain = $acceptedDomains | Where {$_.DomainName -eq $eapAuthoritativeDomain -or $_.DomanName -eq "*.$eapAuthoritativeDomain" };
              # If an accepted domain couldn't be found which matches the default email address policy, then try and find
              # the wildcard domain which matches it and set that as the default
              While ($defaultDomain -eq $null -and $eapAuthoritativeDomain.Contains(".")) {
                  $index = $eapAuthoritativeDomain.IndexOf(".") + 1;
                  $eapAuthoritativeDomain = $eapAuthoritativeDomain.Substring($index);
                  $defaultDomain = $acceptedDomains | Where {$_.DomainName -eq "*.$eapAuthoritativeDomain" };
              };
              $defaultDomain | set-accepteddomain -MakeDefault:$true;
              Write-ExchangeSetupLog -Info "Default domain $defaultDomain";
            " ausgeführt wurde: "Das Argument kann nicht an den Parameter "Identity" gebunden werden, da es NULL ist.".
    Das Argument kann nicht an den Parameter "Identity" gebunden werden, da es NULL ist.

    So, ich weiss wohl das irgendetwas nicht mit den Addressrichtlininen nicht stimmt. Allerdings, und das finde ich sehr seltsam, ist ein Fehler in dem oben geposteten Fehlercode.

    Schaut euch mal die Zeile an wo $defaultDomain bestimmt wird. Ist relativ weit oben.

    $defaultDomain = $acceptedDomains | Where {$_.DomainName -eq $eapAuthoritativeDomain -or $_.DomanName -eq "*.$eapAuthoritativeDomain" };

    In der where Klausel ist ein Fehler bei dem zweiten DomainName. Da fehlt ein i.

    Ich habe die PowerShell Commandos aus dem Fehlerlog mal einzeln ausgeführt und bleibe genauso wie das Setup an eben dieser Zeile hängen, da hier kein Ergebnis kommt.

    Führe ich diese Zeile korrigiert aus, erhalte ich einen Eintrag für $defaultDomain. Mit der Originalzeile bleibt er leer.

    Kurze Frage: Spiegel die PowerShell Anweisungen denn exakt die während dem Setup ausgeführten Befehle wieder ?

    Kann man das PS Script anpassen, Welche Auswirkungen kann das bei der Installation vom SP2 haben ?

    Viele Grüße

    Florian



    Mittwoch, 1. Juni 2016 19:15

Antworten

  • Moin,

    wenn Du Dir genau anschaust, was das Script macht, dann spielt der Programmfehler bei einem sauber konfigurierten Server keine Rolle und das wird auch der Grund sein, warum er so selten aufgefallen ist.

    Schau Dir an, welche Domain in der Adressrichtlinie "Default Poicy" für E-Mail-Adressen eingestellt ist.

    Dann schau in die akzetptierten Domänen und stell sicher, diese Domain dort

    1. als Default eingestellt ist

    2. keine Wildcard-Domain ist (hier ist der Fehler im Script)

    Es ist eher unüblich, dort eine Wildcard-Domain zu haben, daher fällt er bei anderen nicht auf. Die Prüfung auf die Wildcard-Domain ist aber im Script fehlerhaft, so dass das Script die in der Default Policy verwendet Domain dann nicht findet, wenn sie in den akzeptierten Domänen als Wildcard eingetragen ist.

    Wenn das aus irgendeinem Grund gewünscht ist, dann ändere das vor dem SP 3 so ab, wie ich es geschrieben habe und danach wieder zurück.


    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    • Als Antwort markiert FlorianHahner Freitag, 17. Juni 2016 21:04
    Donnerstag, 2. Juni 2016 10:10

Alle Antworten

  • So,

    also es scheint wirklich fehlerhaft im Setup des SP2 integriert zu sein.

    Die betroffene PowerShell Zeile ist in der Datei

    exchsp2\de\setup\serverroles\common\de\microsoft.exchange.management.resources.dll in Zeile 16377 hinterlegt. Es sieht so als das es generell diese Datei betrifft, unabhängig von der Sprache.

    Vielleicht ist hier jemand von Microsoft im Forum, der dazu was sagen kann.

    Viele Grüße

    Florian

    Mittwoch, 1. Juni 2016 20:00
  • Moin,

    von MS wird da keiner Antworten, da bereits lange aus dem Support, und zwar seit das SP3 raus ist, also genau seit dem 12.02.2013 - vor über drei Jahren.

    Ich kann mir nicht vorstellen, das der selbe Fehler im SP3 vorhanden ist, das ja knapp zwei Jahre später kam als das SP2.

    Wenn ich mich recht entsinne, werden die Daten aus dem AD ausgelesen - da stimmt etwas nicht.

    SBS ist zwar immer etwas speziell, aber nicht in diesem Fall.

    Ich würde jetzt erst mal den BPA aus der Exchange Toolbox laufen lassen und die Probleme beheben.

    In der Regel wird bei einem Deutschen Server der Zugriff auf das OAB angemeckert, ist aber meist nur ein Übersetzungs-Fehler, den man natürlich trotzdem (beim 1ten Mal) prüft.

    Und weitere Versuche bitte nur mit dem entpackten SP3 an einem CMD mit Administrativen Rechten starten, Setup.com /M:Upgrade

    Und nicht das aktuell RU in das Upgrade Verzeichnis kopieren, sondern anschließend manuell nachziehen.

    Wie kann ein Server auf einem so alten Stand sein?
    Das ist fahrlässig....

    ;)


    Gruß Norbert

    Mittwoch, 1. Juni 2016 20:37
    Moderator
  • Hi Norbert,

    danke für deine Infos. Leider wurde der Server was das Exchange angeht vernachlässigt da dieser Fehler schon länger besteht. Ich wollte damals schon SP3 installieren, was allerdings ebenfalls fehl schlug. (Ich prüfe nachher noch die Datei von der SP3 Variante)

    Bei anderen Exchange Installationen hatte ich noch dieses Problem gehabt. Daher frage ich mich auch, was an diesem nicht stimmt, dass er überhaupt in diese "fehlerhafte" Abfrage geht.

    Wie gesagt kann ich die Daten einwandfrei per PowerShell auslesen, wenn ich die Befehle des Skriptes selbst eingebe. Ich bin zwar einigermaßen bewandert was Exchange angeht, aber gibt es irgendwo leitlinien wie die Akkzeptierten Domänen / Adressrichtlinien aussehen müssen ?

    Das mit dem Best Practise werde ich mal probieren.

    Viele Grüße

    Florian


    UPDATE: Der Bug (fehlerhaftes Script) ist ebenfalls im SP3 enthalten
    Mittwoch, 1. Juni 2016 21:00
  • Hi Norbert,

    ...
    UPDATE: Der Bug (fehlerhaftes Script) ist ebenfalls im SP3 enthalten

    Moin,

    das kann nicht sein, dann hätte ich das bei über 300 Servern nicht installieren können.

    Wenn du dir sicher bist, mache eine Call bei MS auf - der kostet dann ja nichts.

    JA, es gibt Einschränkungen beim Org-Name, beliebter Fehler waren Leer - oder Sonderzeichen.

    Das sagt dir aber der BPA - was hat der als Output gebracht?

    ;)


    Gruß Norbert

    Donnerstag, 2. Juni 2016 05:29
    Moderator
  • UPDATE: Der Bug (fehlerhaftes Script) ist ebenfalls im SP3 enthalten

    Moin,

    das kann nicht sein, dann hätte ich das bei über 300 Servern nicht installieren können.

    Wenn du dir sicher bist, mache eine Call bei MS auf - der kostet dann ja nichts.


    Hi Norbert,

    naja. Ich mit einem Such-Tool alle Dateien des entpackten SP3 Downloads durchsucht und eben wieder in gesagter DLL diesen speziellen PowerShell String gefunden. Hast du spontan eine Anlaufstelle wo ich dies bei Microsoft melden kann ?

    Wegen einen 300 Exchange Servern. Glaube ich dir sofort. Hatte auch noch nie Stress damit. Aber in diesem einen Fall geht es halt nicht. Bzw. es sollte gehen wenn der Rechtschreibfehler nicht währe.

    Hier noch die Ergebnisse vom BPA

    (wollte Bilder hochladen, Microsoft will erst mein Konto prüfen)

    Vielleicht ist diese Info hilfreich

    Variablen in Empfängerrichtlinie
    Empfängerichtlinie "Default Policy" enthält Variablen, mit denen die Generierung von SMTP-Adressen gesteuert wird.

    Viele Grüße

    Florian

    Donnerstag, 2. Juni 2016 06:15
  • Moin,

    wenn Du Dir genau anschaust, was das Script macht, dann spielt der Programmfehler bei einem sauber konfigurierten Server keine Rolle und das wird auch der Grund sein, warum er so selten aufgefallen ist.

    Schau Dir an, welche Domain in der Adressrichtlinie "Default Poicy" für E-Mail-Adressen eingestellt ist.

    Dann schau in die akzetptierten Domänen und stell sicher, diese Domain dort

    1. als Default eingestellt ist

    2. keine Wildcard-Domain ist (hier ist der Fehler im Script)

    Es ist eher unüblich, dort eine Wildcard-Domain zu haben, daher fällt er bei anderen nicht auf. Die Prüfung auf die Wildcard-Domain ist aber im Script fehlerhaft, so dass das Script die in der Default Policy verwendet Domain dann nicht findet, wenn sie in den akzeptierten Domänen als Wildcard eingetragen ist.

    Wenn das aus irgendeinem Grund gewünscht ist, dann ändere das vor dem SP 3 so ab, wie ich es geschrieben habe und danach wieder zurück.


    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    • Als Antwort markiert FlorianHahner Freitag, 17. Juni 2016 21:04
    Donnerstag, 2. Juni 2016 10:10
  • Hallo Robert,

    vielen Dank für deine Ideen. Letztendlich hattest du mit der Adressenrichtlinie rechtgehabt. Der Kollege, der den Server installiert hatte, hatte die @musterfirma.local komplett entfernt und nur Einträge mit Surname und Firstname-Prefixen eingebaut. Somit brachte die Änderungen des Standards bei den akzeptierten Domainen keinen Erfolg. Selbst das einfache hinzufügen der @musterfirma.local brachte kein Erfolg.

    Erst das Setzen des Attributes "Als Antwortadresse verwenden" bei musterfirma.local brachte Erfolg. Derzeit läuft das Setup des SP3 (hoffentlich erfolgreich).

    ------

    Update lief erfolgreich. Nach einem Reboot noch das Update RollUp und Funktionstest --> Alles OK

    ----

    Ich danke hiermit nochmals allen Beteiligten in diesem Thread und besonders Robert dessen Hinweise zur Lösung geführt haben.

    Viele Grüße

    Florian

    Freitag, 17. Juni 2016 17:55