dr_wahnsinnig

vor 7 Minuten schrieb NilsK:

PS. möglicherweise möchtest du den Namen der Firma aus dem Screenshot entfernen.

Erledigt, danke!

vor 23 Minuten schrieb zahni:

Ich und Norbert könnten da auch einen Spezialisten empfehlen...

Moin,

wahrscheinlich den Nils, richtig?

Die PKI ist für eine Citrix-Umgebung, die eben Zertifikate für die VDIs und die Benutzer ausgibt.

Die CRLs liegen alle an der selben Stelle. für die iCA sind auch beide Locations aktuell, für die rCA eben nicht die zweite Location (siehe Anhang).

Aktuell habe ich auch keine Probleme mit der Zertifikatsverteilung. Mich stört nur die abgelaufene CRL und dass ich sie eben nicht verlängern kann.

Gruß

Andy

Moin liebes Forum,

ich verzweifle gerade daran, eine CRL auf einer CA zu aktualisieren.

Gestern sind die CRLs von beiden Locations abgelaufen und der Zertifikatsdienst hat seinen Dienst verweigert.

Ich habe dann von der offline CA eine neue erstellt und in die online CA importiert und veröffentlicht (für LDAP).

Seitdem startet auch der Zertifikatsdienst auch wieder 😅

Jetzt habe ich noch eine abgelaufene CRL von der zweiten Location (HTTP), die ich ums verrecken nicht aktualisiert bekomme.

Hat jemand einen Tipp für mich, wo ich da ansetzen muss?

Viele Grüße

Andy

vor 21 Minuten schrieb mwiederkehr:

Es scheint ein bekanntes Problem zu sein und vom Microsoft Support ist die Empfehlung, auf das Verzeichnis "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys" den folgenden Benutzern/Gruppen Vollzugriff zu erteilen: Exchange Servers, Exhange Trusted Subsystem, System, eigener Admin-Benutzer. Quelle: https://social.technet.microsoft.com/Forums/en-US/cb194ffc-3afb-4f5a-b40e-eba7a72f1e36/content-index-state-unknown-for-all-databases-on-upgraded-cu11-server?forum=Exch2016SD

 

An anderen Orten ist von C:\Users\All Users statt C:\ProgramData die Rede. Da soll man den Ordner umbenennen und zwei Dienste neu starten, sodass er neu erstellt wird: https://social.technet.microsoft.com/Forums/en-US/fbf7bcd5-2148-4db2-a596-706f70df334f/exchange-server-2019-cu3-time-out-for-test-thread?forum=Exch2019

 

Eine Ursache habe ich nichts gefunden und ich hatte das Problem auch noch nie.

Hi,

den Artikel (https://social.technet.microsoft.com/Forums/en-US/cb194ffc-3afb-4f5a-b40e-eba7a72f1e36/content-index-state-unknown-for-all-databases-on-upgraded-cu11-server?forum=Exch2016SD) hatte ich auch schon gesehen, wollte aber nicht so gerne an den Berechtigungen der MachineKeys rumfummeln.

Ich hab' mir gerade gedacht - "ach, was soll's" und habe die Berechtigungen entsprechend gesetzt und siehe da - der Status hat gewechselt zu "Crawling - The Microsoft Exchange Search Service is crawling the database."

Mal schauen...

vor 56 Minuten schrieb mwiederkehr:

Es scheint ein bekanntes Problem zu sein und vom Microsoft Support ist die Empfehlung, auf das Verzeichnis "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys" den folgenden Benutzern/Gruppen Vollzugriff zu erteilen: Exchange Servers, Exhange Trusted Subsystem, System, eigener Admin-Benutzer. Quelle: https://social.technet.microsoft.com/Forums/en-US/cb194ffc-3afb-4f5a-b40e-eba7a72f1e36/content-index-state-unknown-for-all-databases-on-upgraded-cu11-server?forum=Exch2016SD

 

An anderen Orten ist von C:\Users\All Users statt C:\ProgramData die Rede. Da soll man den Ordner umbenennen und zwei Dienste neu starten, sodass er neu erstellt wird: https://social.technet.microsoft.com/Forums/en-US/fbf7bcd5-2148-4db2-a596-706f70df334f/exchange-server-2019-cu3-time-out-for-test-thread?forum=Exch2019

 

Eine Ursache habe ich nichts gefunden und ich hatte das Problem auch noch nie.

Jo, Suche funktioniert wieder! Vielen Dank für die schnelle Hilfe!

vor 5 Minuten schrieb testperson:

Ob es die einzige Option ist sei mal dahingestellt. Ich hatte allerdings schon ein paar Fälle, wo es dann an den Support ging und unterm Strich wäre ein neuer Exchange deutlich schneller erledigt gewesen. In zwei Fällen war letztlich ein neuer Exchange dann auch der Vorschlag von MS.

Ja, das fürchte ich auch. Es sei denn, es kommt noch jemand mit einer zündenden Idee...

vor 1 Minute schrieb testperson:

Hi,

 

wie lange hast du denn zwischendurch gewartet? Es kann "etwas" dauern, bis sich am Status was tut. Alternativ: Installiere einen weiteren Exchange Server, konfiguriere diesen, prüfen den Suchindex, verschiebe ein paar Mailboxen, beobachte den Suchindex usw. usf.

 

Gruß

Jan

Hi,

mittlerweile sind schon ein paar Stunden vergangen - keine Änderung.

Ich wollte eigentlich keinen zweiten Exchange hier installieren - aber Du könntest Recht haben, dass das die Einzige Option ist...

Moin,

ich habe ein Problem mit dem Suchindex bei einer Exchange 2016 installation seit dem letzten CU Patch (15.1.2507.13).

Die Suche in Outlook und OWA funktioniert nicht.

Der Index-Status zeigt "unknown":

Get-MailboxDatabaseCopyStatus * | sort name | Select name,status,contentindexstate,ContentIndexErrorMessage
Neue Sitzung für implizite Remotevorgänge des Befehls "Get-MailboxDatabaseCopyStatus" wird erstellt...

Name                              Status ContentIndexState ContentIndexErrorMessage
----                              ------ ----------------- ------------------------
exch_2016_db\EX2016     Dismounted           Unknown Could not find registry value of Index Status for database {0e86d73a-465e-45e2-8b19-5ea4f931180d}.
exchange_2016_db\EX2016    Mounted           Unknown Could not find registry value of Index Status for database {97392e9f-ba65-407d-be3a-cd8701df051a}.

Die DB "exch_2016_db" habe ich neu erstellt, um zu schauen, ob ich die Postfächer hierher verschieben kann. Ich erhalte hier aber die gleiche Fehlermeldung.

Ich habe schon den Index neu aufbauen lassen, indem ich die Dienste "MSExchangeFastSearch" und "HostControllerService" beendet, dann den Ordner "97392E9F-BA65-407D-BE3A-CD8701DF051A12.1.Single" aus dem DB-Verzeichnis gelöscht habe und die Dienste anschließend wieder gestartet habe.

Ebenfalls habe ich die vier Ordner aus dem Verzeichnis "D:\Exchange2016\Bin\Search\Ceres\HostController\Data\Nodes\Fsis" gelöscht und mit dem Script "D:\Exchange2016\Bin\Search\Ceres\Installer\installconfig.ps1" und den Parametern "-action I -dataFolder D:\Exchange2016\Bin\Search\Ceres\HostController\Data" neu erstellen lassen. Ergebnis: "Successfully configured Search Foundation for Exchange".

Dennoch erhalte ich unverändert die oben genannten Fehlermeldungen für den Suchindex und die Suche ist nach wie vor nicht verfügbar.

Im Eventlog sehe ich kurz nach dem Start des Suchdienstes Meldungen mit der ID 1010:

An operation attempted against a FAST endpoint exprienced an exception. This operation may be retried. Error details: Microsoft.Exchange.Search.Fast.PerformingFastOperationException: An Exception was received during a FAST operation. ---> System.ServiceModel.CommunicationException: Die Socketverbindung wurde abgebrochen. Dies kann durch einen Fehler beim Verarbeiten der Nachricht, durch ein �berschreiten des Empfangstimeouts durch den Remotehost oder durch eine Problem bei der zugrundeliegenden Netzwerkressource verursacht sein. Lokaler Sockettimeout: "00:00:59.9980020". ---> System.IO.IOException: Fehler bei Schreibvorgang, siehe interne Ausnahme. ---> System.ServiceModel.CommunicationException: Die Socketverbindung wurde abgebrochen. Dies kann durch einen Fehler beim Verarbeiten der Nachricht, durch ein �berschreiten des Empfangstimeouts durch den Remotehost oder durch eine Problem bei der zugrundeliegenden Netzwerkressource verursacht sein. Lokaler Sockettimeout: "00:00:59.9980020". ---> System.Net.Sockets.SocketException: Eine vorhandene Verbindung wurde vom Remotehost geschlossen
   bei System.ServiceModel.Channels.SocketConnection.Write(Byte[] buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout)
   --- Ende der internen Ausnahmestapel�berwachung ---
   bei System.ServiceModel.Channels.SocketConnection.Write(Byte[] buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout)
   bei System.ServiceModel.Channels.BufferedConnection.WriteNow(Byte[] buffer, Int32 offset, Int32 size, TimeSpan timeout, BufferManager bufferManager)
   bei System.ServiceModel.Channels.BufferedConnection.Write(Byte[] buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout)
   bei System.ServiceModel.Channels.ConnectionStream.Write(Byte[] buffer, Int32 offset, Int32 count)
   bei System.Net.Security.NegotiateStream.StartWriting(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
   bei System.Net.Security.NegotiateStream.ProcessWrite(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
   --- Ende der internen Ausnahmestapel�berwachung ---
   bei System.Net.Security.NegotiateStream.ProcessWrite(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
   bei System.Net.Security.NegotiateStream.Write(Byte[] buffer, Int32 offset, Int32 count)
   bei System.ServiceModel.Channels.StreamConnection.Write(Byte[] buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout)
   --- Ende der internen Ausnahmestapel�berwachung ---

Server stack trace: 
   bei System.ServiceModel.Channels.StreamConnection.Write(Byte[] buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout)
   bei System.ServiceModel.Channels.StreamConnection.Write(Byte[] buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout, BufferManager bufferManager)
   bei System.ServiceModel.Channels.FramingDuplexSessionChannel.OnSendCore(Message message, TimeSpan timeout)
   bei System.ServiceModel.Channels.TransportDuplexSessionChannel.OnSend(Message message, TimeSpan timeout)
   bei System.ServiceModel.Channels.OutputChannel.Send(Message message, TimeSpan timeout)
   bei System.ServiceModel.Dispatcher.DuplexChannelBinder.Request(Message message, TimeSpan timeout)
   bei System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
   bei System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
   bei System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]: 
   bei System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   bei System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   bei Microsoft.Ceres.ContentEngine.Admin.FlowService.IFlowServiceManagementAgent.GetFlows()
   bei Microsoft.Exchange.Search.Fast.FastManagementClient.PerformFastOperation[TManagementAgent,TResult](AgentHandle`1 agentHandle, Func`2 function, String eventLogKey)
   --- Ende der internen Ausnahmestapel�berwachung ---

und

An operation attempted against a FAST endpoint exprienced an exception. This operation may be retried. Error details: Microsoft.Exchange.Search.Fast.PerformingFastOperationException: An Exception was received during a FAST operation. ---> System.ServiceModel.FaultException: error CS1548: Cryptographic failure while signing assembly 'c:\Windows\Temp\jaholmyt.3d1\Microsoft.Exchange.Search.Writer.109.dll' -- 'Fehler beim Signieren der Assembly -- Unbekannter Fehler (8013141c).'


Server stack trace: 
   bei System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc)
   bei System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
   bei System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
   bei System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]: 
   bei System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   bei System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   bei Microsoft.Ceres.ContentEngine.Admin.FlowService.IFlowServiceManagementAgent.PutFlow(String name, String serializedFlow)
   bei Microsoft.Exchange.Search.Fast.FastManagementClient.AgentHandle`1.<>c__DisplayClass6_0.<PerformOperation>b__0(TManagementAgent agent)
   bei Microsoft.Exchange.Search.Fast.FastManagementClient.PerformFastOperation[TManagementAgent,TResult](AgentHandle`1 agentHandle, Func`2 function, String eventLogKey)

Ich weiß nicht, wo ich hier noch ansetzen soll.

Hat jemand eine Idee?

Viele Grüße

Andy

vor 5 Minuten schrieb testperson:

Hi,

 

was hast du denn jetzt am Ende überhaupt vor bzw. was willst du erreichen und wo gibt es welches Problem? Je nachdem ist Autodiscover per http-Redirect dann eh eine schlechte Idee.

 

Gruß

Jan

Ich möchte Postfächer von diesem Exchange Server auf einen anderen Exchange Server in einer anderen Gesamtstruktur (Cross-Forest) migrieren.

Wie NorbertFe in diesem Thread erwähnt hat, habe ich nun die Adresse redirect.domain.de ausschließlich auf Port 80 eingerichtet, hier eine Weiterleitung auf mobil.domain.de konfiguriert und jetzt funkt auch der Connectivity Test.

Weshalb ich die Anstrengungen überhaupt angestellt habe ist, dass ich folgende Fehlermeldung bekomme, wenn ich versuche den Migrationsendpunkt des Exchange Servers zu erreichen:

Test-MigrationServerAvailability -ExchangeRemoteMove -Autodiscover -EmailAddress testuser@maildomain.de -Credentials (Get-Credential domain\testuser)


RunspaceId         : c1530c09-f0f9-4961-a228-e9541d986c6f
Result             : Failed
Message            : Konfigurationsfehler bei AutoErmittlung: Der Migrationsdienst konnte den Migrationsendpunkt nicht mithilfe des AutoErmittlungsdiensts ermitteln.
                     Verwenden Sie ggf. die Exchange-Remoteverbindungsuntersuchung (https://testexchangeconnectivity.com) für die Diagnose von Konnektivitätsproblemen.
ConnectionSettings :
SupportsCutover    : False
ErrorDetail        : internal error:Microsoft.Exchange.Migration.AutoDiscoverFailedConfigurationErrorException: Konfigurationsfehler bei AutoErmittlung: Der
                     Migrationsdienst konnte den Migrationsendpunkt nicht mithilfe des AutoErmittlungsdiensts ermitteln. Verwenden Sie ggf. die
                     Exchange-Remoteverbindungsuntersuchung (https://testexchangeconnectivity.com) für die Diagnose von Konnektivitätsproblemen.
                        bei Microsoft.Exchange.Migration.DataAccessLayer.MigrationEndpointBase.InitializeFromAutoDiscover(MigrationEndpoint presentationObject,
                     SmtpAddress emailAddress, Boolean acceptUntrustedCertificates)
                        bei
                     Microsoft.Exchange.Management.Migration.MigrationService.Endpoint.TestMigrationServerAvailability.InternalProcessExchangeRemoteMoveAutoDiscover()
IsValid            : True
Identity           :
ObjectState        : New

Dieser Test verläuft aber mittlerweile erfolgreich:

Der Migrationsendpunkt ist aktiv. Ich hatte den auch schon mehrfach de- und wieder aktiviert.

Get-webservicesVirtualDirectory | select name,mrsProxyEnabled

Name                   MRSProxyEnabled
----                   ---------------
EWS (Default Web Site)            True

Noch eine Idee?

vor 2 Stunden schrieb NorbertFe:

nein eine autodiscoverdomain lautet autodiscover.domain.tld ;) Immer.

Hast ja Recht

Die eine E-Mail Domain lautet benutzer@domain-01.de und hier gibt es eine Umleitung (CNAME) von autodiscover.domain-01.de auf mobil.domain.de. Auch bei den anderen eingerichteten E-Mail Domains verhält es sich so (domain-02.de, domain-03.de -> cname auf mobil.domain.de).  So habe ich das auch schon bei diversen anderen Installationen umgesetzt.

Die Umleitung funktioniert auch soweit. Der Test fragt erst autodiscover.domain-01.de, schaut dann nach einem redirect, findet den auch und probiert hier die XML-Datei über die unvollständige URL zu erreichen.

Wie gesagt, bei den anderen Installationen sehe ich bei diesem Test immer die komplette URL zur XML, nur bei diesem System nicht.

Ich habe jetzt auch mal übergangsweise ein Wildcard-Zertifikat installiert, damit mobil.domain.de und autodiscover.domain.de abgedeckt werden.

vor 42 Minuten schrieb NorbertFe:

Das ist wie der Name schon sagt „intern“

testconnectivity testet aber bin extern. Also wie sieht deine autodiscoverdomain aus? Die sollte auf den exchange verweisen und im Normalfall im san des verwendeten Zertifikats stehen. Deine Firewall muss dann den entsprechenden Pfad natürlich auch durchlassen.

Die Autodiscoverdomain lautet mobil.domain.de und das Zertifikat ist ausgestellt für mobil.domain.de. Wenn ich die URL https://mobil.domain.de/autodiscover/autodiscover.xml manuell in Browser eingebe, bekomme ich auch einen login Prompt.

Mir ist nur nicht klar, warum der Test die Adresse https://autodiscover.domain.de/ und nicht https://autodiscover.domain.de/autodiscover/autodiscover.xml aufruft.

Hi liebes Forum!

Ich kämpfe hier mit einem Autodiscover-Problem:

Wenn ich mit der Microsoft-Remoteverbindungsuntersuchung (https://testconnectivity.microsoft.com) die Einstellungen überprüfe, scheitert der Test bei folgendem Punkt:

Es wird versucht, dem AutoErmittlungsdienst eine POST-Anforderung zu senden, damit er URLs ggf. automatisch erkennen kann.
Beim Senden der POST-Anforderungen für die AutoErmittlung konnten keine AutoErmittlungseinstellungen abgerufen werden.

Testschritte:
Die Microsoft-Verbindungsuntersuchung versucht, eine XML-Antwort des AutoErmittlungsdiensts von URL https://autodiscover.domain.de/ für Benutzer benutzer@E-Mail-Domain.de abzurufen.
Die Microsoft-Verbindungsuntersuchung konnte keine XML-Antwort von der AutoErmittlung abrufen.

Weitere Details
Es ist eine Webausnahme aufgrund des Empfangs der Antwort „HTTP 440 - 440“ von Unknown aufgetreten.  HTTP-Antwortkopfzeilen:  request-id: ada4c049-01e9-48a8-81e7-1b005a32e7b4  X-FEServer: EX-SRV  Connection: close  Content-Length: 154  Content-Type: text/html; charset=utf-8  Date: Mon, 26 Apr 2021 09:12:50 GMT  Server: Microsoft-IIS/10.0  X-Powered-By: ASP.NET

Hier fehlt jedoch der Pfad zur XML:

https://autodiscover.domain.de/ wird aufgerufen und nicht https://autodiscover.domain.de/autodiscover/autodiscover.xml

Kann mir einer sagen, warum das so ist?

Get-ClientAccessServer | fl AutodiscoverServiceInternalUri

gibt folgendes aus:

AutoDiscoverServiceInternalUri : https://autodiscover.domain.de/Autodiscover/Autodiscover.xml

Liebe Grüße

Andy

Moin zusammen,

ich habe nach einer Cross-Forest-Migration ein Problem mit vorhandenen Terminserien in Kalendern in öffentlichen Ordnern.

Wenn der Benutzer (Neue-Domäne\Max.Mustermann) seine alte Terminserie öffnet, bekommt er die Meldung "Diese Besprechung wurde in Ihren Kalender kopiert und erhält keine Aktualisierungen. Wenden Sie sich an den Organisator, Max Mustermann, um Aktualisierungen zu erhalten".

Die X400 und X500-Adressen wurden übernommen.

Auf dem Kalender im öffentlichen Ordner hat der neue Benutzer alle alten Zugriffsrechte.

Kann ich innerhalb des Kalenders auf die Elemente ebenfalls Berechtigungen überprüfen?

Betrifft viele Benutzer mit vielen Terminserien.

Gruß

Andy

Kurzes Update:

Ich habe nun die vorhandenen Benutzer in der neuen Domäne über den Befehl Enable-MailUser E-Mail aktiviert und konnte anschließend mit dem Script Prepare-MoveRequest.ps1 weitermachen.

Die neuen Benutzer habe ich dann mit ADMT migriert.

vor 3 Stunden schrieb testperson:

Multi-Tenant / Hosting, sofern es sich hier darum handeln sollte. Für mich deutet "unterschiedliche Kunden" darauf hin.

 

Ansonsten könnte es anstelle "Verschlüsselung" am Gateway, je nachdem auch noch für eine Archivierung nötig sein "so zu routen". Natürlich kann man das auch anders lösen. Aber dafür müsste man dann die konkreten Anforderungen kennen (und nicht nur die vermeintliche Lösung ). 

 

Moin Jan,

ja, es ist ein Multi-Tenant-System. Das externe System wird auch für SPAM-Filterung, Quarantäne, AntiVirus etc. eingesetzt. Dies ist derzeit für die Kunden so nicht nutzbar.

Ich werde mir ExSBR mal anschauen.

Danke schon mal für den Input! 

Für weitere Gedanken bin ich natürlich weiterhin offen.

vor 13 Minuten schrieb Nobbyaushb:

Kurze knappe Antwort nein

Danke ?

Ich habe so etwas befürchtet.

Moin liebes Forum,

ich habe hier einen Exchange Server mit mehreren akzeptierten Domänen (unterschiedliche Kunden).

Jetzt möchte ich E-Mail, die von Domäne Kunde A an Domäne Kunde B geschickt wird, über einen Smarthost zwecks Verschlüsselung umleiten.

Die Nachricht soll also vom Exchange an den weiteren Server weitergeleitet werden, der die Nachricht verschlüsselt und wieder an den Exchange zurückschickt, damit die verschlüsselte Mail dann in das Empfänger-Postfach zugestellt werden kann.

Jetzt ist es halt so, dass Exchange die Nachricht gleich direkt zustellt, weil ihm ja der Empfänger bekannt ist.

Kann man den E-Mail-Fluss dahingehend anpassen? Ich konnte bislang in den Einstellungen nichts finden.

Die Suche brachte mich auch nur zu Szenarien, in denen auch Nachrichten innerhalb einer Domäne über einen Smarthost geschickt werden sollten.

Viele Grüße

Andy

Moin liebe Experten,

ich habe folgende Ausgangssituation:

Quelle:

- Exchange Server: Exchange 2010

- Domäne: alt.local

- Benutzernamen: Nachname

Ziel:

- Exchange Server: Exchange 2016

- Domäne: neu.local

- Benutzernamen: Nachname+ersten beiden Buchstaben vom Vornamen

Exchange Cross Forest Migrationen (von 2013/2016 nach 2019) habe ich schon erfolgreich durchgeführt. Allerdings habe ich hier immer die Benutzer 1:1 mit ADMT migriert.

Jetzt befinden sich schon Benutzer produktiv in beiden Domänen.

In der Zieldomäne soll nun ein Exchange 2016 installiert und die Postfächer entsprechend migriert werden.

Gibt es die Möglichkeit die User mittels CSV oder manuell oder wie ach immer zu mappen oder wie bekommt man hier die Zuordnung Benutzer alte Domöne <-> Benutzer neue Domäne?

Hat hier jemand Erfahrungen mit so einem Vorhaben?

Liebe Grüße

Andy

EDIT:

Ich gebe doch in dem Migrations-Skript "Prepare-MoveRequest.ps1" die -Identity (E-Mail Adresse) an und es werden daraufhin neue Benutzer angelegt.

Darüber kann ich ja den Abgleich bewerkstelligen.

Was passiert aber mit Benutzern, die bereits in der Zieldomäne vorhanden sind?

Sooo.... Ich habe jetzt einmal den Wert -EnableGSSAPIAndNTLMAuth bei den IMAPSettings auf false gesetzt und den Port 143 zusätzlich im Kemp als L4 Service eingerichtet.

Thunderbird meckert immer noch. Merkwürdig ist allerdings, dass ich auch per Telnet keine Verbindung von extern auf Port 143 bekomme.

Also habe ich im Kemp die L4 Dienste einmal alle abgerissen und die Ports 587, 143 und 993 als L7 Dienste neu Eingerichtet - et voilà, es funktioniert!

Auch wenn ich jetzt den Wert -EnableGSSAPIAndNTLMAuth bei den IMAPSettings auf true setze, läuft die Konfiguration in Thunderbird durch 

Ja, ich habe die IMAP Services auf beiden Servern neu gestartet.

Was mich jetzt nur richtig nervt ist, dass ich gar nicht sagen kann, was denn nun die Ursache war 

Aber wie immer: Vielen Dank für eure tolle und schnelle Hilfe 

Cheers

Andy

vor 1 Minute schrieb NorbertFe:

Mach mal Kerberos weg. Nimm mal "default" oder was auch immer da steht. Dein Postausgangsserver heißt andreas?

Nein der Benutzername für den Posteingangs- und Postausgangs-Servers heißt andreas 

Gerade eben schrieb NorbertFe:

Wie stellst du denn den Thunderbird ein?

Ich richte das Konto so im Screenshot gezeigt ein.
Die Adresse imap.domain.de zeigt direkt am Kemp vorbei auf den Exchange Server. Ändere ich nur die Adresse auf kemp.domain.de, funktioniert die Verbindung nicht.

Am 8.7.2020 um 13:53 schrieb NorbertFe:

One-Arm oder Two-Arm konfig?

Das ist eine Two-Arm konfig. eth0 steht im öffentlichen Netz, eth1 im Exchange Netz.

vor einer Stunde schrieb NorbertFe:

Hab grad keinen Exchange mit Kemp und IMAP in Reichweite. Kannst du mal die Konfig vom Kemp posten?

IMAPS:

Brauchst Du weitere Konfigurationen?

vor 15 Minuten schrieb NorbertFe:

Wie auch bei L4? ;)

 Transparency - ja, stimmt...

vor 14 Minuten schrieb Dukel:

Hast du das Template genutzt?

 

https://support.kemptechnologies.com/hc/en-us/articles/207896256-Microsoft-Exchange-2016#MadCap_TOC_16_2

und folgende Kapitel

 

Was hast du in Thunderbird konfiguriert?

Ja, das Template von Kemp habe ich benutzt, allerdings das für Exchange 2019.

Thunderbird habe ich manuell konfiguriert:

Adresse, Port, Benutzername, Kennwort

Nehme ich mit den konfigurierten Daten (Benutzername, Kennwort, Port) meine für den direkten Zugriff konfigurierte Adresse, meldet Thunderbird erfolg. Ändere ich dann wieder auf den Kemp - Fehler

Über diese Adresse (über den Kemp LB) realisiere ich bereits den externen Outlook, OWA, ActiveSync Zugriff auf den Exchange Server. Lediglich IMAPS und SMTP sollten jetzt hinzukommen.

Gruß

Andy

Okay, direkte Verbindung funktioniert ohne Probleme.

Ich habe nun im Kemp die Dienste IMAPS (993) und SMTP (587)  als L4 eingerichtet - Funktioniert nicht.

Fehlermeldung in Thunderbird: "Thunderbird konnte keine Einstellungen für Ihr E-Mail-Konto finden."

In den Logs auf dem Kemp (messages, warn, auth) kann ich keine Fehler bezüglich des abrufenden Clients finden.

Noch 'ne Idee wo ich da suchen kann?

Gruß

Andy