Condividi tramite

Note sulla versione di Exchange 2013

  • Articolo

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:

  • Installazione e distribuzione

  • Exchange Management Shell

  • Cassetta postale

  • Cartelle pubbliche

  • Flusso di posta

  • Connettività del client

  • Coesistenza di Exchange 2010

Installazione e distribuzione

  • msExchProductId non riflette la versione di versione di Exchange 2013 installata Dopo che Exchange estende lo schema di Active Directory e prepara Active Directory per Exchange, vengono aggiornate diverse proprietà per indicare che la preparazione è completa. Una di queste proprietà è msExchangeProductId nel CN=<your organization>, CN=Microsoft Exchange, CN=Services, CN=Configuration, DC=<domain> contenitore nel contesto di Configuration denominazione. Se non vengono introdotte modifiche allo schema di Active Directory nella versione di Exchange 2013 che si sta installando, questa proprietà non verrà aggiornata o potrebbe mostrare un valore imprevisto. Ciò potrebbe causare confusione se il valore non corrisponde alla versione di Exchange 2013 installata.

    Questo comportamento è previsto perché il valore di msExchProductId non riflette la versione di Exchange 2013 installata. Questa proprietà riflette la versione di Exchange 2013 che ha apportato le ultime modifiche allo schema di Active Directory. Per evitare confusione, è consigliabile seguire la procedura descritta nella sezione Come si sa che ha funzionato? di Preparare Active Directory e domini per verificare che Active Directory sia stato aggiornato ed è pronto per la versione di Exchange 2013 che si sta installando.

  • Il programma di installazione richiede erroneamente .NET Framework 4.0: se si tenta di installare Exchange 2013 senza .NET Framework installato nel computer, il programma di installazione richiede erroneamente l'installazione di .NET Framework 4.0 quando, di fatto, è 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 XML di Exchange vengono sovrascritti durante l'installazione dell'aggiornamento cumulativo: tutte le impostazioni personalizzate di Exchange o Internet Information Server per server eseguite nei file di configurazione dell'applicazione XML di Exchange, ad esempio web.config file nei server Accesso client o nel file EdgeTransport.exe.config nei server Cassette postali, verranno sovrascritte quando si installa un aggiornamento cumulativo di Exchange o un Service Pack. Salvare queste informazioni in modo da poter facilmente riconfigurare il server dopo l'installazione. È necessario riconfigurare queste impostazioni dopo aver installato un aggiornamento cumulativo di Exchange o un Service Pack.

  • 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 altre informazioni su come installare Exchange 2013, vedere Pianificazione e distribuzione.

Exchange Management Shell

  • Shell carica in modo imprevisto i cmdlet di Exchange 2007 o Exchange 2010 In precedenza, l'apertura della shell in un server Exchange 2013 comportava l'apertura di una connessione alla shell al server locale o a un altro server che esegue Exchange 2013. Quando viene stabilita la connessione, vengono caricati i cmdlet di Exchange 2013. A partire da Exchange 2013 CU11, shell si connetterà al server Exchange in cui si trova la cassetta postale dell'utente connesso. Se l'utente connesso non dispone di una cassetta postale, shell si connetterà al server in cui si trova la cassetta postale di arbitrato 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 arbitrato se l'utente non dispone di una cassetta postale) si trova in un server Exchange 2010, shell si connetterà a tale server e caricherà i cmdlet di Exchange 2010. Ciò 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 è di progettazione. 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 arbitrato SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c} in un server Exchange 2013.

    Per informazioni dettagliate su come spostare la cassetta postale di arbitrato, vedere Exchange Management Shell e ancoraggio delle cassette postali 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 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 delle cassette postali durante la migrazione dalle 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 del 30% al 40%. Lo spazio su disco usato dal database delle cassette postali non è aumentato, ma solo l'attribuzione dello spazio usato da ogni cassetta postale è aumentata. L'aumento delle dimensioni delle cassette postali è 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 può causare il superamento delle quote di dimensioni delle cassette postali da parte di alcuni utenti quando la cassetta postale viene spostata in Exchange 2013.

    Per evitare che gli utenti superino le quote di dimensioni delle cassette postali, aumentare i valori di quota del database o della cassetta postale in base al nuovo calcolo della quota. Per configurare i valori di quota del database o della cassetta postale, usare rispettivamente i parametri IssueWarningQuota, ProhibitSendQuota e ProhibitSendReceiveQuota nei cmdlet Set-MailboxDatabase e Set-Mailbox .

  • I client di 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 di Outlook 2007 e Outlook 2010 potrebbero non essere in grado di scaricare la Rubrica offline.

    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 esistente di Exchange 2007 o Exchange 2010 potrebbe causare il download di una nuova copia della rubrica offline da parte di tutti i client dell'organizzazione, con conseguente saturazione della rete e problemi 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 scaricheranno la nuova rubrica offline predefinita.

    Per impedire ai client di scaricare una nuova copia della rubrica offline quando è installato Exchange 2013, 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 non responsabile della rubrica offline richiesta: exchange 2013 CU5 e CU successive hanno modificato il modo in cui gli OAB sono collegati alle cassette postali di generazione della rubrica offline. Questa modifica consente a un utente di essere instradato a una cassetta postale di generazione della rubrica offline che non è responsabile della rubrica offline richiesta dall'utente. Ciò può verificarsi se tutti gli elementi seguenti sono veri:

    • Nell'organizzazione sono presenti più cassette postali di generazione della rubrica offline.

    • È possibile aggiornare i server Cassette postali che ospitano le cassette postali di generazione della Rubrica offline prima di aggiornare i server Accesso client.

    • Si sta 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 eseguono una versione precedente a CU5.

    Per risolvere questo problema, assicurarsi di aggiornare i server Accesso client a Exchange 2013 CU6 o versioni successive prima di aggiornare i server Cassette postali. In questo modo, i server Accesso client sapranno come inviare le richieste alla cassetta postale di generazione della Rubrica offline responsabile della generazione della rubrica offline dell'utente.

    Per altre 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 a cartelle pubbliche abilitate per la posta elettronica: prima di Exchange 2013 CU6, i mittenti non autorizzati potevano inviare messaggi a cartelle pubbliche abilitate per la posta elettronica. Ciò ha consentito ai mittenti esterni di inviare posta a cartelle pubbliche abilitate per la posta, indipendentemente dalle autorizzazioni impostate nella cartella pubblica.

    A partire da Exchange 2013 CU6, se si desidera che i mittenti esterni inviino messaggi a cartelle pubbliche abilitate per la posta elettronica, all'utente anonimo deve essere concessa almeno l'autorizzazione Crea elementi . Se sono state configurate cartelle pubbliche abilitate per la posta elettronica e non è stata eseguita questa operazione, i mittenti esterni riceveranno una notifica di errore di recapito e i messaggi non verranno recapitati alla cartella pubblica abilitata per la 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 altre informazioni sulla migrazione di cartelle pubbliche, vedere Usare la migrazione batch per eseguire la migrazione di cartelle pubbliche a Exchange 2013 da versioni precedenti.

Flusso di posta

  • I cmdlet TransportAgent nei server Accesso client richiedono Windows PowerShell locali: esiste un problema con i cmdlet *-TransportAgent che impedisce l'installazione, la disinstallazione e la gestione degli agenti di trasporto nei server Accesso client tramite Exchange Management Shell. Per installare, disinstallare e gestire gli agenti di trasporto nei server Accesso client, è necessario caricare manualmente lo snap-in Exchange Windows PowerShell e quindi eseguire i cmdlet *-TransportAgent. Se si tenta di installare, disinstallare o gestire gli agenti di trasporto usando 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 nei server Accesso client, eseguire le operazioni seguenti nel server Accesso client che si desidera gestire:

    Avviso

    Il caricamento dello Microsoft.Exchange.Management.PowerShell.SnapIn snap-in 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. Non è supportata la modifica degli elenchi di controllo di accesso (ACL) in file, directory o oggetti di Active Directory di Exchange.

    Importante

    Eseguire la procedura seguente solo nei server Accesso client. Non è necessario caricare lo snap-in exchange Windows PowerShell se si desidera gestire gli agenti di trasporto nei server Cassette postali.

    1. Aprire una nuova finestra 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 aggiunti a un dominio: l'autenticazione tra un client, ad esempio Windows Live Mail ed Exchange 2013, potrebbe non riuscire quando si verificano le condizioni seguenti:

    • Il metodo di autenticazione usato dal client è QUINDI NTLM.

    • Il computer non è aggiunto al dominio.

    Per risolvere 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 a Autenticazione di base su TLS.

  • L'autenticazione GSSAPI non riesce se usata con il cmdlet Send-MailMessage: l'autenticazione GSSAPI (Generic Security Service Application Program Interface) potrebbe non riuscire quando viene usato il cmdlet Send-MailMessage, incluso nelle installazioni predefinite di Windows PowerShell, per inviare posta autenticata a Exchange 2013. In questo caso, verrà visualizzata una voce nel registro eventi dell'applicazione nel server Accesso client di Exchange 2013 che ha ricevuto la connessione con le informazioni seguenti:

    • 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 nei server Accesso client di Exchange 2013. Per rimuovere il Integrated metodo di autenticazione da un connettore di ricezione client, eseguire il comando seguente in 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

  • MapI su HTTP potrebbe riscontrare prestazioni 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 tramite il protocollo potrebbero riscontrare prestazioni scarse. Questo perché 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

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

    Per risolvere questo problema, eseguire le operazioni seguenti:

    1. Nei server che eseguono il ruolo del server Accesso client eseguire i comandi seguenti in un 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 in un 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 quando vengono sottoposte a proxy tramite 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 l'installazione di rollup degli aggiornamenti potrebbe non funzionare correttamente e viene 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 usando uno dei metodi seguenti:

      • L'opzione Apri un'altra cassetta postale in Outlook Web App -OR-

      • Opzione Altro utente nell'interfaccia di amministrazione di Exchange

      • Il server Accesso client a cui l'utente connesso esegue Exchange 2013.

      • Il server Accesso client di Exchange 2010 è stato aggiornato a Exchange 2010 SP3 dalla versione di produzione (RTM) di Exchange 2010 o a 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 Outlook Web App di Exchange 2010 dell'altro utente e potrebbe essere visualizzata una pagina vuota.

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