Exchange 2007 - OWA Fehler 440 Logon timeout (nur bei Exchange auf DCs)

[gysinma1 13]

Hallo Zusammen

 

Ist vorgesehen, dass Exchange 2007 auf einem Domain controller installiert wird ist folgende Reihenfolge essentiell, da sonst Fehlfunktionen vorhanden sind:

 

1. Server aufsetzen

2. Domain controller "machen"

3. IIS installieren

4. Exchange 2007 Installation beginnen

 

Wird der IIS vor dem promoten zum DC installiert, kann u.U. der Fehler 440 Logon timout im OWA auftreten. Ursache: der IUSR_Servername muss bei dem promoting Vorgang von einem Lokalen Benutzer zu einem Globalen Domain user konvertiert werden. Gleichzeitig mit dem IWAM_Computername.

 

Es hilft folgender Workaround um OWA zum Laufen zu kriegen:

1. Mail ACcess Rule deinstallieren (den Rest aber lassen!)

2. IIS deinstallieren

3. IUSR_Servername und IWAM_Servername in der AD suchen und löschen

-

1. IIS installieren

2. ASPNET_Regiis -i in dem Microsoft.NET\Framework64\2.xxx aufrufen (repariert .NET2.0)

3. MailAccess Rule installieren

 

Zur Wiederholung: Grundsätzlich gibt es von MS keinen Support von Exchange 2007 auf Domaincontrollern (!). Is es dennoch vorgesehen, muss der promotingvorgang (nach Microsoft!) vor der Exchange installation gemacht werden.

 

Verliert der Server dannach seine Domaincontroller Funktion, muss zuerst Exchange 2007 komplett deinstalliert werden. Ein promoting/demoting Vorgang mit nem Exchange 2007 drauf funzt nit und wird keinenfalls empfohlen.

 

Gruss,

Matthias

[ziggyonline 10]

Ich hatte dieses Problem auch in meiner Testumgebung, daß OWA bzw. die public-Ornder nicht greifbar waren. (Timeout)

nach einem Howto (ich meine es bei MSXFAQ.DE - Franks MSExchangeFAQ) gelesen zu haben, beschreibst du genau den richtigen Weg, wieder zu einem funktionierenden Web-Access zu kommen !

[gysinma1 13]

Ich hatte dieses Problem auch in meiner Testumgebung, daß OWA bzw. die public-Ornder nicht greifbar waren. (Timeout)

nach einem Howto (ich meine es bei MSXFAQ.DE - Franks MSExchangeFAQ) gelesen zu haben, beschreibst du genau den richtigen Weg, wieder zu einem funktionierenden Web-Access zu kommen !

 

Danke :D - nur dass ich dort nicht geschaut habe ... aufdieeigeneAchselklopp:)

 

Gruss

Matthias

[beamer 10]

hi,

ich hab das beschriebene Problem mit allen Postfächern eines Servers von 3. Der OWA für Mailboxen der DefaultSite funktioniert, der OWA einer 2. Site funktioniert nicht (auch nicht lokal auf dem Host --440--). Meinst du mit "MailAccess Rule" die "Client Access Role"?

 

Gruß

[gysinma1 13]

hi,

ich hab das beschriebene Problem mit allen Postfächern eines Servers von 3. Der OWA für Mailboxen der DefaultSite funktioniert, der OWA einer 2. Site funktioniert nicht (auch nicht lokal auf dem Host --440--). Meinst du mit "MailAccess Rule" die "Client Access Role"?

 

Gruß

 

Hallo

 

Irgendwie komme ich nicht mit. Du hast drei Exchangeserver und auf dem 3.ten funktioniert OWA nicht ? Sind das alle DCs ? Wenn nein trifft mein Thread nicht zu und dann wäre es sinnvoll einen neuen zu eröffnen.

 

Mit MailAccessRule ist nicht die Client Access Role gemeint. Eines sind role-based functions in einer Mailboxorganisation und das andere ist das Quasi Webfrontend des Exchange.

 

Was meinst Du mit auf einer 2ten site ? IIS Site ? Der Exchange benötigt im Webserver eigene ApplicationThreaders. Ich habe (ausser Publikation im ISA) noch nie versucht, diese umzuleiten von Webserver zu webserver. Ich denk' dass ist auch nicht vorgesehen. Will man die CAS Server hochverfügbar machen, müssen diese NLB geclustered werden.

 

Aber vermutlich verstehe ich Deine Frage nicht wirklich :D

 

Gruss

Matthias

[beamer 10]

hallo,

alle Exchange Server sind DC+GC und DNS, alle haben das SP1 + Rollup1+2, Server 1+2 sind auf deutsch installiert und Server 3 auf englisch. Es sind 3 physische Standorte und später auch 3 AD Sites geplant, im Moment sind Server1+2 noch an einem Standort und Server3 steht seit kurzem (nach der Installation und Überprüfung aller Funktionen mit den anderen Servern) in einem anderem Standort und auch in einem anderen AD Site (anderes Subnetz). Für jede AD Site brauch ich ja zur MailboxRole auch einen CAS und einen HUB Transporter. Der OWA funktioniert für die Mailboxen der User auf Server1+2, die noch im selben Standort stehen. An diesen Standort wird auch der https Verkehr der öffentlichen Domain geleitet. Der Port 443 wird von der äußeren Firewall auf das Mailrelay geleitet und von diesem zum Server1. Server1 erkenn ja automatisch, auf welchem Server welche Mailbox liegt, und routet den Verkehr zu diesem (auf basis der AD Site Konfiguration). Wie geschrieben, es funktioniert alles bis auf der OWA des Server3 der seit kurzem in einem Anderen Standort steht. Ich finde es auch komisch, daß der OWA nicht mal lokal am Server3 funtioniert (https://localhost/owa), hier kommt eben der Fehler 440. Dies kann doch nur ein Fehler durch eine mangelhafte Authentifizierung sein, oder :confused:

Ich kann leider keine "MailAccessRule" finden, wo ist die denn in der Exchange Konsole zu sehen? (OrgConfig bzw. ServerConfig.....?)Die MailAccess Rule ist nicht zufällig auf dem ISA Server?

 

Guß

Rainer

–

–

nach der Deinstallation und anschließenden Neuinstallation des IIS, der CAS Role, und der beiden Benutzer (s.o.) sowie reparieren des .NET, funktioniert nun der OWA im LAN (AD Site übergreifend) mit https://<servername o. IP>.<interner domainname>/owa! Es funktioniert allerdings immer noch nicht die Weiterleitung, wenn ich über den externen Domainname komme (das kann doch nur ein authentifizierungsproblem der Server untereinender sein?)!:suspect:

 

mfg

–

ich bekomme beim Verbindungsversuch über die externe URL diese Meldung im Browser:

Outlook Web Access ist nicht verfügbar. Wenden Sie sich mit der folgenden Angabe an den technischen Support für Ihre Organisation, wenn das Problem weiterhin besteht: Es ist kein Microsoft Exchange-Clientzugriffsserver mit der erforderlichen Konfiguration am Active Directory-Standort, an dem dieses Postfach gespeichert wird, vorhanden.

 

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

[hannes3k 10]

Moin,

ich habe bei einem Kunden genau das selbe Problem gehabt.

Das Problem hängt mit der Anonymus Authentifizierung des IIS zusammen.

 

Das Problem ließ sich bei mir durch ersetzten und registrieren des Kennwortes für die standart Benutzer der Anonymus Authentifizierung (IUSR_<servername>,IWAM_<servername>) des IIS lösen.

 

Workaround:

1) Open AD Users & Computers. Expand the Users OU, right-click on the IUSR_<servername> account and select 'Reset password' Reset the password to anything you want (however, it can't be blank).

 

 

2) Open this User Account's properties and verify that the account is not locked out :^) Also, make sure that 'Password never expires' and 'User cannot change password' are selected.

 

3) Repeat steps 1 & 2 for the IWAM_<servername> account. Close AD Users & Computers.

 

 

4) Open Internet Information Services (Start | Administrative Tools)

 

5) Expand <servername> | Web Sites

 

6) Right-click on 'Default Web Site' and select Properties.

 

7) Go to the 'Directory Security' tab and click the Edit button under 'Authentication & Access Control'

 

8) Enter the new password for the IUSR_<servername> account and click OK.

 

9) Enter the password again to confirm and click OK.

 

10) Click OK.

 

11) Open a command prompt and enter iisreset

 

12) At the command prompt, enter the following commands:

cd c:\inetpub\adminscripts

adsutil SET w3svc/WAMUserPass <password> (Where <password> = the password you entered for the IWAM_<servername> account in AD Users & Computers)

c:\windows\system32\cscript.exe "c:\inetpub\adminscripts\synciwam.vbs" -v

iisreset

 

Technet: How to remove and to reinstall IIS on a computer that is running Exchange Server

 

Gruß Hannes