Exchange 2010 Problem beim Senden von eMails im CacheMode

[weeweewee 0]

Hallo,

ich habe einen SBS2011 / Exchange 2010 mit UpdateRollup 15 und allen Updates / Win7 Clients , derzeit 25 Clients.
Vorab einmal: alle alten Clients funktionieren einwandfrei.

Ich habe 2 Stationen ausgetauscht: ALT: Win7/Outlook 2007 Neu: Win10 Pro / Outlook 2013 neueste Updates

Die Einrichtung des Exchange-Kontos funktioniert einwandfrei.
Kontakte und eMails werden alle Synchronisiert und angezeigt.
Neue eMails landen auch im Postfach (Abgeholt durch POP vom Provider durch Server / SmartHost für Versand)

Wenn ich im Cache-Modus eine Mail versenden will, kommt SOFORT eine Antwort
 

Ihre Nachricht hat einige oder alle Empfänger nicht erreicht.

Betreff: jjjjjj
Gesendet am: 30.10.2016 20:52

Folgende(r) Empfänger kann/können nicht erreicht werden:

'xxxxxx@xxxxxx.de' am 30.10.2016 20:52
Keines Ihrer E-Mail-Konten kann Nachrichten an diesen Empfänger senden.

Stelle ich den Cachemodus aus, verhält es sich anders:
Die Mail wird normal versendet, aber der Inhalt der Kontakteordner ist leer (sowohl des Postfaches als auch in öffentliche Kontakte)
Er zeigt mir an, das über 4000 Kontakte im öffentlichen Kontakte sind, die Liste rechts ist aber leer.

OWA funktioniert einwandfrei.

Ich denke (bin nicht sicher), das Problem tritt unter Win10 auf ...

Kennt jmd. das Phänomen bzw. kann jmd helfen?

 

[Nobbyaushb 1.471]

Hast du unter OWA einen Zertifikats-Fehler?

 

Was für ein Zertifikat ist installiert?

 

;)

[weeweewee 0]

Habe auf den internen Clients keinen Zertifikatsfehler unter OWA.

Wenn ich auf ext. Clients das Zertifikat importiere, auch nicht.

Ist ein selbst ausgestelltes Zertifikat.

 

Habe das Problem eingegrenzt:

Tritt nicht unter Windows 7 oder Windows 8.1 auf (frisch installiert mit Office 2013 - selbe Version)

unter Win10 frisch installiert schon.

[MHeiss2003 11]

Habe das gleiche Problem in einer SBS2011 Umgebung mit Outlook 2016. Nachdem ich vermutet hatte, dass es an Office 2016 liegt habe ich Office 2016 deinstalliert und Office 2013 installiert. Leider genau das gleiche Problem. Mir hat das Downgrade auf Windows 7 geholfen, allerdings nur mit Office 2013, mit 2016 gleiches Problem unter Windows 7.

[Nobbyaushb 1.471]

Welchen Stand hat denn der Exchange im SBS?

http://blog-schulenburg.de/index.php/kategorie-als-blog/87-exchange-build-nummern

 

Das Zertifikat passt und OWA kann ohne Fehlermeldung oder Warnung aufgerufen werden?

 

Autodiscover OK?

 

;)

bearbeitet 15. November 2016 von Nobbyaushb

[weeweewee 0]

Standard Version 14.3 (Build 123.4)

ProductVersion: 14.03.0319.002

 

Das Zertifikat passt - OWA ohne Fehler und Warnung

 

Autodiscover NICHT ok, nicht im Zertifikat enthalten (autodiscover.domain.com)

Auf den Clients per Registry abgeschaltet.

 

Soll ich es mal aktivieren und entsprechend umstellen?

 

Würde es so machen:

Set-ClientAccessServer -AutoDiscoverServiceInternalUrl „https://remote.domainneu.de/Autodiscover/Autodiscover.xml“

set-Autodiscovervirtualdirectory -ExternalUrl „https://remote.domainneu.de/Autodiscover/Autodiscover.xml“-InternalUrl „https://remote.domainneu.de/Autodiscover/Autodiscover.xml"

 

:confused: :confused:

[Sunny61 806]

Welchen Stand hat denn der Exchange im SBS?

http://blog-schulenburg.de/index.php/kategorie-als-blog/87-exchange-build-nummern

Kannst Du Christian mal anfragen, ob er die Seite aktualisieren kann/will? Für den Exchange 2010 SP3 fehlt das UR15:

 

ProductVersion FileVersion

-------------- -----------

14.03.0319.002 14.03.0319.002

[weeweewee 0]

Sorry, habe ich nicht verstanden. Meinst du die OWA-Seite, ob die aktualisiert wird?

Oder meinst du die aktualisierung des UR15?

 

das meldet er bei mir für:

 

GCM exsetup |%{$_.Fileversioninfo}

 

ProductVersion FileVersion
-------------- -----------
14.03.0319.002 14.03.0319.002

 

ist das nicht UR15?

[Sunny61 806]

GCM exsetup |%{$_.Fileversioninfo}

 

ProductVersion FileVersion

-------------- -----------

14.03.0319.002 14.03.0319.002

 

ist das nicht UR15?

Doch, das ist UR15. Die Website von Christian Schulenburg ist noch nicht aktuell, deshalb die Frage an Norbert.

bearbeitet 15. November 2016 von Sunny61

[Nobbyaushb 1.471]

@Sunny - Erledigt :)

[Sunny61 806]

@Sunny - Erledigt :)

Danke. :)

[massaraksch 41]

Hi,

 

klingt vielleicht seltsam, aber es gibt diverse Hinweise, daß bei diesem Problem ein

 

sfc /scannow

 

helfen könnte (das Systemdatei-Überprüfungsprogramm).

 

Das Problem hat wohl eher nichts mit Exchange zu tun, da es ja anscheinend nur bei Win 10 auftritt.

[Nobbyaushb 1.471]

Wenn das Autodiscover nicht geht, klappt es nicht mit Clients -> Win 8.1 und gar nicht mit Outlook ab 2016

 

Dort wird ein funktionierendes Autodiscover vorausgesetzt.

 

Auch beim SBS kann man Split-DNS prima konfigurieren, nur halt manuell.

 

;)

[weeweewee 0]

Vielen Dank euch schon einmal, das ihr euch dem Problem annehmt !!!

 

SFC habe ich getestet, findet keine Fehler.

 

Okay, dann werde ich mich mal daran machen... (SplitDNS)

 

Ich hoffe, ich gehe da richtig vor:

 

habe eine lokale Domäne domain1.local und eine Internetdomäne domain2.de

 

remote.domain2.de habe ich per DynDns auf den Server geleitet.

Für SplitDNS bräuchte ich dann noch den AutoDiscovery-Eintrag beim Provider:

SRV-Eintrag

Service: _autodiscover
Protocol: _tcp
Port Number: 443
Host: remote.domain2.de

 

Set-ClientAccessServer -AutoDiscoverServiceInternalUrl „https://remote.domain2.de/autodiscover/autodiscover.xml“

set-Autodiscovervirtualdirectory -ExternalUrl „https://remote.domain2.de/autodiscover/autodiscover.xml“-InternalUrl „https://remote.domain2.de/Autodiscover/Autodiscover.xml"

 

ist das so richtig oder fehlt da etwas?

[Nobbyaushb 1.471]

Der Provider kann keine SRV-Einträge erstellen, und selbst wenn, gelten diese nur für Outlook / Windows, alle anderen Clients ignorieren das.

 

Du brauchst zwei URL, einmal Autodiscover.domain.tld und in deinem Fall remote.domain.tld.

 

Für diese beiden URL muss auch das Zertifikat ausgestellt sein, am besten von extern, z.B. GoDaddy oder StartSSL, kostet alles mittlerweile recht wenig.

 

Dann erstellst du eine primäre Zone im DNS mit dem Namen Autodiscover.domain.tld mit einem leeren Eintrag und der IP des SBS,

ebenso für autodiscover.domain.tld.

 

Und das Autodiscover zeigt zwangsweise auf die soeben externe und nun interne URL autodiscover.domain.tld, sowohl extern als auch intern.

 

;)

 

Edit: wenn das von extern auch funktionieren soll, müssen die externen URL durch deinen ISP gesetzt werden, dann brauchst du für sauberern Betrieb eh ein extern signiertes Zertifikat.

bearbeitet 15. November 2016 von Nobbyaushb