Note sulla versione di Exchange 2013

Si applica a: Exchange Server 2013

Microsoft Exchange Server 2013. Questo argomento contiene informazioni importanti che è necessario conoscere per distribuire correttamente Exchange 2013. Si raccomanda di leggere con attenzione questo argomento prima di iniziare la distribuzione.

In questa sezione sono contenute le seguenti sezioni:

Configurazione e distribuzione
Exchange Management Shell
Cassetta postale
Cartelle pubbliche
Flusso di posta
Connettività del client
Coesistenza di Exchange 2010

Configurazione e distribuzione

msExchProductId non riflette la versione finale di Exchange 2013 installata Dopo che Exchange ha esteso lo schema di Active Directory e preparato Active Directory per Exchange, diverse proprietà vengono aggiornate per mostrare che la preparazione è stata completata. Una di queste proprietà è msExchangeProductId nel CN=<your organization>, CN=Microsoft Exchange, CN=Services, CN=Configuration, DC=<domain> contenitore nel Configuration contesto dei nomi. Se nella versione di Exchange 2013 che si sta installando non vengono introdotte modifiche dello schema di Active Directory, questa proprietà non verrà aggiornata o potrebbe mostrare un valore imprevisto. Questo potrebbe creare confusione se il valore non corrisponde alla versione di Exchange 2013 in fase di installazione.

Questo comportamento è previsto perché il valore di msExchProductId non riflette la versione di Exchange 2013 in fase di installazione. Questa proprietà riflette l'ultima versione di Exchange 2013 che ha apportato modifiche allo schema di Active Directory. Per evitare confusione, si consiglia di seguire i passaggi descritti nella sezione Come si sa che ha funzionato? di Preparare Active Directory e domini per verificare che Active Directory sia stato aggiornato e sia pronto per il rilascio di Exchange 2013 che si sta installando.
Il programma di installazione richiede in modo non corretto .NET Framework 4.0: se si tenta di installare Exchange 2013 senza .NET Framework installato nel computer, il programma di installazione richiede in modo errato l'installazione di .NET Framework 4.0 quando, in realtà, è necessario .NET Framework 4.5 o versione successiva.

Per risolvere questo problema, installare .NET Framework 4.5 o versione successiva. Non è necessario installare .NET Framework 4.0. Per un elenco completo dei prerequisiti, vedere Prerequisiti di Exchange 2013.
I file di configurazione dell'applicazione Exchange XML vengono sovrascritti durante l'installazione dell'aggiornamento cumulativo: Tutte le impostazioni personalizzate di Exchange o Internet Information Server per server definite nei file di configurazione dell'applicazione Exchange XML, ad esempio i file web.config nei server Accesso client o il file EdgeTransport.exe.config nei server Cassette postali, verranno sovrascritte quando si installa un aggiornamento cumulativo o un Service Pack di Exchange. Salvare queste informazioni in modo da poter facilmente riconfigurare il server dopo l'installazione. È necessario riconfigurare queste impostazioni dopo l'installazione di un aggiornamento cumulativo o di un Service Pack di Exchange.
L'installazione di Exchange con autorizzazioni di amministratore delegato causa errori di installazione Quando un utente membro del solo gruppo di ruoli Installazione delegata tenta di installare Exchange in un server di pre-provisioning, l'installazione ha esito negativo. Ciò accade perché il gruppo Installazione delegata non dispone delle autorizzazioni necessarie per creare e configurare determinati oggetti in Active Directory.

Per risolvere questo problema, effettuare una delle operazioni seguenti:
- Aggiungere l'utente durante l'installazione di Exchange per il gruppo di sicurezza di Active Directory Domain Admins.
- Installare Exchange utilizzando un utente membro del gruppo di ruoli Gestione organizzazione.

Per ulteriori informazioni su come installare Exchange 2013, vedere Pianificazione e distribuzione.

Exchange Management Shell

La shell carica in modo imprevisto i cmdlet di Exchange 2007 o Exchange 2010 In precedenza, l'apertura di Shell su un server Exchange 2013 comportava l'apertura di una connessione da parte di Shell al server locale o a un altro server che esegue Exchange 2013. Una volta stabilita la connessione, vengono caricati i cmdlet di Exchange 2013. A partire da Exchange 2013 CU11, Shell si connetterà al server di Exchange in cui si trova la cassetta postale dell'utente connesso. Se l'utente connesso non ha una cassetta postale, Shell si connetterà al server in cui si trova la cassetta postale di arbitraggio SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}. Il server di destinazione può essere qualsiasi versione supportata di Exchange. Ciò significa che se la cassetta postale dell'utente connesso (o la cassetta postale di arbitraggio se l'utente non dispone di una cassetta postale) si trova su un server Exchange 2010, Shell si connetterà a tale server e caricherà i cmdlet di Exchange 2010. Questo potrebbe impedire l'esecuzione di determinate attività perché i cmdlet di Exchange 2010 non possono gestire la configurazione o i server di Exchange 2013.

A partire da Exchange 2013 CU11, questo comportamento è previsto. Per assicurarsi che Shell carichi i cmdlet di Exchange 2013, spostare la cassetta postale dell'utente connesso in Exchange 2013. Se l'utente connesso non dispone di una cassetta postale, spostare la cassetta postale di arbitraggio SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c} su un server Exchange 2013.

Per informazioni dettagliate e su come spostare la cassetta postale di arbitraggio, vedere Exchange Management Shell e ancoraggio della cassetta postale nel blog del team di Exchange.

Cassetta postale

I server Cassette postali che eseguono versioni diverse di Exchange possono essere aggiunti allo stesso gruppo di disponibilità del database Il cmdlet Add-DatabaseAvailabilityGroupServer e l'interfaccia di amministrazione di Exchange consentono erroneamente l'aggiunta di un server Exchange 2013 a un gruppo di disponibilità del database (DAG) basato su Exchange 2016 e viceversa. Exchange supporta l'aggiunta di server delle cassette postali che eseguono la stesso versione, ad esempio Exchange 2013 rispetto a Exchange 2016, in un DAG. Inoltre, l'interfaccia di amministrazione di Exchange visualizza entrambi i server Exchange 2013 e Exchange 2016 nell'elenco di server che è possibile aggiungere a un DAG. Per tale motivo un amministratore potrebbe aggiungere inavvertitamente un server che esegue una versione incompatibile di Exchange a un DAG (ad esempio un server Exchange 2013 a un DAG basato su Exchange 2016).

Attualmente non esiste alcuna soluzione per questo problema. Gli amministratori devono essere molto attenti quando aggiungono un server delle cassette postali a un DAG. Aggiungere solo server Exchange 2013 a DAG basati su Exchange 2013 e solo server Exchange 2016 a DAG basati su Exchange 2016. È possibile distinguere ogni versione di Exchange osservando la colonna Versione nell'elenco di server nell'interfaccia di amministrazione di Exchange. Di seguito sono riportate le versioni del server per Exchange 2013 e Exchange 2016:
- Exchange 2013 15.0 (Build xxx.xx)
- Exchange 2016 15.1 (Build xxx.xx)
Aumento delle dimensioni della cassetta postale durante la migrazione da versioni precedenti di Exchange: quando si sposta una cassetta postale da una versione precedente di Exchange a Exchange 2013, le dimensioni della cassetta postale segnalate possono aumentare dal 30% al 40%. Lo spazio su disco utilizzato dal database delle cassette postali non è aumentato, è aumentata solo l'attribuzione dello spazio utilizzato da ciascuna cassetta postale. L'aumento delle dimensioni della cassetta postale è dovuto all'inclusione di tutte le proprietà degli elementi nei calcoli delle quote, fornendo un calcolo più accurato dello spazio utilizzato dagli elementi all'interno della cassetta postale. Questo aumento potrebbe causare il superamento delle quote di dimensione della cassetta postale da parte di alcuni utenti quando la cassetta postale viene spostata in Exchange 2013.

Per evitare che gli utenti superino le quote per le dimensioni delle cassette postali, aumentare i valori delle quote del database o delle cassette postali in base al nuovo calcolo delle quote. Per configurare i valori di quota del database o della cassetta postale, utilizzare rispettivamente i parametri IssueWarningQuota, ProhibitSendQuota e ProhibitSendReceiveQuota nei cmdlet Set-MailboxDatabase e Set-Mailbox .
I client Outlook 2007 e Outlook 2010 potrebbero non essere in grado di scaricare la Rubrica offline: Se l'URL interno della Rubrica offline non è accessibile da Internet, i client Outlook 2007 e Outlook 2010 potrebbero non essere in grado di scaricare la Rubrica fuori rete.

Per risolvere questo problema per i client Outlook 2007 e Outlook 2010, rendere accessibile l'URL interno della Rubrica offline da Internet. Outlook 2013 non è interessato da questo problema.
L'installazione di Exchange 2013 in un'organizzazione di Exchange esistente può causare il download della Rubrica offline da parte di tutti i client: L'installazione del primo server Exchange 2013 in un'organizzazione di Exchange 2007 o Exchange 2010 esistente potrebbe causare il download di una nuova copia della Rubrica offline da parte di tutti i client dell'organizzazione, con conseguenti problemi di saturazione della rete e di prestazioni del server. Questo problema si verifica perché Exchange 2013 crea una nuova Rubrica offline predefinita nell'organizzazione che sostituisce la Rubrica offline di Exchange 2007 o Exchange 2010. Le cassette postali a cui non è assegnata una Rubrica offline specifica o che si trovano in un database delle cassette postali a cui non è assegnata una Rubrica offline specifica scaricano la nuova Rubrica offline predefinita.

Per impedire ai client di scaricare una nuova copia della Rubrica offline quando Exchange 2013 è installato, assegnare una Rubrica offline a ogni cassetta postale o al database delle cassette postali in cui si trovano le cassette postali. Questa operazione deve essere eseguita prima dell'installazione di Exchange 2013 nell'organizzazione.
Gli utenti possono essere indirizzati a una cassetta postale di generazione della Rubrica offline che non è responsabile della Rubrica offline richiesta: Exchange 2013 CU5 e versioni successive CU hanno modificato il modo in cui le Rubriche offline sono collegate alle cassette postali di generazione della Rubrica offline. Questa modifica consente di indirizzare un utente a una cassetta postale di generazione della Rubrica offline che non è responsabile della Rubrica offline richiesta dall'utente. Ciò può verificarsi se tutte le condizioni seguenti sono vere:
- Nell'organizzazione sono presenti più cassette postali di generazione della Rubrica offline.
- I server Cassette postali che ospitano le cassette postali di generazione della Rubrica offline vengono aggiornati prima di aggiornare i server Accesso client.
- Si stanno aggiornando i server Exchange 2013 da una versione precedente a CU5 a una versione successiva (ad esempio, l'aggiornamento da Exchange 2013 CU3 a Exchange 2013 CU6).
- I server Accesso client stanno eseguendo una versione precedente a CU5.
Per risolvere questo problema, assicurarsi di aggiornare i server Accesso client a Exchange 2013 CU6 o versione successiva prima di aggiornare i server Cassette postali. In questo modo si verifica che i server Accesso client sappiano come inoltrare le richieste alla cassetta postale di generazione della Rubrica offline responsabile della generazione della Rubrica offline dell'utente.

Per ulteriori informazioni sulle modifiche della Rubrica offline in Exchange 2013 CU5, vedere Miglioramenti della Rubrica offline nell'aggiornamento cumulativo 5 di Exchange 2013.

Cartelle pubbliche

I mittenti non autorizzati non possono più inviare messaggi alle cartelle pubbliche abilitate alla posta elettronica: prima di Exchange 2013 CU6, i mittenti non autorizzati potevano inviare messaggi alle cartelle pubbliche abilitate alla posta elettronica. Questo consentiva ai mittenti esterni di inviare messaggi alle cartelle pubbliche abilitate alla posta elettronica, indipendentemente dalle autorizzazioni impostate per la cartella pubblica.

A partire da Exchange 2013 CU6, se si desidera che i mittenti esterni inviino posta alle cartelle pubbliche abilitate alla posta elettronica, è necessario concedere all'utente anonimo almeno l'autorizzazione Crea elementi . Se sono state configurate cartelle pubbliche abilitate alla posta elettronica e non è stata eseguita questa operazione, i mittenti esterni riceveranno una notifica di errore di recapito e i messaggi non verranno recapitati nella cartella pubblica abilitata alla posta elettronica.

È possibile utilizzare Shell o Outlook per impostare le autorizzazioni per l'utente anonimo. Per ulteriori informazioni su come impostare le autorizzazioni per l'utente anonimo, vedere Posta elettronica attiva o Disattiva posta una cartella pubblica.
Il numero massimo di cartelle pubbliche di cui è possibile eseguire la migrazione a Exchange 2013 dai server Exchange legacy è 500.000. Per ulteriori informazioni sulla migrazione delle cartelle pubbliche, vedere Utilizzare la migrazione batch per eseguire la migrazione delle cartelle pubbliche a Exchange 2013 dalle versioni precedenti.

Flusso di posta

I cmdlet TransportAgent nei server Accesso client richiedono Windows PowerShell locale: esiste un problema con i cmdlet *-TransportAgent che impedisce a tali cmdlet di installare, disinstallare e gestire gli agenti di trasporto sui server Accesso client utilizzando Exchange Management Shell. Per installare, disinstallare e gestire gli agenti di trasporto nei server Accesso client, è necessario caricare manualmente lo snap-in di Windows PowerShell di Exchange e quindi eseguire i cmdlet *-TransportAgent. Se si tenta di installare, disinstallare o gestire gli agenti di trasporto utilizzando Exchange Management Shell, le modifiche verranno applicate al server Cassette postali di Exchange 2013 a cui si è connessi.

Per installare, disinstallare o gestire gli agenti di trasporto sui server Accesso client, effettuare le seguenti operazioni sul server Accesso client che si desidera gestire:

Avviso

Il caricamento dello Microsoft.Exchange.Management.PowerShell.SnapIn snap-in di Windows PowerShell e l'esecuzione di cmdlet diversi dai cmdlet -TransportAgent non sono supportati e possono causare danni irreparabili alla distribuzione di Exchange.

È necessario essere un amministratore locale nel server Accesso client in cui si desidera installare, disinstallare o gestire gli agenti di trasporto. La modifica degli elenchi di controllo di accesso (ACL) nei file, nelle directory o negli oggetti Active Directory di Exchange non è supportata.

Importante

Eseguire la procedura seguente solo sui server Accesso client. Non è necessario caricare lo snap-in di Windows PowerShell di Exchange per gestire gli agenti di trasporto nei server Cassette postali.
1. Aprire una nuova finestra di Windows PowerShell.
2. Esegui il comando seguente:
```
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
```
3. Eseguire le attività di gestione dell'agente di trasporto come di consueto.
4. Ripetere questa procedura in ogni server Accesso client che si desidera gestire.

Connettività del client

L'autenticazione NTLM non riesce per i client non aggiunti a un dominio: l'autenticazione tra un client, ad esempio Windows Live Mail, ed Exchange 2013 potrebbe non riuscire quando si verificano le seguenti condizioni:
- Il metodo di autenticazione usato dal client è NTLM.
- Il computer non è aggiunto al dominio.
Per ovviare a questo problema, è possibile eseguire una delle operazioni seguenti:
- Aggiungere al dominio il computer in cui è in esecuzione il client.
- Modificare il tipo di autenticazione usato dal client da NTLM all'autenticazione di base su TLS.
L'autenticazione GSSAPI non riesce quando viene utilizzata con il cmdlet Send-MailMessage: L'autenticazione GSSAPI (Security Service Application Program Interface) generica potrebbe non riuscire quando il cmdlet Send-MailMessage, incluso nelle installazioni predefinite di Windows PowerShell, viene utilizzato per inviare la posta autenticata a Exchange 2013. In questo caso, viene visualizzata una voce nel registro eventi dell'applicazione nel server Accesso client di Exchange 2013 che ha ricevuto la connessione con le seguenti informazioni:
- Origine: MSExchangeFrontEndTransport
- ID evento: 1035
- Descrizione: Autenticazione in ingresso non riuscita con errore IllegalMessage per il nome> del server front-end < client del connettore di ricezione. Il meccanismo di autenticazione è Gssapi. L'indirizzo IP di origine del client che ha tentato di eseguire l'autenticazione in Exchange è [<indirizzo >IP client].
Per risolvere questo problema, è necessario rimuovere il Integrated metodo di autenticazione dal connettore di ricezione client sui server Accesso client di Exchange 2013. Per rimuovere il metodo di Integrated autenticazione da un connettore di ricezione client, eseguire il seguente comando su ogni server Accesso client di Exchange 2013 che potrebbe ricevere connessioni da computer che eseguono il cmdlet Send-MailMessage :
```
Set-ReceiveConnector "<server name>\Client Frontend <server name>" -AuthMechanism Tls, BasicAuth, BasicAuthRequireTLS
```
Le prestazioni di MAPI su HTTP potrebbero risultare scarse quando si esegue l'aggiornamento a Exchange 2013 SP1: se si esegue l'aggiornamento da un aggiornamento cumulativo di Exchange 2013 a Exchange 2013 SP1 e si abilita MAPI su HTTP, i client che si connettono a un server Exchange 2013 SP1 utilizzando il protocollo potrebbero riscontrare prestazioni scarse. Ciò è dovuto al fatto che le impostazioni necessarie non vengono configurate durante un aggiornamento da un aggiornamento cumulativo a Exchange 2013 SP1. Questo problema non si verifica se si esegue l'aggiornamento a Exchange 2013 SP1 da Exchange 2013 RTM o se si installa un nuovo server Exchange 2013 SP1 o versione successiva.

Nota

Questo è un problema solo se il protocollo MAPI su HTTP è abilitato sui server Accesso client. È disabilitato per impostazione predefinita. Se MAPI su HTTP è disabilitato, i client usano invece il protocollo RPC su HTTP.

Per risolvere il problema, eseguire le operazioni seguenti:
1. Nei server che eseguono il ruolo del server Accesso client, eseguire i comandi seguenti nel prompt dei comandi di Windows:
```
set AppCmdLocation=%windir%\System32\inetsrv
set ExchangeLocation=%ProgramFiles%\Microsoft\Exchange Server\V15

%AppCmdLocation%\appcmd.exe SET AppPool "MSExchangeMapiFrontEndAppPool" /CLRConfigFile:"%ExchangeLocation%\bin\MSExchangeMapiFrontEndAppPool_CLRConfig.config"
%AppCmdLocation%\appcmd.exe RECYCLE AppPool "MSExchangeMapiFrontEndAppPool"
```
2. Nei server che eseguono il ruolo del server Cassette postali, eseguire i comandi seguenti nel prompt dei comandi di Windows:
```
set AppCmdLocation=%windir%\System32\inetsrv
set ExchangeLocation=%ProgramFiles%\Microsoft\Exchange Server\V15

%AppCmdLocation%\appcmd.exe SET AppPool "MSExchangeMapiMailboxAppPool" /CLRConfigFile:"%ExchangeLocation%\bin\MSExchangeMapiMailboxAppPool_CLRConfig.config"
%AppCmdLocation%\appcmd.exe RECYCLE AppPool "MSExchangeMapiMailboxAppPool"

%AppCmdLocation%\appcmd.exe SET AppPool "MSExchangeMapiAddressBookAppPool" /CLRConfigFile:"%ExchangeLocation%\bin\MSExchangeMapiAddressBookAppPool_CLRConfig.config"
%AppCmdLocation%\appcmd.exe RECYCLE AppPool "MSExchangeMapiAddressBookAppPool"
```

Coesistenza di Exchange 2010

Le richieste di accesso alle cassette postali di Exchange 2010 potrebbero non funzionare tramite i server Accesso client di Exchange 2013: in alcune situazioni, la richiesta proxy tra i server Accesso client di Exchange 2013 ed Exchange 2010 Service Pack 3 (SP3) senza aggiornamenti cumulativi installati potrebbe non funzionare correttamente e potrebbe essere visualizzato un errore. Ciò può verificarsi se tutte le condizioni seguenti sono vere:
- Un utente con una cassetta postale di Exchange 2013 tenta di aprire una cassetta postale di Exchange 2010 utilizzando uno dei seguenti metodi:
  - Opzione Apri un'altra cassetta postale in Outlook Web App -OPPURE-
  - Opzione Un altro utente nell'interfaccia di amministrazione di Exchange
  - Il server Accesso client a cui l'utente si è connesso sta eseguendo Exchange 2013.
  - Il server Accesso client di Exchange 2010 è stato aggiornato a Exchange 2010 SP3 dalla versione RTM (Release to Manufacturing) di Exchange 2010 o da un Service Pack di Exchange 2010 precedente.
Se tutte le condizioni precedenti sono vere, l'utente non sarà in grado di accedere alle opzioni di Exchange 2010 Outlook Web App dell'altro utente e potrebbe apparire una pagina vuota.

Per risolvere questo problema, installare l'aggiornamento cumulativo 1 di Exchange 2010 SP3 o versione successiva su ogni server Exchange 2010.

Last updated on 2026-08-19