AD does not work with new Server version

Your setup and migration steps sound essentially correct—your new Windows Server 2019 (DC2) holds all FSMO roles, and it's handling AD operations while both DCs are online. However, when you disconnect your original Windows Server 2012 R2 DC (DC1), Active Directory "stops working," and commands like netdom query fsmo fail due to unavailable RPC servers. Let's break down what might be happening:

Likely Issues​

1. DNS Configuration​

Even when FSMO roles are moved, every DC and client must use working DNS servers that can resolve domain names and locate services within the domain. If DC2 is not set up as its own primary DNS server and/or DC1 was still being used as a DNS server, removing DC1 will immediately break AD resolution.

• Check that DC2 is running the DNS Server role.
• Ensure DC2 points to itself (127.0.0.1 or its own IP) for primary DNS. If it points to DC1 (which you are disconnecting), this will cause lookups to fail.
• Check the DNS zones—make sure you have AD-integrated zones, and that DC2 holds a writable copy.
• On DC2, run ipconfig /all and see which DNS servers are listed.

2. Global Catalog (GC)​

DC1 may have been the only Global Catalog server, which is required for many AD queries. If DC2 does not have the GC role enabled, many AD functions will break when DC1 is offline.

• Open "Active Directory Sites and Services" → expand your site → Servers → DC2 → NTDS Settings → right-click → Properties. Check "Global Catalog".
• Wait for the change to replicate if you just enabled it.

3. Replication​

If replication between DC1 and DC2 was incomplete, some critical directory partitions may be missing on DC2. Use repadmin /replsummary and repadmin /showrepl to check replication health.

4. DNS Scavenging/Zone Transfers​

If your AD-integrated DNS zones weren't replicating properly to DC2 (especially if you’re using delegation/subzones), you might have a DNS lookup failure when DC1 goes offline.

5. Firewall or Service Issues​

Make sure DC2’s firewall isn’t blocking RPC/LDAP/AD ports, and ensure all relevant AD services are started.

Diagnostics Checklist​

1. Ensure DC2 is listed as a domain controller in "Active Directory Users and Computers" under Domain Controllers.
2. Ensure DC2 is set as a DNS server for itself and for all clients.
3. Confirm DC2 holds all FSMO roles: netdom query fsmo.
4. Check DC2 is also a Global Catalog server.
5. Confirm replication completed: repadmin /replsummary.
6. Test DNS: nslookup _ldap._tcp.dc._msdcs.<yourdomain> should return DC2’s IP if DC1 is offline.
7. Try dcdiag and see if there are failures.

Next Steps​

I recommend:

• Double-check DNS settings and make DC2 its own DNS primary (and secondary, if it's the only DC/DNS left).
• Make sure “Global Catalog” is checked on DC2.
• Ensure all AD-integrated zones are present on DC2.
• Test services by shutting down DC1 only after confirming all above steps.

If you provide exact dcdiag /v, repadmin /showrepl, or DNS screenshots/outputs, I can give more step-by-step fixes.
Let me know what you find, or if you need help with any of the diagnostic commands!

That's frustrating I've seen similar issues when updating server versions. Sometimes it's just a minor compatibility tweak or missing config. Have you checked if any AD-related settings or policies changed in the new version? Hope you get it sorted soon.

Ugh—yeah, that kind of breakafter-update is exactly the sort of thing that sucks the life out of a Friday afternoon. You’re on the right track asking about AD settings/policies — updates sometimes flip defaults (LDAP signing, channel binding, SMB/NTLM behavior, firewall rules, service start types, etc.) or expose schema/replication differences. Below is a short troubleshooting checklist (prioritized), exact commands to run, and what to look for — plus what to upload if you want me to dig in.
Short checklist (priority order)

• Confirm role/roleless state: is this server a Domain Controller (DC) or a member server? Are there replication partners? (Single-DC environments need extra caution.) itself as primary DNS (127.0.0.1 or its own IP). If DNS points to an offline/old DC, AD will “lose itself.”
• Key services: NeC, NTDS must be running and set to Automatic. If they fail to start in normal boot but run in Safe Mode with Networking, suspect driver/service conflicts, firewall or file corruption.
• FSMO / Global Catalog / replication: confirm FSMO owners, that the server is a Global Catalog (if required), and replication health. Schema changes on newer OS versions can break replication with older DCs.

Commands to run (copy/paste from an elevated prompt or PowerShell) and whs DC and FSMO owners:

• netdom query fsmo
  • Expect to see the five FSMO role owners. If this times out or errors RPC server unavailable, DNS or RPC connectivity is failing.
  • AD / forest functional level:
• PowerShell: Get-ADForest | Select-Object DomainMode, Forestmain/forest levels (needed for some roles/products).
  • DC health:
• dcdiag /v /c /d /e > C:\Temp\dcdiag.txt
  • Look for DNS, LDAP, RPC, Netlogon failures.
  • Replication:
• repadmin /replsummary > C:\Temp\replsummary.txt
• repadmin /showrepl * /csv > C:\Temp\showrepl.csv
  • Check for replication errors, last successful times, and specific failing partitions.
  • DNS & SRV records:
• ipconfig /all
• nslookup -type=SRV _ldap._tcp.dc._msdcs.<yourdomain>
• Get-DnsServerZone (PowerShell, if DNS role installed)
  • Ensure AD-integrated zones exist locally and SRV records resolve to the DC.
  • Services & network in Safe Mode (if normal mode fails):
• In Safe Mode with Networking run:
  • Get-Service Netlogon, DNS, KDC, NTDS, W32Time | Select Name, Status, StartType
  • Get-NetIPConfiguration
  • Set-Service Netlogon -StartupType Automatic (and similarly for DNS/KDC/NTDS)
  • ipconfig /registerdns && net stop netlogon && net start netlogon
  • These help identify whether services are disabled or crash starting in normal boot.
  • File-system & image repair (if you suspect corruption):
• sfc /scannow
• DISM /Online /Cleanup-Image /RestoreHealth /Source:wim:X:\Sources\install.wim:1 /LimitAccess
  • Use matching ISO/build for the Source. DISM often fails if the WIM index doesn’t match OS build.

Common AD-related settings/policies that change with server updates (check these)

• LDAP signing / channel binding enforcement — newer servers can hquire signed LDAP; older DCs or apps may fail if unsigned.
• Kerberos/NTLM deprecation or stricter policies (account lockout thresholds, LSA protections).
• Firewall rules — updates can change profiles or re-enable stricter rules blocking RPC/LDAP/DNS ports.
• SMB version changes or SMB signing enforcement — can affect replication if file-replication/DFS is involved.
• Group Policy changes applied during update that disable services, change startup types, or modify network profiles.

What to collect/upload (fastest way for me to help)

• dcdiag output (the full dcdiag.txt suggested above).
• repadmin /replsummary and repadmin /showrepl outputs.
• ipconfig /all and nslookup SRV output.
• Event Viewer exports (Directory Service, DNS Server, System) covering the time you boot into normal mode and see failures.
  If you attach those logs here I’ll review and point to the exact failure lines — and suggest a surgical fix. The patterns above (DNS pointing to an old DC, services not running in normal boot, schema mismatch after newer-OS schema changes) appear frequently in reports and are quick wins to check first.

Quick emergency checks you can do now
1) Boot Safe Mode with Networking -> run ipconfig /all and Get-NetIPConfiguration -> ensure primary DNS is 127.0.0.1 or the server’s IP.
2) In Safe Mode, make Netlogon/DNS/NTDS startup = Automatic and try to Start-Service for each; note any error messages.
3) If you have another DC: check replication and GC; if not, treat this DC as single-poinider restoring from known-good snapshot if repair fails.
If you want, I’ll:

• Walk you through each command and help inteou can upload the dcdiag/repadmin logs and Event Viewer exports and I’ll parse them and give you exact lines to act on.

Tell me:

• Is this server a DC? (yes/no)
• Was ronment before the update or was it a single DC?
• If you can, paste the output of: netdom query fsmo and ipconfig /all (or attach the files) and I’ll take it from there.