開發人員可以對 Microsoft Office 使用「自動化」，利用 Office 產品的內建功能與特性建立自訂解決方案。此類程式開發在用戶端系統上實行起來並不難，但是如果要從伺服器端程式碼 (例如 Active Server Page (ASP)、DCOM 或 NT 服務) 來執行自動化，情況就會複雜得多。

本文將討論開發人員可能面對的複雜情形，提供加速效能的自動化替代方案，以及如果無法避免伺服器端自動化時，設定 Office 的建議方法。然而，開發人員應該要瞭解，以下的建議僅供參考。Microsoft 並不建議或支援 Office 的伺服器端自動化。

注意 在本文中，「伺服器端」一詞亦指在 Microsoft Windows NT 或 Microsoft Windows 2000 工作站上執行的程式碼 (假如它是從登入使用者的互動式工作站以外的 WinStation 來執行)。例如，在 SYSTEM 帳戶下由工作排程器所啟動的程式碼是在和「伺服器端」ASP 或 DCOM 程式碼相同的環境中執行，因此會遭遇許多相同的問題。如需 WinStations 和 COM 的詳細資訊，請參閱＜其他相關資訊＞和＜參考＞等節。

回此頁最上方

所有目前的 Microsoft Office 版本均被設計、測試及設定做為用戶端工作站上的使用者產品。它們是採用互動式桌面及使用者設定檔，且不提供設計為自動執行的伺服器端元件所需要的重新進入或安全性等級。

目前 Microsoft 並不建議 (亦不支援) 從任何自動、非互動式用戶端應用程式或元件 (包括 ASP、DCOM 及 NT 服務等) 進行 Microsoft Office 應用程式自動化，因為在這種環境下執行，Office 可能會出現不穩定及/或鎖死的情形。

如果您要建構在伺服器端環境中執行的解決方案，應儘量使用可以安全地進行自動執行的元件，或者找到至少有部分程式碼可以執行用戶端的其他替代方案。如果您選擇從伺服器端解決方案使用 Office 應用程式，會發現它缺少許多順利執行所需的能力，且可能要冒解決方案整體穩定性不足的危險。

回此頁最上方

使用 Office 伺服器端自動化的問題

開發人員如果想在伺服器端解決方案中使用 Office，必須考量到以下五點，因為 Office 會由於環境之故，表現不如預期。如果希望程式碼能順利執行，請務必注意這五點，儘量將其影響降到最低。在建立應用程式時請仔細考量這些項目，因為沒有任何解決方案能處理所有問題，且不同的設計也需要改變這些因素的優先順序。

1.	使用者身分識別：即使 Office 應用程式是由自動化所啟動，在執行時仍會採用使用者身分識別。它們會根據啟動應用程式之使用者的使用者登錄 Hive 中的設定，嘗試初始化工具列、功能表、選項、印表機和某些增益集。許多服務是在沒有使用者設定檔的帳戶 (如 SYSTEM 或 IWAM_[servername] 等帳戶) 之下執行，因此 Office 在啟動時可能無法正確初始化，而傳回 CreateObject 或 CoCreateInstance 的錯誤。即使 Office 應用程式能夠啟動，沒有使用者設定檔，其他功能仍然無法正確運作。如果您計劃從某個服務自動化 Office，則需設定程式碼或 Office，讓它使用載入的使用者設定檔執行。
2.	與桌面互動：Office 應用程式假設它們是在互動式桌面之下執行，而在某些情況下必須顯現出來，特定的自動化功能才能正確執行。如果發生意外錯誤，或者需要某個未指定的參數來完成某項功能，Office 的設計是會以強制回應對話方塊詢問使用者要做什麼動作。非互動式桌面上的強制回應對話方塊是無法關閉的，造成執行緒無限期地停止回應 (擱置)。雖然特定的程式碼編寫準則有助於降低發生這種情形的機會，但仍無法完全避免。單單這個問題，就可能使得從伺服器端環境執行 Office 應用程式時危機重重，支援不足。
3.	重新進入與延展性：伺服器端元件必須是隨時可重新進入的多重執行緒 COM 元件，並具有最低負荷以及因應多重用戶端的高輸送量。Office 應用程式幾乎在所有方面都與這些需求相去甚遠。它們是不可重新進入的 STA 自動化伺服器，設計為單一用戶端提供多樣化但需要甚多資源的功能。做為伺服器端解決方案，它們的延展性極低，對重要元素 (例如記憶體) 也有無法透過組態設定來變更的固定限制。更重要的是，它們使用全域資源 (例如，記憶體對應檔、共用增益集或範本以及共用自動化伺服器等)，這些資源會限制可同時執行的執行個體數目，且如果是在多重用戶端環境中設定的，更會引發競爭。開發人員如果計劃同時執行一個以上的 Office 應用程式執行個體，必須考慮使用「共用」或序列化的方式存取 Office 應用程式，以避免發生鎖死或資料損毀的情形。
4.	恢復功能與穩定性：Office 2000、Office XP 與 Office 2003 採用了 Microsoft Windows Installer (MSI) 技術，讓使用者要安裝及自行修護時都更容易。MSI 引入了「第一次使用時才安裝」的概念，讓功能於執行階段 (針對系統，經常是針對特定使用者) 動態地安裝或設定。但在伺服器端環境中，這樣做不但會降低效能，還可能出現對話方塊要求使用者認可安裝或提供適當的安裝磁碟。雖然 MSI 是設計來強化 Office 做為使用者產品時的恢復功能，但在 Office 上實行其功能，卻會在伺服器端環境中產生反效果。此外，在執行伺服器端時，也無法保證 Office 的整體穩定性，因為它並非針對此種用途來設計或測試。在網路伺服器上使用 Office 做為服務元件，可能會降低該部機器、進而影響整個網路的穩定性。如果您計劃將 Office 伺服器端自動化，請試著將程式隔離到一部不影響重要功能，必要時可以重新啟動的專用電腦。
5.	伺服器端安全性：Office 應用程式從未被設想成用在伺服器端，因此也從未考慮到分散式元件所面臨的安全問題。Office 不會驗證傳入的要求、不會防止巨集不小心執行、也不會防止從您的伺服器端程式碼去啟動另一個可能執行巨集的伺服器。請千萬不要開啟從匿名網站上載到伺服器的檔案！根據前次的安全性設定，伺服器可能會利用「系統管理員」或「系統」的身分，以完整的權限執行巨集，破壞您網路的安全性！此外，Office 也會使用許多可快取用戶端驗證資訊的用戶端元件 (例如 Simple MAPI、WinInet、MSDAIPP)，以加速處理。如果 Office 在伺服器端被設定自動化，則一個執行個體可能會服務一個以上的用戶端，而由於驗證資訊已被快取供該工作階段使用，因此有可能某個用戶端可以使用另一個用戶端的快取憑證，以致可透過模擬其他使用者的方式取得未經許可的存取權限。

除了技術問題以外，還必須考慮此種設計在授權方面的可行性。目前的授權準則無法在伺服器上使用 Office 應用程式來服務用戶端要求，除非這些用戶端本身具有已授權的 Office 複本。「使用者授權合約」(EULA) 的條款中並不包含使用伺服器端自動化，替未授權的工作站提供 Office 功能。

除了這些較大的問題之外，許多客戶發現，若未修改其 Office 預設安裝，則在嘗試自動化伺服器端時，會收到下列其中一種常見錯誤：

?	CreateObject/CoCreateInstance 會傳回下列執行階段錯誤訊息，且無法啟動自動化。 在 Microsoft Visual Basic (VB) 或 ASP 中： ? 訊息 1 Run-time error '429':ActiveX component cannot create object (執行階段錯誤 '429'：ActiveX 元件無法建立物件) ? 訊息 2 Run-time error '70':Permission denied (執行階段錯誤 '70'：使用權限被拒) 在 Microsoft Visual C 或 Visual C++ 中： ? 訊息 1 CO_E_SERVER_EXEC_FAILURE (0x80080005):Server execution failed (CO_E_SERVER_EXEC_FAILURE (0x80080005)：伺服器執行失敗)? ? 訊息 2 E_ACCESSDENIED (0x80070005):Access denied (E_ACCESSDENIED (0x80070005)：拒絕存取) 會出現這些錯誤的原因，是因為伺服器端程式碼是在沒有使用者設定檔的情況下執行，或者為啟動環境指定的使用者身分識別沒有適當的 DCOM 權限。
?	開啟 Office 文件時，會出現下列其中一個錯誤： ? 訊息 1 Run-time error '5981' (0x800A175D):Could not open macro storage (執行階段錯誤 '5981' (0x800A175D)：無法開啟巨集的儲存處) ? 訊息 2 Run-time error '1004':Method '~' of object '~' failed (執行階段錯誤 '1004'：物件 '~' 的方法 '~' 失敗) 通常這都是因為權限不足或未註冊 VBA 元件，以致於無法初始化 VBA 所造成的結果，這兩種情形在使用者從沒有使用者設定檔的帳戶執行程式碼 (問題 #1)，以及使用者權杖不含互動式 SID (問題 #2) 等情況下都很常見。
?	CreateObject/CoCreateInstance 停止回應且無法完成，或者費時極久才傳回資訊。在某些伺服器上，雖然建立的動作很快就完成，但是 Windows (NT) 事件記錄檔中出現錯誤 1004。 這個問題通常是執行伺服器端程式碼的非互動式桌面出現強制性的對話方塊 (問題 #2)。如果出現此對話方塊的原因是 MSI 元件的安裝有問題 (遺漏登錄項目或檔案影像損毀)，當它找不到安裝點時，便會提示您插入安裝 CD，重新安裝其中的一或多個元件 (問題 #4)。
?	特定功能意外失敗或者無限期停止回應。 在非互動式桌面上 (問題 #2)，部分資源如印表機、對應磁碟、OLE 內嵌物件及剪貼簿等可能無法取得，或者其狀態變成未定義。同樣地，如果沒有使用者設定檔 (問題 #1)，網路資源就無法取得，使用權限亦會降到最低。
?	執行多重要求或壓力測試可能會讓程式碼在建立或終止某個 Office 應用程式時失敗、停止回應或損毀。一旦發生這種情況，處理程序可能會在記憶體中繼續執行且無法終止，或者被自動化之應用程式的所有執行個體從此點之後均會失敗。 由於 Office 應用程式共用全域資源 (問題 #3)，因此在執行某些特定動作時，必須以序列方式存取 Office 應用程式，包括啟動、關機、列印、匯出及 OLE 連結更新 (包括任何 DDE 通知) 等事件。

除了此處所列的問題之外，還可能出現其他問題或訊息，但成因仍不外以上五項。如果要避開這幾類錯誤，開發人員應將 Office 的作業環境設定成模擬用戶端狀態，或者從任何伺服器端程式碼中移除 Office 應用程式，改用更具延展性的元件 (或者用戶端自動化)。

回此頁最上方

執行伺服器端時使用自動化的替代方案

Microsoft 強烈建議開發人員，如果需要開發伺服器端解決方案，請儘量不使用 Office 自動化，改採其他替代方案。由於 Office 設計上的限制，對 Office 組態所做的變更並不能解決所有問題。Microsoft 提供許多替代方案，不需要將 Office 安裝到伺服器端，且執行大部分的常見工作時，要比自動化來得更快、更有效率。在專案中納入 Office 做為伺服器端元件之前，請先考慮使用這些替代方案。

大部分的伺服器端自動化工作都包含文件建立。由於 Office 2000 及更新版本均支援 HTML 做為原始文件格式，因此大部分文件均可使用 HTML 格式建立，必要時使用可延伸標記語言 (XML) 標記，並使用多用途網際網路郵件延伸標準 (Multipurpose Internet Mail Extension，MIME) 類型串流至用戶端，讓產生的文字顯示在 Office 中。只要使用伺服器上的 ASP，這些文件便可在有需要時進行編輯、儲存、甚至傳回伺服器。如果是舊版的 Office，使用其他易於操控的文字格式 (如 RTF) 亦可達到相同的效果。

有些原始二進位格式可以使用 Office Web 元件 (OWC) 或 ActiveX Data Objects (ADO) 來編輯，其速度和延展性較佳。文件內容可以在沒有自動化的情況下檢視或變更，檔案管理和版本處理也能使用 FrontPage Server Extensions (FPSE) 或「分散式撰寫及版本處理」(Distributed Authoring and Versioning，DAV) 來進行。如果一定要用到自動化，大部分的工作均可卸載至用戶端，以強化系統的穩定度和延展性，因為每個使用者均在自己的環境中以自己的設定執行工作。

如需這些主題及執行範例的詳細資訊，請按一下下面的文件編號，檢視「Microsoft 知識庫」中的文件： 如果貴公司需要在伺服器端建立二進位 Office 檔案，有一些協力廠商可提供對您有幫助的元件。下面是提供此類服務的一些知名廠商的清單。這份清單僅做為參考資料之用。這份清單並不包含所有的廠商。其他廠商或許可提供更適合您的類似服務。您應該調查所有可能的協力廠商解決方案，然後找出最能符合貴公司需要的廠商。下列廠商目前提供了一些解決方案，可用程式方式建立及編輯原始的 Office 檔案格式。如需有關協力廠商的詳細資訊，請造訪下列網站：

Aia Software B.V.Polar SoftArtisans SyncFusion Keylogix注意 本文提及的協力廠商產品是由與 Microsoft 無關的獨立廠商所製造。Microsoft 不以暗示或其他方式，提供與這些產品的效能或可靠性有關的保證。

回此頁最上方

將 Office 設定成可在伺服器端執行

如果所有解決方案都不實用，而您決定在伺服器端進行 Office 的自動化，請先處理之前所列的問題，才能從該環境順利執行。由於這些問題大多與組態設定有關，因此沒有一套步驟能套用在所有系統上，使其 Office 自動化在伺服器端順利運作。有些組態設定會和其他選項衝突，因此每種方式都各有優缺點。可能要經過幾次實驗，才能找出最適合您環境的一種。

要讓 Office 從伺服器端自動化，一般需要完成下列動作：

?	將專案設計成可隔離及封裝 Office。
?	將專案的程式碼撰寫成能預期問題，並以動態方式更正這些問題。
?	為專案提供一個特定的使用者身分識別及設定檔供 Office 使用。

您的專案設計必須考慮到伺服器端安全性，以及試圖使用 Office 自動化時 Office 不可重新進入等問題。將您對 Office 的使用，限制為由序列化物件 (mutex 或自訂鎖定基本項目) 所控制的特定執行個體，或從自訂物件處理常式 (或仲介)「共用」一組嚴密控制的執行個體，它在有需要時可以發行應用程式物件，但會控制需要序列化的部分。由於 Office 是使用特定數量的狀態，因此同時執行特定動作 (例如啟動、關機、列印等等) 的多重用戶端會造成衝突，並且可能會顯示錯誤、提示使用者輸入更多資訊或者拒絕釋出所有執行個體使用的全域資源，因而鎖死一或多個呼叫執行緒。

因此，第一個步驟是在您的伺服器端設計中限制 Office 自動化的使用，並將處理程序隔離到一部必要時可重新開機、不那麼重要的電腦上。同時亦請隔離呼叫內容，讓停止回應的呼叫用戶端不會減損基本系統服務的效能。例如，請勿從 IIS 內部利用系統執行緒直接自動化，而是改將程式碼隔離成在自己的執行緒上執行，如此一旦執行失敗，它也不會影響 IIS 整體的功能。同時也請考量您的設計能否強制安全性和驗證。由於 Office 不會強制執行伺服器端安全性，因此您的程式碼必須確定只有「受信任」的程式碼模組 (例如 ASP 網頁、指令碼檔等等)，才能建立 Office 應用程式的自動化執行個體及呼叫其方法，並在要求 Office 開啟文件之前，先確定所有文件都是安全的。伺服器上的 Office 應用程式隨時都應以「高度」安全性執行。若您的設計未強制執行安全性，就是拿您伺服器的安全開玩笑！

設計就緒之後，請以防禦的角度撰寫程式碼，以嘗試防止問題發生，並在錯誤發生時進行處理。確定您的程式碼會傳遞選擇性參數的值，因為遺失或發生衝突的值有時會需要 Office 提示使用者輸入其他資訊。在所有功能中使用錯誤捕捉，以順利處理錯誤情況，並使用可由自訂設定 (在登錄或 INI 檔案中) 開啟或關閉的記錄程式碼來記錄這些錯誤。如果您執行某個動作，而該動作可能會顯示與 Office 無關的錯誤對話方塊 (例如，列印時如果印表機紙張用完，可能會讓印表機驅動程式顯示對話方塊) 時，請使用逾時或第二個執行緒來監視進度，以準備處理可能的鎖死情形。如需詳細資訊，請參閱「Microsoft 知識庫」中的下列文件： 使用您的記錄程式碼來追蹤問題以及除錯程式。如果您使用自訂物件集區，可以加入效能及延展性測試來監控使用並記錄影響所有用戶端的問題。中央控制器也能讓您終止錯誤的 Office 執行個體，再於必要時重新建立，以強化整體的穩定性。

在程式準備可以部署之後，請確定 Office 在伺服器上的設定是否適當，可以執行合適的使用者內容。Office 需要有使用者設定檔，如果要順利地自動化，必須確定已載入使用者設定檔。在伺服器端環境中工作時，有三種方式可以完成這項工作：

?	將自動化所啟動的 Office 應用程式的所有執行個體，均設定成以互動式使用者的身分執行。
?	將自動化所啟動的 Office 應用程式的所有執行個體，均設定成以特定使用者的身分執行。
?	將您的程式碼設定成可以特定使用者的身分識別執行，方法為使用 MTS/COM+ 封裝並允許 Office 應用程式繼承啟動該應用程式的使用者身分。

第一個選項同時為 Office 提供身分識別以及與特定桌面的互動，除錯時最好使用這個選項 (因為 Office 可以設定為顯示，而本機登入的使用者亦可看到及記錄對話方塊或 GPF 錯誤)。由於它要求互動式使用者要維持登入狀態才能順利執行，因此可能不適合某些情況。如需詳細資訊，請參閱「Microsoft 知識庫」中的下列文件： 第二個選項會指派特定使用者，但不允許互動。Office 會以被指派的使用者身分在隱藏的桌面上的新 WinStation 中啟動。這個選項需要一些額外設定，以確保載入使用者登錄 Hive，因為 COM/DCOM 預設不會執行這項工作。這項設定是系統共用的，因此可能會與其他程式衝突。如需以此種方式設定 Office 的詳細資訊，請參閱「Microsoft 知識庫」中的下列文件： 第三個選項可讓您指派身分識別給特定的網站或程式碼模組，並避免設定一個全域性的固定身分識別給 Office。只要該電腦上先前已設定此身分識別，並且已載入登錄 Hive，Office 便會以該身分識別執行並正確載入。這個選項通常最有彈性也最安全，但是和前一個選項一樣，它也無法提供與可見桌面的互動，而且需要額外的設定。如需以此種方式設定 Office 的詳細資訊，請參閱「Microsoft 知識庫」中的下列文件： 您必須評估上述何種方式符合您的需求，以及對部署您的解決方案有何幫助。此處提供的資訊並不保證能夠解決所有用戶端的所有問題。建議您在部署之前先進行完整的測試。

回此頁最上方

如需有關伺服器端自動化的詳細資訊，請參閱「Microsoft 知識庫」中的下列文件：

回此頁最上方