Jump to content

john23

Members
  • Gesamte Inhalte

    199
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von john23

  1. Bevor ich Outlook.domain.de auf die alte Exchange usmtelle muss ich sichergehen, dass alle Clients die neue richtige Konfig haben, da sonst keiner mehr eine Verbindung bekommen würde (Postfächer sind ja alle auf dem Exchange 2016). Zudem ist die Frage in wie vielen Systemen outlook.domain.de noch eingetragen ist um sich eventuell an E-Mail Konten anzumelden und was zu machen. SMTP selbst wäre nicht schlimm, das sollte ja noch weiter funktionieren. Der ServiceConnection Point zeigt momentan auch auf outlook.domain.de - den sollte ich wohl als erstes auf autodiscover.domain.de ändern, damit der losgelöst von dem Namen funktioniert. Ich habe in den letzten Tagen auch einen Test mit den SCP gemacht um den Loadbalancer zu umgehen --> den SCP auf server1.domain.de gesetzt ( ist auch auf den Zertifikat enthalten). Im Outlook konnte ich aber immer noch sehen, dass der Autodiscover test outlook.domain.de angesprochen hat. Wie lange dauert es bis der SCP aktiv wird für die Clients? Muss ich dienste dafür neu starten?
  2. Danke für die Antwort erst mal. Ich hoffe ja schlauer zu werden statt dümmer :P. Ich habe die Endpunkte vom alten Exchange übernommen, da diese in vielen Systemen drin stehen. Dachte ich würde damit Probleme vermeiden, ist aber wohl anders. Mobile.domain.de und outlook.domain.de zeigen intern momentan auf die gleiche IP - die Namen sind auch überall in den Zertifikaten drinne, daher sollte es wohl gehen, dass ich alle Endpunkte auf Mobile.domain.de ändere außer den RPC endpunkt. EXPR und EXCH könnte ich außerhalb der Arbeitszeit setzten auf ServerExclusivConnect.
  3. Hallo Leute, oh überraschung ich habe wieder ein Autodiscover Thema.. Ich denke ich bin schon besser im Thema Exchange geworden, aber es gibt immer wieder Situationen wo ich nicht so recht weiter weis. TLDR: Autodiscover Outlook2010 geht Outlook 2016 geht nicht. 2x CAS Exchange 2010 2x MB Exchange 210 DAG CAS Array war outlook.domain.de --> Der Name ist auf den LB übergegangen und das CAS Array Objekt in Form von dem Computerobjekt gibt es noch Migration zu Exchange 2016 Kemp Loadmaster 3x Exchange 2016 DAG Clients Windows 7 / Outlook 2010 / 2016 Die Postfächer sind bereits alle auf dem Exchange 2016 Bisher waren alle Clients überwiegend Outlook 2010 was mit meiner Konfiguration auch funktioniert hat. URLs sind auf outlook.domain.de und mobil.domain.de Split DNS ist vorhanden Alles läuft momentan noch über RPC/HTTP(S) MAPI ist Global deakiviert Wenn ich MAPI auf ein Postfach aktiviere komme ich in Outlook nicht mehr rein, weder Outlook 2010 noch 2016. Es gibt eine GPO welche für die Outlook 2010 Clients Konfiguration für Outlook Anywhere verteilt: https://outlook.domain.de Nur SSL für Verbindungen verwenden Bei Langsamen und bei Schnellen Netzwerken Verbindung über HTTP Herstellen ,dann über TCP/IP Auth NTML EXPR und EXCH Eintrag wurden in der Migration nicht geändert: CertPrincipalName : leer Nun kann ich bei den Outlook 2010 Clients problemlos Autodiscover machen, seltsam finde ich nur, dass wenn ich einen Test in Outlook mache ich beim ersten Test 2x http 401 herausbekomme und dann erst ein http 200. Danach nur noch ein HTTP 200. Ein Outlook 2016 Client kann sich via Autodiscover nicht verbinden, es kommt ein Passwort Popup. Über den Browser kann ich mich nicht einloggen wenn ich outlook.domain.de/autodiscover/autodiscover.xml aufrufe jedoch wenn ich am Loadbalancer vorbei an einzelne Exchange Server gehe schon über server.domain.de/autodiscover/autodiscover.xml Wenn ich das ganze zum testen in die Hosts eintrage kann ich dennoch kein Outlook einrichten. Wenn ich den Autodiscover Test mache bekomme ich nur Http: 401 zurück mit Fehgeschlagen (0x800040413) Test-OutlookWebServices | FL Scenario : AutoDiscoverOutlookProvider ScenarioDescription : AutoErmittlung: Outlook-Anbieter Result : Failure Latency : 210 Error : System.Net.WebException: Der Remoteserver hat einen Fehler zurückgegeben: (401) Nicht autorisiert. ---> System.ComponentModel.Win32Exception: Der Zielprinzipalname ist falsch bei System.Net.NTAuthentication.GetOutgoingBlob(Byte[] incomingBlob, Boolean throwOnError, Security Kerberos ID 4 Fehler sind im Eventlog auf dem Client und auf dem Server zu finden. Wenn noch konkrete Infos fehlen trage ich die gerne nach.
  4. Zweiter Neustart hat geholfen.
  5. Geht immer noch nicht nach diesem Update - da die Clients sehr veraltet scheinen werde ich mal generell Windows Update machen.
  6. Jap - nun hast du mich umgehauen. Danke dir !
  7. Im IE habe ich das nun angehackt und kann das auch aufrufen. Outlook zeigt noch das gleiche beim Test. Oder gibt es da auf "Outlook" ebene noch was einzustellen?
  8. Im IE lande ich auf ( siehe Bild unten) - im Firefox sehe ich die Owa Login seite ohne Zertifikatsfehler Zertifikat ist Wildcard Client ist Windows 7
  9. Ja - aber spielt das eine Rolle wenn das in den URLs auf dem Exchange nicht konfiguriert ist? Ist auch im Split DNS
  10. Ja es ist ein Proxy im einsatz auf den ich aber nur indirekt was machen kann. Ausnahmen sind definiert remote.domain.de ( im internet Explorer) Wenn ich den Proxy raus nehme bekomme ich dann nur noch den Status Code 0.
  11. Hallo Leute, ich habe hier einen Exchange 2019 mit Outlook 2016 Clients und folgendes wird mir beim Autodiscover Test Angezeigt. Ich habe via regedit ExcludeHttpsRootDomain auf 1 gesetzt, da ich sonst direkt nach dem Dienstverbindungspunkt ein 404 bekomme wenn dann die RootDomain abgefragt wird. Alle Einträge intern / extern sind auf remote.domain.de gesetzt. Split DNS ist vorhanden. Ich kann nicht nachvollziehen wieso ich kein Konto eingerichtet bekomme. Natürlich geht auch Kalender / Automapping nicht richtig, da Autodiscover nicht richtig geht. AutoDiscoverServiceInternalUri : https://remote.domain.de/Autodiscover/Autodiscover.xml Get-AutodiscoverVirtualDirectory ist leer - die anderen URLs sind alle gesetzt.
  12. Danke für den Hinweis - habe mir das Postfach wohl kaputt gemacht. Ich versuche das zu reparieren.
  13. Hallo, ich versuche gerade einen frisch Migrierten Exchange 2013 aktuellstes CU (Migriert von Exchange 2007) auf einen Exchange 2019 auf Server 2019 umzuziehen. Die ersten paar Konten konnte ich auch ohne Probleme in die neue Datenbank schieben, nun kommt aber bei allen Migration Batches folgendes: Gui sagt: Ich habe pro User eine eigene Batch und hatte die alle auf manuell starten und abschließen: Fehler: ExternallySuspendedException: Die E-Mail-Migration konnte für diesen Benutzer nicht ausgeführt werden, da das Abonnement des Migrationsdiensts extern angehalten wurde. Get-moveRequest sagt mir AutoSuspended Die Log file: 13.06.2019 21:30:28 [exchange13n] '': Verschiebungsanforderung erstellt. 13.06.2019 21:30:42 [exchange] Der Microsoft Exchange-Postfachreplikationsdienst 'exchange.domain.local' (15.2.330.5 caps:3FFFFF) überprüft die Anforderung. 13.06.2019 21:30:42 [exchange] Verbunden mit Zielpostfach '49c9d92f-c828-4647-9bba-027a9867f9a1 (Primär)', Datenbank 'DB01', Postfachserver 'exchange.domain.local' Version 15.2 (Build 330.0). 13.06.2019 21:30:42 [exchange] Der Synchronisierungsstatus für die Anforderung "c115fa23-5d67-4262-9a5e-c1e40eef786c" ist null. 13.06.2019 21:30:43 [exchange] Verbunden mit Quellpostfach '49c9d92f-c828-4647-9bba-027a9867f9a1 (Primär)', Datenbank 'Mailbox Database 1106514788', Postfaschserver 'exchange13n.domain.local' Version 15.0 (Build 1473.0), Proxyserver 'exchange13n.domain.local' 15.0.1473.3 caps:0400001F7FFFFFCB07FFFF. 13.06.2019 21:30:43 [exchange] Die Anforderungsverarbeitung wurde gestartet. 13.06.2019 21:30:43 [exchange] Quellpostfachinformationen: Reguläre Elemente: 14695, 2.014 GB (2,162,007,916 bytes) Regulär gelöschte Elemente: 0, 0 B (0 bytes) FAI-Elemente: 64, 2.567 MB (2,691,630 bytes) Gelöschte FAI-Elemente: 0, 0 B (0 bytes) 13.06.2019 21:30:43 [exchange] Der Synchronisierungsstatus für die Anforderung "49c9d92f-c828-4647-9bba-027a9867f9a1" wurde wegen "CleanupOrphanedMailbox" gelöscht. 13.06.2019 21:30:43 [exchange] Eine alte Kopie des Postfachs wurde aus der Zieldatenbank entfernt. Der Vorgang wird in 30 Sekunden wiederholt. 13.06.2019 21:31:13 [exchange] Die Postfachsignatur wird für Postfach '49c9d92f-c828-4647-9bba-027a9867f9a1 (Primär)' nicht beibehalten. Outlook-Clients müssen für den Zugriff auf das verschobene Postfach neu gestartet werden. 13.06.2019 21:31:13 [exchange] Phase: CreatingFolderHierarchy. Prozent abgeschlossen: 10. 13.06.2019 21:31:13 [exchange] Die Ordnerhierarchie aus Postfach '49c9d92f-c828-4647-9bba-027a9867f9a1 (Primär)' wird initialisiert: 78 Ordner gesamt. 13.06.2019 21:31:13 [exchange] Fortschritt bei der Ordnererstellung: 0 Ordner in Postfach '49c9d92f-c828-4647-9bba-027a9867f9a1 (Primär)' erstellt. 13.06.2019 21:31:15 [exchange] Ordnerhierarchie für Postfach '49c9d92f-c828-4647-9bba-027a9867f9a1 (Primär)' initialisiert: 77 Ordner erstellt. 13.06.2019 21:31:15 [exchange] Phase: CreatingFolderHierarchy. Prozent abgeschlossen: 10. 13.06.2019 21:31:15 [exchange] Phase: CreatingInitialSyncCheckpoint. Prozent abgeschlossen: 15. 13.06.2019 21:31:15 [exchange] Fortschritt für anfänglichen Synchronisierungsprüfpunkt: 0/78 Ordner verarbeitet. Gegenwärtig wird das Postfach '49c9d92f-c828-4647-9bba-027a9867f9a1 (Primär)' abgeschlossen. 13.06.2019 21:31:16 [exchange] Anfänglicher Synchronisierungsprüfpunkt abgeschlossen: 73 Ordner verarbeitet. 13.06.2019 21:31:16 [exchange] Phase: LoadingMessages. Prozent abgeschlossen: 20. 13.06.2019 21:31:16 [exchange] Phase: LoadingMessages. Prozent abgeschlossen: 20. 13.06.2019 21:41:06 [exchange] Das Kopieren der Nachrichten ist abgeschlossen. Regeln und Sicherheitsbeschreibungen werden kopiert. 13.06.2019 21:41:08 [exchange] Anfängliches Seeding abgeschlossen, 14757 Elemente kopiert, Gesamtgröße 2.013 GB (2,161,928,977 bytes). 13.06.2019 21:41:08 [exchange] Phase: CopyingMessages. Prozent abgeschlossen: 95. 13.06.2019 21:41:08 [exchange] Kopierstatus: Vorgang für 14757/14757 Nachrichten, 2.013 GB (2,161,928,977 bytes)/2.013 GB (2,161,928,977 bytes), 73/78 Ordner abgeschlossen. 13.06.2019 21:41:08 [exchange] Änderungen an der Ordnerhierarchie in Quelle '49c9d92f-c828-4647-9bba-027a9867f9a1 (Primär)' gemeldet: 0 geänderte Ordner, 0 gelöschte Ordner. 13.06.2019 21:41:08 [exchange] Gesamtzahl der auf das Postfach "49c9d92f-c828-4647-9bba-027a9867f9a1 (Primär)" angewendeten Änderungen: Neu 0, Geändert 0, Gelöscht 0, Gelesen 0, Ungelesen 0, Elementaktualisierungen 0, Übersprungen 0, Gesamt 0. 13.06.2019 21:41:08 [exchange] Inkrementelle Synchronisierung '49c9d92f-c828-4647-9bba-027a9867f9a1 (Primär)' abgeschlossen: 0 Hierarchieaktualisierungen, 0 Inhaltsänderungen. 13.06.2019 21:41:08 [exchange] Phase: IncrementalSync. Prozent abgeschlossen: 95. 13.06.2019 21:41:08 [exchange] Auftrag wird automatisch angehalten. Für mich sieht das alles gut aus, außer dass die GUI sagt fehler. Ist das einfach ein Fehler auf der GUI und es ist alles gut und ich kann die Postfächer einfach abschließen ohne einen Datenverlust zu beführchten?
  14. Habe gerade auch im Virtual Server so ziemlich alles abgestellt an Atuh und Relay für jedermann erlaubt und das macht keinen unterschied. Da ich via Telnet den Kram los werden ohne Auth denke ich mal, dass das Problem es im Virutal Server liegt. Tante Edit: Oh nun geht es doch. Hatte auch in den Sicherheitsrechten Relay erlaubt und auch gruppe jeder hinzugefügt. Juhu. Übringes noch eine kurze Frage. Geht das auch bei Exchange 2003 / 2010 Coexist, dass der Exchange 2010 den Relay für alles macht? OWA, Active-Sync? Etc?
  15. Setup hat den nicht automatisch erstellt habe den wie in der Anleitung via Powershell erstellt. New-RoutingGroupConnector -Name „MigrationConnector“ -SourceTransportServers „FWEX2010.frankysweb.local“ -TargetTransportServers „FWEX2003.frankysweb.local“ -Cost 100 -Bidirectional $true Das ganze scheint irgendwie am Exchange 2010 abgelehnt zu werden. Event ID 7004 Dies ist ein Fehlerprotokoll des SMTP-Protokolls für den virtuellen Server mit ID 1, Verbindung #40. Remotehost '192.168.1.1' hat auf den SMTP-Befehl 'mail' mit '530 5.7.1 Client was not authenticated ' geantwortet. Der vollständige gesendete Befehl lautete 'MAIL FROM:<user@domain.de> SIZE=4412 '. Hierdurch wird die Verbindung wahrscheinlich fehlschlagen.
  16. Ja, der Exchange hat einen Smarthost und sendet die Mails nicht direkt via DNS raus. Der Smarthost ist aber im SmallBusiness-SMTP Connector drin und nicht im Virtuellen Standardserver für SMTP. Die Mails landen wohl auch in der Warteschlange Migrationsconnector ( Routinggruppenconnector). Generell sieht die Struktur anders aus als bei Franky in der Aneitung ( weil es ein SBS ist?)
  17. Hallo Zusammen, ich muss noch einenalten Exchange 2003 nach Exchange 2010 migrieren. Exchange 2010 ist installiert nach Frankys Anleitung Mail Exchange 2010 --> 2003 geht Mail Exchange 2010 --> Exetern geht Mail Exchange 2003 --> 2010 Geht nicht --> Fehler siehe unten Habe schon auf dem Exchange 2010 einen eigenen Receive Connector angelegt, der Mails von dem Exchange 2003 annehmen soll. Die IP dort eingetragen und auch Anonymos via Powershell auf den Connector erlaubt. Habe auch so ziemlich alle Kombinationen der Authentifizierungseisntellungen durch, die Mails bleiben einfach auf dem Exchange 2003 in der Warteschlange "SMTP Protokollfehler" Nutzer bekommt folgende meldung zurück: Sie sind nicht berechtigt, Nachrichten an diesen Empfänger zu senden. Wenden Sie sich an den Systemadministrator. <domain.de #5.7.1 smtp;530 5.7.1 Client was not authenticated> Via Telnet / Putty bekomme ich eine Mail von alten Exchange zum neuen rüber. https://www.frankysweb.de/exchange-2010-migration-von-exchange-2003-zu-exchange-2010/ John
  18. Mit neu angelegten Benutzern auf dem Exchange2010 und dann migriert ist das Problem auch nicht nachvollziehbar. Ist vielleicht eine Altlast an AD Objekten?
  19. Jap ,ist mir bekannt. Aber wenn ich den Befehl gegen ein auf dem Exchange 2016 erstellten Postfach laufen lasse geht alles und das bleibt auch ohne $ Zeichen. Ist das einzige was ich momentan als unterschied feststellen kann und das die anderen Konten halt migriert sind. Alle Konten neu anzulegen wo man Rechtetechnisch via Powershell dran muss wäre nun ziemlich blöde... @kamikatze Ich kenne Kunden in größe von 75 Leuten wo ich momentan von einem SBS 2003 migirere. John
  20. So nun ist es doch ein Problem. Es lässt sich reproduzieren, dass neu angelegte Postfächer auf dem neuen Exchange sich über Vollzugriff einrichten lassen. Bei migrierten Postfächern jedoch leider nicht. Rechte werden mit folgendem Befehl vergeben: Add-MailboxPermission -Identity USER1 -User USER2 -AccessRights FullAccess -InheritanceType All Wenn ich die Rechte durch die Powershell hinzufügen dann sieht man in der Exchange 2010 Konsole User2$ und nicht nur User2. Wenn ich Rechte via GUI am Exchange 2010 vergebe, dann kommt dieses $ Zeichen nicht. Bin nicht sicher, ob da ein Zusammenhang besteht. Outlook Version 2010 14.0.7184.5000 32 Bit Exchange 2010 aktuell für Migration Exchange 2016 gepatched Exchange 2016 CU 12 aktuell
  21. Habe es gerade nochmal getestet und es scheint zu gehen - mit der Begrenzung, dass ich bei der Einrichtung sagt "Admin hat eine Änderung durchgeführt". Die Meldung kommt jedoch nur bei der Einrichtung. Werde das noch beobachten - scheint dann eventuell auch kein generelles Problem zu sein. Danke soweit John
  22. Bisher nur Outlook 2010. Outlook 2016 Rollout kommt noch.
  23. Das weiß ich auch - verstehe nur nicht wieso das Einbinden des Postfachs aufeinmal probleme macht. John
  24. Hallo Leute, folgendes Szenario: Exchange 2010 ( CAS / DB Server) - Outlook 2010 User A hat ein Postfach - User B,C etc. hat kein eigenes Postfach. In Exchange 2010 konnte man User B,C via GUI auch SendenAls und Vollzugriffsrechte auf das Postfach von User A geben. Das wurde bisher auch verwendet damit dann User B,C ein Outlook Profil einrichten konnten und dann das Postfach von User A ganz normal verwenden. Durch die Vollzugriffsrechte muss der Benutzer B oder C nicht mal ein Passwort eingeben um das Postfach einzurichten, da diese ja Vollzugriffsrechte haben und das dann quasi mit Ihren eigenen Zugangsdaten einrichten können. Nun wird zu Exchange 2016 ( Kemp + DB Server) mit Outlook 2010 migriert. Wenn die Nutzer A,B,C migriert sind scheint erst mal alles wie gehabt zu funktionieren. Wenn man die Berechtigung SendenAls oder Vollzugriff jedoch entfernt können die Rechte via GUI nicht mehr gesetzt werden. Im Exchange 2016 tauchen in der GUI Benutzer ohne Postfach gar nicht auf um dann z.B. User B oder C Vollzugriff auf das Postfach von User A zu vergeben. Die Vergabe der Rechte bekomme ich via Powershell soweit hin, jedoch lässt sich das Postfach von User A als Benutzer B nicht einrichten. Es kommt ein Passwortpopup welches nicht weg geht, egal ob ich Zugangsdaten von User A oder von User B eintrage. Ist das ganze unter Exchange 2016 noch so möglich wie es unter Exchange 2010 gemacht wurde? Hat einer eine Idee? Wie sieht das ganze unter Outlook 2016 aus? Gruß John
  25. Wenn der Benutzer auf dem Exchange 2016 keine interne Mails empfangen kann aber versenden, dann würde ich den Empfangsconnector prüfen. Gehe ich richtig in der Annahme, dass die Mails auch noch auf dem alten Exchange in der Warteschlange zu sehen sind?
×
×
  • Neu erstellen...