2025/10/28

commvault Auxiliary Copy輔助複製的工作記錄查詢

commvault 平常備份的記錄，都可以從用戶端電腦裡面去點選。

但Auxiliary Copy輔助複製的工作記錄查詢卻不在裡面，要先去排程策略，找到輔助複製的排程，從排從去查看工作記錄。

2025/10/21

將來銀行連線銀行樂天銀行信貸資訊

將來銀行:

2024年年底申請，100萬，7年，利息3%，開辨費$588，綁約一年。

連線銀行:

2025年下半年申請轉增貸，158萬，10年，利息2.88%，開辨費$1288，綁約一年。

樂天銀行:

2025年下半年申請73萬(無轉增貸選項)，10年，利息2.72%，開辨費$0，綁約二年。

WIN2025DC 開啟其他DC的共用資料夾存取被拒 KDC不支援所要求的加密類型

環境:

DC主機作業系統: win2022 & win2025

網域&樹系功能等級: 2016

異常狀況:

win2025dc剛登入系統後，連線任何dc的共用資料夾都是正常的，但大概半小時後，就無法連線，會跳出存取被拒的視窗，要求重新輸入帳號密碼。而且畫面右下角還會跳出"windows需要您目前的認證"

所有的win2025dc都有這個問題，但win2022dc都沒這個問題。

後來有做一個測試:

1.在dc上執行klist purge，清除所有票證

2.接著執行klist get krbtgt。

沒問題的dc就可以抓到票證，但有問題的dc就會出現KDC不支援所要求的加密類型。

經調查，是administrator密碼很久沒變更，使用的是rc4的加密協定，但win2025dc預設會不支援。

所以就是把domain administrator帳號裡，勾選支援aes 128跟256位元加密類型，然後再重設administrator的密碼，就可以排除這個問題。

2025/10/13

DC作業系統網域功能等級樹系功能等級升級-win2025 dc無法登入

環境:

DC主機作業系統: win2012r2

網域&樹系功能等級: 2003

升級流程:

1. 新增win2022 DC主機，設定5大角色

2. 移除win2012r2 DC主機

3. 網域&樹系功能等級升級到2016

4. 新增win2025 DC主機，出現異常

異常狀況:

不管新增幾台win2025 DC主機，升級成DC角色重開機後，win2025 DC主機遠端桌面或本機無法登入，都會出現帳號密碼有錯，安裝最新的windows更新，使用不同的domain admin帳號登入都一樣無法登入

解決過程:

上網查詢相關解法，可以先在win2022DC主機上，用ps session連到win2025DC主機，把KDC服務關閉，就可以登入win2025DC，但登入後，就算把KDC服務開啟，也是無法正常與其他DC主機同步。

試過ChatGPT提供的很多方法，都無法解決，但在一些文件上有看到重設krbtgt這個系統帳號的密碼，就可以解決問題了，很多人建議去下載一個重設krbtgt密碼的powershell，做重設密碼。

先請微軟連線確認問題，收集完相關log，也是判斷KDC服務的一些加密協定不支援，造成登入失敗，DC同步失敗等問題，因此建議重設krbtgt這個系統帳號的密碼，用ADUC去重設，沒有提供powershell來做重設。

在第一次重設krbtgt密碼後，新建的win2025主機升成DC後，就可正常登入運作了，不用等第二次重設。

但微軟有建議，要在10小時後重設第二次，所有隔天有再重設一次。

Environment

Existing DC Operating System: Windows Server 2012 R2
Domain & Forest Functional Level: Windows Server 2003

Upgrade Procedure

Added a new Windows Server 2022 domain controller and transferred all five FSMO roles to it.
Removed the Windows Server 2012 R2 domain controller.
Upgraded the domain and forest functional levels to Windows Server 2016.
Added a new Windows Server 2025 domain controller — issue occurred.

Issue Description

After promoting any Windows Server 2025 machine to a domain controller and rebooting, it becomes impossible to log in either locally or via Remote Desktop.
The system reports that the username or password is incorrect.
Installing the latest Windows updates or using different domain administrator accounts does not resolve the problem — all attempts to log in fail.

Troubleshooting Process

Based on online findings, a temporary workaround was discovered:
From the Windows Server 2022 DC, use PowerShell remoting (PSSession) to connect to the affected Windows Server 2025 DC and stop the KDC service.
After stopping the KDC service, login becomes possible.
However, once logged in, re-enabling the KDC service does not restore normal replication or synchronization with other domain controllers.

Multiple potential solutions provided by ChatGPT and other sources were tested but did not resolve the issue.
Several documents mentioned that resetting the “krbtgt” system account password could resolve similar problems. Many users recommended using a PowerShell script to perform the reset.

Microsoft was then engaged for remote troubleshooting. After reviewing the collected logs, Microsoft determined that the issue was caused by unsupported encryption protocols within the KDC service, which led to authentication and replication failures.
Microsoft advised resetting the krbtgt account password using Active Directory Users and Computers (ADUC), rather than via PowerShell.

After performing the first krbtgt password reset, newly promoted Windows Server 2025 DCs were able to log in and operate normally.
A second reset was not immediately required for functionality.

However, Microsoft still recommended performing a second krbtgt password reset after 10 hours, which was carried out the following day as advised.

2025/10/01

redhat 備份虛擬機還原開機後出現錯誤 fsck.ext3: memory allocation failed while retrying to read bitmaps for /p1

一台redhat 備份虛擬機，在還原到其他硬體，開機後出現錯誤

fsck.ext3: memory allocation failed while retrying to read bitmaps for /p1

an error occurred during the file system check dropping you to a shell the system will reboot when you leave the shell

這時就先去查/p1是掛在哪個硬碟後，用root密碼登入，執行下列指令

fsck -y /dev/sda1

完成後在執行 reboot，就可以正常進入到系統了。

2025/09/26

netapp 建立iscsi 並掛載到windows

netapp(8.2.3P3 )建立iscsi磁碟步驟(web console操作)，並在windows server掛載:

1 在netapp的Storage -> Volumes ，執行Create，建立過程要選iscsi，並設定容量。

2 在netapp的Configuration-> iSCSI，啟用iscsi服務，要輸入目標節點名稱，會是iqn開頭的值。

3 在Windows 執行iscsi啟動器，輸入netapp的IP進行連線，連線成功，此時會在目標的頁籤看到netapp的節點名稱，如果剛剛在第二步沒找到節點名稱，就是輸入這個。

4 在設定這個頁籤，可以看到Windows 的啟動器名稱，也是iqn開頭的值，但跟netapp的節點名稱不一樣。

5 在netapp的Storage-> LUN，LUN管理裡執行Create一個LUN，這邊會連結到第一步建立的Volumes。

6 在netapp的Storage-> LUN，Initiator Group建立一個Group，建立時，會需要輸入第四步的Windows 的啟動器名稱。

7 在netapp的Storage-> LUN，LUN管理裡剛剛建立的LUN，連結到第六步建立的Initiator Group。

8 回到Windows 執行iscsi啟動器，重新連線，這時後再去磁碟管理中，就會看到多了一個新的磁碟，就是Netapp上iscsi分享出來的空間。

NetApp (8.2.3P3) iSCSI Disk Creation Steps (Web Console) and Mounting on Windows Server

Create a Volume on NetApp
- Go to Storage → Volumes → Create
- Select iSCSI during the creation process and set the desired capacity.
Enable iSCSI Service on NetApp
- Go to Configuration → iSCSI → Enable iSCSI
- Enter the Target Name, which will start with iqn.
Connect from Windows using iSCSI Initiator
- Open the iSCSI Initiator on Windows and enter the NetApp IP to connect.
- Once connected, you will see the NetApp Target Name under the Targets tab.
- If you couldn’t find the Target Name in step 2, enter the one displayed here.
Check Windows Initiator Name
- In the Configuration tab of the iSCSI Initiator, you can see the Windows Initiator Name, which also starts with iqn but is different from the NetApp Target Name.
Create a LUN on NetApp
- Go to Storage → LUNs → Create
- Link the new LUN to the Volume created in step 1.
Create an Initiator Group (igroup) on NetApp
- Go to Storage → LUNs → Initiator Groups → Create
- Enter the Windows Initiator Name from step 4 when creating the igroup.
Map the LUN to the Initiator Group
- In Storage → LUNs, select the newly created LUN and map it to the igroup created in step 6.
Mount the LUN on Windows
- Go back to Windows and reconnect using the iSCSI Initiator.
- Then open Disk Management, and you should see a new disk representing the iSCSI space shared from NetApp.

2025/09/16

WINDOWS11連線WINDOWS2003共用資料夾錯誤碼:0x80004005

原本WINDOWS11連線WINDOWS2003共用資料夾都正常，但突然有一天卻無法連線，錯誤碼:0x80004005 。

利用WINDOWS7, 10, 2008, 2025都可以，非常奇怪。

最後解決方法是把WINDOWS11裡的SMB1.0 用戶端移除後重新安裝一次，就好了。

Originally, Windows 11 could connect to the Windows 2003 shared folder without any issues, but suddenly one day it stopped working, showing error code: 0x80004005.

Strangely, Windows 7, 10, 2008, and 2025 could all connect normally.

The final solution was to remove the SMB 1.0 client feature on Windows 11 and reinstall it, which fixed the problem.

2025/09/08

DNS 有不同主機對應相同IP

網域的DNS主機中，發現有一些電腦已取到其他IP，但DNS上還會保留舊記錄，不會自動清除，其他電腦後來取得該IP時，DNS上就有兩台電腦對應同一個IP。

這就會造成連線電腦時，會連錯電腦。

檢查過DHCP，已經設定成動態更新DNS了，還是不會更新DNS記錄，後來查發現，DNS的設定中，也要把啟用動清除過時的記錄打勾，DNS裡的舊記錄才會被清除。

On the domain DNS server, it was found that some computers had already obtained new IP addresses, but the DNS still kept their old records without automatically clearing them. When another computer later obtained that same IP, the DNS ended up showing two computers mapped to the same IP address.

This caused connection issues, as attempts to connect to one computer could actually connect to the wrong one.

After checking the DHCP settings, it was confirmed that dynamic DNS update was already enabled, but the DNS records were still not being updated. Further investigation revealed that in the DNS settings, the option “Enable scavenging of stale records” must also be checked; only then will outdated DNS records be cleared.