icePatrick

Du musst den Service Connection Point anpassen, dass ist quasi deine Autodiscover URL des lokalen Active Directory. Anzeigen des SCP über die Exchange Powershell: Get-ExchangeServer | Get-ClientAccessServer | fl Name,Identity,*Uri* Setzen auf O365, dies beeinflusst allerdings alle Outlook Clients in diesem Active Directory: Get-ExchangeServer | Get-ClientAccessServer | Set-ClientAccessServer -AutodiscoverServiceInternalUri https://outlook.office365.com/Autodiscover/Autodiscover.xml

Kann es sein, dass die eine Domain auf Authorativ und die andere auf internes Relay steht: https://community.office365.com/en-us/f/158/t/278850 Das Access denied verwundert mich ein bisschen.

ich würde die Mails über Outlook erstmal in eine PST Datei exportieren. Danach die PST Datei direkt über den Exchange importieren, ich glaube ab Exchange 2013 geht das über die GUI, andernfalls über die PowerShell. Sollten dann noch Fehler bzgl. Größenbeschränkung kommen folgende PowerShell Befehle ausführen: Bei einem Abbruch, wenn es zu viele große Elemente gibt, folgende Befehle ausführen, zuvor jedoch die eingestellten Werte erfassen: Set-TransportConfig -MaxReceiveSize 250MB -MaxReceiveSize 250MB Get-ReceiveConnector | Set-ReceiveConnector -MaxMessageSize 250MB Get-SendConnector | Set-SendConnector -MaxMessageSize 250MB Danach folgende Dienste neu starten: MSExchangeMailSubmission MSExchangeTransport MSExchangeMailboxAssistants

Schau mal nach, ob auf dem 2012 Server SMB 1.0 installiert ist, falls nicht bitte nachinstallieren: https://workinghardinit.wordpress.com/2014/04/25/windows-xp-clients-cannot-execute-logon-scripts-against-a-windows-server-2012-r2-domain-controller-workaround/

Hier hat wirklich der Outlook Cache noch den alten Eintrag drin. Gehe in Active Directory Benutzer und Computer > Ansicht > Erweiterte Features aktivieren OU Microsoft Exchange System Objects > hier die Eigenschaften des öffentlichen Ordners auswählen, Reiter "Attribut-Editor" Hier das Attribut "proxyAddresses" auswählen und als zusätzlichen Eintrag X500:/O=ERSTE ORGANISATION/OU=ERSTE ADMINISTRATIVE GRUPPE/CN=RECIPIENTS/CN=***05731E20435C8313E30C9CB346B3E3F6004AE0@firma.tld hinzufügen. Ich weiß jetzt nicht, inwieweit du den Eintrag oben verändert hast, das müsstest du noch anpassen.

Hi, schau dir mal diesen KB-Artikel an, vielleicht trifft das beschriebene zu und der Hotfix löst das Problem: http://support.microsoft.com/kb/2769790/en-us

Heisst eure interne Domain so wie eure öffentliche Domain? Bei uns ist das der Fall, die Anmeldung dauert ausserhalb des Unternehmen auch sehr lange. Im Eventlog gibt es für jeden Netzwerkadapter eine DNS Fehlermeldung. Ich vermute, weil er die Domain augenscheinlich ja erreicht (hinter firma.de verbirgt sich allerdings nur die Webseite) versucht der Laptop, sich dort anzumelden und läuft dann irgendwann in einen Timeout. Habe allerdings noch keine Möglichkeit gefunden, die Anmeldung ausserhalb des Firmennetzes zu beschleunigen.

Ich würde auch mal testen was passiert, wenn du diesen einen Standort autark betreibst, ohne VPN Verbindung zu den anderen Standorten. Evtl. treten dann Anmeldefehler an den Clients auf.

Mir ist keine Möglichkeit bekannt, wenn du die Dateien mit Robocopy /copyall kopierst werden auf dem neuen Server in den Dateieigenschaften die SIDs der alten Benutzer angezeigt. Wenn es dir nur darum geht, im Nachhinein gewisse Dinge nachvollziehen zu können (z.B. wer hat Datei XYZ erstellt) kannst du dir eine Liste mit den SIDs zu den alten Usern erstellen und dann jedesmal darin die SID nachschlagen.

Wie heisst den der Standort? Fängt dieser mit einer Zahl an? http://www.faq-o-matic.net/2012/10/31/ad-standorte-namen-drfen-nicht-mit-ziffern-beginnen/

Für was soll der csuffix.net gut sein? Gibt es csuffix.net im Internen DNS? Mach mal ein nslookup addimain.net. also mit einem Punkt am Schluss, dann sollte der Client korrekt auflösen.

Melde dich mal am Exchange ohne Netzwerk an, stelle die Netzwerkverbindung wieder her und starte den Exchange neu. Falls das nicht hilft würde ich mich ohne Netzwerk am Exchange anmelden, Netzwerkverbindung herstellen, dann am Exchange in die Computereigenschaften gehen und wenn eure Domäne Firma.local heißt den Wert nur auf Firma ändern, mit OK bestätigen und den Server neu starten. Dadurch wird er frisch in die Domäne aufgenommen, ohne aus der Domäne genommen zu werden. Habe das aber noch nie an einem Exchange durchgeführt, sollte er danach gar nicht mehr funktionieren hast du ja immer noch die Sicherung.

Geht denn alles andere noch (OWA, SBS Konsole)? Ging die Remoteseite, bevor du den Sharepoint Assistent ausgeführt hast? Ist das bei dir eine Testumgebung oder Produktiv? Falls test kannst du mal folgendes ausprobieren. Habe in meinen Unterlagen folgenden Link abgelegt, da hatte auch jemand nach ausführen des Sharepoint Assitent Probleme, Lösung steht im letzten Beitrag. http://www.mcseboard.de/topic/177918-sbs-2011-nach-konfiguration-von-sharepoint-keine-funktion-exchange-mgmtkonsole/

Wahrscheinlich wurde das SP1 für Sharepoint installiert. Führe folgendes durch, dann erhälst du die Meldung nicht mehr: - Die "SharePoint 2010 Administrations Konsole" unter "Start->Alle Programme->Microsoft SharePoint 2010 Products" als Administrator ausführen - In der sich öffnenden Kommandozeile "(get-spserver $env:computername).NeedsUpgrade" eingeben und schauen, was ausgegeben wird. Wird ein "True" als Antwort gegeben, sollten die weiteren Schritte das Problem beseitigen können. - Die gute alte Kommandozeile "als Adminstrator"(!) öffnen ins Verzeichnis "C:\Programme\Common Files\Microsoft Shared\Web Server Extensions\14\BIN" wechseln (cd "C:\Programme\Common Files\Microsoft Shared\Web Server Extensions\14\BIN") - Ausführen des Befehls "PSConfig.exe -cmd upgrade -inplace b2b -force -cmd applicationcontent -install -cmd installfeatures"

Schau mal hier, test mal die erwähnten Updates: http://social.technet.microsoft.com/Forums/windowsserver/en-US/d2d60b1e-8f0a-4106-9c95-22938ff92978/synchronize-from-microsoft-updates-an-http-error-occurred