dr_wahnsinnig

Erledigt, danke!

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

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... Jo, Suche funktioniert wieder! Vielen Dank für die schnelle Hilfe!

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

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

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?

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.

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.

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.

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

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

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.

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

IMAPS: Brauchst Du weitere Konfigurationen?

Transparency - ja, stimmt... 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