我剛炒了容量規劃工具的 這些天的所有憤怒.

發現它便於使用，並快速建模工作今年夏天的用戶端環境.

有些惶恐, 我按下了最後的確定按鈕，它建議非常類似于我們給我們的客戶的東西 (我們實際上扔在第二個應用程式伺服器中為未來 excel 使用). 我認為這個是一個好兆頭，增加我的自信在工具中.

它看起來很強大的東西更多好的出發點比一個空白頁.

我喜歡那個讓你進入某些好的細節資訊環境. 有多少使用者, 你如何專案他們將使用系統 (發佈, 合作, 等), 分支辦公室和連通性 / 他們與媽媽伺服器之間的網路容量. 好的東西.

它先廣泛基於提出問題，然後允許您調整您的環境相當精細模型的詳細資訊.

我猶豫了一下下載它，因為我有很多其他事情要看著它, 閱讀並試圖消化. 我很高興我這麼做.

這是一個簡單的兩步過程. 下載系統中心容量規劃師，然後下載 SharePoint 模型. 它在 Windows XP 上運行的很好.

基於我快速的印象, 它可能會考慮如何看不到:

• 搜索: 文檔總數, 也許類型的文檔, 語言.
• Excel 伺服器: 多少, 如果在所有?
• 表單伺服器: 多少, 如果在所有?
• BDC: 多少, 如果在所有.

那些可能進行建模和我只是沒看到他們在 10 分鐘審查.

我一定會在我下一次用戶端使用它.

如果沒有 顧問 而是為一個真實公司工作 :), 我將模型我當前的環境，看看該工具的推薦的模型與現實的匹配. 那將是很整潔. 它可能會導致一些良好的基礎設施的討論.

</結束>

我的用戶端最近安裝從魔法裝置 瞻博 這顯然取代其舊的 Cisco 網路負載平衡器 (NLB). 在大約同一時間, 我們安裝了 修補程式來解決工作流問題.

一天或兩天以後, 我們注意到一個問題，當我們訪問的共用的服務提供程式 (過磷酸鈣). 我們可以給它, 但我們會為一個使用者 ID 和密碼每一頁上多次挑戰. 這並沒有發生與主要入口網站應用程式, 也不是中央行政部門. 自然, 我們不知道這兩個 (Juniper 或修復程式) 就是這個問題, 雖然強烈被懷疑此修補程式, 找我們了不安裝它完全正確.

原來杜松有某種壓縮設置. 之一 身穿長袍的數位 在網路中組打開該設置. 這解決我們的問題.

這不是第一次壓縮已對我來說一個 SharePoint 問題的根源. 對 IE IIS 壓縮不利的善良的人們在點網廠從一個協力廠商工具 6 瀏覽器 (IE 7 瀏覽器不困難的工作).

所以, 添加"壓縮" 到危害清單.

</結束>

歸功於: http://www.elfwood.com/art/s/h/sherry/death_colour.jpg.html