microsoft exchange web services managed api 2.2: bekannte Probleme betreffend Exchange 2016 bekannt?

[andrew 15]

Liebes MCSE Board

 

Ist euch Exchange Spezialisten bekannt, dass auf einem Exchange 2016 folgende Anwendung zu Problemen führen und oder Instabilitäten hervorrufen kann? Anwendung: microsoft exchange web services managed api 2.2

Wenn ja, welche Probleme und oder Instabilitäten könnten hervorgerufen werden?

 

Nette Grüsse

Andrew

 

[Nobbyaushb 1.363]

Kannst du deine Frage bitte weiter spezifieren?

 

Und welches CU hat der 2016, oder ist das eine generelle Frage?

 

Irgendwas von 3rd Party?

 

[andrew 15]

Meine Frage ist eine allgemeine Frage: Mich würde interessieren, wenn auf einem Exchange 2016 diese Anwendung hier installiert ist microsoft exchange web services managed api 2.2, ob diese Anwendung auf dem Exchange zu Problemen führen kann im Sinne von: Dass der Exchange 2016 instabil wird und oder dass andere, Unannehmlichkeiten auftreten könnten!

 

Welche CU aktuell auf unserem Exchange installier ist, kann ich jetzt gerade nicht überprüfen, da nicht im Geschäft und heute nicht am Arbeiten. "Schätzungsweise müsste ist das letzte CU vor ca. 6 Monaten installiert worden"

Mich würde es interessieren, ob es Gründe gibt, die strikt dagegen sprechen, auf einem Exchange 2016 diese Anwendung zu installieren?

 

bearbeitet 5. November 2020 von andrew

[tesso 360]

Warum willst du die EWS Api auf dem Exchange installieren?

Ich installieren an einem Client/Server, der dann die Skripte ausführt.

[andrew 15]

Will die Anwendung microsoft exchange web services managed api 2.2 NICHT auf einem Exchange 2016. Sie war bei einem Kunde installiert und wurde in der Zwischenzeit durch einen externe Informatik Firma deinstalliert Und: Es wurde die Frage gestellt, warum diese Applikation auf dem Exchange installiert gewesen sei.

 

Warum und wieso diese Anwendung dort installiert war kann wohl auch schwer im nachhinein herausgefunden werden oder?

Thema: Wenn ein Exchange vielleicht irgendwelche kleine Probleme aufweist wie: Nachrichten kommen ab und zu erst nach ein paar Minuten im Benutzerpostfach xy an oder wenn z.B. Mails mit starken Verzögerungen versendet werden usw. Dann kann es gemäss meiner Erfahrung passieren, dass dann mal ein Kunde schnell zum Hörer greift, der externen Firma xy anruft, der externe Mitarbeiter verbindet sich per remote, analysiert das System und stellt wohl berechtigt die Frage, warum und wieso eben beispielsweise diese Anwendung auf dem Exchange installiert war und deinstalliert Sie, weil er der Ansicht ist, dass diese nicht auf den Exchange gehöre und höchstes Probleme verursachen könnte.

 

Spinnen wir den Faden nun noch weiter in das "Extreme". Man wird vielleicht vom Kunde sogar "angegriffen" im Sinne von: Hey, unser Exchange läuft nun stabil, die Anwendung microsoft exchange web services managed api 2.2 wurde auf dem Exchange installiert und nun deinstalliert und war schuld für diese "kleine Probleme".

 

Miene genannten Probleme sind nur Beispiele, müssen nicht stimmen. Ich möchte nur darauf hinaus, dass eine solche Behauptung sehr "schwierig" zu beurteilen ist. 

Darum auch meine Frage im Titel und eingehend von meinem Post, denn wie soll ich dann beispielsweise beweisen können, dass diese Applikation Problem X oder Z eben NICHT zwingend schuld daran war. OK, vielleicht gehört eine solche Applikation wirklich nicht auf den Exchange, aber eben, ab und zu im Leben oder in der IT läuft was nicht immer nach Schema X ab, wenn Schema X als "der korrekte Weg oder Bestr Practices oder wie soll man das nennen?" verläuft.

 

Darum wäre ich nach wie vor froh, um Stellung zu meiner gezielten Frage zu nehmen. Hat Jemand Erfahrungen, dass wenn diese Applikation auf einem Exchange installiert oder installiert würde, tatsächlich zu "zig Problemen" führen kann oder könnte, meine Frage nun verstanden?

 

Vielleicht ist ja eine solche Anwendung auch unwissentlich auf dem Exchange installiert worden oder man wollte eine Anwendung xy auf dem Exchange installieren und by the way wurde halt diese Anwendung microsoft exchange web services managed api 2.2 auch mit installiert, wer weiss das schon?!

bearbeitet 5. November 2020 von andrew

[tesso 360]

Die EWS API ist nur eine API über die du auf die EWS Schnittstelle zum programmieren dieser Schnittstelle zugreifst. 

Der Exchange nutzt die nicht selbst. Daher ist es sehr unwahrscheinlich, das die API für eine Instabilität verantwortlich ist. Ich habe die nur mal auf einem Testsystem direkt auf dem Exchange installiert, der hatte danach keine Probleme.

Problematisch sind eher neuere .net Versionen, wenn der Exchange noch nicht das entsprechende CU hat.

Und natürlich auch alles Richtung (falsch oder nicht konfigurierte) Virenscanner. Dazu noch alles was in den Nachrichtentransport eingreift.

[andrew 15]

Ok. das finde ich nun mal eine richtig aussagekräftige Antwort  Mit dieser kann ich was anfangen, vielen Dank.

Gerne möchte ich da gleich einhacken: Jeden Monat stehen immer die bekannten Windows Updates zur Verfügung, welche nicht nur auf Clients, sondern natürlich auch auf Servern installiert werden müssen.

 

Nun, wenn ich auf einem Exchange vielleicht mal ein .NET installiere oder installieren möchte, wie weiss ich denn, ob diese .NET Applikation mit der bestehenden installierten CU auf dem Exchange "kompatibel" ist?

 

Mit ist nicht bekannt, dass in den System requirements des entsprechenden .NET, welches mir via WSUS zum Download bereit gestellt wurde, dort irgendwo angezeigt wird, dass z.B. als Voraussetzung CU Version xy installiert sein muss?

bearbeitet 5. November 2020 von andrew

[Dukel 436]

Sowas muss man als Admin prüfen:

https://docs.microsoft.com/en-us/exchange/plan-and-deploy/system-requirements?view=exchserver-2019#supported-net-framework-versions-for-exchange-2019

[andrew 15]

Danke für den Link.

[tesso 360]

Dazu dann beispielhaft noch die Möglichkeit die .net Installation zu unterbinden.

https://support.microsoft.com/en-us/help/3133990/how-to-temporarily-block-the-installation-of-the-net-framework-4-6-1

 

Für supportete Umgebungen würde ich in der SUpport Matrix nachsehen.

https://docs.microsoft.com/en-us/Exchange/plan-and-deploy/supportability-matrix?view=exchserver-2019

[andrew 15]

Die Möglichkeit der Unterbindung durch .NET finde ich interessant. Könnte je nach Situation hilfreich sein.