Windows Server因為Windows update後，導致自動重啟或是自動重新開機

從 Windows Server 2016 開始，微軟確實改變了更新機制，使其行為更接近消費端的 Windows 10，這在伺服器管理上引發了不少討論。

以下為您確認微軟在 Windows Server 2016 上的具體行為：

1. 預設行為：自動下載與安裝

在 Windows Server 2016 中，系統預設會自動檢查、下載並安裝更新。與舊版（如 2012 R2 或 2008）不同，2016 的圖形介面（GUI）設定中，提供給管理員選擇「僅通知但不下載」的選項被大幅簡化或隱藏，導致系統看起來像是「強迫更新」。

2. 自動重啟的邏輯

微軟設計了 「使用時段」(Active Hours) 的概念：

預設行為：系統會在偵測到非使用時段時，自動重新啟動以完成更新安裝。

強制性：如果更新被標記為重要安全更新，且系統多次嘗試在非使用時段重啟未果，它最終可能會忽略使用時段強制重啟。

無人值守：對於伺服器而言，如果沒有透過群組原則（GPO）特別設定，系統會認為只要不在使用時段內，重啟就是安全的。

如何在企業環境中重新取得控制權？

身為系統管理員，通常不希望伺服器「自行決定」何時重啟。您可以透過以下幾種專業方式來調整此行為：

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

在 Windows Server 2016 中，若要「安裝更新但完全不重啟」，或是「完全由人工決定何時安裝與重啟」，可以透過以下幾種層次的操作來實現：

1. 最徹底的方法：將更新改為「手動模式」(透過 sconfig)

這是最簡單且最有效的方法，能防止系統在背景自行下載與安裝，進而避免後續引發的自動重啟。

在 PowerShell 或 CMD 輸入 sconfig。

輸入 5 (更新設定)。

輸入 M (手動/Manual)。

效果：系統不會自動檢查更新，也不會自動下載。你必須手動執行 Windows Update 檢查並點擊安裝，重啟的時間也完全由你控制。

如圖Windows Server 2022 Standard範例

2. 專業管理員的做法：透過群組原則 (GPO)

如果你希望系統「可以自動下載」，但「絕對不能自動重啟」，請修改以下原則：

路徑：電腦設定 > 系統管理範本 > Windows 元件 > Windows Update

設定 A：設定自動更新

設定為 「3 - 自動下載並通知安裝」。

效果：系統下載完檔案後會停住，等待管理員點擊「安裝」。只要不點安裝，就不會進入重啟階段。

設定 B：對於已登入的使用者，不隨自動更新安裝而自動重新啟動

設定為 「已啟用」。

效果：只要伺服器上有管理員帳號正在登入狀態（即使是 RDP 斷線後保留 session），系統就不會強制倒數重啟。

3. 進階密技：停用「更新協調器」排程 (Update Orchestrator)

有時候即便設定了 GPO，Windows Server 2016 還是會因為內建的「排程工作」強制重啟。這是最讓管理員頭痛的地方。

開啟 「工作排程器」。

導航至：微軟 (Microsoft) > Windows > UpdateOrchestrator。

找到名為 「Reboot」 的項目。

將其改為 「停用 (Disabled)」。

註：有時系統會自動恢復此項目的權限。若要徹底封鎖，需要進到檔案路徑 C:\Windows\System32\Tasks\Microsoft\Windows\UpdateOrchestrator 將 Reboot 檔案的寫入權限移除。

使用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)，操作非常直覺。

使用圖形介面安裝服務：

1. 下載並解壓縮 NSSM。

2. 打開命令提示字元 (CMD) 並切換到 nssm 所在目錄，輸入：

   nssm install 你的服務名稱
   

3. 此時會跳出一個 GUI 視窗：

   • Path: 選擇你要執行的 .exe 或直譯器（如 python.exe）。

   • Startup directory: 程式運行的工作目錄（通常會自動帶入）。

   • Arguments: 程式需要的參數（例如 runserver 0.0.0.0:8000 或腳本路徑）。

   • 在 I/O 頁籤可以設定 Log 輸出路徑。

4. 點擊 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. 完成與啟動服務

1. 欄位填妥後，點擊視窗下方的 Install service 按鈕。

2. 看到彈出 Service "nginx" installed successfully! 的成功訊息後，代表服務已經註冊成功。

3. 啟動 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

https://drive.proton.me/urls/MV7M5ARMRG#GN6n4oWZavDG

WINDOWS SERVER 2019-2022無法啟用處理。

WINDOWS SERVER 2022無法啟用處理:

廠商安裝他們自己的軟體時，有時OS會呈現一種狀態，就是還沒跟微軟買好，或是公司採購流程，因故沒跑完，所以沒有得到啟用金鑰，直接先裝好OS，在試用期的狀態下，先把他們的軟體先裝好，並測試好。也就是呈現還沒有啟用好的狀態下，使用這個OS，並且最後加入公司AD網域。

當測試某軟體的Service後，Windows Server OS，也已經超過試用期，甚至後來買到取的合法金鑰，也發生無法啟用的情形。值得注意的事，發現當join ad domain時，是無法啟用的，我需要刻意，離開網域，再啟用，就可以成功啟用。

(這個試用期我不是很確定，有人說30天，也有人說180天)。

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

以下待測試，還沒測到，問題就解決了。暫時留此備用。

WINDOWS SERVER 評估版本該如何轉換為正式版

發表日期 2022-07-18 在 16:20:59 by futako

若您購買SERVER授權之後, 無法直接在評估版(Evaluation/試用版)直接輸入金鑰啟用，請參考以下說明再進行啟用

您可以將 Windows Server 的評估版轉換為零售版。 如果您已安裝 Standard edition 的評估版，您可以將它轉換成 Standard edition 或 Datacenter edition 的零售版本。但如果您已安裝Datacenter 版本的評估版，您只能將它轉換成 Datacenter edition 的零售版本

Windows Server 2019/2022 評估版本該如何轉換為正式版

解決方案：

以下說明以Windows Server Standard示範

在機器以本地管理員執行 CMD，輸入以下指令：

dism /online /set-edition:ServerStandard /productkey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX /accepteula

不需要更改，直接抄入CMD中執行

** XXXXX-XXXXX-XXXXX-XXXXX-XXXXX 更改成正式版之金鑰

 

等執行完了，重啓機器。

重啓完，再以機器以本地管理員執行 CMD，輸入

slmgr /upk

slmgr /ipk 金鑰

** 將 金鑰 更改爲授權網站提供的25位數金鑰

微軟授權方式

微軟授權方式

01.甚麼是大量授權服務中心？

大量授權服務中心 (Volume Licensing Service Center) 是唯一可供 Microsoft 大量授權客戶檢視其授權資訊的位置。 關於產品如何使用、能使用多長時間，以及客戶想要如何將產品部署至商業環境，與 Microsoft 所簽的授權合約中皆有指定。例如，授權合約或權利中可詳細規定單一軟體產品，其中並附帶多重啟用的租用合約。此外，客戶可以購買服務合約 (例如，軟體保證)，該合約可提供與 Microsoft 間建立授權關係之下可享受的權益，例如：免費產品升級，及固定數量的服務票證。

從 2023 年 4 月開始，大量授權服務中心 (VLSC) 客戶將會被重新導向至 Microsoft 365 系統管理中心

https://login.microsoftonline.com

02.大量授權可以安裝在幾台電腦上？

實際裝機數量需視您的購買數量而定，假設以大量授權購買 10 套軟體，就可一次裝在 10 台電腦上。

Open 大量授權方案的採購門檻很低，企業只要單次採購五套 (含) 以上的微軟軟體 (除了 MSDN、SBS 或以 per Core 方式來採購的 Server 產品只要一套 (含) 以上)，就可適用 Open 授權方案進行採購，以取得更優惠的採購價格。

以下是符合 Open 合約的各類產品採購門檻：

1.五套 (含) 以上：作業系統 (包含 Windows 10 升級版)、應用程式 (Office、Project 等等)、伺服器產品、Server CAL。

2.一套 (含) 以上：MSDN、SBS 或以 per CPU 方式來採購的 Server 產品。

若採購數量超過 250 套，可以透過 MPSA 大量授權方案以取得更優惠的價格。

03.新電腦是否可以購買大量授權的軟體？

若是 Windows 軟體，新機必須有 OEM 或 FPP Windows 專業版授權，才能透過大量授權方案採購 upgrade 版本。其他軟體均可以購買大量授權版本。

04.大量授權產品可否降級？降級媒介取得方式為何？

可以降級，從 VLSC 授權網站下載軟體。

05.在使用大量授權服務中心時遇到問題，可以去哪裡尋求協助？

大量授權服務中心的「常見問答集」(FAQ)。

https://learn.microsoft.com/zh-tw/licensing/vlsc-faqs-home-page

06.我所購買的產品不需要啟動流程，因此也不會有 Product Key？

不需要啟動的產品，分為 － 需要 Product Key 及不需要 Product Key 兩種。

需要 Product Key 產品 - 在安裝光碟的正面會註明需要 Product Key，同時 Product Key 也會附在安裝光碟封套的背面。

不需要 Product Key 產品 - 在安裝光碟上就會註明不需要 Product Key。

07.企業採購新電腦時，應該透過何種授權方式採購完整版本的作業系統？

微軟完整版本作業系統，只能透過隨機版本 (OEM/COEM) 及彩盒包裝 (FPP) 提供，大量授權方案 (Open, Open Value, Select, Enterprise Agreement, 等) 僅提供作業系統升級授權，並沒有提供完整版本作業系統授權。

08.我什麼時候會收到產品的 VLK？之後又可以在哪裡查詢到 VLK 資訊呢？

客戶也可以隨時透過「微軟大量授權服務網站(Volume License Service Center; VLSC)」，查詢大量授權合約的 VLK。 另外，MPSA 客戶是透過「Business Center」查詢MPSA合約的VLK。

09.是不是每種透過微軟大量授權方案所取得的產品，都需要 VLK 來加以啟動？

只有需要啟動的產品，才需要 VLK。在大量授權中，共有三種產品是需要 VLK 的，分別是：Windows、Office 及 Windows Server。新版的 Office 2007 也使用 VLK。但 Windows 10 跟 Office 2016，則是改採用了第二代的大量授權技術 Volume Activation 2.0 (VA 2.0)，包含有 MAK 及 KMS 兩種金鑰。

10.同一項產品但語言版本、專業或標準版不同，就會需要對應不同的 VLK 嗎？

基本上，VLK 是不分語言版本，同時也不分專業版或標準版的。想要查詢各產品對應的 VLK，可以參考此處。

11.如果企業已經預想到舊機汰換後，需要轉移所購買的微軟軟體到別台電腦上，那應該選擇哪一種授權方式？

企業可以採購彩盒包裝零售版或透過大量授權方案採購的軟體保證，皆是允許進行轉移的。

12.WINDOWS SERVER 的授權方式有何改變？

自Windows Server 2016 起 Datacenter版本和 Standard版本的授權方式已從處理器授權改成實體核心授權（與私有及公用雲環境的授權方式相同），提供一致的授權單位，並簡化多雲端基礎架構的授權管理。當伺服器上的所有實體核心皆已取得授權時，Datacenter 版本可提供執行無限個 OSE 和無限個 Windows Server 容器的權利，當伺服器上的所有實體核心皆已取得授權時，Standard 版本可提供執行兩個 OSE 或兩個 Hyper-V 容器和無限個 Windows Server 容器的權利。

Windows Server 授權模式如下：

• 每一個實體伺服器都必須具備所有實體核心的授權
• 每一個實體處理器都必須具備至少 8 個實體核心的授權
• 每一個實體伺服器都必須具備至少兩個處理器的授權，總計至少有 16 個實體核心
• 核心授權是以兩個一組的方式銷售（即雙核心授權）

13. 如何下載VLSC授權網站的安裝程式及金鑰

有關下載安裝程式及金鑰影片 (英文說明) ,

https://www.microsoft.com/en-us/videoplayer/embed/43fc3a30-154d-413e-929d-427839c4e65a

從 2023 年 4 月開始，大量授權服務中心 (VLSC) 客戶將會被重新導向至 Microsoft 365 系統管理中心

14.Windows server 2021 授權說明

1. 授權由【實體CPU】授權方式改為【核心(core)授權】

2. 一顆實體CPU至少算8核心(core)

3. —台伺服器至少要採購16核心(core)

4. 為伺服器購足所有Windows server 2019 Datacenter版實體核心數後,可安裝無上限個VM。

5. 為伺服器購足所有Windows server 2019標準版實體核心數後，最多僅可安裝2個VM。

6. Windows server 2019標準版與Datacenter版功能不完全相同

VM授權說明:

1. 舉例:4顆實體CPU (每顆6核心)，買足了 4 X 8 =32核心Windows server 2019標準版的授權後‘只能使用2個VM,客戶若欲使用第3個VM，需再加購32核心Windows server 2019標準版的授權

2. 如果伺服器中的所有實體核心都已取得授權，Standard版提供的使用權最多可用於2個OSE或Hyper-V Container.在所有的實體核心皆具備標準版授權的情況下，可擁有兩個OSE的使用權利，若要再増加兩個OSE使用權利，則必須針對所有的核心額外購買授權'。

3. 無法在同一台實體伺服器上混用Windows Server 2019及Windows Server 2016授權,或更低版本。

[AD]找出事件紀錄-從中找AD帳號鎖定問題

針對帳號鎖定進行問題分析如下: 

特別是 4740

備註：若要搜尋與帳號鎖定相關的事件記錄，以下是 Windows Server 2003 與 Windows Server 2008 的相關事件編號與相關描述。

Event ID (Win2k3)	Event ID (Win2k8)	描述
0	4720	用戶帳戶已建立。
-	4723	嘗試更改帳戶密碼。
644	4740	已自動鎖定使用者帳戶。
	4767	解除鎖定使用者帳戶。
	4624	登入成功。
529	4625	登入失敗。嘗試以不明的使用者名稱，或已知使用者名稱與錯誤密碼登入。
675	4771	預先驗證失敗。此事件是在使用者鍵入不正確的密碼時，於金鑰發佈中心(KDC)上所產生。
676	4772	驗證票證要求失敗。在 Windows XP 或 Windows Server 2003 系列中不會產生此事件。
681	4777	登入失敗。嘗試網域帳號登入。在 Windows XP 或 Windows Server 2003 系列中不會產生此事件。
-	5025	Windows 防火牆服務已停止。

例如:

事件 4720 S：已創建用戶帳戶。

事件 4722 S：已啟用用戶帳戶。

事件 4723 S、F：已嘗試更改帳戶密碼。

事件 4724 S、F：已嘗試重置帳戶密碼。

事件 4725 S：已禁用用戶帳戶。

事件 4726 S：已刪除用戶帳戶。

事件 4738 S：已更改用戶帳戶。

事件 4740 S：用戶帳戶被鎖定。

事件 4765 S：SID 歷史記錄已添加到帳戶。

事件 4766 F：嘗試將 SID 歷史添加到帳戶失敗。

事件 4767 S：已解鎖用戶帳戶。

 相關資料參考:

https://www.lepide.com/freetools/account-lockout-examiner.html

https://www.lepide.com/how-to/identify-the-source-of-account-lockouts-in-active-directory.html

 https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/security-auditing-overview

https://learn.microsoft.com/zh-tw/windows/security/threat-protection/auditing/security-auditing-overview

修改遠端桌面的PORT

執行-->regedit

找到下面的位置

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp\PortNumber

改成10進位的方式

打上你要的PORT號碼

最後重新開機。

管理 Windows Server 檔案伺服器中已開啟的檔案和資料夾

管理 Windows Server 檔案伺服器中已開啟的檔案和資料夾
1. 使用 "系統管理工具 > 共用與存放管理" 的 “管理開啟的檔案”
在 Windows Server 2008 R2 要管理檔案伺服器中已經開啟的檔案和資料夾，可以使用 "系統管理工具 > 共用與存放管理" 的 “管理開啟的檔案” 功能。


Windows Server 2012 R2，"共用與存放管理" 被擺放到了 "遠端伺服器管理工具" 項目下 ("新增角色及功能精靈" 的： 功能 > 遠端伺服器管理工具 > 角色管理工具 > 檔案服務工具 > 共用與存放管理工具)；代表 "共用與存放管理" 只能夠被用在 "遠端伺服器管理" 工作上，而無法提供本機 (Windows Server 2012 R2) 的 "共用與存放管理"。


執行 Windows Server 2012 R2 的 "共用與存放管理"，出現該工具只能夠在 Windows 2008 或 2008 R2 中使用 (難怪放到遠端伺服器管理工具了)，2012 以後的請使用伺服器管理員的提示。)


而 Windows 2012 R2 的 "伺服器管理員 > 檔案和存放服務 > 共用" 也沒有提供 “管理開啟的檔案” 的相關功能。

2. 使用 Microsoft 管理主控台的 "共用資料夾" (FSMGMT.MSC)

Microsoft 管理主控台的 "共用資料夾" 也提供了管理開啟檔案的功能。執行 "FSMGMT.MSC" (在命令提示字元或是 Windows圖示 + R)，開啟 "共用資料夾" 管理主控台，可以較快地 (跟上述的 "共用與存放管理" 相比) 管理已經開啟的共用檔案，是最方便的圖形化共用資料夾管理工具。

在微軟的 TechNet，有人建議應該要使用  FSMGMT.MSC 來替代 "共用與存放管理"，因為 FSMGMT.MSC 是一個較快速且具有時間彈性選擇 (A faster and more time resilient alternative)：
https://technet.microsoft.com/en-us/library/cc725689(v=ws.11).aspx