## Case #2: 導入 Windows Server 2003 x64 並整合多服務角色

### Problem Statement（問題陳述）
業務場景：單機承載 Web（ASP.NET 2.0）、SMTP、檔案分享、虛擬機、VPN/NAT、影片轉檔等多角色，需要升級作業系統至 64 位元以提升擴展性與整體反應，並降低舊架構限制。
技術挑戰：確保各角色在 x64 OS 正確運作，處理驅動與應用相容性，規劃 32/64 位元混合應用的併存策略。
影響範圍：所有對外服務，升級不當會導致服務中斷或相容性問題。
複雜度評級：高

### Root Cause Analysis（根因分析）
直接原因：
1. 需要 x64 OS 以支援更現代的服務與效能（EM64T）。
2. 原有應用中含 32 位元相依（如部落格），需處理併存。
3. 驅動程式、IIS、RRAS 等在 x64 的安裝與設定差異。

深層原因：
- 架構層面：多角色整合在同一 OS，依賴正確的位元模式管理。
- 技術層面：x64 與 WOW64 相容性議題。
- 流程層面：需要兼顧不停機與設定一致性。

### Solution Design（解決方案設計）
解決策略：進行乾淨安裝 Windows Server 2003 x64，對每個角色分別做 x64 版本部署；對僅支援 x86 的應用，透過 IIS 6 32 位元應用集區或替換方案處理；完成後進行服務驗證與觀察期。

實施步驟：
1. 安裝 OS 與驅動
- 實作細節：安裝 2003 x64，導入晶片組/網卡/儲存驅動。
- 所需資源：驅動包、KVM 或遠端管理。
- 預估時間：2-3 小時。

2. 部署各角色（Web、SMTP、File、RRAS、VM、Encoder）
- 實作細節：IIS 6、IIS SMTP、檔案分享、RRAS、虛擬化平台、WME9。
- 所需資源：安裝媒體、套件。
- 預估時間：4-6 小時。

3. 規劃 32/64 位元併存
- 實作細節：對特定站台啟用 x86 應用集區（見 Case #3）。
- 所需資源：IIS 管理工具。
- 預估時間：1 小時。

關鍵程式碼/設定：
```cmd
:: 驗證 OS 與 CPU 位元
wmic os get osarchitecture
wmic cpu get Name

:: 確認 ASP.NET 2.0 已註冊
%WINDIR%\Microsoft.NET\Framework64\v2.0.50727\aspnet_regiis.exe -i

## Case #3: x64 上運行 32 位元部落格的相容性處理（IIS 6 32-bit App Pool）

### Problem Statement（問題陳述）
業務場景：部落格系統僅能在 32 位元模式運行，但主機 OS 已升級至 Windows Server 2003 x64，造成網站無法在預設 64 位元應用集區運作。
技術挑戰：IIS 6 預設在 x64 啟動 64 位元工作行程，32 位元相依會導致載入失敗。
影響範圍：部落格網站對外服務中斷。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 部落格系統含 32 位元元件（可能為 COM/原生 DLL）。
2. IIS 6 預設 64 位元應用集區與 32 位元模組不相容。
3. 缺少對 x86 應用集區的正確設定。

深層原因：
- 架構層面：應用對平台位元耦合。
- 技術層面：IIS 6 工作者程序位元模式與 ISAPI/模組相依。
- 流程層面：升級前未完成相容性盤點。

### Solution Design（解決方案設計）
解決策略：為該網站建立 32 位元應用集區或臨時啟用整機 32 位元模式，確保網站可運作，並制定後續替換/升級計畫以移除 x86 相依。

實施步驟：
1. 啟用 32-bit Worker Process（IIS 6）
- 實作細節：Enable32bitAppOnWin64 設為 1。
- 所需資源：adsutil.vbs、IIS 6 管理工具。
- 預估時間：15 分鐘。

2. 分離應用集區並指派網站
- 實作細節：為部落格新建 x86 集區，其他站台用 x64 集區。
- 所需資源：IIS MMC。
- 預估時間：15 分鐘。

3. 長期策略：升級/替換部落格為 64 位元相容版本
- 實作細節：評估替代方案（作者選擇更換）。
- 所需資源：新系統評估與資料遷移。
- 預估時間：1-2 天。

關鍵程式碼/設定：
```cmd
:: 全機啟用 32 位元工作行程（若需）
cscript %SystemDrive%\Inetpub\AdminScripts\adsutil.vbs set w3svc/AppPools/Enable32bitAppOnWin64 1

:: 或建立專用 x86 應用集區（IIS MMC 中設定）
:: 並將部落格站台指派到該集區

## Case #4: IIS 6 上僅允許 ASP.NET 2.0（移除混用與非必要 ISAPI）

### Problem Statement（問題陳述）
業務場景：Web Server 僅需承載 ASP.NET 2.0 站台，為降低攻擊面與相容性風險，需移除不必要的舊版 ASP/ISAPI 以及無用的 Web 元件。
技術挑戰：IIS 6 預設可能啟用多種 Web 擴充，混用容易帶來相容性與安全風險。
影響範圍：所有 Web 站台的穩定性與安全性。
複雜度評級：低

### Root Cause Analysis（根因分析）
直接原因：
1. 非必要的 ISAPI/擴充被啟用，增加攻擊面。
2. 混用 ASP.NET 1.1/2.0 可能引起衝突。
3. 過多的 IIS 功能影響維護複雜度。

深層原因：
- 架構層面：缺乏最小化原則。
- 技術層面：IIS 擴充管理與版本並存問題。
- 流程層面：部署時未執行基線硬化。

### Solution Design（解決方案設計）
解決策略：僅註冊 ASP.NET 2.0 64 位元（或相應 x86 Pool 的 2.0），停用/移除無需的 ISAPI/擴充，建立基線設定與管控清單。

實施步驟：
1. 註冊 ASP.NET 2.0 並停用其他版本
- 實作細節：使用 aspnet_regiis 指定版本。
- 所需資源：.NET 2.0 工具。
- 預估時間：20 分鐘。

2. 移除不必要的 Web Service Extensions
- 實作細節：IIS 6 MMC -> Web Service Extensions -> 設為 Prohibit。
- 所需資源：IIS 6 MMC。
- 預估時間：20 分鐘。

3. 建立部署基線與稽核
- 實作細節：文件化允許清單。
- 所需資源：文件模板。
- 預估時間：1 小時。

關鍵程式碼/設定：
```cmd
:: 僅註冊 ASP.NET 2.0 (x64)
%WINDIR%\Microsoft.NET\Framework64\v2.0.50727\aspnet_regiis.exe -i

:: 禁用無需的 Web Service Extensions（使用 MMC 或 adsutil 進行）

## Case #5: 升級後 100Mbps 網路被塞爆，規劃 Gigabit 乙太網（GBE）

### Problem Statement（問題陳述）
業務場景：升級 CPU 與 x64 後，檔案/網頁傳輸高峰時出現 100Mbps 網路打滿的情況，成為系統新瓶頸。
技術挑戰：現有交換器/網卡僅 100M，無法應對提升後的處理與 IO 能力。
影響範圍：所有透過網路的服務吞吐與延遲。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 100Mbps 物理上限（實際約 94Mbps）已達頂。
2. 主機升級後，CPU/磁碟不再是瓶頸，使網路成為最弱環節。
3. 網路設備與佈線（Cat5）不支援 GBE。

深層原因：
- 架構層面：端到端容量不一致。
- 技術層面：網卡/交換器規格不足。
- 流程層面：升級規劃未同步網路層。

### Solution Design（解決方案設計）
解決策略：端到端升級至 GBE（伺服器 NIC、交換器、佈線），同步調整 OS 網路設定並進行吞吐測試與觀察，確保網路不再為首要瓶頸。

實施步驟：
1. 網路硬體升級
- 實作細節：更換為 1GbE NIC 與千兆交換器；檢查線材 Cat5e/Cat6。
- 所需資源：Intel/Realtek 1GbE NIC、GbE Switch、線材。
- 預估時間：2-3 小時。

2. OS 調整與測試
- 實作細節：安裝驅動；以 iperf 測試吞吐；必要時調整 Jumbo Frame。
- 所需資源：iperf、驅動工具。
- 預估時間：1-2 小時。

關鍵程式碼/設定：
```cmd
:: 以 iperf 測試（需另行下載 iperf）
iperf -s  :: 伺服器端
iperf -c <server-ip> -P 4 -t 30  :: 客戶端併發測試

## Case #6: 在 x64 主機上部署虛擬化平台並啟用硬體輔助

### Problem Statement（問題陳述）
業務場景：主機需同時承載多角色，虛擬化可用於隔離與測試。升級 CPU 後具備 VT 與 x64 能力，需落地虛擬化平台。
技術挑戰：確保 BIOS 開啟 VT、選型與部署相容的虛擬化平台、配置資源限制避免干擾主機。
影響範圍：所有在 VM 中的服務與主機穩定性。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 先前 CPU 不支援 VT，虛擬化受限。
2. BIOS 預設可能關閉 VT。
3. 資源配置不當會影響主機服務。

深層原因：
- 架構層面：多角色需要隔離層。
- 技術層面：虛擬化與硬體輔助依賴 BIOS/CPU。
- 流程層面：資源治理缺乏。

### Solution Design（解決方案設計）
解決策略：安裝虛擬化平台（如 Microsoft Virtual Server 2005 R2 或 VMware Server），在 BIOS 開啟 VT，創建 VM 並設定 CPU/記憶體/網路的資源界限與隔離，確保主機服務穩定。

實施步驟：
1. 開啟 VT 與檢查
- 實作細節：BIOS 內啟用 Intel VT-x；以工具確認。
- 所需資源：主機板 BIOS、檢測工具。
- 預估時間：30 分鐘。

2. 安裝虛擬化平台與建立 VM
- 實作細節：安裝 Virtual Server 2005 R2；用 VBS 自動化建立 VM。
- 所需資源：安裝媒體、管理工具。
- 預估時間：2 小時。

關鍵程式碼/設定：
```vb
' VBScript：建立 Virtual Server VM（概念示例）
Set vs = CreateObject("VirtualServer.Application")
Set vm = vs.CreateVirtualMachine("TestVM", "D:\VMs\TestVM.vmc")
vm.Memory = 512 * 1024 * 1024 ' 512MB
vm.Save

## Case #7: 在 2003 x64 配置 RRAS 實現 VPN 與 NAT

### Problem Statement（問題陳述）
業務場景：同一台主機需提供 VPN 與 NAT，讓遠端可存取內網，同時讓內網設備透過主機對外。
技術挑戰：正確啟用 RRAS 功能，配置 NAT 與 VPN（PPTP/L2TP），處理基本防火牆與路由。
影響範圍：遠端辦公、內網對外連線。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 未安裝與啟用 RRAS。
2. 路由/NAT 介面未正確指定。
3. VPN 通道與認證未正確設定。

深層原因：
- 架構層面：單機多角色需要網路邊界能力。
- 技術層面：RRAS 配置細節繁多。
- 流程層面：缺乏自動化與文件化。

### Solution Design（解決方案設計）
解決策略：在 2003 x64 啟用 RRAS，配置一張外網、一張內網 NIC，開啟 NAT 與 VPN，進行通訊測試與基本強化（允許清單、憑證）。

實施步驟：
1. 安裝與啟用 RRAS
- 實作細節：管理工具中啟用，或用 netsh 基本腳本。
- 所需資源：系統元件。
- 預估時間：1 小時。

2. 配置 NAT 與 VPN
- 實作細節：指定外網介面做 NAT，建立 VPN 入口（PPTP）。
- 所需資源：靜態路由規劃、帳號。
- 預估時間：1-2 小時。

關鍵程式碼/設定：
```cmd
:: 啟用 RRAS（需在 GUI 或 routing 命令中完成細節）
netsh routing ip nat install
netsh routing ip nat add interface "WAN" full
netsh routing ip nat add interface "LAN" private

:: 範例：允許 PPTP（TCP 1723）與 GRE（協定 47）通過防火牆/路由

## Case #8: 檔案伺服器在 x64 的快取與吞吐優化

### Problem Statement（問題陳述）
業務場景：主機同時扮演檔案伺服器，升級後出現 100M 網路瓶頸，意味著核心瓶頸從 CPU/磁碟轉移到網路。需在 x64 下適當調整檔案快取與網路以達到更穩定吞吐。
技術挑戰：Windows 2003 x64 的檔案快取與 TCP 參數調整。
影響範圍：檔案存取速度、備份/傳輸任務效率。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. x64 增加系統可用 VA 與快取空間，吞吐提升。
2. 網路 100M 成為瓶頸（見 Case #5）。
3. 預設設定未針對檔案伺服器最佳化。

深層原因：
- 架構層面：單機多角色爭用 IO。
- 技術層面：快取/網路參數未調整。
- 流程層面：缺乏基準與監控。

### Solution Design（解決方案設計）
解決策略：透過登錄鍵調整 LargeSystemCache 與檔案伺服器優化，搭配網路升級與基準測試，建立可重現的吞吐曲線。

實施步驟：
1. 啟用檔案伺服器快取優化
- 實作細節：調整 LanmanServer 參數、LargeSystemCache。
- 所需資源：reg.exe、重開機維護窗。
- 預估時間：30 分鐘。

2. 建立吞吐基準與監控
- 實作細節：robocopy/iperf 與 perfmon。
- 所需資源：工具下載。
- 預估時間：1-2 小時。

關鍵程式碼/設定：
```cmd
:: 啟用大型系統快取
reg add HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management /v LargeSystemCache /t REG_DWORD /d 1 /f

:: Server 服務最佳化為檔案共享
reg add HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters /v Size /t REG_DWORD /d 3 /f

## Case #9: 影片轉檔到 WMV 的雙核心批次化流程

### Problem Statement（問題陳述）
業務場景：主機需將 DV/DC 影片壓成 WMV。升級為雙核心後，應善用平行處理加速轉檔，同時避免影響前台服務。
技術挑戰：在 x64 環境使用工具鏈（Windows Media Encoder 9）與腳本化批次處理；控制優先級與併發數。
影響範圍：影片轉檔速度與主機響應。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 單執行緒轉檔無法利用雙核心。
2. 無批量流程導致手動成本高。
3. 背景轉檔與前台服務競爭資源。

深層原因：
- 架構層面：缺乏作業佇列/計劃。
- 技術層面：未使用腳本化與優先級控管。
- 流程層面：缺乏排程與資源治理。

### Solution Design（解決方案設計）
解決策略：以 WME9 提供的自動化腳本進行批次轉碼，控制同時任務數為 2（對應雙核心），將轉碼程序設置為低優先級並於離峰時段執行。

實施步驟：
1. 建立批次轉碼腳本
- 實作細節：使用 wmcmd.vbs 或 WME COM 自動化。
- 所需資源：WME9、VBScript。
- 預估時間：1-2 小時。

2. 排程與優先權控管
- 實作細節：Task Scheduler 於離峰啟動；低優先級/CPU 親和性。
- 所需資源：排程器、批次檔。
- 預估時間：30 分鐘。

關鍵程式碼/設定：
```cmd
:: 以 wmcmd.vbs 進行轉檔（路徑視安裝而定）
cscript wmcmd.vbs -input:input.avi -output:output.wmv -v_codec:WMV9 -a_codec:WMA9

:: 低優先級啟動（避免壓垮前台）
start "" /low cscript wmcmd.vbs -input:%1 -output:%~n1.wmv ...

## Case #10: 多角色單機的資源隔離：保護 Web 服務不被背景任務拖慢

### Problem Statement（問題陳述）
業務場景：主機同時跑 Web、轉碼、檔案分享等，作者偏好讓機器「忙一點」。需避免背景工作影響前台 Web 響應。
技術挑戰：在單機上限制背景任務的 CPU/記憶體使用，合理排程與親和性設定。
影響範圍：Web SLA、使用者體驗。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 背景任務（轉碼等）高耗 CPU。
2. 未設優先級/親和性造成爭用。
3. 無資源上限或監控。

深層原因：
- 架構層面：多角色共機。
- 技術層面：缺乏 OS 層級資源治理。
- 流程層面：缺乏排程策略。

### Solution Design（解決方案設計）
解決策略：對背景程式設定低優先級與 CPU 親和性，必要時限制在單一核心；配合排程器在離峰執行；建立基本監控與告警。

實施步驟：
1. 設定進程優先級與親和性
- 實作細節：透過 start 參數或自製小工具。
- 所需資源：批次/小程式。
- 預估時間：30 分鐘。

2. 排程與監控
- 實作細節：Task Scheduler、perfmon 閾值告警。
- 所需資源：Windows 工具。
- 預估時間：1 小時。

關鍵程式碼/設定：
```cmd
:: 將轉碼程序設為低優先級、限用 CPU 2（十六進位 mask 02）
start "" /low /affinity 2 cscript wmcmd.vbs -input:%1 -output:%~n1.wmv ...

## Case #11: 程式化偵測進程位元架構（.NET 2.0 上的 32/64 位元判斷）

### Problem Statement（問題陳述）
業務場景：在 x64 OS 上需要判斷某應用是否以 32 位元或 64 位元執行，以決定載入對應元件或採取容錯（與部落格相容議題對應）。
技術挑戰：.NET 2.0 尚無內建 Is64BitProcess 屬性，需要透過 Win32 API 判斷。
影響範圍：相容性與錯誤處理。
複雜度評級：低

### Root Cause Analysis（根因分析）
直接原因：
1. .NET 2.0 不提供直接屬性。
2. 需要透過 IsWow64Process 判斷。
3. 載入錯誤可能導致應用崩潰。

深層原因：
- 架構層面：二進位相依性。
- 技術層面：x64/WOW64 行為理解不足。
- 流程層面：缺乏啟動前檢查。

### Solution Design（解決方案設計）
解決策略：在應用啟動時偵測進程位元模式，針對 x86/x64 做相容性分支或提示，避免載入不相容模組。

實施步驟：
1. 實作偵測函式
- 實作細節：P/Invoke IsWow64Process。
- 所需資源：.NET 2.0、C#。
- 預估時間：30 分鐘。

2. 併入啟動邏輯
- 實作細節：決定載入路徑或給予提示。
- 所需資源：應用程式碼基。
- 預估時間：30 分鐘。

關鍵程式碼/設定：
```csharp
using System;
using System.Runtime.InteropServices;

class Bitness
{
    [DllImport("kernel32.dll", SetLastError=true, CallingConvention=CallingConvention.Winapi)]
    [return: MarshalAs(UnmanagedType.Bool)]
    static extern bool IsWow64Process(IntPtr hProcess, out bool wow64);

    public static bool Is64BitProcess()
    {
        if (IntPtr.Size == 8) return true; // 原生 x64
        bool isWow64;
        if (IsWow64Process(System.Diagnostics.Process.GetCurrentProcess().Handle, out isWow64))
            return !isWow64; // x86 on x64 -> wow64 = true
        return false; // 無法判斷時視為 x86
    }
}

## Case #12: 無 EIST 的 Pentium D 920 前期版本之功耗/溫度治理

### Problem Statement（問題陳述）
業務場景：作者購買的 920 為早期版本，不支援 Enhanced SpeedStep（EIST），導致無法動態降頻降壓，可能帶來較高功耗與溫度。
技術挑戰：在無 EIST 的情況下降低功耗與溫度，維持穩定度。
影響範圍：電費、散熱噪音、硬體壽命。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 2006 Q2 前的 920 不支援 EIST。
2. 主機板/BIOS 無法提供動態節能。
3. 24/7 背景運算增加發熱。

深層原因：
- 架構層面：老舊製程與高 TDP。
- 技術層面：CPU Stepping 限制。
- 流程層面：購買前未確認規格（「功課沒做好」）。

### Solution Design（解決方案設計）
解決策略：短期採用 BIOS 手動降壓/固定較低倍頻（若主板支援）、優化散熱與機箱風道、限制背景任務利用率；中期考慮更換支援 EIST 的後期 920 或升級平台。

實施步驟：
1. 散熱與電源優化
- 實作細節：高效散熱器、導熱膏、風道管理。
- 所需資源：散熱器、風扇。
- 預估時間：1-2 小時。

2. 手動降壓/限頻（視主板）
- 實作細節：BIOS Offset Undervolt、關閉自動超頻。
- 所需資源：BIOS。
- 預估時間：30 分鐘。

3. 任務治理
- 實作細節：背景任務 CPU 使用率上限/低優先級（見 Case #10）。
- 所需資源：腳本。
- 預估時間：30 分鐘。

關鍵程式碼/設定：
```cmd
:: 以低優先級啟動耗能任務，間接降低平均功耗
start "" /low cscript wmcmd.vbs -input:%1 -output:%~n1.wmv ...

## Case #13: 以 PerfMon 偵測並證明網路瓶頸（100M 塞滿）

### Problem Statement（問題陳述）
業務場景：需要客觀證據證明 100M 網路已成瓶頸，以支持升級至 GBE 的決策。
技術挑戰：收集與視覺化性能數據，避免只靠主觀感受。
影響範圍：IT 預算與升級時程。
複雜度評級：低

### Root Cause Analysis（根因分析）
直接原因：
1. 缺乏長期的網路介面利用率資料。
2. 未對高峰期做好記錄。
3. 無基準對照。

深層原因：
- 架構層面：監控不足。
- 技術層面：對 PerfMon/計數器不熟悉。
- 流程層面：缺少例行性能報告。

### Solution Design（解決方案設計）
解決策略：建立 PerfMon 記錄工作，持續記錄 Network Interface(*)\% Network Utilization、Bytes Total/sec 等，導出報表與圖表，以數據支撐升級。

實施步驟：
1. 建立 Data Collector
- 實作細節：使用 logman 或 GUI 建立計數器日誌。
- 所需資源：內建工具。
- 預估時間：30 分鐘。

2. 報表與決策支持
- 實作細節：定期匯出 CSV、生成圖表。
- 所需資源：Excel/腳本。
- 預估時間：1 小時。

關鍵程式碼/設定：
```cmd
:: 建立網路性能記錄（每 5 秒取樣）
logman create counter NetLog -c "\Network Interface(*)\Bytes Total/sec" "\Network Interface(*)\Output Queue Length" -si 00:00:05 -o C:\Perf\NetLog.blg
logman start NetLog
:: ...觀察一段時間後
logman stop NetLog
relog C:\Perf\NetLog.blg -f csv -o C:\Perf\NetLog.csv

## Case #14: 部署 SMTP 伺服器（IIS 6 SMTP）於 x64 環境

### Problem Statement（問題陳述）
業務場景：主機提供 SMTP 服務，用於系統通知與郵件轉送。需確保在 x64 環境可用與安全。
技術挑戰：IIS 6 SMTP 在 x64 為 32 位元元件，需處理相依與基本防濫發設定。
影響範圍：郵件可靠性與信譽。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. SMTP 元件為 x86，需確認相容。
2. Relay/匿名設定容易誤用成開放中繼。
3. DNS 反查/SPF 設定不足導致退信。

深層原因：
- 架構層面：多角色共存需最小暴露。
- 技術層面：SMTP 配置細節。
- 流程層面：缺乏寄出監控。

### Solution Design（解決方案設計）
解決策略：安裝 IIS 6 SMTP，設定受信來源、限制 Relay，配置退信處理與基本 DNS/SPF，建立投遞佇列監控。

實施步驟：
1. 安裝與基本配置
- 實作細節：指定 Smart Host 或 DNS，限制 Relay。
- 所需資源：IIS 元件、DNS。
- 預估時間：1 小時。

2. 安全與監控
- 實作細節：啟用日誌、監控 Queue 長度。
- 所需資源：事件檢視器/自動化腳本。
- 預估時間：1 小時。

關鍵程式碼/設定：
```cmd
:: 啟用 SMTP 服務（透過「新增/移除 Windows 元件」）
:: 日誌位置與格式於 MMC 設定；
:: 定期檢查 C:\Inetpub\Mailroot\Queues 的佇列堆積

## Case #15: 驗證 CPU 功能的程式化工具（CPUID：VT/EM64T）與部署前檢核

### Problem Statement（問題陳述）
業務場景：在硬體採購/部署前需快速驗證處理器是否支援 VT 與 EM64T，以避免像 820 那樣不支援 VT 的情況。
技術挑戰：跨機器快速準確檢測，並產出報告。
影響範圍：硬體選型與部署效率。
複雜度評級：低

### Root Cause Analysis（根因分析）
直接原因：
1. 人工查表易誤。
2. 無統一檢測腳本。
3. 多台主機需盤點。

深層原因：
- 架構層面：前置檢核流程缺失。
- 技術層面：對 CPUID 與工具不熟。
- 流程層面：採購前驗證未制度化。

### Solution Design（解決方案設計）
解決策略：提供可攜小工具（C/C++ 或 PowerShell+WMI）批量檢測 VT/EM64T，將結果輸出 CSV 供決策參考。

實施步驟：
1. 製作檢測程式
- 實作細節：使用 __cpuid 或第三方工具調用。
- 所需資源：編譯環境。
- 預估時間：1-2 小時。

2. 批量盤點與報告
- 實作細節：透過登入腳本/管理工具收集結果。
- 所需資源：網域/SMB。
- 預估時間：2 小時。

關鍵程式碼/設定：
```c
// 參考 Case #1 的 CPUID 程式，輸出 CSV 行：Host,VT,EM64T

## Case #16: 規劃端到端 GBE 升級與驗證（含佈線、設備與測試）

### Problem Statement（問題陳述）
業務場景：100M 網路已成瓶頸，需落地端到端 GBE 升級並驗證，避免「升級不完全」導致效益不彰。
技術挑戰：確保 NIC/交換器/線材/驅動全數達標與相容；建立標準驗證流程。
影響範圍：所有網路服務的吞吐與延遲。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 任一環節未升級都會回落至 100M。
2. 驅動與設定（如 Jumbo）未對齊。
3. 缺乏標準驗證步驟。

深層原因：
- 架構層面：端到端思維不足。
- 技術層面：設備異廠相容議題。
- 流程層面：缺乏驗證清單。

### Solution Design（解決方案設計）
解決策略：制定升級清單與驗證順序，包含硬體更換、驅動更新、OS 設定、iperf/SMB 實測；保留回退計畫。

實施步驟：
1. 清單與現況盤點
- 實作細節：列出路徑所有節點與規格。
- 所需資源：資產清冊。
- 預估時間：1 小時。

2. 分段升級與測試
- 實作細節：逐段以 iperf 驗證；最後以 SMB 實測。
- 所需資源：iperf、測試檔。
- 預估時間：2-4 小時。

關鍵程式碼/設定：
```cmd
:: NIC 進階設定（視驅動程式 GUI）
:: ipconfig /all 確認連線速率與雙工
:: iperf 同步雙向測試：iperf -c <server> -P 4 -t 30 -d