gelöscht
-
Gesamte Inhalte
808 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von gelöscht
-
-
vor 4 Minuten schrieb peterg:
OK, dann muss ich aber auch am DNS bei Domainfactory und wohl am DNS unserer Domäne rumfummeln. Da muss ich mal googeln
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
-
vor 1 Stunde schrieb addy0604:
Gibt es eigentlich Besonderheiten bei der Installation von CUs unter Exchange 2016? Ich glaub ich hab mal was gelesen, das vorherige CUs vorher deinstalliert werden müssen, bin mir aber nicht sicher.
Bei Exchange 2010 hatte ich jedenfalls nie Probleme. Einfach drüberinstalliert, neu gestartet, fertig…
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
-
vor einer Stunde schrieb tesso:
Die Implementation ist noch nicht hundertprozentig fertig.
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
-
Am 7/29/2018 um 15:36 schrieb tesso:
Der Index der Datenbanken soll sich jetzt in den Datenbanken befinden. Das glaube ich noch nicht so recht. Es wird weiterhin die Ordnerstruktur samt Inhalt angelegt.
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
-
vor 17 Stunden schrieb =BT=Viper:
Genau sowas steht mir nun auch bevor. 2007 -> 2016. Da es aber eine recht kleine Organisation ist, wird es wohl schneller sein die Mails über Outlook zu exportieren und danach wieder importieren.
Mein Vorgehen wäre also:
1. Mails in PST exportieren
2. Postfach auf EXCH2007 löschen
3. Postfach auf EXCH2016 erstellen
4. Outlook neu verbinden und Mails importieren5. Danach alten EXCH2007 deinstallieren
Meint ihr das funktioniert so?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/
-
Am 7/20/2018 um 17:51 schrieb Dirk-HH-83:
#Vorschlag Ultimative Lösung 2
Komplettwechsel auf O365 ohne Migration mit APT Schutz und Mail-Archivierungsaddon...
bei Hybridbetrieb verstehe ich den Vorteil nicht
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
-
Am 7/15/2018 um 19:23 schrieb john23:
Hatte mich etwa falsch ausgedrückt. War mir nur nicht sicher, ob der FSW immer konfiguriert sein kann/darf.
Danke für die Antworten.
Das FSW muss beim erstellen einer DAG immer angegeben warden. Wie viele Member dort später hinzugefügt warden spielt erstmal keine Rolle.
ASR
-
Am 7/11/2018 um 16:09 schrieb tesso:
Kenne ich schon.
Ist doch normal, alles was nicht in der Supportmatrix ist nicht supportet.
Dabei ist mir heute aufgefallen, das bei Ex2010SP3RU22 noch nicht der AD2016 Support eingetragen ist. Ich meine in den Releasenotes stand es drin.
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
-
vor 2 Stunden schrieb NorbertFe:
Immer schön, wenn man zwei Fragen stellt und eine davon beantwortet wird. ;) Aber du hast ja erstmal eine Lösung. Im Allgemeinen passiert das, wenn das Adminpostfach noch auf dem alten Server residiert.
Oder, falls der Admin keine Mailbox hat, die Arbitration Mailboxen nicht nach 2016 "gemoved" wurden.
ASR
-
vor 2 Stunden schrieb NorbertFe:
Wenn autodiscover funktioniert, dann passiert das doch automatisch. Ich vermute, nur der Alias hat das "erfolgreich" verhindert bisher.
Ja, könnten aber auch Clients sein die kein Autodiscover machen/können… Who knows?
ASR
-
vor 19 Stunden schrieb john23:
Den alten Server gibt es nicht mehr und das Computerobjekt auch nicht mehr - nur noch einen Alias mit dessen Namen im DNS.
Wenn es eine kleine Umgebung ist, stell doch die paar betroffenen auf den neuen Server um und gut.
ASR
-
Doch
vor einer Stunde schrieb NorbertFe:Dann hilft dir der alias aber nicht. Hast du Exchange überhaupt mit Kerberos im Einsatz? Per default spricht der mit den Clients afaik nicht Kerberos.
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
-
Am 6/6/2018 um 19:02 schrieb testperson:
es kann sicherlich Gründe für einen Exchange On-Prem geben. Bei 10 Usern würde ich aber definitiv O365 in Betracht ziehen.
+1
sehe ich genau so.
ASR
Mails von manchen Sender benötigen 15 Minuten bis sie beim Server ankommen
in MS Exchange Forum
Geschrieben
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