成功案例:跟Windows說再見

| | | | | | 19則回應

    

其實轉換工作並沒有想像中困難。如前幾期文章所介紹，市場中已有許多可選擇且日漸成熟的替代方案，不論是作業系統或是應用軟體，只要審慎評估成本與需求，取其最大綜合效益，大可放心嘗試。以下舉例分享我們客戶的轉換經驗。

汰換郵件伺服器

我們曾有個客戶是美國的一間小型學院，師生人數大約有500人，原本所使用的郵件伺服器作業系統是Windows NT4.0，再加上Exchange Server 5.0；至於Client端方面，安裝有Windows 98/NT/ME/2000/XP等各種不同版本的作業系統，大部分的人所使用的郵件軟體是Outlook，另一部份人使用Outlook Express。

基於兩大原因，該學院希望可從Windows轉換至Linux之上：第一個原因是郵件伺服器經常當機，尤其在週末或夜晚無人值班的時候，一但出錯無人可解決，多半要等到上班時間MIS人員重新開機才能恢復正常，因而希望更換至更穩定的作業系統。

第二，該學院雖有考慮升級至Windows 2000，但他們不願支付高額的軟體授權費用。原本，該學院已經委請一家軟體公司架設了Mandrake 9.0，並使用Mandrake內建的Postfix郵件伺服器軟體，再加上Open Source的Squirrel-mail。測試之後，發現Postfix本身的效能與穩定性俱佳，但還是有幾個問題：

• 無法將NT的密碼自動轉換至Mandrake之上。

• 原本在Exchange Server上，該學院已建立許多的公用的通訊錄及郵件夾，皆無法自動轉換至Mandrake中。對他們而言，手動重新建立公用通訊錄所需花費的時間還可接受，但是公用郵件夾難以負荷。

• 不論是導入Squirrel-mail或其他的Web Mail系統，他們都面臨了一個難題。在原先的Outlook使用者群中，有許多人將郵件與通訊錄存放於Exchange Server，當系統移植至Mandrake + Postfix之後，上述使用者的郵件與通訊錄都要能轉換至Mandrake中。

• 另外，該學院的MIS人員也希望可以針對個別的使用者設定信箱容量大小。

步驟一：先使用LSP轉換帳號、群組、密碼：LSP可自動化將500多組帳號與密碼複製至Mandrake中。這個步驟本身不用10分鐘即可完成。當然，嚴格說來，我們轉換的是NT的系統帳號，而原先有些郵件帳號與系統帳號並不一致，這家軟體公司仍然手動利用Postfix的Alias功能，重新建立郵件帳號與系統帳號之間的對應關係。不過，密碼本身並不需要重新建立，整個過程大概在2小時之內完成。

步驟二：在Mandrake上安裝LMAIL：這個過程大概只需要10分鐘，但在安裝完成之後，還必須進行郵件收發與Wen Mail介面的測試與調整，之後再利用LMAIL的管理界面設定每一個使用者的信箱容量大小，共花約莫3個小時程。

• 步驟三：將Exchange Server上的公用通訊錄轉換至LMAIL：這個步驟的轉換工作也很快，不用10分鐘即可完成。

  步驟四：將Exchange Server上的公用郵件夾轉換到Mandrake： 由於該學院的公用郵件夾累積高達2GB容量的資料，總共花費近4小時的時間才轉換完畢。LMAIL提供一個可安裝在Windowa端的工具，可自動顯示公用郵件夾中還有多少子郵件夾，使用者可選擇要將哪些郵件夾上傳至LMAIL之中。

  在前文中，曾經提及LMAIL可配合Postfix存放成Maildir格式，所以該項能可用來將公用郵件夾儲存至任何支援Maildir格式的Web Mail系統或郵件伺服器。

  步驟五：Client端Outlook及Outlook Express轉換： 步驟五所用的工具與步驟四有相同的功能。因為該學院共有500個使用者，MIS因而決定除老師之外，每一個學生只能有100MB的信箱容量。大部分的人可在2小時之內將100MB的信件移至Mandrake之上。當然，他們稍微有將上傳的時間點錯開。

使用者滿意的轉換成功率

扣除Client端轉換工作時程，伺服器端的轉換過程只花了不到2天的時間（包含安裝Mandrake、LMAIL與Exchange Server的公用通訊錄與郵件夾的轉換），師生們也都不需改變密碼與帳號。而所有Client端Outlook及Outlook Express的郵件與通訊錄，由500個USER自行使用LMAIL工具移植至LMAIL，大約也在兩星期之內全部完成。

扣除採購硬體設備的費用，此次花費在軟體轉換的成本不超過2,000塊美金，而且上線至今幾乎沒有再發生過當機事件。當然，這2,000塊美金沒有包含MIS與使用者在轉換過程所必須的投入的時間成本。

任何的轉換工具不可能是百分之百完美。可想而知的，通訊錄的轉換成功率遠高於郵件，通訊錄的成功轉換機率幾乎可達至99%以上。然而，Outlook Express又較Outlook成功率高得許多。我沒辦法提出十分具體的數字，但若要大概估計，Outlook Express可達95%以上，而Outlook大約可達90%左右。

轉換完成之後，有些非英文的內容偶爾會產生亂碼；有些html格式的郵有時無法十分正確的顯示內容….等。但是，我們也發現大部分的問題並不是無解，只是需要更多時間，在程式中針對特定問題個別解決。大體而言，該學院的資訊管理人員表示滿意，而多數使用者也認為已是個可接受的成功轉換率。

轉換過程中的意外插曲

在我們過去的經驗中，曾經服務過許多需求大不相同，但同樣殷切想從Windows轉換至Linux的客戶，其中有很多的轉換工作十分順利成功，當然也有一小部份不幸失敗。

我們在美國另外有家客戶是當地的某一工程師協會，會員人數共有3,000人，他們共架設2台Windows NT伺服器，由於會員散居各地，最重要的應用反而是FTP伺服器，因而安裝2台NT上的IIS。但因為2台NT上各有各的帳號與密碼，MIS計畫將2台NT伺服器上的帳號與密碼全部彙整至一台安裝Redhat 8.0的伺服器中。

這類的轉換應用對於LSP而言，原本是件輕而易舉的工作。有趣的是，在轉換過程中，發生了一件意料之外的事情。

經評估之後，該工程師協會決定使用LSP進行轉換工作，在一個下午的時間中，他們前後轉換2台NT伺服器。首先，MIS先將第一台NT伺服器利用LSP轉換至Redhat之上，之後再如法炮製轉換第二台NT，完成之後，發現了一個問題：他們的系統內原本共有60個群組，多數都已全部轉換至Redhat中，但其中有3大群組只轉成了一部份的使用者。

客戶通知我們之後，我們共花了2天時間才找出癥結。非常奇怪的，原來Redhat 8.0之上的群組功能，「似乎」無法容納超過一定數字以上的組員數量。我們沒有繼續追查原因，但發現其實在Redhat 7.3版之前，以及Redhat 9.0之後都沒有這個問題。（進行該轉換工作時，Redhat已推出9.0新版作業系統，但該客戶因已先購買而導入8.0）。之後，我們建議該工程師協會該台伺服器改成Redhat 9.0，同時重新進行一次轉換工作，該問題果然迎刃而解。

憑良心說，我們曾在不同廠牌的Linux，或是同一廠牌但不同版本的作業系統確實偶爾會遭遇類似的狀況，是事先能以掌握。從Windows轉換至Linux雖不是一件易如反掌的工作，但也不難如登天的重大工程，我相信，不論是要耐心手動完成，或是選擇一項好的轉換工具撙節時間成本，只要下定決心，在事前規劃得宜，大多數從Windows轉換至Linux的案子都可有其圓滿結果。