6
Exchange 2010 und Outlook Anywhere
Hallo Leute
Habe ein Problem mit dem einrichten von Outlook Anywhere
Also ich versuch Euch mal mein Problem mit Outlook Anywhere zu beschreiben…
Server1.domain.local DC auf Windows 2008R2
Server2.domain.local Exchange 2010 auf Windows 2008R2
Zertifikat vom goDaddy
OWA geht via https://owa.firma.tdl/owa
ActiveSync geht ebenfalls
Im Exchange habe ich Outlook Anywhere aktiviert und auch via Windows RPC installiert / aktiviert. Als URL habe ich bei Anywhere die gleiche Adresse via für das OWA angegeben (owa.firma.tdl) da das Zertifikat auf diesen Namen ausgestellt wurde. Die Clientauthentifizierungsmethode habe ich auf „NTLM“ eingestellt und „SSL-Verschiebung“ ist nicht aktiviert.
Auf dem Client (auf Outlook 2003 und Outlook 2007 getestet) habe ich folgendes im Setup des eMail-Konto eingegeben.
Servername server1.domain.local
Benutzername Hans Muster
In den erweiterten Einstellungen… Exchange-Verbindung mit http herstellen
URL https://owa.firma.tdl
„Nur SSL für Verbindung verwenden“ ist aktiviert
„Sitzung gegenseitig authentifizieren“ ist deaktiviert
Und bei der Authentifizierung ist auch wieder NTLM gewählt
Klicke ich nun auf überprüfen poppt ein Fenster für die Benutzereingaben auf.. in diesem Fenster geben ich die benötigten Angaben ein…
Benutzername domain.local\Hans Muster
Passwort sein normales Passwort
Nun dauert es ne Weile und dann erscheint folgender Fehler:
Die Anmeldung von Outlook ist fehlgeschlagen. Überprüfen Sie Ihre Netzwerkverbindung, sowie den Server- und Postfachnamen. Es steht keine Verbindung mit dem Microsoft Exchange Server zur Verfügung. Outlook muss im Onlinemodus oder verbunden sein, um diesen Vorgang auszuführen.
Auf dem Exchange-Server finde ich in den Event-Logs nichts…
Da alle anderen Dienste wie owa, eas usw. funktionieren verstehe ich gar nichts mehr.. weiss einer von Euch Rat?
Habe ein Problem mit dem einrichten von Outlook Anywhere
Also ich versuch Euch mal mein Problem mit Outlook Anywhere zu beschreiben…
Server1.domain.local DC auf Windows 2008R2
Server2.domain.local Exchange 2010 auf Windows 2008R2
Zertifikat vom goDaddy
OWA geht via https://owa.firma.tdl/owa
ActiveSync geht ebenfalls
Im Exchange habe ich Outlook Anywhere aktiviert und auch via Windows RPC installiert / aktiviert. Als URL habe ich bei Anywhere die gleiche Adresse via für das OWA angegeben (owa.firma.tdl) da das Zertifikat auf diesen Namen ausgestellt wurde. Die Clientauthentifizierungsmethode habe ich auf „NTLM“ eingestellt und „SSL-Verschiebung“ ist nicht aktiviert.
Auf dem Client (auf Outlook 2003 und Outlook 2007 getestet) habe ich folgendes im Setup des eMail-Konto eingegeben.
Servername server1.domain.local
Benutzername Hans Muster
In den erweiterten Einstellungen… Exchange-Verbindung mit http herstellen
URL https://owa.firma.tdl
„Nur SSL für Verbindung verwenden“ ist aktiviert
„Sitzung gegenseitig authentifizieren“ ist deaktiviert
Und bei der Authentifizierung ist auch wieder NTLM gewählt
Klicke ich nun auf überprüfen poppt ein Fenster für die Benutzereingaben auf.. in diesem Fenster geben ich die benötigten Angaben ein…
Benutzername domain.local\Hans Muster
Passwort sein normales Passwort
Nun dauert es ne Weile und dann erscheint folgender Fehler:
Die Anmeldung von Outlook ist fehlgeschlagen. Überprüfen Sie Ihre Netzwerkverbindung, sowie den Server- und Postfachnamen. Es steht keine Verbindung mit dem Microsoft Exchange Server zur Verfügung. Outlook muss im Onlinemodus oder verbunden sein, um diesen Vorgang auszuführen.
Auf dem Exchange-Server finde ich in den Event-Logs nichts…
Da alle anderen Dienste wie owa, eas usw. funktionieren verstehe ich gar nichts mehr.. weiss einer von Euch Rat?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 135882
Url: https://administrator.de/forum/exchange-2010-und-outlook-anywhere-135882.html
Ausgedruckt am: 24.12.2024 um 13:12 Uhr
6 Kommentare
Neuester Kommentar
so habe nun noch einen Test via https://www.testexchangeconnectivity.com/Default.aspx gemacht...
Scheint alles im Grünen Bereich zu sein, bis auf zwei Warnungen "Validating certificate trust" und "Testing NSPI Interface on Exchange Mailbox Server"
"Validating certificate trust"
Only able to build certificate chain when using the Root Certificate Update functionality from Windows Update. Your server may not be properly configured to send down the required intermediate certificates to complete the chain. Consult the certificate installation instructions or FAQ's from your Certificate Authority for more information.
verstehe nicht ganz was er hier will...
"Testing NSPI Interface on Exchange Mailbox Server"
NspiBind returned ecNotSupported. This typically indicates that your server requires RPC encryption. ExRCA will attempt the NSPI test again with encryption.
habe ich mittels "Get-MailboxServer Server2 | fl MapiEncryptionRequired" getestet und Encription ist nicht eingeschaltet...
Scheint alles im Grünen Bereich zu sein, bis auf zwei Warnungen "Validating certificate trust" und "Testing NSPI Interface on Exchange Mailbox Server"
"Validating certificate trust"
Only able to build certificate chain when using the Root Certificate Update functionality from Windows Update. Your server may not be properly configured to send down the required intermediate certificates to complete the chain. Consult the certificate installation instructions or FAQ's from your Certificate Authority for more information.
verstehe nicht ganz was er hier will...
"Testing NSPI Interface on Exchange Mailbox Server"
NspiBind returned ecNotSupported. This typically indicates that your server requires RPC encryption. ExRCA will attempt the NSPI test again with encryption.
habe ich mittels "Get-MailboxServer Server2 | fl MapiEncryptionRequired" getestet und Encription ist nicht eingeschaltet...
Testest du nur von extern, oder geht es auch vom internen Netz nicht? Hast du den RPC Proxy richtig konfiguriert? Wenn im Exchange Log nichts zu finden ist, vermute ich mal, das der RPC Proxy die Anfragen nicht weiterreicht
Hallo Uemmel
also ich teste Anywhere sowohl von intern wie auch extern. Von intern scheint alls zu funktionieren wie es sollte. Bin mal zumindest mit dem Server genau mit diesen Einstellungen wie ich Sie auch extern eingeben verbunden.
Die IIS-Log habe ich mal durchgesehen, wüsste aber nicht auf was ich speziell achten sollte... Habe RPC-Einträge im wie folgt drin:
2010-02-14 00:03:39 Server2IP RPC_IN_DATA /rpc/rpcproxy.dll Server2.Firma.local:6001 443 - GatewayIP MSRPC 401 1 2148074254 0
2010-02-14 00:03:39 Server2IP RPC_OUT_DATA /rpc/rpcproxy.dll Server2.Firma.local.local:6001 443 - GatewayIP MSRPC 401 1 2148074254 15
2010-02-14 00:07:43 Server2IP RPC_IN_DATA /rpc/rpcproxy.dll Server2.Firma.local:593 443 - ExterneClientIP MSRPC 401 1 2148074254 78
2010-02-14 00:07:43 Server2IP RPC_OUT_DATA /rpc/rpcproxy.dll Server2.Firma.local:593 443 - ExterneClientIP MSRPC 401 1 2148074254 31
2010-02-14 00:26:20 Server2IP RPC_IN_DATA /rpc/rpcproxy.dll Server2.Firma.local:6002 443 Server2.Firma.local\Hans+Muster ExterneClientIP MSRPC 401 1 1326 46
2010-02-14 00:26:20 Server2IP RPC_OUT_DATA /rpc/rpcproxy.dll Server2.Firma.local:6002 443 Server2.Firma.local\Hans+Muster ExterneClientIP MSRPC 401 1 64 31
also ich teste Anywhere sowohl von intern wie auch extern. Von intern scheint alls zu funktionieren wie es sollte. Bin mal zumindest mit dem Server genau mit diesen Einstellungen wie ich Sie auch extern eingeben verbunden.
Die IIS-Log habe ich mal durchgesehen, wüsste aber nicht auf was ich speziell achten sollte... Habe RPC-Einträge im wie folgt drin:
2010-02-14 00:03:39 Server2IP RPC_IN_DATA /rpc/rpcproxy.dll Server2.Firma.local:6001 443 - GatewayIP MSRPC 401 1 2148074254 0
2010-02-14 00:03:39 Server2IP RPC_OUT_DATA /rpc/rpcproxy.dll Server2.Firma.local.local:6001 443 - GatewayIP MSRPC 401 1 2148074254 15
2010-02-14 00:07:43 Server2IP RPC_IN_DATA /rpc/rpcproxy.dll Server2.Firma.local:593 443 - ExterneClientIP MSRPC 401 1 2148074254 78
2010-02-14 00:07:43 Server2IP RPC_OUT_DATA /rpc/rpcproxy.dll Server2.Firma.local:593 443 - ExterneClientIP MSRPC 401 1 2148074254 31
2010-02-14 00:26:20 Server2IP RPC_IN_DATA /rpc/rpcproxy.dll Server2.Firma.local:6002 443 Server2.Firma.local\Hans+Muster ExterneClientIP MSRPC 401 1 1326 46
2010-02-14 00:26:20 Server2IP RPC_OUT_DATA /rpc/rpcproxy.dll Server2.Firma.local:6002 443 Server2.Firma.local\Hans+Muster ExterneClientIP MSRPC 401 1 64 31
Habe noch ein wenig gespielt, immer noch ohne Erfolg aber noch ein paar Infos die evt. Helfen.
Versuche ich nun das Konto mit einem auf Server 2 unbekannten Benutzer einzurichten finde ich die entsprechenden Infos auch im EventLog des Server2
Fehler beim Anmelden eines Kontos.
Antragsteller:
Sicherheits-ID: NULL SID
Kontoname: -
Kontodomäne: -
Anmelde-ID: 0x0
Anmeldetyp: 3
Konto, für das die Anmeldung fehlgeschlagen ist:
Sicherheits-ID: NULL SID
Kontoname: max meister
Kontodomäne: server2.firma.local
Fehlerinformationen:
Fehlerursache: Unbekannter Benutzername oder ungültiges Kennwort.
Status: 0xc000006d
Unterstatus:: 0xc0000064
Prozessinformationen:
Aufrufprozess-ID: 0x0
Aufrufprozessname: -
Netzwerkinformationen:
Arbeitsstationsname: ExternerClient
Quellnetzwerkadresse: ExternereClientIP
Quellport: 39854
Detaillierte Authentifizierungsinformationen:
Anmeldeprozess: NtLmSsp
Authentifizierungspaket: NTLM
Übertragene Dienste: -
Paketname (nur NTLM): -
Schlüssellänge: 0
Dieses Ereignis wird beim Erstellen einer Anmeldesitzung generiert. Es wird auf dem Computer generiert, auf den zugegriffen wurde.
Die Antragstellerfelder geben das Konto auf dem lokalen System an, von dem die Anmeldung angefordert wurde. Dies ist meistens ein Dienst wie der Serverdienst oder ein lokaler Prozess wie "Winlogon.exe" oder "Services.exe".
Das Anmeldetypfeld gibt den jeweiligen Anmeldetyp an. Die häufigsten Typen sind 2 (interaktiv) und 3 (Netzwerk).
Die Felder für die Prozessinformationen geben den Prozess und das Konto an, für die die Anmeldung angefordert wurde.
Die Netzwerkfelder geben die Quelle einer Remoteanmeldeanforderung an. Der Arbeitsstationsname ist nicht immer verfügbar und kann in manchen Fällen leer bleiben.
Die Felder für die Authentifizierungsinformationen enthalten detaillierte Informationen zu dieser speziellen Anmeldeanforderung.
- Die übertragenen Dienste geben an, welche Zwischendienste an der Anmeldeanforderung beteiligt waren.
- Der Paketname gibt das in den NTLM-Protokollen verwendete Unterprotokoll an.
- Die Schlüssellänge gibt die Länge des generierten Sitzungsschlüssels an. Wenn kein Sitzungsschlüssel angefordert wurde, ist dieser Wert 0.
Nehme ich nun den Account welcher auf dem Server existiert, bekomme ich folgende Meldung
Ein Konto wurde erfolgreich angemeldet.
Antragsteller:
Sicherheits-ID: NULL SID
Kontoname: -
Kontodomäne: -
Anmelde-ID: 0x0
Anmeldetyp: 3
Neue Anmeldung:
Sicherheits-ID: Firma\Hans Muster
Kontoname: Hans Muster
Kontodomäne: Firma
Anmelde-ID: 0x1a9ea7
Anmelde-GUID: {00000000-0000-0000-0000-000000000000}
Prozessinformationen:
Prozess-ID: 0x0
Prozessname: -
Netzwerkinformationen:
Arbeitsstationsname: ExternerClient
Quellnetzwerkadresse: ExterneClientIP
Quellport: 0
Detaillierte Authentifizierungsinformationen:
Anmeldeprozess: NtLmSsp
Authentifizierungspaket: NTLM
Übertragene Dienste: -
Paketname (nur NTLM): NTLM V1
Schlüssellänge: 0
Dieses Ereignis wird beim Erstellen einer Anmeldesitzung generiert. Es wird auf dem Computer generiert, auf den zugegriffen wurde.
Die Antragstellerfelder geben das Konto auf dem lokalen System an, von dem die Anmeldung angefordert wurde. Dies ist meistens ein Dienst wie der Serverdienst oder ein lokaler Prozess wie "Winlogon.exe" oder "Services.exe".
Das Anmeldetypfeld gibt den jeweiligen Anmeldetyp an. Die häufigsten Typen sind 2 (interaktiv) und 3 (Netzwerk).
Die Felder für die neue Anmeldung geben das Konto an, für das die Anmeldung erstellt wurde, d. h. das angemeldete Konto.
Die Netzwerkfelder geben die Quelle einer Remoteanmeldeanforderung an. der Arbeitsstationsname ist nicht immer verfügbar und kann in manchen Fällen leer bleiben.
Die Felder für die Authentifizierungsinformationen enthalten detaillierte Informationen zu dieser speziellen Anmeldeanforderung.
- Die Anmelde-GUID ist ein eindeutiger Bezeichner, der verwendet werden kann, um dieses Ereignis mit einem KDC-Ereignis zu korrelieren.
- Die übertragenen Dienste geben an, welche Zwischendienste an der Anmeldeanforderung beteiligt waren.
- Der Paketname gibt das in den NTLM-Protokollen verwendete Unterprotokoll an.
- Die Schlüssellänge gibt die Länge des generierten Sitzungsschlüssels an. Wenn kein Sitzungsschlüssel angefordert wurde, ist dieser Wert 0.
Versuche ich nun das Konto mit einem auf Server 2 unbekannten Benutzer einzurichten finde ich die entsprechenden Infos auch im EventLog des Server2
Fehler beim Anmelden eines Kontos.
Antragsteller:
Sicherheits-ID: NULL SID
Kontoname: -
Kontodomäne: -
Anmelde-ID: 0x0
Anmeldetyp: 3
Konto, für das die Anmeldung fehlgeschlagen ist:
Sicherheits-ID: NULL SID
Kontoname: max meister
Kontodomäne: server2.firma.local
Fehlerinformationen:
Fehlerursache: Unbekannter Benutzername oder ungültiges Kennwort.
Status: 0xc000006d
Unterstatus:: 0xc0000064
Prozessinformationen:
Aufrufprozess-ID: 0x0
Aufrufprozessname: -
Netzwerkinformationen:
Arbeitsstationsname: ExternerClient
Quellnetzwerkadresse: ExternereClientIP
Quellport: 39854
Detaillierte Authentifizierungsinformationen:
Anmeldeprozess: NtLmSsp
Authentifizierungspaket: NTLM
Übertragene Dienste: -
Paketname (nur NTLM): -
Schlüssellänge: 0
Dieses Ereignis wird beim Erstellen einer Anmeldesitzung generiert. Es wird auf dem Computer generiert, auf den zugegriffen wurde.
Die Antragstellerfelder geben das Konto auf dem lokalen System an, von dem die Anmeldung angefordert wurde. Dies ist meistens ein Dienst wie der Serverdienst oder ein lokaler Prozess wie "Winlogon.exe" oder "Services.exe".
Das Anmeldetypfeld gibt den jeweiligen Anmeldetyp an. Die häufigsten Typen sind 2 (interaktiv) und 3 (Netzwerk).
Die Felder für die Prozessinformationen geben den Prozess und das Konto an, für die die Anmeldung angefordert wurde.
Die Netzwerkfelder geben die Quelle einer Remoteanmeldeanforderung an. Der Arbeitsstationsname ist nicht immer verfügbar und kann in manchen Fällen leer bleiben.
Die Felder für die Authentifizierungsinformationen enthalten detaillierte Informationen zu dieser speziellen Anmeldeanforderung.
- Die übertragenen Dienste geben an, welche Zwischendienste an der Anmeldeanforderung beteiligt waren.
- Der Paketname gibt das in den NTLM-Protokollen verwendete Unterprotokoll an.
- Die Schlüssellänge gibt die Länge des generierten Sitzungsschlüssels an. Wenn kein Sitzungsschlüssel angefordert wurde, ist dieser Wert 0.
Nehme ich nun den Account welcher auf dem Server existiert, bekomme ich folgende Meldung
Ein Konto wurde erfolgreich angemeldet.
Antragsteller:
Sicherheits-ID: NULL SID
Kontoname: -
Kontodomäne: -
Anmelde-ID: 0x0
Anmeldetyp: 3
Neue Anmeldung:
Sicherheits-ID: Firma\Hans Muster
Kontoname: Hans Muster
Kontodomäne: Firma
Anmelde-ID: 0x1a9ea7
Anmelde-GUID: {00000000-0000-0000-0000-000000000000}
Prozessinformationen:
Prozess-ID: 0x0
Prozessname: -
Netzwerkinformationen:
Arbeitsstationsname: ExternerClient
Quellnetzwerkadresse: ExterneClientIP
Quellport: 0
Detaillierte Authentifizierungsinformationen:
Anmeldeprozess: NtLmSsp
Authentifizierungspaket: NTLM
Übertragene Dienste: -
Paketname (nur NTLM): NTLM V1
Schlüssellänge: 0
Dieses Ereignis wird beim Erstellen einer Anmeldesitzung generiert. Es wird auf dem Computer generiert, auf den zugegriffen wurde.
Die Antragstellerfelder geben das Konto auf dem lokalen System an, von dem die Anmeldung angefordert wurde. Dies ist meistens ein Dienst wie der Serverdienst oder ein lokaler Prozess wie "Winlogon.exe" oder "Services.exe".
Das Anmeldetypfeld gibt den jeweiligen Anmeldetyp an. Die häufigsten Typen sind 2 (interaktiv) und 3 (Netzwerk).
Die Felder für die neue Anmeldung geben das Konto an, für das die Anmeldung erstellt wurde, d. h. das angemeldete Konto.
Die Netzwerkfelder geben die Quelle einer Remoteanmeldeanforderung an. der Arbeitsstationsname ist nicht immer verfügbar und kann in manchen Fällen leer bleiben.
Die Felder für die Authentifizierungsinformationen enthalten detaillierte Informationen zu dieser speziellen Anmeldeanforderung.
- Die Anmelde-GUID ist ein eindeutiger Bezeichner, der verwendet werden kann, um dieses Ereignis mit einem KDC-Ereignis zu korrelieren.
- Die übertragenen Dienste geben an, welche Zwischendienste an der Anmeldeanforderung beteiligt waren.
- Der Paketname gibt das in den NTLM-Protokollen verwendete Unterprotokoll an.
- Die Schlüssellänge gibt die Länge des generierten Sitzungsschlüssels an. Wenn kein Sitzungsschlüssel angefordert wurde, ist dieser Wert 0.
gerade eben ist mir eine Zertifikat-Fehler-Meldung Aufgefallen, wenn ich auf einem Internen-Client wo eigentlich alles funktioniert das Outlook starte.
Der Fehler kommt nach dem Starten von Outlook nach ein paar Minuten
Zertifikats Sicherheitswarnung
autodiscover.firma.tdl
Fehler:
Der Name auf dem Sicherheitszertifikat ist ungültig oder Stimmt nicht mit dem Namen der Webseite überein.
Dies kommt nehme ich mal an daher, dass das Zertifikat auf owa.firma.tdl lautet.
spielt dies für mein externer Client eine Rolle? Ich konfiguriere diesen ja von Hand und lasse so nehme ich mal an Autodiscover dadurch aus.
Der Fehler kommt nach dem Starten von Outlook nach ein paar Minuten
Zertifikats Sicherheitswarnung
autodiscover.firma.tdl
Fehler:
Der Name auf dem Sicherheitszertifikat ist ungültig oder Stimmt nicht mit dem Namen der Webseite überein.
Dies kommt nehme ich mal an daher, dass das Zertifikat auf owa.firma.tdl lautet.
spielt dies für mein externer Client eine Rolle? Ich konfiguriere diesen ja von Hand und lasse so nehme ich mal an Autodiscover dadurch aus.
Da es von intern ja geht, sollte das nicht der Grund sein. Wenn das Zertifikat nicht gültig ist, sollte ein Warnhinweis kommen und danach funktionieren.
Was steht denn im Log, wenn du dich versuchst mit dem Benutzer anzumelden und absichtlich ein falsches Passwort eingibst. Findest du im Log dann ebenfalls die Einträge.
Nutzt du eine Firewall?
Was steht denn im Log, wenn du dich versuchst mit dem Benutzer anzumelden und absichtlich ein falsches Passwort eingibst. Findest du im Log dann ebenfalls die Einträge.
Nutzt du eine Firewall?
