tux007 10 Geschrieben 22. Januar 2010 Melden Teilen Geschrieben 22. Januar 2010 Hi, Ich habe einen Win 2008 SBS Server in Betrieb. Darauf läuft auch ein Exchange.... Nunja, es funktioniert soweit alles ganz gut und ich habe von den Usern noch keine beschwerden bekommen. Bis auf eins: Beim Start von Outlook 2007 kommt eine Passwortabfrage. Dort steht auch der richtige Username incl. Domain drin. Im Hintergrund werden die Ordner Syncronisiert. Outlook ist mit Exchange verbunden. Wenn man das Passwort eingibt, geht das Fenster kurz weg und ist sofort wieder da. Dann klickt man auf "Abbrechen" und unten rechts im Outlook steht "Kennwort erforderlich". Es lässt sich normal arbeiten. Wenn man dann auf "Kennwort erforderlich" klickt fährt ein Menü aus. Da steht dann "Kennwort eingeben". Ein Klick dadrauf und die Meldung idt weg. Hat von euch jemand eine Idee was das sein könnte? Die User haben alle zusätzliche Postfächer. z.B. Info@ und andere projektbezogene Mailadressen, die nicht einfach in einen Verteiler gehen sollten... Der User ist ja König. Die Einstellungen die man im Outlook für das Exchange Postfach machen kann habe ich schon geprüft und einige Kombinationen ausprobiert. (u.a. auf NTLM beschränkt und den Cachemode ausgeschaltet) Zusätzliche Postfächer hatte ich zu Testzwecken schon mal rausgenommen. Ich habe aber bemerkt, dass in der Ereignisanzeige auf dem Server unter Sicherheit zum Zeitpunkt des Startens von Outlook auf dem Client immer 2 mal eine Anmeldung fehl schlägt. Zitieren Link zu diesem Kommentar
tux007 10 Geschrieben 22. Januar 2010 Autor Melden Teilen Geschrieben 22. Januar 2010 Hier das Ergeignis wo die Anmeldung fehl schlägt: Protokollname: Security Quelle: Microsoft-Windows-Security-Auditing Datum: 18.01.2010 18:45:22 Ereignis-ID: 4625 Aufgabenkategorie:Anmelden Ebene: Informationen Schlüsselwörter:Überwachung gescheitert Benutzer: Nicht zutreffend Computer: server.domain.local Beschreibung: Fehler beim Anmelden eines Kontos. Antragsteller: Sicherheits-ID: SYSTEM Kontoname: server$ Kontodomäne: DEUTSCHLAND Anmelde-ID: 0x3e7 Anmeldetyp: 3 Konto, für das die Anmeldung fehlgeschlagen ist: Sicherheits-ID: NULL SID Kontoname: server$ Kontodomäne: Fehlerinformationen: Fehlerursache: Unbekannter Benutzername oder ungültiges Kennwort. Status: 0xc000006d Unterstatus:: 0xc0000064 Prozessinformationen: Aufrufprozess-ID: 0x110c Aufrufprozessname: C:Program FilesMicrosoftExchange ServerBinMicrosoft.Exchange.Search.ExSearch.exe Netzwerkinformationen: Arbeitsstationsname: server Quellnetzwerkadresse: - Quellport: - Detaillierte Authentifizierungsinformationen: Anmeldeprozess: Advapi Authentifizierungspaket: Negotiate Übertragene Dienste: - Paketname (nur NTLM): - Schlüssellänge: 0 Dieses Ereignis wird beim Erstellen einer Anmeldesitzung generiert. Es wird auf dem Computer generiert, auf den zugegriffen wurde. Die Antragstellerfelder geben das Konto auf dem lokalen System an, von dem die Anmeldung angefordert wurde. Dies ist meistens ein Dienst wie der Serverdienst oder ein lokaler Prozess wie "Winlogon.exe" oder "Services.exe". Das Anmeldetypfeld gibt den jeweiligen Anmeldetyp an. Die häufigsten Typen sind 2 (interaktiv) und 3 (Netzwerk). Die Felder für die Prozessinformationen geben den Prozess und das Konto an, für die die Anmeldung angefordert wurde. Die Netzwerkfelder geben die Quelle einer Remoteanmeldeanforderung an. Der Arbeitsstationsname ist nicht immer verfügbar und kann in manchen Fällen leer bleiben. Die Felder für die Authentifizierungsinformationen enthalten detaillierte Informationen zu dieser speziellen Anmeldeanforderung. - Die übertragenen Dienste geben an, welche Zwischendienste an der Anmeldeanforderung beteiligt waren. - Der Paketname gibt das in den NTLM-Protokollen verwendete Unterprotokoll an. - Die Schlüssellänge gibt die Länge des generierten Sitzungsschlüssels an. Wenn kein Sitzungsschlüssel angefordert wurde, ist dieser Wert 0. Ereignis-XML: 4625 0 0 12544 0 0x8010000000000000 29701691 Security server.domain.local S-1-5-18 server$ DEUTSCHLAND 0x3e7 S-1-0-0 server$ 0xc000006d %%2313 0xc0000064 3 Advapi Negotiate server - - 0 0x110c C:Program FilesMicrosoftExchange ServerBinMicrosoft.Exchange.Search.ExSearch.exe - - Zitieren Link zu diesem Kommentar
NorbertFe 2.104 Geschrieben 22. Januar 2010 Melden Teilen Geschrieben 22. Januar 2010 Ein Hinweis auf einen identischen Thread wäre nett: unnötige Passwortabfrage [Forum - Outlook 2007] - msxforum Bye Norbert Zitieren Link zu diesem Kommentar
tux007 10 Geschrieben 22. Januar 2010 Autor Melden Teilen Geschrieben 22. Januar 2010 jo, sorry, aber ich find halt keine Lösung, da poste ich auch schonmal in 2 Foren in der Hoffnung irgendwie weiter zu kommen. Allerdings hab ich den Thread hier ja 1 erfolglose Woche später aufgemacht. Zitieren Link zu diesem Kommentar
maschiin 10 Geschrieben 25. Januar 2010 Melden Teilen Geschrieben 25. Januar 2010 Proxy im Einsatz? Hatten neulich identisches Verhalten. Den Exchange in den Proxy-Settings als Ausnahme konfiguriert und die Abfrage war weg. Gruß Zitieren Link zu diesem Kommentar
tux007 10 Geschrieben 27. Januar 2010 Autor Melden Teilen Geschrieben 27. Januar 2010 (bearbeitet) also ich hab bisher keinen proxy eingestellt, installiert oder irgendwo genutzt. bin grade beim testen, ein system n(icht in der domain mit Win seven und outlook 2003) funktioniert. Werde als nächstes mal versuchen Outlook neu zu insten. bearbeitet 27. Januar 2010 von tux007 Zitieren Link zu diesem Kommentar
tux007 10 Geschrieben 8. März 2010 Autor Melden Teilen Geschrieben 8. März 2010 (bearbeitet) also der hotfix ist es leider nicht hat jemand eine andere Idee?? ich bin ratlos :( Ich habe noch ein Problem, was die selbe Ursache haben könnte: Das offline Adressbuch kann nicht syncronisiert werden. 19:51:15 Synchronisiererversion 12.0.6509 19:51:15 Postfach "Default" wird synchronisiert 19:51:15 Vorgang abgeschlossen 19:51:16 Microsoft Exchange-Offlineadressbuch 19:51:16 Die Offlineadressbuchdateien werden nicht heruntergeladen. Es wurde kein Server (URL) gefunden. 19:51:16 0X8004010F Dies tritt auf, wenn ich manuell über Senden/Empfangen nur das Adressbuch herunterladen möchte. Ein interessantes Detail: Wenn ich den Router aus mache, dauert die anfrage einige Zeit Länger. Ist der Router an, kommt recht schnell die fehlermeldung 0x8004010F "Fehler beim Vorgang. Ein Objekt konnte nicht gefunden werden." Die Meldung kommt aber auf jeden fall.... Wieso auch immer hat ein Client sich das Adressbuch heruntergeladen, der Fehler ist aber reproduzierbar auch dort vorhanden. bearbeitet 8. März 2010 von tux007 Zitieren Link zu diesem Kommentar
olc 18 Geschrieben 8. März 2010 Melden Teilen Geschrieben 8. März 2010 Hi, also wenn ich mir den Prozess oben anschaue, dann deutet es in dem von Dir geposteten Fall auf die "Suche" hin: "ExSearch.exe" Wenn die Suche unter System Rechten läuft, könnte das ein Hinweis auf das Problem sein. Deaktiviere einmal den MSSearch Dienst und prüfe, ob der Fehler auch weiterhin noch auftritt. Viele Grüße olc Zitieren Link zu diesem Kommentar
tux007 10 Geschrieben 8. März 2010 Autor Melden Teilen Geschrieben 8. März 2010 danke für den Hinweis, ich werde es gleich morgen ausprobieren. Beim "best practise analyser" vom Exchange habe ich eine Fehlermeldung über einen fehlenden Dienstprinzipalname. Das soll man wie folgt fixen: Fehlender Dienstprinzipalname Immerhin steht unter oberem Link das Symptom der fehlgeschlagenen Kerberos Authentifizierung. Weitere Meinungen und Tipps sind gern gelesen... :) Zitieren Link zu diesem Kommentar
tux007 10 Geschrieben 9. März 2010 Autor Melden Teilen Geschrieben 9. März 2010 bringt beides nichts. MS Search ausgeschaltet --- keine Änderung Dienstprinzipalname eingetragen und auch keine Änderung des Problems.... :confused: Zitieren Link zu diesem Kommentar
olc 18 Geschrieben 9. März 2010 Melden Teilen Geschrieben 9. März 2010 Hi, merkwürdig ist durchaus, warum dort eine Authentifizierung im Maschinenkontext (also etwa SYSTEM) erfolgt und das auch noch über NTLM. Das kann bis 2008 R2 in der Form nicht funktionieren. Geh einmal in den System Kontext eines betroffenen Clients, etwa mittels "PsExec\\localhost -s cmd" und führe ein "klist purge" aus. Danach zieht Du einen Netzwerktrace auf dem Client, während Du den Fehler in Outlook reproduzierst (also eine Anmeldung durchführst). Dann filterst Du den Netzwerktrace nach Kerberos Paketen und schaust, ob wirklich keine Principal Name Fehler auftreten. Falls doch, kannst Du den problematischen SPN gleich im Trace ablesen... Viele Grüße olc Zitieren Link zu diesem Kommentar
IThome 10 Geschrieben 9. März 2010 Melden Teilen Geschrieben 9. März 2010 War da nicht mal was mit dem Update Rollup 9 für Exchange 2007 ? Zitieren Link zu diesem Kommentar
tesso 375 Geschrieben 9. März 2010 Melden Teilen Geschrieben 9. März 2010 Was hast auf den Clients als DNS eingetragen? Mir schwant du hast den Router eingetragen. Sollte das so sein, dann trage bitte den SBS als DNS ein, sonst werden die SRV Einträge nicht gefunden. Zitieren Link zu diesem Kommentar
tux007 10 Geschrieben 10. März 2010 Autor Melden Teilen Geschrieben 10. März 2010 @tesso: dachte ich auch, ist aber nicht so. Die Clients bekommen die IP über den DHCP des SBS. Der SBS hatte als DNS sich selbst und den Router eingetragen, das habe ich geändert auf nur den SBS, es funzt immer noch (hoffentlich bekomme ich in paar Stunden keinen Anruf) Also DNS Probleme sind ausgeschlossen (möchte ich doch behaupten). @IThome: Ja was war denn da??? @olc: "Netzwerktrace" meinst du mit wireshark oder ähnlichem die Pakete mitschneiden??? thanks for supprt. Zitieren Link zu diesem Kommentar
Stephan Betken 43 Geschrieben 10. März 2010 Melden Teilen Geschrieben 10. März 2010 Ja was war denn da??? Jemand, der seinen Server nicht auf dem aktuellen Stand hat! ;) http://www.mcseboard.de/ms-exchange-forum-80/outlook-autodiscover-dienst-161762.html#post994684 Für den SBS brauchst aber noch das Microsoft Exchange Server 2007 SP2-Installationstool dabei. Zitieren Link zu diesem Kommentar
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.