Windows Server 2025 - Upgrading hell!

whitehondo · 2025-01-17T09:33:07.595Z

Well brand new domain when I connect it to domain same
Issue……

Rod-IT · 2025-01-17T11:49:32.303Z

WhiteHondo:

Well brand new domain when I connect it to domain same
Issue……

What do you mean brand new domain and same issue?

I will ask again so we can better assist you. What is the DNS of the DC?

Rod-IT · 2025-01-17T11:57:19.488Z

WhiteHondo:

Microsoft should not allow it then shouldn’t they

Blaming someone else for your actions is an easy way out.

Just because you can do something, doesn’t mean you should. In the IT field, it’s always advisable to keep abreast of things, especially upgrade and migration paths. At a minimum, check or seek guidance before doing something, especially if it’s not your own environment.

You can upgrade a 2012 server to 2022, but this is also advised against, upgrades are n+2, meaning from where you are, to the next and the one beyond that.

2012 - 2016 and 2019.

Respectfully, your profile doesn’t give us much to work with, we don’t know if you have been in IT 5 years or 40, nor where your skills lie, so if we’re asking questions you either know or think you know, we do so as we don’t know you or your skills.

We can only assist you based on details, not assumption.

While you may not see it as so, we are actually trying to assist you here.

whitehondo · 2025-01-17T13:09:17.808Z

It’s pointing to itself as the DNS but it’s get access denied, I assume because of the Kerberos corruption maybe… running reg query HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters looks fine, replsummery shows error 8341 on repadmin and is concerning - it’s a common error when there’s a broken RPC connection, often caused by authentication issues (which makes sense)… I’m hesitate to boot into DSRM and run kdb5_util destroy
kdb5_util create -s….
So I tried: repadmin /options servername +DISABLE_OUTBOUND_REP and i get repadmin can’t connect to a “home server”

LDAP Error 81(0x51)

Looking like it’s going to have to be a server 2022 rebuild…… any suggestions would be great…

chris-kelly · 2025-01-17T13:25:36.495Z

WhiteHondo:

It’s pointing to itself as the DNS

As Rod has already alluded to, this is incorrect. DCs should point at OTHER DCs, and only point to themselves as a secondary/tertiary.

Rod-IT · 2025-01-17T13:44:08.843Z

WhiteHondo:

It’s pointing to itself as the DNS

How do you except a DC pointing to itself to replicate with other DCs when it’s using itself as the DNS source.

You need to point this to another DC first, then 127.0.0.1 as the secondary - perhaps you will understand why I asked.

Also with respect, please stop going off on a tangent, if you want help, we’re here, but stopping services and changing registry values is going to make helping so much harder as we’re not privy to things you’re doing.

Start by setting the DNS to another DC first and wait 15 minutes.

Active Directory DNS Refresher - Windows - Spiceworks Community

adrian_ych · 2025-01-17T16:27:10.975Z

If you suspect that DNS is the main reason for replication issues…

must set DNS rights to be edited by Domain Admins (if there are access issues)
may want to disable Windows firewall for both DC, at least for now (just in case)
Need to set such that primary DNS server IP is other DC, 2nd DNS server IP is 3rd (if you have 3 DCs) or 127.0.0.1 (if only 2 DCs)
have static records of DCs in all the DCs’ DNS server (else run “IPconfig /registerDNS” on all DCs), wait 15-30 min
Wait 24hrs to 72hrs for replication to propogate if all or any of the above was done.

dashbarron · 2025-01-22T20:01:50.266Z

Back when we had Server 2003 we had to upgrade to 2012. It was technically possible according to M$, but was suggested it wasn’t a great idea.

Lo and behold everything that could go wrong, did go wrong. Even tried to upgrade to 2008 as a stop gap first.

Lesson learned: just install fresh.

This process started Saturday night so it could be done Monday morning. Of course it didnt’ work. And if I had planned to do the fresh install it would of have been quicker and a lot, lot less stressful.

whitehondo · 2025-01-24T08:06:22.850Z

Continue of the pain… So I was unable to run my old scripts, connecting via LDAPS would give ‘Server down or unavailable’ LDAP would give “Strong Authentication required”… so here was the fix:

Domain Controller Policy
===Computer Configuration
======Policies
=========Windows Settings
============Security Settings
===============Local Policies
==================Security Options
=====================Domain controller: LDAP server channel binding token requirements: “When Supported”
=====================Domain controller: LDAP server signing requirements: “None”
=====================Domain controller: LDAP server Enforce signing requirements: “Disabled”
=====================Network security: LDAP client encryption requirements: “Negotiate Sealing”
=====================Network security: LDAP client signing requirements: “Negotiate Signing”
Source: LDAP Authentication with Active Directory Windows Server 2025, bind fails | Netgate Forum

However, the issue still remains- Turing on the KDC service prevents anyone signing into the server…. Still trying to fix that one. Replication is giving 8341 for some domains but other tests like the connectivity test are passing and replsummary looks fine… very confusing…

danielogorman4265 · 2025-01-24T09:49:23.763Z

Silly question, if you have other DC’s why dont you just stand up a new one at that site and then just kill the broken one and do a manual cleanup in AD, Role Sizures if required etc…
Even if you could get the busted one back on its feet im not sure I would trust it now long term

SamGates1 · 2025-01-24T10:36:19.774Z

Continue of the pain… So I was unable to run my old scripts, connecting via LDAPS would give ‘Server down or unavailable’ LDAP would give “Strong Authentication required”… so here was the fix:

You seem to be somewhat casting around in all sorts of apparently unconnected directions. Either that or I’m missing something. Has the DNS for the servers now been set to the format recommended by Rod and a number of others here (now multiple times)?

Replication is your primary problem.
This is very often DNS.
Your DNS is or was configured incorrectly
Until rectified, no other issues you’re casting around at matter, as they might all come back to your primary problem

dougduncan51 · 2025-01-24T14:59:18.158Z

I ran into what sounds like the same issue but on clients. Two Win 11 23h2 machines. They automatically upgraded to 24h2. These machines are in a domain running on a windows 2016 server. Both exhibited issues with NLA. I could log on with a local account but not through the domain. I reported the problem to Microsoft and rolled them back to 23h2. Locked them down so they don’t try it again without my knowing.
I’ll wait for Microsoft to announce a fix. By the way, the machines are in a test lab.

Rod-IT · 2025-01-25T23:37:08.085Z

WhiteHondo:

Continue of the pain…

Unfortunately, your pain is going to continue, regardless of how much effort you put in to this and how many things you fix, different issues will pop-up when you least expect them and likely with more damaging consequences. AD and DNS are the lifeblood of your infrastructure and it’s currently wounded.

This is now a game of whack-a-mole and you likely wont win without some help - get someone in to assist you, someone physical who knows more about AD and DNS than yourself.

The number of changes you’re making, with some being unrelated is likely to be further damaging and maybe not immediate in it’s appearance.

I think you’ve realized a mistake has been made here and you’re desperately trying to resolve it, which I commend. However, flailing around like a fish out of water and not acknowledging the advice you’re being given has lost my interest.

I hope at least, you’re making notes on what you’ve changed, so when someone is able to assist you, you can give them an accurate report on what else has happened.

jimwillsher7467 · 2025-01-26T17:09:08.130Z

I know I’m replying to a thread that’s a few days old, but here’s my experience.

Domain is 2019 and at the highest level for domain and forest.

Installed a brand new Server 2025 Datacentre VM, activated it, ran Windows Updates, all good.
Joined the domain, all good.
Login to the VM with the Domain Admin account, all good.
Can reboot as many times as you like, and login fine, no issues.

Added the AD DS role and promoted to a DC.
Reboot
Cannot login, I am told the username and password (same domain admin account) is incorrect.

I’ve not just spun up a brand new 2019 Datacentre VM and gone though all the hoops. Promoted to a DC. Rebooted. NO PROBLEMS whatsoever.

So…I can add a 2019 DC into a 2019 domain and have no issues, but if I do it with a 2025 DC I can’t then login at all.

Have I missed or overlooked something?

Jim

Rod-IT · 2025-01-26T17:39:09.882Z

Jim Willsher:

So…I can add a 2019 DC into a 2019 domain and have no issues, but if I do it with a 2025 DC I can’t then login at all.

Since your topic is not related to an in-place upgrade it might be worth creating your own topic.

But, are you saying you can’t login to the 2025 server or the domain at all?

jimwillsher7467 · 2025-01-26T17:44:07.483Z

Good point, I’ll create a topic. But yes, exactly that. Domain Admin credentials are recognised nicely by the 2025 VM right up until the point I promote and reboot.

Rod-IT · 2025-01-26T18:07:35.132Z

See if the workaround posted here helps either of you.

Server 2025 Domain Controllers - Trust relationship issues on - Microsoft Community

whitehondo · 2025-01-31T10:19:32.394Z

The issue is with Server 2025 and adding to an existing domain. I’ve managed to fix it but it was a stuff around. Firstly it was partly DNS but a whole bunch of other stuff as well:
First had to connect to the server with PSSESSION OR COMPUTER manager → connect to another machine to sign in, then ran net stop KDC.
*Kerberos Key Distribution Center service set it to Manuel.
Then Servers replication was fixed once the DNS was changed to have the PDC as primary for DNS and itself as secondary server,

Purge the system account Kerberos tickets by running klist -li 0x3e7 purge from an elevated command prompt.

Use the Netdom utility to reset the secure channels between these domain controllers and the PDC Emulator operations master role holder. To do so I had to run the following command from the affected domain controllers:

netdom resetpwd /server:server_name /userd:domain_name \administrator /passwordd: administrator_password

Where server_name is the name of the server that is the PDC Emulator operations master role holder.

• Network type has changed from Domain to Public/Guest
• NLA service is set to OFF and Manual…
• Set ‘Network Discovery’ to Active and ‘File Share’ as per your requirements on Domain networks profile.
• use regedit to
o disable Domain Discovery negative cache located at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters
o disable DNS negative cache located at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
o Add AlwaysExpectDomainController DWORD value 1 at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters
Other issues from others • Change NLA service to Delayed start and add dependencies (Netlogon, DNS) to NLA Service if required.
• Run script to reset Network interface for startup and Logon

dnscmd /config domain.lan /aging disable

Installed this update: January 14, 2025—KB5050009 (OS Build 26100.2894)

https://support.microsoft.com/en-us/topic/january-14-2025-kb5050009-os-build-26100-2894-d78f27bc-6405-461f-a525-2d1dc4e45759

Update didn’t fix it so
finally, I reset the krb account with powershell.

$newPassword = ConvertTo-SecureString “NewPassword123!” -AsPlainText -Force

Set-ADAccountPassword -Identity “KRBTGT” -NewPassword $newPassword -Reset

Check it’s been replicated on each domain with

Get-ADUser KRBTGT -Property PasswordLastSet | Select-Object Name, PasswordLastSet

After 10 hours it was fixed.

The second problem was getting refused running scripts, i got errors like the following: Get-ADUser: The server is not operational or “Strong Authentication Required” (0x0008) regardless of ldaps or ldap as the protocol.
The fix for that was this:

From gpedit:
Domain Controller Policy
===Computer Configuration
======Policies
=========Windows Settings
============Security Settings
===============Local Policies
==================Security Options
=====================Domain controller: LDAP server channel binding token requirements: “When Supported”
=====================Domain controller: LDAP server signing requirements: “None”
=====================Domain controller: LDAP server Enforce signing requirements: “Disabled”
=====================Network security: LDAP client encryption requirements: “Negotiate Sealing”
=====================Network security: LDAP client signing requirements: “Negotiate Signing”
Source: LDAP Authentication with Active Directory Windows Server 2025, bind fails | Netgate Forum

Massive pain but this is what was needed to get it working completely.

Another user said they fixed there’s doing the following:

Set the KDC Service to Manual
Make sure that the 2025 Domain Controller (Just promoted) has DNS Zone
_msdcs.YOURDOMAIN (Mine didn’t have that zone - Create Manually all the objects under it (you can google this) start and stop netlogon and DNS Server services - Should rebuild that. and later you can delete the static entries and then reboot and it will rebuild them with TIME STAMP (not static)
Reboot and make sure that your 2025
Backup Domain controller has your PDC IP address as the #1 in the 2025 servers NIC
Cards DNS Settings (not itself or 127.0.0.1)
You may need to build manually the Netlogon and sysvol on the 2025 server under (C:\windows\sysvol) you can google that as well. stop and restart netlogon service should rebuild that
I had to create the Certificates for my primary domain controller under
Certificates | Personal and I didn’t have any
CERTS… I had to build them back (4 of them total)
Next big step is to make sure you go into the PDC and the 2025 Server (users and computers and look up the username krbtgt. The username is disabled but used for the KDC for authentication. This user maybe locked out which will not allow any 2025 server to sign in… Right click on that username and change the password to the one you are using for the Administrator for the domain on both the PDC and the 2025 backup DC. Then reboot. You have to make sure that AD is Syncing with repadmin /replsum - if you have no errors. then set the KDC service back to automatic and reboot and you should be good!!
Source: Couch-North69 - reddit
Reddit - Dive into anything
Special thanks to this post as well: Issues after latest update on Win11 and Server 2025

TechJan · 2025-02-12T13:16:52.350Z

One thing to check that is a known bug on server 2025 when running as a domain controller. Check the firewall profile. It gets set to public often at startup. Only way around is disconnect and connect network card.
A domain controller with a public firewall profile will not work that great…

theitguy107 · 2025-02-12T15:08:50.368Z

Glad you got it resolved, but I honestly would follow @danielogorman4265’s advice and just get rid of that VM and start over with a new one. I would be very uncomfortable with running such a mission critical server in production when I had to jump through so many unconventional hoops to get it working. It doesn’t take long to build a new one, and you may be grateful for taking the time to do so in the future.