I messaggi di posta elettronica inviati dall'ambiente locale a Exchange Online sembrano essere esterni dopo l'esecuzione di HCW

Articolo
01/24/2024
Si applica a:

Exchange Server 2013 Standard Edition, Exchange Server 2013 Enterprise Edition, Exchange Server 2016 Standard Edition, Exchange Server 2016 Enterprise Edition

Numero KB originale: 4052493

Sintomi

Considerare lo scenario descritto di seguito:

La Configurazione guidata ibrida viene eseguita in un ambiente Exchange Server 2016 o Exchange Server 2013 che include un server Perimetrale.
Un utente invia un messaggio di posta elettronica da Exchange locale all'account Exchange Online di un altro utente. Entrambi gli utenti si trovano nell'organizzazione.

In questo scenario si notano i problemi seguenti sul lato ricevitore:

Il messaggio sembra essere esterno.
Il mittente non si risolve in un destinatario nell'elenco indirizzi globale.The sender doesn't resolve to a recipient in the global address list (GAL).

Sintomi aggiuntivi quando si verifica il problema:

Esiste un attributo Outbound to Office 365TLSCertificateName nel connettore send che invia messaggi a Microsoft 365. Quando si verifica il problema, il valore dell'attributo non viene replicato nei server Perimetrali.
Quando si esegue il start-edgesynchronization comando dal server cassette postali, l'output mostra il tipo di configurazionecome Incompleto. Di seguito è riportato un estratto di esempio:
```
RunspaceId: RunspaceId
Result: Incomplete
Type: Configuration
Name: userwap
```
L'errore seguente viene registrato nei log di EdgeSync che si trovano nella <ExchangeInstallation>\TransportRoles\Logs\EdgeSync cartella .

Date/Time.082Z,c76158dc155c4e2eab69305612c58890,689,,EdgeServerName.contoso.com,50636,SyncEngine,Low,Un valore nella richiesta non è valido. [ExDirectoryException]; Eccezione interna: un valore nella richiesta non è valido. [DirectoryOperationException],"Failed to synchronize entry CN=Outbound to 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",,,

Per abilitare i log di EdgeSync, eseguire il comando seguente:
```
Get-EdgeSyncServiceConfig | Set-EdgeSyncServiceConfig -LogLevel high -LogEnabled $true
```

Causa

Questo problema si verifica per i motivi seguenti:

Il limite è impostato su 256 per l'attributo ms-Exch-Smtp-TLS-Certificate archiviato nello schema per ADAM nei server Perimetrali.
La lunghezza della stringa seguente dal certificato di terze parti è superiore a 256 caratteri:

<I> Nomesoggetto S>autorità di certificazione<

Per determinare la lunghezza della stringa, eseguire il comando seguente:
```
("<I>$((Get-SendConnector 'outbound to Office 365').tlscertificatename.certificateissuer)<S>$((Get-SendConnector 'outbound to Office 365').tlscertificatename.certificatesubject)").length
```

Per risolvere questo problema, utilizzare uno dei seguenti metodi.

Risoluzione 1: aumentare il limite a 1024 nel server Perimetrale

Aprire una finestra di Windows PowerShell usando l'opzione Esegui come amministratore.
Installare il toolkit di amministrazione remota del server eseguendo il comando seguente:
```
Add-WindowsFeature RSAT-ADDS
```
Importare il modulo Active Directory eseguendo il comando seguente:
```
Import-Module ActiveDirectory
```

Verificare il valore del limite per l'attributo TLSCertificateName eseguendo il comando seguente:

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

Impostare il limite 1024 eseguendo il comando seguente:

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}

Nei server Trasporto HUB o Cassette postali eseguire il comando seguente per sincronizzare le modifiche al server Edge:
```
start-EdgeSynchronization
```

Risoluzione 2: Configurare l'FQDN per l'uso del connettore di invio

Configurare il connettore di invio per non usare l'attributo TLSCertificateName per specificare il certificato da usare durante la negoziazione TLS. Usare invece un FQDN per selezionare il certificato di terze parti appropriato in base alla procedura di selezione del certificato descritta in Selezione dei certificati TLS anonimi in uscita.

Per configurare il connettore di invio per l'uso del nome di dominio completo, seguire questa procedura:

Assicurarsi che il nome di dominio che verrà impostato come FQDN sia impostato come Nome soggetto o Nome alternativo soggetto del certificato di terze parti.
Impostare Il connettore di invio per l'uso del nome di dominio completo eseguendo il comando seguente. Questo comando cancella anche l'attributo TLSCertificateName .
```
Set-SendConnector "outbound to Office 365" -Fqdn "Domain Note in step 1 of option 2" -TlsCertificateName:$null
```
Nei server Trasporto HUB o Cassette postali eseguire il comando seguente per sincronizzare le modifiche al server Edge:
```
start-EdgeSynchronization
```

Risoluzione 3: usare un certificato che non causa il superamento del limite

Usare un certificato che non causa il superamento del limite. A tal fine, attenersi alla seguente procedura:

Creare un certificato in cui la stringa seguente del certificato è inferiore a 256 caratteri:

<I>Issuer<S>SubjectName
Importare il certificato.
Associare il certificato ai rispettivi servizi.
Eseguire di nuovo la Configurazione guidata ibrida per usare il nuovo certificato.

Condividi tramite