2k3 - und OWA

[icon 10]

Servus miteinander,

 

ich bin gerade ein wenig ratlos, eventuell hat einer von euch eine Idee.

 

Hintergrund:

Umzug eines Domänencontrollers sowie Exchange Server auf ein neues System wurde vor 2 Wochen durchgeführt.

FSMO Rollen und Exchange wurden sauber umgezogen. Beides liegt auf dem selben System.

Den alten Server konnte ich sauber deinstallieren und auch die DC Funktion wurde ordnungsgemäß entfernt. Danach ging der alte Server offline.

Das AD läuft wunderbar.

Keine Fehlereinträge im Eventlog. Service Packs und Patches sind aktuell.

 

Was ich tun wollte: Eigentlich ganz simple Outlook WebAccess.

Formularbasierte Auth. eingeschalten, Komprimierung hoch.

SSL im IIS mit selfssl eingerichtet.

Domäne in der Authentifizierung eingetragen und SSL erzwingen. Basta.

 

Hab das bestimmt schon 1000 mal gemacht und es hat immer problemlos funktioniert.

 

Das Problem:

Wenn ich https://servername/exchange aufrufe, bekomme ich die Warnung wegen dem Zertifikat. Logisch, weils ja kein öffentliches ist.

Also gehts mit "Laden der Website fortsetzen" weiter.

Jetzt sollte eigentlich die Login Seite kommen, tut Sie aber nicht. Es kommt auch keine Passwortabfrage.

Stattdessen kommt vom IE lapidar der Hinweis das die Seite nicht angezeigt werden kann.

 

Wenn ich auf den Server schau, finden sich im Eventlog keinerlei Einträge, keine Warnungen oder gar Fehler. (nein ich hab die Fehler nicht mittels Filter ausgeblendet :p )

Das Einzige was ich bis dato an Fehlern gefunden habe hier :

aus ..\system32\logfiles\w3svc1\extend1.log

2009-05-28 08:11:03 W3SVC1 FLOERSCH2 192.168.1.35 GET /exchange - 80 - 192.168.250.1 HTTP/1.1 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1;+Mozilla/4.0+(compatible;+MSIE+7.0;+Win32;+1&1);+.NET+CLR+2.0.50727;+.NET+CLR+3.0.04506.30;+.NET+CLR+3.0.04506.648;+.NET+CLR+1.1.4322;+.NET+CLR+3.5.21022;+.NET+CLR+3.0.4506.2152;+.NET+CLR+3.5.30729) - - 192.168.1.35 403 4 5 1828 679 218

die unterschiedlichen IP´s resultieren daraus das ich aus dem VPN getestet habe, aber auch wenn ichs vom Server direkt, oder von einem Client aus teste passiert das Selbe.

 

und aus ..\system32\logfiles\httperr\httperr1.log

2009-05-28 09:02:36 192.168.250.1 1867 192.168.1.35 443 HTTP/1.1 GET /exchange/jd - 1 Connection_Dropped ExchangeApplicationPool

 

Die Einstellungen hab ich jetzt schon mehrfach kontrolliert, die virtuellen Verzeichnisse des IIS, nach http://support.microsoft.com/?scid=kb%3Ben-us%3B883380&x=14&y=7 neu erstellen lassen und das Ganze neu konfiguriert.

 

Wie gesagt, ich habs schon oft so eingerichtet und es hat immer ohne Probleme funktioniert, ist ja auch nicht weiter schwer. Aber im Moment bin ich ein wenig ratlos.

 

Danke im Vorraus für eure Hilfe

[icon 10]

kleines update ... verbindungen ohne SSL funktionieren auch nicht.

Wer an den ASP.Net User gedacht hat, hier fehlen schlicht die passenden Ereignis Einträge. :(

 

Hat einer von euch ne Idee?

[icon 10]

alternativ: da ich jetzt schon 2 Tage über diesem Problem grübele und nicht wirklich weiterkomme ....

 

besteht alternativ die Möglichkeit den IIS auf einem anderen Server zu nutzen um das OWA zur Verfügung zu stellen? Hat da einer ne Art HowTo parat?

[icon 10]

Hier mal ein Auszug aus den "Authentication & Access Control Diagnostics 1.0" ==> Monitor URL Features

 

Zur Info: Das Erzwingen von SSL hab ich ausgeschaltet. Die Adresse die aufgerufen wurde ist http://exchange-server/exchange/BenutzerPostfach

Die Passwortabfrage erfolgt, allerdings kommt dann ein "Zugriff verweigert"

 

System time: Tue, 02 Jun 2009 13:45:40 GMT

Initializing AuthMon, it might take awhile...

Initialization completed, waiting for HTTP requests...

<AuthMon Date="06/02/2009 13:46:05.848"

Status="Currently monitoring for new requests...">

 

 

<AuthMonRow Number="1" tid="0x6f8" Date="06/02/2009 13:46:05.848"

Name="LoadLibraryW all set"

LibFileName="w3core.dll"

/>

 

<AuthMonRow Number="2" tid="0x6f8" Date="06/02/2009 13:46:05.848"

Name="LoadLibraryW"

LibFileName="w3core.dll"

/>

 

<AuthMonRow Number="3" tid="0x6f8" Date="06/02/2009 13:46:05.864"

ProcIdentity="NT-AUTORITT\SYSTEM" ThreadIdentity=""

Name="CoCreateInstance" Success="Yes" Error_Number="0x0"

ProgID="{A9E69610-B80D-11D0-B9B9-00A0C922E750}" time_taken="15 ms"

/>

 

<AuthMonRow Number="4" tid="0x6f8" Date="06/02/2009 13:46:05.927"

Name="AuthMonInitialize" Result="0x0"

/>

 

<AuthMonRow Number="5" tid="0xfd8" Date="06/02/2009 13:46:05.942"

Name="OnNewRequest" SiteId="1" Conn="0xfc00000040000005" Req="0xfc00000060000006"

Verb="GET"

Url="/exchange"

Auth_header_length="0" Auth_header=""

/>

 

<AuthMonRow Number="6" tid="0xfd8" Date="06/02/2009 13:46:05.958"

Name="LogonUserExW" Success="Yes" Error_Number="0"

UserName="IUSR_FLOERSCH2" Domain="MUENCHEN" LogonType="Network Cleartext"

time_taken="0 ms"

/>

 

<AuthMonRow Number="7" tid="0xc10" Date="06/02/2009 13:46:06.380"

Name="AcquireCredentialsHandleA" Result="0x0"

Principal="(null)" Package="wdigest"

/>

 

<AuthMonRow Number="8" tid="0xc10" Date="06/02/2009 13:46:06.380"

Name="AcceptSecurityContext" Result="0x90312" ContextAttr="0x4"

Package="WDigest" UserName=""

ClientName=""

ServerName=""

time_taken="0 ms"

/>

[icon 10]

ok, neuer Tag neues Glück.

was ich bisher so alles versucht habe:

 

Da es sich um einen Domänen Controller handelt:

 

UPDATE: ASP.NET funktioniert nicht mit einem Domänenkonto ohne Administratorberechtigungen auf einem Domänencontroller

entsprechend auch

Prozess- und Anforderungsidentität in ASP.NET

 

- Zurücksetzen der virtuellen Verzeichnisse im IIS

- Ändern der Idendität der Appl Pools auf "Lokales System"

- Auth Diagnostics 1.0 (mit Kaffeesatzlesen kommt man hier glaub ich genauso weit)

 

aktueller Stand der Dinge:

Ich habe einen Domain Controller mit Exchange installiert. DNS,DHCP, FSMO komplett auf diesem Server.

Im Exchange System Manager habe ich unter Protokolle einen zusätzlichen virtuellen HTTP Server angelegt und den alten beendet.

Die virtuellen Verzeichnisse für diese neue Website sind entsprechend angelegt.

Als Authentifizierungsmethode ist aktuell nur die Standard Authentifizierung aktiv.

Das IIS-LOG sagt folgendes

#Software: Microsoft Internet Information Services 6.0

#Version: 1.0

#Date: 2009-06-04 12:52:06

#Fields: date time s-sitename s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status

2009-06-04 12:52:06 W3SVC100 192.168.1.35 GET /WebAccess - 80 - xx.xx.xx.xx Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1;+Mozilla/4.0+(compatible;+MSIE+7.0;+Win32;+1&1);+.NET+CLR+2.0.50727;+.NET+CLR+3.0.04506.30;+.NET+CLR+3.0.04506.648;+.NET+CLR+1.1.4322;+.NET+CLR+3.5.21022;+.NET+CLR+3.0.4506.2152;+.NET+CLR+3.5.30729) 401 2 2148074254

 

über http://exchsrv/webaccess bekomme ich zumindest die Passwort abfrage.

Im Event Viewer sehe ich die erfolgreiche Benutzeranmeldung mit der ID 540

 

Erfolgreiche Netzwerkanmeldung:

Benutzername: jd

Domne: MUENCHEN

Anmeldekennung: (0x0,0x1761627)

Anmeldetyp: 8

Anmeldevorgang: Advapi

Authentifizierungspaket: Negotiate

Arbeitsstationsname: SRV2

Anmelde-GUID: {24905d31-e05f-628b-5803-8aac75c89385}

Aufruferbenutzername: SRV2$

Aufruferdomne: MUENCHEN

Aufruferanmeldekennung: (0x0,0x3E7)

Aufruferprozesskennung: 4208

bertragene Dienste: -

Quellnetzwerkadresse: xx.xx.xx.xx

Quellport: 4197

 

 

Weitere Informationen ber die Hilfe- und Supportdienste erhalten Sie unter Events and Errors Message Center: Basic Search.

 

Wenn ich das hier: Microsoft Corporation

If the user name is a domain account, IIS contacts a domain controller to verify the credentials. If this fails, IIS returns a 401.2 error. If communication with the domain controller is successful, but the user name or password is invalid, IIS returns a 401.1 error.

richtig verstanden habe, dann ist wohl meine Kommunikation mit dem Domain Controller gestört, aber wie wenn alles auf derselben Maschine läuft? Und warum hab ich dann im Event Viewer die erfolgreiche Anmeldung?

 

Bin für jeden Denkansatz dankbar :)

[icon 10]

So, da es gegenüber dem Kunden ein wenig **** kommt zu erklären dass die Umstellung die er für teuer Geld bezahlt hat doch nicht so ganz 100% erfolgreich war, hab ich mir folgenden Spass gemacht.

 

...

 

Auf einem neuen Server, bei uns in der Firma, 2003 R2 installiert.

Selbigen zum weiteren DC erklärt und danach Exchange installiert.

Service Packs drauf, Postfach von meinem Testbenutzer umgezogen und fertig.

 

Also fast genau so wie bei der ersten Installation, nur mit zwei kleinen Unterschieden :

1. Der Server hängt in einem völlig anderen Subnet und ist nur mittels VPN mit dem Kundennetzwerk verbunden.

2. Der Server hält keine der FSMO Rollen.

 

Wenn ich jetzt mittels http://server/exchange an den neuen Server herantrete, werde ich brav nach dem Login gefragt. Ich verrate ihm natürlich wer ich bin und schon habe ich Zugriff auf mein Postfach.

 

So, kann mir jetzt bitte jemand verraten wo mein Fehler bei der ersten Installation lag? Und, wenn den jemand gefunden hat - kann er mir bitte sagen wie ich den wieder behebe? :confused:

 

PS: Was nach wie vor nicht funktioniert, ist der Zugriff auf ein Postfach welches im Informationsspeicher von Server1 liegt. :(