berlinger
Goto Top

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?

Content-Key: 135882

Url: https://administrator.de/contentid/135882

Ausgedruckt am: 29.03.2024 um 01:03 Uhr

Mitglied: berlinger
berlinger 14.02.2010 um 02:33:13 Uhr
Goto Top
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...
Mitglied: 16409
16409 14.02.2010 um 12:17:36 Uhr
Goto Top
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
Mitglied: berlinger
berlinger 14.02.2010 um 13:20:14 Uhr
Goto Top
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
Mitglied: berlinger
berlinger 14.02.2010 um 16:23:48 Uhr
Goto Top
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.
Mitglied: berlinger
berlinger 14.02.2010 um 18:58:49 Uhr
Goto Top
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.
Mitglied: 16409
16409 16.02.2010 um 12:14:46 Uhr
Goto Top
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?