Exchange Queue &A: Gruppi di disponibilità del database
Utilizzando i gruppi di disponibilità del database è una buona idea, soprattutto perché è possibile copiare e memorizzarli in varie posizioni, ma si noti problemi di indirizzamento.
Henrik Walther
Indirizzamento Conundrum
D: Abbiamo distribuito Exchange 2010 e reso disponibile tramite gruppi di disponibilità del database (DAGs) tutti i server di cassette postali. Sono cose nella forma valida e tutto funziona come previsto, tranne un dettaglio secondario.
Quando un utente riceve un messaggio inviato da un dipendente con una cassetta postale presente in un DAG, a sua volta invia un altro messaggio per un dipendente o un destinatario di un'altra organizzazione, l'intestazione del messaggio Internet di illustrato nel messaggio ricevuto il server cassette postali è stato configurato con un indirizzo APIPA, ad esempio 169.254.5.133. Si utilizzano indirizzi IP statici per tutti i server di Exchange 2010, in modo che non capiscono perché verrà visualizzato come un indirizzo APIPA (vedere di Figura 1). Possibile si enlighten ci?
R: Questa è una domanda interessante. La risposta breve è che si verifica solo quando sono state apportate ad elevata disponibilità utilizzando DAGs uno o più server cassette postali Exchange 2010 e funzionalità DAG si basa sul componente cluster di Failover Windows (WFC). Il problema con i server di cassette postali che non fanno parte di un DAG non vengono visualizzati.
Richiedere Let’s vicino quello che succede qui. Il componente WFC in Windows Server 2008 R2 prevede che le applicazioni che utilizzano WFC, ad esempio SQL, Exchange e file server, per individuare le risorse del cluster in modo specifico. L'applicazione deve connettersi a una risorsa cluster individuando le informazioni corrette utilizzando un server DNS.
Ciò è noto come un punto di accesso client (CAP). Un CAP è costituito da un nome NetBIOS e una o più risorse indirizzo IP. In Windows Server 2008 R2, se il server supporta gli aggiornamenti dinamici, le informazioni CAP sono registrate nel DNS dopo il CAP viene portato in linea nel WFC.
Sfortunatamente, sono applicazioni che salta il passaggio DNS e invece connettono direttamente a un nodo del cluster utilizzando la prima scheda di rete nell'elenco di associazione. Per impostazione predefinita, la prima scheda di rete contenuta nell'elenco dell'associazione è la scheda di cluster di Failover Microsoft Virtual (vedere di Figura 2). Questa scheda è configurata con un indirizzo APIPA.
.png)
Figura 1 APIPA di indirizzi in un'intestazione Internet
.png)
Figura 2 di Cluster di Failover di Microsoft scheda virtuale
In questo modo, indovinare quale applicazione non utilizza DNS per individuare e collegare una risorsa cluster? A caso: Exchange 2010 (ed Exchange 2007, nonché).
Come è possibile risolvere questo piccolo fastidio? Fortunatamente, è facile con l'aiuto di uno strumento poco noto come nvspbind, è possibile scaricare da MSDN Code Gallery: code.msdn.Microsoft.com/nvspbind. Nvspbind è stato sviluppato specificamente per il binding di rete dalla riga di comando per la modifica.
Let’s controllare l'ordine di binding delle schede nel server. Eseguire nvspbind.exe /o ms_tcpip. Come può vedere in di Figura 3, Local Area Connection * 9 (che equivale a scheda di cluster di Failover Microsoft Virtual) viene elencato per primo.
.png)
Nella figura 3 visualizzazione di un elenco utilizzando nvspbind
Successivamente, è necessario spostare Local Area Connection * 9 verso il basso. Eseguire il seguente comando:
nvspbind.exe /- “Local Area Connection* 9” ms_tcpip
.png)
Figura 4 di spostamento Local Area Connection * 9 nell'elenco ordine di binding
Come può vedere in di Figura 4, Local Area Connection * 9 è stato spostato verso il basso nell'elenco ordine di binding. Provare a inviare un nuovo messaggio. L'intestazione Internet vengono visualizzati l'indirizzo IP reale del server (vedere di Figura 5).
.png)
Figura 5 di Internet un'intestazione che mostra l'indirizzo IP reale del server delle cassette postali
Copia manuale
D: Abbiamo appena distribuiti server Exchange 2010. Si intende utilizzare DAGs per rendere altamente disponibili i database delle cassette postali. Ci stiamo pianificazione di otto copie di ciascun database delle cassette postali. Ciascun database delle cassette postali avranno copie in tre posizioni fisiche. Ci concentreremo per database di circa 500 GB ciascuno. A causa della larghezza di banda limitata a uno dei percorsi fisici, prevediamo una volta lungo seeding. In questo modo, invece, ci stiamo chiedendo se è possibile in qualche modo copiare manualmente i file di database in un percorso remoto con un'unità USB?
R: Sì, è possibile farlo in questo modo, così come un metodo supportato. Per copiare manualmente un database fuori rete, disattivare la registrazione circolare per i rispettivi database. A tal fine esecuzione:
Set-MailboxDatabaseMDB01 -CircularLoggingEnabled $false
Quindi smontare i database utilizzando:
Dismount-Database MDB01 -Confirm $false
Copiare il database e tutti i file di registro in un altro percorso, ad esempio un'unità USB.
Una volta completato il processo di copia, montare nuovamente utilizzando la copia di database attivo:
Mount-Database MDB01
Connettersi ora disco USB per il server che ospiterà il database, copiare i file di database e di registro nello stesso percorso di quello utilizzato nel server di origine da cui sono stati copiati i file.
Aggiungere quindi la copia del database utilizzando l'Add-MailboxDatabaseCopy - parametro SeedingPostponed. Il comando esatto sarebbe qualcosa di simile:
Add-MailboxDatabaseCopy -Identity MDB01 -MailboxServer E2K10EX04–SeedingPostponed
Non vi è alcun processo di seeding perché i file EDB e i file di registro associati sono già presenti. Infine, attivare la registrazione circolare utilizzando:
Set-MailboxDatabaseMDB01 -CircularLoggingEnabled $true
Strada guerrieri
D: Ci stiamo esegue Exchange 2010 e abbiamo molte “ strada guerrieri ” che dipende fortemente dalle applicazioni Web di Outlook o OWA (quello utilizzato per essere chiamato automaticamente). Questi utenti non possono accedere a OWA quando la password è scaduta. Inoltre abbiamo trovato che i nuovi dipendenti per i quali è stato impostato l'account a “ cambiamento obbligatorio password all'accesso successivo ” quando l'account utente innanzitutto creato (vedere di Figura 6), non è possibile accedere a OWA prima di cui modificare la password tramite altri meccanismi.
.png)
Figura 6 Cambiamento obbligatorio password all'accesso successivo attivato
È stato state prodotte con questo fastidio poiché abbiamo spostato da Lotus Domino a Exchange 2003 molti anni fa. Sai come è possibile risolvere il problema?
R: Intervallo valido per questa domanda. Quando il team di Exchange ha iniziato la pianificazione di Exchange 2007 SP3, come Exchange 2010 SP1, ha deciso di correggere la mancanza di poter accedere a OWA quando la password dell'utente è scaduta o è stato impostato l'account utente per utente cambiamento obbligatorio password all'accesso successivo. Elaborato con lo strumento reimpostazione della password di OWA. Si tratta di un modulo IIS 7 che rileva le password scadute e reindirizza gli utenti a una pagina della password di modifica nuovissima.
.png)
Figura 7 di pagina di accesso di Outlook Web App 2010 autenticazione basata su form
Let’s vedere in azione, è necessario? L'utente tenta di accedere a OWA 2007 o 2010 utilizzando la pagina di accesso di autenticazione basata su form (FBA), come illustrato in di Figura 7. A questo punto, l'utente viene reindirizzato alla nuova pagina Cambia Password, illustrato in di Figura 8. Qui, è necessario immettere la password corrente, oltre a quello nuovo e quindi fare clic sul pulsante Invia.
.png)
Figura 8 di pagina di Outlook Web App 2010 Cambia Password
A questo punto, viene modificata la password e l'utente può accedere utilizzando la nuova password. Semplice e intuitivo, vero?
Tenere presente che la pagina Modifica Password non è attivata per impostazione predefinita dopo l'installazione di Exchange 2007 SP3 o Exchange 2010 SP1. È necessario attivare questa opzione con una chiave del Registro di sistema. In particolare, è necessario accedere a ciascun Exchange 2007 o Exchange 2010 client server di accesso (CAS) e avviare l'editor del Registro di sistema.
Nell'editor del Registro di sistema individuare: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchange OWA. In questo caso, sarà necessario creare una nuova chiave REG_DWORD denominata ChangeExpiredPasswordEnabled. Attivare questa impostando il valore di dati su “ 1 ”, come illustrato in di Figura 9.
.png)
Figura 9 di la chiave del Registro di sistema necessaria per abilitare la modifica password di OWA
Guerrieri del viaggio possono ora accedere a OWA, indipendentemente se la password è scaduta o deve essere modificata.
_***Henrik Walther****è un master di Microsoft Certified: Exchange 2007 ed Exchange MVP con più di 15 anni di esperienza nel settore IT. Lavora come un forTimengoConsulting architetto di tecnologia (un Microsoft Gold Certified Partner in Danimarca) e un technical writer per Biblioso Corporation(società americana specializzata in Gestione servizi di documentazione e localizzazione). Tramite posta elettronica Walther in v-henwal@microsoft.com . * _