逐步指南:使用 Microsoft Exchange Server 2003 SP2 部署 Windows Mobile 裝置

附錄 C:疑難排解行動訊息解決方案

發佈日期: 2006 年 12 月 22 日

本章節提供疑難排解工具的相關資訊,以及有關 Microsoft Direct Push 技術的詳細資訊和特定的疑難排解步驟,方便您區隔網路基礎結構內的行動能力問題。

本節包含有關下列主題的資訊:

  • 記錄和疑難排解工具

  • Direct Push 技術的相關問題

  • ISA Server 2006 的問題

  • 伺服器上的憑證實作問題

  • 前端與後端 Exchange 伺服器之間的通訊問題

  • 常見問題集

記錄和疑難排解工具

下列的疑難排解和記錄工具能幫助您追蹤和解決行動能力問題。

監視 Exchange Server 2003 SP2 的行動效能

若要追蹤 Exchange ActiveSync 及其他行動訊息元件的效能、可用性和可靠性,您可以使用 Exchange Server Management Pack。Exchange Server Management Pack 包含的規則和指令碼元件可驗證通訊服務的可用性、傳送測試電子郵件以確認作業,以及測量實際的傳遞時間。

Exchange Server 2003 SP2 中新增了下列新規則:

  • Exchange 資料庫大小限制

  • Exchange ActiveSync 組態設定

  • Exchange ActiveSync 最新通知效能

  • Exchange ActiveSync 錯誤

  • 監視智慧型郵件篩選的效能

  • 智慧型郵件篩選錯誤

  • 寄件者識別碼組態錯誤

  • 寄件者識別碼錯誤

  • 磁碟讀寫效能

  • DSAccess 設定

  • 公用資料夾複寫

「Exchange Management Pack 組態精靈」提供一個圖形化使用者介面 (GUI),可用來設定 Exchange 2000 和 Exchange 2003 Management Pack,包括測試信箱、郵件追蹤和監視服務。

您可以從 Microsoft 網站下載 Exchange Management Pack:http://go.microsoft.com/fwlink/?LinkId=55885 (英文)

《適用於 MOM 2005 的 Exchange Server Management Pack 指南》(英文) 中說明了如何使用 Exchange Management Pack 來監視和維護訊息資源。

您可以從 Microsoft 網站下載管理套件指南:http://go.microsoft.com/fwlink/?LinkId=58794 (英文)

ISA Server 最佳作法分析程式

若要判斷整體健康狀況,以及診斷常見的設定錯誤,請從 Microsoft 下載中心 (英文) 下載並執行 Microsoft ISA Server Best Practices Analyzer Tool。

Direct Push 技術的相關問題

如需 Direct Push 技術如何運作的詳細資訊,請參考本文內的 <了解 Direct Push 技術>。

一般 Direct Push 疑難排解秘訣

一般來說,系統管理員可以採取三個疑難排解步驟來解決連線問題:

  1. 確認行動裝置上的作業系統包含 MSFP。版本號碼為 148xx.2.x.x 或更新版本的 Windows Mobile 5.0 裝置包含 Messaging and Security Feature Pack。若要確認裝置上的作業系統版本,請依序選取 [開始]、[設定] 和 [關於]。

  2. 確認您的行動業者支援 Direct Push。由您的行動業者執行基本的疑難排解是很重要的,這樣一來您就可以確定行動業者在他們的行動資料網路上是否支援 Direct Push。

  3. 在行動業者的網路上針對 Exchange ActiveSync 提供行動裝置,並嘗試手動進行同步處理。如果可行,就代表網路支援基本的網際網路連線。

  4. 透過將裝置上的同步處理排程設為 [項目到達時],來啟用裝置上的 Direct Push 技術。傳送電子郵件至提供裝置的帳戶,並確認行動裝置可透過 Exchange ActiveSync 的方式立即與之同步處理。如果這個步驟可行,請等候約二十分鐘,然後再試一次。如果不可行,請確認行動業者的逾時是設為三十分鐘。

路徑疑難排解 Direct Push

在許多情況下,網路中的單一防火牆或閘道就可能引起計時問題,而阻礙 Direct Push 路徑。

  • 如果您的使用者遇到電池壽命短暫的問題,活動訊號間隔可能會過短。請洽行動業者來修改裝置活動訊號間隔。

  • 如果使用者的裝置有很長一段時間都未同步處理,可能是 Exchange 伺服器工作階段持續時間短於最大活動訊號間隔所致。請洽詢行動業者。

  • 裝置未同步處理另一個可能的導因跟防火牆設定有關。防火牆工作階段應該等於或大於行動業者網路上的閒置逾時時間,否則防火牆將會過早關閉工作階段。

在各種行動訊息案例下,都需要確保您的防火牆設定為可與 Exchange ActiveSync 和 Direct Push 技術正確運作。各個網路基礎結構互異,下圖描述的是典型的網路基礎結構,其中的防火牆閒置工作階段逾時需要調整為 30 分鐘。

Cc182278.cert_info(zh-tw,TechNet.10).gif

使用 30 分鐘的活動訊號間隔對電池壽命和頻寬的耗用皆有正面的影響。當允許 Direct Push 工作階段存留較長的時間時 (例如 30 分鐘),HTTP 的往返就比較少,收送的資料也比較少,還有裝置耗用的電源也較少。

在其他基礎結構的案例下,閒置工作階段逾時設定還可能包括 Exchange 2003 Server 與行動裝置之間的其他封包轉寄網路裝置或 Web 應用裝置。若要針對協力廠商防火牆或反向 Proxy 裝置修改閒置工作階段逾時設定,請參考硬體製造商的說明文件。此外,Microsoft 也與行動業者合作增加其傳出防火牆的閒置連線逾時,但是部署 Direct Push 技術的公司還是需要根據上述指示在他們的傳入防火牆上增加這些逾時。在 Microsoft 本身的部署中,防火牆逾時是設為 30 分鐘。

驗證 Direct Push 初始化

Exchange 產品小組寫了一篇文章,說明系統管理員為了區隔 Direct Push 問題可以採取的步驟。如需其他資訊及這篇文章的完整內容,請造訪下列連結:http://go.microsoft.com/fwlink/?LinkId=67080 (英文)

  1. 檢查 FE 上的應用程式記錄檔以查看下列事件,來確認已載入 Exchange ActiveSync 且已初始化透過 IP 的 AUTD。Exchange Activesync 會在第一次嘗試同步處理時初始化。

    Event Type: Information
    Event Source:     Server ActiveSync
    Event Category:   None
    Event ID:   3002
    Date:       3/19/2006
    Time:       12:44:08 PM
    User:       N/A
    Computer:   1B25A
    Description:
    Microsoft Exchange ActiveSync has been loaded: Process ID: [3048].
    
    Event Type: Information
    Event Source:     Server ActiveSync
    Event Category:   None
    Event ID:   3025
    Date:       3/19/2006
    Time:       12:44:19 PM
    User:       N/A
    Computer:   1B25A
    Description:
    IP-based AUTD has been initialized.
  2. 確認 FE 是在連接埠 2883 上接聽。

  3. 若要檢查伺服器是否是在 AUTD 連接埠上接聽,您可以執行「netstat -ano」。以下是透過 IP 的 AUTD 初始化前後的結果。

之前

Proto       Local Address     Foreign Address   State       PID

UDP         0.0.0.0:1985      *:*                           1928
UDP         0.0.0.0:3456      *:*                           3356

After

Proto       Local Address     Foreign Address   State       PID

UDP         0.0.0.0:1985      *:*                           1928
UDP         0.0.0.0:2883      *:*                           3048
UDP         0.0.0.0:3456      *:*                           3356

Netstat 提供處理程序識別碼,此識別碼會根據應用程式記錄檔中的初始化事件對應 EAS 處理程序。

另外一個檢查伺服器是否是在 AUTD 連接埠上接聽的方法是使用 PortQry (可自 Microsoft.com 取得)。下面列出在該連接埠上接聽的處理程序:

Process ID: 3048 (w3wp.exe)

PID   Port        Local IP          State             Remote IP:Port
3048  TCP 31479  172.29.8.222      ESTABLISHED       172.29.9.107:3268
3048  TCP 31480  172.29.8.222      ESTABLISHED       172.29.9.107:389
3048  UDP 2883    0.0.0.0                             *:*

使用記錄檔疑難排解 Direct Push 問題

  1. 若要啟用裝置記錄,請前往 [ActiveSync]、[功能表]、[設定伺服器]、[下一步]、[進階],然後將 [事件記錄] 開啟為 [Verbose]。記錄檔將儲存在 Windows\ActiveSync 資料夾中。PING 命令將記錄在「Ping Exchange Server x.txt」中,其中 x =1,2,3。您應該會看到類似下面的命令:

    POST Microsoft-Server-ActiveSync?User=administrator&
    DeviceId=6F24CAD599A5BF1A690246B8C68FAE8D&
    DeviceType=PocketPC&Cmd=Ping
    MS-ASProtocolVersion: 2.5
  2. POST 命令也會記錄在 FE 上的 IIS 記錄檔中。

    裝置上的 Ctrl 記錄檔也可以用來疑難排解 Direct Push 技術,不過此檔案的格式可能會隨裝置更新而變更。

    檢查 BE 上的 IIS 記錄檔,以查看是否已建立或更新 AUTDState.XML。您應該會看到類似下面的項目:

    PUT /exchange/Administrator@1b1domain.lab/NON_IPM_SUBTREE/
    Microsoft-Server-ActiveSync/PocketPC/
    6F24CAD599A5BF1A690246B8C68FAE8D/AutdState.xml

Cc182278.note(zh-tw,TechNet.10).gif 附註:

AUTDState.XML 是在收到第一個 PING 要求時建立,而且只會在活動訊號或資料夾清單變更時更新。因此您可能不會在每個 Ping 要求中看到此命令。

AUTD 狀態資訊是保存在信箱伺服器上每名使用者信箱的 NON_IPM_SUBTREE 內。

在 IE 中,您可以依序選擇 [檔案]、[開啟舊檔],核取 [開啟成網頁資料夾] 的方塊,並鍵入

http://server/exchange/user/NON_IPM_SUBTREE/Microsoft-Server-ActiveSync/Autd-State.XML

下面是範例 AUTDState.XML 檔案。

<?xml version="1.0" encoding="utf-8"?>
<AutdState xmlns="Ping:">
   <Version>1.0</Version>
   <HeartbeatInterval>680</HeartbeatInterval>
                <Folders>
  <Folder>
         <Id>7529a5b36290aa458b9e1fc2d5ff85a6-3aaa2</Id>
      <Class>Email</Class>
   </Folder>
   <Folder>
    <Id>7529a5b36290aa458b9e1fc2d5ff85a6-2cfb8</Id>
    <Class>Calendar</Class>
    </Folder>
 </Folders>
</AutdState>
UDP: Src Port: Unknown (33660); Dst Port: Unknown (2883); Length = 162 (0xA2)
    UDP: Source Port = 0x837C
    UDP: Destination Port = 0x0B43
    UDP: Total length = 162 (0xA2)
    UDP: UDP Checksum = 0xC233
    UDP: Data: Number of data bytes remaining = 154 (0x009A)
00000:  00 0E 0C 06 CA C0 00 D0 B7 24 86 2B 08 00 45 00   ....ÊÀ.Е$†+..E.
00010:  00 B6 C8 73 00 00 80 11 07 3A AC 1D 09 71 AC 1D   .¶Ès..€..:¬..q¬.
00020:  08 DE 83 7C 0B 43 00 A2 C2 33 4E 4F 54 49 46 59   .Þƒ|.C.¢Â3NOTIFY
00030:  20 68 74 74 70 75 3A 2F 2F 31 62 32 35 61 2E 31    httpu://1b25a.1
00040:  62 31 64 6F 6D 61 69 6E 2E 6C 61 62 3A 32 38 38   b1domain.lab:288
00050:  33 2F 33 35 33 39 35 63 65 34 2D 31 35 30 34 2D   3/35395ce4-1504-
00060:  34 61 63 34 2D 39 37 32 31 2D 66 31 35 32 63 36   4ac4-9721-f152c6
00070:  34 36 65 61 33 35 20 48 54 54 50 2F 31 2E 31 0D   46ea35 HTTP/1.1.
00080:  0A 53 75 62 73 63 72 69 62 65 2D 67 72 6F 75 70   .Subscribe-group
00090:  3A 20 55 73 50 43 57 77 46 4C 32 30 71 37 44 2B   : UsPCWwFL20q7D+
000A0:  6E 61 76 6F 4D 71 79 41 3D 3D 0D 0A 53 75 62 73   navoMqyA==..Subs
000B0:  63 72 69 70 74 69 6F 6E 2D 69 64 3A 20 32 37 0D   cription-id: 27.
000C0:  0A 0D 0A 00         

當使用 MSFP 裝置同步至 Exchange 2003 SP2 時遺失 Push Mail 和 GAL 查詢。

下文轉貼 Microsoft Technet 上的一篇部落格文章,說明系統管理員在同步至 Exchange 2003 時,用來區隔 Direct Push 電子郵件和 GAL 查詢時所採取的步驟。如需其他資訊及這篇文章的完整內容,請參閱下列的 Technet 部落格:http://blogs.technet.com/vik/archive/2006/10/17/push-mail-and-gal-lookup-missing-when-syncing-to-exchange-2003-sp2-with-a-msfp-device.aspx (英文)

在部署期間您可能會碰到這樣的問題:伺服器正在執行中,您可以順利進行同步處理,但卻看不到當項目到達時同步處理的選項,還有進行線上查詢 (Lookup Online) 的選項也不見了。這通常是防火牆問題所造成,因為 Options 動詞命令被封鎖的關係。

我們可以在裝置記錄檔上看到,從下列項目並沒有傳回 OPTIONS 命令的預期回應。請在裝置內從 [進階] 中的伺服器設定啟用裝置上的 Verbose 記錄來查看這些記錄檔。

=-= Build 14847 =-=
=-= No XIP Information Available =-=
Mail.company.com
=-=- [12/10/2006 2:28:59.0] -=-=
=-=-=-= Client Request =-=-=-= 
OPTIONS Microsoft-Server-ActiveSync?User=dptest&
DeviceId=6F24CAD599A5BF1A690246B8C68FAE8D&DeviceType=PocketPC 
Accept-Language: en-us
X-MS-PolicyKey: 0 
-=-=-=- Start of Body -=-=-=-
=-=- [12/10/2006 2:29:4.0] -=-=
=-=-=-= Server Response =-=-=-
HTTP/1.1 500 Internal Server Error 
( The system cannot find the file specified.  )
Connection: close
Pragma: no-cache
Cache-Control: no-cache
Content-Type: text/html
Content-Length: 2014

HTTP 500 是伺服器針對裝置所傳的 OPTIONS 命令所做的回應。

我們一般是在 URLScan 封鎖動詞命令時收到這個回應。所以我們必須檢查伺服器中的 URLScan。假如有出現 URLScan,那麼就可以將 OPTIONS 加入 URLScan.ini 檔案的 AllowVerb 區段。

IIS 記錄檔確認也有上述徵狀。

2006-10-10 04:01:13 W3SVC1 SCIDUBMSG01 10.251.99.165 POST
/Microsoft-Server-ActiveSync User=username&
DeviceId=02563C023942F3E168000050BF1977E0&DeviceType=PocketPC&
Cmd=Sync&Log=V1TCaSSC:0A0C0D0FS:0A0C0D0SP:1C3I3040S122000R0S0L0H0P 443 
consoto\username 209.95.228.19 HTTP/1.0 Microsoft-PocketPC/3.0 - - 
mail.company.com 200 0 0 326 516 249

請注意上述記錄項目中的 Log=V1 項目。

它指出使用的是 Airsync 通訊協定 1.0 版,然而若要使用 Push 功能,則應使用最新的 Airsync 2.5 版。

在理想的情況下,我們應該使用 Airsync 通訊協定 2.5 版,這將顯示為 Log=V4。

因此在 URLScan 中或任何封鎖 OPTIONS 動詞命令的軟體中允許 OPTIONS 動詞命令,應該就可以解決問題。

Sample Server response=-=- [16/9/2006 1:15:23.0] -=-=
=-=-=-= Server Response =-=-=-
HTTP/1.1 200 OK
Date: Fri, 15 Sep 2006 19:45:21 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Pragma: no-cache
Content-Length: 0
Public: OPTIONS, POST
Allow: OPTIONS, POST
MS-Server-ActiveSync: 6.5.7638.1
MS-ASProtocolVersions: 1.0,2.0,2.1,2.5
MS-ASProtocolCommands: Sync,SendMail,SmartForward,
SmartReply,GetAttachment,GetHierarchy,
CreateCollection,DeleteCollection,MoveCollection,
FolderSync,FolderCreate,
FolderDelete,FolderUpdate,MoveItems,
GetItemEstimate,MeetingResponse,
ResolveRecipients,ValidateCert,Provision,
Search,Notify,Ping

根據以上伺服器傳回的命令清單,裝置將決定要使用哪個版本的 AirSync 通訊協定。一些像是 Direct Push 技術或 AUTD 等不同的功能都有賴使用的通訊協定版本進行通訊。

檢查您 Exchange 伺服器上的 URLScan,並看看是否有任何其他裝置或軟體裝置封鎖 OPTIONS 命令。

URLScan 是供網站系統管理員使用的附加元件工具。系統管理員可以控制 URLScan 的動作,也可以限制伺服器處理的 HTTP 要求類型。URLscan.ini 檔案是此工具的組態檔,如果重新命名此檔案,URLscan 將無法運作,但一旦將檔名改回來就可以再度運作,而且毫無影響。

如需詳細資訊,請參閱微軟知識庫文件 <使用 IIS 的 URLScan> (http://support.microsoft.com/kb/307608)。本文的目的是要確保能有效散發網際網路資訊服務 (IIS) 安全性工具 URLScan。

編輯好 URLSCAN.ini 檔案之後,並不需要重新啟動伺服器,只要重新啟動 IIS 與 WWW 服務即可。

ISA Server 2006 的相關問題

下面是在 ISA Server 2006 的早期部署階段發現的問題。

從 ISA Server 2004 升級後需要雙重驗證

從 ISA Server 2004 升級之後,使用表單型驗證定義 Exchange 發行規則時,會提示使用者兩次提供他們的認證。在 ISA Server 2004 中,當您使用「新增郵件伺服器發行規則精靈」建立規則時,並不需要驗證委派,因為這會由 ISA Server 自行處理。但是將此規則升級至 ISA Server 2006 後,規則的驗證委派會設為 [無] 委派。

解決的辦法是針對受影響的規則將驗證委派手動設定為 [基本驗證]。

已移除當使用者離開網站時登出的功能

[在使用者離開網站時登出] 設定已自 ISA Server 2006 中移除。使用者應該永遠使用登出按鈕來確實登出 Outlook Web Access。

Windows Mobile 使用者收到錯誤 401 未授權

當 Windows Mobile 使用者嘗試存取使用「新增 Exchange 發行規則精靈」發行的 Outlook Web Access 或 Windows Mobile Access 網站時,使用者會收到錯誤 401,而不是 Exchange 登入表單。

當 Exchange HTML 表單設定目錄中遺失 Windows Mobile 所需的 HTML 表單目錄時,即會出現此錯誤

解決的辦法是在 %programfiles%\Microsoft ISA Server\CookieAuthTemplate\Exchange 資料夾中手動建立兩個目錄:cHTML 和 xHTML。然後將 %programfiles%\Microsoft ISA Server\CookieAuthTemplate\Exchange\HTML 資料夾的內容複製到 cHTML 及 xHTML 資料夾。

使用者收到拒絕存取的錯誤訊息

當使用者嘗試連線到發行的 Outlook Web Access 網站卻沒有在 URL 的最後加上 /exchange 尾碼 (例如,https://mail.contoso.com) 時,使用者並不是收到表單型驗證登入畫面,而是收到「拒絕存取」的錯誤訊息。這個錯誤可能很難排解,因為這是 ISA Server 的預期行為。

因應措施是發行 Exchange 前端伺服器的根目錄,採取「拒絕」的動作,並將使用者重新導向至適當的 URL,例如 https://mail.contoso.com/exchange。

請執行下列程序將使用者自動重新導向至適當的 Outlook Web Access URL。

建立 Exchange Web 用戶端存取發行規則
  1. 在 ISA Server 管理的主控台樹狀目錄中,按一下 [防火牆原則]:

    • 在 ISA Server 2006 Standard Edition 中,依序展開 [Microsoft Internet Security and Acceleration Server 2006]、[Server_name],然後按一下 [防火牆原則]。

    • 在 ISA Server 2006 Enterprise Edition 中,依序展開 [Microsoft Internet Security and Acceleration Server 2006]、[陣列]、[Array_Name],再按一下 [防火牆原則]。

  2. 在 [工作] 索引標籤上,按一下 [發行網站]。使用精靈建立規則,如下表中簡述。

頁面

欄位或內容

設定

歡迎使用

網頁發行規則名稱

鍵入規則的名稱,例如 Exchange_Redirect。

選取規則動作

符合規則條件時所採取的動作

選取 [拒絕]。

發行類型

請選擇這個規則將發行單一網站或外部負載平衡器、Web 伺服器陣列,或是數個網站。

選取 [發行單一網站或負載平衡器]。

伺服器連線安全性

選擇 ISA Server 將與已發行的 Web 伺服器或伺服器陣列建立的連線類型

選取 [使用 SSL 連線到發行的 Web 伺服器或伺服器陣列]。

伺服器憑證必須安裝在已發行的 Exchange 前端伺服器上,而根 CA 憑證則必須安裝在 ISA Server 電腦上。

內部發行詳細資料

內部網站名稱

鍵入 Exchange 前端伺服器的內部 FQDN。例如:exchfe.corp.contoso.com。

重要

內部網站名稱必須與安裝在內部 Exchange 前端伺服器上的伺服器憑證名稱一致。

若無法正確解析內部網站名稱,可以選取 [使用要連線到發行伺服器的電腦名稱或 IP 位址],然後輸入可由 ISA Server 電腦解析的必要 IP 位址或名稱。

內部發行詳細資料

路徑 (可省略)

在 [路徑] 方塊中鍵入 /。

公用名稱詳細資料

於右列接受要求

公用名稱

這個網域名稱 (在下方鍵入)

鍵入要 ISA Server 接受其連線的網域名稱。例如,輸入 mail.contoso.com。

選取網頁接聽程式

網頁接聽程式

選取之前建立的網頁接聽程式,例如 Exchange FBA。

驗證委派

選取 ISA Server 用來驗證到發行的 Web 伺服器的方法

選取 [基本驗證]。

使用者組

這個規則套用到來自下列使用者組的要求

選取核准存取此規則的使用者組。這應該跟 Exchange 發行規則中使用的是同一個使用者組。

完成新增網頁發行規則精靈

完成新增網頁發行規則精靈

完成以結束精靈。

伺服器上的憑證實作問題

如需疑難排解伺服器上憑證實作的相關資訊,請參閱 Microsoft Technet 網站上的 <憑證撤銷和狀態檢查> (英文):

http://www.microsoft.com/technet/prodtechnol/winxppro/support/tshtcrl.mspx

前端與後端 Exchange 伺服器之間的通訊問題

如需前端與後端通訊問題的相關資訊,請參閱 Microsoft 支援網路廣播 <疑難排解 Microsoft Exchange Server 2003 ActiveSync 問題> (英文)。

http://support.microsoft.com/default.aspx?scid=%2Fservicedesks%2Fwebcasts%2Fen%2Ftranscripts%2Fwct032504.asp

常見問題集

Exchange 產品小組寫了一篇文章,說明系統管理員為了區隔 Direct Push 問題時可以採取的步驟。如需部署 Direct Push 的詳細資訊,請參閱 Exchange Server 部落格文章 <Direct Push 只需一個活動訊號> (英文),網址是 http://go.microsoft.com/fwlink/?LinkId=67080

  1. Direct Push 技術可用於收件匣以外的資料夾嗎?

    可以,Direct Push 可用於郵件資料夾、連絡人、行事曆和工作。用於 Direct Push 的資料夾清單與設定用於同步處理的資料夾清單一樣。

  2. 什麼裝置支援 Direct Push 技術?

    Windows Mobile 5 裝置需裝有 Messaging and Security Feature Pack (MSFP) 才能使用 Direct Push。MSFP 附隨在 AKU2.2 中,所以任何裝有 AKU 2.2 的 Windows Mobile 5 裝置皆支援 Direct Push。AirSync 通訊協定已授權給幾家公司,例如 Palm、Motorola、Nokia、Symbian、Dataviz 和 SonyEricsson。請洽認可的廠商,看看是否提供具備 Direct Push 功能的裝置。

  3. Wi-Fi 支援 Direct Push 嗎?

    不支援,Direct Push 需要有行動電話資料連線。在 Wi-Fi 或 Desktop Passthrough (即當裝置插在連接座上時) 並不支援。

    基於硬體限制,Wi-Fi 無法進入待命模式並接收通知。因此,若要讓 Wi-Fi 支援 Direct Push,Wi-Fi 連線就必須一直保持作用中狀態,這樣很快就會耗盡電池。

  4. Direct Push 技術可與 SecurID 搭配使用嗎?

    RSA 的代理程式有個更新程式可讓它與 Direct Push 技術搭配使用。RSA Authentication Agent 5.3 for Web for IIS 可讓您使用 Exchange ActiveSync,而不需要在每次叫用 ActiveSync 時就得重新驗證。如需詳細資訊,請閱讀本文並洽 RSA。

  5. Direct Push 會影響伺服器效能嗎?

    典型 FE 會為數千個連線提供服務,範圍從使用 OWA、OMA、EAS 的用戶端到使用 RPC/HTTP 用戶端不等。根據 Microsoft IT 所做的測試,Direct Push 所開啟的額外連線並不需要部署任何其他 FE 或 BE 伺服器。它也不需要升級現有伺服器上的硬體。

    如需詳細資訊,請參考標題為 <Microsoft IT 使用 Windows Mobile 2003 和 Exchange Server 2003 行動訊息的延展性經驗> (英文),網址是

    http://www.microsoft.com/windowsmobile/business/strategy/scalability.mspx

顯示: