Server 2008 EE R2 mit Exchange 2010 - OWA defekt seit Service Pack 1 installation

[Snowman_24 11]

Hallo liebe Forumsgemeinde,

 

jetzt bin ich mit meinem Latein leider total am Ende. :confused:

 

Könnt Ihr mir vielleicht weiterhelfen?

 

Das ist passiert:

 

Am vergangenen Montag habe ich auf meinem Server (Windows Server 2008 EE R2 mit installiertem Exchange 2010) das Service Pack 1 für Server 2008 installiert.

Es dauerte fast 2 Stunden, bis die Installation abgeschlossen war.

 

Auf den ersten Blick, lief alles wieder wunderbar - keine Fehlermeldungen im Log und die Arbeitsplätze konnten sich auch wieder anmelden und Mails (Win7 und Outlook 2010) empfangen und versenden.

 

Doch dann wollte ich mich von extern auf die OWA-Seite einloggen.

Hierzu habe ich einen Link (http://mail.******.de) auf meine feste IP (https://***.**.**.**/exchange).

 

Und dann kam schon eine Fehlermeldung:

 

Serverfehler in der Anwendung /.

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

 

Laufzeitfehler

Beschreibung: Anwendungsfehler auf dem Server. Aufgrund der aktuellen benutzerdefinierten Fehlereinstellungen für diese Anwendung können die Details des Anwendungsfehlers nicht angezeigt werden.

 

Details: Sie können die Details dieser Fehlermeldung auf dem lokalen Computer anzeigen, indem Sie ein <customErrors>-Tag in der Konfigurationsdatei web.config erstellen, die sich im Stammverzeichnis der aktuellen Webanwendung befindet. Das mode-Attribut dieses <customErrors>-Tags sollte auf RemoteOnly festgelegt werden. Sie können die Details auf Remotecomputern anzeigen, indem Sie "mode" auf "Off" festlegen.

 

 

<!-- Web.Config Configuration File -->

 

<configuration>

<system.web>

<customErrors mode="RemoteOnly"/>

</system.web>

</configuration>

 

 

Hinweise: Die aktuelle Seite kann durch eine benutzerdefinierte Fehlerseite ersetzt werden, indem Sie das defaultRedirect-Attribut des <customErrors>-Konfigurationstags dieser Anwendung so setzen, das es auf einen benutzerdefinierten Fehlerseiten-URL zeigt.

 

 

<!-- Web.Config Configuration File -->

 

<configuration>

<system.web>

<customErrors mode="On" defaultRedirect="mycustompage.htm"/>

</system.web>

</configuration>

 

Ich habe dann im Ereignisprotokoll auf dem Server folgende Fehlermeldung erhalten:

[Snowman_24 11]

Ereigniscode: 3008

Ereignismeldung: Es ist ein Konfigurationsfehler aufgetreten.

Ereigniszeit: 12.03.2011 12:21:15

Ereigniszeit (UTC): 12.03.2011 11:21:15

Ereignis-ID: 6ae5a66fc3094030b2456c41a0d81a53

Ereignissequenz: 19

Vorkommen: 11

Ereignisdetailcode: 0

 

Anwendungsinformationen:

Anwendungsdomäne: /LM/W3SVC/1/ROOT-5-129443653046483037

Vertrauensebene: Full

Virtueller Anwendungspfad: /

Anwendungspfad: C:\inetpub\wwwroot\

Computername: SERVER-STURM

 

Prozessinformationen:

Prozess-ID: 18668

Prozessname: w3wp.exe

Kontoname: IIS APPPOOL\DefaultAppPool

 

Ausnahmeinformationen:

Ausnahmetyp: ConfigurationErrorsException

Ausnahmemeldung: Einen Abschnitt, der als allowDefinition='MachineToApplication' registriert ist, über die Programmebene hinaus zu verwenden verursacht einen Fehler. Dieser Fehler kann von einem virtuellen Verzeichnis verursacht werden, das nicht als Anwendung in IIS konfiguriert ist. (C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\owa\web.config line 37)

bei System.Configuration.ConfigurationSchemaErrors.ThrowIfErrors(Boolean ignoreLocal)

bei System.Configuration.BaseConfigurationRecord.GetSectionRecursive(String configKey, Boolean getLkg, Boolean checkPermission, Boolean getRuntimeObject, Boolean requestIsHere, Object& result, Object& resultRuntimeObject)

bei System.Configuration.BaseConfigurationRecord.GetSection(String configKey)

bei System.Web.Configuration.RuntimeConfig.GetSectionObject(String sectionName)

bei System.Web.Configuration.RuntimeConfig.GetSection(String sectionName, Type type, ResultsIndex index)

bei System.Web.Configuration.RuntimeConfig.get_Identity()

bei System.Web.HttpContext.SetImpersonationEnabled()

bei System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context)

 

 

 

Anforderungsinformationen:

Anforderungs-URL: https://server-sturm.sturmnet.local:443/exchange

Anforderungspfad: /exchange

Benutzerhostadresse: 10.30.0.10

Benutzer:

Ist authentifiziert: False

Authentifizierungstyp:

Threadkontoname: IIS APPPOOL\DefaultAppPool

 

Threadinformationen:

Thread-ID: 521

Threadkontoname: IIS APPPOOL\DefaultAppPool

Identitätswechsel für: False

Stapelüberwachung: bei System.Configuration.ConfigurationSchemaErrors.ThrowIfErrors(Boolean ignoreLocal)

bei System.Configuration.BaseConfigurationRecord.GetSectionRecursive(String configKey, Boolean getLkg, Boolean checkPermission, Boolean getRuntimeObject, Boolean requestIsHere, Object& result, Object& resultRuntimeObject)

bei System.Configuration.BaseConfigurationRecord.GetSection(String configKey)

bei System.Web.Configuration.RuntimeConfig.GetSectionObject(String sectionName)

bei System.Web.Configuration.RuntimeConfig.GetSection(String sectionName, Type type, ResultsIndex index)

bei System.Web.Configuration.RuntimeConfig.get_Identity()

bei System.Web.HttpContext.SetImpersonationEnabled()

bei System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context)

Details des benutzerdefinierten Ereignisses:

 

Nach langem suchen in diversen Foren konnte ich dann eine Abhilfe finden:

 

(siehe hier: Nach Service Pack 1 auf Server 2008 R2 geht OWA des Exchange 2010 nicht mehr - Windows Server - administrator)

 

Problemlösung:

Microsoft .NET Framework (64) 4.0 aktiviert:

aspnet_regiis.exe -i enable

[Snowman_24 11]

Nach langem suchen in diversen Foren konnte ich dann eine Abhilfe finden:

 

(siehe hier: Nach Service Pack 1 auf Server 2008 R2 geht OWA des Exchange 2010 nicht mehr - Windows Server - administrator)

 

Problemlösung:

Microsoft .NET Framework (64) 4.0 aktiviert:

aspnet_regiis.exe -i enable

 

 

Leider hat das aber bei mir nicht so wirklich funktioniert.

 

Wenn ich an die interne URL hinten statt "exchange" jetzt "owa" eingebe, funktioniert OWA 2010 wieder, aber wenn ich exchange dransetze, kommt wieder die Meldung von oben und auch der Eintrag im Ereignisprotokoll.

 

Ich habe jetzt im IIS lange gesucht und bin, glaub ich zumindest, fündig geworden:

 

Im IIS unter "Default Web Site" habe ich die Verzeichnisse z.B. Exchange, Exchweb, OWA und natürlich noch viele mehr.

 

Die Verzeichnisse Exchange und Exchweb sind ja eigentlich "nur" weiterleitungen, welche dann auf das Verzeichnis OWA zugreifen.

 

Irgendwie scheinen aber die "weiterleitungen" nicht mehr zu funktionieren.

 

Ich habe irgendwie die Vermutung, dass es etwas mit der ApplicationPoolIdentity bzw. der Pass-Through-Authentifizierung zu tun hat - zumindest das dort mit dem Service Pack 1 irgendetwas beschädigt wurde.

 

Könnt Ihr mir helfen???

 

DANKE im Voraus

[freidenka 10]

Nabend,

 

ich weiß nicht ob ich da richtig liege, aber überprüfe mal den physikalischen Pfad, damit gibst du den Ressourcenplatz an, welcher die Oberfläche bereithält.

 

 

Grüße,

Jan

[GuentherH 61]

Hallo.

 

Wenn ich an die interne URL hinten statt "exchange" jetzt "owa" eingebe, funktioniert OWA 2010 wieder

 

Das ist ja auch der Standardaufruf seit Exchange 2007. Wurde da bei euch etwas geändert?

 

LG Günther

[NorbertFe 1.836]

Richtig, und da /exchange auch keine Proxyfunktion mehr bietet in Exchange 2010, sondern redirect, kann das meiner Meinung nach auch vor dem SP1 nicht funktioniert haben. ;)

Siehe auch hier:

MSXFAQ.DE - CASProxy 2010

 

Bye

Norbert

[Snowman_24 11]

Hallo,

 

danke erst mal, für Eure Antworten.

 

@ Jan:

 

Der Pfad von "Exchange" und "Exchweb" stimmt eindeutig mit dem des "OWA" überein.

 

Was mir aber auffällt, in den Pfad-Einstellungen (Grundeinstellung) gibt es eine Möglichkeit, diesen zu testen (Einstellungen testen).

 

Bei "Exchange" und "Echweb" bekomme ich die beiden Meldungen:

 

- OK : Authentifizierung : Pass-Through-Authentifizierung (DefaultAppPool:ApplicationPoolIdentity)

--> Details: Die Identität des Anwendungspools ist gültig.

 

- "gelbes Ausrufezeichen" : Der Zugriff auf den Pfad (C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\owa) kann nicht überprüft werden.

--> Details: Der Server ist so konfiguriert, dass zum Zugriff auf den angegebenen physikalischen Pfad die Pass-Through-Authentifizierung mit einem vordefinierten Konto verwendet wird. IIS-Manager kann jedoch nicht überprüfen, ob das vordefinierte Konto Zugriff hat. Stellen Sie sicher, dass die Identität des Anwendungspools Lesezugriff auf den physikalischen Pfad hat. Wenn der Server mit einer Domäne verbunden ist und die Identität des Anwendungspools "NetworkService" oder "LocalSystem" ist, stellen Sie sicher, dass <domäne>\<computername>$ Lesezugriff auf den physikalischen Pfad hat. Testen Sie diese Einstellungen dann erneut.

 

Und jetzt kommts:

 

Möchte ich die "Einstellungen testen..." unter OWA (was ja funktioniert), bekomme ich die Meldung:

 

Fehler beim Ausführen des Vorgangs.

Details:

Ungültiger Anwendungspfad

 

Im weiteren Fenster "Ergebniss" bleibt alles leer.

 

Der Pfad unter OWA ist aber korrekt.

 

Ändere ich in den Pfad-Einstellungen den Zugriff unter "Verbinden als..."

von Pass-Through-Authentifizierung auf z.B. Administrator, dann funktioniert auch der Test.

 

Daher denke ich, der Fehler liegt hier irgendwo in der Pass-Through-Authentifizierung.

 

Ich habe die Angaben gestern mit den Angaben eines gleichen Servers eines Kunden verglichen, bei dem das SP1 noch nicht installiert wurde.

Dort stimmt alles mit den Einstellungen auf meinen Server überein, aber die Einstellungen konnte ich dort auch mit der Pass-Through-Authentifizierung testen.

 

Hier mal die Adressen, wo Ihr das selbst sehen könnt:

 

https://217.91.67.80/exchange = Laufzeitfehler

https://217.91.67.80/exchweb = Laufzeitfehler

https://217.91.67.80/owa = ok, allerdings stimmt hier natürlich das Zertifikat nicht.

 

Der korrekte Link lautet:

 

https://owa.sec-sturm.de/exchange = Laufzeitfehler

https://owa.sec-sturm.de/exchweb = Laufzeitfehler

https://owa.sec-sturm.de/owa = ok

 

@ Günther:

 

nein, ausser das Service-Pack einspielen, habe ich nichts verändert.

 

Grüße

Marcus

[dmetzger 10]

Wie GuentherH und NorbertFe bereits erwähnt haben, lautet die Standard-URL für Exchange 2010 Outlook Web App https:/<URL>/owa. Das funktioniert anscheindend einwandfrei. Wo also ist das Problem?

[Snowman_24 11]

Hallo,

 

naja, es funktionierte eben bis zum Update und jetzt nicht mehr.

Mit OWA funktioniert es, ja, aber mich würde trotzdem interessieren, warum die Umleitung nicht mehr klappt.

 

Grüße und Danke

Marcus

[Snowman_24 11]

Hallo zusammen,

 

leider geht es jetzt doch mit einem Fehler weiter.

Wenn ich in OWA eine Mail z.B. im Posteingang löschen möchte,

ist die Mail auch kurz gelöscht, wird aber innerhalb weniger Augenblicke wieder angezeigt

und es erscheint eine Fehlermeldung:

 

"Die Aktion konnte aufgrund eines Konfigurationsproblems auf dem Server nicht ausgeführt werden. Wenn das Problem weiterhin auftritt, wenden Sie sich an den Helpdesk."

 

Könnt Ihr damit etwas anfangen?

 

Danke und Grüße

Marcus

[RobertWi 81]

Moin,

 

ich würde die Verzeichnisse mal über die EMC reparieren.

 

/exchange ist eigentlich nur ein simpler HTTP-Redirect, wie Norbert schon schreibt - konfiguriert zu 100% im IIS.

[Snowman_24 11]

Hallo RobertWi,

 

ich habe das jetzt mal versucht.

Die Verzeichnisse OWA und ECP habe ich mit Hilfe der EMC zurückgesetzt.

Leider gleiches Problem... :(

 

Grüße

Marcus

[RobertWi 81]

Aber das Problem ist doch im EXCHANGE-Verzeichnis, oder?

[Snowman_24 11]

Hallo,

 

wo das Problem genau liegt, weiß ich eben nicht.

Bin langsam am verzweifeln.

 

Ich möchte den Exchange-Server nicht neu aufsetzen.

Das schaffe ich zur Zeit zeitlich nicht.

 

Die redirects: Exchange und Exchweb lasse ich jetzt mal so.

Aber dass ich in OWA nichts löschen kann - das muss wieder funktionieren.

 

Grüße

Marcus

[RobertWi 81]

Moin,

 

na ja, dann bleibt halt nur ein kostenpflichtiger Call bei MSFT oder ein externer Dienstleister. Aber Deine Arbeitszeit kostet ja auch Geld und wenn Du Dich in der gesparten Zeit um wichtigere Dinge kümmern kannst, sollte es das der Firma wert sein.