我有理由今天玩 codeplex 多面搜索 今天的專案.
到處都有一段時間, 但猶豫了一下，下載並使用它的通常原因 (主要缺乏的時間), 加上徹底的恐懼🙂
如果你想提高您的搜索和探索新的選項, 下載並安裝它，當你有一個小時左右的閒置時間. 遵照安裝手冊 》 和我花了不到 20 分鐘要安裝和工作. 它提供了價值分鐘零.
它看起來很難擴展. 作者為一個複雜的 BDC 場景提供一個詳細的演練. 我可能會丟失它, 但願他們還將提供一個簡單的場景，涉及一個預先存在的屬性或可能會添加一個新的託管的屬性. 我將試著寫下了自己在未來一段時間.
底線 — 以分鐘為單位, 您可以安裝, 對其進行配置, 使用它並為您的香草 MOSS 搜尋添加一些非常酷的功能並成為英雄 🙂
</結束>
在過去的一周, 我 同事 和我在為一個用戶端在紐約做一些工作. 我們測試實現使用其"標準的 MOSS 的不同的方面" 工作站版本 (反對我們的筆記本電腦). 在這樣做時, 我們遇到了幾個錯誤按照下面的步驟:
我們是來實現那幾次 (通常第一次) 我們將該文檔保存, 保存"粘在一起。" 保存未保存. 我們將把該檔拉回上來和我們的改變只是並不存在.
我們此時不理解根問題, 但我們想，我們應該確保，在該工作站上已安裝了最新的微軟辦公軟體服務包. IT 人員去那樣做了. 我們又通過測試，我們發現了一個新的問題. 當我們保存它, 我們現在有這個錯誤:
這一次, 好像是每個更改, 事實上, 保存, 我們回答是還是不到腳本問題.
我們終於有了看看實際的 Office 版本和原來的工作站運行 MS Office 2000 服務包 3 其中顯示下説明-> 關於"Office 2002"作為.
故事的寓意: 我將始終使用辦公室 2003 作為我最低限度基準 office 版本時使用 WebDAV 和苔蘚.
</結束>
(對於搜尋引擎的目的, 這是錯誤的文本):
行: 11807
Char: 2
錯誤: 物件不支援此屬性或方法
代碼; 0
你想要繼續運行此頁面上的腳本嗎?
在一個或我 第一次的博客, 我描述我們遵循從 SPS 遷移客戶的整個過程 2003 對青苔. 一位讀者留下評論問更多的細節和它在這兒.
為該遷移專案, 我們還需要找到移動大量的 SPS 的好方法 2003 檔在對青苔. 初始荷載很容易. 在 MOSS 中創建一個新的目的文件庫並使用 windows 資源管理器中移動檔.
這是新的文件庫:
打開兩個視窗的探險家. SPS 點第一次 2003 第二次在 MOSS 中的新文件庫. 下面的螢幕擷取畫面顯示了這. 請注意，頂級瀏覽器實際上指向我 c:\臨時磁碟機, 但是你可以想像它指向 SPS 2003 文件庫:
在那之後拖放式操作, 我的目標看起來是這樣:
現在是時間來處理中繼資料. 假設我們有只有一列的中繼資料為這些檔命名為"位置。" 我們可以看到從上面的"所有文檔" 查看位置為空. 很容易使用資料工作表視圖中輸入的位置, 或甚至進入每個文件屬性一個一個地添加位置. 讓我們假設最終使用者必須用手這樣做，是有沒有切實可行的辦法來分配位置列的值自動. 此外, 讓我們假設有數百個文檔 (或許是上千) 和許多天更新中繼資料，它會把很多. 我們都知道, 沒有人會坐下來和工作四五天直更新檔的中繼資料. 相反, 他們將在幾個星期甚至更長的時間內爆發，. 為了促進這一進程, 我們可以創建一個"未加標籤的資料" 如圖所示的視圖:
現在, 當別人坐下來花其分配每天一兩個小時已遷移的文檔標記, 他們可以使用"未加標籤的文檔" 視圖，以集中他們的努力:
作為使用者標記檔, 他們下車此清單.
這種未加標籤的資料檢視的概念還可以説明一類人在論壇詢問的資料驗證問題. 外框, 有是沒有辦法阻止使用者將檔上載到苔蘚，然後不輸入中繼資料. 我們可以指定一個特定網站列是強制性的和不應允許使用者保存按鈕. 不過, 如果使用者上傳，然後關閉瀏覽器 (或使用 windows 資源管理器上傳文檔), 我們不能強迫使用者輸入中繼資料 (再次, 外框).
這種方法可以用於説明這種狀況. 我們可以用"差已標記的資料" 查看來輕鬆地識別這些文檔並改正. 這夫婦與 KPI，你有良好的能見度對-向下切入來管理這些特殊情況下的資料.
</結束>
MSDN 搜索論壇, 人們經常問這樣的問題:
"我有一份名為 ' 程式設計指南’ 但當我搜索臨’ 搜索沒有找到它。"
它可能感覺不像它, 但這等於是萬用字元搜尋. 苔蘚/WSS 使用者介面不支援萬用字元搜尋開箱即用.
如果你挖到搜索 web 部件, 你會發現一個核取方塊, "啟用搜索詞詞幹". 詞幹是人類語言術語. 它不是一個電腦語言子字串() 類型函數.
這些都是一些莖:
這些都不是莖:
WSS/苔蘚搜尋引擎不支援萬用字元搜尋通過 API. 這裡是一個描述如何做到這一點的博客文章: http://www.dotnetmafia.com/blogs/dotnettipoftheday/archive/2008/03/06/how-to-use-the-moss-enterprise-search-fulltextsqlquery-class.aspx
協力廠商產品, Ontolica, 提供萬用字元搜尋. 我沒有使用該產品.
</結束>
上個星期, 我出如何工作 迴圈，並實現狀態機 使用 SharePoint 設計器，並提到, 順便提一句, 這很可能會寫一篇博客文章有關更好的工作流日誌記錄.
井, 桑吉拉其普特搶先. 看一看.
日誌資料保存到一個自訂清單中似乎比使用常規工作流歷史記錄:
有一些風險 / 負面影響:
</結束>
這過去的一周我完了概念專案證明用戶端在曼哈頓. 同時實施的解決方案, 遇到了青苔 Kpi 的另一個缺點 (在這裡看到的以前的 KPI 問題和我的解決方法。).
背景: 用於設計器 SharePoint 工作流模型相當複雜多月長業務流程. 作為它突突地前進, 它將更新清單中的一些狀態資訊. Kpi 使用此資料來做他們的魔力.
我們決定要創建一個新的網站每次一個新的這些業務流程揭開序幕. 工作流本身的旁白, 這些網站主機幾個文件庫, 使用訪問群體設定等等等等. 只是一堆的東西，説明內部員工之間的協作, 出差旅行的員工和用戶端參與商業夥伴.
我們還想要展示一些 Kpi，監視的整體健康情況這一特定的業務進程所提倡的工作流狀態資料並使用 Kpi 查看.
最後, 我們用做對網站中的清單視圖上計數的 KPI 清單項 (而不是從另一個資料來源, 像 excel 或 SQL).
問題: 你可以想像, 假設我們都攜帶進入生產世界前進的基本思想, 我們想要的網站範本. 提供基於"業務流程的新網站" 範本.
問題是你似乎無法得到這種方式運作的 KPI. 在創建基於範本的 KPI 清單與 KPI web 部件的新網站時, 新網站 KPI 資料都破了. 無論源新網站 KPI 清單點你定義當你第一次保存它作為一個範本.
舉個例子:
具現化過程不正確的 URL.
我試著解決這個問題通過指定相對 URL 定義 KPI 清單項時. 不過, 我不能任何變化的為了工作.
我總是想要配對這些"問題" 博客文章具有某種解決方案, 但在這種情況下，我沒有一個好. 最好的我可以圖是你需要轉到新調配的網站和手動修復一切. 這種介面使得這更難的因為更改的源清單中的 URL 會導致刷新, 所以你真的要重新定義整件事從零開始.
如果有人知道更好的方法來處理這, 請張貼評論.
</結束>
這一周, 我有點糾結我的團隊得到簡單的兩個伺服器場中安裝的苔蘚. 經歷了它, 我有這種問題的人報告更感謝 MSDN 論壇和其他地方.
最終場配置:
我們在開始專案之前, 我們讓客戶知道需要打開哪些埠. 在互諒互讓, 來回過，, 我們從未明確地說，兩個重要的事情:
第一天, 我們到場安裝苔蘚和學沒已創建資料庫和苔蘚的域帳戶. 搬東西, 我們走在前面，和安裝一切與 intranet 伺服器上的本地帳戶.
在這一點, 過去的 SSL 憑證，我們發現了混亂和, 不幸的是, 決定要我們基礎設施的傢伙回來之後的一個星期繼續安裝 DMZ 伺服器. 在平均時間, 我們的解決方案建築師向前與業務的東西.
一個週末的流逝，用戶端獲取證書.
我們的基礎設施的傢伙顯示，併發現在 DMZ 伺服器未加入任何域 (具有有限的信任的週邊域或 intranet 的域). 我們浪費了近 1/2 在這一天. 如果我們沒有讓我們停滯不前的失蹤 SSL 憑證, 我們發現這早些時候. 哦好吧….
另一天走刀和各種安全委員會, 有關各方和 (不是這樣) 無辜的旁觀者都同意這是確定以加入 DMZ 伺服器與內聯網的域 (這是 POC, 畢竟, 不是生產的解決方案).
基礎設施的傢伙來東西包起來. 這次我們成功地通過現代天挑戰親切地稱為"SharePoint 設定精靈。" 我們有聚醚醚酮在管理中心和 … 怡山楂! … DMZ 伺服器列出伺服器場中. 我們靠近一點看，實現我們破開香檳蟎有點早. WSS 服務陷入"開始" 狀態.
長話短, 原來，我們忘記了通過管理中心的服務帳戶的身份從原始的本地帳戶更改為新的域帳戶. 我們那樣做, 重新回合組態嚮導大功告成! 我們在業務.
</結束>
最近學會它是可能，甚至相當輕鬆地創建使用 SharePoint 設計器的狀態機工作流. 必要性是發明和所有的好東西的母親又尋找發明需要這個星期. 巧合的是, 我偶然 這個 MSDN 論壇帖子 以及. 我個人的經驗這周和那"獨立確認" 借給我的信念的力量. 我打算寫關於這在更大的長度，一個完整的例子, 但這裡是它的要點:
要對其進行配置:
每個國家工作流遵循此粗糙的模式:
除了明顯的好處，可以創建聲明性狀態機工作流, 所有狀態資訊是建設 Kpi 和有趣的很棒的視圖.
它不會有一個相當大的缺點 — 標準工作流程歷史記錄追蹤比正常情況更無用 🙂 這很容易補救, 然而. 將您所有的審計類型資訊存儲在自訂清單. 這可能是一個好的主意，甚至為香草的順序工作流, 但這是另一篇文章的內容 🙂
稱之為"認錯" 因為我有, 不幸的是, 不止一次在論壇上表示，和其他地方那個必須使用 visual studio 創建狀態機工作流. 那只是不是真的.
</結束>
雖然這不是字面上真的, 作為一個實際問題, 面向 internet 的 web 前端 DMZ 中必須在域中 (e 小節. 一些不在自己小小的工作組中的獨立伺服器). 它並不需要在同一個域作為內部 WFE(s) 伺服器和其他伺服器 (和可能不應該), 但它需要一個域.
我和我的同事花費大量的時間對一項提案，其中包括 SharePoint 的先決條件. 這包括將啟用 DMZ 伺服器等等加入農場的防火牆配置的全面清單. 不幸的是, 我們未能添加某處說，一個句子, 影響, "這種配置的整個血腥點是允許您 DMZ 繼續保持伺服器, 在域中, 加入該內部的農場。"
一場完美的風暴的事件, 在我們基本上看左時我們可能看上去右, 密謀隱藏此從我們相當晚在過程中的問題, 從而防止我援引我 "壞消息告訴早" 規則.
歎息.
Twitter 是一個非常奇怪的鴨子. 我一直使用 Twitter 為有點超過一個月，一些莫名的方式, 它是幾乎一樣重要對我的電子郵件. 我發現自己模模糊糊地不安穩了，如果我等得太久，再看其他人嘰嘰喳喳談論. 我會在 Twitter 的偶爾的性能問題很惱火，因為這意味著我錯過了. 我得到一小股的興奮，當我看到一個新的 Woot 公告.
它是一個真正的社區建設者在真的相輔相成的博客和論壇和甚至個人面對面會議的方式.
上個月, 我跟隨一人企圖在嘗試管理家宴時搖晃冷.
我學到關於我主要"知道很多人的個人詳細資訊" 通過博客 — 他們住在哪裡, 他們工作的專案種類, 他們有的工作 / 家庭問題，就像我一樣管理.
一個人的母親去世了， … 傷心的事件肯定. 但共用這一事實發生變化，提高了整體體驗的字元.
那是只是個人的東西.
還有比這更. 它也是另一種介質為分享想法, 或更多的時候我覺得, 尋求説明. 把一個問題在 Twitter 和你永遠不會留下掛和反應通常在幾分鐘內到達.
如果你沒試過, 你是應該放手一搏.
我抬頭看 http://www.twitter.com/pagalvin
