Coda di Exchange & R: Exchange viene continuamente modificate
Se si modifica giorni di calendario predefinito, gli endpoint di datacenter o reindirizzamento server, è sempre necessario essere in grado di apportare modifiche a Exchange.
Henrik Walther
Blues lunedì
D. Ci sono una grande organizzazione europea e appena sono stati migrati da IBM Lotus Domino a Microsoft Exchange 2010. La maggior parte dei nostri utenti utilizzano Outlook Web App 2010 come client di posta elettronica predefinito. Più utenti hanno osservato che "Domenica" è il valore predefinito primo giorno della settimana è impostato in impostazioni | Calendario nel Pannello di controllo di Exchange (vedere nella figura 1).
.jpg)
Figura 1 il valore predefinito primo giorno della settimana per una cassetta postale di Exchange 2010.
Poiché il lunedì è considerato il primo giorno della settimana lavorativa nel settore delle fototessere, che si desidera modificare questa impostazione per tutti gli utenti di Exchange 2010 all'interno dell'organizzazione. Possiamo utilizzare il Exchange Management Console (EMC) o Exchange Management Shell (EMS) per effettuare questa operazione a livello centrale per tutti i nostri utenti? Aver preso in esame nella pagina delle proprietà per le cassette postali di EMC e persino mediante servizi di gestione Emergenze tramite il cmdlet Get-Mailbox, ma non possiamo vediamo eventuali attributi correlati al primo giorno della settimana. È possibile avere un aiuto?
**R.**Lunedì è il primo giorno della settimana lavorativa in molti paesi europei, in modo che ho capito la frustrazione. Per fortuna, è relativamente semplice modificare questa impostazione per tutti gli utenti. Non sia possibile utilizzare di EMC, ma si può certamente farlo con Exchange Management Shell (EMS). La maggior parte pensare che sarebbe necessario utilizzare il cmdlet Set-Mailbox per modificare tale impostazione. In realtà, è necessario utilizzare il cmdlet Set-MailboxCalendarConfiguration.
Eseguire il seguente comando e si vedrà che tutte le impostazioni specifiche del calendario è possibile manipolare per una cassetta postale (vedere nella figura 2):
Get-MailboxCalendarConfiguration –Identity <user> | fl
.jpg)
Figura 2 Modifica il valore predefinito primo giorno della settimana tramite di Exchange Management Shell.
Se si desidera modificare "WeekStartDay" per tutti gli utenti nell'organizzazione di Exchange 2010 fosse "Harper" nell'attributo società, ad esempio, lunedì, utilizzare il comando riportato di seguito:
Get-User –Filter "Company –eq 'Contoso'" | Set-MaiboxCalendarConfiguration –WeekStartDay “Monday”
Torna al centro
D. Abbiamo abbiamo in esecuzione Exchange 2010 per circa un anno. Siamo un'azienda di grandi dimensioni, e fino ad ora abbiamo utilizzato un unico centro dati che ospita la nostra soluzione di messaggistica di Exchange 2010. Dell ha introdotto un ulteriore datacenter in modo da poter raggiungere adattabilità delle cassette postali a livello di sito. Sarà attivi degli utenti che tentano entrambi datacenter, in modo che abbiamo creato un array di server di accesso Client (matrice CA) in altri datacenter.
Abbiamo già spostato i primi 100 utenti nel nuovo centro dati per verificare cose funzioneranno come previsto. Non siamo abbastanza esiste. Vediamo i problemi con l'endpoint del client Outlook MAPI modificato da "outlook-1.contoso.com" (CAS oggetto array FQDN nel primo datacenter) a "outlook-2.contoso.com" (nuova CA oggetto array FQDN nel centro dati nuovo).
I client MAPI Outlook semplicemente continuano a utilizzare il punto finale precedente, che significa che i client Outlook creare sessioni RPC per la matrice di CA nel centro dati primo e la matrice CA comunica quindi con RPC con i server di cassette postali nel nuovo centro dati. Qualsiasi idea se tale condizione è voluta? In caso contrario, si dispone di più pallida idea di come ci possiamo correggerlo?
**R.**Alcuni Exchange Queue & Un lettore ricorderà ho trattato questo argomento prima. Quando si sposta le cassette postali da un datacenter con una matrice di CA in un altro datacenter con un'altra matrice di CA, non si desidera rendere il vecchio endpoint risolvibile o non è disponibile. Ciò avrà un impatto tutti gli utenti attivi nel primo centro dati.
La soluzione alternativa, anche se non è abbastanza, ovvero è possibile aggiornare il profilo MAPI di Outlook per gli utenti che dispongono di cassette postali spostate nel nuovo centro dati (utilizzando l'opzione "Ripristina profilo" all'interno di Outlook. ad esempio).
Alcuni si potrebbe domandare perché Exchange 2010 si comporta in questo modo. Funzionava bene con le versioni precedenti di Exchange. I client MAPI Outlook ora connettono al servizio di accesso Client RPC (servizio RPC CA) nel ruolo del server Accesso Client, non direttamente all'archivio nel ruolo del server cassette postali.
In Exchange 2007 e versioni precedenti, quando si è spostato una cassetta postale dal database di cassette postali, produrrebbe nel database delle cassette postali di origine l'invio di un "ecWrongserver" per il client di Outlook. Che forzato a individuare la cassetta postale nel database in cui è ora memorizzata nella cassetta postale.
Il servizio RPC CA non può rispondere con un "ecWrongServer" quando un * sopra (opzione di database o il failover) avviene tra due centri dati (e il servizio RPC CA è disponibile). Esso non può rispondere in modo analogo, se si sposta una cassetta postale da un database di cassette postali in un centro dati a un database di cassette postali in un altro, in cui l'attributo RpcClientAccessServer del database di destinazione contiene un'altra completamente dominio nome completo (FQDN).
Durante lo sviluppo di Exchange 2010 SP1, sono stati piani per introdurre un'opzione "Consenti Cross RPC Client accesso al sito" cosiddetti che consentono di configurare per un gruppo di disponibilità di Database (DAG). Questa opzione è stata considerata eccessivamente complessa, in modo che è stato tagliato a destra prima di SP1 di Exchange 2010 spedito.
Possiamo abbiamo coesistere?
D. Che abbiamo sviluppato Exchange 2010 nella nostra organizzazione di Exchange 2003. Stiamo pianificando scegliere lo spazio dei nomi che viene utilizzato per accedere a una cassetta postale in Exchange 2003 per la matrice Exchange 2010 CA. Sono già state aggiunte un FQDN legacy (legacy.contoso.com) al certificato SAN/UC e configurato l'URL legacy nella directory virtuale OWA 2010.
Abbiamo preparato enable SSL offload sulla soluzione del sistema di bilanciamento carico che distribuisce il traffico client tra le autorità di certificazione. Abbiamo inoltre abbiamo seguite la procedura descritta in questo articolo TechNet Wiki per la configurazione SSL offload sui server Exchange 2010 CA. Offload SSL non è abilitato sul server di Exchange 2003 front-end (FE).
Siamo molto sicuri del fatto SSL offload funzionerà in uno scenario di coesistenza, in cui i client si connettono ai server Exchange 2010 CA e vengono reindirizzati ai server di Exchange 2003 FE. Si conosce questo scenario funzionerà?
**R.**Sì, gli utenti OWA 2003 accedere alle cassette postali mediante l'autenticazione ai server di Exchange 2010 CA che reindirizzano la sessione per i server di Exchange 2003 FE. Questo funzionerà anche con SSL abilitato sui server Exchange 2010 CA e la soluzione di bilanciamento del carico.
Alcuni di voi potrebbe avere previsto un'altra risposta. Exchange 2003 URL configurato nella directory virtuale OWA 2010 deve essere sotto forma di "https://legacy.contoso.com/exchange" e non "http://legacy.contoso.com/exchange". In caso contrario, si otterrà un 91 ID evento nel registro dell'applicazione (vedere nella figura 3).
.jpg)
Figura 3 errore nel registro applicazione quando è stato configurato legacy URL HTTP, invece di HTTPS.
Il precedente URL deve iniziare con HTTPS e non HTTP. Poiché i server Exchange 2010 CA reindirizzano semplicemente la sessione del client a un server di Exchange 2003 FE, esso funzionerà correttamente quando si utilizza HTTPS per l'URL legacy OWA.
Copy Queue
D. Quando utilizzano i vari scenari di Exchange 2010 DAG (di solito in ambienti di laboratorio), possibile che venga visualizzato un elevatissimo lunghezza coda di copia (vedere nella figura 4).
.jpg)
Figura 4 una coda di copia estremamente elevati è sempre una possibilità.
La prima volta che ho notato che ho pensato, "che cosa il?" Dopo un'analisi più approfondita, vedo che è lo stesso numero esatto ogni volta che si verifica. Sai se si tratta di un bug o qualcosa del genere?
**R.**Il numero è visualizzato è il valore più alto, è possibile impostare per lunghezza coda di copia. Copia di registro non è in corso e gli aggiornamenti al database cluster non sono in corso. Una perdita di connettività di rete tra i nodi di DAG in genere comporta qualcosa di simile.
In un ambiente di laboratorio lenta, ciò può verificarsi in alcuni casi. Non è non dovrebbe visualizzarlo in un ambiente di produzione, anche se. In tal caso, è consigliabile cercando di individuare la causa principale per la connettività di rete tra i nodi DAG perdere dei dati...
.jpg)
**Henrik Walther**è Microsoft Certified Master: Exchange 2007 ed Exchange MVP con più di 16 anni di esperienza nel settore IT. Lavora come Technology Architect presso un Microsoft Gold Certified Partner in Danimarca e un technical writer per Biblioso Corporation (servizi di localizzazione e documentazione gestita da una società negli Stati Uniti è specializzata in). È anche un fornitori con contratti lavorando su vari team di prodotto (compresi i team di Exchange e Lync) in Microsoft.