Exchange Queue & A Aumenta dimensione allegato comprensibile, replica di cartelle pubbliche e altro ancora

Henrik Walther

D infrastruttura di messaggistica dell'organizzazione in Microsoft è basata su Exchange Server 2007. È necessario un limite di dimensione dei messaggi relativamente rigoroso di 12 MB impostato in tutta l'organizzazione.

Si hanno rilevato un comportamento strano che sembra essere correlate alle dimensioni del file allegato a un messaggio. Quando si invia un posta elettronica messaggio a un utente esterno, si supponga, allegato 11MB, il messaggio viene recapitato al destinatario previsto. Compito se questo messaggio (incluso l'allegato) viene inoltrato al mittente della rete interna, al mittente un rapporto di mancato recapito (NDR) che indica che il messaggio è maggiore del limite di sistema corrente o che la cassetta postale del destinatario sia pieno.

Dopo avere accettato chiusura esaminare il problema, si noterà che a un certo punto dopo il messaggio esce dell'organizzazione, la dimensione dell'allegato aumenta da circa 30 %. La domanda è necessaria allegato aumentare le dimensioni durante l'invio e ricezione dei messaggi di posta elettronica tramite Internet? E più importante è il comportamento previsto?

A la breve risposta è Sì. Si tratta spesso comportamento previsto, non solo per Exchange Server 2007, ma anche per le versioni precedenti di Exchange Server, nonché qualsiasi altro sistema di messaggistica che supporta MIME (Multipurpose Internet Mail Extensions) e utilizza base64 per codificare gli allegati. Quando un utente interno di Exchange invia un messaggio a un destinatario all'interno dell'organizzazione di Exchange, il messaggio non richiede una conversione del contenuto. Ciò significa che è non viene visualizzato il messaggio o allegati aumenteranno le dimensioni quando vengono recapitati. I messaggi inviati a destinatari esterni, invece, possono richiedere la conversione del contenuto.

Un messaggio SMTP standard (noto anche come messaggio di testo normale è costituito da una busta del messaggio e il contenuto del messaggio, l'intestazione di messaggio e il corpo del messaggio. Questi elementi sono basati su normale testo di US-ASCII a 7 bit. Quando un messaggio contiene gli elementi che non sono testo US-ASCII normale, gli elementi devono essere codificati. Quando si gestiscono tale contenuto non di testo, inclusi gli allegati, MIME viene utilizzato per la codifica. Exchange 2007 e versioni precedenti di Exchange Server utilizzano l'algoritmo base64 per codificare gli allegati. E lo svantaggio della codifica Base64 che esso bloats gli allegati da 33%.

In Exchange 2007, tranne quando Outlook Web Access è utilizzata, più relativi a trasporto conversione del contenuto viene effettuata sul server Trasporto Hub. Per una spiegazione dettagliata, vedere l'argomento "Informazioni su conversione contenuto" al technet.microsoft.com/library/bb232174.

D si sono in centro di una transizione da Exchange 2003 a Exchange 2007. Si sono spostati tutte le cassette postali degli utenti ai server delle cassette postali Exchange 2007, ognuno dei quali configurate utilizzando la replica continua cluster (CCR). È attualmente replicano tutte le cartelle pubbliche da nostri legacy server di cartelle pubbliche di Exchange 2003 in un server cassetta postale di base CCR. Tuttavia, abbiamo hanno scoperto durante i test che quando si verifica un failover con perdita di dati nel cluster di replica continua di tipo cluster, il database delle cartelle pubbliche non viene portato in linea sul nodo di altri. È inoltre Impossibile installarlo manualmente dopo il failover.

Si hanno un ambiente di laboratorio che rispecchia l'infrastruttura di Exchange 2007 nell'ambiente di produzione e test illustrato che il problema si verifica qui nonché. È non vengono visualizzati questo problema con uno dei database delle cassette postali su tutti i gruppi di replica continua di tipo cluster su cui si verifica un failover con perdita di dati, in modo che sembra strettamente correlate a database di cartelle pubbliche nei cluster CCR. Poiché si desidera ottenere ridondanza true per tutti i database, inclusi il database delle cartelle pubbliche, si dispone qualsiasi una conoscenza approfondita cosa causerebbe questo comportamento?

A I metodi di replica utilizzate per la replica continua di tipo cluster e dalla replica di cartelle pubbliche in Exchange 2007 sono due elementi molto diversi. Di conseguenza, non è consigliabile che è possibile combinare più database di cartelle pubbliche in un'organizzazione di Exchange Server cassetta postale di base CCR, se uno dei database cartelle pubbliche è ospitato in un server cassette postali in base CCR. È effettivamente possibile farlo durante una transizione e il gruppo di prodotti Exchange supporta con un database delle cartelle pubbliche ospitato in un server di cassetta postale di base CCR e, ad esempio, un server di Exchange 2003 legacy. Ma è estremamente consigliabile rimuovere il database delle cartelle pubbliche sul server delle cassette postali non basati su replica continua di tipo cluster cartelle pubbliche dopo che tutti i dati sono replicato.

Ciò che si verificano nell'ambiente di messaggistica di Exchange è normale. Quando si dispone di più database di cartelle pubbliche e uno di essi è ospitato in un server cassetta postale di base CCR, il database di cartelle pubbliche sul server delle cassette postali in base CCR verrà non da portare in linea durante un failover con perdita di dati (ovvero un'interruzione non pianificata.

In realtà, il database delle cartelle pubbliche non da portare in linea prima di nodo precedentemente attivo è attivare i nuovamente. Inoltre, tutti i file di registro delle transazioni del gruppo di archiviazione in cui il database di cartelle pubbliche è ospitato di devono essere disponibili.

Se questo non è un'opzione, la prima linea di difesa deve essere per ripristinare l'archivio cartelle pubbliche dall'ultimo backup valida, riprodurre i registri disponibili e quindi Seminare a altro nodo del database ripristinato. In alternativa, è impossibile creare l'archivio di cartelle pubbliche da zero. In questo caso, il nodo attivo originale deve essere recuperato e un nuovo database delle cartelle pubbliche deve essere creato e i dati delle cartelle pubbliche sono state replicate da un altro server cartelle pubbliche nell'organizzazione di Exchange.

Ciò che può sembrare dispari è che quando viene eseguita un'interruzione (pianificata) senza perdita di dati, il database delle cartelle pubbliche viene portato in linea. Si tratta in questo caso di un comportamento previsto. Per ulteriori informazioni vedere "cluster Continuous replica e pubblica cartella database nel" " Pianificazione della replica continua cluster."

D tutti I server delle cassette postali all'interno l'infrastruttura di messaggistica in base a Exchange 2007 vengono configurate tramite la replica continua di tipo cluster. Siamo molto soddisfacenti la modalità di replica continua di tipo cluster funziona, ma ha una domanda ci auguriamo che può rispondere.

Quando manutenzione in linea viene eseguito ogni sera, una delle attività è la deframmentazione in linea. Come è garantire che i database sul nodo passivo di un cluster CCR ottenere deframmentare durante la manutenzione in linea?

A la deframmentazione in linea attività, che elimina tutti gli elementi contrassegnati per rimozione e quindi attiva lo spazio utilizzato da tali elementi in spazi vuoti, Genera nuovo file di registro delle transazioni durante il processo. Qualsiasi file di registro delle transazioni generati sul nodo replica continua di tipo cluster attivo verranno replicati sul nodo passivo con le modifiche in corso per i database nel nodo passivo nonché.

Con questo presente, verificare che si pianifica la finestra della manutenzione in linea in modo che non in conflitto con la finestra di backup, come si forza la deframmentazione in linea per interrompere. Non la deframmentazione necessariamente deve completare ogni giorno, ogni settimana o anche ogni due settimane per questo scopo. In passato, istruzioni dal gruppo di prodotti di Exchange specificato con la deframmentazione in linea completata almeno ogni due settimane. Ma che modificato con Exchange Server 2007 SP1, ambiente ogni organizzazione è diverso. Per ulteriori informazioni su nuove indicazioni, vedere il post nel Blog del team di Microsoft Exchange.

D si prevede di utilizzare la replica continua di tipo Exchange 2007 cluster in modo da ottenere ridondanza true per i nostri server delle cassette postali. Attualmente, si cerchi in modalità di trasporto dumpster viene utilizzato in combinazione con la replica continua di tipo cluster per non assicurarsi che nessun messaggio perso durante un failover con perdita di dati dal nodo attivo la replica continua di tipo cluster sul nodo passivo. Si conosce di qualsiasi trasporto dumpster gotchas opportuno tenere in considerazione?

A il trasporto dumpster garantisce che dispongano di una perdita di dati minima durante un failover con perdita di dati da un nodo a un'altra in un server di cassette postali di Exchange 2007 che utilizza la replica continua di tipo cluster. A tale scopo redelivering i messaggi che sono stati recentemente inviati al server delle cassette postali. Durante un failover con perdita di dati, c'è una possibilità reale andranno perse alcune transazioni dei file di registro e, a causa di questo, nonché dati effettivi. Come indicato, il trasporto dumpster redelivers i messaggi che sono stati recentemente inviati al server delle cassette postali e quindi assicura che i dati perduti durante l'errore con perdita di dati vengono ripristinati. Tuttavia, poiché è solo i messaggi vengono recapitati tramite il server Trasporto Hub su cui il trasporto dumpster si trova, dati, ad esempio attività e calendario elementi creati vicino al failover con perdita di dati andranno persi.

D È attualmente prevede una migrazione da un'organizzazione Exchange 2003 cross-forest a un'organizzazione Exchange 2007 in un nuovo insieme di strutture Active Directory. È ampiamente sono studied la documentazione di migrazione cross-forest" Come transizione da un unico insieme di strutture per tra insiemi di strutture", che indica che è necessario creare un trust tra insiemi di strutture e non un trust tra insiemi di strutture esterno. Perché è che non può essere utilizzato un trust esterno?

A anche se la documentazione di Exchange 2007 su TechNet indicante che è necessario utilizzare un trust tra insiemi di strutture anziché di un trust esterno, non significa che non è possibile utilizzare un trust esterno. In realtà, un trust esterno funziona bene per una migrazione di Exchange cross-forest, ma è uno svantaggio. È necessario specificare un account con le autorizzazioni appropriate per accedere a un controller di dominio nell'insieme di strutture trusted durante la creazione di una cassetta postale collegata (vedere la Figura 1 ), poiché è non può utilizzare le credenziali di registrato, utente indipendentemente le autorizzazioni assegnate ai è.

Figura 1 Specifica un account di pagina dell'account principale durante la creazione di una cassetta postale collegata

D Microsoft organizzazione solo modificato per Exchange 2007 e Finora si sono molto pienamente con la nuova versione, una possibile eccezione. Nuovamente quando si sono stati utilizza Exchange 2003 SP2, è stato possibile configurare l'ambiente in modo che il nome visualizzato semplice di una cassetta postale utente è stato visualizzato come mittente di un messaggio in uscita. Per il nostro costernazione si sono non stati in grado trovare una funzionalità simile in Exchange 2007. Non farci sapere che questa funzionalità è mancante in Exchange 2007.

A questa funzionalità è, infatti, mancante RTM di Exchange 2007, a destra fino rollup Update 4 (RU4) di Exchange 2007 SP1 è stato rilasciato in ottobre 2008. Con RU4 SP1, è possibile ancora una volta, come avviene con Exchange 2003 SP2, configurare Exchange per visualizzare il nome visualizzato semplice nei messaggi in uscita. Questa operazione può essere eseguita utilizzando il cmdlet Windows PowerShell set-RemoteDomain con il parametro –Use­SimpleDisplayName. Ad esempio, per attivare i nomi visualizzati semplici nei messaggi in uscita inviati al dominio contoso.com, utilizzare il comando illustrato nella Figura 2 .

Nella figura 2 utilizzo semplice visualizzare nomi per i messaggi in uscita

D che cos'è la procedura consigliata per la deframmentazione le copie del database sul nodo passivo in un server cassetta postale Exchange 2007, la replica continua di tipo cluster, in base? Verrà Exchange diventano complicato se i database su uno dei nodi nella tecnica CCR sono deframmentare, ma non quelli presenti altri nodi.

A se è necessaria una deframmentazione non in linea, deve sempre essere eseguita sul nodo attivo del cluster di replica continua di tipo cluster, non sul nodo passivo. Tenere presente anche se si esegue l'operazione una deframmentazione non in linea di uno o più database sul nodo attivo, è necessario un reseeding completo dei database specifici sul nodo passivo.

Ciò significa, ad esempio, che se si dispone di un database 200GB (quando si utilizza la replica continua di tipo cluster, la dimensione del database consigliata è 200GB durante la replica su una rete di 1 GB), verrà richiedere diverse ore eseguire la deframmentazione (una buona regola è 2 a 4 GB all'ora). Ma al termine del processo di deframmentazione, sarà necessario anche replicare 200GB dei dati nel nodo passivo. Se la distribuzione dei file di log è in corso della rete pubblica, ciò può influire sulle prestazioni complessive di rete che si è verificata agli utenti finali.

Nella maggior parte dei casi, il motivo per eseguire una deframmentazione off­line consiste nel rimuovere gli spazi nel database per ridurre la dimensione del database. Ma è raramente necessario poiché verrà riutilizzata spazio prima di un database aumenta ulteriormente. E non è effettivamente rilevante se lo spazio disponibile nel database o sul disco,?

Se presenti molti gigabyte di spazio in un database e si desidera rimuoverlo, approccio migliore consiste di spostare tutte le cassette postali in uscita del database e in uno nuovo.

Walther Henrik è un Microsoft Certified master: Exchange 2007 e MVP per Exchange con più di 14 anni di esperienza in azienda IT. Lavora come un architetto di tecnologia per Interprise consulenza (un partner Microsoft Gold in Danimarca e come un Technical writer per Biblioso Corporation (una società base statunitense specializzata in servizi di documentazione e la localizzazione gestiti).