none
Migration Exchange 2007 auf 2010 - kein Login per Mac und Iphone möglich RRS feed

  • Frage

  • Hallo zusammen,

    haben eine Migration von Exchange 2007 auf 2010 durchgeführt. Es funktioniert

    alles soweit mit Outlook und OWA (Intern sowie Extern ohne Cert-Fehler).

    Allerdings können wir uns nun nicht mehr per Iphone (Intern,Extern) sowie

    per Mac (immer Passwortabfrage) einwählen.

    Ein Problem was besteht ist, das der Autodiscover Modus ein falsches Zertifikat

    nimmt, allerdings weiß ich nicht wieso. Das seltsame ist, der Aussteller ist unser Router.

    Hat jemand eine Idee was ich eventuell ändern könnte?

    Mittwoch, 6. Februar 2013 13:11

Antworten

  • Also es geht nun - kann Mails und den Kalender auf einem Mac empfangen und versenden.

    Habe noch was am DNS - Autodiscover geändert und was am Ende nun den Erfolg gebracht, schwer

    zu sagen.

    Danke an ALLE ;)

    • Als Antwort markiert Alex Pitulice Dienstag, 12. Februar 2013 15:28
    Montag, 11. Februar 2013 13:17

Alle Antworten

  • Hallo,

    als erstes solltest du die internen und extern URL prüfen.

    http://msexchangefaq.de/e2007/casproxy.htm

    Kannst du mal an einem internen Client das Autodiscover prüfen?

    Strg+rechstklick auf das OL-Icon in der Taskleiste, E-Mail-Autokonfiguartion testen.

    Die beiden Guess-Smart Haken raus.

    Die ermittelten URL prüfen.

    ;)


    Gruß Norbert

    Mittwoch, 6. Februar 2013 13:39
    Moderator
  • Hallo,

    die URL bei Intern und Extern gleich eingetragen und wird vom jeweiligen

    DNS gehandelt. Vor dem Exchange haben wir ein Gateway, welches die

    Anfragen durchschleift.

    Der E-Mail Konfig zeigt, das die URLs welche ich konfiguriert habe, genommen werden -

    allerdings floppt ein Sicherheitshinweis auf welcher mir sagt - dass das Zertifikat

    1) nicht von einer vertrauenswürdigen Firma ausgestellt wurde.

    2) der Name mit der Website nicht übereinstimmt.

    Der Aussteller des Zertifikats ist unser Router, nur hab ich keine Ahnung wieso der Router

    eine Zertifikatsanfrage auslöst.

    Das SSL Zertifikat ist ein SAN welches 5 verschiedene Domännamen enthält und auch ein

    Eintrag für den Autodiscover. Und diesen meckert er an.

    Wenn ich den Befehl eingebe:

    Get-ClientAccessServer | fl name,autodiscoverserviceinternaluri sehe ich das er auf die https:// Adresse meines Servers

    geht anstatt auf den öffentlichen DNS Eintrag. Habe ich aber geändert so wie es beim alten Exchange war.



    • Bearbeitet MichiMM Mittwoch, 6. Februar 2013 15:01
    Mittwoch, 6. Februar 2013 13:55
  • Hallo,

    ist der Router auch das Gateway, von dem du im OP schreibst?

    Die URL auf den 2010 dort angepasst?

    Landen auch wirklich alle https: (Port443) auf dem Exchange und nicht auf dem Router?

    Hatte sowas mal mit Lancom.

    Ihr verwendet also Split DNS, da stimmt alles?

    ;)


    Gruß Norbert

    Mittwoch, 6. Februar 2013 15:48
    Moderator
  • Hallo,

    die URL autodiscover.page.de/...... landet auf dem öffentlichen Gateway und wird per VPN durch

    unseren Router an den Exchange geleitet. der Ping auf die URL stimmt überein, der richtige

    DNS angelegt - pingt man intern auf die URL an, geht er direkt auf unseren Exchange Server - das sollte

    soweit alles klappen und funktioniert auch mit Outlook wunderbar, OWA intern wie extern wunderbar.

    Nur die Macs haben derzeit das Problem, das sie immer wieder eine PW-Abfrage stellen und das

    falsche autodiscover Zertifikat anzeigen (das vom Router).

    Was noch seltsam ist, das ein Iphone intern wie extern funktioniert.

    Habe die Vermutung das der IIS oder irgendwas die Authentifizierung nicht ermöglicht.

    • Bearbeitet MichiMM Mittwoch, 6. Februar 2013 16:07
    Mittwoch, 6. Februar 2013 16:04
  • Hallo,

    Nur die Macs haben derzeit das Problem, das sie immer wieder eine PW-Abfrage stellen und das

    falsche autodiscover Zertifikat anzeigen (das vom Router).

    Was noch seltsam ist, das ein Iphone intern wie extern funktioniert.

    Habe die Vermutung das der IIS oder irgendwas die Authentifizierung nicht ermöglicht.

    Dem Iphone ist das Zertifikat ziemlich egal.

    Das kann nicht am IIS liegen, wenn die Clients (die internen oder die externen?) das Cert vom Router sehen.

    Stimmt die URL zum EWS? Den nutzen die Mac.

    ;)


    Gruß Norbert

    Mittwoch, 6. Februar 2013 16:20
    Moderator
  • Hallo,

    das mit dem EWS scheint ein guter Tip zu sein - die URL ist aufjedenfall eine andere wie beim

    Exchange 2007 und ich kann die neue nicht setzen weil er mir was mit dem DNS meckert.

    Da werde ich mal nun dran gehen ;)

    Der Exchange meckert beim umstellen der URL das er das Objekt Exchange Server nicht auf dem DC finden kann, wobei alle DNS Auflösungen funktionieren.

    bzw. mit Get-WebServicesVirtualDirectory | fl zeigt er mir die externe und interne URL richtig an und ich kann mich bei beiden URLs mit meinem Windows-User anmelden. Wieso da der DNS meckert, ist fraglich.

    Was ich mich noch frage ist, ob der Exchange 2007 das Problem verursacht da er noch läuft. Wollte ihn noch nicht komplett ablösen, bevor nicht alles 100% geht.

    • Bearbeitet MichiMM Donnerstag, 7. Februar 2013 09:07
    Donnerstag, 7. Februar 2013 08:04
  • Also auf dem Iphone gehen meine Mails wieder, das Problem konnte dieser Link lösen:

    http://codingstube.de/2010/06/active-sync-mit-exchange-server-schlagt-fehl-z-b-iphone-keine-verbindung-zum-server/

    was mir beim Mac auffällt ist, das im Ereignislog unter Sicherheit ich folgenden Hinweis erhalte.

    Protokollname: Security
    Quelle:        Microsoft-Windows-Security-Auditing
    Datum:         07.02.2013 15:21:11
    Ereignis-ID:   4625
    Aufgabenkategorie:Anmelden
    Ebene:         Informationen
    Schlüsselwörter:Überwachung gescheitert
    Benutzer:      Nicht zutreffend
    Computer:      Exchange.xxx.local
    Beschreibung:
    Fehler beim Anmelden eines Kontos.

    Antragsteller:
        Sicherheits-ID:        SYSTEM
        Kontoname:        EXCHANGE$
        Kontodomäne:        xxxx
        Anmelde-ID:        0x3e7

    Anmeldetyp:            8

    Konto, für das die Anmeldung fehlgeschlagen ist:
        Sicherheits-ID:        NULL SID
        Kontoname:        xxx@xxx-xxxx.de
        Kontodomäne:        EXCHANGE

    Fehlerinformationen:
        Fehlerursache:        Unbekannter Benutzername oder ungültiges Kennwort.
        Status:            0xc000006d
        Unterstatus::        0xc0000064

    Prozessinformationen:
        Aufrufprozess-ID:    0xd48
        Aufrufprozessname:    C:\Windows\System32\inetsrv\w3wp.exe

    Netzwerkinformationen:
        Arbeitsstationsname:    EXCHANGE
        Quellnetzwerkadresse:    xxx.xxx.xxx.xxx
        Quellport:        51480

    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.


    • Bearbeitet MichiMM Donnerstag, 7. Februar 2013 14:26
    Donnerstag, 7. Februar 2013 14:26
  • Hi Michi,

    Kann es sein, dass auf dem Mac als Benutzername die E-Mail Adresse definiert ist und der User Principal Name vom betroffen Benutzer jedoch username@domain.local ist?

    Falls ja, dann ändere den Benutzernamen auf dem Mac Client, dass dieser gleich wie der UPN ist oder ändere den UPN in die E-Mail Adresse um. Die zweite Variante wäre schöner.

    Anleitung um den UPN im AD zu ändern.

    1. UPN Suffix hinzufügen

    2. UPN des Benutzers ändern

    Gruss Andy

    Donnerstag, 7. Februar 2013 17:37
  • Hi Andy,

    leider hat das damit nichts zu tun. Hab es mal so mal so getestet und das anmelden klappt

    einfach nicht.

    Beim Iphone funktioniert die normale Exchange Einrichtung und Anmeldung wieder - sprich

    normal sollte das klappen und hat mit dem Exchange 2007 auch geklappt ;)

    Echt seltsam das ganze.


    Achso was eventuell noch interessant zu erfahren wäre - der DC ist ein 2012
    • Bearbeitet MichiMM Freitag, 8. Februar 2013 07:53
    Freitag, 8. Februar 2013 07:49
  • Kannst du mal schauen was in den IIS - Exchange Logfiles steht unter C:\inetpub\logs\LogFiles\W3SVC1\ wenn du versuchst dich anzumelden mit dem MAC?

    Da sollten dann zeilen mit /EWS/Exchange.asmx zu finden sein.

    Freitag, 8. Februar 2013 10:04
  • Mehr steht eigentlich nicht drin:

    2013-02-08 10:31:38 192.168.xxx.xxx POST /autodiscover/autodiscover.xml - 443 - 192.168.xx.xx Mac+OS+X/10.8.2+(12C2034);+ExchangeWebServices/3.0+(157);+Mail/6.2+(1499) 401 0 0 15

    2013-02-08 10:33:17 192.168.xxx.xxx POST /EWS/Exchange.asmx - 443 - 192.168.xxx.xxx Mac+OS+X/10.8.2+(12C2034);+ExchangeWebServices/3.0+(157);+Mail/6.2+(1499) 401 0 0 0

    Hab gesehen dass das Rollup eventuell das mit dem EWS und Mac lösen kann:

    http://support.microsoft.com/kb/2785908

    Freitag, 8. Februar 2013 10:38
  • Mehr steht eigentlich nicht drin:

    2013-02-08 10:31:38 192.168.xxx.xxx POST /autodiscover/autodiscover.xml - 443 - 192.168.xx.xx Mac+OS+X/10.8.2+(12C2034);+ExchangeWebServices/3.0+(157);+Mail/6.2+(1499) 401 0 0 15

    2013-02-08 10:33:17 192.168.xxx.xxx POST /EWS/Exchange.asmx - 443 - 192.168.xxx.xxx Mac+OS+X/10.8.2+(12C2034);+ExchangeWebServices/3.0+(157);+Mail/6.2+(1499) 401 0 0 0

    Hab gesehen dass das Rollup eventuell das mit dem EWS und Mac lösen kann:

    http://support.microsoft.com/kb/2785908

    Naja dort ist ein HTTP Error 401, heißt nicht authorisiert. 
    Freitag, 8. Februar 2013 11:26
  • Hi,

    kannst du Adminsholder und Vererbungsprobleme ausschließen?
    http://www.msexchangefaq.de/konzepte/adminsdholder.htm

    Hast du den das EWS-Directory zurückgesetzt?


    Viele Grüße
    Christian

    Samstag, 9. Februar 2013 18:31
    Moderator
  • Hallo,

    mit der Vererbung haben wir das Problem, das er diese immer deaktiviert.

    Damit konnte ich das das Problem lösen, das die Push-Nachrichten aufs Iphone wieder

    gehen.

    Die restlichen Vorschläge gehe ich nun einzeln durch.

    Montag, 11. Februar 2013 08:53
  • >mit der Vererbung haben wir das Problem, das er diese immer deaktiviert.

    Dann ist oder war der User mal Mitglied einer administrativen Gruppe.

    Wenn er es ist: Rausnehmen, mit Admins kann nicht gearbeitet werden.

    Wenn er es war: AdminSDHolder prüfen, siehe Link von Christian.


    Grüße aus Berlin schickt Robert
    MVP Exchange Server
    Montag, 11. Februar 2013 09:41
  • Wenn ich einen neuen User anlege, der nur in der Domänen-Benutzer Gruppe ist, funktioniert

    das anmelden per Mac ebenso nicht. Nur als Info - falls das eine Rolle spielt


    Das Problem besteht ja nur bei Apple Mail - internes Outlook, Iphone funktioniert - auch mit meinem User der Adminrechte hat.
    • Bearbeitet MichiMM Montag, 11. Februar 2013 09:52
    Montag, 11. Februar 2013 09:50
  • Also habe nun alles getestet und auch mal das Script in diesem Link versucht:

    http://www.msexchangefaq.de/konzepte/adminsdholder.htm

    auch habe ich einen neuen User nochmals angelegt aber das anmelden per AppleMail funktioniert

    nicht.

    Werde zum test auch mal ein Outlook per Anywhere testen.

    Montag, 11. Februar 2013 10:24
  • Also es geht nun - kann Mails und den Kalender auf einem Mac empfangen und versenden.

    Habe noch was am DNS - Autodiscover geändert und was am Ende nun den Erfolg gebracht, schwer

    zu sagen.

    Danke an ALLE ;)

    • Als Antwort markiert Alex Pitulice Dienstag, 12. Februar 2013 15:28
    Montag, 11. Februar 2013 13:17