PadawanDeluXe

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: === Beispiel Powershell (Frontend) 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?

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: 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!

Hallo zusammen, ich muss mich für den schlechten Eröffnungspost echt entschuldigen. Sorry - normalerweise ist die Qualität da besser bei mir. >> 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 >> 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.

Ergänzung: ich poste anbei anonymisiert die Powershell Fehlermeldung: Path Ergebnis:

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.

Das ist der Gedächtnistag für alle diejenigen die keinen Brückentag genommen haben.

Hi, ich denke, das Problem liegt am (Outlook) Client. Probier mal diesen Ordner hier zu löschen: %USERPROFILE%\Local Settings\Application Data\Microsoft\Outlook und in der Registry den Baum unter: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office (Hinweis: der jeweilige User muss angemeldet sein) Ich erinnere ein Problem mit der Geschwindigkeit in einem ähnlichen Szenario. Bitte prüfe es nochmals im Cache mode. (dann hättest du zumindest eine Diagnose)

Hallo zusammen, ich kann am 30.08. der 06.09. wäre mir unlieb da ich dort bereits eine Verpflichtung habe.

Auf baldige Besserung! Alles Gute! Schade das es dieses Mal nicht klappt aber das nächstes Mal bestimmt!

Hi, gibt es eine Firewall auf einem der beteiligten Systeme die SMB/CIFS blockt? Es liest sich so als wenn genau für den PC so etwas konfiguriert wurde. Vielleicht kannst du das aber auch aus der Inventarliste ableiten.

Hallo vkf, wenn die Mailadresse abgelehnt wird vom System kann er Kontakt zum Betreiber aufnehmen. Das Kontaktformular findet er hier: Formular

Hallo zusammen, ich wäre dabei. Vorläufiger Termin ist eingetragen. Mir persönlich wäre eine Woche später lieber. Es soll aber bitte nicht an mir scheitern. Wie wäre es denn mal wieder mit einem "Call for Papers"? Ein kurzer Vortrag von 15-30min wäre doch mal wieder klasse um Gespräche zu initiieren.

Hallo zusammen, leider habe ich schlechte Nachrichten zu überbringen, denn: ich kann nicht. Das zu begründen ist kurz gefasst: Mir wurde nahegelegt zu der Veranstaltung die parallel in meinem Kalender steht zu erscheinen. Also kurz gesagt heißt das: ich bin bis 2200 gebunden und komme erst dann los. Wie sieht es denn dann aus? Soll ich dann nachkommen?

Na wir wollen ja potentziell Interessenten hier nicht abschrecken... ;) etwas geheimnisvolles müssen wir uns ja behalten. Brüder im Geiste... hihi. Ich bekomme schon wieder Gedanken.

Hallo zusammen, ich werde dabei sein. Mein Blut in Form meines Daumenabdruckes bestätige meine Willensabsichten...

Hi, mach mal bitte eine PowerShell auf und tippe mal folgendes ein: Systeminfo.exe Kannst du bitte einmal das volle (anonymisierte) Output posten? EDIT: Jan hat bereits die Hardware geprüft; Bitte einmal wie o.g. durchführen und dann hier zum Vergleich einmal posten bitte. Danke!

Wir nutzen unterschiedliche Tools. Ja Ansible ist toll, aber auch SCCM oder andere

Ich würde hier an dieser Stelle mal darüber nachdenken ein grundsätzliches Automatsierungstool einzuführen. Wenn ihr das habt - scripting machen. Das startet man am besten mit einem PAP. Wir haben ein Automatisierungstool und ich baue meine Tasks genau nach diesem Prinzip nach. Möglichst mit Boardmitteln per Shell dann habe ich die wenigstens Probleme gehabt in der Vergangenheit.

Hi und willkommen ich kann aus meiner Vergangenheit sagen, dass der Windows Deployment Server sehr sehr gute Dienste leistet wenn man einmalig etwas Zeit darin investiert und ebenfalls ein paar Dinge für die Zukunft bedenkt. Wie @NilsK eingangs schon erwähnte ist generell nur zu sagen, dass du dir einen Weg suchen musst indem du dir effizient dein Setup zusammen stellst. Was ist denn deine Anforderung? Möchtest du wirklich nur Clients aufsetzen? Hast du denn immer identische Hardware? Wie sieht es mit Treiberpaketen usw. aus? Ein Golden Image bei 100 Installationen im Jahr vorzuhalten empfinde ich persönlich nicht als großen Invest wenn man anschließend eine Silent Installation hat. Letztlich (so sehe ich es) ist ein PXE Boot Server immer noch das universalste Werkzeug anstelle jedes Mal ein dediziertes Systemimage zu erstellen.

Hallo zusammen, grundsätzlich hätte ich Interesse an einem Treffen. Ich würde auch einen Freitag bevorzugen. Wiesbaden sind etwa 4-5h ab hier - das muss ich dann sehen. @XP-Fan ich würde mich freuen wenn wir uns mal wieder sehen. Was ist eigentlich mit @Finanzamt @Esta ? Wärt ihr auch dabei?

Hallo q617, ich las in einem deiner Threads, dass AutoIT bereits verwendet wird. Im Endeffekt muss man sich eben überlegen welche Schritte zu erledigen sind und diese vielleicht in einem Programmablaufplan (PAP) darstellen. Anschließend sollte eine entsprechende Spracheg ewählt werden (AutoIT, PowerShell o.ä.) um das Aufgabenpaket zu erledigen. Wenn es hier keine komplette Pipeline gibt zur Bereitstellung dann ist man grundsätzlich frei - am schnellsten wird wahrscheinlich PowerShell sein, wenn man halbwegs fit ist.

Jop - genau das war der fehlende Parameter dahinter.

Hallo Norbert, aber wo kann ich es dann mit der Verwaltungsshell denn sehen?

Ich schau mal ob es wirklich ein Client Setting ist. Was anderes könnte ich mir so auch nicht mehr vorstellen..... Danke für deinen Tipp!

Hallo zusammen, zum Wochenende hätte ich da nochmal einen Nussknacker: Ich habe auf eine Exchange Instanz einen merkwürdigen Fehler mit einem Benutzer-Postfach, welches vor der finalen Löschung in eine Shared-Mailbox konvertiert wurde. Nach einem Zeitraum (ich meine es war ca. 1 Jahr) wurde es endgültig gelöscht. Jetzt erhält allerdings ein einzelner Benutzer eine Fehlermeldung, dass das Postfach nicht zu finden sei aber auch nur dann wenn er den Out-of-Office Agenten aktiviert. Sobald er nun eine Mail erhält wird auch durch das System ein Fehler generiert, den ich oben in den Threadtitel gepackt habe. Naja ich kann mir ja vorstellen, dass der X500 Name nach der Konvertierung nicht mehr korrekt war aber jetzt wo er nicht mehr vorhanden ist sollte das kein Fehler mehr sein außer es wird in der OoO Konfiguration der Empfänger noch benannt. Das habe ich geprüft und konnte hier keine Weiterleitung an genau diesen Adressaten erkennen. Auch in den Empfängermailboxen findet sich kein Verweis mehr auf besagte x500 Adresse. Auch im Transport habe ich keine Feststellung machen können, wieso und weshalb ein Lookup auf diese Adresse stattfindet. Somit also meine Frage an euch: Habt ihr noch eine Idee wie ich identifizieren kann, ob noch ein Verweis auf diese Adresse in meiner Exchange Instanz besteht bzw. wie kann ich diesen Fehler einfach abstellen? (ja ich kann diese Adresse einfach in irgendeine Mailbox packen - das wäre für mich ein Workaround, löst aber das Problem final nicht) Vielen Dank für euren Support.