none
Outlook kann ein Exchange 2013 Postfach nicht öffnen: Fehler: ...Bevor Sie Ihre Ordner mit Ihrer Outlook-Datendatei (.ost) synchronisieren können... RRS feed

  • Frage

  • Beim Versuch ein Exchange2013-Profil mit Outlook zu öffnen taucht folgender Fehler auf:

    "Ihre Standard E-Mail-Ordner können nicht geöffnet werden. Bevor Sie Ihre Ordner mit Ihrer Outlook-Datendatei (.ost) synchronisieren können, müssen Sie eine Verbindung mit Microsoft Exchange mit Ihrem aktuellen Profil herstellen."

    Dieser Fehler taucht nur auf, wenn der Client-Rechner kein Domainmitglied ist.

    Vom Rechner, der ein Mitglied in der Domäne ist, klappt die Verbindung dagegen problemlos.

    Wie kann das o.g. Problem mit der Verbindung von "nicht-Domainmitglieder beseitigt" werden?

    Exchange 2013 ist auf dem Windows Standard Server 2012 R2 installiert.
    Es handelt sich um eine lokale Domäne und Clients im Intranet.
    Der gleiche Fehler taucht bei allen Outlook 2007, 2010, 2013 Versionen auf.
    Das Zertifikat wurde wie unter http://technet.microsoft.com/de-de/library/jj218640%28EXCHG.150%29 beschrieben erstellt und am Client-Rechner installiert.

    Montag, 24. März 2014 12:50

Antworten

  • Hallo Robert,

    ich habe parallel zu dir eine Teststellung aufgebaut und versucht das Problem nachzustellen. Allerdings erhielt ich nie deine Fehlermeldung in Outlook, selbst mit dem selbst signierten Zertifikat des Exchange nach der Installation klappte es trotz Meldungen.

    Wenn du eine Externe URL für Outlook Anywhere einträgst, gibt es mehrere Möglichkeiten der Zertifikate:

    1. (die einfachste) du besorgst dir ein SSL Zertifikat von einer offiziellen CA, denn dort ist das Root Zertifikat bzw. die Zertifikatskette bereits in Windows einhalten. Also Zertifikat beantragen, am Exchange einrichten und fertig. Kostet aber was ...
    2. Du baust dir eine CA im Active Directory, das Root Zertifikat wird innerhalb der Domäne automatisch verteilt, konfigurierst es wie in der Anleitung am Exchange und für die internen Clients ist alles fertig. Die Clients außerhalb der Domäne müssen aber auf welche Art auch immer das Stammzertifikat deiner CA bekommen. Export-Import oder Manuelle Installation kannst du dir aussuchen.
    3. Mit dem selbst signierten Zertifikat zu arbeiten würde ich dir auf jeden Fall abraten. Das macht nur Arbeit und Probleme

    Ich weiß, dass du bei StartSSL kostenlos Zertifikate bekommst, wo das Root Zert schon in Windows enthalten ist. Ich vielleicht nicht eine der sichersten CA's und das Level der Verifizierung ist auch das geringste aber kannst du ja mal ausprobieren.

    Die Outlook Proxy Einstellungen kommen übrigens aus dem Autodiscovery und kannst du normalerweise drin lassen. Funktionieren sollte es trotzdem.

    Gruß Thomas

    • Als Antwort vorgeschlagen Alex Pitulice Freitag, 28. März 2014 13:37
    • Als Antwort markiert Alex Pitulice Dienstag, 1. April 2014 10:47
    Donnerstag, 27. März 2014 16:30

Alle Antworten

  • Hallo Robo,

    du schreibst, dass das Zertifikat gemäß o.g. Anleitung installiert wurde. Das Zertifikat in der Anleitung ist aber für den CAS Server gedacht, damit er ein SSL Zertifikat besitzt.

    Wurde das Zertifikat durch eine Zertifizierungsstelle ausgestellt? Wenn ja, bekommen deine Clients in der Domäne das CA Stammzertifikat sehr wahrscheinlich automatisch. Die außerhalb der Domäne natürlich nicht.

    Oder ist es ein selbst signiertes Zertifikat?

    Gruß Thomas


    Montag, 24. März 2014 18:31
  • Ich nutze in meiner Domäne die Dienste: Zertifizierungsstelle und Zertifizierungsstellen-Webregistrierung, also eine interne Zertifizierungsstelle. Das Zertifikat mit meinen spezifischen DNS-Einstellungen für den Zugriff über das Internet habe ich nach folgender Anleitung erstellt: http://www.msblog.eu/exchange-2013-serverzertifikat-erstellen/

    Das Zertifikat habe ich auf dem Client-Rechner unter vertrauenswürdigen Zertifizierungsstellen importiert.

    Vielleicht helfen noch folgende Ergänzungen: Ich habe die Betriebssysteme gerade vor zwei Tagen installiert (Server 2012 R2, Exchange 2013 [heute sogar SP1], auf Client-Rechner Windows 8.1 und Office 2013 - also eine frische Testumgebung ohne Abwärtskompatibilitäten).

    Wenn der Client-Rechner kein Domain-Mitglied ist, taucht der oben beschriebene Outlook-Fehler auf: "...Bevor Sie Ihre Ordner mit Ihrer Outlook-Datendatei (.ost) synchronisieren können..."

    Wenn der selbe Client-Rechner zum Mitglied der Domäne gemacht wird, startet Outlook fehlerfrei.

    Wenn zurück auf Arbeitsgruppen-Rechner umgestellt wird, ist der Fehler wieder da.

    Bei früheren Exchange-Versionen hat ein Postfach sofort funktioniert (auch wenn Outlook auf einem Nicht-Domainmitglied lief).

    Ein Freund von mir, der auch Mitglied im Partner Programm ist, hat gerade das gleiche Problem in seiner Testumgebung. Und wir sind beide in Moment völlig ratlos...

    Welche Angaben zu dem von mir erstellten Zertifikat soll ich noch machen? Ist hier überhaupt das Zertifikat die Ursache?

    Montag, 24. März 2014 20:17
  • Guten Morgen,

    führe mal auf dem Client outlook.exe /rpcdiag aus und poste die Ausgabe hier. Ebenso führe auf dem Exchange Server bitte Get-OutlookAnywhere | ft Server,Client*,IIS* -AutoSize aus.

    Gruß Thomas


    Dienstag, 25. März 2014 06:52
  • Ich nochmal,

    unter der Adresse https://testconnectivity.microsoft.com/?tabid=client kannst du einen Client Test Tool herunterladen um Konnektivitätsprobleme zu ermitteln. Im Tab Exchange kannst du das auch online durchführen lassen.

    Vieleicht hilft dir das auch schon weiter.

    Gruß Thomas

    Dienstag, 25. März 2014 06:57
  • Danke für die Unterstützung,
    hier poste ich die gewünschten Ausgaben:

    1. outlook.exe /rpcdiag  [Client-Rechner ist kein Domainmitglied]
    Screenshot outlook.exe /rpcdiag [Workgroup]

    2. outlook.exe /rpcdiag  [der selbe Client-Rechner als Domainmitglied]

    screenshot outlook.exe /rpcdiag Domainmitglied

    3. Get-OutlookAnywhere | ft Server,Client*,IIS* -AutoSize

    Server IISAuthenticationMethods
    ------ ------------------------
    SRV01  {Negotiate}

    Gruß

    Robert

    Dienstag, 25. März 2014 21:54
  • Hi Robert,

    dazu fällt mir folgendes ein. Negotiate sieht mir ziemlich stark nach kerberos Authentifizierung aus, was innerhalb der Domäne ohne Probleme funktionert. Von extern (Clients außerhalb der Domäne) nicht. Wenn ich richtig gelesen habe kann man auch Negotiate und NTLM einstellen, also beides. Mit NTLM kommen auch externe Clients klar. Kannst du das mal in deiner Testumgebung probieren?

    Set-OutlookAnywhere -id xy\rpc

    -ExternalClientAuthenticationMethod: NTLM

    -InternalClientAuthenticationMethod: Negotiate

    -IISAuthenticationMethods: {NTLM, Negotiate}

    Gruß Thomas

    Mittwoch, 26. März 2014 06:42
  • Hallo,

    ich habe das Problem gelöst:
    In meiner kompl. "jungfräulichen" neu-Installation habe ich in der Domäne RBN.local unter Exchange ein Benutzer-Postfach für Benutzer RB erstellt. Ich habe keine weiteren Konfigurationen vorgenommen und  wollte nur die Grundfunktionalität eines Postfachs im Intranet testen.

    Am Client-Rechner, der KEIN DomainMitglied ist, habe ich wie üblich ein Outlook-Profil erstellt; srv01.rbn.local und Benutzer rb@rbn.local wurden korrekt konfiguriert. Beim starten von Outlook kommt dann die bekannte Fehlermeldung: "...Bevor Sie Ihre Ordner mit Ihrer Outlook-Datendatei (.ost) synchronisieren...".

    Am Domaincontroller habe ich mir die Konfiguration von Outlook Anywhere angeschaut:

    Am Client-Rechner unter Outlook, bei Proxyeinstellungen, habe ich diese Adresse verwendet:

    Jetzt kam beim öffnen von Outlook die Meldung, dass das Zertifikat von einem nicht vertrauenswürdigen Herausgeber stamm. Wo bekommt man das Zertifikat her (am einfachsten)?

    Ich habe am DomainController über Systemsteuerung / Internetoptionen / Inhalte / Zertifikate in der Kartei Vertrauenswürdige Zertifizierungsstellen zwei Zertifikate mit dem Namen srv01 und WMSvc-SRV01 exportiert und anschliessend am Clientrechner in Vertrauenswürdige Stammzertifizierungsstellen importiert (zusätzlich noch in Vertrauenswürdige Herausgeber).

    Vielleicht weiss jemand von der Comunity folgendes: wenn ich bei OutlookAnywhere am Exchange den externen Zugriffspfad eintrage - ändert sich das Zertifikat automatisch?

    Liesse sich vielleicht der kompliziertere Vorgang über Zertifizierungsstelle so vereinfachen?

    Gruß

    Robert


    • Bearbeitet Robotron-X Donnerstag, 27. März 2014 16:34 kleine Fehler beseitigt
    Donnerstag, 27. März 2014 16:01
  • Noch eine Korrektur,

    den Proxy-Eintrag bei Outlook kann man nicht herausnehmen.

    Gruß

    Robert

    Donnerstag, 27. März 2014 16:20
  • Hallo Robert,

    ich habe parallel zu dir eine Teststellung aufgebaut und versucht das Problem nachzustellen. Allerdings erhielt ich nie deine Fehlermeldung in Outlook, selbst mit dem selbst signierten Zertifikat des Exchange nach der Installation klappte es trotz Meldungen.

    Wenn du eine Externe URL für Outlook Anywhere einträgst, gibt es mehrere Möglichkeiten der Zertifikate:

    1. (die einfachste) du besorgst dir ein SSL Zertifikat von einer offiziellen CA, denn dort ist das Root Zertifikat bzw. die Zertifikatskette bereits in Windows einhalten. Also Zertifikat beantragen, am Exchange einrichten und fertig. Kostet aber was ...
    2. Du baust dir eine CA im Active Directory, das Root Zertifikat wird innerhalb der Domäne automatisch verteilt, konfigurierst es wie in der Anleitung am Exchange und für die internen Clients ist alles fertig. Die Clients außerhalb der Domäne müssen aber auf welche Art auch immer das Stammzertifikat deiner CA bekommen. Export-Import oder Manuelle Installation kannst du dir aussuchen.
    3. Mit dem selbst signierten Zertifikat zu arbeiten würde ich dir auf jeden Fall abraten. Das macht nur Arbeit und Probleme

    Ich weiß, dass du bei StartSSL kostenlos Zertifikate bekommst, wo das Root Zert schon in Windows enthalten ist. Ich vielleicht nicht eine der sichersten CA's und das Level der Verifizierung ist auch das geringste aber kannst du ja mal ausprobieren.

    Die Outlook Proxy Einstellungen kommen übrigens aus dem Autodiscovery und kannst du normalerweise drin lassen. Funktionieren sollte es trotzdem.

    Gruß Thomas

    • Als Antwort vorgeschlagen Alex Pitulice Freitag, 28. März 2014 13:37
    • Als Antwort markiert Alex Pitulice Dienstag, 1. April 2014 10:47
    Donnerstag, 27. März 2014 16:30
  • Ich habe meine Testumgebung (Server 2012 R2, Exchange 2013) erneut kompl. neu installiert. Die Fehlermeldung

    "Ihre Standard E-Mail-Ordner können nicht geöffnet werden. Bevor Sie Ihre Ordner mit Ihrer Outlook-Datendatei (.ost) synchronisieren können, müssen Sie eine Verbindung mit Microsoft Exchange mit Ihrem aktuellen Profil herstellen."

    tritt immer dann auf, wenn Outlook (egal welche Version) auf einem Rechner läuft, der kein Domainmitglied ist, und keine Exchange-Proxyeinstellungen gemacht sind. (Es handelt sich um ein lokales Netzwerk).

    Wenn man in den Exchange-Proxyeinstellungen die lokale Domäne einträgt und Verbindung ohne SSL macht (http://mydomain.local), dann ist die Verbindung zu Exchange da.

    Wenn man in den Exchange-Proxyeinstellungen die lokale Domäne einträgt und Verbindung mit SSL macht (https://mydomain.local), dann kommt die Fehlermeldung über Zertifikat; und Outlook kann mit Exchange nicht verbinden.

    Ganz anders verhält sich Outlook, wenn der Client-Rechner ein Mitglied in der Domäne ist. In diesem Fall braucht Outlook keine Exchange-Proxyeinstellungen.

    Ist das jetzt prinzipiell so, dass Exchange-Proxyeinstellungen bei Nicht-Domain-Rechner erfordedrlich sind? Bei früheren Exchange Versionen musste kein Proxy verwendet werden.

    Sonntag, 6. April 2014 22:15
  • Ganz ehrlich, dir fehlt ein bischen das Basiswissen wie Exchange funktioniert.. Bei Exchange 2013 brauchst du (vor SP1) immer die Proxyeinstellungen. Wenn der Client in der Domäne ist bekommt er aber diese Einstellungen über den SCP im AD. Wenn der Client nicht in der Domäne ist, dann versucht er über autodiscover  im DNS diesen zu bekommen. Da du anscheind keinen Autodiscover Eintrag im DNS hast, mußt du die Einstellungen eben manuell eintragen. Zusätzlich: Zertifikate sind mittlerweile das A und O, ohne vernünftige Zertifkate läuft das alles nicht sauber. Also entweden ein kostenpflichtiges von einer anerkannten CA kaufen oder selbst innerhalb des ADs eine CA einrichten. Das Root und Intermediate Zertifikat mußt du dann aber irgendwie auf die Clients bekommen. Das Selfsigned Zertifikat vom Exchange auf die Clients in die Stammzertifizierungsstellen zu verteilen ist auch eher eine "schlechte" Lösung..

    Gruß

    Jörg

    Montag, 7. April 2014 08:24
  • Nachdem ich Outlook Anywhere und Virtuelle Verzeichnisse mit den entspr. internen und externen Domänen konfiguriert habe, den Zertifizierungsdienst und Webregistrierungdienst konfiguriert habe, ein Zertifikat erstellt habe, auf dem Client-Rechner das Zertifikat der Zertifizierungsstelle und das Exchange-Zertifikat installiert habe, die DNS konfiguriert habe - funktionieren nun die Verbindungen aus dem Intranet und Internet.

    Das was früher im Intranet (mit Exchange 2007/2010) bei Outlook sofort funktionierte: Benutzer eintragen, den Namen prüfen - Postfach öffnen und alles hat funktioniert (incl. öffentlichen Ordner)  ist jetzt bei Exchange 2013 komplizierter geworden.

    Ein Problem konnte ich in meinemr Testumgebunbg noch nicht lösen: Die öffentlichen Ordner werden beim Outlook nicht angezeigt, beim Zugriff über owa sind sie aber da.
    Ich habe die primäre SMTP-Adresse bereits auf die externe Domäne umgestellt
    Set-Mailbox -publicfolder “Mailbox-Name” -PrimarySMTPAddress mailboxname@extern.dyndns.org -EmailAddressPolicyEnabled $false

    funktioniert aber noch nicht.

    Was sollte ich noch prüfen / konfigurieren?

    Gruß

    Robert

    Montag, 7. April 2014 21:56
  • Schau mal ob der Artikel hilft.  http://support.microsoft.com/kb/2839517
    Dienstag, 8. April 2014 07:33
  • Den Hotfix hatte ich schon.

    Heute morgen, nachdem ich den rechner eingeschaltet habe, existiert keine Verbindung zu Exchange.

    Folgender Fehler taucht in der Exchange-Konsole auf:

    New-PSSession : [srv01.rbn.local] Beim Verbinden mit dem Remoteserver "srv01.rbn.local" ist folgender Fehler
    aufgetreten: [ClientAccessServer=SRV01,BackEndServer=srv01.rbn.local,RequestId=b0e51fd2-ca6a-4d41-8796-747ecb2f37bc,Tim
    eStamp=08.04.2014 12:35:48]  Weitere Informationen finden Sie im Hilfethema "about_Remote_Troubleshooting".
    In Zeile:1 Zeichen:1
    + New-PSSession -ConnectionURI "$connectionUri" -ConfigurationName Microsoft.Excha ...
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
       gTransportException
        + FullyQualifiedErrorId : -2144108477,PSSessionOpenFailed

    ich habe bei IIS die Bindungen überprüft - bei https ist das von mir erstellte Zertifikat eingestellt, was aber schon gestern so war, und alles hat funktioniert; es muss also eine andere Ursache haben.

    Da ich noch gestern  die ÖffentlichenOrdner unter Outlook nicht sehen konnte, habe ich als letzten Befehl folgendse gemacht (die SMTP-Adresse des Postfachs mit öffentlichen Ordnern von oe@srv01.rbn.local auf oe@myexternaldomain.dyndns.org geändert):

    Set-Mailbox -publicfolder “oe” -PrimarySMTPAddress oe@myexternaldomain.dyndns.org -EmailAddressPolicyEnabled $false

    Kann dies den o.g. Fehler verursacht haben.
    Wie kriege ich wieder die Verbindung zu Exchange. (Browserverbindung zu ecp funktioniert auch nicht)

    Gruß

    Robert

    Dienstag, 8. April 2014 13:57
  • Unter IIS Verwaltung im Zweig "Exchange Back End" bei der Bindung über https wurde das Zertifikat enfernt. D.h. dort stand gar kein Zertifikat. Nachdem ich dort das Zertifikat wieder aus der Auswahlliste selektiert habe geht alles wieder. Wie kann das sein, dass nach der Erstellung eines neuen Zertifikats dort plötzlich gar kein Zertifikat gebunden ist und das ganze System völlig lahm gelegt wird?....

    Nun zu meinem ursprünglichen Problem: die öffentlichen Ordner werden bei Outlook nicht angezeigt. Vielleicht hat jemand eine Idee was ich noch machen / prüfen kann?

    Robert

    Dienstag, 8. April 2014 21:59