我在一個專案，我們需要收集度量一個功能叫做"分享一個故事。" 這個想法是很簡單 — 如果你正在看一篇有趣的文章在 intranet 上，並且想要與其他人共用它, 按一下標記為"共用這個故事連結" 通過電子郵件將它發送給您的好友.

我們玩自訂表單為此目的, 但在結束, 常識贏得了一天，我們只是使用熟悉 <a href = mailto:…> 技術. (<href mailto:…> 是有點出乎意料的強勁; 作為獎金, 該連結給我帶回我舊的 UNIX 男子頁天; 那段日子!).

此技術為最終使用者提供了偉大的介面，因為他們，要使用他們熟悉的 MS Outlook 用戶端 (或已安裝的任何電子郵件用戶端).

它使事情更難我們可憐的開發人員類型以來他們用戶端 ＊ 還 ＊ 想要運行報告，在未來如何往往顯示使用者分享的故事，甚至哪些情景最經常共用.

我們 whiteboarded 幾個可能的解決方案. 我最喜歡的是到碳副本 (抄送) SharePoint 清單. 這種方式, 最終使用者仍然獲取 outlook 用戶端，而我們要捕獲的事件，因為我們會買電子郵件的副本. 有一些明顯的缺點. 主要的問題是，該使用者可以簡單地清空或否則為裂傷抄送位址. 和, 我們需要管理電子郵件，事件庫. 我們有一個預定的工作負責，清理的白板上.

如果您有一些聰明的辦法，解決這個問題, 請不要告訴.

</結束>

訂閱我的博客.

跟我在 Twitter 上 http://www.twitter.com/pagalvin

一樣的請求，並許諾, 我已經上傳我如何獲得"偉大的演示文稿" 從最終使用者的 SharePoint 專案和實現要求. 正是在這裡: http://cid-1cc1edb3daa9b8aa.skydrive.live.com/self.aspx/SharePoint/Paul Galvin Great Requirements.zip

我這 SharePoint 的最佳做法在會議上介紹 Feb 2009 (www.sharepointbestpractices.com). 如果你出席會議, 你也會這會議 DVD.

演示文稿包括了很多筆記與大多數幻燈片. 它不是只是要點.

(治理案例研究的其他演示文稿，請參閱在這裡: http://paulgalvin.spaces.live.com/blog/cns!1CC1EDB3DAA9B8AA!3099.entry

</結束>

訂閱我的博客.

跟我在 Twitter 上 http://www.twitter.com/pagalvin

像許多 SharePoint 顧問類型, 已經受到大量的 SharePoint 功能. 幾次, 我潛水很深. 其他時間我只是注意到它，我飛往的另一組的功能表選項. 其中之一是"自助式網站創建。" 我還沒有為它直到這周需要.

這一周, 我需要解決的業務問題，我想要變得更加普遍，因為公司鬆開，擁抱 SharePoint 更直接最終使用者控制. 在此情況下, 我設計的網站範本，以支援特定的終端使用者社區. 在這個社區的人應該能夠隨意使用此範本，每當衝動他們創建自己的網站.

我記得看到"自助式網站創建" 之前和我過總是藏那我腦思維的"自助服務網站創建" SharePoint 邱林意義, 顯然不夠, 就像"開啟我如果你想讓最終使用者能夠創建網站，當他們想要的。"

所以, 我打開它, 試一試了，對我來說, 它不創建網站. 它創建網站 收藏. 相當大的差別. 這是不是我想要什麼, 一點也不.

它是可能的讓最終使用者創建新的子網站，通過自訂權限等級. 這正是在那裡，我就去放在第一位除了標籤"自助式網站創建" 標籤欺騙了我. 通過 twitter, 我知道這也欺騙了別人🙂

我仍然工作如何提供一點點的一個更精簡的過程，同時保持純粹是框中, 但有一個明確的路徑遵循. 只是不要分心于該標籤.

</結束>

訂閱我的博客.

跟我在 Twitter 上 http://www.twitter.com/pagalvin

我是之一 20 或 30 (或者是- 100?) 專家組成員在最後一夜 紐約 SharePoint 使用者組 會議. 而不是通常的演示文稿格式, 這都是關於 Q&A 小組成員和觀眾之間. 在早期, 邁克爾 · 勞特 介紹我到一個新的想法，我想要分享.

一名觀眾描述如何他的公司支付了一名顧問來為他的公司編寫的應用程式. 顧問公司將它寫成一個主控台應用程式使用的是 SharePoint 物件模型. 作為一個結果, 這意味著該程式必須在伺服器場中的伺服器上運行. 這意味著，任何想要使用的應用程式的人都必須登錄到伺服器, 做這項工作和登出. 在第一次, 這不是個問題, 但是很快, 更多和更多 (非技術性) 使用者需要使用該實用程式. 他的問題是 (釋義):

"什麼是我的選項? 我不想讓使用者直接登錄伺服器, 但他們需要該功能。"

邁克爾 · 勞特建議他配置新的虛擬機器, 將它加入到作為 WFE 農場和讓使用者從那裡運行該應用程式.

這是一個非常驚人的想法，對我來說. 推廣這種解決方案使我想起基本上是臨時性的概念, 幾乎可支配 WFE. 這是一個很乾淨的概念. 此臨時 WFE 可以運行一個主控台應用程式，使用 SharePoint 物件模型. 你也可以使用它來運行 stsadm 命令. 它並不一定要定期當地平衡的一部分. 如果它落下或獲取失事, 你可以只是旋轉了一個新. 我重複我自己, 但我只是要說我認為這是一個絕妙的主意.

</結束>

訂閱我的博客.

跟我在 Twitter 上 http://www.twitter.com/pagalvin

過去的一周, 有人問了一個問題關於創建一個 SharePoint 環境，將處理相當大批量的新文檔 (10,000 +/- 在這種情況下). 對此不了解, 但 由於這份白皮書, 我覺得更加知情.

對我來說, 這份白皮書是差不多隻是一個在時刻的書標記, 而且什麼開始讀通過它覺得我應該突出我主外賣. SharePoint 可以縮放以處理, 在最低限度, 此負載:

• 50k 每一天的新文檔.
• 10 百萬檔總數.

我寫 50 k/10 毫米數位，因為它們很容易記住. 只要你知道他們的最小值, 你不會有麻煩. 最大值至少是 10 高比和極端調諧 %, 可能很多較高.

謝謝, 邁克 · 沃爾什, 再一次為他 每週 WSS 常見問題更新和更正後. 如果您不訂閱它, 你應該認真考慮這樣做.

</結束>

訂閱我的博客.

在過去的一周, 我 同事 和我在為一個用戶端在紐約做一些工作. 我們測試實現使用其"標準的 MOSS 的不同的方面" 工作站版本 (反對我們的筆記本電腦). 在這樣做時, 我們遇到了幾個錯誤按照下面的步驟:

• MS word 文檔，通過 windows 資源管理器打開 (其中使用 WebDAV).
• 進行更改.
• 保存它.

我們是來實現那幾次 (通常第一次) 我們將該文檔保存, 保存"粘在一起。" 保存未保存. 我們將把該檔拉回上來和我們的改變只是並不存在.

我們此時不理解根問題, 但我們想，我們應該確保，在該工作站上已安裝了最新的微軟辦公軟體服務包. IT 人員去那樣做了. 我們又通過測試，我們發現了一個新的問題. 當我們保存它, 我們現在有這個錯誤:

這一次, 好像是每個更改, 事實上, 保存, 我們回答是還是不到腳本問題.

我們終於有了看看實際的 Office 版本和原來的工作站運行 MS Office 2000 服務包 3 其中顯示下説明-> 關於"Office 2002"作為.

故事的寓意: 我將始終使用辦公室 2003 作為我最低限度基準 office 版本時使用 WebDAV 和苔蘚.

</結束>

訂閱我的博客.

(對於搜尋引擎的目的, 這是錯誤的文本):

行: 11807

Char: 2

錯誤: 物件不支援此屬性或方法

代碼; 0

URL: http://sharepoint01/DocumentReview/_vti_bin/owssvr.dll?location=Documents/1210/testworddocument.doc&dialogview=SaveForm

你想要繼續運行此頁面上的腳本嗎?

在一個或我 第一次的博客, 我描述我們遵循從 SPS 遷移客戶的整個過程 2003 對青苔. 一位讀者留下評論問更多的細節和它在這兒.

為該遷移專案, 我們還需要找到移動大量的 SPS 的好方法 2003 檔在對青苔. 初始荷載很容易. 在 MOSS 中創建一個新的目的文件庫並使用 windows 資源管理器中移動檔.

這是新的文件庫:

打開兩個視窗的探險家. SPS 點第一次 2003 第二次在 MOSS 中的新文件庫. 下面的螢幕擷取畫面顯示了這. 請注意，頂級瀏覽器實際上指向我 c:\臨時磁碟機, 但是你可以想像它指向 SPS 2003 文件庫:

在那之後拖放式操作, 我的目標看起來是這樣:

現在是時間來處理中繼資料. 假設我們有只有一列的中繼資料為這些檔命名為"位置。" 我們可以看到從上面的"所有文檔" 查看位置為空. 很容易使用資料工作表視圖中輸入的位置, 或甚至進入每個文件屬性一個一個地添加位置. 讓我們假設最終使用者必須用手這樣做，是有沒有切實可行的辦法來分配位置列的值自動. 此外, 讓我們假設有數百個文檔 (或許是上千) 和許多天更新中繼資料，它會把很多. 我們都知道, 沒有人會坐下來和工作四五天直更新檔的中繼資料. 相反, 他們將在幾個星期甚至更長的時間內爆發，. 為了促進這一進程, 我們可以創建一個"未加標籤的資料" 如圖所示的視圖:

現在, 當別人坐下來花其分配每天一兩個小時已遷移的文檔標記, 他們可以使用"未加標籤的文檔" 視圖，以集中他們的努力:

作為使用者標記檔, 他們下車此清單.

這種未加標籤的資料檢視的概念還可以説明一類人在論壇詢問的資料驗證問題. 外框, 有是沒有辦法阻止使用者將檔上載到苔蘚，然後不輸入中繼資料. 我們可以指定一個特定網站列是強制性的和不應允許使用者保存按鈕. 不過, 如果使用者上傳，然後關閉瀏覽器 (或使用 windows 資源管理器上傳文檔), 我們不能強迫使用者輸入中繼資料 (再次, 外框).

這種方法可以用於説明這種狀況. 我們可以用"差已標記的資料" 查看來輕鬆地識別這些文檔並改正. 這夫婦與 KPI，你有良好的能見度對-向下切入來管理這些特殊情況下的資料.

</結束>

訂閱我的博客.

這一周, 我有點糾結我的團隊得到簡單的兩個伺服器場中安裝的苔蘚. 經歷了它, 我有這種問題的人報告更感謝 MSDN 論壇和其他地方.

最終場配置:

• 在防火牆內的 SQL 索引/內部網繼續保持.
• 在 DMZ 中繼續保持.
• 某種形式的 DMZ 與內部伺服器之間的防火牆.

我們在開始專案之前, 我們讓客戶知道需要打開哪些埠. 在互諒互讓, 來回過，, 我們從未明確地說，兩個重要的事情:

1. SSL 意味著您需要一個證書.
2. DMZ 伺服器必須是域的一部分.

第一天, 我們到場安裝苔蘚和學沒已創建資料庫和苔蘚的域帳戶. 搬東西, 我們走在前面，和安裝一切與 intranet 伺服器上的本地帳戶.

在這一點, 過去的 SSL 憑證，我們發現了混亂和, 不幸的是, 決定要我們基礎設施的傢伙回來之後的一個星期繼續安裝 DMZ 伺服器. 在平均時間, 我們的解決方案建築師向前與業務的東西.

一個週末的流逝，用戶端獲取證書.

我們的基礎設施的傢伙顯示，併發現在 DMZ 伺服器未加入任何域 (具有有限的信任的週邊域或 intranet 的域). 我們浪費了近 1/2 在這一天. 如果我們沒有讓我們停滯不前的失蹤 SSL 憑證, 我們發現這早些時候. 哦好吧….

另一天走刀和各種安全委員會, 有關各方和 (不是這樣) 無辜的旁觀者都同意這是確定以加入 DMZ 伺服器與內聯網的域 (這是 POC, 畢竟, 不是生產的解決方案).

基礎設施的傢伙來東西包起來. 這次我們成功地通過現代天挑戰親切地稱為"SharePoint 設定精靈。" 我們有聚醚醚酮在管理中心和 … 怡山楂! … DMZ 伺服器列出伺服器場中. 我們靠近一點看，實現我們破開香檳蟎有點早. WSS 服務陷入"開始" 狀態.

長話短, 原來，我們忘記了通過管理中心的服務帳戶的身份從原始的本地帳戶更改為新的域帳戶. 我們那樣做, 重新回合組態嚮導大功告成! 我們在業務.

</結束>

訂閱我的博客.

雖然這不是字面上真的, 作為一個實際問題, 面向 internet 的 web 前端 DMZ 中必須在域中 (e 小節. 一些不在自己小小的工作組中的獨立伺服器). 它並不需要在同一個域作為內部 WFE(s) 伺服器和其他伺服器 (和可能不應該), 但它需要一個域.

我和我的同事花費大量的時間對一項提案，其中包括 SharePoint 的先決條件. 這包括將啟用 DMZ 伺服器等等加入農場的防火牆配置的全面清單. 不幸的是, 我們未能添加某處說，一個句子, 影響, "這種配置的整個血腥點是允許您 DMZ 繼續保持伺服器, 在域中, 加入該內部的農場。"

一場完美的風暴的事件, 在我們基本上看左時我們可能看上去右, 密謀隱藏此從我們相當晚在過程中的問題, 從而防止我援引我 "壞消息告訴早" 規則.

歎息.

訂閱我的博客.

論壇使用者經常作為 像這樣的問題:

> 您好 ！,
>
> 請告訴我，是否有任何的可能性，以生成一個自訂清單
> 主頁和詳細的類型 (像發票) 而無需使用 InfoPath.
>

SharePoint 提供了某些現成功能，像這樣支援種類的業務需求.

一般, 一個連結在一起使用查閱列的兩個清單. 清單 A 包含發票標題資訊和清單 B 包含發票詳細資訊.

使用附加清單來維護客戶編碼, 產品編號, 等.

使用內容查詢 web 部件 (在 MOSS 只中) 和/或資料檢視 web 部件來創建清單的合併的視圖. SQL 伺服器報表服務 (SRS) 也是它的報告側供.

不過, 有一些重要的限制使它難使用純預置的功能，甚至中等複雜的東西. 這些包括:

• 有關查找大小列出 vs. "斑彩" 查找列類型的. 查找列類型提出自己對 UI 以不同的方式取決於是否啟用了多重選取或不. 在任一情況下, 外框控制項顯示源清單中的所有可用專案. 如果源清單 1,000 專案, 這就一個問題. 通過這些專案未頁查找控制項. 相反, 它將所有的他們拉入控制. 這使得資料錄入和性能非常尷尬的使用者介面.
• 查找"拉回來" 一列資訊. 你永遠不能拉回多個列的源清單中的資訊. 例如, 您不能選擇一個客戶"12345" 並在同一時間顯示的號碼，以及客戶的名稱和位址. 查找只顯示客戶數量，別無其他. 這就使得一個尷尬和困難的使用者介面.
• 沒有內部形式溝通. 我已經寫了關於此這裡. 您不能實現級聯下拉清單, 有條件地啟用/禁用的欄位, 等.
• 沒有串聯刪除或內置的參照完整性. SharePoint 視為獨立的實體的自訂清單，並且不允許您將它們連結到對方 ERD 傳統意義上. 舉個例子, SharePoint 允許您創建兩個自訂清單, "客戶" 與"發票抬頭". 在客戶清單中，可以在連結回客戶創建發票抬頭. 然後, 您可以從清單中刪除客戶. 外框, 沒有辦法防止這種情況. 要解決這種問題, 您通常使用的事件處理常式.

可能看起來暗淡, 但我仍使用 SharePoint 作為起點為構建這種功能. 儘管你需要在一個解決方案中有差距, SharePoint 使我們能夠填補這些空白使用工具 （如:

• 事件處理常式. 用於實施參照完整性.
• 自訂列: 創建自訂列類型並使用它們而不是預設的查閱列. 添加分頁, 緩衝和 AJAX 功能，使其反應.
• BDC. 這只苔蘚的功能使我們能夠的查詢其他 SharePoint 清單與通常的查閱列的高級使用者介面. BDC 也可以向後端伺服器應用程式. 使用 BDC 以避免複製. 而不是從 ERP 系統的後端複製客戶資訊, 改為使用 BDC. BDC 功能提供友好的使用者介面拉那直接從 ERP 系統，並屬於避免麻煩的維護複製解決方案的資訊.

  BDC 是蘚類植物的功能 (WSS 中不可用) 和挑戰來配置.

• ASP.NET web 表單: 創建完整的 ajax 的表單，使用 SharePoint 物件模型和/或 web 服務，同時提供了一個非常敏感的使用者介面利用 SharePoint 清單.

最後一個選項可能會覺得你從頭開始, 但考慮這一事實 SharePoint 平臺開始您具有下列主要功能:

• 維護安全模型.
• 維護功能表系統.
• "主表" (e 小節. 自訂清單) 與安全, 內置的維修和審核.
• 搜索.
• 後端集成工具 (BDC).

如果在 visual studio 中使用一個新的空白專案啟動, 你有很多的基礎設施和管道建造之前你靠近 SharePoint 的提供.

我相信微軟打算擴展 SharePoint 中的應用發展方向. 這似乎是對現有的 SharePoint 基礎的自然延伸. 微軟 CRM 應用程式提供了大量的可擴充性，支援頁眉/詳細應用程式開發所需的類型. 雖然這些功能是在客戶關係管理, 技術是明顯可用到 SharePoint 開發團隊，我期望，它一定會成為其 SharePoint 產品年底 2008. 如果任何人有知識或深入的見解, 請留下評論.

</結束>