sZone 10 Geschrieben 10. Februar 2012 Autor Melden Geschrieben 10. Februar 2012 Auf jeden Fall danke für Deine Hilfe. Du hast also auch keine Idee mehr...? :rolleyes: Hat das Fragezeichen im Symbol etwas zu bedeuten? Zitieren
NorbertFe 2.167 Geschrieben 10. Februar 2012 Melden Geschrieben 10. Februar 2012 Hat das Fragezeichen im Symbol etwas zu bedeuten? Nichts was dich beunruhigen müßte, sprich das ist quasi normal beim Exchange. Bye Norbert Zitieren
sZone 10 Geschrieben 11. Februar 2012 Autor Melden Geschrieben 11. Februar 2012 Danke für die Info. Mir ist aufgefallen, dass nicht nur der Abwesenheitsassistent betroffen ist, sondern alle Optionspunkte. Immer gelange ich zurück zur OWA Login-Page und bekomme nach dem erneuten Anmeldevorgang den Hinweis "Unzulässige Anforderung". Gruß sZone Zitieren
RobertWi 81 Geschrieben 11. Februar 2012 Melden Geschrieben 11. Februar 2012 Moin, dann hat der Berater wohl auch beim ECP-Verzeichnis vergessen, die Berechtigungen korrekt zu setzen: set-EcpVirtualdirectory -id srvdecom1\* -BasicAuthentication $true -WindowsAuthentication $true -FormsAuthentication $false Danach wieder den IIS neustarten. Zitieren
sZone 10 Geschrieben 11. Februar 2012 Autor Melden Geschrieben 11. Februar 2012 Moin, das war die Lösung. Nun klappt es auch mit den Optionen. :) Besten Dank noch mal für den Support. Eine Sache ist mir noch aufgefallen... Die öffentliche OWA Adresse ist gelegentlich, auch über mehrere Stunden, nicht erreichbar. Auch die EAS Regel greift nicht, sprich iPads und co bekommen keine Emails. Die anderen TMG Veröffentlichungsregeln funktionieren. Intern funzt OWA auch. Ich habe gerade mal die Reihenfolge der Regeln im TMG-Manager geändert, sprich OWA nach ganz oben. Keine Besserung... Hat jemand eine Idee? Gruß sZone Zitieren
sZone 10 Geschrieben 11. Februar 2012 Autor Melden Geschrieben 11. Februar 2012 Seit dem ich die Authentifizierung vom ECP-Verzeichnis angepasst habe, erreiche ich OWA nicht mehr über die öffentliche Adresse. Wenn ich die Regel auf dem TMG teste ist alles OK. Hat jemand von euch eine Idee.. Gruß sZone Zitieren
RobertWi 81 Geschrieben 11. Februar 2012 Melden Geschrieben 11. Februar 2012 Wie gesagt: Der Berater hat es vermurkst. Hol ihn nochmal ins Haus uns lass es ihn richtig machen. Aus der Ferne ist das alles nur Kaffesatzleserei. Zitieren
sZone 10 Geschrieben 11. Februar 2012 Autor Melden Geschrieben 11. Februar 2012 Hast ja recht..., mit dem Berater. Irgendwie mache ich immer wieder dieselben Erfahrungen. Die Dinge werden nur zur Hälfte erledigt... :mad: Mittlerweile funktioniert OWA wieder..., ohne dass ich etwas geändert habe. Evtl. benötigt das System ja mehrere Stunden um Änderungen zu schlucken. Zitieren
Numrollen 0 Geschrieben 23. März 2017 Melden Geschrieben 23. März 2017 Ich habe genau die gleichen Symptome bei Exchange 2010, 2 Server (wobei einer aktuell keine Postfächer trägt). Wir wollen von TMG auf Kemp wechseln und dafür habe ich die interne owa URL abgeändert (extern=intern und per dns..). Seit dem tritt das Problem auf. Auth sieht bei mir so aus: CertificateAuthentication : InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity} ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity} LiveIdSpNegoAuthentication : False WSSecurityAuthentication : True LiveIdBasicAuthentication : False BasicAuthentication : True DigestAuthentication : False WindowsAuthentication : True CertificateAuthentication : InternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity} ExternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity} LiveIdSpNegoAuthentication : False WSSecurityAuthentication : True LiveIdBasicAuthentication : False BasicAuthentication : False DigestAuthentication : False WindowsAuthentication : True Einzige Besonderheit: Kein Autologin des Benutzers an Owa. Deswegen OWA Authentifizierung über FormBased und Benutzername an Anmeldedomäne. Zitieren
Nobbyaushb 1.508 Geschrieben 23. März 2017 Melden Geschrieben 23. März 2017 Ich habe genau die gleichen Symptome bei Exchange 2010, 2 Server (wobei einer aktuell keine Postfächer trägt). Wir wollen von TMG auf Kemp wechseln und dafür habe ich die interne owa URL abgeändert (extern=intern und per dns..). Seit dem tritt das Problem auf. Auth sieht bei mir so aus: CertificateAuthentication : InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity} ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity} LiveIdSpNegoAuthentication : False WSSecurityAuthentication : True LiveIdBasicAuthentication : False BasicAuthentication : True DigestAuthentication : False WindowsAuthentication : True CertificateAuthentication : InternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity} ExternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity} LiveIdSpNegoAuthentication : False WSSecurityAuthentication : True LiveIdBasicAuthentication : False BasicAuthentication : False DigestAuthentication : False WindowsAuthentication : True Einzige Besonderheit: Kein Autologin des Benutzers an Owa. Deswegen OWA Authentifizierung über FormBased und Benutzername an Anmeldedomäne. Moin, warum hängt man sich an einen 5 Jahre alten Thread? Mache bitte einen neuen Thread auf und schreibe gleich genau rein, was gemacht wurde, welche Version von Kemp du hast (Appliance / VM / Version) und welcher Exchange im Einsatz ist: http://blog-schulenburg.de/index.php/kategorie-als-blog/87-exchange-build-nummern ;) 1 Zitieren
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.