NorbertFe

Nein. Aber auch die autodiscover Konfiguration für die zusätzliche Domäne stand oben im Thread schon als Lösung drin. ;)

Die Auswirkungen wären die selben gewesen ;)

Ähm das wäre jetzt auch identisch gewesen, wenn du der blöden Mailbox einfach die andere Mailadresse zugewiesen hättest, wie ich das vor Stunden bereits vorgeschlagen hab. Erspart dir nämlich zwei unterschiedliche autodiscover Konfigurationen.

Hallo und willkommen, wieso "wagen"? Gebissen wird hier meist nicht. ;) Bevor du wirklich dein LDAP (auch per s gesichert) nach extern aufmachst, solltest du erstmal nachfragen, ob es nicht sinnvollere Authentifizierungsmethoden gibt. Schau mal in diesen Thread hier: Bye Norbert

WSUS Package Publisher. Ein Tool für die Bereitstellung eigener Updatepakete über den WSUS.

Die Frage ist, warum steht das da drin? Normalerweise ist das leer und die Default Mailbox kommt global. Stimmt, jetzt wo du es sagst, erscheint mir das auch logisch. :) Dann eben die andere clientseitige MEthode.

Naja aber wenns geht, hast du sofort die Rückmeldung. Das Problem generell ist, dass vieles eben auf Autodiscover basiert und das dann so oder so immer eine "nicht näher bestimmte" Zeitspanne benötigt, bis alle Clients mal wieder neu autodiscovern. :/

Würde ich zumindest mal empfehlen.

.local oder die public Domain für die auch das Zertifikat gilt? Ist halt etwas "Gestocher", wenn man nicht vor dem System sitzt. ;)

Achso noch was: https://support.microsoft.com/en-in/help/2788136/outlook-users-cannot-access-public-folders-in-exchange-server-2013-or schau auch mal hier: Geht zwar um Resssourcenmailboxen, aber auch da war Autodiscover und falsche Adresserichtlinie der Auslöser: Bye Norbert

Hast du eventuell mal ein anderes Outlook? EInfach um ein clientseitiges Problem zu diagnostizieren?

Nein, denn das ist ja eine Änderung der Mailbox und nicht des Servers. Die Umstellung erfolgt per Autodiscover, kann also ein paar Minuten/Stunden dauern bis das ankommt. Alternativ neues Outlook Profil anlegen und schauen ob die Verbindungseigenschaften jetzt auf http/RPC stehen statt auf HTTP. https://blogs.technet.microsoft.com/rmilne/2017/01/25/how-to-disable-mapihttp-for-a-single-mailbox/ Geht notfalls auch clientseitig. Siehe Link. Bye Norbert

Ist das ein single Server (Exchange)? Ich würde mal exemplarisch statt Mapi/http für einen betroffenen User auf Outlook Anywhere konfigurieren. Das geht ja mittels set-casmailbox in Exchange 2016 (Set-CASMailbox -MapiHttpEnabled:$False) und mal beobachten, ob das zu Änderungen führt.

Erfolgt der Zugriff mittels mapi/http oder RPC over https?

Trifft es immer die gleichen Nutzer oder willkürlich mal den und mal den? Wenn letzteres, könnte es auch ein Threshold Problem auf dem Exchange sein.

Die 8h sollen auch ausgenutzt werden. ;)

Lebt der Exchange 2010 noch? Wie viele Public Folder Mailboxes hast du?

Die Änderung kann eine Weile dauern. Wie lange hast du bisher gewartet, nachdem du diese Änderung (adsiedit) vorgenommen hast?

Wie lautete denn der Servername des Exchange 2010 und gab es ggf. ein RPC CAS Array, welches den "falschen" Namen hatte?

Funktioniert es mit neuen Outlookprofilen? Betrifft das nur migrierte Postfächer oder auch neue?

Wenn es mehrere VMs werden würden, wäre die Lizenzierung auf jeden Fall falsch. Denn die Mindestlizenzierung beträgt dann 4 Cores/vCPUs per VM. Die kann man nicht auf 2 VMs mit je 2 Cores/vCPUs splitten.

2011. Fällt ja schnell auf ;)

Du hast adminrechte auf der Firewall? Bei den Fragen die du stellst eher unwahrscheinlich. Frag doch den Firewall-Admin, wie du deinen Server ins Internet stellen kannst. Ich bezweifle allerdings, dass die das zulassen.

Alles klar. Danke für die Rückmeldung und viel Erfolg.

Hallo, interessant wäre zu wissen, welche Exchangeversion du in welchem Patchstand einsetzt. Nur die Default Policy einzusetzen ist schlechter Stil, denn die greift immer und für alles. Damit man das etwas "sinnvoller" steuern kann, definier doch mal eine neue, welche nur für Kontakte wirkt und definiere darin dann die entsprechenden Bedingungen.