PSA: Do NOT use Windows Server 2025 as the schema master before installing Exchange Server SE RTM
Posted by grimson73@reddit | sysadmin | View on Reddit | 141 comments
PSA: Do NOT use Windows Server 2025 as the schema master before installing Exchange Server SE RTM. The Windows Server team is working on a permanent fix for this issue (to be released in the following months). If you are already affected by this issue, contact Microsoft Support (Active Directory team) and they have a process to allow AD replication to work (but it might require manual schema editing).
#WindowsServer2025 #MSExchangeSE #ADSchema
As cross posting is not allowed, I took this from r/exchangeserver
sysneeb@reddit
is this for people who only use on-premise excahnge server? like if use exchange online it shouldnt be a problem right?
techworkreddit3@reddit
Glad we took our exchange servers off prem in 2015
jacksbox@reddit
Both of the customers still running Exchange on prem are going to be frustrated.
ocdtrekkie@reddit
Eh, I have a good laugh every time 365 is having an outage and my little Exchange SE box is doing it's job. Yeah, migration is a pain, but I can't imagine how people take the trade off of paying a lot more for a solution that doesn't work twice as often, just to not have to... reboot it occasionally?
MortadellaKing@reddit
Also the data sovereignty issues if you're outside the US are a bit of a concern these days.
lordjedi@reddit
Not really. MS has the ability to store all of your data in a geographic region if that's what's necessary.
ocdtrekkie@reddit
They can store it in a geographic region but they cannot deny the US government access to it. Microsoft is a US company, and US law basically means the US doesn't care if it's hosted in Europe if they want it and can compel Microsoft to give it to them.
lordjedi@reddit
The US has the 4th amendment. They cannot "compel" a US company to give them data without a warrant. The US is not China.
Which countries consider this a nonstarter? I'm genuinely curious since I work for a multinational that operates under GDPR and uses MS cloud services.
ocdtrekkie@reddit
The US-EU data sharing agreement has been struck as illegal multiple times. The current one is holding for now but is dubiously legal. The fourth amendment is... kinda a joke these days, the US has FISA courts specifically for this kind of request and it has minimal scrutiny.
lordjedi@reddit
Really? Cause Apple is the one that recently withdrew high data protection from the UK:
https://arstechnica.com/tech-policy/2025/10/uk-once-again-demands-backdoor-to-apples-encrypted-cloud-storage/
I'm not doing research on reddit. I'm pointing out that when you make dumbass comments like "A US company can be compelled by the US govt to give up your data" you're obviously full of shit.
I noticed that you didn't mention any countries where using a US company (like either MS or Google) is a non starter.
ocdtrekkie@reddit
This really is a "you don't seem to know the minimum amount necessary to have this conversation", but you should start here: https://www.theregister.com/2025/07/25/microsoft_admits_it_cannot_guarantee/
This particular link is about France, if naming a specific country is important.
lordjedi@reddit
From your link:
"It is said to compel these companies, via warrant or subpoena, to accept the request."
Via warrant or subpoena. That falls right in line with what I said earlier.
ocdtrekkie@reddit
The issue is that the EU does not much like the idea that US law can compel data about EU citizens. And again, as I mentioned, many data requests on foreign citizens are routed through separate, secret courts here called FISA courts, which are mostly a rubber stamp.
It also sounds like you might be unaware the federal government had two comedians fired recently for being critical of the President...
ocdtrekkie@reddit
If you're outside the US, you need to be concerned the US can access it. If you're in the US, you need to be concerned that Microsoft will let Chinese citizens access it. Even for the DoD-specific ultra high security tier, Microsoft picked cheap labor over security.
https://www.propublica.org/article/microsoft-china-defense-department-digital-escorts-investigation-warning
MortadellaKing@reddit
Ever tried to get support for M365 issues? I could rebuild an exchange environment in the time they take to resolve things. If I didn't have an ownership stake in my org, maybe I wouldn't care. But as long as I do, we'll host our own data.
lordjedi@reddit
It's not "a lot more" and it works easily 99% of the time. The times that it does go down are region specific (Exchange Online does not go down worldwide twice as often as your server). Even those outages do not last long.
The difference between those outages and having it on-prem are that email admins aren't having to troubleshoot or jump on the phone with MS support to find out why their server isn't working. They simply wait for email to come back online (which doesn't take very long when it does go down).
ocdtrekkie@reddit
99% of the time is terrible service quality. I agree Exchange Online meets two nines of reliability, that's why I don't use it. My house is more reliable than Exchange Online.
And generally when Exchange on-prem breaks, "troubleshooting" is "reboot it and wait 5 minutes". Exchange Online outages often take hours for Microsoft to troubleshoot and restore, because it's an incredibly complicated globally-distributed system with thousands more potential failure modes.
lordjedi@reddit
According to this they have up to 4 9s of reliability.
https://learn.microsoft.com/en-us/office365/servicedescriptions/office-365-platform-service-description/service-health-and-continuity
The difference between this and you is that if you leave tomorrow, your company has to find a replacement to keep the on-prem going. With Exchange Online, they don't (they'll still need an admin, but the service is mostly maintained on the backend by MS with a 99.99% reliability).
ocdtrekkie@reddit
This isn't really different. Apart from migrations and the very rare "install the Exchange CU installer on the server and click next a bunch", most of my managing Exchange is... managing mailboxes, the same thing I'd have to do on 365. For a simple single-server on-prem installation, the awful burden of managing Exchange is kinda a myth. If you got DAGs and stuff, yeah, much more brutal.
In your other comment you said you work for a multinational... so I assume you would have these. This is a case where Exchange Online might be a reasonable case for you (apart from the data sovereignty topic, see over there), but an incredibly silly case for me. I run a few hundred mailboxes on one VM. When it breaks I reboot it and we are good again. :D
DobermanCavalry@reddit
Never had anyone raise a ticket saying exchange online was down in the last 5 years, so what do i care if its down for 5 minutes at 3am when none of the users are awake?
Also, we moved off exchange on prem the year there were two very actively exploited zero days. No, rebooting was the least of my concerns.
ocdtrekkie@reddit
365 had like two workday outages last week:
https://www.bleepingcomputer.com/news/microsoft/microsoft-365-outage-blocks-access-to-teams-exchange-online/
https://www.bleepingcomputer.com/news/microsoft/azure-outage-blocks-access-to-microsoft-365-services-admin-portals/
Go a week further back, Microsoft broke Exchange Online in a "only support can fix your tenant" way:
https://www.bleepingcomputer.com/news/microsoft/new-bug-in-classic-outlook-can-only-be-fixed-via-microsoft-support/
Here's last month's global Exchange outage:
https://www.bleepingcomputer.com/news/microsoft/microsoft-investigates-exchange-online-outage-in-north-america/
And if security is your concern, I covered that in this other comment, 365 is not reasonably secureable, largely because the breaches come from Microsoft's own practices or service-wide authentication mistakes, all things not even possible in an on-prem environment: https://old.reddit.com/r/sysadmin/comments/1o4t4nv/psa_do_not_use_windows_server_2025_as_the_schema/nj6e8u8/
The above two issues are... honestly catastrophic failures that should lead anyone from a security standpoint to run screaming from 365 as fast as possible, it's incredible they remain a government contractor.
DobermanCavalry@reddit
OK, so they had two outages last week. They could have had fifty outages, but I didnt notice and neither did 250 users. Is it an outage if the only reason I know about it is an article on bleeping computer?
But something tells me this will not be a fruitful conversation with you, so I bid you goodnight.
ocdtrekkie@reddit
Good morning! 365 is having problems again: https://old.reddit.com/r/sysadmin/comments/1o5gtrv/another_m365_outage/
DobermanCavalry@reddit
Sounds good, no impact to my environment
zz9plural@reddit
Yes. Just because it didn't impact you (that you know of), doesn't mean it didn't happen or impact anyone else.
DobermanCavalry@reddit
You know what did impact me? An exchange on prem zero days that gave bad actors complete access to active directory.
binkbankb0nk@reddit
If that was possible in your environment, then you didn't know how to run Exchange. It was that straightforward.
zz9plural@reddit
Same. Did you know that two things can be true at the same time?
systempenguin@reddit
You're being religious.
Bad trait for a sysadmin.
Just because it's right for your organisation, doesn't mean it's right for all of them.
DobermanCavalry@reddit
You must be a fucking genius to gather all of that from two short posts.
systempenguin@reddit
I'm glad you picked up on that.
Usually I have to tell people what a genius I am.
Euler007@reddit
Yeah not having exchange and SharePoint on prem made my life so much easier.
MairusuPawa@reddit
It's like the best publicity for Microsoft cloud products are Microsoft on-prem products.
ratshack@reddit
“Always has been…” bang
Cutoffjeanshortz37@reddit
We did Exchange a couple of years ago, then SharePoint last year. Soooo much easier.
curi0us_carniv0re@reddit
I've slept a lot better since I did the same.
Kardinal@reddit
It's extremely difficult to get exchange servers out of a hybrid environment, and most people still are. It plays some roles in schema for hybrid if memory serves. This this is pretty important.
We have no user mailboxes on prem but we do have exchange for relay and a few on prem integrations.
torbar203@reddit
Basically you can shut down the last exchange server-assuming it's not needed for any on prem integrations or smtp relay, but if you uninstall it that's where the trouble happens because the uninstall process removes some important stuff from AD that will break shit
discosoc@reddit
Are you just not syncing ad>m365 at all?
grimson73@reddit (OP)
As you should :) .. but this isn't specific an Exchange thing. I think its extending the ad schema on a 2025 fsmo DC that create duplicate records. So a (any) schema extension might trigger this issue.
Maybe the next line is: glad we took out dc's off prem in 2026 ;)
Longjumping_Law133@reddit
Trilion dollar company, not a team or 4 20 year old programmers, its trilion dollar company
hutacars@reddit
30% of their code is AI generated, per their own admission. This is what you get.
broknbottle@reddit
This likely is referring to Docs in a raw format like xml or markdown. This is kept in a repo and some framework produces pretty docs. This is likely what they bamboozling the media with when they say 30% of code.
JSON, YAML, markdown, HTML etc are not code but some will lump them in if they are part of a solution or necessary for it to exist
lordjedi@reddit
They've had problems like this before. This is completely unrelated to AI generated code.
That said, they're making massive investments into AI. Should they not eat their own dog food? If their AI is able to generate code, then they should absolutely be using their engine to write code.
pointlessone@reddit
Massive investment doesn't give them an excuse for subjecting the world to AI jank without an alternative.
I don't want the software that I and millions of other businesses depend on to be stable to be written without the standard controls that have been in place for decades.
lordjedi@reddit
You mean code reviews? Are you privvy to MS internal auditing policies?
Just because the code is written by AI does not mean it doesn't go through the same processes as before.
Again, incompatibilities between DCs, Exchange, and every other MS product has been an issue for decades. This isn't new with "AI code".
Savings_Art5944@reddit
it is Intrinsic Overvalued.
Savings_Art5944@reddit
If they dogfooded their own slop then this kind of amateur code would have been found long ago.
gex80@reddit
That would require them to not use Exchange online. Why would they not?
Savings_Art5944@reddit
See above:
If they did then they would have found the issues already.
gex80@reddit
Then how would they find issues with exchange online which arguably makes way more money than a "legacy" product they want to get rid of?
Savings_Art5944@reddit
On-prem/online. Test both scenarios obviously!
Don't they have Exchange Server SE, the current version(2025) of the on-prem exchange server? I'm sure it's supported for a few more years.
gex80@reddit
You don't know what dog fooding is then. Dog fooding is when you actively use your product and are subject to the same outages and issues your users are. Testing is not dog fooding.
Savings_Art5944@reddit
Wait. Do you think all the MS employees just use one(azure) online exchange server and thats it? Not that there could be any remote offices that have their own exchange servers running locally? 🤔
Honestly, IDK. I don't recommend anyone use MS services or software. I'd never go back on-prem exchange either.
lurkeroutthere@reddit
Never be first, never be last and never volunteer
grimson73@reddit (OP)
I just looked it up, but Windows Server 2025 was released on 1 november 2024! That's almost a year. And to be honest this bug is really a scary one, it f*cks with your AD / Replication / Schema. This should not happen.
lurkeroutthere@reddit
No argument there but I typically have not rushed to use the latest iteration for anything core of the domain for at least a couple years in the past but 2025 looked especially underbaked as an is release, with no actual feature improvements I can think of any system admin types actually want.
a_dsmith@reddit
OMG this is how I found out I have my own technet article, yes please for the love of god do not do it. it's an absolute ball ache and I spent WEEKS fixing it
grimson73@reddit (OP)
Care to explain what you did? did you manually fix the AD schema? is it possible?
a_dsmith@reddit
Ofcourse, firstly I would like to state it wasn't Microsoft who identified the workaround it was something I was trying at 2am on the 8th of September that resolved this issue for myself. I then had an hour or so convo with Microsoft and their product teams informing them of what I did.
To set the scene we had 4 AD sites, 2 of the sides had 2 2019 DCs in each and the other two sites were 2 x 2 Win25 DCs. We first noticed that both 2025 DC sites could replicate between one another, while not ideal the estate was essentially in a split-brain style mode, changes could replicate but it it took 30-40 hours (not fun) - so Microsoft said how about we demote and repromote a DC at site C that wasn't taking the contents from site A - we did this and identified it didn't fix our replication but no additional values came back, I then took this approach to our 2025 sites.
I first tried with Server 2022 and identified that this allowed for broken AD code to be replicated and still not let you delete the values HOWEVER when you deploy a 2019 DC into a 2025 site, it will not replicate the duplicate AD values to a newly deployed controller. I was then able to delete the virtual DCs at both 2025 sites - deploy 2019 DCs (had a requirement to keep services like DHCP in HA etc.) I was then able to demote the 2025 physical boxes, repromote them setting a 2019 box I created fresh as the replication point and all DC objects were functional again.
Going in and manually editing the attributes was not possible for us, we tried as well as Microsoft but the values would not save. Below are our filtered case notes if anyone's interested in the premier support / product team case summary
Symptom:
Domain Controller replication fails with the error "The replication operation failed because of a schema mismatch between the servers involved."
Observations:
The customer recently extended the Forest's schema using the Exchange CU 15 setup ( setup.exe /prepareschema) while the Domain Controller holding the schema master role was running Windows Server 2025
Cause:
The issue is due to a code defect in Windows Server 2025, the schema master allows adding a duplicate entry to attributes of Schema objects:
Example: <output of the repadmin /showattr DCName "DN of the address-book-container object"
Resolution:
Microsoft worked with the customer on troubleshooting sessions that allowed to identify the objects and attributes with duplicate values.
Armed with this information the customer transferred the Schema master SMO role to a non-Windows 2025 Domain Controller, demoted the WS2025 Domain Controllers and removed the duplicate entries on exchange schema objects.
AD schema version is at 91 and Exchange schema version is at 17003 across all DCs.
More information:
Microsoft is working internally to address this code defect.
The case will not be charged.
grimson73@reddit (OP)
Ah thanks! .. so you mitigated it by installing a Windows Server 2019 DC into the 2025 site so only correct AD values are replicated, leaving the issue at the 2025 AD servers. Then demoting the 'faulty' Windows 2025 AD servers. After verifying replication then reintroducing Windows 2025 AD controllers.
Nice find! .. bummer that manual doesn't seem to work (as this would be much easier) .. curious what the official fix will be from Microsoft.
Again really thanks for sharing to get an impression of what can be done.
a_dsmith@reddit
Pretty much, when I spoke with Microsoft that morning they mentioned they were doing something slightly different but were still testing something additional to this in the background - sounded much more complex and I didn't personally push it because I had self-resolved and no worries!
grimson73@reddit (OP)
I hope they find a better alternative than installing and demoting domain controllers :). I do not know anyone that got hit but again I'm just very curious about all this.
a_dsmith@reddit
I would like to state, I am not a MSFT employee - I am just a victim of their poor programming so more often than not and I improvise based on legacy knowledge and findings of how their tooling works.
While this solution has been working fine for us since the start of September and there have been no AD replication issues to report back, implementing what worked for me (on your own) should not be done so blindly and should be tested with an isolated DC to ensure you're happy with the results as there is no going back if you lose AD objects or break your attributes.
If you do not want to carry the risk, speak to Microsoft and their AD team will sit with you during implementation.
grimson73@reddit (OP)
Fully understood, it's just very informative what other parties observed, and eventually how they mitigated the situation. Again, thanks for sharing!
Vast_Fish_3601@reddit
Wtf does this even mean.
Ok
Ok
Which CU? Any CU, any version? Because PAD schema changes cause issues?
So move schema master to 2022 DC? Then run exchange update?
So won’t use 2025 as schema master at all?
Maybe have AI write this next time because it would do a better job explaining. Jfc.
a_dsmith@reddit
So I can answer this because I am the reason this article exists - Exchange 19 CU14 then upgrade to CU15 caused everything to go horribly wrong and yes remove the roles from server 2025 before touching exchange however I would recommend you use Server 2019 for the spare DC and not 2022 because 2022 CAN replicate the broken values where as 2019 could not (in our environment)
grimson73@reddit (OP)
Thanks for chiming in so you are the one ;) Please tell us what did Microsoft do or could you fix it yourself with guidance? Is everything fixed? If you could elaborate on the path to the fix, please. Just curious how things went :).
Tech88Tron@reddit
Why in the world would you update a schema to 2025 un 2025???
That's just volunteering to be the bug finder.
grimson73@reddit (OP)
What do you mean? the bug is (if i'm correct) that when you update the AD schema on a Windows Server 2025 fsmo master schema holder then issues with replicating the schema may arise. So this is more about Windows Server 2025 than Exchange. Also, sometimes a schema update is necessary.
Tech88Tron@reddit
There were many Server 2025 bugs, and big ones that broke Domain Controllers.
All discovered by people silly enough to upgrade their domains ASAP because they couldn't wait.
YourUncleRpie@reddit
Good to know but why would anyone still use on-prem exchange lol
sysadmin_dot_py@reddit
It affects hybrid Exchange environments, too, which includes all cloud Exchange, but on-prem AD identities synced to Entra.
Fatel28@reddit
You do not need exchange to run AD sync. Just use the attributes directly.
Blastergasm@reddit
An exchange server still needs to be installed somewhere for those attributes to be present though even if the server is powered off.
Professional-Heat690@reddit
Not anymore, new cloud feature in preview...
https://learn.microsoft.com/en-us/exchange/hybrid-deployment/enable-exchange-attributes-cloud-management
sysadmin_dot_py@reddit
Amazing. Somehow I missed this. Thanks for posting! I think we will implement after the phase 2 (write-back) is implemented. Can't wait!
Remarkable_Mirror150@reddit
How good! Totally missed this
Fatel28@reddit
That is not true. You can just prepare the schema and never actually install.
That being said, most attributes you actually need are present without doing that. The only time we ever actually prepare the schema in synced environments is if we need to use the authOrig attribute, which is rare.
Lord_Saren@reddit
Was going to say, this is how my org is set up. On-prem AD sync to Entra with O365 Exchange. No on-prem exchange anywhere.
kuahara@reddit
I have on prem exchange that syncs to 365 using AD Connect. I do not like the idea of going purely cloud because I still feel like I have more granular control when troubleshooting.
With cloud only, I only have access to whatever MS decides to expose. Example: proxyAddresses, targetAddress, legacyExchangeDN, msExchHideFromAddressLists, msExchRecipientDisplayType, etc.. With cloud only, some of this is abstracted behind powershell cmdlets with limited functionality.
On prem, I can create transport rules, connectors, etc.. Cloud limits that for security reasons.
A big one is message tracking. On prem, I can access message tracking and log data directly from disk and query it in powershell. With cloud, I only get what Microsoft exposes through the web portal with reduced retention and granularity.
On prem, I can still view and purge transport queues, retry messages, and manipulate routing behavior. Can't do any of that with cloud, just partial statuses and remediation requires me to open a ticket with MS.
On prem, I decide when I apply cumulative updates, schema extensions, and service config changes. With cloud only, MS controls feature roll outs that I can't delay or roll back when they're disruptive.
ofd227@reddit
It's the entire reason I migrated lol
itguytn@reddit
We are the same way and have been since going to M365/Exchange Online back in 2018. Decommissioned the on-prem Exchange server around 2019 but have always wondered if the Exchange attributes ever needed updating to keep up with any possibly changes with Exchange Online.
Fatel28@reddit
It's the way for sure
BigShallot1413@reddit
This is correct, but the Exchange “server” can be powered off and deleted. Just install Exchange powershell on a VM if you need to manage attributes.
Kwinza@reddit
Thats not evwn remotely true.
sysadmin_dot_py@reddit
Correct, but that's not relevant to the article posted by OP. The issue is with the schema and DC replication if you have Exchange schema modifications.
Fatel28@reddit
That's my whole point. You don't even need to do those. I'd say across all our customers who are AD synced, only one or two have the schema modifications. It's not necessary.
icebalm@reddit
Data sovereignty.
MortadellaKing@reddit
This... Most people here are likely Americans, they have no clue their government has imposed rules that allow them to access the datacentres of US based companies even if they are overseas or in Canada. Scary.
ender-_@reddit
Yup. One of our clients that moved to 365 is planning a move back on-premises thanks to https://www.theregister.com/2025/07/25/microsoft_admits_it_cannot_guarantee/
(two others never moved to 365)
dispatch00@reddit
Because some of us can run it better than Microsoft. But thanks for the original thought. No one ever posts this.
wirtnix_wolf@reddit
Not "some". Most of us.
Glass_Call982@reddit
If you're not American, this is a pretty good reason:
https://www.cyberincontext.ca/p/microsoft-admits-us-law-supersedes
We're an MSP servicing mainly healthcare and that's a big concern.
bphett@reddit
We do, but we're a utility company on a coastal area that gets hurricanes. We use it for greater security, and availability during a disaster when there is no connection to the internet. I'd love to go to Exchange Online, but every time I propose it it gets denied for those reasons.
Lord_Saren@reddit
It sounds like you could also make the same argument in reverse. What happens if your building is hit by a hurricane? Do you have backups off-site? If the internet is down, how would you access these backups?
bphett@reddit
Our dedicated dark fiber network that spans our three county service area and travels through our substations is how. Also, we have an SD-WAN with redundant DIA connections at each office. We are in the process of installing starlink at every substation, and our primary datacenter is in a concrete bunker with a dedicated generator located a few miles away from the coastline. Im working on an offsite backup datacenter as well.
Lord_Saren@reddit
I think you might be cooked on switching to the O365 exchange with a setup like that
bphett@reddit
Yup. That's why we use on-prem. Just pointing out there's still a use-case for it in 2025.
stimj@reddit
Relay for legacy apps and MFPS, even if nothing else.
MRHousz@reddit
Postfix has entered that chat
havocspartan@reddit
No, there’s literally no reason. You can do O365 mail relay over port 25 with a simple spf change, since the copier industry isn’t embracing MFA prompts.
https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365
ApiceOfToast@reddit
Well, no mailbox limit. But same holds true for any other self hosted Mail server.
I feel like it's something you'd only use if you already have On-Prem exchange instances. Otherwise no way you're paying MS for that hot mess
Ubera90@reddit
I mean you have to buy CALs still
ApiceOfToast@reddit
For the user yeah, honestly Exchange SE doesn't make sense to me, like it's more expensive than online to my understanding. Or you could get a o365 plan that includes exchange, most of them count as cals for exchange se if I remember correctly
QuillOmega0@reddit
How the hell do you even do that without going through the whole rigmarole of bullshit?
grimson73@reddit (OP)
Wasn’t support ‘free’ if it was a product defect but you have to pay up in advance? Really a long time ago needing support. Seems like this time you can’t ignore or workaround if you are hit with this bug.
Doso777@reddit
Possibly. We got billed anyways.
disclosure5@reddit
It used to be. I've done it in the last few years and you go through five cycles of "gathering the logs" only to have them say they "aren't complete", before they close your ticket in the middle of the night.
thesmiddy@reddit
you have to lie about your timezone so that they call you at 4pm thinking it's 7pm.
disclosure5@reddit
This is genious..
sprousa@reddit
Do not use Windows Server 2025…FTFY
ofd227@reddit
Ive been running it doing some not important stuff. Gonna try DHCP with it next. Let's see what happens
geusebio@reddit
Windows Server 2025... to do a task usually achieved by a SoC with a 4MB ROM.. wat.
RussEfarmer@reddit
Win server DHCP integrates well with AD DNS and has easy to setup failover. Can't hate
systempenguin@reddit
Any OS in the last 20 years can register hostnames to DNS Servers. That's not a Windows thing, at all.
RussEfarmer@reddit
Note how I said "AD" DNS... if your AD integrated DNS zone only allows secure updates and the DHCP client you want to register in DNS does not have a kerberos principal, it can't be registered. The DHCP server can register the record FOR the client though, which is an easy setup in the Microsoft DHCP role.
systempenguin@reddit
Which is irrelevant.
If you need secure updates, devices that cannot handle that authentication - Shouldn't be making such DNS Requests in the first place.
If the device cannot handle secure updates on it's own, you gain no security benefit whatsoever of having the DHCP Server do a secure update for it.
That's like sending your credit card in plain HTTP to the payment processor and then claiming it's secure because the payment processor is encrypting it's traffic to the bank.
ofd227@reddit
My servers are role specific
HybridAthlete98@reddit
Would WS2025 be fine for cloud-native workloads / hosting applications that are currently on WS2022?
Asking as we'd like to keep mainstream support and crafting a business case to upgrade to propose to our client.
VMs are not domain joined, provisioned by Terraform IaC and configs are pushed with Ansible/Chef and Azure DevOps deployments.
Fatality@reddit
The only issues seem to be with the DC role
Antarioo@reddit
Is there ever a reason to run a current release year of windows anything?
i can't recall not waiting at least a year before considering it for upgrades. usually much longer.
NexusOne99@reddit
Man the more I see the happier I am I got laid off. 20+ years in and I'm changing fields.
Vegetable-Emu-4370@reddit
PSA: Do NOT use Windows Server 2025
Cormacolinde@reddit
Combined with the issues with running mixed Domain Controllers with 2025 this is not great. And if you have already upgraded your schema to 2025 and started using dMSAs you are pretty screwed.
Walbabyesser@reddit
Is this an issue? With the dMSAs?
ocdtrekkie@reddit
In addition to the fact being on 2025 schema would be a problem, you may also want to note that yes, dMSAs have unfixed security issues: https://www.akamai.com/blog/security-research/abusing-dmsa-for-privilege-escalation-in-active-directory
My understanding is the current recommendation is to not have any Windows Server 2025 DCs until this is fixed. Combined with this Exchange problem, I get the impression ADDS on 2025 is not production ready today.
Ludwig234@reddit
Microsoft have patched the dMSA issue but really you should control your ACLs harder and it won't be an issue either way.
Cormacolinde@reddit
No, it’s because once you update your schema and start using a new feature you can’t downgrade. Which means you can’t install a 2022 DC which is Microsoft’s “solution”.
grimson73@reddit (OP)
Interesting .. thanks for sharing.
J-Cake@reddit
The first line of the heading of this post on my phone was 'PSA: Do NOT use Windows Server' and I was like hell yea I agree
grimson73@reddit (OP)
Don’t you like some challenges once in a while within your it environment? 😄
J-Cake@reddit
I do. But Windows is not a challenge, just a pain.
spicysanger@reddit
We began migrating all customers off on prrm exchange at least 5 years ago. We have no regrets.
Loudergood@reddit
Who is using server 2025 IN 2025 in production? Yikes. I know we don't get service packs or "R2" anymore but at least wait 3 years.. 2022 is just ripening.
Glass_Call982@reddit
We've stuck with 2022, it just works so well and is supported till 2031.
RookFett@reddit
So glad I passed on 2025 for upgrade and went with 2022.
grimson73@reddit (OP)
AmyDeferred@reddit
I don't think hashtags work on Reddit, btw.
grimson73@reddit (OP)
Sorry just copied it from the exchange server sub. But I agree.
RunningEscaping@reddit
I just installed Exchange SE into my environment two weeks ago in a domain that has some 2025 domain controllers but mostly 2022 controllers. Thankfully haven't moved any FSMO roles to the 2025 servers yet, no repl issues seen