E-Mails, die von der lokalen Bereitstellung an Exchange Online gesendet wurden, scheinen nach dem Ausführen von HCW extern zu sein.

2024-07-30
Gilt für:: Exchange Server 2013 Standard Edition, Exchange Server 2013 Enterprise Edition, Exchange Server 2016 Standard Edition, Exchange Server 2016 Enterprise Edition

Ursprüngliche KB-Nummer: 4052493

Problembeschreibung

Stellen Sie sich folgendes Szenario vor:

Sie führen den Hybridkonfigurations-Assistenten für eine Exchange Server 2016- oder Exchange Server 2013-Umgebung aus, die einen Edgeserver enthält.
Ein Benutzer sendet eine E-Mail-Nachricht von Exchange lokal an das Exchange Online-Konto eines anderen Benutzers. Beide Benutzer befinden sich in Ihrer Organisation.

In diesem Szenario stellen Sie die folgenden Probleme auf der Empfängerseite fest:

Die Nachricht scheint extern zu sein.
Der Absender wird in der globalen Adressliste (GAL) nicht zu einem Empfänger aufgelöst.

Zusätzliche Symptome, wenn das Problem auftritt:

Es gibt ein "Outbound to Office 365 TLSCertificateName "-Attribut für den Sendeconnector, der Nachrichten an Microsoft 365 sendet. Wenn das Problem auftritt, wird der Attributwert nicht auf die Edgeserver repliziert.
Wenn Sie den start-edgesynchronization Befehl vom Postfachserver ausführen, zeigt die Ausgabe den Konfigurationstyp als unvollständig an. Es folgt ein Beispielauszug:
```
RunspaceId: RunspaceId
Result: Incomplete
Type: Configuration
Name: userwap
```
Der folgende Fehler wird in den EdgeSync-Protokollen protokolliert, die <ExchangeInstallation>\TransportRoles\Logs\EdgeSync sich im Ordner befinden.

Datum/Uhrzeit.082Z,c76158dc155c4e2eab69305612c58890,689,,EdgeServerName.contoso.com,50636,SyncEngine,Low,A-Wert in der Anforderung ist ungültig. [ExDirectoryException]; Innere Ausnahme: Ein Wert in der Anforderung ist ungültig. [DirectoryOperationException],"Fehler beim Synchronisieren des Eintrags CN=Ausgehend mit Office 365,CN=Connections,CN=Exchange Routing Group (DWBGZMFD01QNBJR),CN=Routing groups,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=ExchangeOrgName,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com",,,

Führen Sie den folgenden Befehl aus, um die EdgeSync-Protokolle zu aktivieren:
```
Get-EdgeSyncServiceConfig | Set-EdgeSyncServiceConfig -LogLevel high -LogEnabled $true
```

Ursache

Dieses Problem tritt aus folgenden Gründen auf:

Die Obergrenze wird für das Attribut "ms-Exch-Smtp-TLS-Certificate ", das im Schema für ADAM auf den Edgeservern gespeichert ist, auf 256 festgelegt.
Die Länge der folgenden Zeichenfolge aus dem Drittanbieterzertifikat beträgt mehr als 256 Zeichen:

<I>Issuer<S>Antragstellername

Führen Sie den folgenden Befehl aus, um die Länge der Zeichenfolge zu ermitteln:
```
("<I>$((Get-SendConnector 'outbound to Office 365').tlscertificatename.certificateissuer)<S>$((Get-SendConnector 'outbound to Office 365').tlscertificatename.certificatesubject)").length
```

Verwenden Sie eine der folgenden Methoden, um dieses Problem zu beheben.

Auflösung 1: Erhöhen der Obergrenze auf 1024 auf dem Edgeserver

Öffnen Sie ein Windows PowerShell-Fenster, indem Sie die Option "Als Administrator ausführen" verwenden.
Installieren Sie das Remoteserververwaltungs-Toolkit, indem Sie den folgenden Befehl ausführen:
```
Add-WindowsFeature RSAT-ADDS
```
Importieren Sie das Active Directory-Modul, indem Sie den folgenden Befehl ausführen:
```
Import-Module ActiveDirectory
```

Überprüfen Sie den Cap-Wert für das Attribut TLSCertificateName, indem Sie den folgenden Befehl ausführen:

Get-ADObject -Filter {name -eq "ms-Exch-Smtp-TLS-Certificate"} -SearchBase ((get-ADRootDSE -Server localhost:50389).schemaNamingContext) -Server localhost:50389 -Properties * | Select-Object rangeupper

Legen Sie die 1024-Obergrenze fest, indem Sie den folgenden Befehl ausführen:

Get-ADObject -Filter {name -eq "ms-Exch-Smtp-TLS-Certificate"} -SearchBase ((get-ADRootDSE -Server localhost:50389).schemaNamingContext) -Server localhost:50389 -Properties * | Set-ADObject -Replace @{rangeupper=1024}

Führen Sie auf den HUB-Transport- oder Postfachservern den folgenden Befehl aus, um die Änderungen mit dem Edgeserver zu synchronisieren:
```
start-EdgeSynchronization
```

Lösung 2: Konfigurieren des Sendeconnectors verwenden FQDN

Konfigurieren Sie den Sendeconnector, um das TLSCertificateName-Attribut nicht für die Angabe des Zertifikats zu verwenden, das während der TLS-Aushandlung verwendet werden soll. Verwenden Sie stattdessen einen FQDN, um das entsprechende Drittanbieterzertifikat basierend auf dem Zertifikatauswahlverfahren auszuwählen, das unter Auswahl von ausgehenden anonymen TLS-Zertifikaten beschrieben wird.

Führen Sie die folgenden Schritte aus, um den Sendeconnector für die Verwendung des FQDN zu konfigurieren:

Stellen Sie sicher, dass der Domänenname, der als FQDN festgelegt wird, als Antragstellername oder alternativer Antragstellername des Drittanbieterzertifikats festgelegt wird.
Legen Sie den Sendeconnector so fest, dass er den FQDN verwendet, indem Sie den folgenden Befehl ausführen. Mit diesem Befehl wird auch das TLSCertificateName-Attribut gelöscht.
```
Set-SendConnector "outbound to Office 365" -Fqdn "Domain Note in step 1 of option 2" -TlsCertificateName:$null
```
Führen Sie auf den HUB-Transport- oder Postfachservern den folgenden Befehl aus, um die Änderungen mit dem Edgeserver zu synchronisieren:
```
start-EdgeSynchronization
```

Lösung 3: Verwenden des Zertifikats, das nicht dazu führt, dass die Obergrenze überschritten wird

Verwenden Sie ein Zertifikat, das nicht dazu führt, dass die Obergrenze überschritten wird. Gehen Sie dazu wie folgt vor:

Erstellen Sie ein Zertifikat, in dem die folgende Zeichenfolge aus dem Zertifikat kleiner als 256 Zeichen ist:

<I>Issuer<S>SubjectName
Importieren Sie das Zertifikat.
Ordnen Sie das Zertifikat den jeweiligen Diensten zu.
Führen Sie den Hybridkonfigurations-Assistenten erneut aus, um das neue Zertifikat zu verwenden.