內部 SharePoint 將資訊版權管理整合到 SharePoint
Pav Cherny
可在程式碼下載: ChernySharePoint2009_05.exe(871 KB)
內容
AD RMS 實際執行環境和預先生產的階層架構
AD RMS 預先生產拓撲
預先生產伺服器組態
SharePoint IRM 的組態問題
Preproduction-特定的問題
編譯和登錄
測試的 IRM 保護裝置
部署自訂 IRM 的文件保護裝置
結論
Microsoft Office SharePoint Server (MOSS) 2007 隨附於根據資訊版權管理 (IRM) 架構的保護裝置。 這些 SharePoint 整合的好處具有 Active Directory 權限 Management Services (AD RMS) 提供 Microsoft Office 使用者。 不幸的是,Windows SharePoint Services (WSS) 3.0 不包含使用 IRM 保護裝置,現成。 不過,是解決方案。 如果您瀏覽範例應用程式,並在 MSDN 上的程式碼片段程式碼的圖庫],精華之間就會發現是, Microsoft Office 檔案格式保護裝置原始程式碼Microsoft 發佈在 8 月 2008 的。 原始程式碼有一個非專屬,世界各地,免 」 為-是"Microsoft 公用授權 (ms-PL)。 這會是很棒的尋找,因為這表示您可以將原始程式碼編譯,並且到 WSS 3.0 以及加入這些元件。 這的種方式中,您可以可以從任何 SharePoint 環境中 AD RMS 基礎安全性和相容性功能。
這個的資料行中,我會繼續與 AD RMS 的 SharePoint 整合的上個月的討論顯示您如何建立的 AD RMS 預先生產的開發環境、 編譯,IRM 保護裝置,以及整合 WSS 3.0 中編譯的元件。 您實際上不需要編譯,IRM 保護裝置,在預先生產環境,但是因為它反白顯示您在實際執行環境中可能會遇到一些一般 AD RMS 組態問題的一個有趣的練習。 您不必是 C / C ++ 開發人員瞭解 AD RMS 生產和預先生產的階層架構和如何影響部署 AD RMS,Microsoft Office 及 WSS 3.0 的概念。 而且不需要編譯並測試 IRM 保護裝置的 C / C ++ 開發技巧。 開發人員主題,例如擴充原始程式碼,或轉換整合自發的保護裝置,保護裝置已超出本文的範圍。 只有您會遇到的開發人員工作,是有關建立安裝專案,以簡化在部署已編譯的保護裝置元件,WSS 3.0 的實際執行伺服器上的幾下滑鼠。 小幫手 」 (可在程式碼下載頁面的 TechNet Magazine 上) 的資料可能會包含工作表] 和 [工具,引導您完成部署,編譯,及測試在執行 Windows Server 2008 的 x 64 版本的電腦上的程序。
AD RMS 實際執行環境和預先生產的階層架構
SharePoint,像其他任何想要加密或解密內容,使用 AD RMS 的應用程式必須經過數位簽署資訊清單簽署 AD RMS 階層架構將應用程式。 此資訊清單會定義這些模組可以和無法載入到位址空間之應用程式中,建立安全的環境中,並保護加密的內容,在記憶體中。 對於為有效資訊清單,它必須數位簽署藉由在憑證授權單位 (CA) 屬於的 AD RMS 憑證階層。 這可以使用的應用程式的簽署 CA,以獨佔方式由 Microsoft,實際執行階層架構,或者它可以是預先生產的階層架構,可讓開發人員 self-sign 應用程式資訊清單]。 請注意資訊清單可以屬於階層,但非兩者同時。 由在實際執行的 CA 所簽署資訊清單無效預先生產的階層架構中,反之亦然,因為階層有不同的根授權單位。 應用程式資訊清單中詳細地的討論, AD RMS SDK.
當您在 Active Directory 樹系中安裝在第一個的 AD RMS 伺服器時, 您會以隱含方式建立 AD RMS 階層架構。 預設狀況下,AD RMS 的安裝常式會使用 Microsoft DRM 伺服器自我註冊服務 CA 發行伺服器共享憑證 (SLC) 」 是階層架構,導致 Microsoft DRM 實際執行根目錄,在信任的根目錄的一部分。 [圖 1 ] 顯示衍生自生產 AD RMS 伺服器的 [SLC 此憑證鏈結。 如果要檢查 AD RMS 階層架構,在自己的環境中簽出小幫手] 資料,包括 AD RMS 憑證鏈結工具 (CertificateChain.exe)。
[圖 1 : AD RMS 應用程式簽章 Certifi cate 屬於 AD RMS 預先生產階層架構 。
Microsoft DRM 生產環境的根目錄會建立在實際執行階層架構中,],並 Microsoft 要求登入實際執行授權合約取得實際執行的憑證來簽署到實際執行的階層架構的應用程式必要條件的所有軟體廠商。 實際執行憑證的目的,是建立和登入發行的應用程式資訊清單。 供開發您應該改用預先生產的憑證。 原本,Microsoft 也會需要軟體廠商,來簽署開發授權合約取得預先生產的憑證,但是 (ISVTier5AppSIgningPubKey.dat) 公開金鑰、 私密金鑰 (ISVTier5AppSigningPrivKey.dat) 和相對應的預先生產憑證 (ISVTier5AppSignSDK_Client.xml) 都現在包含在 AD RMS SDK,讓您可以在開發期間簽署資訊清單,而不需要聯絡 Microsoft。 為快速筆記中,索引鍵和預先生產的憑證也包含 Microsoft Office 檔案格式保護裝置的原始程式碼封裝。
簽署應用程式資訊清單使用預先生產的憑證,則表示您無法在配合實際執行 AD RMS 伺服器中使用應用程式。 [圖 1 顯示,isvtier5appsignsdk_client.xml 憑證鏈結中的根目錄發行者是清楚地不實際執行伺服器的根目錄的 Microsoft DRM ISV 根。 您可以檢查 isvtier5appsignsdk_client.xml 使用我的 AD RMS 憑證鏈結工具。 它會遵循您需要使用不同的 SLC 在信任的根目錄中有 Microsoft DRM ISV 根 AD RMS 伺服器 (請參閱 [圖 1 )。 若要部署這類 AD RMS 伺服器,您必須建立獨立的 Active Directory 樹系,您的開發環境。
AD RMS 預先生產拓撲
使用獨立的 Active Directory 樹系最好讓一些思考 AD RMS 預先生產拓撲。 特別是,您必須決定是否要在獨立的伺服器] 或 [直接在網域控制站上,請安裝 AD RMS。 在大部分的情況下部署網域控制站已足夠開發用途使用。 請注意這是不實際執行環境的建議。 在實際執行環境,您必須不部署網域控制站上的 AD RMS,因為網域使用者帳戶指定為 AD RMS 的網路識別會再需要本機登入的網域系統管理員權限。 本機登入是在網域控制站上的系統管理員權限。 在成員伺服器,網域使用者帳戶不完全需要較高的權限。 如果不確定網域控制站問題,在實際執行環境中讀取 [Jason Tyler 部落格文章] 」 RMS 的 DON'Ts 與 dos." 相關的網域控制站將 RMS 概念,Jason 指出,這是這類錯誤的作法","每次我看到,我希望到告知,請挑選一個參數,並符合我在 toolshed 背後的人。
下一個問題是在網域控制站上安裝 WSS 3.0],[Office 2007 中及 [Microsoft Visual Studio 2008。 這裡您絕對應該即使在開發環境中使用獨立的伺服器。 為 「 AD RMS 的問題與 WSS 3.0 的安全性設定不同網域控制站,比較的成員伺服器上。 使用 [成員伺服器,您會保留一個相當於測試編譯元件時,提供更可靠的結果到 WSS 3.0 生產環境的組態。 不用說您可以將網域控制站和成員伺服器在單一的實體電腦上如果您使用 Microsoft Hyper-V Server 2008,如 [圖 2 ] 所示。 Hyper-V 會是 64 位元的虛擬化的技術,因此您可以將在 x64 Edition 的 Windows Server 2008 在兩個虛擬機器上。 請注意超 V Server 2008 不可以包含圖形化的管理工具,但您可以超 V 伺服器遠端管理工具上安裝個別的 Windows Vista 工作站述小幫手] 工作表的安裝 > Hyper-V 伺服器的遠端管理 Windows Vista 工作站上。
[圖 2 A 小型 AD RMS 開發環境 Hyper-V 主機 。
預先生產伺服器組態
安裝 「 Active Directory 權限管理服務 」 角色之前, 您必須設定特定登錄設定伺服器上,以便在 AD RMS 安裝 enrolls 預先生產的階層架構中的伺服器。 如果您略過此組態步驟,您會得到錯誤的階層架構。 請記住您無法移動 AD RMS 伺服器之間的階層。 如果您的伺服器在實際執行階層架構中註冊,您就必須解除安裝 AD RMS、 刪除 Active Directory 中的 AD RMS 服務連線點 (SCP)、 設定在的登錄和再重新安裝 「 Active Directory 權限管理服務 」 角色。
[圖 3 ] 列出登錄設定,決定在執行 Windows Server 2008 的電腦上的 AD RMS 階層。 階層參數設定為 1,可讓在預先生產的階層架構。 0 的值或沒有此參數的情況下則會表示 AD RMS 應該部署在實際執行階層架構中。 額外的登錄設定用於回溯相容性,但這不需要在我們的開發環境中。 如需詳細的資訊,請參閱 [AD RMS SDK 中 「 設定在 「 登錄 」 主題]。 下列程式碼都可以儲存為 AD RMS 伺服器上,預先生產的階層,以登錄 (.reg) 檔案。
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DRMS\2.0]
"Hierarchy"=dword:00000001
[圖 3 : AD RMS 用戶端都 can’t 存取 AD RMS 伺服器 。
SharePoint IRM 的組態問題
在 AD RMS 伺服器部署 」 和 「 組態是相當簡單的。 技巧是成員伺服器執行登入 SharePoint 到預先生產的階層架構的 WSS 3.0 的組態。 您無法只啟動 SharePoint 3.0 Central Administration、 切換至 [作業] 索引標籤,按一下資訊版權管理,和再選取選項使用預設的 RMS 伺服器 Active Directory 中所指定。 按一下 [確定] 將導致只顯示 [圖 3 ] 中的錯誤訊息。 訊息會顯示,AD RMS 用戶端 (msdrm.dll) 存在,它 Windows Server 2008 的預設安裝,但 AD RMS 伺服器是無法存取。
不幸的是,不是錯誤訊息,或追蹤記錄檔或顯示為 true 的問題性質的應用程式記錄。 一個選項,以取得更詳細的資訊是存取的追蹤登入,例如,https://adrms.litware.com:443/_wmcs/certification Explorer 中,直接中所指定的 URL。 很可能是 Internet Explorer 報告有 」 問題此網站的安全性憑證 」,如果預先生產 AD RMS 伺服器會使用自我簽署的 Secure Sockets Layer (SSL) 憑證,用戶端不信任的。 要信任伺服器的 SSL 憑證,您必須在本機電腦上 「 受信任的根憑證授權單位 」 存放區中安裝 SSL 憑證。 請確定將您憑證放置在本機電腦的實體存放區因為您必須讓憑證使用所有的 SharePoint 安全性帳戶,不只是您自己的使用者帳戶。 < 在 AD RMS 預先生產環境中部署 WSS01 > 小幫手] 工作表會說明步驟。
有時候,它很難處理的自我簽署 SSL 憑證。 SharePoint 的 AD RMS SCP,在 Active Directory 中,決定 AD RMS 憑證 Web 服務的 URL。 如果,SCP 會指定一個 URL,與不同的 Web 伺服器的 SSL 憑證中的主機名稱的主機名稱,Web 伺服器維持不受信任即使您在 「 受信任的根憑證授權] 存放區中安裝 SSL 憑證。 [圖 4 ] 顯示常見的組態案例,會導致此問題。 組態會使用的別名,在 AD RMS URL,與實際的主機名稱不同。 因為您無法變更 AD RMS URL AD RMS 伺服器的部署之後,但 CNAME 記錄可讓您 URL 指向不同的伺服器,必要時,這有助於伺服器維護與嚴重損壞修復。 如 [圖 4 ] 中的四個步驟指示,先,SharePoint 伺服器會查閱 AD RMS SCP,以判定 AD RMS URL 的 serviceBindingInformation 屬性。 接下來,它解析主機的名稱 adrms.litware.com dc01.litware.com 根據 CNAME 記錄。 SharePoint 會再連接到傳回 dc01.litware.com 的 SSL 憑證的 dc01.litware.com,並這會造成不相符的位址衝突]。
[圖 4 : SSL 憑證是不受信任,因為以一個名稱不相符 。
若要解決這個衝突,請在使用 SelfSSL 工具可以從網際網路資訊服務 (IIS) 6.0 Resource Kit 中取得發出 adrms.litware.com AD RMS 伺服器上的 SSL 憑證。 小幫手] 工作表的 < 在 AD RMS 預先生產環境中部署 DC01 >,包含下載資訊] 和 [逐步指示。
修正 SSL 會憑證問題都是以正常運作的設定,第一步,但受信任的 SSL 憑證不是唯一的需求。 如果嘗試設定 IRM,而不授與中央系統管理應用程式集區的讀取和執行存取的安全性帳戶會收到錯誤訊息前伺服器授與使用權限,IRM 會無法運作。 使用網域帳戶名稱: WSS01$@litware.com。 因為用戶端必須呼叫 certify AD RMS 憑證取得權限帳戶憑證 (RAC) 失敗因為遺失 ServerCertification.asmx 檔案的存取權限的 Web 服務的方法,您發生這個錯誤。 預設,只有 AD RMS 伺服器的 SYSTEM 帳戶擁有的存取。 建議的解決方案是從 ServerCertification.asmx 上的 [憑證] 資料夾繼承權限,然後與讀取中加入您的 WSS 3.0 伺服器的電腦帳戶,執行權限以及。 這會確保所有潛在的應用程式集區帳戶有必要的權限。 請參閱 [小幫手] 工作表,如需詳細資訊的 < 部署 DC01 AD RMS 預先生產環境中 >。
Preproduction-特定的問題
這時候,IRM Framework 應該是功能以外時,您是在預先生產環境。 請記住 AD RMS 用戶端和應用程式必須使用不同的憑證鏈結這裡。 如果嘗試在原始的設定中設定 IRM) 架構,」,需要的 Windows Rights Management 用戶端存在,但無法正確地,設定 」 收到 「 錯誤,並且追蹤記錄檔包含 「 電腦尚未啟用 」 的另一個有用提示。 這是 AD RMS 用戶端仍處於實際執行階層架構的指標。 您可以確認這在 「 登錄編輯程式 」。 檢查登錄機碼 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\uDRM\Hierarchy 和 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\uDRM\Hierarchy。 0 的值會指定在實際執行的階層架構。 變更這些值為 1,會啟動在預先生產的階層架構。 下列程式碼會列出.reg 檔以方便地套用組態變更。
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\uDRM]
"Hierarchy"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\uDRM]
"Hierarchy"=dword:00000001
不過,沒有會很驚訝登錄變更不會生效立即。 錯誤會保留,因為 AD RMS 用戶端已經產生的不正確的電腦憑證,在第一個成功的嘗試,而會繼續使用此憑證。 在您的 WSS 伺服器上開啟 [C:\ProgramData\Microsoft\DRM\Server] 資料夾,並刪除所有子資料夾] 及 [檔案]。 您也可以檢查 %LOCALAPPDATA%\Microsoft 資料夾。 如果它包含 \DRM 子資料夾,刪除子資料夾,因為它會儲存不再在預先生產的階層架構中使用的用戶端授權。 AD RMS 用戶端會重新建立這些子資料夾 」 和 「 中需要的憑證檔案。
切換回 SharePoint 3.0 Central Administration 請再次嘗試設定 IRM,並不要讓下一個錯誤訊息騙您: 為之前的相同的錯誤訊息,但錯誤原因實際上的不同。 追蹤記錄檔,且您將,找出"時發生問題建立並初始化安全性的 environment… 時 」 的核取 現在,這是一個資訊清單的問題 ! SharePoint 仍使用 AD RMS 的憑證鏈結工具實際執行資訊清單會顯示如果開啟 Stsprtid.xml 檔案位於 %PROGRAMFILES%\Common \ Microsoft Web 伺服器 Extensions\12\Bin 資料夾中 (請參閱 [圖 5 )。
[圖 5 : 實際執行的資訊清單 doesn’t 使用預先生產的階層 。
您必須刪除 (或重新命名) 生產 Stsprtid.xml 檔案,產生新的資訊清單使用 genmanifest.exe 工具包含在.AD RMS SDK 也為以 Microsoft Office 檔案格式保護裝置的下載套件,並重新啟動 IIS。 下載封裝也隨附 SharePoint 組態檔 (Sharepoint.mcf) 」 和 「 (genmft.bat 和 genmft.64.bat) 來簡化這項工作的批次檔。 仍然,64 位元環境裡的,批次檔只能簽署到預先生產的階層架構的 Microsoft Office 應用程式,並略過 SharePoint。 在 64 位元伺服器上,請登入 SharePoint,使用 [小幫手] 內容中包含 Sharepoint.bat 檔,或直接使用 genmanifest.exe 工具]。 命令語法
Genmanifest.exe -chain isvtier5appsignsdk_client.xml sharepoint.mcf
Stsprtid.xml
請參閱 genmanifest.exe 在 msdn.microsoft.com/en-us/library/aa362621 (VS.85) 的.aspx 頁面。
編譯和登錄
需要取代 SharePoint 的資訊清單檔案,您可以成功地完成 IRM 設定。 我們已完成硬碟的一部分。 現在的享有,回報編譯並測試保護裝置) 元件的時間。 這是簡單的任務。 原始程式碼隨附於 Visual Studio 2005 專案可以升級到 Visual Studio 2008 沒有問題。 不過,請記住您在 64 位元伺服器上使用。 Visual Studio 專案設定為 32 位元環境。 您必須變更此設定來編譯為 x 64 平台元件,如 [圖 6 ] 所示。 請參閱也小幫手] 的工作表 」 編譯、 測試,和部署 Microsoft Office 檔案格式保護裝置。
[圖 6 到使用 IRM 保護裝置,在 64 位元 WSS 伺服器上的,在編譯原始程式碼在 x64 平台 。
Visual Studio 會處理 COM 元件註冊一次建置,但是您仍然必須註冊,IRM 保護裝置在 WSS 3.0 中。 在 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\IrmProtectors 其類別識別項 (CLSID) 登錄元件。 以下是登錄檔,以完成這個步驟:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server
Extensions\12.0\IrmProtectors]
"{2E4402B2-F2DA-4BC8-BB2C-41BECF0BDDDB}"="MsoIrmProtector"
"{81273702-956F-4CBD-9B16-43790558EE29}"="OpcIrmProtector"
您也可以檢查 IrmProtectors.reg) 檔案,在小幫手] 內容的內容。 它包含的其他機碼,以供資訊目的之用。 我會包含這些機碼,因為,IRM 保護裝置的 MOSS 2007 會有類似的項目。 唯一的差別是 MOSS 保護裝置實際上使用它們的設定我們 IRM 保護裝置而使用硬式編碼的值時。
測試的 IRM 保護裝置
現在,注意,IRM 保護裝置的 WSS,您可以重新啟動 IIS,開啟您的 SharePoint 網站,設定文件庫中,AD RMS 原則建立、 上載,然後下載文件,以確認,IRM 保護裝置運作。 不過,這可以是費時,如果您 struggling 基本 COM 註冊的問題。 例如,如果您忘了啟動 x64-位元平台,在 Visual Studio,編譯處理序完成,而不會發生錯誤,但 COM 登錄保持完整,WSS 無法載入的保護裝置,而且您將不能夠測試 AD RMS 保護。 您可以先檢查 COM 登錄] 和 [在 SharePoint 中執行測試,才在登錄檢查顯示完成的成功,來儲存時間。 [圖 7 ] 顯示基本的指令碼檢查 COM 登錄。 它只會載入 COM 元件,並顯示結果訊息方塊。
On Error Resume Next
set MsoIrmProtector=NOTHING
set OpcIrmProtector=NOTHING
set MsoIrmProtector=CreateObject("MsoIrmProtector.MsoIrmProtector")
set OpcIrmProtector=CreateObject("OpcIrmProtector.OpcIrmProtector")
IF MsoIrmProtector IS NOTHING AND OpcIrmProtector IS NOTHING THEN
Wscript.Echo "Unable to load MsoIrmProtector and OpcIrmProtector."
ELSEIF MsoIrmProtector IS NOTHING THEN
Wscript.Echo "OpcIrmProtector loaded successfully, but
unable to load MsoIrmProtector."
ELSEIF OpcIrmProtector IS NOTHING THEN
Wscript.Echo "MsoIrmProtector loaded successfully, but
unable to load OpcIrmProtector."
ELSE
Wscript.Echo "MsoIrmProtector and OpcIrmProtector loaded
successfully."
END IF
[圖 7 請確定 IRM 保護裝置適當地為 COM 元件登錄在 SharePoint 中測試,保護裝置之前。
On Error Resume Next
set MsoIrmProtector=NOTHING
set OpcIrmProtector=NOTHING
set MsoIrmProtector=CreateObject("MsoIrmProtector.MsoIrmProtector")
set OpcIrmProtector=CreateObject("OpcIrmProtector.OpcIrmProtector")
IF MsoIrmProtector IS NOTHING AND OpcIrmProtector IS NOTHING THEN
Wscript.Echo "Unable to load MsoIrmProtector and OpcIrmProtector."
ELSEIF MsoIrmProtector IS NOTHING THEN
Wscript.Echo "OpcIrmProtector loaded successfully, but
unable to load MsoIrmProtector."
ELSEIF OpcIrmProtector IS NOTHING THEN
Wscript.Echo "MsoIrmProtector loaded successfully, but
unable to load OpcIrmProtector."
ELSE
Wscript.Echo "MsoIrmProtector and OpcIrmProtector loaded
successfully."
END IF
使用適當的登錄設定,Office 2007 文件格式 OpcIrmProtector 元件都是立即的功能性的。 不過,MsoIrmProtector) 元件,適用於舊版 Office 的格式會有的額外需求。 資料夾包含在 MsoIrmProtector.dll 也必須包含 \1033 子資料夾,與範本檔案。 範本檔案的原始程式碼,而會位於 \MsoIrmProtector\Templates 資料夾中。 您必須將這些檔案複製到 \1033 子資料夾] 中,以便 MsoIrmProtector 元件可以納入它們與不支援 AD RMS,Office 2000 和 Office XP 的 Office 應用程式的回溯相容性的 AD RMS–protected 文件處理。 否則,您將無法開啟舊版的 Office 文件。 舉例來說,您會收到這個錯誤,當您嘗試在文件庫中建立新的 Word 文件顯示在 [圖 8 。
[圖 8 Word can’t 閱讀此文件因為在 MsoIrmProtector 無法建立文件在適當的格式不範本檔案 。
部署自訂 IRM 的文件保護裝置
恭喜您 ! 您已成功建置、 註冊,並測試自訂的 WSS 3.0 的 IRM 保護裝置。 現在,如何您取得這些元件到 WSS 3.0 實際執行伺服器? 之後所有,您必須安裝,IRM 保護裝置在所有的伺服器上如果您要在實際執行環境中使用這些元件。 以手動方式執行部署是冗長乏味又容易出錯。 最好是建置安裝專案、 如何包含 DLL 和所需的檔案結構內的範本文件、 如何匯入 WSS 3.0 中, 整合元件所需的登錄設定以及如何部署,然後使用,產生的 Microsoft Windows Installer (.msi) 檔案。
它最好也要測試部署參考系統上。 除了其他的功用外這類的測試顯示很重要的必要條件您必須符合部署元件之前。 特別是,Visual Studio 2008 會將 Microsoft.NET Framework 3.5 SP1 的相依性 Setup.exe,並保護裝置元件需要 Microsoft Visual C ++ 可轉散發套件。 這是一個標準的需求,使用 Visual C ++ 編譯的 DLL 的可執行檔。 請確定可轉散發套件符合您在開發環境中所使用的版本。 例如,如果您使用 Microsoft Visual Studio 2008 SP1,然後部署 Microsoft Visual C ++ 2008 SP1 可轉散發套件 (x64). 「 測試保護裝置部署,Microsoft Office 檔案格式 」 的小幫手] 工作表會示範如何測試 IRM 保護裝置部署在單一伺服器上。
結論
IRM 以保護需要 MOSS 2007,所使用的 Microsoft Office 文件,但編譯 Microsoft Office 檔案格式圖庫,您可以將適當的 IRM 保護裝置元件整合到 WSS 3.0 以及 MSDN 程式碼上可用的保護裝置原始程式碼。 您也可以修改原始程式碼以實作自訂的功能,如果您有 C / C ++ 技術,並且會有在的 AD RMS 的預先生產環境中部署 SharePoint。 請記住您的修改會影響所有的 AD RMS–enabled 文件庫。 我建議保留不變,並在檢查定期進行更新和其他的功能可能是新版本 MSDN 程式碼庫原始程式碼,除非您是開發人員尋找好的範例.IRM Framework 中整合您自己的應用程式,否則。 在這種情況下原始程式碼會是一個很好的起點。
請記住 Microsoft 不沒有設計.IRM Framework 保護 SharePoint 資料庫中內容的項目。 您不應該變更解密常式,例如,或您的 SharePoint 使用者可能無法開啟文件,因為.IRM Framework 授與應用程式集區帳戶 」 和 「 目前使用者的 AD RMS 存取權限保護的內容時。 也請注意特定的保護裝置會需要其他的保護裝置,建立功能完整的系統。 例如,[MsoIrmProtector 保護裝置,以舊版的 Office 文件格式] 和 [Office 2007 格式,OpcIrmProtector 保護裝置屬於一起。 如果您部署,MsoIrmProtector 保護裝置,而在 OpcIrmProtector,Word 2007 使用者可能新文件使用,template.doc 內容範本建立在 SharePoint,Doc1.docx 為儲存檔案時。 MsoIrmProtector 的保護裝置會會 AD RMS 保護套用至 template.doc,因此 Doc1.docx 會最後在文件庫權限受保護的表單中因為沒有任何 OpcIrmProtector 保護裝置,來解密在上載內容。 應用程式集區帳戶 」 和 「 目前使用者仍然只可以開啟此文件的實體。 有其他方法來保護透過 AD RMS 的 SharePoint 內容資料庫中的文件例如,使用 ISPExternalBinaryStorage COM 介面。
Pav Cherny 是 IT 專業人員和作者,專精於 Microsoft 技術,協同作業的整合的通訊)。 他的出版物包含著重於 IT 作業] 及 [系統管理白皮書、 產品的手冊和書籍。 Pav 會是總裁的 Biblioso Corporation,公司的專長於 Managed 文件和當地語系化的服務。