none
alten lokalen Exchange Server aus DNS entfernen / Postfächer umgezogen nach Office 365 RRS feed

  • Frage

  • Hallo,

    wir haben noch einen alten Exchange Server 2010 lokal bei uns am laufen. Unser Postfächer sind seit wenigen Monaten nach Office 365 umgezogen.
    Beim starten von Outlook verbindet Outlook sind ohne ändern der registry am client zum lokalen Exchange.
    Der lokale User im AD ist nicht mehr zum anmelden am Exchange Konto geeignet.
    Reicht es den autodiscover im lokalen DNS (Windows 2008 R2 Domäne) den autodiscover auf Office 365 zu ändern?
    Outlook schlägt immer noch das lokale Benutzerkonto zum Verbinden vor.

    Viele Grüße
    Roland

    so mein registry "hack" aus für Outlook 2016:

    Windows Registry Editor Version 5.00
    
    [HKEY_CURRENT_USER\Software\Microsoft\Exchange]
    "MapiHttpDisabled"=dword:00000001
    
    [HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover]
    "ExcludeHttpsRootDomain"=dword:00000001
    "ExcludeScpLookup"=dword:00000001
    "PreferLocalXML"=dword:00000000
    "ExcludeHttpRedirect"=dword:00000001
    "ExcludeHttpsAutoDiscoverDomain"=dword:00000001
    "ExcludeSrvRecord"=dword:00000001
    


    Freitag, 5. Januar 2018 10:57

Alle Antworten

  • Hallo Roland,

    Outlook verwendet (auf Domainmitgliedern) im ersten Schritt immer den SCP im Active Directory. Erst wenn dieser nicht ermittelt werden kann erfolgen die Abfragen Abfragen im DNS.

    Wenn Ihr ein Hybrid Deployment habt, dann sollte mit dem Verschieben in die Cloud im Attribut targetaddress die sekundäre SMTP Adresse des Cloud Postfaches stehen (xxx@deinefirma.mail.onmicrosoft.com) und das Postfachobjekt wird vom Typ geändert in ein RemotePostfach.
    Mit dieser Information erfolgt im Outlook dann ein Redirect auf die Cloud Dienste.

    Wenn Du keine Postfächer mehr auf dem lokalen Exchange hast, Dann solltest Du auch den DNS Eintrag anpassen.

    Wie werden den die Benutzer in der Cloud verwaltet? Mittels AzureADConnect?

    Sieh Dir mal dieses Thema an. Geht in eine ähnliche Richtung. https://social.technet.microsoft.com/Forums/de-DE/1ce29373-71f1-4b76-9dbd-60a3f4dc4e52/outlook-2016-fragt-nach-jedem-start-nach-benutzername-und-kennwort?forum=exchange_serverde

    Gruß Malte

    Montag, 8. Januar 2018 10:09
  • Wenn Du keine Postfächer mehr auf dem lokalen Exchange hast, Dann solltest Du auch den DNS Eintrag anpassen.

    Wie werden den die Benutzer in der Cloud verwaltet? Mittels AzureADConnect?

    Hallo Malte,

    doch wir haben noch alle Postfächer im lokalen Exchange, aber die verwendet niemand mehr.

    Die Benutzer werden in der Cloud (Office 365) verwaltet.
    AzureADConnect ist aktiv, aber ungeschickterweise wurde der im Anschluss eingerichtet, so dass ich die synchronisierten Benutzer den Postfächern in der Cloud nicht mehr zuordnen kann (zumindest behauptet dies das Support Team der Telekom Cloud)

    Viele Grüße
    Roland

    Montag, 8. Januar 2018 11:55
  • Hallo Roland,

    Ihr habt also Benutzer direkt in der Cloud angelegt, diesen eine Exchange Online Lizenz zugewiesen und dann ohne MoveRequest die Postfachinhalte in die Cloud geschaufelt. Zum Beispiel über den Umweg einer PST-Datei.
    Richtig?
    Wenn das der Fall ist, dann hast Du sozusagen zwei Exchange Organisationen (1 x lokal und 1 x Cloud) und natürlich auch zwei Verzeichnisdienste (lokal und Cloud).

    Die lokalen Benutzer hast Du mittels Hardmatching durch AzureADConnect mit den Cloud Nutzern verknüpft OHNE die Option Exchange Hybrid zu aktivieren.
    Richtig?

    Wenn alle Postfächer in der Cloud bereitstehen und kein Client mehr eine Verbindung zum Lokalen Exchange benötigen, dann kannst Du folgendes tun:

    1. Den Zugriff auf den SCP in der Configuration Partition für die umgestellten Postfächer verweigern. ACHTUNG nicht die Domain User Gruppe nehmen, denn dann kannst Du diesen Eintrag nicht mehr administrieren.

    Den SCP findest Du unter: CN=Autodiscover,CN=Protocols,CN=SERVERNAME,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=EXCHANGE_ORG_NAME,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=DEINEDOMAIN,DC=de

    2. Anpassen des DNS Eintrages

    Wenn es ein Host Eintrag ist, dann diesen in einen CNAME umwandeln (Löschen neu erstellen) und auf den Eintrag zeigen lassen, den Du in den Domaineinstellungen in der Cloud findest.

    3. Überlegen wie es mit dem lokalen Exchange weitergehen soll. (Nur wenn die Exchange Hybrid Option nicht aktiviert ist)

    Gruß Malte

    Montag, 8. Januar 2018 14:42
  • Hallo Malte,

    richtig, Postfachinhalte über PST und IMAP-Migration Script in die Cloud geschaufelt.
    (leider ist unser AD root-Domänenname im Denic bereits registriert aber nicht auf uns, was eine DNS-Auflösung in der Cloud de facto unmöglich machte)
    nein, nicht ganz, die User in der Cloud alle manuell neu angelegt. Ja, es sind nun 2 Exchange Organisationen.

    Den lokalen Exchange 2010 brauchen wir nicht mehr.

    Viele Grüße
    Roland

    Montag, 8. Januar 2018 19:48
  • Hallo Roland

    Da es sich um reine Cloud-Accounts handelt und ihr den lokalen Exchange Server nicht mehr benötigt, dann empfehle ich dir diesen zu deinstallieren.

    Gruss

    Pano


    Pano Boschung, PageUp AG


    Mittwoch, 10. Januar 2018 09:15
  • Hallo Pano,

    korrekt, aber wenn ich die Kombination "AzureADConnect eingerichtet" lese, dann werde ich vorsichtig beim deinstallieren von Exchange.

    Es besteht also keine Verbindung zwischen den Cloud Konten und den Konten im lokalen AD, ja dann kann man den Exchange deinstallieren.

    Das Thema des Mappings von Benutzerkonten ist eine etwas andere Sache.
    Zur zeit existiert kein single Sign On, das ist für Anwender schon sehr lästig.

    Nehmen wir an:
    DNS des Aktive Directory: fremdedomain.net
    DNS der SMTP Domain: meinedomain.de
    UPN Suffixe der Cloudbenutzer: meinedomain.de
    UPN Suffix der AD Benutzer: fremdedomain.net

    Postfächer in der Cloud aktiviert und lizensiert. lokal kein Exchange im AD vorhanden und keine Exchange Attribute an den Benutzern.

    Im O365 existiert kein aus dem AD synchronisierte Benutzer. Dann stehen folgende Optionen zur Verfügung:

    1. Ändern des Active Directory UPNs der Anwender auf den im O365 festgelegten UPN (von userkürzel@fremdedomain.net auf user@meinedomain.de)

    2. Befüllen des AD Attributes Mail mit der primären Mail Adresse die in 0365 verwendet wird.

    3. Soft- oder Hardmatch mittels AzureADConnect durchführen.
    https://support.microsoft.com/en-us/help/2641663/how-to-use-smtp-matching-to-match-on-premises-user-accounts-to-office
    https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-troubleshoot-sync-errors

    Jetzt ist auch ein SSO der verschiedensten Ausprägungen konfigurierbar.

    Gruß Malte

    Donnerstag, 11. Januar 2018 11:33