Esporta (0) Stampa
Espandi tutto

Note sulla versione di Exchange 2013

 

Si applica a: Exchange Server 2013

Ultima modifica dell'argomento: 2014-06-12

Microsoft Exchange Server 2013. Questo argomento contiene importanti informazioni necessarie per distribuire correttamente l'aggiornamento cumulativo 5 di Exchange 2013. Si raccomanda di leggere con attenzione questo argomento prima di iniziare la distribuzione.

In questa sezione sono contenute le seguenti sezioni:

  • L'installazione richiede erroneamente.NET Framework 4.0   Se si tenta di installare Exchange 2013 senza aver installato .NET Framework sul computer, L'installazione richiede erroneamente che si installi .NET Framework 4.0 quando, in realtà, è richiesto .NET Framework 4.5.

    Per ovviare a questo problema, installare .NET Framework 4.5. Non è necessario installare .NET Framework 4.0. Per l'elenco completo dei prerequisiti, vedere Prerequisiti di Exchange 2013.

  • I file di configurazione XML di Exchange vengono sovrascritti durante l'installazione dell'aggiornamento cumulativo   Qualsiasi impostazione personalizzata per singolo server apportata nei file di configurazione XML di Exchange, ad esempio, i file web.config sui server Accesso client oppure il file EdgeTransport.exe.config sui server Cassette postali, verrà sovrascritta quando si installa un aggiornamento cumulativo di Exchange o Service Pack. Salvare queste informazioni in modo da poter facilmente riconfigurare il server dopo l'installazione. È necessario configurare nuovamente queste impostazioni dopo aver installato l'aggiornamento cumulativo o il Service Pack di Exchange.

  • La directory virtuale MAPI non viene creata durante il ripristino del server   Quando si esegue Setup.exe con lo switch RecoverServer in un server in cui è installato il ruolo server Accesso client, la directory virtuale MAPI non viene creata. Se la directory virtuale MAPI non esiste, i client che utilizzano MAPI tramite protocollo HTTP per connettersi al server di Exchange, ad esempio Outlook, non saranno in grado di connettersi.

    NotaNota:
    È un problema solo se MAPI tramite protocollo HTTP è attivato nei server Accesso Client. È disabilitato per impostazione predefinita. Se MAPI tramite HTTP è disabilitato, i client usano il protocollo RPC tramite HTTP.

    Per risolvere il problema, attenersi alla procedura nell'articolo della Knowledge Base KB2931223 (la directory virtuale MAPI non è presente nel nodo del sito Web predefinito).

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

  • Le dimensioni delle cassette postali aumentano quando si migra dalle precedenti versioni di Exchange   Quando si sposta una cassetta postale da una versione precedente di Exchange a Exchange 2013, le dimensioni della cassetta postale riportate possono aumentare dal 30 al 40 per cento. Lo spazio su disco utilizzato dalla cassetta postale non è aumentato, è aumentata solo l'attribuzione dello spazio utilizzato da ciascuna cassetta postale. L'aumento delle dimensioni delle cassette postali è dovuto all'inserimento delle proprietà di tutti gli elementi nei calcoli della quota, fornendo un calcolo più preciso dello spazio occupato dai vari elementi all'interno della cassetta postale. Tale aumento potrebbe causare un problema ad alcuni utenti che potrebbero superare le quote previste per le dimensioni della cassetta postale quando questa viene spostata su Exchange 2013.

    Per evitare che gli utenti superino la quota prevista per le dimensioni della cassetta postale, aumentare i valore delle quote del database o della cassetta postale in modo che si adattino al calcolo delle nuove quote. Per configurare i valori delle quote della cassetta postale o del database, utilizzare i parametri IssueWarningQuota, ProhibitSendQuota e ProhibitSendReceiveQuota rispettivamente sui cmdlet Set-MailboxDatabase e Set-Mailbox.

  • I client di Outlook 2007 e Outlook 2010 potrebbero non essere in grado di scaricare la Rubrica fuori rete   Se l'URL interno della Rubrica fuori rete (OAB) non è accessibile da Internet, i client di Outlook 2007 e Outlook 2010 potrebbero non essere in grado di scaricare la Rubrica fuori rete.

    Per risolvere questo problema in Outlook 2007 e Outlook 2010, rendere l'URL interno alla Rubrica fuori rete accessibile da Internet. Outlook 2013 non è interessato da questo problema.

  • L'installazione di Exchange 2013 in un'organizzazione di Exchange esistente potrebbe far scaricare la Rubrica fuori rete a tutti i client   L'installazione del primo server Exchange 2013 in un'organizzazione esistente di Exchange 2007 o Exchange 2010 potrebbe far scaricare a tutti i client nell'organizzazione una nuova copia della Rubrica fuori rete, causando saturazione della rete e problemi relativi alle prestazioni del server. Questo problema si verifica perché Exchange 2013 crea una nuova Rubrica fuori rete predefinita nell'organizzazione che sostituisce la Rubrica fuori rete di Exchange 2007 o Exchange 2010. Le cassette postali che non dispongono di una specifica Rubrica fuori rete assegnata o che si trovano in un database della cassetta postale al quale non è stata assegnata una Rubrica fuori rete specifica, scaricheranno la nuova Rubrica fuori rete predefinita.

    Per impedire ai client di scaricare una nuova copia della Rubrica fuori rete quando Exchange 2013 viene installato, assegnare una Rubrica fuori rete a ogni cassetta postale o a ogni database di cassette postali in cui si trova la cassetta postale. Questo deve essere fatto prima che Exchange 2013 venga installato nell'organizzazione.

  • Gli utenti possono essere instradati a una cassetta postale di generazione Rubrica fuori rete che non è responsabile della Rubrica fuori rete richiesta   Exchange 2013 CU5 cambia il modo in cui le Rubriche fuori rete sono collegate alle cassette postali di generazione Rubrica fuori rete. Tale modifica consente l'instradamento di un utente a una cassetta postale di generazione Rubrica fuori rete non responsabile della Rubrica fuori rete richiesta dall'utente. Ciò può accadere in presenza di tutte le seguenti condizioni:

    • Si dispone di più cassette di generazione Rubrica fuori rete nell'organizzazione.

    • I server Cassette postali che ospitano le cassette postali di generazione Rubrica fuori rete vengono aggiornati prima dei server Accesso client.

    • I server Exchange 2013 vengono aggiornati a CU5 o successiva da una versione precedente a CU5, ad esempio da Exchange 2013 CU3 a Exchange 2013 CU5.

    • I server Accesso client eseguono una versione precedente a CU5.

    Per risolvere il problema, accertarsi di aggiornare i server Accesso client a Exchange 2013 CU5 prima di aggiornare i server Cassette postali. In tal modo si garantirà che i server Accesso client sappiano come eseguire il proxy delle richieste alla cassetta postale di generazione Rubrica fuori rete responsabile della generazione della Rubrica fuori rete dell'utente.

    Per saperne di più sulle modifiche della Rubrica fuori rete in Exchange 2013 CU5, vedere Miglioramenti della Rubrica fuori rete nell'aggiornamento cumulativo 5 di Exchange 2013.

  • Mittenti non autorizzati possono inviare messaggi a cartelle pubbliche   Le cartelle pubbliche situate nei server che eseguono Exchange 2013 SP1 o versioni successive accettano messaggi da mettenti esterni all'organizzazione Exchange, indipendentemente dalla configurazione della cartella pubblica. Questo problema può consentire alle cartelle pubbliche di ricevere posta indesiderata e altri messaggi non desiderati.

    Attualmente, non esiste alcuna soluzione per questo problema.

  • Non è possibile accedere alle cartelle pubbliche legacy tramite i servizi Web di Exchange   I client che si connettono a Exchange 2013 mediante i servizi Web di Exchange (EWS), non possono accedere alle cartelle pubbliche nei server di Exchange 2007 o Exchange 2010. I client che utilizzano EWS includono Mac Outlook e Outlook Web App. Se un client EWS tenta di accedere a una cartella pubblica legacy, riceverà un errore.

    L'unica soluzione disponibile al momento consiste nel migrare le cartelle pubbliche legacy in Exchange 2013. Tuttavia, esistono alcuni problemi che devono essere considerati prima di migrare le cartelle pubbliche. Per ulteriori informazioni, vedere Cartelle pubbliche.

  • I cmdlet TransportAgent cmdlets sui server Accesso client richiedono Windows PowerShell locale   Esiste un problema con i cmdlet *-TransportAgent che ne impediscono l'installazione o disinstallazione e gestione degli agenti di trasporto sui server Accesso client che utilizzano Exchange Management Shell. Per installare, disinstallare e gestire gli agenti di trasporto sui server Accesso client, è necessario caricare lo snap-in di Exchange Windows PowerShell snap-in e gestire 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.

    AttenzioneAttenzione:
    Il caricamento dello snap-in di Microsoft.Exchange.Management.PowerShell.SnapIn Windows PowerShell e l'esecuzione dei cmdlet diversi dai cmdlet *-TransportAgent non è supportato e potrebbe dar luogo a danni irreparabili alla distribuzione di Exchange.
    Per installare, disinstallare o gestire gli agenti di trasporto è necessario essere un amministratore locale sul server Accesso client. Non è supportata la modifica di elenchi di controllo di accesso (ACL) sui file e directory di Exchange o sugli oggetti di Active Directory.
    ImportanteImportante:
    Attenersi alla seguente procedura solo sul server Accesso client. Non è necessario caricare lo snap-in di Exchange Windows PowerShell se si desidera gestire gli agenti di trasporto sui server Cassette postali.
    1. Aprire una nuova finestra di Windows PowerShell.

    2. Eseguire il comando riportato di seguito.

      Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
      
    3. Eseguire normalmente le attività di gestione degli agenti.

    4. Ripetere questa procedura su ciascun server Accesso Client che si desidera gestire.

  • L'autenticazione NTLM non riesce per i client non aggiunti al domino L'autenticazione tra un client, come Windows Live Mail, e Exchange 2013 potrebbe non riuscire se le seguenti condizioni sono vere:

    • Il metodo di autenticazione che utilizza il client è NTLM.

    • Il computer non è stato aggiunto al dominio.

    Per ovviare a questo problema, è possibile effettuare una delle seguenti operazioni:

    • Aggiungere il computer in esecuzione sul client al dominio.

    • Modifica il tipo di autenticazione che il client utilizza da NTLM per autenticazione di base su TLS.

  • L'autenticazione GSSAPI non riesce quando si utilizza insieme al cmdlet Send-MailMessage L'autenticazione del programma GSSAPI (Generic Security Service Application Program Interface) potrebbe non riuscire quando il cmdlet Send-MailMessage, incluso nell'installazione predefinita di Windows PowerShell, viene utilizzato per inviare la posta autenticata a Exchange 2013. Quando ciò si verifica, viene visualizzata una voce nel registro evento dell'Applicazione sul server Exchange 2013 Client Access 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 connettore di ricezione front-end client <nome server>. Il meccanismo di autenticazione è Gssapi. L'indirizzo IP di origine del client che ha tentato l'autenticazione per Microsoft Exchange è [<indirizzo IP client>].

    Per risolvere questo problema, è necessario rimuovere il metodo di autenticazione Integrated dal connettore di ricezione client sui server Exchange 2013 Client Access. Per rimuovere il metodo di autenticazione Integrated da un connettore di ricezione client, eseguire il seguente comando su ciascun server Exchange 2013 Client Access che può ricevere le 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 tramite HTTP potrebbero essere ridotte 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 attiva MAPI tramite HTTP, i client che si connettono a un server di Exchange 2013 SP1 usando il protocollo potrebbero rilevare un peggioramento delle prestazioni. 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.

    NotaNota:
    È un problema solo se MAPI tramite protocollo HTTP è attivato nei server Accesso Client. È disabilitato per impostazione predefinita. Se MAPI tramite HTTP è disabilitato, i client usano il protocollo RPC tramite HTTP.

    Per risolvere il problema, procedere come segue:

    1. Nei server che eseguono il ruolo del server Accesso client, eseguire i seguenti comandi in un prompt dei comandi di Windows:

      set AppCmdLocation=%windir%\System32\inetsrv
      set ExchangeLocation=%ProgramFiles%\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 seguenti comandi in un prompt dei comandi di Windows:

      set AppCmdLocation=%windir%\System32\inetsrv
      set ExchangeLocation=%ProgramFiles%\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"
      

  • La richiesta di accesso alle cassette postali di Exchange 2010 potrebbe non funzionare quando è proxy attraverso i server Accesso client di Exchange 2013   In alcune situazioni, la richiesta proxy tra i server Accesso client di Exchange 2013 e Exchange 2010 Service Pack 3 (SP3) senza pacchetti di aggiornamento cumulativo installati potrebbero non funzionare correttamente e viene visualizzato un errore. Questo problema si verifica in presenza di tutte le seguenti condizioni:

    • Un utente con una cassetta postale di Exchange 2013 prova ad aprire una cassetta postale di Exchange 2010 tramite uno dei seguenti metodi:

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

      • L'opzione Un altro utente nell'interfaccia di amministrazione di Exchange

    • Il server Accesso client al quale si connette l'utente esegue Exchange 2013.

    • Il server Accesso client di Exchange 2010 è stato aggiornato a Exchange 2010 SP3 dalla versione RTM di Exchange 2010 o service pack Exchange 2010 precedente.

    Se tutte le condizioni elencate sopra sono vere, l'utente non sarà in grado di accedere alle altre opzioni di Exchange 2010 Outlook Web App e potrebbe essere visualizzata una pagina vuota.

    Per risolvere questo problema, installare Exchange 2010 SP3 Update Rollup 1 o versione successiva su ciascun server Exchange 2010.

 
Il documento è risultato utile?
(1500 caratteri rimanenti)
Grazie per i commenti inviati.
Mostra:
© 2014 Microsoft