none
Exchange 2016 CU11 Update - Verwaltungstool Fehler RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen,

    wir haben aktuell Exchange Server 2016 CU10 im Einsatz und einen Server (Admin-Server) auf denen die Verwaltungstools (Management Shell) installiert sind. Ich habe auf dem Admin-Server das CU11 eingespielt und somit die Exchange 2016 Komponenten (Exchange Tools & Management Shell) aktualisiert. Des Weiterem wurde im Anschluss .Net 4.7.2 (NDP472-KB4054530-x86-x64-AllOS-ENU.exe) installiert und der Server neu gestartet.

    Heute morgen habe mich als erstes darüber gewundert, das der Exchange Reporter von Frankys Web nicht mehr die Top Empfänger und Absender in seiner Statusmail anzeigt. Beim Aufruf der Toolbox sowie einer MMC mit dem SnapI "Warteschlange" auf dem Adminserver sind beide in einen Fehler gelaufen und das SnapIn hat sich beendet. Ein Neustart hat bisher auch nicht geholfen.

    Deserialization fails: System.IO.FileLoadException: Die Datei oder Assembly "Microsoft.Exchange.Data.Directory, Version=14.0.0.0, Culture=neutral, PublicKeyToken=31bxxxxxxxxxxxxxxe35" oder eine Abhängigkeit davon wurde nicht gefunden. Die gefundene Manifestdefinition der Assembly stimmt nicht mit dem Assemblyverweis überein. (Ausnahme von HRESULT: 0x80131040)
Dateiname: "Microsoft.Exchange.Data.Directory, Version=14.0.0.0, Culture=neutral, PublicKeyToken=31xxxxxxxxxxxxxxxxx364e35"
   bei System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   bei System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   bei System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean forIntrospection)
   bei System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
   bei System.Reflection.Assembly.Load(String assemblyString)
   bei System.UnitySerializationHolder.GetRealObject(StreamingContext context)
   bei System.Runtime.Serialization.ObjectManager.ResolveObjectReference(ObjectHolder holder)
   bei System.Runtime.Serialization.ObjectManager.DoFixups()
   bei System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler handler, __BinaryParser serParser, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
   bei System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream, HeaderHandler handler, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
   bei Microsoft.Exchange.Data.SerializationTypeConverter.DeserializeObject(Object sourceValue, Type destinationType)

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 dieses Feature deaktivieren, indem Sie den Registrierungswert [HKLM\Software\Microsoft\Fusion!EnableLog] entfernen.

    Im Eventlog gibt es einen Eintrag: Quelle: DistributedCOM; Ereignis-ID: 10016

    Durch die Berechtigungseinstellungen für "Anwendungsspezifisch" wird dem Benutzer "NT-AUTORITÄT\SYSTEM" (SID: S-1-5-18) unter der Adresse "LocalHost (unter Verwendung von LRPC)" keine Berechtigung vom Typ "Lokal Aktivierung" für die COM-Serveranwendung mit der CLSID 
{8DxxxxxxxxxxxxxxxxxxxxxE4919}
 und der APPID 
{F72xxxxxxxxxxxxxxxxx65169}
 im Anwendungscontainer "Nicht verfügbar" (SID: Nicht verfügbar) gewährt. Die Sicherheitsberechtigung kann mit dem Verwaltungstool für Komponentendienste geändert werden.

    Ich habe jetzt bedenken das CU 11 auf die Exchange Server zu installieren und dann noch das .Net 4.7.2.


    • Bearbeitet Lexxitus Freitag, 1. Februar 2019 07:15
    Freitag, 1. Februar 2019 07:15
    |

Antworten

  • Question
    Anmelden
    0
    Anmelden

    Habe das CU11 nur mit seinen Verwaltungstools auf einen komplett frischem System (Server 2016) installiert und die selben Fehler treten auf. Ich lehne mich mal aus dem Fenster und behaupte das hier ein Fehler im CU11 vorhanden ist der bei einer Standalone Installation auftritt.

    Wir sind gespannt was bei CU12 kommt und ob da auch die bisher aufgetretenden Sicherheitslücken sauber/fehlerfrei geschlossen werden können.

    Update: CU12 ist wieder wie das CU10 und die Verwaltungstools sind als Standalone nutzbar.


    • Als Antwort markiert Lexxitus Mittwoch, 6. Februar 2019 10:40
    • Bearbeitet Lexxitus Mittwoch, 20. Februar 2019 14:21
    Mittwoch, 6. Februar 2019 10:40
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    Moin,

    der DCOM-Fehler kommt auch bei einem frisch installierten CU11 auf 2016 mit .NET 4.7.1 vor, da funktioniert aber sonst alles.

    Ansonsten kann man diese Berechtigungsfehler ja entschärfen, sind nur Rechte in der Registry und anschließend in Component Services.

    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Freitag, 1. Februar 2019 07:29
    |
  • Question
    Anmelden
    0
    Anmelden

    Mich wurmt hauptsächlich der Fehler das die Toolbox bzw. der Aufruf der Warteschlange fehlschlägt.

    In meiner Testumgebung tritt der Fehler auf den bereits aktualisierten Exchange Servern 2016 CU11 nicht auf.

    Sofern ich auf einem System (wo nur die Verwaltungstools installiert sind) mit den Fehler in der Shell folgenden befehl absetze, erhalte ich Fehlermeldungen die auf den Exchange Servern CU11 (Testumgebung) nicht erhalte.

    Get-ExchangeServer | Get-MessageTrackingLog

    Fehlermeldung

    Das Eingabeobjekt kann an keine Parameter des Befehls gebunden werden, da der Befehl keine Pipelineeingaben akzeptiert oder die Eingabe und deren Eigenschaften mit keinem der Parameter übereinstimmen,
die Pipelineeingaben akzeptieren.
    + CategoryInfo          : InvalidArgument: (EX0x:PSObject) [Get-MessageTrackingLog], ParameterBindingException
    + FullyQualifiedErrorId : InputObjectNotBound,Get-MessageTrackingLog
    + PSComputerName        : ex01.domain.local

    Eine Deinstallation vom CU11 (Verwaltungstools) und .Net 4.7.2 sowie Neuinstallation vom CU11 bringt danach die selben Fehler.



    Habe die Verwaltungstools von CU10 installiert und diese funktionieren auf dem Server problemlos. Kann das CU11 hier buggy sein............?



    • Bearbeitet Lexxitus Freitag, 1. Februar 2019 12:52
    Freitag, 1. Februar 2019 07:34
    |
  • Question
    Anmelden
    0
    Anmelden

    Habe das CU11 nur mit seinen Verwaltungstools auf einen komplett frischem System (Server 2016) installiert und die selben Fehler treten auf. Ich lehne mich mal aus dem Fenster und behaupte das hier ein Fehler im CU11 vorhanden ist der bei einer Standalone Installation auftritt.

    Wir sind gespannt was bei CU12 kommt und ob da auch die bisher aufgetretenden Sicherheitslücken sauber/fehlerfrei geschlossen werden können.

    Update: CU12 ist wieder wie das CU10 und die Verwaltungstools sind als Standalone nutzbar.


    • Als Antwort markiert Lexxitus Mittwoch, 6. Februar 2019 10:40
    • Bearbeitet Lexxitus Mittwoch, 20. Februar 2019 14:21
    Mittwoch, 6. Februar 2019 10:40
    |
  • Question
    Anmelden
    0
    Anmelden

    Moin,

    ich verstehe nicht, wozu man die Tools auf einem anderen Rechner oder Server braucht.

    Entweder über das ECP oder Remote PowerShell ist alles zu managen. :)

    Gruß Norbert

    Sonntag, 10. Februar 2019 13:08
    |
    Moderator