jmw

On 5/30/2024 at 3:11 PM, NorbertFe said:

Normalerweise sollten die auch $null sein. Kann man notfalls per Exchange 2010 plugin setzen/leeren.

 

https://support.microsoft.com/en-au/topic/autodiscover-event-id-1-after-installing-exchange-server-2019-cu3-or-exchange-server-2016-cu14-93850e62-4cf4-8a76-5fd4-c8ce6f032015

 

 

Und abgesehen davon bitte auf jeden Fall testen, ob ein neues Profil sauber erstellt wird, oder ob da auch falsche Werte verwendet werden. Es gibt bei solchen Umstellungen immer irgendwelchen Schwund bei den Profilumstellungen, der sich normalerweise aber im unteren einstelligen Prozenzbereich bewegt.

Danke, das waren super Hinweise!

Nach dem Aufruf von

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010

ließen sich auf dem Server direkt die InternalUrl und ExternalUrl setzen - Set-AutodicoverVirtualDirectory hat die properties wieder. Die InternalURL muss leer sein! Dann kontrolliert man mit
 

Set-AutodicoverVirtualDirectory -ExternalUrl <autodiscover-url> 

was dann unter 

https://mail.domain.tld/autodiscover/autodiscover.json/v1.0/User1@domain.tld?Protocol=Autodiscoverv1

zurückgegeben wird.

Wenn allerdings beide leer sind, dann kommt es zu dem Fehler, der in dem von dir verlinkten Support-Dokument beschrieben wird. Auf dem Server geht dann auch gar kein autodiscover mehr, im Browser angesprochen gibts 500 Fehler und das Eventlog ist voll mit Fehlern  - sieht ganz schlimm aus

Ich vermute, da hat ein M$ Cloud Programmierer ohne Ahnung von Exchange schnell mal den deprecated markierten Eintrag für sein tolles Autodiscover V2 verwendet und nun ändert das keiner mehr 

Vielen Dank und Grüße

Jan Michael

Hallo zusammen - wir migrieren gerade unsere Exchange 2016 Vdir Urls von intern addomain.local zu Split-DNS mit unser public domain.tld.

Alle VDirs sind gesetzt und funktionieren wunderbar - nur verbinden noch einige Outlooks mit der alten addomain.local. Dem liegt die Autodiscover V2 Url zugrunde, die noch die alte addomain.local zeigt.

https://mail.domain.tld/autodiscover/autodiscover.json/v1.0/User1@domain.tld?Protocol=Autodiscoverv1

{
  "Protocol": "Autodiscoverv1",
  "Url": "https://mail.addomain.local/autodiscover/autodiscover.xml"
}

Ich finde aber keine Option, auf diese Url direkt Einfluss zu nehmen.

Eigentlich würde ich erwarten, das ClientAccessServices dafür zuständig ist - ist es aber nicht, denn es ist korrekt gesetzt:

Get-ClientAccessService | ft -a Name,AutoDiscoverServiceInternalUri

Name          AutoDiscoverServiceInternalUri
----          ------------------------------
EX01          https://mail.domain.tld/Autodiscover/Autodiscover.xml

Auch das AutodiscoverVirtualDirectory, in dem internalurl und externalurl deprecated und seit 2013 gar nicht mehr änderbar sind, zeigen andere Werte.

Get-AutodiscoverVirtualDirectory | ft Identity,InternalUrl,externalurl

Identity                                      InternalUrl                                                        ExternalUrl
--------                                      -----------                                                        -----------
EX01\Autodiscover (Default Web Site)          https://autodiscover.addomain.local/Autodiscover/Autodiscover.xml  https://mail.addomain.local/Autodiscover/Autodiscover.xml

Vielleicht weiß jemand, wie die autodiscoverv1 Url für Autodiscover V2 von den Exchange Servern berechnet wird? 

Vielen Dank und Grüße!

Hallo zusammen, 

in meiner Exchange 2016 Testumgebung habe ich zwei Server in einer DAG laufen. Diese wollen allerdings nicht replizieren. Beim Versuch, eine DB Replik anzulegen, wird nur der Rumpf auf dem Partnerserver erstellt, aber die Daten werden nie repliziert. Die Meldung ist immer: A secure channel could not be established. 

Alles weitere funktioniert ganz normal.

Dr. Google konnte weiter auch nicht helfen - der Fehler scheint nicht alltäglich zu sein . Ich bin für jeden Hinweis dankbar - insbesondere auch, wie ich das tracen kann!

Test-ReplicationHealth -Server SERVER

Server          Check                      Result     Error
------          -----                      ------     -----
SERVER   ClusterService             Passed
SERVER   ReplayService              Passed
SERVER   ActiveManager              Passed
SERVER   TasksRpcListener           Passed
SERVER   TcpListener                *FAILED*   The health test of the TCP listener for the Microsoft Exchange Replication service on server 'SERVER' failed. This
                                                      server cannot participate in replication until the error is resolved. Error: An error occurred while communicating with
                                                      server 'SERVER'. Error: A secure channel could not be established.

Das DAG Netzwerk sieht so aus:

Get-DatabaseAvailabilityGroupNetwork | ft -a name,Subnets,Interfaces,*Enabled,IgnoreNetwork,Identity,isvalid

Name                    Subnets               Interfaces                                                   MapiAccessEnabled ReplicationEnabled IgnoreNetwork Identity                     IsValid
----                    -------               ----------                                                   ----------------- ------------------ ------------- --------                     -------
MapiDagNetwork          {{10.40.104.0/24,Up}} {{SERVER01,Up,10.40.104.22}, {SERVER02,Up,10.40.104.23}}                  True              False         False LAB1\MapiDagNetwork             True
ReplicationDagNetwork01 {{10.40.132.0/24,Up}} {{SERVER01,Up,10.40.132.131}, {SERVER02,Up,10.40.132.132}}               False               True         False LAB1\ReplicationDagNetwork01    True

Vielen Dank 

Jan Michael