更多有關 SharePoint 2013 中高信任度應用程式的疑難排解祕訣

英文原文已於 2012 年 11 月 2 日星期五發佈 嗨,我是一位應用程式設計人員,我喜歡進行開發,但是,老實說 – 如果我需要追蹤一個以上有關新 SharePoint 應用程式的「Token 的發行者不是受信任發行者」問題,那麼我可能會對著電腦大聲嘶吼。為了嘗試協助您保護您的聲音 (和理智),我將從此處列出的事項清單開始 (這是我在遇到此問題時所查看的清單)。當我發現引發此問題和可解決該問題之令人興奮的新方法時,就會更新此處的文章,並在下方擲出「已更新!」的字樣。 請務必記住,當我說「高信任度應用程式」時,表示您並未使用 ACS 做為 SharePoint 應用程式的信任代理人;而是您的應用程式會改為建立 OAuth Token 並利用您自己的憑證來簽署它。我知道我們已在他處詳細記載這整個程序,因此不打算在此再次說明此程序。我將假設您已閱讀過該程序且已嘗試執行該程序,而現在您已經準備好來向您的螢幕舉手致敬。但是,話雖如此,我還是會在此處提供看見此錯誤發生的方法: 新增至 SPTrustedRootAuthority 清單 – 當您使用憑證來簽署 OAuth Token 時,需要建立 New-SPTrustedRootAuthority。就像 SharePoint 2010 中的 New-SPTrustedIdentityTokenIssuer,您需要將 Token 簽署的憑證和鏈結中的每個憑證新增至 SharePoint 的信任授權單位清單。您可以遵循此程序的相同步驟,如同我在下列文章中所述:http://blogs.technet.com/b/speschka/archive/2010/02/13/root-of-certificate-chain-not-trusted-error-with-claims-authentication.aspx (可能為英文網頁)。只需忽略從 ADFS 匯出憑證的相關資訊即可 – 我假設您已經透過某些其他工具,為您的高信任度應用程式建立憑證 – 公用根 CA (例如,GoDaddy、VeriSign 等)、自我簽署憑證或網域發出的憑證。 用戶端識別碼使用全部大寫的字元 – 如同我在其他文章中所述,請確定當您在應用程式的 AppManifest.xml 檔案中插入用戶端識別碼時,不會使用大寫字母,或者如果您正在建置自我裝載的解決方案,不會在…

0

如何達到搜尋結果的最佳有效時間?適用於 SharePoint 的連續編目簡介

英文原文已於 2012 年 9 月 15 日星期六發佈 對象:搜尋管理員/IT 專業人員先決條件:本部落格假設讀者已經具備有關 SharePoint 搜尋拓撲、編目機制,以及編目排程原則的基本搜尋管理知識。附註:此功能是 SharePoint 2013 的新功能。 什麼是搜尋結果的有效時間?在使用者將文件上傳至其 SharePoint 網站之後,在文件可透過 SharePoint 搜尋入口網站進行「搜尋」之前的這段時間稱為有效時間的延遲。 有效時間的依據是什麼?有很多因素 – 存放庫的大小、變更速率、來自存放庫的要求回應時間、編目排程、變更的類型。這是因為若要讓文件可供「搜尋」,需要觸發編目 (可以手動或透過排程自動觸發),變更需要進行識別、要求和處理。 所以,問題是什麼呢?傳統上,會在 Sharepoint 搜尋中提供兩個排程選項 – 完整編目或累加編目。完整編目會開始探索整個主機,而累加編目只會處理主機中自從上次發生編目之後已變更的項目 (可能是使用每份文件的時間戳記比較,也可能是針對追蹤已修改之文件的存放庫使用預先存在的變更記錄)。為了達到較長的有效時間,建議的處理方式是讓累加編目更積極進行 (例如,每天每 30 分鐘執行一次)。 完整編目與累加編目的其中一項限制是它們無法平行執行,例如,若有某個完整編目或累加編目正在進行,則系統管理員便無法在該內容來源上開始另一個編目。這會對編制項目索引的方式強制執行先進先出處理方式。此外,某些類型的變更會導致執行階段延長 (例如,在主機根層級上的原則變更,表示整個主機需要重新編制索引以更新每個已索引項目的安全性描述元)。將這兩個因素結合在一起會導致有效時間產生變動,即使已設定經常性累加編目排程也一樣。為了說明這一點,以下為累加編目的預期心理模型 (相較於現實世界),之後緊接著該系統的有效時間。       所以,該如何修正?連續編目的簡介我建議針對 SharePoint 類型的內容來源使用編目選項,提供免排程的替代項目來管理內容來源。基礎結構是設計來藉由克服完整/累加編目的兩個基本限制,確保一致的有效時間: 它們可以平行執行 一個深度變更將不會導致後續所有變更的有效時間降級 告訴我更多資訊…幕後作業是,選取連續編目將導致每 15 分鐘啟動一次編目,而不論之前的工作階段是否已完成。這表示在深度變更之後立即進行的變更不需要在後面「等待」。當深度原則變更在其他連續編目工作階段上運作時,新變更將持續進行平行處理。以下圖表說明連續編目如何每 15 分鐘平行向上微調,以協助管理突然增加的內容量,而不會影響整體有效時間。下圖說明對於在累加編目上使用連續編目來達到之有效時間的影響。     那麼,我還需要知道哪些內容?在後續部落格中,我們將更詳細地檢閱連續編目如何處理不同類型的案例 (錯誤、安全性等),以及您如何使用編目記錄檔和編目記錄,更深入了解其中發生哪些狀況。 常見問題集: 我可以針對所有類型的內容來源使用連續編目嗎?否。連續編目僅適用於 SharePoint…

0

適用於表單型驗證的新 SharePoint Server 2013 測試實驗室指南

英文原文已於 2012 年 9 月 27 日星期四發佈 測試實驗室指南:示範利用 SharePoint Server 2013 進行的表單型驗證 (可能為英文網頁) 現在已可供使用。本指南將為您示範如何將適用於使用者存取的表單型驗證設為 SharePoint 2013 三層式伺服器陣列的預設小組網站。其中會針對下列內容提供逐步指示: 步驟 1:設定 SharePoint Server 2013 三層式伺服器陣列測試實驗室 (可能為英文網頁)。 步驟 2:使用輕量型目錄存取通訊協定 (LDAP) 成員資格提供者來設定表單型驗證。 步驟 3:示範從 CLIENT1 進行的表單型驗證。 本指南是 TechNet Library 中設定宣告式 Web 應用程式的表單型驗證所述之程序的測試實驗室版本。 下圖顯示這本新指南的測試實驗室組態。其中並未新增任何新的伺服器。 利用最近的新增功能 (包含社交功能 TLG (可能為英文網頁) 和第二個伺服器陣列 TLG 迷你模組 (可能為英文網頁)),SharePoint Server 2013 的 TLG 堆疊現在看起來如下: 如需詳細資訊,請參閱 SharePoint Server…

0

指定您的 ADOMD.NET 資料提供者版本

英文原文已於 2012 年 9 月 12 日星期三發佈 我前陣子寫了一篇有關如何讓您的 PerformancePoint 2010 安裝使用 SQL 2012 的文章。該文章談論到可在何處找到 SQL Server 2008 R2 SP1 Feature Pack,此外,此套件還包含了 ADOMD.NET 資料提供者版本 10.5.2500,而 PerformancePoint 需要此版本才能連線至任一個 2012 Analysis Services 資料來源 — 包括 PowerPivot 活頁簿模型在內。這非常適合用於 PerformancePoint 2010,但是,如果您需要在 PerformancePoint 2013 執行個體中使用相同功能,則使用 SQL 2012 時,您將需要 ADOMD.NET 資料提供者的主要版本 11.0。您可以經由 spPowerPivot.msi,在此處 (可能為英文網頁) 下載該版本。 狀況說明 此時,當您在安裝 SQL Server 2012 SP1 執行個體時只想安裝…

0

新的測試實驗室指南:示範 SharePoint Server 2013 Preview 的社交功能

英文原文已於 2012 年 9 月 18 日星期二發佈 測試實驗室指南 (TLG)<示範 SharePoint Server 2013 Preview 的社交功能 (可能為英文網頁)>說明如何開始使用基本組態 (可能為英文網頁) 和三層式 (可能為英文網頁) 測試實驗室中的電腦,來設定和示範 SharePoint Server 2013 Preview 的社交功能。 這個 TLG 會帶領您完整進行 SharePoint Server 2013 Preview 的下列社交功能: 我的網站 關注 社群網站 小組網站 (包含網站摘要) 其中會針對下列內容提供逐步指示: 設定基本組態測試實驗室 (可能為英文網頁) (如果您尚未完成此動作)。 設定三層式 (可能為英文網頁) 測試實驗室 (如果您尚未完成此動作)。 建立 [我的網站] 網站集合並進行設定。 設定 [關注] 設定。 安裝及設定社群網站。 設定小組網站。 示範 SharePoint…

0

報名參加 2012 年在拉斯維加斯舉行之 SharePoint 會議的 SharePoint 設計階段研討會

英文原文已於 2012 年 9 月 26 日星期三發佈 您今年想要參加 SharePoint 會議 (可能為英文網頁) 嗎? 我們將再次為個別客戶提供場數有限的專門解決方案設計研討會。 這些設計階段研討會的目的是協助 IT 專業人員 (在某些情況下還包含開發人員) ,根據 SharePoint 2013 產品來展望與規劃解決方案。 沒錯,這些諮詢研討會都是免費提供給選定來參加 SharePoint 會議的候選人來參與。立即為您的公司報名! 研討會將持續 60-90 分鐘。如果您被選上,將能遇見一或多位產品專家 (Microsoft 產品小組成員、顧問或已獲認證的主題專家) 來討論您的解決方案目標、獲得有關目前挑戰的建議,以及展望如何使用 SharePoint 2013 產品來增強您的解決方案。SharePoint 文件小組成員 (在 TechNet、MSDN 及 Office.com 上發佈內容的成員) 將協助舉辦這些研討會。 我們目前正針對下表所列的建議類別來招募將參加 SharePoint 會議的客戶。 建議的專長領域 說明 商務智慧 您是否對於如何在企業環境中實作新的商務智慧功能感到興奮?您想要在 Excel 和 SharePoint 儀表板中整合 PowerPivot 資料模型和 Power View…

0

首選哪裡去了?查詢規則簡介

英文原文已於 2012 年 9 月 19 日星期三發佈 對象:搜尋管理員/IT 專業人員先決條件:本部落格假設讀者已經具備基本的 SharePoint 2010 搜尋管理知識。 如果您曾經在 SharePoint 2010 產品上管理過「搜尋」,就可能已建立過 [搜尋關鍵字] 和 [首選]。它們或許是讓您將結果升級到頁面最上方 (以您想要的順序),藉以改善特定查詢相關性的最簡單方式。但在 SharePoint 2013 Preview 中,您將無法在 [網站設定] 中找到 [管理搜尋關鍵字] 連結。 這是因為 [搜尋關鍵字] 已經發展為某個更具彈性的功能:查詢規則。以下為差異之處。 搜尋關鍵字表示『當查詢為「影像庫」時,將我們的影像庫連結升級』 查詢規則表示『如果「看起來像是使用者想要使用影像」,就顯示「有用的影像結果。」』 查詢規則的功能就是這個一般性。比起僅比對特定查詢,它們讓您能夠推論使用者的想法;比起僅將特定結果升級,它們可以完整顯示與使用者查詢相關之結果的其他區塊。 搜尋關鍵字可以針對「影像庫」或「圖片庫」進行精確查詢,而查詢規則可以改善對於這所有大量不同影像查詢的搜尋。 然而,如果您想要執行的動作是將結果升級到查詢最上方 – 別擔心!使用查詢規則的方式就像使用搜尋關鍵字一樣簡單。事實上,如果您正在從 SharePoint 2010 產品升級,SharePoint 2013 Preview 會將您所有舊的搜尋關鍵字轉換為查詢規則。 因此,讓我們來建立可在精確查詢「影像庫」或「圖片庫」上觸發的查詢規則,然後將影像庫的結果升級到頁面最上方。 首先,請移至 [查詢規則] 管理頁面。在搜尋中心右上角,按一下齒輪圖示,然後選取 [網站設定]。 接著,在 [網站設定] 頁面的 [搜尋] 標題下方,按一下 [查詢規則]。請注意,您可能會在…

0

在 SharePoint 2013 中使用要求管理員

英文原文已於 2012 年 9 月 15 日星期六發佈 我尚未看見許多關於本主題的資訊,因此坦白說,我認為需要花些時間,才能取得一些適用於要求管理員 (RM) 的 PowerShell。對於不熟悉 RM 的人來說,這是 SharePoint 2013 的新功能,其設計目的是進行 SharePoint 要求的路由傳送與節流處理。藉由具備連入要求本質的知識 (例如,使用者代理程式、要求的 URL 或來源 IP),SharePoint 可自訂每個要求的回應。它會根據您定義的規則進行路由傳送,或對要求進行完全節流處理。RM 規則會針對每個 Web 應用程式進行套用,就像是在 SharePoint 2010 中進行節流處理一樣。 在高階方面,RM 的目標如下: RM 可以路由傳送到健康情況較好的 WFE,讓健康情況較差的 WFE 保持運作 RM 可以識別有害的要求並立即拒絕它們 RM 可以為較低優先順序的要求 (Bot) 進行節流處理,為較高優先順序的要求 (使用者) 提供服務,藉以設定要求的優先順序 RM 可以傳送特定類型的所有要求,例如,搜尋特定電腦 隔離的流量可以協助疑難排解單一電腦上的錯誤 RM 可以將大量要求傳送給功能更強大的 WFE 路由傳送和節流規則會以如下方式來實作: 路由傳送規則會路由傳送要求,並關聯至 MachinePools MachinePools 包含伺服器…

0

使用 SharePoint 2013 在幾分鐘內建置特殊化的搜尋體驗

英文原文已於 2012 年 10 月 10 日星期三發佈 對象:搜尋管理員/IT 專業人員先決條件:本文假設讀者已經具備基本的 SharePoint 2010 搜尋管理知識。 SharePoint 2013 Preview 中的企業搜尋中心幾乎會搜尋 SharePoint 編目的所有內容。這就是為什麼它的搜尋結果會標示為「全部內容」: 但對於特殊化的資料或案例來說,您通常會想要一個相符的特殊化搜尋體驗。這就是「全部內容」旁邊的連結。例如,[人員] 可將您帶至 [人員搜尋],此搜尋只會傳回人員結果、以不同方式顯示它們,以及利用智慧方式回應特定的人員相關查詢,例如電話號碼的搜尋。 建置您自己的搜尋體驗非常容易。核心部分如下: 搜尋體驗 = 結果來源 + 搜尋結果網頁組件 「搜尋結果」是搜尋體驗的核心。它保證結果會符合特定的狀況。例如,本機人員結果來源只會傳回人員結果。您可以將結果來源想成是 SharePoint 2010 同盟位置加上搜尋範圍。 「搜尋結果網頁組件」及其所在頁面是搜尋體驗的表面。它會將查詢傳送至適當的結果來源。因此,人員搜尋會擁有一個可將查詢傳送至本機人員結果來源的搜尋結果網頁組件。 現在,全新推出的搜尋體驗 (例如,人員) 也會使用一些其他搜尋功能,例如,使用結果類型與顯示範本來變更結果的外觀,以及使用查詢規則來利用智慧方式回應使用者。但是,它們的核心一律是結果來源和搜尋結果網頁組件。而且,建立這些搜尋體驗只需要幾分鐘。 現在就來試試 – 讓我們建置一個適用於 PDF 的簡單搜尋體驗。 建立 PDF 結果來源 首先,建立只會傳回 PDF 結果的結果來源。從搜尋中心,按一下齒輪圖示、選擇 [網站設定],然後按一下 [結果來源]。 接著,按一下 [新增結果來源],並設定下列內容: 來源的名稱:PDF 結果 它的說明:副檔名為 .pdf 的結果…

0

使用 Azure IaaS 服務建立和使用 CSUpload 工具的憑證

英文原文已於 2012 年 9 月 16 日星期日發佈 在我的於 Azure IaaS 服務中使用 SharePoint 的相關文章中 (http://blogs.msdn.com/b/sharepoint_cht/archive/2012/07/23/sharepoint-azure.aspx),我的一位朋友 Mike Taghizadeh (他要求我提到他 :-)) 注意到我並未提供如何建立憑證以及將憑證與 csupload 命令列工具搭配使用的指示。因此,為了協助可能有相同問題的人,我將在此處快速說明該程序。 首先,您真正可以針對此目的用來建立憑證的最簡單方法是在 Windows 7 或 Windows Server 2008 或更新版本上開啟 [IIS 管理員],然後在其中建立自我簽署憑證。您可以在 [IIS 管理員] 中按一下伺服器名稱,然後按兩下中間窗格的 [伺服器憑證] 來尋找該憑證。這樣會顯示所有已安裝的憑證,而您可以在右工作窗格中看見 [建立自我簽署憑證…] 的選項。 當您建立憑證之後,需要匯出該憑證兩次 – 一次含有私密金鑰,另一次則沒有。您必須這樣做兩次的原因是因為您需要將不含私密金鑰的憑證上傳至 Azure。含私密金鑰的憑證則需要新增至您利用 csupload 連線至 Azure 之電腦上的個人憑證存放區。當您在 [IIS 管理員] 中建立憑證時,它會將憑證放置於電腦的個人存放區,這就是為什麼您需要匯出它,並將它新增至您自己的個人存放區的原因。 匯出憑證的方法非常簡單 – 只需在 [IIS 管理員] 中按一下憑證,然後按一下憑證內容的…

0