到了這時候很明顯的是網站的設定出了問題， 但是之前負責架站的前輩已經離職了，
因此只好慢慢摸索，可憐的砍尼還一直被我騷擾幫忙測試，（嗯，你是好人～）
最後終於整理出以下的設定方式：
- 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中建立「上方連結列」或其他連結時，要注意是否不用輸入網站的根目錄，直接輸入網址即可。
