gelöscht

IMHO: wenn schon Greylisting, dann sollte das Device in der Lage sein das auf dynamic IP Ranges zu limitieren. Ich würde aber erwarten, dass das Sohpos Teil auch Blacklisting verwenden kann und damit das Greylisting obsolet ist. ASR

Oder jemanden Fragen der sich mit sowas auskennt... ASR

Auf welchem Server Du das ausführst ist egal. Wie wäre es mit: get-mailbox -database DB4 -monitoring | disable-mailbox get-mailbox -database DB4 -archive | disable-mailbox ? ASR

Warum erst alle einlesen und dann filter? Mach das gleich: Get-Recipient -Filter {RecipientTypeDetails -eq "SharedMailbox"} | FT Name,Manager >C:\temp\shared.csv ASR

Nein, deinstallieren ist nicht. "Einfach" drüber, wie in Exchange 2010 (mal davon abgesehen dass es da keine CUs gab). Vorher hier schauen was es alles für das neue CU braucht: https://technet.microsoft.com/en-us/library/ff728623(v=exchg.150).aspx ASR

Poste doch mal bitte die Autodiscover Antwort wenn die betroffenen User ein Autodiscover für die PF Mailbox macht. Ansonsten ist das Kaffeesatzleserei. ASR

Das impliziert doch der Name "Preview", oder? In jedem Fall werden die "alten" Indexdateien schon nicht mehr für die Suche verwendet. ASR

Funktioniert Autodiscover für die PF Mailbox? ASR

Was ist denn wenn Du den ActiveSync AppPool recyclelst (MSExchangeSyncAppPool)? Geht es dann auch wieder? Kannst Du mal das HealthChecker Script von hier ausführen und den Output posten: https://github.com/dpaulson45/HealthChecker#download Evtl. TCPKeepAlive nicht richtig gesetzt? Sind alle Clients zur selben Zeit betroffen? Reverse Proxy oder MDM dazwischen? Irgenwelche Warnungen dazu im Application Log? ASR

Das ist keine Glaubensfrage, für derlei Themen solltest Du in die Kirche gehen. Schau Dir ein: Get-MailboxStatistics <2019mailbo> | FL *bigfun* an, dann siehst Du die Daten zum neuen Index. ASR

Leg doch mal einen neuen User an der "nur" in "Organization Management" ist und versuche es mit dem. Wenn das nicht klappt, gib mal mit dem -DomainController Parameter einen bestimmten DC an - wahrscheinlich eher ein AD Replikations- denn ein Exchange Problem. Alternativ kannst Du dann auch noch das hier vorgeschlagene versuchen: https://support.microsoft.com/en-gb/help/977960/you-cannot-create-a-new-exchange-server-2010-mailbox-database-in-a-mul ASR

Ja, minimal Hybrid reicht dafür. ASR

Nein, das ist kein guter Plan. Antworten auf alte Mails geht nicht, Serientermine kaputt usw. Auch kannst Du nicht 2007 und 2016 zur selben Zeit haben. Installiere einen Exchange 2013 in die Org und verschiebe die Maiboxen dahin. Oder geh direkt nach O365 und Du kommst nicht mehr in solcherlei Probleme. ASR

Für alle die Zeit zum spielen haben: https://blogs.technet.microsoft.com/exchange/2018/07/24/exchange-server-2019-public-preview/

Ich würde das in jedem Fall bervorzugen, der Betrieb eines eigenen Servers macht nur viel Arbeit, kostet viel Geld und mach technisch und Security mäßig keinen Sinn. Ob mit Migration oder nicht sei dahingestellt. ASR

Das FSW muss beim erstellen einer DAG immer angegeben warden. Wie viele Member dort später hinzugefügt warden spielt erstmal keine Rolle. ASR

Zumindest hier: https://technet.microsoft.com/en-us/library/ff728623(v=exchg.150).aspx schon. ASR

Single-Sign-On ist nicht das selbe wie Passwort Sync... Das hat auch nichts mit SBS zu tun, bestimmte Attribute sind in Azure AD eben "read only" (Stand heute). Musst halt schauen das von den 5Leuten keener in den kommenden Monaten heiratet, den Namen ändert und eine andere E-Mail-Adresse braucht. Dann geht das auch alles ohne On-Prem Server. Evtl. macht es aber eben auch sinn die Identitäten komplett in Azure zu managen, so dass es irgendwann gar keinen Server mehr On-Prem braucht. ASR

Bei 5Usern würde ich nie und nimmer ein AAD Connect bzw. Hybrid machen. Schau mal nach "Cutover Migration". Exchange Hybrid ist von Microsoft bei mehr als 1000Mailboxen vorgesehen. ASR

Oder, falls der Admin keine Mailbox hat, die Arbitration Mailboxen nicht nach 2016 "gemoved" wurden. ASR

Ja, könnten aber auch Clients sein die kein Autodiscover machen/können… Who knows? ASR

Wenn es eine kleine Umgebung ist, stell doch die paar betroffenen auf den neuen Server um und gut. ASR

Doch Klar: wenn als der Servername als namespace verwendet wird. SPN für HTTP wird für den Namen bei der Installation von IIS erzeugt, Auth. steht per Default auf Negoiate. Die Frage/Problemstellung an sich verstehe ich trotzdem nicht. Existiert denn der "alte" Server noch bzw. dessen Computerobjekt? ASR

Hallo, bei einer Cutover Migration Stellst Du nach dem "cut" die AutoDiscoverServiceInternalUri auf $Null, also: Set-ClientAccessServer -Identity <meineServer> –AutoDiscoverServiceInternalUri $Null ASR

+1 sehe ich genau so. ASR