Exchange 2016 / 2019: Falsche MS-Vorgaben für UCMA

[English]Kleiner Hinweis für Administratoren von Microsoft Exchange Server 2016 und 2019. Microsoft hat in seiner Dokumentation zu den Anforderungen und in den Paketen für Updates für eine Installation einen dicken Bock geschossen. Dort wird UCMA 4.0 gefordert und verlinkt. Die Version 4.0 von USMA ist aber nicht mit neueren .NET-Versionen und Windows Server 2016/2019 kompatibel. Dort braucht es UCMA 6.0. Hier ein paar Informationen zu diesem Sachverhalt.


Anzeige

Ich bin bereits auf Twitter auf den nachfolgenden Post von Blog-Leser Karl gestoßen, in dem er  die Problemlage kurz beschreibt. Die offiziellen Dokumente Microsofts verlinken immer noch UCMA 4.0 als Voraussetzung für Microsoft Exchange Server 2016 (und wohl auch 2019).

 UCMA-Problem bei Exchange 2016/2019

Das Problem dabei: Die vom Setup für die Installation von Exchange Server 2016 gefordert Unified Communications Managed API 4.0 (UCMA 4.0) wird  in späteren .NET Framework-Versionen nicht unterstützt. UCMA 4.0 wird auch nicht auf auf Windows Server 2012 R2, Windows Server 2016 oder Windows Server 2019 unterstützt. Benötigt wird das neuer UCMA 6.0, was sich aber nicht so einfach installieren lässt, da es Konflikte mit den Laufzeit-Bibliotheken  der C++ Redistributable 2015 bis 2019 gibt.

Unified Communications Managed API 4.0 Runtime


Anzeige

Aufgefallen ist das Ganze, weil der Microsoft Exchange Server 2016 CU 18 eines Kunden beim Herunterladen von Updates über sconfig beim Update KB3175339 (Sec-Fix für UCMA 4.0) hängen blieb. Blog-Leser Karl hat mir dann diesen Kommentar zum Blog-Beitrag VC ++ 2019: Das Ende des MS C++ Redistribution Chaos? hinterlassen. Dort verweist er auf seinem Post Exchange 2016 / Exchange 2019 wrong recommendations on Unified Communications Managed API bei Microsoft Q&A, wo er den Sachverhalt noch ausführlicher beschreibt.

Ursache für das Hängen-bleiben war, dass das Paket im Katalog aufgeführt, aber als Download nicht mehr verfügbar ist. Beim Kunden läuft der Exchange Server 2016 auf Windows Server 2016 LTSC. Das CU 18 oder frühere CUs für Exchange wurden in den Requirements weder erwähnt (um nach der veralteten Version von UCMA 4.0 zu suchen), noch hat Microsoft die Pakete aktualisiert.

Benötigt wird UCMA 6.0, wobei dessen Installation in der geschilderten Umgebung zum Abenteuer ausartet. Karl hat sich die zur Installation von UCMA 6.0 geforderten  Voraussetzungen angesehen und sichergestellt, dass diese erfüllt sind. Trotzdem wurde das das Installationsprogramm nach Angabe des Installationspfades auf UCMA 6.0 beendet.

Der Grund dafür wurde in den Installationsprotokollen gefunden. Das UCMA-Setup versucht, C++ Redist 2015-2019 x64-Paketversion 14.12.x zu installieren, die stark veraltet ist. Leider hat derjenige, der das Paket für UCMA erstellt hat, eine falsche fest programmierte Versionsprüfung implementiert. Karl musste daher UCMA 4.0 deinstallieren, was in Ordnung gewesen wäre. Zusätzlich musste er auch die Laufzeitpakete der C++ Redistributionen 2015-2019 x64 deinstallieren.

Karl legt in seinem Post den Microsoft-Leuten ans Herz, beim Packen und Zusammenstellen von Installationspaketen niemals feste Versionsprüfungen auf eine bestimmte Versionsnummer vorzunehmen. Die Prüfungen sollten immer auf gleichen oder höheren Versionsstand erfolgen. Die aktuelle und sichere Version der Restristributable von C++ 2015-2019 ist die Version 14.28.x.

Die obigen Ausführungen zu Windows Server 2016 und Exchange Server 2016 gelten auch für die Kombination von Microsoft Exchange Server 2019, den man ausschließlich auf Windows Server 2019 (und demnächst vermutlich auch auf Windows Server 2021) installieren kann. Dort is nur UCMA 6.0 zugelassen. Microsoft hat sein eigenes Zeugs, auch im Business-Umfeld, nicht mehr wirklich im Griff.


Anzeige

Dieser Beitrag wurde unter Software, Windows Server abgelegt und mit , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

11 Antworten zu Exchange 2016 / 2019: Falsche MS-Vorgaben für UCMA

  1. Michael Schneider sagt:

    … Leider hat derjenige, der das Paket für UCMA erstellt hat, eine falsche fest programmierte Versionsprüfung implementiert. …

    In welchem Jahr wurde das programmiert?

    • Karl Wester-Ebbinghaus (@tweet_alqamar) sagt:

      Hi Michael,
      das ist nicht relevant. MSI ermöglicht durch einfache mathematische Operatoren wie = oder =< eine Versionsprüfung.
      Man kann das sogar via InstEd selbst in einer MST Datei ändern.

      UCMA ist noch nicht so alt.

      Version:
      2046.19

      Date Published:
      11/6/2018

      Hast du noch Fragen hierzu?

      • MOM20xx sagt:

        machen wir was falsch? wir haben das auf unseren 2 exchange servern 2016 im dag verbund auf windows server 2016 mit letzten cu noch immer in der version 4 im einsatz und merken eigentlich keine probleme. auch secupdates zu dieser komponente wurden mal vor jahren angeboten, die haben wir installiert damals.

        • Karl Wester-Ebbinghaus (@tweet_alqamar) sagt:

          Hi Mom, wenn ich nicht über sconfig patcht werde ihr wahrscheinlich kein Problem bemerken.

          Ihr macht insofern nichts falsch. Microsoft schon, weil die Komponente veraltet und nicht supported ist.

  2. Boris B. sagt:

    Wir haben bei diversen Kunden Exchange 2016 CU18 und UCMA 4.0 laufen – ohne Probleme.

    Mein Wissensstand war, dass der Exchange 2016 UCMA 4.0 eigentlich nicht mehr benötigt, aber die Install-Routinen manchmal meckern, wenn es fehlt (z.B. bei einem Restore mit dem /m:recoverserver Parameter) .

  3. stefan seidl sagt:

    also ich installiere gerade einen ex19 auf einem server2019 std und konnte das ucma 4.0 problemlos installieren.. installation nach dieser anleitung: https://www.frankysweb.de/howto-installation-von-exchange-2019-auf-server-2019/

    • Karl Wester-Ebbinghaus (@tweet_alqamar) sagt:

      Hallo Stefan, das ist nicht per Punkt. UCMA 4.0 ist auf Server 2019 nicht supported. Siehe Screenshots.
      Bitte prüfe über sconfig ob dir für das UCMA 4.0 ein KB Update angeboten wird.

  4. Martin Feuerstein sagt:

    Kleiner Blick in die Glaskugel: Karl Wester-Ebbinghaus installierte die Updates nicht mit Quelle WSUS, sondern direkt von Microsofts Update-Servern. Alle/einige andere Mitkommentierende, die keine Probleme mit fehlschlagenden Updates haben, setzen vermutlich einen WSUS ein, wo keine Kategorie existiert, die Updates für UCMA vermuten lassen. An meinem WSUS-Server konnte ich entsprechend für "Unified", "UCMA" oder "KB3175339" auch keine Einträge finden. SConfig würde ja auch keine Fehler melden, wenn am WSUS ein entsprechendes Updates einfach nicht freigegeben ist.
    Trotzdem vielen Dank für den Hinweis mit UCMA 4.0 vs. 6.0, hab auch noch einige Server vor mir wo nur UCMA 4.0 drauf ist.

  5. Martin Feuerstein sagt:

    Noch ein Nachtrag: UCMA 6.0 auf Server/Exchange 2016 "einfach mal so" draufzuklatschen ist eine schlechte Idee. Auch wenn der Dienst (mit .config-Fix) scheinbar startet, stürzt der Dienst häufig ab, in %systemroot%\temp werden massenweise große Absturzberichte angelegt, am Ende ist c:\ voll (statt 30 GB frei) und der E-Mail-Server steht. Bleibt nur UCMA 6.0 zu deinstallieren und wieder UCMA 4.0 zu installieren. Vielleicht fehlt mir da nur ein kleines Stück, um das Upgrade gradezubiegen aber so macht das keinen Spaß.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.

Du findest den Blog gut, hast aber Werbung geblockt? Du kannst diesen Blog auch durch eine Spende unterstützen.