Troubleshoot Messaging Integration in SharePoint

發行項
08/18/2016

SharePoint 內幕疑難排解訊息整合

Pav Cherny

程式碼下載：SharePoint2008_08.exe(416 KB)

一般疑難排解方法
SharePoint 訊息架構
取得診斷資訊
輸出訊息傳輸
輸入訊息傳輸
目錄管理
結論

在設計良好的 SharePoint 環境中，資訊工作者不必為了共同作業而改變他們的通訊習慣或是工作常規。他們可以利用 SharePoint，將文件和其他資訊 (例如警示和提醒) 直接送到他們的信箱，而不必不斷手動檢查共同作業站台。

使用者也可以藉由回覆這些郵件，或是以電子郵件將新項目傳送到文件庫和清單等方式，來參與工作流程。

然而，將 SharePoint® 整合至安全的訊息環境中除了有其挑戰性之外，也讓非 SharePoint 元件有機可乘，而影響以 SharePoint 為基礎的共同作業。挑戰在於，要如何在整合環境內發生問題的地方，有效地隔離和消除問題的根源。

在本專欄中，我會根據一套經過實證且可快速獲得成效的疑難排解策略，來探討 SharePoint 訊息整合。原則是要有效地找出問題點，然後以更詳盡明確的疑難排解步驟，進一步鎖定問題所在。

在大型組織中，這類分階段調查可能表示在進行初步分析之後，把案子交由其他專家辦理，尤其當問題是與非 SharePoint 元件相關時更是。另一方面，在中小型組織中，單由一名 IT 系統管理員直接包辦疑難排解所有相關系統的工作是很常見的，這也更加指出使用結構化方法的需要。

為了讓本專欄利於練習，我使用了裝有 Active Directory®、Exchange Server 2007 和 WSS 3.0 的測試環境。建置此測試環境的逐步說明，以及在本專欄中提到的疑難排解工具，皆可在附隨的材料中找到，這些材料位於 TechNet Magazine 網站的「程式碼下載 (Code Downloads)」區段。

一般疑難排解方法

疑難排解 SharePoint 訊息整合，或許比其他互通性的案例還需要高度結構化的方法。而使這樣的企圖更為複雜的因素有好幾個。

很顯然地，您得處理複雜的技術，而光是訊息傳輸的問題、訊息格式轉換、安全性層面，以及目錄管理問題就已經夠惱人了，有些令人困惑的 SharePoint 錯誤訊息更是雪上加霜。網際網路新聞群組到處充斥著未經澄清的往來討論和建議，這些內容很可能會誤導您 — 像是建議在 SharePoint 中央系統管理的應用程式集區識別下執行所有 Web 應用程式，以便讓訊息整合能夠順利運作就是一例。

不過，還是有正面影響可言，那就是 SharePoint 極具彈性。事實上，如果您知道要往哪裡找的話，它可以提供您詳盡的疑難排解資訊。只要幾個基本的指令碼，您就可以大大提升疑難排解的效率。

疑難排解的首要目標，是了解您要應付的是什麼問題。您必須識別出問題的所在，以及它所牽涉的元件。您也可以在不同的系統設定下重現問題，然後研究 Windows® 事件記錄檔和文字記錄檔。但因為有些問題是偶發性的，可能需要一點技巧。儘管如此，越是能重現問題，就越能更快識別和消除它的根源。另外一個常受到忽視的重要目標，是將所有設定變更和修正動作全部記錄下來，並確定將它們套用到環境內所有相關的系統上 (例如 Web 伺服陣列中所有的前端伺服器)。

SharePoint 訊息架構

每當您碰到與訊息整合相關的問題時，不妨先喝杯咖啡或茶，檢閱一下 SharePoint 訊息整合架構，再進行疑難排解。不然，可能到最後修正的是錯誤的問題或元件也說不定。例如，阻止您在 Active Directory 中建立連絡人物件的「拒絕存取」錯誤，不見得表示您必須修正 Active Directory 中的存取權限，您稍後就會明瞭。

無論是哪種情況，重要的是了解訊息整合當中相關各個元件的角色，以及個別元件彼此互動的方式。您可從 [圖 1] 看出 SharePoint 與 Exchange 連線案例的重要元件，這在下一節會詳細說明。

[圖 1] SharePoint 訊息整合架構 (按一下以放大影像)

取得診斷資訊

可靠的診斷資訊是最重要的疑難排解工具之一。而最經典的，非 Windows 事件記錄檔莫屬。另外，您還可以使用 SharePoint 中央系統管理 (在 [作業] 頁面上的 [記錄與報告] 下，按一下 [診斷記錄]) 來控制 SharePoint 寫入網頁伺服器上的 Windows 事件記錄檔的詳細程度。您可以指定將最不重要的事件報告到事件記錄檔以及追蹤記錄。如果您要的是低層資訊，那麼追蹤記錄 (預設位於 %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Logs 下) 將非常管用，但是它填滿的速度很快，所以請節制使用此功能。

另外一種取得診斷資訊的方法，是設定相對應的 web.config 檔案來啟用受影響的 Web 應用程式的偵錯功能，如附隨資料中的 Web Application Config.pdf 所述。SharePoint 會將詳盡的追蹤資訊直接顯示在使用者介面中。這種方法的優點在於，您不用一一剖析好幾個 MB 的追蹤資料，就可以查看相關的錯誤資訊。缺點是您必須變更 Web 應用程式的系統設定。別忘了備份原始的 web.config 檔案，然後在完成疑難排解之後，還原成原始的設定。

您也可以設定 SMTP 服務，將詳細的處理資訊寫入 SMTP 通訊協定記錄檔 (在 IIS 管理員中，選取 [一般] 索引標籤上的 [啟用記錄] 核取方塊)。請務必如附隨資料中的 SharePoint Messaging Integration.pdf 所述，將 ODBC 記錄隨同 SMTP 服務功能一起安裝，即使您不打算使用 ODBC 記錄也一樣。否則，SMTP 服務將不會寫入通訊協定記錄檔。根據預設，SMTP 通訊協定記錄檔是位於 %SystemRoot%\System32\LogFiles\SmtpSvc1。它是一個文字檔，可讓您詳細分析 SMTP 通訊，並判斷訊息是否已離開 SharePoint 伺服器。

在 Hub Transport Server 與 SMTP 服務的通訊期間，您也可以在 [傳送連接器] 和 [接收連接器] 設定中啟用通訊協定記錄 (請參閱 SharePoint Messaging Integration.pdf)。您可以使用其他各種工具，來追蹤訊息在 Exchange Server 2007 環境中跨越 Hub Transport Server 和 Mailbox Server 所採用的路徑，例如訊息追蹤、佇列檢視器，以及管線追蹤。如果您想要關於疑難排解 Exchange Server 2007 郵件流程問題的詳細資訊，請參閱＜傳輸與郵件流程問題＞，網址是 go.microsoft.com/fwlink/?LinkID=120145。

在 Active Directory 網域控制站上，您可以啟用目錄存取和其他類別 (透過設定 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics 下相對應的登錄項目) 的診斷記錄，來收集詳細的疑難排解資訊。值為 0x0 的類別表示只會記錄重要的事件，而 0x5 的值則代表所有事件，包括偵錯資訊在內。使用高於 0x3 的記錄層級可能會折損伺服器效能，並且很快會填滿 Windows 事件記錄檔。在正常的操作期間，所有值都應該設為 0x0。

在疑難排解的情況下收集 SharePoint、Exchange 和 Active Directory 伺服器上的詳細診斷資訊，有利您迅速且可靠地找出問題點。其他疑難排解工具，像是 TCP/IP 工具 (ping、tracert、telnet 等等) 和網路監視器可能也很管用，因為這些系統之間的大部分通訊都是在電腦網路上進行。Microsoft® Network Monitor 3.1 可在 go.microsoft.com/fwlink/?LinkId=120143 上取得。

輸出訊息傳輸

資源

配備了事件記錄檔、追蹤記錄、通訊協定記錄檔、訊息追蹤記錄和網路追蹤後，就可以開始排解 SharePoint 訊息整合的疑難了。讓我們先從簡單的部分下手：輸出訊息傳輸。SharePoint 支援各種不同設定的輸出訊息傳輸，而且網頁伺服器上不需要有本機 SMTP 服務。不過，在完整的訊息整合案例中，還是建議使用本機 SMTP 服務。[圖 2] 顯示了此案例中的主要元件。

[圖 2] 輸出訊息傳輸 (按一下以放大影像)

此訊息案例包含四個階段：SharePoint 必須將訊息傳輸給 SMTP 服務，SMTP 服務必須處理訊息，Hub Transport Server 必須接收訊息，然後 Exchange Server 2007 必須將訊息傳輸到最終目的地。

如果 SharePoint 無法將訊息傳輸到 SMTP 服務，通常您會在使用者介面中收到錯誤，例如無法傳送電子郵件通知。原因可能是 SMTP 服務不在執行中的關係。或者，SMTP 通訊協定記錄有可能會以錯誤碼 550 (未採取要求的動作：無法使用信箱) 來告訴您它拒絕提交嘗試，這表明了問題是出在 SMTP 服務身上。

若要確認這不是 SharePoint 的問題，您可以使用一個基本指令碼 (請參閱附隨資料中的 SMTP.vbs)，以相同的寄件者和收件者資訊，提交一個測試訊息。如果是 SMTP 服務的問題，指令碼就會失敗。實際上，這個指令碼可提供您寶貴的線索找出問題的根源，因為不幸的是，即使啟用偵錯功能，SharePoint 也不會揭露這項資訊，如 [圖 3] 所示。

[圖 3] 無法轉送訊息 (按一下以放大影像)

您可以透過在 SMTP 服務設定中授權讓網頁伺服器進行轉送，然後重新啟動 SMTP 服務，來解決 SharePoint 訊息提交的問題。現在訊息既然可以抵達 SMTP 服務，下一個重要的問題是，SMTP 服務是否能將訊息路由到 Hub Transport Server。

如果訊息仍留在 [佇列] 資料夾，SMTP 服務便無法聯繫 Hub Transport Server。原因可能是 Microsoft Exchange Transport 服務不在執行中，或是網路通訊或設定的問題。不過只要利用 Telnet 用戶端，便可以迅速且輕易地查驗您是否可以連接到接收連接器的目的地連接埠，這個連接器是為了進行內部通訊而設定的。

這並不一定是 TCP 連接埠 25。事實上，如果 SMTP 服務使用這個連接埠，您可將訊息傳輸到 Hub Transport Server 的預設接收連接器，這個接收連接器是為了封鎖匿名訊息提交而設定的。在本例中，您會在 [放置] 資料夾中看到一個訊息檔案 (Windows SharePoint Services 計時器服務必須停止，否則訊息會在幾秒鐘之後消失)。訊息檔案是一種傳遞狀態通知，它會指出訊息已遭拒，並產生「診斷碼：smtp;530 5.7.1 用戶端未經驗證。」

為了解決這個問題，您應該為 SharePoint 伺服器建立專用的接收連接器。由於 SharePoint 伺服器是內部系統，因此請選取 [以外部方式保護安全] 驗證選項。這樣一來，您就不用授與匿名登入帳戶延伸的權限了。另外，也可以考慮使用 IPsec 來保護 SharePoint 伺服器與 Hub Transport Server 之間的通訊。

如果訊息離開 SMTP [佇列] 資料夾，而且 SharePoint 伺服器及 Hub Transport Server 上的 SMTP 通訊協定記錄 (請查閱 %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog\SmtpReceive 資料夾) 指出訊息順利傳輸，就算大功告成，只要 Exchange Server 2007 可以將訊息路由到目的地就行了。如前文所述，如果訊息沒有送達指定的 Exchange 收件者，請使用 Exchange Server 2007 內含的郵件流程疑難排解工具來調查任何問題。要注意的是，在這個階段，錯誤的收件者資訊、垃圾郵件篩選器和訊息大小限制都可能阻礙最終的傳遞。

輸入訊息傳輸

反方向的訊息傳輸則稍微複雜一些，因為潛在的問題更加難以捉摸。舉例來說，SharePoint 產品說明文件建議針對 SharePoint 電子郵件網域，設定 DNS 中的 MX 記錄，這很容易在 Exchange 的組織中誤送訊息。

Exchange Server 2007 是使用傳送連接器與相關的位址空間來傳輸訊息。即便您的 SharePoint 是內部的，它還是可能將 SharePoint 訊息路由到 Edge Transport Server，以便在網際網路上傳輸。對於內部訊息傳輸，請改用傳送連接器與詳細的位址空間，並在連接器設定中，將執行 SMTP 服務的 SharePoint 伺服器指定為智慧主機 (請參閱隨附的下載中的 SharePoint Messaging Integration.pdf)。以專用的 Bridgehead 伺服器來建立定義完備的路由拓樸，有助於達成 Exchange 至 SharePoint 間可靠的訊息傳輸。

為了查驗訊息確實抵達您的 SharePoint 伺服器，請停止 Windows SharePoint Services 計時器服務。如果不這麼做，訊息會堆積在 [放置] 資料夾中，因為計時器服務會處理訊息，並將檔案附件放到與收件者電子郵件地址相關的文件庫，如 [圖 4] 所示。假如訊息沒有抵達 [放置] 資料夾，請使用 Hub Trasnport Server 上的佇列檢視器來查看 Exchange 是否正確地路由訊息。之後再調查可能阻礙 Hub Transport Server 與 SharePoint 伺服器上的 SMTP 服務進行通訊的網路通訊問題。

[圖 4] 輸入訊息傳輸 (按一下以放大影像)

重新啟動計時器服務時，應該會看到訊息項目從 [放置] 資料夾消失。然而，若是 SharePoint 在 Windows 事件記錄檔中指出訊息處理順利，但訊息附件最後在目的地文件庫裡面卻沒有顯示成文件，這表示 Exchange 是以 Exchange RTF 格式來傳送訊息。若要調查這個問題，請再次關閉計時器服務，從 Outlook® 用戶端傳送另外一封含附件的訊息，然後等訊息抵達 [放置] 資料夾後，在記事本中開啟它。接下來請搜尋「winmail.dat」字串。如果找到此字串，表示 Exchange Server 傳送訊息的格式有誤。

SharePoint 要求訊息附件必須以 MIME 或 UUENCODE 格式編碼。此外，SharePoint 也不會在 Windows 事件記錄檔中顯示任何 winmail.dat 相關的處理問題 (見 [圖 5])。因此，檔案附件根本就不會顯示在文件庫中。您可以利用記事本作為疑難排解的工具，然後針對 SharePoint 電子郵件網域，在 Exchange 管理主控台中設定遠端網域定義，來消除格式化的問題。請在 [以日誌報告附件型式來傳送的原始郵件格式] 索引標籤的 [Exchange RTF 格式] 下，選取 [永不使用 (Never use)]。

[圖 5] Winmail.dat 訊息處理 (按一下以放大影像)

目錄管理

其中一個比較實用的計時器服務事件是事件 6873，它會指出處理內送電子郵件檔案時，因為別名不明而發生錯誤。如果 Exchange 使用者在傳送訊息時指定的 SharePoint 電子郵件地址有誤 (例如不存在的文件庫)，就會發生這個錯誤。

您可以在 SharePoint 中央系統管理內的 [內送電子郵件] 設定中，設定 [目錄管理服務]，以便在 Active Directory 中針對有啟用郵件的文件庫建立收件者物件，藉此緩和這個問題。Exchange 使用者隨後就可以方便地從通訊錄選取這些含有正確地址資訊的收件者物件了。

不過，要注意的是，您這樣等於是開了一大罐全新的疑難排解蟲。根據最低權限的原則，目錄管理服務會在保全的系統設定中失敗，因為這項功能在網頁伺服器上必須要提高權限才能使用。更麻煩的是，產品說明文件 (例如 technet.microsoft.com/library/cc262947.aspx) 在建議您必須在 Active Directory 中針對 SharePoint 收件者物件指定的 OU 裡面，授與中央系統管理應用程式集區帳戶「建立、刪除和管理使用者帳戶」的權限，也誇大其詞了些。

目錄管理服務會建立連絡人和群組物件，因此中央系統管理應用程式集區帳戶對這個 OU 中的連絡人和群組物件需要具備完整控制權，但它對使用者帳戶並不需要系統管理權限。假如您是據此在 Web 伺服陣列中設定目錄管理服務，然後試著啟用文件庫的郵件功能，就非常有可能會遇到「拒絕存取」錯誤。

錯誤資訊將問題的矛頭指向 Active Directory 權限，於是 SharePoint 系統管理員便迅速指派完整控制權給 SharePoint OU 的任何人。但是，這不但只會削弱 Active Directory 安全性，更不能解決問題。

結構化疑難排解要求您先找出問題點，然後套用鎖定目標的設定變更。如果您遵循這套方法，然後檢查網域控制站上的 Windows 事件記錄檔，或許也使用網路監視器來追蹤網路通訊，您可能會發現 SharePoint 在發生這個問題時，並沒有存取 Active Directory。因此，變更 Active Directory 設定不太可能會修正這個問題。問題是出在 SharePoint 伺服器身上。

不幸的是，要取得更多關於此權限問題的實用資訊比登天還難。SharePoint 並不會在 Windows 事件記錄檔中記錄任何額外的資訊。不過，如果您啟用 SharePoint 偵錯的話，可看到呼叫堆疊 (如 [圖 6] 所示)，它會建議目錄管理服務使用 SharePoint Web 服務的 CreateContact 方法。SharePoint SDK 會告訴您這是「電子郵件整合 Web 服務」(<WSS_server>:<admin_port>/_vti_bin/SharepointEmailWS.asmx)。

[圖 6] 偵錯輸出

Server was unable to process request. ---> Access is denied.
   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message,      WebResponse response, Stream responseStream, Boolean asyncCall) 
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[]      parameters) 
   at Microsoft.SharePoint.DirectorySoap.SPDirectoryManagementProxy.CreateContact(String Alias,      String FirstName, String LastName, String ForwardingEmail, ContactFlags Flags) 
   at Microsoft.SharePoint.SPList.UpdateDirectoryManagementService(String oldAlias, String      newAlias) 
   at Microsoft.SharePoint.SPList.Update(Boolean bFromMigration) 
   at Microsoft.SharePoint.SPList.Update() 
   at Microsoft.SharePoint.ApplicationPages.EmailSettingsPage.SubmitButton_Click(Object sender,      EventArgs args) 
   at System.Web.UI.WebControls.Button.OnClick(EventArgs e) 
   at System.Web.UI.WebControls.Button.RaisePostBackEvent(String eventArgument) 
   at System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String      eventArgument) 
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean      includeStagesAfterAsyncPoint)

讓我們以網頁瀏覽器瀏覽 SharepointEmailWS.asmx，看看受到支援的作業清單。您會看到 CreateContact 方法，如果您想要在 Active Directory 中建立連絡人的話，按一下 CreateContact 連結即可顯示您必須傳送到此 Web 服務的 SOAP 訊息。這一步相當管用，因為現在您就可以建立以指令碼為基礎的疑難排解工具 (請參閱附隨材料中的 SharepointEmailWS.vbs)，在 SharePoint 使用者介面外面工作，以方便在進行測試期間指定不同的使用者。[圖 7] 顯示您在中央系統管理應用程式集區帳戶 (左方) 下，以及在 SharePoint 系統管理員帳戶下 (右方) 執行此指令碼所傳回的資訊。

[圖 7] 兩種不同的「拒絕存取」錯誤 (按一下以放大影像)

錯誤訊息竟不相同！兩個訊息都指明存取遭拒，但是左方的錯誤表示是處理問題，而右方的錯誤則不然。那麼應用程式集區帳戶與 SharePoint 系統管理員帳戶之間到底有什麼差別呢？

SharePoint 系統管理員在 SharePoint 伺服器上是本機系統管理員，而應用程式集區帳戶則不是。雖然將 Web 應用程式的應用程式集區帳戶新增到本機 Administrators 群組，然後重新啟動網頁伺服器可以解決問題，但並不是什麼好主意。我認為在實際執行網頁伺服器上執行具備系統管理權限的應用程式集區帳戶並不妥當。

為什麼應用程式集區帳戶需要這些提高權限呢？同樣地，答案在於指令碼。如果您基於測試目的，在網頁伺服器上授與所有使用者本機系統管理員權限，您會發現即使所有其他帳戶 (包括 SharePoint 系統管理員在內) 都被拒絕存取，應用程式集區帳戶還是可以使用「電子郵件整合 Web 服務」。這表示「電子郵件整合 Web 服務」是根據應用程式集區設定來作出存取控制的決策。

應用程式集區設定是 IIS Metabase (在 IIS 7.0 中為 applicationHost.config 檔案) 的一部分，而 Metabase 預設只限本機系統管理員存取。所幸，您可以使用 IIS 6.0 Resource Kit 工具內含的 Metabase Explorer，授權讓非系統管理員帳戶存取 Metabase。在 IIS 7.0 上，要授與 applicationHost.config 檔案的完整控制權更加簡單，只要執行下列命令就行了：

CACLS "%SystemDrive%\Windows\System32\inetsrv\config\applicationHost.config" 
/G "<application pool account>" :F /E iisreset /noforce

總而言之，為了在 Active Directory 建立連絡人物件，中央系統管理應用程式集區對於目標 OU 中的連絡人和群組物件，必須具備完整控制權。而 Web 應用程式的集區帳戶在 Web 伺服陣列中的 SharePoint 伺服器上，必須能夠完整存取 Metabase。現在您可以開始使用 SharePoint 使用者介面來建立連絡人物件了。

等等，還不止這些呢！在 Active Directory 中建立收件者物件，只不過是目錄整合故事的前半段。後半段是產生 Exchange 相關的收件者屬性，然後更新以伺服器為主的通訊錄。比方說，如果您使用 Exchange 管理命令介面命令 Update-GlobalAddressList "Default Global Address List" 來更新 Exchange 伺服器上的全域通訊清單，可以在 Outlook 通訊錄中找到針對 SharePoint 文件庫新建的收件者物件。但是傳送訊息到這些收件者可能會產生因地址資訊錯誤而無法送遞的報告，如 [圖 8] 所示。

[圖 8] 無法送達文件庫的訊息 (按一下以放大影像)

IMCEAEX 是 Internet Mail Connector Encapsulated Address for Exchange 的縮寫。它表示舊版 Exchange Internet Mail Connector 其實可以處理封裝的非 Exchange 收件者地址的格式。但我們如今處理的是 Exchange Server 2007 和原生 SMTP 架構的傳送連接器。

重點是，SharePoint 電子郵件整合 Web 服務並不會寫入 Exchange Server 2007 進行訊息傳輸所需的地址屬性。它只會寫入名字、姓氏、顯示名稱和目標地址以及 ms-ExchRequireAuthToSendTo 屬性 (不過最後一項屬性可有可無)。但是它不會設定郵件別名，或是舊版 Exchange DN 或 Proxy 位址，也不會將收件者物件與 Exchange 收件者原則相關聯。

若要解決此問題，請使用 Exchange 管理命令介面中的 Get-Mailbox 指令程式，取得內含指向 SharePoint 電子郵件網域之目標位址的所有收件者物件。然後將輸出代入 Set-MailContact 指令程式，來啟動 Exchange 收件者原則，如下所示：

Get-Contact | where { $_.WindowsEmailAddress –like
  '*sharepoint.contoso.com' } | Set-MailContact
  -EmailAddressPolicyEnabled:$True

或者，您可以使用 Exchange 管理命令介面，並選取連絡人物件屬性中的 [依照電子郵件地址原則自動更新電子郵件地址] 核取方塊。

WSS 3.0 和 MOSS 2007 都支援現成的完整訊息整合，以啟用以電子郵件為主的警示和通知、工作流程和文件提交。正確設定系統雖然不是一件易事，但訊息整合可提升工作者的產能。更具體的說，您必須確定輸入和輸出訊息傳輸都能正常運作，同時也應該確保目錄整合能夠運作。

SharePoint 錯誤訊息不一定都很直觀，也不一定能提供參考資訊。但是我已經示範一些方法，可以找出整合問題根源、確定起因，以及如何在不危及 SharePoint 伺服器安全性的情況下可靠地消除問題。

Pav Cherny 是 IT 專家兼作者，專攻 Microsoft 共同作業與整合通訊技術。其著述包括白皮書、產品手冊和探討 IT 營運和系統管理的書籍。同時 Pav 也是專營管理文件與本土化服務之 Biblioso Corporation 的總裁。

共用方式為

其他資源