到了這時候很明顯的是網站的設定出了問題, 但是之前負責架站的前輩已經離職了,
因此只好慢慢摸索,可憐的砍尼還一直被我騷擾幫忙測試,(嗯,你是好人~)
最後終於整理出以下的設定方式:
- SharePoint 網站的設定方式:
在還原好WSS網站後,在「目錄安全設定」中,預設會是「整合式Windows驗證」,在這樣的設定下,intranet access是沒有問題的,但是從internet連線的時候,會直接跳出「HTTP 401.2」的錯誤,而不會跳出輸入帳號密碼的驗證視窗。經過跟MIS的確認後,
由於公司有使用proxy的關係,因此必須將「驗證的存取」部分設定為「基本驗證(使用純文字傳送密碼)」,如此在internet連線的時候就會正常跳出驗證視窗。
另外要注意的是,「啟用匿名存取」一定要取消掉,否則上述的驗證視窗一樣不會跳出來,而且Search Engine的crawler不用經過身分驗證就可以進來爬資料,如此直接就造成(公司/個人)資料外洩,因此一定要取消,強迫所有的連線都要通過身分驗證的程序。
- download網站(連到另一台file server提供檔案下載服務)的設定方式:
- 不考慮proxy (無法提供Internet access,第一次restore之後的作法):
此時SharePoint網站的「目錄安全性設定」勾選「整合式Windows驗證」。建立虛擬目錄,別名為「download」(大小寫沒差),路徑指向\\myFileServer/mtSharedFolder,而後點選在「網站目錄」右邊的「使用者名稱」按鈕,在此採用一個有效的AD Domain帳號。
如此設定可以讓intranet透過AD驗證來存取網站的內容,但是整個portal本身從Internet上會變成無法存取。
- 正確作法(考慮proxy):
跟MIS確認之後,應將SharePoint網站的「目錄安全性設定」勾選
「基本驗證(使用純文字傳送密碼)」,如此從Internet上連線到http://MyServerName.com的時候,就會跳出驗證視窗。
做了這樣的調整之後,變成原本的download網站無法存取,
因此需做以下兩個調整:
(1)將download網站的「目錄安全性設定」改為
「基本驗證(使用純文字傳送密碼)」。
(2)點選「網站目錄」右邊的「使用者名稱」按鈕,勾選「當要確認到網路目錄的存取時永遠使用已驗證過的使用者認證」。
- 不考慮proxy (無法提供Internet access,第一次restore之後的作法):
- 網站連結失效問題
- 原本以為經過上述的步驟,應該所有的設定都大功告成了,
但是透過一些掃描broken link的工具(e.g. FF LinkChecker)挑了幾個網頁來掃描之後,發現有些連結失效了!原來是在WSS中建立「上方連結列」(或其他連結)時,是不用輸入網站的根目錄的,直接輸入網址即可。
在這樣的情況下,WSS會以http://server_name/作為根目錄,而不是「http://MyCompanyDomainName.com.tw」,如此當Server更名的時候可能就會造成連結失效。
因此最好在每次建立新的頁面或連結之後,確認一下網站的根目錄應該一律調整為「http://MyCompanyDomainName.com.tw」,如此未來要還原到其他VM或者是Server更名都不會有影響。
以上就是最後完全設定、修正完畢的過程,經過了這次修復WSS的慘痛SE經驗之後,
最後再整理一些結論:
- 平時一定要用stsadm tool做好備份檔,並且妥善保存,否則當server掛點的時候,保證很難還原的回來!這一點我再強調一百萬遍都不夠~
- 用Google找資料時,要小心WSS 3.0和MOSS 2007是完全不同的東西,另外用「WSS」當關鍵字,往往效果不如「Windows SharePoint Service」。
- WSS可以考慮run在VM上,這樣做的好處是萬一當實體機器掛了的話,可以先暫時把VM備份倒出來,移到另一台機器上run,可以更快的暫時恢復服務。缺點是VM並不一定會每日備份,因此資料的狀態很可能會回溯到一段時間以前,這時候在利用每日的stsadm備份檔將Portal完成還原之前,建議不要修改暫時復原的VM上的Portal的資料內容。
- 在WSS中建立「上方連結列」或其他連結時,要注意是否不用輸入網站的根目錄,直接輸入網址即可。
沒有留言:
張貼留言