Fix Post-Demotion DC Slowdown

After demoting and removing our old Windows domain controller/DNS server (192.168.1.3), file access over our Windows file share has become painfully slow whenever that machine is powered down. A quick netstat -ano | findstr 445 shows repeated SYN_SENT traffic toward 192.168.1.3, confirming the new server is still trying to reach the retired DC on port 445. Here is what I already know: • Staff open files via a standard Windows file share on a server. • The retired IP shows up in both DNS server records and a couple of Group Policy / logon-script items. • The former DC also handled DNS before its demotion. I need a clean-up that removes every lingering reference to 192.168.1.3, updates or recreates any stale DNS records, Group Policy objects, or logon scripts, and verifies that all authentication and file-share traffic is directed exclusively to the new domain controller. Once complete, file-opening speed must remain normal even when the old box is completely off the network. Deliverables 1. Audit report pinpointing every place the legacy DC is still referenced (DNS zones, AD Sites-and-Services, Sysvol scripts, GPOs, DFS namespaces, etc.). 2. Step-by-step remediation (or direct remediation if granted remote access) to eliminate those references. 3. Confirmation tests and screenshots or logs demonstrating that no traffic toward 192.168.1.3 remains and that file shares open at expected speed with the old server offline. 4. A brief checklist of best-practice tasks so we avoid this issue the next time we retire a controller. If PowerShell, ADUC, ADSI Edit, or similar tools are required, please feel free to use them; just document what was done so I can replicate in future.