Beiträge von wrangel

Zitat von NorbertFe

Probiers aus.

Das ist Exchange - ein viele GB dicker Blob, der nur Mail und Kalender kann - und man muss stets die Funktionen reverse engeneeren...

O365 benutzt wirklich für die Verbindung zu On premise per EWS die InternalURL?

Hallo zusammen,

ich bin gerade dabei, eine hybrid Konfiguration zu aktivieren und dafür will ich EWS, OAB und Autodiscover über eine Schnittstelle zu O365 öffnen.

Diese Schnittstelle ist per haproxy als reverse proxy eingerichtet. Tests mit https://hybrid.domain.de/EWS/Exchange.asmx sind erfolgreich, nach Anmeldung ich bekomme die "Service - You have created a service" Seite.

Wenn ich aber unter https://testconnectivity.microsoft.com/, "Exchange Server" : "Synchronisierung, Benachrichtigung, Verfügbarkeit und automatische Antworten" teste, bekomme ich aber immer einen Fehler: "Nachricht: The request failed. The remote name could not be resolved: 'mail.domain.local'".

Hier macht mich der Name etwas stutzig: Warum wird der im Autodiscover "<server>" - Node ausgegebene Name verwendet (oder ist dies gar der hostname-part der internen EWS URL)?

Im haproxy.log sehe ich nur die (erfolgreichen) Autodiscover Meldungen, nicht jedoch die erwarteten Verbindungen auf die EWS.

Nun also zunächst die Frage, warum bekommte ich die Meldung: "The remote name could not be resolved: 'mail.domain.local'"

Vielen Dank und Grüße

Jan Michael

PS C:\OAuthConfig> Get-WebServicesVirtualDirectory -Server server-ex01 | FL server,*url*,*oauth*


Server               : SERVER-EX01
InternalNLBBypassUrl :
InternalUrl          : https://mail.domain.local/EWS/Exchange.asmx
ExternalUrl          : https://hybrid.domain.de/EWS/Exchange.asmx
OAuthAuthentication  : True

============================================================

Fehler

============================================================

Es wird ein temporärer Ordner zur Ausführung von Synchronisierungstests erstellt.

Fehler beim Erstellen des temporären Ordners zur Durchführung von Tests.

Ausnahmedetails:

Nachricht: The request failed. The remote name could not be resolved: 'mail.domain.local'
Typ: Microsoft.Exchange.WebServices.Data.ServiceRequestException
Stapelüberwachung:
at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.BuildEwsHttpWebRequest()
at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.ValidateAndEmitRequest(IEwsHttpWebRequest& request)
at Microsoft.Exchange.WebServices.Data.MultiResponseServiceRequest`1.Execute()
at Microsoft.Exchange.WebServices.Data.ExchangeService.BindToFolder(FolderId folderId, PropertySet propertySet)
at Microsoft.Exchange.WebServices.Data.ExchangeService.BindToFolder[TFolder](FolderId folderId, PropertySet propertySet)
at Microsoft.Exchange.Tools.ExRca.Tests.GetOrCreateSyncFolderTest.PerformTestReally()
Ausnahmedetails:
Nachricht: The remote name could not be resolved: 'mail.domain.local'
Typ: System.Net.WebException
Stapelüberwachung:
at System.Net.HttpWebRequest.GetRequestStream(TransportContext& context)
at System.Net.HttpWebRequest.GetRequestStream()
at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.TraceAndEmitRequest(IEwsHttpWebRequest request, Boolean needSignature, Boolean needTrace)
at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.BuildEwsHttpWebRequest()

autodiscover.xml.txt

Also keine Abkürzung...

Hallo Forum,

wieder eine etwas grundsätzliche Frage:

Nach einem Update mit Maintenance Mode per

Set-ServerComponentState exchange-server –Component ServerWideOffline –State Active –Requester Maintenance

sehe ich auf einigen (nicht allen) Servern oft (immer?) dieses Bild:

Component         State
---------         -----
ServerWideOffline Active
HubTransport      Active
FrontendTransport Active
Monitoring        Active
RecoveryAction... Active
AutoDiscoverProxy Inactive
ActiveSyncProxy   Inactive
EcpProxy          Active
EwsProxy          Inactive
ImapProxy         Active
OabProxy          Inactive
OwaProxy          Active
PopProxy          Active
PushNotificati... Active
RpsProxy          Active
RwsProxy          Active
RpcProxy          Inactive
UMCallRouter      Active
XropProxy         Active
HttpProxyAvail... Active
ForwardSyncDaemon Active
ProvisioningRps   Active
MapiProxy         Inactive
EdgeTransport     Active
HighAvailability  Active
SharedCache       Active

Der Requester ist jedesmal die HealthApi (habe gerade nicht mehr den Output von (Get-ComponentState | where {$_.State -eq 'Inactive'}).LocalState zur Hand).

Das zu beheben ist erstmal auch kein Problem und die Lösungen sind wiederholt protokolliert:

https://www.frankysweb.de/exch…-server-component-states/ und https://www.johnlose.de/2016/0…-update-oder-patchfehler/ und viele weitere.

Ich finde aber keine Erklärung, warum es passiert, dass die HealthApi die Components wieder runter nimmt.

Könnt ihr mich auf die richtige Spur bringen?

_{Server: Exchange Version 15.0 (Build 1497.2) / Windows 2012 R2}

Hallo Forum,

mal eine grundsätzliche Frage:

Ich habe eine DAG (mit zwei Ex2013 Servern) und installiere Windows Updates. Und boote den Server dabei.

Vorher setze ich den Server in etwa so in den Maintenance Modus, wie hier beschrieben: https://dev.techrunnr.com/inst…exchange-server-2013-dag/

Würdet ihr bei Windows Updates einen DAG Member auch in den Maintenance Modus schicken - oder - direkt installieren, booten, fertig?

Zitat von cj_berlin

Moin,

die Infos bekommt der Client ja von Autodiscover. Schau mal, was passiert, wenn Du nach der Änderung den Autodiscover-AppPool auf allen Servern recycelst.

Ja, das ist genau das, was ich gesucht habe!

Set-OrganizationConfig -MapiHttpEnabled $false
Restart-WebAppPool MSExchangeAutodiscoverAppPool
bzw.
Set-OrganizationConfig -MapiHttpEnabled $true
Restart-WebAppPool MSExchangeAutodiscoverAppPool

Ändert die autodiscover.xml, die der Exchange Server ausliefert sofort!

Vielen Dank an alle für die ganzen Hinweise!

Zitat von NobbyausHB

Du bist vor einer Migration zu Exchange 2016 oder 2019?

Nur so halb - wir richten einen Hybrid zu 0365 ein und müssen von rpc/http zu mapi/http wechseln, damit oauth funktioniert. Danach wird vermutlich ein Update kommen...

Zitat von NobbyausHB

Hatte ich in meiner Antwort geschrieben - und du hast nicht davon geschrieben, das am Client was gemacht wird

Der Client bekommt für jeden Versuch ein neues Profil, um diese Quelle für Verzögerungen und Seiteneffekte auszuschließen.

Tatsächlich ändert sich die autodiscover.xml nach

[PS] C:\Windows\system32>Set-OrganizationConfig -MapiHttpEnabled $false
Creating a new session for implicit remoting of "Set-OrganizationConfig" command...

[PS] C:\Windows\system32>iisreset /stop /timeout:120
Attempting stop...
Internet services successfully stopped

[PS] C:\Windows\system32>iisreset /start /timeout:120
Attempting start...
Internet services successfully started

/timeout:120 - reicht hier aus für einen Neustart vom IIS.

Zitat von NorbertFe

Nein das greift sofort. Bis die Clients allerdings das Profil aktualisieren dauert es schon ein paar Stunden/Tage.

Mmmh... Dagegen spricht, dass ich auf dem Server

[PS] C:\Windows\system32>set-OrganizationConfig -MapiHttpEnabled $false
[PS] C:\Windows\system32>Get-OrganizationConfig | fl *mapi*

MapiHttpEnabled : False

ausführe und im Client dann ein neues Profil erstellen lasse. Rpc ist erst wieder aktiviert, wenn ich den Server neu starte.

Da sich dann auch erst die autodiscover.xml unterscheidet (und der Type="mapiHttp" Abschnitt verschwindet), vermute ich, dass die serverseitige Erstellung der autodiscover.xml die Ursache für die Verzögerung ist.

Damit wäre die nächste Frage - wie erstellt der Server die autodiscover.xml und wie kann ich eine Erneuerung erzwingen?