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.