2026年6月4日星期四

使用NSSM將Nginx程式轉為Windows服務。(通用其他程式)

NSSM (Non-Sucking Service Manager) 的主要用途正如你所聽到的：它可以把任何傳統的執行檔（.exe）或腳本（.bat、.cmd、.vbs、PowerShell、Python 等）封裝並註冊成 Windows 服務（Windows Service）。

在預設情況下，Windows 無法直接將一般的程式當作服務來執行，因為標準的 Windows 服務必須遵循特定的 Service Control Manager (SCM) 通訊協定。如果直接用系統指令硬把普通 .exe 註冊成服務，啟動時通常會跳出「服務未回應控制要求」的錯誤。

NSSM 就是為了解決這個痛點而生的「代理人（Proxy）」。

為什麼要使用 NSSM？（核心功能）

1. 讓普通程式具備「服務」的特性

開機自動背後執行： 即使沒有使用者登入 Windows 系統，程式也會在背景自動啟動。
權限控管： 可以指定特定的系統帳戶（如 LocalSystem）或特定的網域/本地使用者帳戶來執行該程式。

2. 強大的崩潰自動重啟機制 (Auto-Restart)

這是 NSSM 最受工程師青睞的功能。如果你的程式因為 Bug、記憶體溢位或其他原因不正常關閉（Crash），NSSM 會自動監測到並立刻重啟該程式。它還內建了「重啟延遲」設定，防止程式陷入無限快速重啟的死迴圈。

3. 完美的 I/O 重新導向 (日誌記錄)

一般的控制台程式（Console Application）運行時會有輸出畫面（stdout 和 stderr）。變成服務後，這些畫面會消失。NSSM 可以幫你把這些原本會顯示在黑畫面的文字，即時寫入到指定的 .log 文字檔中，方便日後查修。

4. 優雅的關閉機制 (Graceful Shutdown)

當你停止服務時，NSSM 不會粗暴地直接殺掉（Kill）你的程式，而是會循序漸進地發送作業系統關閉訊號（如 WM_CLOSE、WM_QUIT），讓你的程式有時間處理未完的資料、關閉資料庫連線後才乾淨地結束。

常見的應用場景

在企業 IT 環境或開發流程中，NSSM 常被用來封裝以下類型的程式：

Web 服務/API 伺服器： 例如用 Python (Flask/FastAPI)、Node.js、Go 語言寫好的後端程式，需要 24 小時在 Windows 伺服器上穩定運行。
自動化腳本： 定時執行的批次檔（.bat）或 PowerShell 監控腳本。
開源工具： 許多從 Linux 移植過來、沒有原生 Windows 服務介面的開源工具（例如早期的 Prometheus Exporter、某些資料庫轉發工具）。

如何使用 NSSM？（極簡步驟）

NSSM 最棒的地方在於它同時提供了圖形介面 (GUI) 和命令列 (CLI)，操作非常直覺。

使用圖形介面安裝服務：

下載並解壓縮 NSSM。
打開命令提示字元 (CMD) 並切換到 nssm 所在目錄，輸入：
nssm install 你的服務名稱
此時會跳出一個 GUI 視窗：
- Path: 選擇你要執行的 .exe 或直譯器（如 python.exe）。
- Startup directory: 程式運行的工作目錄（通常會自動帶入）。
- Arguments: 程式需要的參數（例如 runserver 0.0.0.0:8000 或腳本路徑）。
- 在 I/O 頁籤可以設定 Log 輸出路徑。
點擊 Install service 就完成了！接下來就可以去 Windows 的 services.msc（服務管理面板）裡面看到它，並設定成自動啟動。

常用命令列指令：

如果你想透過指令快速管理，它也支援：

建立服務: nssm install 你的服務名稱
刪除服務： nssm remove 你的服務名稱
啟動服務： nssm start 你的服務名稱
停止服務： nssm stop 你的服務名稱
編輯現有服務： nssm edit 你的服務名稱（會再次跳出 GUI 視窗讓你修改設定）

總結來說，NSSM 是一個非常輕量、穩定且完全免費的工具，是 Windows 系統管理員與開發者在處理背景程序時的必備神器。

======================================================

如果你在命令提示字元（CMD）中輸入了：

 nssm install nginx 
or
 nssm edit nginx

這時候系統會跳出 NSSM 的圖形化設定視窗（NSSM Service Installer），讓你填寫詳細的執行路徑與參數。

因為 Nginx 官方的 Windows 版本本身就只是一個普通的控制台程式（Console Application），沒有內建 Windows 服務的控制代碼，所以用 NSSM 來封裝它是非常標準且常見的做法。

請按照以下步驟在跳出的視窗中進行設定：

1. 欄位設定指引

在跳出的 Application 頁籤中，請填入以下資訊：

Path (目的程式路徑)： 點擊右側的 ... 按鈕，找到你解壓縮 Nginx 的目錄，選取 nginx.exe。
範例：C:\nginx\nginx.exe
Startup directory (啟動工作目錄)： 當你選好 Path 之後，這個欄位通常會自動帶入。請確保它是 nginx.exe 所在的資料夾。
範例：C:\nginx ⚠️ 注意： 這個欄位非常重要，因為 Nginx 啟動時需要去相對路徑讀取 conf/nginx.conf 檔案，如果工作目錄弄錯，服務會啟動失敗。
Arguments (啟動參數)： 這裡留空即可（通常不需要填寫，預設就會直接啟動）。

2. 建議進階設定：日誌重新導向 (I/O)

雖然 Nginx 本身就會寫入 logs/error.log，但如果 Nginx 因為主設定檔（nginx.conf）寫錯而導致「根本連開都開不起來」時，Nginx 自己的 Log 是不會有紀錄的。

建議切換到 I/O 頁籤：

Output (stdout): 設為 C:\nginx\logs\nssm_stdout.log
Error (stderr): 設為 C:\nginx\logs\nssm_stderr.log

這樣一來，如果服務啟動失敗，你可以直接來這兩個檔案看 Windows 拋出的最底層錯誤訊息。

3. 完成與啟動服務

欄位填妥後，點擊視窗下方的 Install service 按鈕。
看到彈出 Service "nginx" installed successfully! 的成功訊息後，代表服務已經註冊成功。
啟動 Nginx： 此時服務雖然註冊了，但預設還沒開始執行。請在 CMD 輸入以下指令來啟動它：
nssm start nginx
（或者你可以按 Win + R 輸入 services.msc 打開 Windows 服務管理員，找到 nginx 點選「啟動」，並確認啟動類型為「自動」）。

💡 日後如何維護？

變成 Windows 服務後，當你修改了 nginx.conf 設定檔，請不要直接去點 nginx.exe，也不要用 nginx -s reload（因為那會脫離 NSSM 的控制），請統一使用 NSSM 的指令：

重新啟動服務（應用新設定）： nssm restart nginx
停止服務： nssm stop nginx
修改 NSSM 設定： 如果路徑填錯了，輸入 nssm edit nginx 可以重新打開圖形視窗修改。
移除服務： 如果以後不想用了，輸入 nssm remove nginx 即可乾淨刪除。

https://drive.google.com/file/d/1NOaoX1tJyoeHKnQbI8vD3CbsgT7Jsoh-/view?usp=drive_link

2026年6月3日星期三

Nginx漏洞修補與升級方式說明(Windows)

面對這個剛爆發不久的 CVE-2026-42945 (NGINX Rift) 高風險漏洞，果斷選擇升級是非常正確的決定。這個漏洞存在於 Nginx 的重寫模組（ngx_http_rewrite_module）中，會導致堆疊緩衝區溢位（Heap Buffer Overflow），可能引發遠端程式碼執行（RCE）或阻斷服務攻擊（DoS）。

針對 Windows 環境下將 Nginx 1.19.6 升級的完整步驟與注意事項，為您整理如下：

步驟一：確認目標版本

官方已針對此漏洞釋出修補版本。既然您目前使用的是開源版本，建議升級至以下版本或更新的版本：

穩定版 (Stable)： 1.30.1 或以上

主力版 (Mainline)： 1.31.0 或以上

請至 Nginx 官方下載頁面 (nginx.org) 下載對應 Windows 的 .zip 壓縮包。

步驟二：備份現有環境（核心步驟）

在進行任何升級前，請務必先備份目前的設定與檔案，以防萬一需要復原。

請拷貝現有 Nginx 目錄（例如 C:\nginx-1.19.6\）中的以下內容：

conf/ 目錄：包含主要的 nginx.conf 及其他設定檔。

html/ 或 www/ 目率：您的網頁網頁靜態檔案（若有放在這裡）。

SSL 憑證：若有存放憑證在 Nginx 目錄下，請務必備份。

步驟三：執行升級流程 (無縫替換)

Windows 版的 Nginx 不需要安裝，它是以綠色免安裝（攜帶版）的方式執行。請依照以下步驟手動替換：

1. 停止目前的 Nginx 服務

打開命令提示字元 (CMD) 並切換到您目前的 Nginx 目錄，執行以下指令安全停止服務：

    $ nginx.exe -s quit && sudo apt-get upgrade

(如果 Nginx 完全沒有回應，可以使用 taskkill /f /im nginx.exe 強制結束行程)。若您有將 Nginx 註冊為 Windows 服務（如使用 WinSW 或 NSSM），請至 Windows「服務」視窗中將其停止。

2. 解壓新版本

將下載好的新版本（例如 nginx-1.30.1.zip）解壓縮到新的目錄（例如 C:\nginx-1.30.1\）。

3. 遷移設定檔

將步驟二備份的 conf/ 目錄內的所有設定檔（特別是 nginx.conf），複製並覆蓋到新版 C:\nginx-1.30.1\conf\ 目錄中。

4. 測試新版本設定檔是否相容

從 1.19.6 跨越到 1.30.x 版本跨度較大，某些語法可能有所變更。在啟動前，請在 CMD 切換到新目錄並執行測試：

cd C:\nginx-1.30.1
nginx.exe -t

若顯示 syntax is ok 和 test is successful：代表設定檔相容，可以正常使用。
若報錯：請根據錯誤訊息調整 nginx.conf 中不再支援的舊語法。

5. 啟動新版 Nginx

測試成功後，直接啟動新版 Nginx：

start nginx

（若原本有使用 Windows 服務工具如 WinSW，請記得將工具內的執行路徑更新為新版的 C:\nginx-1.30.1\nginx.exe，然後啟動該服務）

但是

Windows 綠色版唯一的「小缺點」與維運解法

雖然它是免安裝的，但這也意味著：當 Windows 伺服器重開機時，Nginx 預設是不會自己啟動的。在企業的 Windows Server 生產環境中，系統管理員通常不會手動去雙擊 nginx.exe，而是會使用第三方工具（最常見的是 WinSW 或 NSSM），將這個綠色版的 nginx.exe 包裝註冊成「Windows 系統服務」。

這時候就要提到NSSM的應用。

透過使用NSSM將程式轉為Windows服務。

2026年5月14日星期四

VMware VCenter 6.7設定Log Server失敗

使用vCenter 6.7 設定步驟開啟 VAMI 介面：開啟瀏覽器，輸入 https://<您的vCenter_IP>:5480。

登入：使用 root 帳號及其密碼登入。

進入 Syslog：點選左側選單最下方的「Syslog」索引標籤。

設定轉送：在「轉送組態」(Forwarding Configuration) 區塊，點擊「設定」(Configure)。填寫伺服器資訊：伺服器位址：輸入您的 Log Server IP 或 FQDN。

通訊協定：6.7 版本同樣支援 UDP、TCP、TLS、RELP 協定。

連接埠：預設為 514 (UDP/TCP)

錯誤訊息:

Error in method invocation _failure() missing 1 required positional argument: 'err'

不是你 Log Server IP 填錯，也不是 514 port 問題。

這是 VMware vCenter Server VAMI (:5480) 裡面很有名的爛 Python UI 例外錯誤。人類很愛把「後端報錯」直接丟給管理員，彷彿你應該通靈知道 _failure() 少了什麼參數。

通常代表：

VAMI 前端送出設定失敗

後端 service 沒正常回應

syslog config validation 爆掉

某些 protocol 在 6.7 有 bug

certificate / hostname 驗證問題

appliance service 異常

而不是單純「不能設定」。

你現在應該改查：

SSH登入VMware Vcenter

shell 進入設定。

1. 查看 rsyslog 狀態


systemctl status rsyslog

如果沒跑：


systemctl restart rsyslog

直接看目前 syslog 設定：

cat /etc/vmware-syslog/syslog.conf

加入log server設定

假如Log Server IP: 1.2.3.4

*.* @1.2.3.4:514

再測：

rsyslogd -N1

如果顯示：

End of config validation run. Bye.

代表 config 正常。

代表：

rsyslog 設定檔語法是正常的

所以問題不是：

config syntax
forwarding rule
URI 格式

而是：

rsyslog 啟動階段失敗

通常剩下幾種可能：

PID file 問題
socket 被占用
權限問題
module 載入失敗
log file 無法寫入
disk 滿了
SELinux/AppArmor
systemd limit/cache 問題

現在要直接看 rsyslog 真正 stderr。

請執行


rsyslogd -dn

注意：

-d = debug
-n = foreground

它會直接噴真正錯誤。

root@photon-machine [ / ]# rsyslogd -dn rsyslogd: error reading pid file, cannot start up rsyslogd: run failed with error -3000 (see rsyslog.h or try https://www.rsyslog.com/e/3000 to learn what that number means)

你的問題是：


error reading pid file, cannot start up

代表：

rsyslog 的 PID file 壞掉或卡住了

通常是：

上次 crash
abnormal shutdown
service 沒正常結束
PID file 殘留
權限錯誤

導致 rsyslog 認為：

「已經有另一個 rsyslog 在跑」。

立刻處理

先找 PID file：


find /run /var/run -name "*rsyslog*.pid"

通常會看到：


/var/run/rsyslogd.pid

確認目前沒有 rsyslog process


ps -ef | grep rsyslog

正常情況應該只剩 grep 自己。

如果沒有真正 rsyslogd process：

改名或刪除 PID file(建議改名)

例如：
mv /var/run/rsyslogd.pid /var/run/rsyslogd.pid.bak


rm -f /var/run/rsyslogd.pid

reset systemd failed state


systemctl reset-failed rsyslog



再啟動
systemctl start rsyslog

查看：
systemctl status rsyslog

查看服務，終於正常 active (running)


回到
VMware vCenter Server VAMI (:5480)
 進入 Syslog：點選左側選單最下方的 「Syslog」 索引標籤。
 設定轉送：在「轉送組態」(Forwarding Configuration) 區塊，點擊 「設定」(Configure)。
總算是沒有下面的錯誤訊息了，檢查Log Server，也確認有收到Log。
設定成功。

錯誤訊息:
Error in method invocation _failure() missing 1 required positional argument: 'err'

因為Nessus 弱點掃描，而將Windows關閉停用 SSL 2.0 , SSL 3.0 和 TLS 1.0, 1.1，並強制使用 TLS 1.2處理(用 IIS Crypto 工具處理法)

方法：IIS Crypto（比較符合人類文明）

工具：

IIS Crypto

操作

建議直接：

勾：
- TLS 1.2
取消：
- SSL 2.0
- SSL 3.0
- TLS 1.0
- TLS 1.1（建議）
- 3DES

然後：

Apply
Reboot

考慮安全性說明:

IIS Crypto 是安全且在業界被廣泛信賴的工具。

在系統管理與資安稽核的領域中，它幾乎是處理 Windows Server SSL/TLS 設定的「標準配備」。雖然它是第三方軟體，但其運作機制非常透明且單純。

以下從幾個維度幫你分析它的安全性與可靠性：

1. 運作機制：它只是個「註冊表包裝器」

IIS Crypto 本身並不包含任何加密演算法，也不會安裝任何系統服務或後端程式。

本質： 它只是一個圖形化界面（GUI），幫你修改我們之前討論過的那些 Schannel 註冊表路徑（HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\...）。
不常駐： 設定完、按下 Apply 並重啟後，你可以直接刪除這個 .exe 檔案，它不會留在系統中執行。

2. 為什麼專業人士愛用它？

避免人為錯誤： 就像你之前糾結要寫 168 還是 168/168，手動改 Registry 很容易打錯字。IIS Crypto 內建的名稱都是經過微軟官方規範驗證過的。
Best Practices 模板： 它的「Best Practices」按鈕是根據當時主流的安全標準（如 PCI DSS、TLS 指引）定義的，能快速關閉已知的弱點（如 SSL 3.0, RC4, 3DES）。
數位簽章： 該軟體由 Nartac Software 提供，官方下載的版本通常帶有正確的數位簽章，確保程式碼未被篡改。

3. 使用它有哪些「風險」？

工具本身是安全的，但「設定的內容」可能會帶來副作用。這並非工具的錯，而是加密政策改變後的必然結果：

遠端桌面 (RDP) 斷線風險： 如果你是在遠端操作，且不小心關閉了所有與客戶端相容的加密套件（例如只開 TLS 1.2，但你的連線端電腦太舊），重啟後你可能會連不進伺服器。
應用程式相容性： 某些舊版的資料庫連接程式（如舊版 SQL Client）或舊型設備（如舊型影印機的 Scan to Folder）可能只支援 TLS 1.0 或 3DES。一旦你用 IIS Crypto 停用它們，這些連線就會中斷。

4. 給你的安全建議

如果你還是擔心，可以採取以下步驟：

官方下載： 務必只從 Nartac Software 官網下載。
先備份註冊表： 在執行任何變更前，先匯出整個 SCHANNEL 註冊表路徑做備份。
先在測試環境執行： 如果你有測試機，先跑一次，確認 RDP 與應用程式服務一切正常。
檢查工具： 如果你在極度嚴苛的環境，可以用 Strings 工具查看它的內部文字，你會發現它真的只是在呼叫註冊表機碼。

總結： 對於要修復 Nessus 掃出的 SWEET32 與 SSL v2/v3 弱點，IIS Crypto 是最安全且最有效率的選擇，比手動一個一個改 Registry 要可靠得多。

2026年4月29日星期三

因為Nessus 弱點掃描，而將Windows關閉停用 SSL 2.0 , SSL 3.0 和 TLS 1.0, 1.1，並強制使用 TLS 1.2處理(regedit處理法)

Windows關閉停用 SSL 2.0 , SSL 3.0 和 TLS 1.0, 1.1，並強制使用 TLS 1.2

有一台windows server 2012 R2 主機，被弱點掃描軟體Nessus，掃出

SSL Version 2 and 3 Protocol Detection "The remote service encrypts traffic using a protocol with known weaknesses." "The remote service accepts connections encrypted using SSL 2.0 and/or

SSL 3.0. These versions of SSL are affected by several cryptographic flaws, including:

- An insecure padding scheme with CBC ciphers.

- Insecure session renegotiation and resumption schemes.

An attacker can exploit these flaws to conduct man-in-the-middle attacks or to decrypt communications between the affected service and clients.

Although SSL/TLS has a secure means for choosing the highest supported version of the protocol (so that these versions will be used only if the client or server support nothing better), many web browsers

implement this in an unsafe way that allows an attacker to downgrade a connection (such as in POODLE). Therefore, it is recommended that these protocols be disabled entirely.

NIST has determined that SSL 3.0 is no longer acceptable for secure communications. As of the date of enforcement found in PCI DSS v3.1, any version of SSL will not meet the PCI SSC's definition of 'strong

cryptography'." "Consult the application's documentation to disable SSL 2.0 and 3.0.

Use TLS 1.2 (with approved cipher suites) or higher instead.

處理方式:

應該關閉 SSL 2.0 與 SSL 3.0，並強制使用 TLS 1.2。

通常弱掃做到這點了，都會順便關掉TLS 1.0和TLS 1.1，避免多花一次工。

這項弱點（主要是為了防範 POODLE 攻擊）在現代安全標準中是非常基礎且必要的修復。SSL 2.0/3.0 早已被證明存在嚴重的加密缺陷，攻擊者可以利用這些漏洞進行中間人攻擊 (MITM) 並解密通訊內容。

由於 Windows Server 2012 R2 的預設設定較舊，通常需要手動調整註冊表或使用工具來符合目前的 Nessus 掃描要求。

1. 修復步驟：停用舊協定並啟用 TLS 1.2

在 Windows Server 2012 R2 中，所有的協定控制都在以下註冊表路徑： HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

A. 停用 SSL 2.0 , SSL 3.0 和 TLS 1.0, 1.1。

你需要針對 SSL 2.0 , SSL 3.0 和 TLS 1.0, 1.1分別建立 Client 與 Server 子機碼，並將其停用：

建立機碼：Protocols\SSL 3.0\Server
在右側建立 DWORD (32-bit) 值：
- Enabled = 0
- DisabledByDefault = 1
對以下種類重複上述動作。

SSL 3.0 client 和 Server
SSL 2.0 client 和 Server
TLS 1.0 client 和 Server
TLS 1.1 client 和 Server

B. 啟用 TLS 1.2

雖然 2012 R2 支援 TLS 1.2，但有時並未預設開啟。請確保以下路徑已正確設定：

建立機碼：Protocols\TLS 1.2\Server
在右側建立 DWORD (32-bit) 值：

Enabled = 1
DisabledByDefault = 0

下圖範例參考為Windows Server 2022:
(Windows Server 2012 不支援TLS 1.3)

重要補充1：.NET Framework 的相容性 (隱藏陷阱)

在 Windows Server 2012 R2 上，即便你關閉了系統層級的 SSL 3.0，有些執行在 .NET Framework (3.5 或 4.x) 上的應用程式可能還是會嘗試使用舊協定。為了確保 .NET 應用程式也使用 TLS 1.2，建議增加以下註冊表項：

路徑 1: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319
路徑 2: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319
新增項目:

SchUseStrongCrypto = 1 (DWORD)
SystemDefaultTlsVersions = 1 (DWORD)

重要補充2：就算是關掉了以下3DES,DES,SSL 2.0,SSL 3.0,TLS 1.0,TLS 1.1的windows 安全通道。僅留下TLS 1.2可通。但弱掃，還是有找出這些弱點的結果。

原因是這些主機的AP用的不是走windows的安全通道。因為早期發展SSL/TLS不是很成熟，各廠商通常自幹或幾乎各玩各的。早期 Schannel 的問題很多，Windows 很晚才成熟。

更重要的是：企業開始受不了「每套軟體自己管 TLS」。

時代	狀況
2003 / 2008	幾乎各玩各的
2012 / 2012 R2	過渡期
2016	開始大量整合 Schannel
2019 / 2022	已經很普遍

資安稽核也開始逼廠商

尤其：

PCI-DSS

HIPAA

ISO 27001

金融監管

開始要求：

TLS policy centralized

OS-level hardening

統一 Cipher Policy

於是：

廠商開始發現：

「跟著 OS TLS Policy 走，比較不會被客戶罵。」

這是人類文明少數因為懶惰而進步的例子。

重要補充3：若因為弱掃還是被找出弱點?

可以查看弱掃結果看port number是多少，是什麼程式在用的。

舉例 port 6701 , 9999

PowerShell

netstat -ano | findstr :9999

你會看到：


TCP    0.0.0.0:9999    LISTENING    1234

最後那個 PID：
tasklist /FI "PID eq 1234"

找出到底是哪個程式在運作。

參考下圖:

Windows停用 3DES 與 DES 相關套件

Windows停用 3DES 與 DES 相關套件

有一台windows server 2022主機，被弱點掃描軟體Nessus，掃出SSL Medium Strength Cipher Suites Supported (SWEET32)，Reconfigure the affected application if possible to avoid use of medium strength ciphers.

SWEET32 (CVE-2016-2183) 弱點主要是針對 64 位元區塊加密演算法 (64-bit block ciphers) 的攻擊，而 3DES 與 DES 正是這類受影響的加密套件。

在 Windows Server 2022 中，要徹底修復這項弱點，核心動作就是停用 3DES 加密。

處理方式:

1. 核心修復動作：修改 Registry 註冊表

這是最直接且標準的做法，透過修改 Schannel（Windows 的安全通道）設定來停用 3DES。

開啟 Registry Editor (regedit)。

導覽至以下路徑：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers

在 Ciphers 下方建立一個名為 Triple DES 168的子機碼（如果不存在）。

在 Triple DES 168 下，建立兩個 DWORD (32-bit) 值：

Enabled：數值資料設為 0

DisabledByDefault：數值資料設為 1

針對 DES（如果存在），也在 Ciphers 下建立名為 DES 56/56 的子機碼，並重複上述步驟。

提醒： 修改完成後，務必重新啟動伺服器，這項變更才會真正被載入系統記憶體中。

這樣處理後，Nessus 的 Medium Strength Cipher (SWEET32) 警示就會消失。

注意: Gemini 提供錯誤的答案，regedit在 Ciphers 下方建立一個名為 Triple DES 168/168 的子機碼，多了/168。要注意喔，應該是 Triple DES 168

2026年4月22日星期三

使用Commvault備份時，遇到VMware 磁碟整併鎖定問題排除

使用Commvault備份時，遇到VMware 磁碟整併鎖定問題排除:

我使用Commvault備份軟體，透過VMware Vcenter去備份ESX Server內的VM。

但備份時會產生快照，但備份已經跑完了，快照還在，VMware Vcenter提示訊息說虛擬機器磁碟需要整併。

但我執行整併，發現虛擬機器磁碟整併失敗，Vcenter提示訊息說無法存取遭到鎖定的檔案。

===========

這種情況在備份環境中（特別是使用 Commvault 或 Veeam 等軟體）非常常見，通常是因為 HotAdd 傳輸模式 造成的。

當 Commvault 的 VSA (Virtual Server Agent) 透過 HotAdd 模式備份時，它會將受保護 VM 的磁碟「掛載」到 VSA Proxy 機器上。如果備份過程中斷或解除掛載失敗，磁碟鎖（Lock）就會殘留在 VSA 上，導致 vCenter 無法執行磁碟整併。

以下是處理此問題的標準 SOP：

第一步：找出「鎖定者」（檢查 Commvault VSA Proxy）

這是最常見的原因。請檢查負責該備份作業的 Commvault VSA (Proxy) 虛擬機。

在 vCenter 中，找到該備份作業使用的 VSA 虛擬機。
右鍵點擊 VSA 虛擬機 -> 編輯設定 (Edit Settings)。
檢查硬體清單中，是否有多出來的硬碟（通常硬碟容量或名稱會與出問題的 VM 一致）。
解決方法： 如果發現不屬於 VSA 本身的硬碟，請點擊 「移除 (Remove)」。
- 注意： 務必選擇 「從虛擬機器移除 (Remove from virtual machine)」，千萬不要勾選「從資料存放區刪除檔案」。
移除後，回到出問題的 VM 再次執行「整併 (Consolidate)」。

訂閱：文章 (Atom)

2026年6月4日 星期四