Exchange 佇列問題與解答：獲得正確的訊息

這個月，我們定期交換佇列 & 專欄作家被加入一個客人對解決您最傷腦筋的交換問題做出貢獻。

Henrik Walther

與來賓派遣喬治 Hinterhofer

郵件跟蹤

**問：**您可以共用提示或對你如何做郵件跟蹤兩個？ 我們發現要使用有限的 GUI。 我們正在尋求建議如何獲取所需的資訊的郵件跟蹤日誌。

**答：**使用 Windows PowerShell 的郵件跟蹤是可取的做法。 它為您提供更多的查詢參數控制，快得多。 典型的一行程式將是：

Get-TransportServer | Get-Messagetrackinglog –sender test@contoso.com –Start "03/18/2012 09:00AM"

這會將你的所有郵件跟蹤記錄從所有傳輸伺服器在您的環境中，有的 test@contoso.com，2012 年 3 月 18 日，起價 9 上午的發送位址 如果要將結果匯出到您的使用者或客戶，管道進入出口-CSVcmdlet 的結果：

Get-TransportServer | Get-Messagetrackinglog –sender test@contoso.com –Start "03/18/2012 09:00AM" | Export-CSV –Path c:\temp\messagetracking.csv

要深入進行故障診斷的結果嗎？ 為命令添加格式-listcmdlet：

Get-TransportServer | Get-Messagetrackinglog –sender test@contoso.com –Start "03/18/2012 09:00AM" | fl

為便於使用和抽出大量的輸入，它是寫自己小的 Windows PowerShell 函數的一個好主意。 這樣可以快速和有效的搜索。 此示例將搜索所有集線器傳輸伺服器中的日誌、 接受匯作為參數並搜索資料值得最後 24 小時：

functionmt {param ($sender) $SDate = (get-date).adddays(-1) get-transportserver | get-messagetrackinglog -sender $sender -start $SDate }

隨意適應此函數來滿足您的需要。 此外可以將這段代碼放置在 $ 設定檔.ps1 檔，所以它獲取啟動時載入。 從此以後，您只需鍵入：

mt –sender test@contoso.com

使用更新彙總套件

**問：**我們聽說我們可以使用 Exchange 2010 安裝源媒體上更新資料夾安裝在安裝過程中的匯總。 是這是準確的嗎？

答：是的這是準確的 — — 至少部分。 您可以使用更新目錄以新鮮的 Exchange 2010 安裝過程中安裝匹配的匯總並減小所需的安裝時間。 只是.msp 檔放到相應的目錄中，如中所示圖 1。

圖 1 添加到更新目錄.msp 允許您安裝匹配的匯總。

請不要嘗試這對於升級安裝，例如，發佈的第二次的服務包，或第一的服務包，到第二個服務包的製造。 這將不起作用，安裝將會失敗。 升級需要按順序進行，不能以這種方式將它們合併。 更多的資訊，在 TechNet 庫頁中，"安裝最新的更新彙總套件，對於 Exchange 2010."

SP1 或 SP2 嗎？

**問：**我們已到第二個服務包升級我們的 Exchange 2010 邊緣伺服器。 安裝完成，沒有錯誤。 不過，在用 Get ExchangeServer 望內部版本號，他們仍然顯示為 14.1.xx，aka SP1。 在這裡哪裡出了問題？

**答：**這是有點誤導，但實際上預期的行為。 邊緣訂閱後，Microsoft 不會更新生成數位作為定期 EdgeSync 進程的一部分。 如果您需要重做整個訂閱 （例如，如果您的證書用於 EdgeSync 過期），您將看到生成數位也會更新。

許可權的延誤

**問：**當我試圖授予 Exchange 2010 年的郵箱的郵箱完全控制許可權時，郵箱清單需要很長的時間來填充 （任意位置從幾分鐘到小時）。 有什麼可以做那件事嗎？

**答：**這是一個常見的問題。 在"選擇帳戶"視窗，慢慢地不當的 LDAP 查詢填充的理由。 您正在讀取的所有郵箱，並隨後應用篩選器。 如果你正在尋找一個名為"弗雷德"的郵箱，例如，將第一次獲得的所有安全主體的清單。 然後你會檢查之後是否其中之一是弗雷德的。 這一過程是緩慢的尤其是在大使用者計數裝置。

幸運的是不夠的安全增強功能的 Microsoft Exchange 或 Exchange(SE)，決定針對 Exchange 2010 SP2，即匯總 1 的最新和最大匯總中解決此問題。 此修復程式的直接連結這裡。

集成身份驗證

**問：**我們試圖啟用 Windows 集成身份驗證為動用 Outlook Web 應用程式 （OWA） 以獲得體面單一登入經驗為我們內部的加入域的客戶。 用戶端訪問一個稱為 https://mail.contoso.com 的網路負載平衡 (NLB) URL。

我們第一次啟動代理程式禁用，OWA 虛擬目錄上啟用 Windows 集成身份驗證。 但是，當試圖訪問 https://mail.contoso.com/owa，我們是仍然獲取憑據的提示。 當我們通過直接輸入一個用戶端訪問服務 (CAS) URL，例如，https://cas1.contoso.com/owa 或 https://cas2.contoso.com/owa，訪問 OWA 頁面時我們就被記錄沒有提示了。 要使它實際上更光怪陸離，如果我們在我們的案例 https://10.1.1.150/owa，鍵入的 mail.contoso.com，解決的 IP 我們是也登錄無須身份驗證。 您可以幫忙嗎？

答： 工作後向上和向下通過 Netmon 和小提琴手痕跡的路上，我終於發現使用的身份驗證方法的改變 （您可以看到這些在 小提琴手） 當我從 https://10.1.1.150/owa （工作，不提示） 切換到了 https://mail.contoso.com/owa （提示）。

原來訪問時解決的 IP，我們使用 Windows NT LAN 管理器來對 OWA 進行身份驗證。 切換到 NLB 完全限定功能變數名稱時，我們開始使用 Kerberos 去反對，民安隊。

多一點開挖施工和聰明地使用 setspn.exe – l 透露有人添加了一個稱為 http/mail.contoso.com 到完全不相關的電腦帳戶的服務主要名稱 (SPN) 項。 這反過來使用戶端電腦去 Kerberos 票證的 （因為在活動目錄中找到對應的項），然後提出 CAS 框中的票。 CAS 框顯然還不知道怎麼處理 Kerberos 票證發出一些完全不同的框，所以它扔多次身份驗證的提示。

假的 SPN 條目被刪除後，Windows 集成身份驗證開始工作立即針對 NLB URL 和身份驗證提示不見了。

免責聲明不和諧

**問：**我們試圖創建傳輸規則將添加到所有傳出郵件的免責聲明。 在測試期間，我們發現的運輸箱似乎忽略該規則。 它才添加所需的免責聲明，即使之後重新開機所有集線器框，以確保他們實際裝載該規則。 然而，同樣的規則有魅力，在我們的測試環境中工作。 你有什麼主意嗎？

答： 要執行此功能的實際規則看起來像所示 圖 2。

圖 2 此規則的目的是在外寄郵件的末尾添加免責聲明。

在檢查後像複製嫌疑，運輸服務不知道有任何改變，等等，一切看起來都正確。 然後我們檢查額外跟蹤處理傳出電子郵件時捕獲.etl 規則引擎。

.Etl 透露運輸服務充分意識到新的傳輸規則，但是無論是什麼原因沒有認出傳出郵件作為"傳出"。出於某些原因，他們被視為內部。

進一步跟蹤顯示規則引擎考慮為內部的遠端域中的"預設遠端域"條目。 因此，它才適用免責聲明規則。

在查看的問題，我注意到它說 IsInternal： 遠端域的預設值為 $true。 這會告訴治療要的位址空間中的所有郵件交換 ＊ 為內部 — — 並因此不適用免責聲明。 我們改回預設值設置為 false。 現在免責聲明被成功應用。

Henrik Walther 是 Microsoft 認證大師：Exchange 2007 和 Exchange MVP，而且在 IT 產業擁有 16 年以上的經驗。 他工作作為微軟金牌認證合作夥伴在丹麥，技術設計師和 Biblioso corp.的技術作者 （美國的公司是專門做管理的文檔編制和當地語系化的服務）。 他也是在微軟工作 （包括交換和 Lync 隊） 的各種產品團隊承包供應商。

格奧爾格 · Hinterhofer 是 Exchange 2010 年微軟認證的大師。 他作為總理外地高級工程師，只對 Microsoft Exchange 重點工作。 他根據在奧地利，維也納附近。

相關內容

• Exchange 佇列問題與解答：Exchange 變化多端
• Exchange 佇列問題與解答：移轉及更新
• Exchange 佇列問題與解答：關於 DAG