Coda di Exchange & R: Ricevere i messaggi in modo ottimale
Questo mese, la nostra coda di Exchange regolari & Un cronista è affiancato da un collaboratore di ospite per risolvere i vostri problemi di Exchange più fastidioso.
Henrik Walther
Con contributore ospite George Hinterhofer
Verifica dei messaggi
D. Potete condividere un suggerimento o due su come messaggio di rilevamento? Troviamo la GUI per essere di uso limitato. Stiamo cercando consigli su come ottenere le informazioni richieste dai registri di verifica messaggi.
**R:**Utilizzo di Windows PowerShell per la verifica dei messaggi è l'approccio preferibile. E ti dà un maggiore controllo sui parametri di query ed è molto più veloce. Sarebbe un one-liner tipico:
Get-TransportServer | Get-Messagetrackinglog –sender test@contoso.com –Start "03/18/2012 09:00AM"
Ciò si otterrebbe tutti i record di verifica dei messaggi da tutti i server di trasporto nell'ambiente che dispongono di un indirizzo di invio di test@contoso.com, a partire da 18 marzo 2012, 9 Se si desidera esportare i risultati in uno dei tuoi utenti o clienti, pipe i risultati nella esportazione-CSVcmdlet:
Get-TransportServer | Get-Messagetrackinglog –sender test@contoso.com –Start "03/18/2012 09:00AM" | Export-CSV –Path c:\temp\messagetracking.csv
Vuole scavare i risultati per la risoluzione dei problemi? Aggiungere il formato-listcmdlet al comando:
Get-TransportServer | Get-Messagetrackinglog –sender test@contoso.com –Start "03/18/2012 09:00AM" | fl
Per facilità d'uso e per risparmiare un sacco di battitura a macchina, è una buona idea di scrivere la propria piccola funzione di Windows PowerShell. In questo modo per la ricerca rapida ed efficace. Questo esempio cercare i log di tutti i server Trasporto Hub, –sender come parametro di accettare e delle ultime 24 ore vale la pena di dati di ricerca:
functionmt {param ($sender) $SDate = (get-date).adddays(-1) get-transportserver | get-messagetrackinglog -sender $sender -start $SDate }
Sentitevi liberi di adattare questa funzione alle proprie esigenze. Si può anche mettere questo pezzo di codice nel file con estensione ps1 $profilo così che ottiene caricato all'avvio del computer. Da allora in poi, sarebbe solo necessario digitare:
mt –sender test@contoso.com
Utilizzare gli aggiornamenti per rollup
D. Abbiamo sentito che possiamo usare cartella degli aggiornamenti sul supporto di origine installazione Exchange 2010 per installare aggiornamenti cumulativi durante l'installazione. È in questo preciso?
**R.**Sì, è esatto — almeno parzialmente. È possibile utilizzare la directory aggiornamenti per installare un rollup corrispondente durante una nuova installazione di Exchange 2010 e ridurre il tempo di installazione necessari. Basta semplicemente inserire il file con estensione msp nella rispettiva directory, come illustrato nella Figura 1.
.jpg)
Figura 1 aggiungendo il msp nella directory aggiornamenti consente di installare un rollup corrispondente.
Non tentare questo per un'installazione di aggiornamento, come ad esempio rilasciato alla produzione per il secondo service pack o il primo service pack per il secondo service pack. Questo non funziona e non riuscirà su installazione. Gli aggiornamenti devono essere fatte in modo sequenziale e non è possibile combinarli in quel modo. Ci sono maggiori informazioni sulla pagina TechNet Library, "installare l'aggiornamento cumulativo più recente per Exchange 2010."
SP1 o SP2?
D. Noi abbiamo aggiornato il nostro server Edge di Exchange 2010 al secondo service pack. L'installazione è completata senza errori. Tuttavia, quando guardando i numeri di build con Get-ExchangeServer, essi mostrano ancora come 14.1.xx, aka SP1. Che cosa è andato storto qui?
**R.**Questo è un po' fuorviante, ma il comportamento previsto in realtà. Una volta una sottoscrizione di Edge in luogo, Microsoft non aggiorna i numeri di build come parte del normale processo EdgeSync. Se hai bisogno di rifare l'abbonamento intero (ad esempio, se il certificato utilizzato per EdgeSync scade), vedrai che i numeri di build aggiornerà pure.
Ritardi di autorizzazioni
D. Quando sto cercando concedere le autorizzazioni completo alla cassetta postale in una cassetta postale in Exchange 2010, l'elenco delle cassette postali richiede molto tempo per compilare (dovunque da diversi minuti fino a ore). C'è qualcosa che può essere fatto a tale proposito?
**R.**Questa è una domanda comune. La ragione per la finestra "Selezionare account" popolando così lentamente è improprio LDAP query. Siete tutte le cassette postali di recupero e applicare il filtro in seguito. Se sono state cercando per una cassetta postale denominata "Fred", ad esempio, in primo luogo otterreste un elenco di tutte le entità di protezione. Allora si dovrebbe controllare in seguito per vedere se uno di questi è di Fred. Questo processo è penosamente lento, soprattutto nelle installazioni del grande numero di utenti.
Per fortuna abbastanza, miglioramenti della protezione per Microsoft Exchange o Exchange(SE), ha deciso di risolvere questo problema nell'ultima e più grande cumulativo per Exchange 2010 SP2, vale a dire Rollup 1. Il link diretto per la correzione è qui.
Autenticazione integrata
D. Stiamo cercando abilitare l'autenticazione integrata di Windows per Exchnage Outlook Web App (OWA) per ottenere una decente single sign-on esperienza per i nostri clienti interni, dominio. I client accede a un URL di bilanciamento carico di rete (NLB) chiamato https://mail.contoso.com.
Abbiamo disattivato il primo Boot Agent e attivata l'autenticazione integrata di Windows sulle directory virtuale OWA. Tuttavia, quando si tenta di accedere a https://mail.contoso.com/owa, noi stiamo ancora ricevendo richieste le credenziali. Quando abbiamo accedere alle pagine OWA inserendo direttamente un servizio di accesso Client (CAS) URL, ad esempio https://cas1.contoso.com/owa o https://cas2.contoso.com/owa, ci stiamo registrati su con alcun prompt. Per renderlo ancora più strano, se si digita l'IP risolto di mail.contoso.com, nel nostro caso https://10.1.1.150/owa, ci stiamo anche connesso con alcuna autenticazione. È possibile avere un aiuto?
R. Dopo aver lavorato la mia strada su e giù attraverso le tracce Netmon e violinista, finalmente ho notato che un cambiamento di metodi di autenticazione utilizzato (si possono vedere questi in Fiddler) quando sono passato dalla https://10.1.1.150/owa (lavorando, non chiedere conferma) a https://mail.contoso.com/owa (richiesta).
Si scopre che durante l'accesso IP risolto, stavamo usando Windows NT LAN Manager per eseguire l'autenticazione OWA. Quando si passa al bilanciamento carico di rete completamente qualificato nome di dominio, abbiamo iniziato a utilizzare Kerberos per andare contro le CAS.
Uso un po' più intelligente e scavo di SetSPN – l ha rivelato che qualcuno aveva aggiunto una voce di nome principale di servizio (SPN) denominata http/mail.contoso.com per un account computer totalmente estranei. Questo computer client a sua volta fatto andare per un ticket Kerberos (perché una voce corrispondente è stata trovata in Active Directory) e poi presentare il biglietto per la casella di CAS. La casella CAS ovviamente non aveva idea che cosa fare con un ticket Kerberos rilasciato a qualche scatola completamente diverso, così gettò un prompt di autenticazione ripetute.
Una volta è stata rimossa la voce SPN fasulla, l'autenticazione integrata di Windows ha iniziato a lavorare immediatamente contro l'URL di bilanciamento carico di rete e la richiesta di autenticazione era sparita.
Dichiarazione di non responsabilità discordia
D. Stiamo cercando di creare una regola di trasporto per aggiungere un disclaimer a tutta la posta in uscita. Durante i test, abbiamo scoperto che le caselle di trasporto sembrano ignorare la regola. Essa non ha aggiunto i dinieghi desiderati, anche dopo il riavvio tutte le caselle di Hub per assicurarsi che essi effettivamente caricata la regola. Tuttavia, la stessa regola sta lavorando come un fascino nel nostro ambiente di prova. Avete qualche idea?
R. La vera e propria norma per svolgere questa funzione assomiglia a ciò che viene mostrato Figura 2.
.jpg)
Figura 2 questa regola aveva lo scopo di aggiungere un disclaimer alla fine dei messaggi in uscita.
Dopo aver controllato i soliti sospetti come replica, servizio di trasporto di non essere a conoscenza di qualsiasi cambiamento e così via, tutto sembrava corretto. Poi abbiamo verificato ExTRA traccia per catturare un ETL del motore regole durante l'elaborazione di messaggi di posta elettronica in uscita.
L'ETL ha rivelato che il servizio di trasporto era pienamente consapevole della nuova regola di trasporto, ma per qualsiasi motivo non riconosce mail in uscita come "outgoing". Per qualche ragione, sono stati trattati come interni.
Ulteriore analisi hanno rivelato il motore di regole, considerato la voce "Dominio remoto predefinito" nei domini remoti come interni. Pertanto, essa non si applica la regola di esclusione di responsabilità.
Mentre esaminando la questione, ho notato dice IsInternal:$ true per il dominio remoto predefinito. Questo dice Exchange per trattare andando su uno spazio indirizzo di tutta la posta * come interna — e quindi non si applica la clausola di esonero. Abbiamo cambiato all'impostazione predefinita false. Ora sono applicati con successo i dinieghi.
.jpg)
.jpg)
Henrik Walther è un Microsoft Certified Master: Exchange 2007 ed Exchange MVP con più di 16 anni di esperienza nel settore IT. Lavora come Technology Architect per un Microsoft Gold Certified Partner in Danimarca e come un technical writer per Biblioso Corp. (una società statunitense specializzata in gestione servizi di localizzazione e documentazione). È anche un fornitore contrattato lavorando su vari team di prodotto (comprese le squadre di Exchange e Lync) di Microsoft.
Georg Hinterhofer è un Microsoft Certified Master per Exchange 2010. Egli lavora come ingegnere senior campo premier, concentrandosi su unicamente su Microsoft Exchange. Egli è basato in Austria, nei pressi di Vienna.