Jump to content

Exchange Management Shell und ECP nicht verfügbar

PadawanDeluXe

Empfohlene Beiträge

PadawanDeluXe Mentor

PadawanDeluXe   80

Geschrieben
Geschrieben

Hallo zusammen,

ich habe ein ungewöhnliches Problem: meine Management Shell und die ECP Konsole sind nicht erreichbar. 
 

Shell liefert einen Authentifizierungsfehler zurück. 
 

ECP wirft HTTP Code 500

 

geprüft habe ich bereits folgende Dinge:

- Registry Einträge der Powershell

- IIS Config der Endpunkte Front- und Backend

 

gem. Changelog wurden Windows Patche installiert. Sonst gab es keine Änderungen. 
 

System:

Win Server 2022

Exchange 2019 CU5 

 

Eine Upgradeinstallation lief reibungslos durch. Die Anwender melden derzeit keine Fehler somit ist die DAG verfügbar. Eine Reperaturinstallation wurde noch nicht ausgeführt. Die Registry Werte der PowerShell sind aus unserer Sicht korrekt. (Vgl. Probleme Exchange 2016 CU6 Update) Ein manueller Import des Exhange Management Moduls war nicht hilfreich. Virenscanner wurde entfernt, Updates wurden deinstalliert Testweise. Kein Erfolg. 
 

Dank vorab für euren Support. 

 

 

Nobbyaushb Grand Master

Nobbyaushb   1.692

Geschrieben
Geschrieben (bearbeitet)

Ergänzend:

auch ein Add an der ISE wie von Alith vorgeschlagen klappt nicht  

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

 

Nachtrag - die Pfade stimmen meiner Meinug nach auch

 

bearbeitet von Nobbyaushb
Sunny61 Grand Master

Sunny61   853

Geschrieben
Geschrieben
vor 3 Stunden schrieb PadawanDeluXe:

ich poste anbei anonymisiert die Powershell Fehlermeldung:

 

Path Ergebnis:

Zukünftig bitte als Text in einen Code-Tag posten, das erleichtert das Lesen ungemein. Bei deinem Bild sind am Anfang der ersten Zeile zwei Semikolon drin, die gehören dort bestimmt nicht rein. So sieht es von einem Windows Client aus:

  

C:\Users\ich>echo %PATH%
C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Users\ich\AppData\Local\Microsoft\WindowsApps;C:\adb;C:\ADB\;C:\Users\ich\AppData\Local\Microsoft\WindowsApps;
C:\Users\ich>

 

 

Nobbyaushb Grand Master

Nobbyaushb   1.692

Geschrieben
Geschrieben

Die Ausgabe hier nun: 

New-PSSession : [hm mhex04
m t •] Processing data from remote server mhex04.kundenurl.de failed with the
following error message: [ClientAccessServer=MHEX04, BackEndServer=mhex04.kundenurl.de, RequestId=b03240ad-78d2-4556
-bc7c-442e7eee5bf4, TimeStamp=4/2/2026 6:01:30 PM]|
[AuthZRequestId=0ea45bf5-2f26-4744-ae2e-620d7e71be59][FailureCategory=AuthZ-SetupVersionInformationCorruptException]|
Unable to determine the installed file version from the registry key "SOFTWARE \Microsoft \PowerShell\'. For more information, see the about_Remote_Troubleshooting Help topic.
At line:1 char:1
+ New-PSSession -ConnectionURI "SconnectionUri" -ConfigurationName Micr ...
+ NIUNNNNNNNNNNN/////////////////////////////////////////////n
+ CategoryInfo
: OpenError: (System. Manageme.... RemoteRunspace: RemoteRunspace) [New-PSSession], PSRemotin
TransportException
+ FullyQualifiedErrorId :

Ich habe das m.E. passend gemacht 

PadawanDeluXe Mentor

PadawanDeluXe   80

Geschrieben
  • Autor
Geschrieben

Hallo zusammen,

ich muss mich für den schlechten Eröffnungspost echt entschuldigen. Sorry - normalerweise ist die Qualität da besser bei mir. 

 

vor 6 Stunden schrieb Sunny61:

Zukünftig bitte als Text in einen Code-Tag posten, das erleichtert das Lesen ungemein. Bei deinem Bild sind am Anfang der ersten Zeile zwei Semikolon drin, die gehören dort bestimmt nicht rein. So sieht es von einem Windows Client aus:

  

C:\Users\ich>echo %PATH%
C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Users\ich\AppData\Local\Microsoft\WindowsApps;C:\adb;C:\ADB\;C:\Users\ich\AppData\Local\Microsoft\WindowsApps;
C:\Users\ich>

 

 

 

>> ich habe nochmal nachgeschaut das Semikolon steht dort tatsächlich so drin. Hier nochmal das Ergebnis des Befehls (administrative CMD):

  

C:\>echo %PATH%
; ;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\ProgramData\chocolatey\bin;D:\Program Files\Exchange\V15\bin;D:\Program Files\Exchange\V15\Bin\Search\Ceres\Native\;C:\Users\MHAdmin\AppData\Local\Microsoft\WindowsApps;

 

>> hier auch nochmal die Meldung aus der Exchange Mangement Shell:

  

New-PSSession : [ServerFQDN] Processing data from remote server ServerFQDN failed with the
following error message: [ClientAccessServer=CommonName,BackEndServer=ServerFQDN,RequestId=d05f7478-3533-4daa
-aa25-f27a393ffac0,TimeStamp=4/3/2026 7:55:54 PM]
[AuthZRequestId=af9fd34b-0aa1-4537-a11c-656f9606851f][FailureCategory=AuthZ-SetupVersionInformationCorruptException]
Unable to determine the installed file version from the registry key 'SOFTWARE\Microsoft\PowerShell\'. For more
information, see the about_Remote_Troubleshooting Help topic.
At line:1 char:1
+ New-PSSession -ConnectionURI "$connectionUri" -ConfigurationName Micr ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
   gTransportException
    + FullyQualifiedErrorId : IncorrectProtocolVersion,PSSessionOpenFailed

 

vor 7 Stunden schrieb d83b:

wirklich CU5 oder CU15 gemeint?

 

>> Das ist ein Schreibfehler. Aktuelle Version des Servers ist Exchange 2019 CU15 also 15.2.1748.10

 

==

 

Ich habe soeben auf einem der beiden Clustermember die Semikolons entfernt. Das Ergebnis ist danach jedoch weiterhin wie vorher.

  • Like 1
Sunny61 Grand Master

Sunny61   853

Geschrieben
Geschrieben

Die Registry Keys in der Fehlermeldung habt ihr sicherlich schon kontrolliert, oder?

Auch wenn es in dieser URL um Ex2016 geht, der Fehler geht IMHO in diese Richtung: https://azure365pro.com/exchange-management-shell-failurecategory-authz-setupversioninformationcorruptexception/

https://support.microsoft.com/en-us/topic/event-id-258-unable-to-determine-the-installed-file-after-you-uninstall-windows-powershell-2-0-1b34cdcf-7039-ff1f-af78-4e6c78cfe39d

Die 'normale' PS funktioniert einwandfrei?

PadawanDeluXe Mentor

PadawanDeluXe   80

Geschrieben
  • Autor
Geschrieben

Hallo,

die normale Powershell funktioniert einwandfrei. Den von dir zitierten Beitrag hatte ich bereits während meiner Recherche gefunden und geprüft. Hier sind die Registry Keys korrekt.

 

Der von @Sunny61 referenzierte Artikel liefert (leider) nicht mehr die Registry Settings bei MS zurück in der Gallery 

 

Gem. Meldung findet der IIS schlicht das Authentifizierungsmodul nicht. Nach weiterer Recherche wird potentiell das PowerShell Frontend im IIS der beiden Server nicht korrekt adressiert. Im Eventlog sieht man die EventID 23,258 im Application Log. 

 

EventID 23 

(Process w3wp.exe, PID 13408) "Exchange AuthZPlugin Fails to finish method GetApplicationPrivateData due to application exception Microsoft.Exchange.Diagnostics.SetupVersionInformationCorruptException: Unable to determine the installed file version from the registry key 'SOFTWARE\Microsoft\PowerShell\'. ---> System.FormatException: Input string was not in a correct format.
   at System.Number.ParseDouble(String value, NumberStyles options, NumberFormatInfo numfmt)
   at System.Convert.ToDouble(String value)
   at System.Linq.EnumerableSorter`2.ComputeKeys(TElement[] elements, Int32 count)
   at System.Linq.EnumerableSorter`1.Sort(TElement[] elements, Int32 count)
   at System.Linq.OrderedEnumerable`1.<GetEnumerator>d__1.MoveNext()
   at System.Linq.Buffer`1..ctor(IEnumerable`1 source)
   at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source)
   at Microsoft.Exchange.Diagnostics.ExchangeSetupContext.get_PSHostPath()
   --- End of inner exception stack trace ---
   at Microsoft.Exchange.Diagnostics.ExchangeSetupContext.get_PSHostPath()
   at Microsoft.Exchange.Configuration.Authorization.InitialSessionStateBuilder.InitializeWellKnownSnapinsIfNeeded(ExchangeRunspaceConfigurationSettings settings, Boolean isPowerShellWebServiceSession)
   at Microsoft.Exchange.Configuration.Authorization.InitialSessionStateBuilder.Build(List`1 allCmdlets, List`1 allScripts, ExchangeRunspaceConfiguration runspaceConfig)
   at Microsoft.Exchange.Configuration.Authorization.ExchangeRunspaceConfiguration.CreateInitialSessionState()
   at Microsoft.Exchange.Configuration.Authorization.ExchangeAuthorizationPlugin.GetInitialSessionStateCore(PSSenderInfo senderInfo)
   at Microsoft.Exchange.Configuration.Authorization.ExchangeAuthorizationPlugin.<>c__DisplayClass24_0.<GetApplicationPrivateData>b__1()
   at Microsoft.Exchange.Configuration.Authorization.AuthZLogHelper.HandleExceptionAndRetry[T](String methodName, Func`1 func, Boolean throwException, T defaultReturnValue)."

 

EventID 258 

(Process 13408, PID w3wp.exe)"RemotePS Public API Func GetApplicationPrivateData throws Exception Microsoft.Exchange.Diagnostics.SetupVersionInformationCorruptException: Unable to determine the installed file version from the registry key 'SOFTWARE\Microsoft\PowerShell\'. ---> System.FormatException: Input string was not in a correct format.
   at System.Number.ParseDouble(String value, NumberStyles options, NumberFormatInfo numfmt)
   at System.Convert.ToDouble(String value)
   at System.Linq.EnumerableSorter`2.ComputeKeys(TElement[] elements, Int32 count)
   at System.Linq.EnumerableSorter`1.Sort(TElement[] elements, Int32 count)
   at System.Linq.OrderedEnumerable`1.<GetEnumerator>d__1.MoveNext()
   at System.Linq.Buffer`1..ctor(IEnumerable`1 source)
   at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source)
   at Microsoft.Exchange.Diagnostics.ExchangeSetupContext.get_PSHostPath()
   --- End of inner exception stack trace ---
   at Microsoft.Exchange.Diagnostics.ExchangeSetupContext.get_PSHostPath()
   at Microsoft.Exchange.Configuration.Authorization.InitialSessionStateBuilder.InitializeWellKnownSnapinsIfNeeded(ExchangeRunspaceConfigurationSettings settings, Boolean isPowerShellWebServiceSession)
   at Microsoft.Exchange.Configuration.Authorization.InitialSessionStateBuilder.Build(List`1 allCmdlets, List`1 allScripts, ExchangeRunspaceConfiguration runspaceConfig)
   at Microsoft.Exchange.Configuration.Authorization.ExchangeRunspaceConfiguration.CreateInitialSessionState()
   at Microsoft.Exchange.Configuration.Authorization.ExchangeAuthorizationPlugin.GetInitialSessionStateCore(PSSenderInfo senderInfo)
   at Microsoft.Exchange.Configuration.Authorization.ExchangeAuthorizationPlugin.<>c__DisplayClass24_0.<GetApplicationPrivateData>b__1()
   at Microsoft.Exchange.Configuration.Authorization.AuthZLogHelper.HandleExceptionAndRetry[T](String methodName, Func`1 func, Boolean throwException, T defaultReturnValue)
   at Microsoft.Exchange.Configuration.Authorization.AuthZLogHelper.<>c__DisplayClass13_0`1.<ExecuteWSManPluginAPI>b__2()
   at Microsoft.Exchange.Diagnostics.CmdletInfra.Diagnostics.ExecuteAndLog[T](String funcName, Boolean missionCritical, LatencyTracker latencyTracker, IExEventLog eventLog, EventTuple eventTuple, Trace tracer, IsExceptionInteresting isExceptionInteresting, Action`1 onError, T defaultReturnValue, Func`1 func). fails with Exception %4 ."

 

Ein weiterer Workaround wie hier beschrieben hat nicht funktioniert. Auf den Servern selbst kann das Snapin nicht importiert werden. (wenn Pwsh V2 verwendet wird) bei Version 5 kann das Modul geladen, aber nicht verbunden werden. 

 

Wir haben nochmals die IIS Frondend Configs gem. MS Vorgabe hier geprüft. Hier ist alles in Ordnung. Schaue ich in die Backends ist Powershell in Ordnung aber PowerShell-Proxy wirft folgenden Fehler:

 

 

image.png.42200b1c2c15e1d2368bc30e01f4e5d8.png

 

Die web.config liefert in Zeile 61 folgendes:

(Config ab Zeile 59ff) 

  <system.web>
    <machineKey validationKey="AutoGenerate,IsolateApps" />
    <authentication mode="Windows" />
    <compilation debug="true">
      <assemblies>
        <add assembly="Microsoft.Exchange.Configuration.Core, Version=15.0.0.0, Culture=neutral, publicKeyToken=31bf3856ad364e35" />
        <add assembly="Microsoft.Exchange.Configuration.RemotePowershellBackendCmdletProxyModule, Version=15.0.0.0, Culture=neutral, publicKeyToken=31bf3856ad364e35" />
        <add assembly="Microsoft.Exchange.Configuration.ObjectModel, Version=15.0.0.0, Culture=neutral, publicKeyToken=31bf3856ad364e35" />
        <add assembly="Microsoft.Exchange.Configuration.RedirectionModule, Version=15.0.0.0, Culture=neutral, publicKeyToken=31bf3856ad364e35" />
        <add assembly="Microsoft.Exchange.Data, Version=15.0.0.0, Culture=neutral, publicKeyToken=31bf3856ad364e35" />
        <add assembly="Microsoft.Exchange.Data.Directory, Version=15.0.0.0, Culture=neutral, publicKeyToken=31bf3856ad364e35" />
        <add assembly="Microsoft.Exchange.Common.Directory.DirectoryVariantConfig, Version=15.0.0.0, Culture=neutral, publicKeyToken=31bf3856ad364e35" />
        <add assembly="Microsoft.Exchange.Configuration.FailFast, Version=15.0.0.0, Culture=neutral, publicKeyToken=31bf3856ad364e35" />
        <add assembly="Microsoft.Exchange.Security, Version=15.0.0.0, Culture=neutral, publicKeyToken=31bf3856ad364e35" />
        <add assembly="Microsoft.Exchange.Configuration.DiagnosticsModules, Version=15.0.0.0, culture=neutral, publicKeyToken=31bf3856ad364e35" />
      </assemblies>
    </compilation>
  </system.web>

 

Kann mir hier ggfs. jemand seine webconfig mal teilen zum Vergleich?

 

Danke nochmal an alle für die Unterstützung!

 

Sunny61 Grand Master

Sunny61   853

Geschrieben
Geschrieben

Hier mal eine von uns, Exchange SE, fully patched. Beginnt bei mir in Zeile 60 mit system.web.

  

<system.web>
    <machineKey validationKey="AutoGenerate,IsolateApps" />
    <authentication mode="Windows" />
    <compilation debug="true">
      <assemblies>
        <add assembly="Microsoft.Exchange.Configuration.Core, Version=15.0.0.0, Culture=neutral, publicKeyToken=31bf3856ad364e35" />
        <add assembly="Microsoft.Exchange.Configuration.RemotePowershellBackendCmdletProxyModule, Version=15.0.0.0, Culture=neutral, publicKeyToken=31bf3856ad364e35" />
        <add assembly="Microsoft.Exchange.Configuration.ObjectModel, Version=15.0.0.0, Culture=neutral, publicKeyToken=31bf3856ad364e35" />
        <add assembly="Microsoft.Exchange.Configuration.RedirectionModule, Version=15.0.0.0, Culture=neutral, publicKeyToken=31bf3856ad364e35" />
        <add assembly="Microsoft.Exchange.Data, Version=15.0.0.0, Culture=neutral, publicKeyToken=31bf3856ad364e35" />
        <add assembly="Microsoft.Exchange.Data.Directory, Version=15.0.0.0, Culture=neutral, publicKeyToken=31bf3856ad364e35" />
        <add assembly="Microsoft.Exchange.Common.Directory.DirectoryVariantConfig, Version=15.0.0.0, Culture=neutral, publicKeyToken=31bf3856ad364e35" />
        <add assembly="Microsoft.Exchange.Configuration.FailFast, Version=15.0.0.0, Culture=neutral, publicKeyToken=31bf3856ad364e35" />
        <add assembly="Microsoft.Exchange.Security, Version=15.0.0.0, Culture=neutral, publicKeyToken=31bf3856ad364e35" />
        <add assembly="Microsoft.Exchange.Configuration.DiagnosticsModules, Version=15.0.0.0, culture=neutral, publicKeyToken=31bf3856ad364e35" />
      </assemblies>
    </compilation>
  </system.web>

 

mwiederkehr Veteran

mwiederkehr   419

Geschrieben
Geschrieben

Kannst Du die Zeile  

<authentication mode="Windows" />

einmal auskommentieren? Meldet der IIS danach immer noch einen Fehler?

 

Bei mir ist die Zeile aber auch drin und der IIS-Manager meldet kein Problem. Dann müsste auf höherer Ebene (evtl. applicationhost.config) etwas verstellt sein.

PadawanDeluXe Mentor

PadawanDeluXe   80

Geschrieben
  • Autor
Geschrieben (bearbeitet)

Hi, das ist eine Idee...

 

zur Info für alle: 

    <linkedConfiguration href="file://C:\Program Files\Exchange\V15\ClientAccess\SharedWebConfig.config"/>
    <linkedConfiguration href="file://C:\Program Files\Exchange\V15\bin\SharedBindingRedirects.config" />

 

Wären die beiden Verweise auf die übergeordneten Ebenen aus meiner Sicht. Ich habe einfach mal mit Compare Plugin (Notepad++) die Sache verglichen und komme hier auch bei einem (bestehenden als funktional geprüften) Backup auf keine Unterschiede. 

Mag mir denn mal jemand aus dem Frontend/Backend seine aktivierten Auths schicken für die Endpunkte Powershell (Frontend) / Powershell (Backend) / Powershell-Proxy (Backend) und die jeweilg darüber liegende Default Web Site / Exchange Back End?

Orientierung:
image.thumb.png.ede7b1f5082626c9e005d06c4908e001.png

===
Beispiel Powershell (Frontend)
image.png.d108c459bd5bf4ba90ca6ad0f0f5bef6.png

 Ich lese hierzu in der MS KB hier nach und orientiere mich zunächst am Standard. Ich weiß dass die Frage eher obsolet ist - aber vielleicht fällt eine Differenz auf. 

 

@mwiederkehr bekommst du für die Subsite "Powershell-Proxy" ebenfalls eine Fehlermeldung?

bearbeitet von PadawanDeluXe
Ergänzung zur Frage im Post
mwiederkehr Veteran

mwiederkehr   419

Geschrieben
Geschrieben

Hier von einem Exchange 2019 CU14 (Update ist "schon" terminiert):

image.png.fe7de1d772fd8f0f3d9861368bc17cff.png

 

image.png.8fd39b25dd040c072615dad6e51843bb.png

 

image.png.6eace399d3d06a5c4ab4bf52f00117f1.png

 

Ich habe die Fehlermeldung auch, wenn ich bei "PowerShell-Proxy" auf "Authentication" klicke. Bitte entschuldige, ich hatte vorhin nur das Verzeichnis angeklickt. Normalerweise erscheinen Fehler in der web.config direkt dort.

 

Aus Sicht von IIS ist die Meldung nachvollziehbar: Module kann man nur auf Websites oder Anwendungen aktivieren, nicht auf Verzeichnissen. Ich weiss nicht, was die Überlegung der Exchange-Entwickler dahinter war.

 

Auf jeden Fall läuft der Server trotzdem. Und, wie einem Exchange-Leute ja immer wieder sagen, soll man den IIS-Manager nicht verwenden. :-)

  • Danke 1
MurdocX Veteran

MurdocX   1.059

Geschrieben
Geschrieben

Hi,

 

oben steht mehrmals, dass er den Registry-Eintrag nicht lesen/entziffern kann. Wurde dort schon mal angesetzt? "HKLM\SOFTWARE\Microsoft\PowerShell\"

 

Schon mal versucht die PS zu reparieren?

Schon mal das HealthChecker.ps1 ausgeführt?

 

VG,

Jan

MurdocX Veteran

MurdocX   1.059

Geschrieben
Geschrieben
vor 1 Minute schrieb NorbertFe:

Dürfte schwierig werden ohne Exchange powershell. ;)

Der geht an Dich. :D haha.

Klassisches Henne - Ei Problem hier. 

Am 4.4.2026 um 12:37 schrieb Sunny61:

https://support.microsoft.com/en-us/topic/event-id-258-unable-to-determine-the-installed-file-after-you-uninstall-windows-powershell-2-0-1b34cdcf-7039-ff1f-af78-4e6c78cfe39d

Die 'normale' PS funktioniert einwandfrei?

Das war auch meine Vermutung. Das Problem existiert wohl, wenn die PS mal deinstalliert wurde. 

Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde dich hier an.

Jetzt anmelden
Zurück zur Übersicht


×
×
  • Neu erstellen...