iT邦幫忙

0

WIN SERVER 出現錯誤LOG

  • 分享至 

  • xImage

您好:
近期沒有改到任何設定
只有
目前
FILE SERVER2019 ,11/17 更新 KB5070883
11/18更新 KB890830 惡意軟體移除工具
AD 2012R2 11/18更新 KB890830 惡意軟體移除工具

PC 11.24 裝
2025-11 適用於 x64 系統 Windows 11, version 25H2 的累積更新 (KB5068861) (26200.7171)

但11.27 之後,PC登入網域,
AD SERVER都會出現錯誤LOG,但可以正常登錄
FILE SERVeR 可以存取,但也會出現 錯誤LOG

查gemini,說有可能是 更新的問題
請問前輩們是否有遇過

主旨:
	安全性識別碼:		XX\A01$
	帳戶名稱:		A01$
	帳戶網域:		
	登入識別碼:		0xE9715276

物件:
	物件伺服器:		DS
	物件類型:		group
	物件名稱:		
	控制代碼識別碼:		0x0

操作:
	操作類型:		Object Access
	存取:		控制存取
				
	存取遮罩:		0x100

FILE FERVER

已檢查網路共用物件,查看是否可授與用戶端想要的存取權。
	
主體:
	安全性識別碼:		XX\A09
	帳戶名稱:		A09
	帳戶網域:		XX
	登入識別碼:		0x2102D214

網路資訊:	
	物件類型:		File
	來源位址:		192.168.XX.XX
	來源連接埠:		2668
	
共用資訊:
	共用名稱:		
	共用路徑:		
	相對目標名稱:	099.tmp

存取要求資訊:
	存取遮罩:		0x17019F
	存取:		DELETE
				READ_CONTROL
				WRITE_DAC
				SYNCHRONIZE
				ReadData (或 ListDirectory)
				WriteData (或 AddFile)
				AppendData (或 AddSubdirectory 或 CreatePipeInstance)
				ReadEA
				WriteEA
				ReadAttributes
				WriteAttributes
				
存取檢查結果:
	DELETE:	授與者	D:(A;;0x1301bf;;;WD)
				READ_CONTROL:	授與者	D:(A;;0x1301bf;;;WD)
				WRITE_DAC:	未授與
				SYNCHRONIZE:	授與者	D:(A;;0x1301bf;;;WD)
				ReadData (或 ListDirectory):	授與者	D:(A;;0x1301bf;;;WD)
				WriteData (或 AddFile):	授與者	D:(A;;0x1301bf;;;WD)
				AppendData (或 AddSubdirectory 或 CreatePipeInstance):	授與者	D:(A;;0x1301bf;;;WD)
				ReadEA:	授與者	D:(A;;0x1301bf;;;WD)
				WriteEA:	授與者	D:(A;;0x1301bf;;;WD)
				ReadAttributes:	授與者	D:(A;;0x1301bf;;;WD)
				WriteAttributes:	授與者	D:(A;;0x1301bf;;;WD)
				

謝謝

圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

1 個回答

1
Ray
iT邦大神 1 級 ‧ 2025-11-28 13:48:13

微軟的問題怎麼會去問對手 Google 的 Gemini?
當然是要問自家的 M365 Copilot 才知道內幕啊...
(微軟有很多內部文件是沒有公開, 無法被搜尋的)


Windows 11 25H2 11 月累積更新 KB5068861近期被社群與媒體回報:網路共用/SMB 行為有回歸或搜尋問題,以及安裝時的錯誤;雖然並未阻止網域登入,但可能在連線或驗證過程產生額外的錯誤事件(例如 SMB 或認證子系統的警告/失敗後重試)。

2025 年的安全強化(自 24H2 起)提高 SMB 簽章的預設要求。部分環境若 NAS/檔案伺服器或舊端點未完全支援,就會出現「能用但拋錯」的情況(例如檔案瀏覽器搜尋失效、簽章驗證警告等)

簡單講:

KB5068861 + 近年的 SMB/認證強化,可能讓你的環境在登入與存取時:
「雖然仍成功完成,但多了警告/錯誤事件」。

1.確認 SMB 簽章策略(Client/Server)

於用戶端:開啟 本機安全性原則 → 安全性選項

「Microsoft network client: Digitally sign communications (if server agrees)」
「Microsoft network client: Digitally sign communications (always)」
先將 if server agrees=Enabled、always=Disabled(或依你既有 GPO 設定),避免因為「始終要求」而對舊裝置造成警告。

於檔案伺服器(Server 2019):確認 SMB 簽章需求是否與用戶端一致,並在共用上開啟/關閉簽章以測試事件是否消失。(背景:24H2/25H2 的預設更嚴格)。

2.測試網路共用搜尋/索引

從受影響用戶端,在檔案總管對檔案伺服器分享資料夾做搜尋;若搜尋失效或延遲且伴隨伺服器端 SMB 錯誤事件,暫時視為 KB5068861 的已知回歸。可先以 重建索引 / 使用 UNC 直接列舉作權宜,並評估是否要暫退該更新於少數機器。

3.檢查 AD 登入相關事件

在 **DC(2012 R2)**的事件檢視器:

安全性(Security):留意 Kerberos(4768/4769/4771)、NTLM(4624/4776) 的失敗/重試。
系統(System):Netlogon、LSA、KDC 或 SMBServer 的錯誤/警告。
若有 STATUS_INVALID_SIGNATURE(0xc000a000)、STATUS_LOGON_FAILURE(0xc000006d) 等,通常與 SMB/認證強化的相容性有關。

4.確認網路設定與 NLA 狀態

少數更新後會出現網路檔案/印表共用暫時失效或網路設定轉為 Public,導致登入/探索階段拋事件。可確認 Network Location Awareness(NLA) 服務延遲啟動與相依性(Netlogon/DNS),避免 DC/檔案伺服器在開機初期誤套用錯誤的防火牆設定。

5. 收集用戶端錯誤碼

若用戶端有 Windows Update 安裝錯誤(例如 0x80070306/0x800f081f/0x800f0983),雖然你已安裝成功,但其他端點若失敗也會造成行為不一致。可用 Catalog 或 Media Creation Tool重灌該更新以保持一致性。


如果可以貼上 Log 的 Event ID, Source, Error Code 比較方便收斂方向.

我要發表回答

立即登入回答