如同前一篇文章提及，最近有空就是在做 Windows Server 2019 的安裝升級及測試。先說本文結論好了，以下不代表任何官方及公司或團體，若有考慮原地升級到 Server 2019，
建議起新機，再將服務及設定做移轉
原因及測試如下
Page 3 of 41
從 Windows Server 2008 開始，微軟就已經支援原地升級版本 ( In-place Upgrade )，不管是選擇原地升級還是全新安裝做移轉，其實都有風險存在，需要妥善規劃及完整測試。
畢竟是吃這行飯，總要走在前面些，最近也開始在著手進行 Windows Server 2019 的測試；一般我在做測試或佈建階段，大都會先利用微軟公開的 AVMA Key 或 KMS Key 進行安裝，避免零售版 (MAK) 金鑰啟用太多次，但這次在安裝 Server 2019 時卻遇到奇怪的狀況。
常用 Facebook 的朋友可能會發現，點擊 Facebook 外部貼文的網址連過去後，網址列會莫名被加了「?fbclid=」再接一大串參數。主要是 Facebook 近期改以這方式來改善及追蹤分享狀況，但根據國內外討論，這樣會嚴重影響像是 Google Analytics 的分析。
一般對 fbclid 參數的處理會有兩種角度，一種是用戶自己在瀏覽器加 Redirector 外掛做去除，只是…會想加外掛的應該都是進階使用者了，一般使用者根本就不會注意也不會關心。
另一個角度則是由網站管理者處理。自己研究相關資料，網站管理者的處理方式也分兩種。
APCUPSD 是我除了 Network UPS Tools 另一套很愛用的 UPS 管理軟體，不僅完整提供基本狀況顯示及 Tray Icon，還能作到 Server / Client Agent 的監控方式，也就是用一台主機就能讓其他台僅有電源線接在 UPS 的電腦，於電源異常狀態下自動執行關機，而且同樣跨平台完全免費，連家用級的 APC UPS 都能納入管理控制。只是，如同名字所述，他僅能管控 APC 的不斷電系統。
另外，APCUPSD 還提供了網頁式的狀態監控，所以之前花了一點時間研究，終於成功把他掛入 Windows IIS 中運作。但前陣子將底層的 Windows Server 升級後，卻發現頁面出現了亂碼；與早期使用 Windows Server 2008 R2 / IIS 7.5 時，日期時間顯示為全英文資訊不同。檢查發現，網頁預設為 UTF8，手動在瀏覽器轉編碼為 BIG5 後，亂碼就恢復正常顯示「台北標準時間」。
在前面文章有說明如何用 Fortigate 與 Azure 做站對站 VPN，但建起來的連線是單條線路，一般企業不太可能接受及擔負單條線路帶來的風險，所以我嘗試實做及測試，用雙線路與 Azure VPN Gateway 建立 VPN 連線，期望能達成高可用性的運作目標。
地端 VPN 設備同樣使用 Fortigate，線路的部份採用一條中華電信 (CHT)，另一條為遠傳 (Sparq)。
本文不會對設定位置及欄位做太多說明，因為前文已提及。先簡單結論這次的佈建，其實就是在 Azure 及 Fortigate 上，再做一次 VPN 的設定建立。
在建好 Azure 與地端的 Site to Site VPN 後，心中有了一個大膽的想法
因為在預設狀況下， Azure 上的資源都是直接從雲端上 Internet，是否有可能強制走 VPN 從地端出去呢? 幾番測試研究後，終於實做出來。
[警語] 請務必閱讀完，瞭解設定後的狀況
近期留言