Beiträge von Flo

Ok, ich glaub langsam hab ich´s.
Ich hab jetzt mal im Access log vom IIS geschaut und finde folgende Zeile:

2010-02-18 13:16:25 192.168.0.254 RPC_IN_DATA /rpc/rpcproxy.dll exchange.domain.local:6001 443 - 192.168.0.253 MSRPC 404 13 0 19

Zu dem 404 finde ich dann:
Dieses Problem tritt auf, wenn die RPC-Proxy-Servererweiterungen nicht ordnungsgemäß geladen werden.

Das habe ich ja auch schon vermutet, nur alles was ich dazu finde bezieht sich auf ältere IIS und der IIS7 ist halt leider schon ziemlich anders.
Also wie stelle ich sicher, dass die "Servererweiterung" richtig geladen ist im IIS7?

Ein bisschen googeln hat mich immer wieder auf eine 32/64 Bit Problematik aufmerksam gemacht und eine Zeile in der "applicationHost.config"
Nämlich diese:

<add name="PasswordExpiryModule" image="C:\Windows\system32\RpcProxy\RpcProxy.dll" />

Ich hatte diese Zeile überhaupt nicht, hab sie jetzt halt mal eingetragen und in das RPC Virtual Direcotry unter Module geladen. Allerdings bekomm ich immer noch den 404 Error.

Da deinstallieren und installieren vom RPC over HTTP ja anscheinend nichts bringt meine Frage jetzt. Was muss ich alles machen, damit dieses blöde Modul richtig geladen ist im IIS7?

Grüße
Florian

Neuer Fehler mittlerweile, wenn ich den Ping laufen lasse kommt folgendes:

Exception 1818 (0x0000071A)
Number of records is: 1
ProcessID is 6012
System Time is: 2/18/2010 11:1:42:242
Generating component is 14
Status is 1818
Detection location is 1390
Flags is 0
NumberOfParameters is 1
Long val: 900000

Erfolgreich läuft dafüer aber z.B. ein:
Test-OutlookConnectivity -RpcProxyServer:extern.dyndns.org -RpcProxyAuthenticationType:Basic -ClientAccessServer:exchange.domain.local -RpcAuthenticationType:NTLM -MailboxCredential:(get-credential domain\user) -Identity user@domain.local:

ClientAccessServer Mailbox Database Scenario Result Latency Error
(MS)
------------------ ------- -------- -------- ------ ------- -----
exchange.domain.local user@do... Mailbox Da... AutoErmittlung: Webdiensanf... Erfo... 62.00
exchange.domain.local user@do... Mailbox Da... RFRI::GetReferral. Erfo... 23.00
exchange.domain.local user@do... Mailbox Da... NSPI::GetProfileDetails. Erfo... 23.00
exchange.domain.local user@do... Mailbox Da... Mailbox::Connect. Erfo... 20.00
exchange.domain.local user@do... Mailbox Da... Mailbox::Logon. Erfo... 16.00

Half auch nichts, aber ich bin wieder mal einen Schritt weiter.

Durch ein "Test-OutlookWebServices" ist mir aufgefallen, dass mein DNS die dyndns Adresse nicht mehr auflösen konnte, war durch ne Spielerrei im DNS. Habe ich behoben und "Test-OutlookWebServices" läuft wieder komplett erfolgreich durch.

Dadurch ist jetzt auch die Ausnahme 1722 (0x000006BA) beim rpcping verschwunden. Allerdings gibt mir rpcping jetzt einfach garnichts mehr zurück.
Läuft jetzt schon 5 Minuten ohne irgend ein Output.

deaktiviert und aktiviert schon ettliche Male, allerdings nie die halbe Stunde gewartet.
Ich versuchs mal

kleine Ergänzung, es stimmt wohl wirklich irgendwas mit dem rpc nicht. Quasi alle rpcping Versuche landen in einer 1722 Ausnahme:

C:\>rpcping -t ncacn_http -s exchange.domain.local -o rpcProxy=extern.dyndns.org -P "*,*,*" -H 1 -F 3 -a connect -u 10 -v 4 -e 6002

RPCPing, Version 6.0. Copyright (C) Microsoft Corporation, 2002-2006
Geben Sie das Kennwort für RPC/HTTP proxy ein:

Ausnahme 1722 (0x000006BA)
Die Anzahl der Datensätze ist: 2
Die Prozess-ID ist 1952.
Die Systemzeit ist: 2/17/2010 15:41:23:598.
Die generierende Komponente ist 13.
Der Status ist 0x6BA, 1722.
Der Ort der Ermittlung ist 1352.
Die Flags sind 0.
"NumberOfParameters" ist 1.
Long-Wert: 0xc002100a
Die Prozess-ID ist 1952.
Die Systemzeit ist: 2/17/2010 15:41:23:598.
Die generierende Komponente ist 14.
Der Status ist 0xC002100A, -1073606646.
Der Ort der Ermittlung ist 1380.
Die Flags sind 0.
"NumberOfParameters" ist 2.
Long-Wert: 0x2ee7
Unicode-Zeichenfolge: /rpc/rpcproxy.dll?exchange.domain.local:6002

hab meinen exchange und domänen Namen geändert für´s Forum

Hi,

ich verzweifel hier seit 3 Tagen und komm einfach nicht weiter.
Ich habe mir letzte Woche mit ner Applikation meine IIS Config zerschossen und bekomme seit dem mein Outlook Anywhere nicht mehr ans rennen.

Vielleicht kurze Info zu meiner Umgebung.

Kleines Firmennetzwerk, alles auf einer Mühle. Server 2008, Exchange 2010 (letze Woche erst geswicht von 2003/2007). Hängt an nem Router und der an ner Telekom Leitung.
Mails von draußen kommen per Popcon rein, gesendet wird über nen Sendeconnector. Für die externe IP habe ich ne dyndns Adresse. Zertifikat ist erstellt und mit der eigenen Zertifizierungsstelle ausgestellt.
Clients in der Domäne können wunderbar Mailen, in alle Richtungen. OWA von extern funktioniert einwandfrei nachdem ich die Zertifikate installiert hatte. Ich bekomme keine Fehlermeldung, oder Warnung wenn ich auf die https:// Adresse zugreife.

Ebenso Problemlos funktioniert Active Sync mit den Handys.

Was aber absolut nicht mehr gehen will ist Outlook Anywhere.
Habe die Client Access Rolle schon komplett neu installiert, RPC-over-HTTP neu installiert, will alles nicht helfen. Ich finde auch keine Fehlermeldung. Wenn ich versuche mit Outlook zu connecten hängt es einfach und sagt dann dass der Exchange nicht zur Verfügung steht. Wenn ich im Verbindungsstatus schaue steht da: HTTPS – wird hergestellt, aber er macht einfach nichts.

Ich kann das Ganze auch lokal im Netz nachstellen, wenn ich mich mit nem Rechner lokal anmelde und nicht den Domain Controller als DNS angebe, sondern den Router funktioniert es intern auch nicht mehr. Ist der DC als DNS eingetragen, oder ich hau den Servernamen in die hosts funktioniert es, aber er zeigt mir im Verbindungsstatus TCP/IP als Verbindung.

Ein RPC-over-HTTP Test über http://www.testexchangeconnectivity.com ist erfolgreich bis auf „Certificate chain could not be built. You may be missing required intermediate certificates.”
Was ich aber als normal sehe, da der Server der dort testet nicht mein Zertifikat von meiner Zertifizierungsstelle hat.

Bin so langsam wirklich mit meinem Latein am Ende, einer noch ne Idee wie ich den Fehler weiter eingrenzen kann?

Grüße
Florian