Our developer says they still do not officially support server 2022 and are still testing. Isn't this a bit long to be testing?

[-]

eptiliom@reddit

Several of our vendors skip every other release.

They aren't testing squat. They are just telling you that to get you off the phone.

[-]

pdp10@reddit

They are just telling you that to get you off the phone.

Then insist on filing an issue/ticket/bug, or being added as a stakeholder to the existing one.

Bonus if you can add to the issue/ticket/bug with the useful results of your own testing. Shaming developers into doing the right thing, is always an option.

[-]

cosine83@reddit

Tried that with a big casino gaming software vendor 10+ years ago. The bug I fixed was still present as of Winter 2023.

[-]

Had that happen at a previous job. The vendor was horri-bad, and it was a vertical market appliance. Their way of wanting to "fix" stuff? Buy the new upgraded appliance for well in the six digit range.

I got tired of their crap. I cracked open the appliance, it was just a generic Supermicro enclosure with a SSD. I dd-ed off the OS, saving the image. I then installed Linux some F/OSS stuff, and had the interface be a curses based interface accessible from SSH. It replaced the vendor's hot garbage perfectly.

So much that when the vendor rep wanted to see how their appliances are doing, I showed them the appliance and complimented them on how perfectly their stuff worked, with just one minor modification... a complete purge of every single chunk of software they wrote.

The result? The vendor paid the company I worked for, for insane prices, just for a few shell scripts I wrote... and then turned around, sold that as a version upgrade, after tossing a craptastic webUI on it.

[-]

PM_pics_of_your_roof@reddit

God does that email back feel good.

[-]

NotYourOrac1e@reddit

I go the extra route and show them their code optimized too. "This is how you write a query"

[-]

Kodiak01@reddit

This is like asking CDK when a 64bit Drive client will be available.

[-]

Texkonc@reddit

Ugh......Considering their boxes are on Centos7......

This is a fun industry...

[-]

GuiltyGreen8329@reddit

car industry knowers know

[-]

Kodiak01@reddit

Dealertrack and R&R do not have a strong presence in the MD/HD market though, nowhere even close to CDK/Karmak/Procede.

[-]

GuiltyGreen8329@reddit

oh

i just used them at my kia dealer

never considered manufacturers would use it

[-]

Kodiak01@reddit

I work at a Class 4-8 truck dealership. CDK and Procede are by far the two most popular on that side of the industry. Karmak is around, but I would put it in a distant 3rd.

[-]

yensid7@reddit

We're a dealership network, too. We use Karmak. A bit over 10 years ago we were looking to move off of Karmak's mainframe/terminal system to either CDK or Karmak's Client/Server/SQL upgraded system. Evaluated that vs CDK's new Windows client. When we visited a customer and saw CDK's client was just a front end for their mainframe/terminal system, and the old timers were still spending most of their time in the terminal, we went with Karmak. Hope it's gotten better!

I don't have any familiarity with Procede, haven't really heard it mentioned, but most of the others I talk to in our industry are at the Karmak conferences, so that's not surprising.

[-]

jameson71@reddit

CDK's client was just a front end for their mainframe/terminal system, and the old timers were still spending most of their time in the terminal

That...really sounds like the best of both worlds. Reliability of a mainframe with a nice client gui.

[-]

Kodiak01@reddit

I will give up my text DMS access when they pry it from my cold, dead fingers.

[-]

Kodiak01@reddit

I only used Procede for about a year long ago when I temporarily switched to a Freightshaker dealer. I don't know if I just wasn't trained correctly, but it seemed... clunky. Everything was like a series of spreadsheets with a lot of manual copying.

For CDK, most everyone here, at least on the Parts side, still uses the old school text system as we can do things MUCH faster than their slow GUI model. The only function we're forced to use the GUI is for AOMD which is required for centralized PO handling (vs CPO which everything was isolated.) Most all of us in our location and department have 20-30 years experience so we're all pretty set in our ways.

CDK does have it's quirks, but it is very versatile, especially if you're familiar with SQL for advanced report building (they also have a drag and drop report generator as well.)

If you ever drop into a sub like /r/partscounter or /r/serviceadvisors, there is one thing that everybody can pretty much agree on:

Tekion sucks. My condolences to anyone using ADS as well (LKQ/Keystone was using that back over a decade ago, and some aftermarket suppliers like Metro Fuel Injection switched to it as well.)

I'm told our group actually looked at alternate options to CDK at one point, but one of the biggest sticking points turned out to be the lack of ability to easily export all the current data from it. I expect other DMS providers make it similarly difficult as a way to keep customers.

[-]

yensid7@reddit

Yeah, we've onboarded a CDK shop before (we've got quite a few sites, a number of which are from acquisitions), and I know it was a struggle to get them imported. Luckily I wasn't too involved in that - we have an admin who just does Karmak, and their team took care of most of it.

Thanks for letting me know about those subs, I never realized!

[-]

Kodiak01@reddit

Thanks for letting me know about those subs, I never realized!

Hopefully you're at least already subscribed to /r/Justrolledintotheshop!

[-]

Qurtys_Lyn@reddit

As long as it's not Reynolds. Anything but Reynolds.

Happy to not be dealing with that nonsense anymore.

[-]

Jordan011@reddit

Our group is on it. The group is run by people who know nothing about computers and they hate change. Not to mention R&R love their long contracts, so they'll be on it forever.

I'm solo IT for 5 stores, a restaurant, an RV Park, and a hotel now. 💀

[-]

VexingRaven@reddit

Even better, come work in accounting and you can support all 3 plus whatever other stinky shit software every other industry your accountants support uses.

[-]

Sudden_Office8710@reddit

🤣 dear lord it’s been a minute since I heard someone bring up Reynolds & Reynolds used to do work for this company called the Net Lab that was building dealership portals back in the ‘90s what a crazy time that was back in the e-commerce dark ages where we made shit more than we do now.

[-]

GuiltyGreen8329@reddit

as someone who hasnt worked with it, ive gotten that feeling from them.

[-]

yensid7@reddit

Hahaha, truck industry, too!

[-]

WhatwouldJeffdo45@reddit

It wasn't till almost 5 years ago now they finally removed clear text telnet....

[-]

Kodiak01@reddit

We never used that, all of us prefer the standard text DMS windows.

I can understand why service would use the GUI in certain circumstances, however; when a service employee has Invoicing access, they can mass-move parts between lines in PRO. You can't do that in the text version.

[-]

fataldarkness@reddit

Fffuuuuuccccccckklkk CDK, I'm 7 years out of supporting them but holy crap they suck.

[-]

AHrubik@reddit

Yep. The testing period for a production OS 3 years old has long passed. They had access to 2022 for at least a year before release as well. They just don't want to commit the resources to support it so it will never leave "testing" status.

[-]

My_Big_Black_Hawk@reddit

We’re leaving a large vendor because of this.

[-]

MagicWishMonkey@reddit

It's not like windows changes much between releases, it's kind of crazy that companies tie their shoelaces together like that.

[-]

My_Big_Black_Hawk@reddit

Absolutely agree. Sometimes there are OS dependencies, but often it’s just the software installer not including future OSs in their “approved” OS list. It’s just so the vendor can scam their customers out of more money to buy their next version of software. “Sorry this version of our software is not supported on windows server 2022 and up. You need to upgrade to 7.x. Let me write up a quote and send it your way”

[-]

AHrubik@reddit

I don't blame you. Some organizations have a one down strategy. Since 2025 is (has been) production released it's time to move to 2022. Any software vendor who still doesn't support 22 is seriously mismanaged.

[-]

bindermichi@reddit

So they leave you with unsupported servers? Why would you even accept that?

[-]

eptiliom@reddit

Extended support has always lasted longer than the version skips as far as I can recall.

I accept whatever my bosses tell me to accept. Im not here to uprise against my employer.

[-]

bindermichi@reddit

Just tell them how much the extended support will ist them. That alone should create sufficient pressure

[-]

kerosene31@reddit

I've had them ask me to let them know how our internal testing goes.

[-]

Lukage@reddit

We had a vendor earlier this year ask us for our hardware specs so they can give another client a recommendation. We were the first to insist the app, database, and end user apps be not on one giant orgy of a terminal server.

"It causes too much latency to function if they're on separate VMs."

[-]

RBeck@reddit

Presuming it's all IP traffic it's hard to see the difference between processes running on the same hypervisor within the same VM or on different VMs. The "network traffic" never leaves memory.

[-]

lungbong@reddit

Similar, we have a vendor doesn't support odd numbered versions of Windows Server.

[-]

WorkLurkerThrowaway@reddit

The vendor of our “core” most important software that we run our entire business on just barely announced a version other than server 2016 that would be supported.

[-]

SpecialRespect7235@reddit

Depends. In comparison, Shoretel support doesn't officially support any technology developed after Windows 2003.

[-]

Sir-Spork@reddit

Yep, got software running on 15 year old versions of red hat because of that and when the finally certify the next version, that OS is end of life or nearly so

[-]

dumbappsignup@reddit

It isn't reasonable to expect enterprise software to compile on modern OSes. It depends on the application, the stack, the technology but no without actual context probably not something you should expect. Medical: hard no. Military: no. Accounting: nope. GIst is that let them tell you when it's ready they're the professional, if they tell you it isn't tested and isn't a good idea they know.

Example: some apps written in older csharp versions might be unsupported on newer OSes. Some dependencies the app uses same story.

Medical software explanation: drivers written for older os might just not work at all and require investment to write for the new app...

[-]

RegularOrdinary9875@reddit

You know, windows server 2022 is going out of the support next year 😁

[-]

pugs_in_a_basket@reddit

It's normal, unfortunately. There's no standard. Or maybe there is, the standard being if the vendor is in danger of losing business if they dont. And there you have it. Do what you must, or as it usually, what you can (renew the contract).

[-]

boblob-law@reddit

Is your vendor Fiserv.

[-]

therankin@reddit

I just had an upgrade project done and VMs were deployed with Server 2025 (24H2). Isn't that the current version? Or is that considered too new to be current?

[-]

Used_Cry_1137@reddit

Sure, if you assume that:

They’ve been testing since 1JAN2022 and not like a month ago.

They’ve been given time by their management to test this. (Ha ha ha ha!)

They didn’t find any incompatibility to make changes to accommodate.

[-]

anonymously_ashamed@reddit

You should check out medical. I installed a brand new PACS (imaging) system in 2021 on server 2012 because it's the newest they supported. In 2023 they started to support server 2016.

In 2022 I installed a different PACS system elsewhere on the most recent OS they supported: Server 2016. But they "were close on server 2019, probably in 2023 we could start a project to upgrade".

In 2022 I was still supporting a few windows 7 devices because the company decided going out of business was easier than upgrading to Windows 10.

No, there is no standard. No, they're probably not even testing it. They have no need to waste cycles testing something that gains them nothing.

In reality, it's probably fine to run on the newer OS, but if you need support and they notice, don't expect them to be of any help.

[-]

Arudinne@reddit

In reality, it's probably fine to run on the newer OS

50/50 shot really.

We used to run Tableau on prem. It would not even install let along work on Server 2022 and wouldn't even work with our Server 2022 Domain controllers, so users from one of our three domains (M&As) just never worked with it.

This was true until well into mid 2023 when we finally shut it down after migrating to the cloud version.

[-]

Corrupt_Power@reddit

Tbf this tends to be an intentional tactic when there's a cloud version available, to force people over to it.

[-]

pdp10@reddit

Not just cloud. Fifteen years ago we were finishing up the last of a migration from a legacy client VPN into IPsec on Cisco ASA, when it turned out that Cisco had no 64-bit Windows IPsec client. Because client VPN used a binary network driver, the word size had to match the NT kernel.

We already used the open-source vpnc as client on Linux. We tried the third-party ShrewSoft IPsec client on 64-bit Windows, but this never worked well and reliably enough to go into production. Our VPN consolidation

When questioned, Cisco wanted us to switch to their "SSL" (their term) based VPN, which required additional all-new per-client licensing. Not acceptable.

We started the long process of moving to zero trust and dropping the highly problematic client VPNs. Cisco did eventually issue a 64-bit client, but by that point we barely cared anymore. Years later, "SSL" VPNs had catastrophic infosec vulnerabilities, prompting a widespread reversion to IPsec client VPNs.

[-]

ender-_@reddit

I remember getting the old Cisco VPN client to run on x64 Windows by also installing some other VPN product, which included an x64 version of the driver that Cisco also used (IIRC, it also involved getting around Windows itself blocking the Cisco installer).

[-]

admalledd@reddit

Yea, as a developer whose job it is to triage "why did our old code explode/not work on $new?" about half the time, a good sniff test is if the application:

Uses the Registry outside of HKLM\Software\$prog and HKCU\Software\$prog
Uses COM, especially 32-bit COM libraries.
Uses DCOM. Run, very fast, from anything using DCOM, to your nearest internal InfoSec compliance person and have a conversation on if you are violating contracts/spec by having DCOM. Great way to push back on Vendors using DCOM still.
Integrates/queries AD, especially if it is for anything more than "log in the user, is user in group?" basics. If it is looking up custom attributes, consider changing careers.
Application has a native UI that still uses MFC (... Looking at you VisualStudio legacy-ext-compat!)
Application requires installer, or you, in anyway to touch the GAC or look at dotnet FusionLogs.
Requires you to install NetFramework of any version between 1.0 and 3.5 or CLR 2.0, etc

There are other yellow/red flags, but each of those above are things that have caused code that my job maintains explode in some way when trying newer OS versions (or newer AD).

[-]

TheMcSebi@reddit

Thanks for the insight!

[-]

MBILC@reddit

And more so less of an issue now with how Windows Server 2022 and 2025 do not differ much at the core....

Sure 2012 to 2019...big changes, 2016, meh, some...

It is like Windows 11 and update rings, or going Windows 10 to 11, it is still v10 of the kernel, but 10.0.19 for win 10, 10.0.2* for 11, so unless said apps actually do an OS check for version..most times it "should" work... but is still a gamble.

[-]

spin81@reddit

They have no need to waste cycles testing something that gains them nothing.

...and no competition, probably.

[-]

TheMcSebi@reddit

Do you know by any chance the reason why it doesn't work? In my experience even Windows 95 Software runs on modern windows.

I assume it's Dongle drivers, so DRM as always. Can you confirm?

[-]

spoonstar@reddit

Our trick was to upgrade our fleet anyway and leave progressively smaller amounts (down to 1 after 5-6 months) on the older their-supported-yet-getting-patches OS set aside to let the vendor remote into to see the issue.

[-]

Secret_Account07@reddit

Wow. This is insane to me

[-]

MBILC@reddit

Or, they release support for newer OSes in a new major version so they can try and charge you a boat load to get support again...

Otherwise they still support the old version, so long as you remain on an EoL OS....

The other issue is companies not wanting to keep up support contracts to allow the upgrades to be done/included because "it works, when do we ever reach out to support" , then 10-15 years go by and the change to a new version is SO drastic because interfaces changed, functionality and now cost is even more than if they just kept an active support contract going...and you can not even do a 1:1 migration from your ancient relic version..

[-]

Antique_Grapefruit_5@reddit

I change vendors when this happens...

[-]

MBILC@reddit

When ever possible, people do need to put their foot down on these sorts of things.

But then you also get into the politics now of changing systems and often times those above, decide to stay because they do not like change (if it is a system for other departments)

[-]

19610taw3@reddit

Mmhmm.

Medical IT, here. I have software that "doesn't support" anything newer than server 2012.

The software itself receives regular updates, but the vendor just won't certify it for any newer server OS.

So it's running on 2022 unsupported.

[-]

Cormacolinde@reddit

And then there’s the stupid software devs who ask you not to install updates. Or stop working if you install any .NET update, even just security updates.

[-]

landob@reddit

Just curious. was it opalrad? I feel like I ran into that. Had to spin up a 2023 RDS server just so it could have I think IE8 cause it didn't support past that or something : /

[-]

Miserable-Wallaby776@reddit

Honestly, "testing" is often just vendor-speak for "we haven't gotten around to it yet," and there's definately no standard. I'd just document teh risk of staying on the old OS and make the business unit that owns the app formally accept it in writing.

[-]

No_Winner2301@reddit

There is no standard it depends on the agreement you have with them. The question seems nonsensical do you not really mean vendor and not developer?

[-]

noideabutitwillbeok@reddit

I work in medical and this isn't too out of the ordinary. Had someone try to give us new gear earlier this year that was Windows 7 as "they weren't done testing on 10 yet". Holy shit dude, 11 is out already. Denied it, told them to come back once they figure their shit out.

[-]

booi@reddit

Why would you target windows server anything in this day and age

[-]

hy2rogenh3@reddit

We’ve worked with our leadership team to put version and OS support in contacts. If a vendor doesn’t support in security support OSes we’ll move on and sever the contract. But we’re regulated and there is stricter controls so your mileage may vary.

[-]

CARLEtheCamry@reddit

And next year those vendors will come back and and pitch an "appliance" and try not to tell you what it's actually running.

Caught a building management vendor trying to get us to install their appliance, running Win CE 6 connected to a cellular modem.

[-]

crazzygamer2025@reddit

I haven't used Win ce 6 since around 2015 I don't think that version of the windows is getting security updates

[-]

CARLEtheCamry@reddit

You don't say.

[-]

pixr99@reddit

"Hey, wait a sec. This appliance is actually three racoons in a trenchcoat!"

[-]

doubleUsee@reddit

three racoons in a trenchcoat would be so much more secure though...

[-]

Splask@reddit

Strict controls can be a pain, but its always nice to say if you don't support stuff that we are required to have to stay compliant, then we are not doing business.

[-]

cats_are_the_devil@reddit

That's a very good strategy.

[-]

karlsmission@reddit

as somebody who works with internal apps trying to get them on modern OS, This screams "the guy who made this 20 years ago doesn't work for the company anymore, and none of the rest of us know what the hell is going on, and we have no idea what to do".

without knowing what the app is, is there an exist strategy? or an option to move off to something else, or at least give it it's own garden to play in that doesn't touch anything else?

[-]

occasional_cynic@reddit

The best is manufacturing where you find out the entire company went under twenty years ago.

[-]

karlsmission@reddit

been there, done that. Had some machines that required not just older machines to run, but specific motherboards with a specific chipset and bios level. I had saved searches on ebay to find them when they cropped up, and re-capped those mofos like it was my job (which... it was).

[-]

pdp10@reddit

From an abundance of caution, we now have a mothballed stock of Asus motherboards from circa 2000 to 2010, replete with serial and parallel ports, original PCI slots, etc. Long-running standards like ATX are so nice.

[-]

Pr3vYCa@reddit

I wonder if stock like these should be turned on once in awhile to shake off the rust ?

[-]

cluberti@reddit

Heh - sounds like a manufacturing company I contracted for awhile back. Literal large rooms full of old Compaq machines (sans hard drives) in box, because the old application they ran to control the line and floor robots was (very) sensitive to things like CPU speeds and still needed direct access to serial ports and didn't work via USB converters. From what I understand they still have a large stockpile of these 20+ years later, and no plans to replace any of it just yet due to how costly that can be (and I suspect the next few years under tariffs aren't going to make that any more palatable).

[-]

ToastedChief@reddit

Sounds like our old Honeywell Dell T5500 and 470 computers for operation :’)

[-]

karlsmission@reddit

This was a decade ago, so I don't remember the machines all that well (I was there a year before I burned out hard). I don't think that place is still in business.

[-]

pickled-pilot@reddit

This is why I’m actually a fan of the software subscription model. It give the vendor some much needed revenue to support continued operation a support of the product.

[-]

thegoatmilkguy@reddit

I'm in manufacturing/energy and found out a vendor for a key app was just one guy... And then he off and died during COVID and nobody had source code or anything. Nobody makes this niche thing so we paid another company to build something functionally equivalent so we could have a tool that was supported and not running on hopes and prayers. Pretty sure just one guy in the new company did the whole thing so we could end up in the same scenario again...

[-]

usernamedottxt@reddit

Goes for parts too. Worked for a manufacturing plant once and the only clean room in the entire building was the back corner with the most expensive machines and the highest paid folks. Their job was to reverse engineer, prototype, and do small runs of various bits and pieces that were no longer produced. They were doing some non-standard size bearings for a customer that bought the machine 10 years ago and the supplier had been closed just about as long.

[-]

thirsty_zymurgist@reddit

I had a buddy in college who's father had a small manufacturing company, really more of a "job shop", that was licensed by GM to make parts for their older cars. He made a fortune producing one-off parts for classic cars. Most stuff he had the plans for but there was a few stories he told of having the old broken part and having to recreate it.

[-]

mjh2901@reddit

Now its even better, company was bought by private equity, they created a website to purchase the product and posted all tech documents, removed all the dates. Then closed the company, laid everyone off and handed the product over to division that just sells it, no support, no development.

[-]

pdp10@reddit

This is a good reminder to test vendor support, or ideally PoC implement the product, before making a commitment.

If your stakeholders will let you. If they won't, put that fact in writing, and move on.

[-]

CelestialFury@reddit

put that fact in writing

Best advice for anything, really. CYA is always in effect.

[-]

jimmytickles@reddit

SAP?

[-]

admalledd@reddit

We actually have a funny one for internally: Server 2022, no matter what we do, does not work with a legacy COM library we have to use, even have a MSFT ticket out is how desperate we are. In a fit of madness, we tried Server 2025 and with two regedits it works juust enough. What changed? no idea. Why didn't those regedits work on Server2022? no idea.

[-]

cluberti@reddit

Fun fact, Server 2022 is the only mainline Windows server branch that wasn't built off of a mainline LTSC Windows release, client release, or semi-annual channel build, but instead is build 20348 which is not aligned to a Windows 10 or a Windows 11 semi-annual channel release nor an LTSC channel release, even though it was released before Microsoft had "officially" canceled all but the LTSC releases of Windows Server in 2023 (the last SAC release of Windows Server was 20H2...).

It's an oddball build in Windows land, so not surprising it has it's own "quirks and features".

[-]

karlsmission@reddit

that's some fuckery. I work somewhere where 99% of what we use was built in house, which is great, we don't rely on outside vendors for stuff.... BUT most of it was made 15+ years ago, and the programmers that did so are LONG gone. There has been a lot of effort to rebuild stuff in a modern and documented way, but that process is slow and painful. I'm more infrastructure side of the house, so I mostly just get cried to about how bad it is, and tell people that no, increasing resources yet again won't actually fix the bad code....

[-]

admalledd@reddit

That is mostly us too, parent company is really the merging of some 15+ over the years, so quite the collection of strange.

I am one of the developers whose thing it is to modernize/update the apps. Though our ratio is more 80% internal, though we do use vendor-libraries for a number of things. This COM lib is just damned one that we have to use, and is provided by a client-vendor, they know it sucks, I worked with their devs on it from time to time when we were trying to get it to work.

[-]

stoltzld@reddit

I think you meant to type exit strategy?

[-]

karlsmission@reddit

Damn it, yes. I blame auto correct. It likes to change correctly typed words to other words it thinks I mean to say.

[-]

stoltzld@reddit

Yeah, every so often I'll read an old post or comment and have to correct it. I have to train myself to proofread more often instead of trusting the spell correct.

[-]

karlsmission@reddit

For text messages, I've seen it change words when I hit send. like straight up, I'll read it, and make sure it's what I want to say, hit send and just as I do that, it will flip a word and send it... I hate my iphone, but cannot change from it for a while still.

[-]

stromm@reddit

N-1.

As long as an app supports that, I’m OK with it.

The real issue is what isn’t the app support team (internal, not vendor) being held accountable?

[-]

disclosure5@reddit

Server 2022 is already N-1.

[-]

stromm@reddit

Uh huh.

Was I not clear about anything I wrote?

[-]

uptimefordays@reddit

Yes, the time to test was before general availability.

[-]

PREMIUM_POKEBALL@reddit

For how much fuckery 2025 is going under with AD nonsense we may have to walk this back: we’re testing in realtime lol.

[-]

thefinalep@reddit

server 2025? Never heard of her. I'm only aware of server 2022 as being the latest ;)

[-]

1StepBelowExcellence@reddit

IMO, Server 2022 is the new 2008 and 2025 is the new 2012 in the sense of the tech debt and resistance to change both the latter versions brought/will inevitably bring.

[-]

uptimefordays@reddit

2025 has been fine provided you're aware of changes it brings, such as "no longer supporting old ciphers for NTLM." The problem isn't Server 2025 it's people not staying on top of changes or testing prior to production deployment. Microsoft has not been quiet about changes but they cannot force customers to read product announcements, patch notes, technical blogs, etc.

[-]

disclosure5@reddit

You've complained in a number of places that people should be reading official channels regarding recent issues - Active Directory in Windows 2025 was effectively broken for months with the only proper "documentation" being a couple of Reddit threads. I spend a lot of my day reading Microsoft's announcements and documentation and the suggestion the current breakage was a loudly documented config issue is one I can't agree with.

The only single cipher used in NTLM is MD4. Perhaps you're talking Kerberos ciphers.

[-]

uptimefordays@reddit

Microsoft announced NTLM would be deprecated in October 2023. Later, in June 2024, Microsoft officially announced the deprecation of all NTLM versions. By December 2024, Microsoft confirmed that NTLMv1 was removed starting with Windows Server 2025 and Windows 11, version 24H2, aligning with their "secure by default" initiative.

It’s kind of surprising how a multi year change caught so many IT department flat footed.

[-]

disclosure5@reddit

Planned deprecation of NTLM has nothing whatsoever to do with the issues people are experiencing. NTLM still works fully and NTLMv1 removal hasn't affected anyone since NTLMv2 has been a default since like Windows XP days.

Noone was caught flat footed by this, noone was impacted by this and I'd encourage you to consider how smuggly you're attacking people that read absolutely everything but were caught off guard by Microsoft's entirely undocumented changes to Kerberos in AD 2025 which is what people are struggling with.

[-]

MBILC@reddit

Might want to check recent news the last 2 weeks. 2025 had another major bug in the recent cumulative updates.

[-]

uptimefordays@reddit

I should also clarify, my esteemed employer does not run WinServ 2025 DCs so this and NTLM related issues are not impacting us.

However, when patches do impact us, it's much easier telling my CIO and the business "this is impacting all of Microsoft's customers" rather than telling them "it's only a P1 here because of our esoteric setup."

[-]

MBILC@reddit

For sure, it is nice to be able to fall back to blame Microsoft, and especially in orgs that do not do testing prior to patching, or do not leave a window of a week or 2 before patching critical infra to be sure any bugs are fixed first.

being on the latest and greatest for critical infra is not always best, especially when 2022 is still fully supported.

It is good to get some systems running and testing with a new server OS to confirm things will run fine, which for most companies, 2025 works just fine, but there are just as many who have had constant headaches with 2025 (in part as you noted, by not keeping up on release notes and changes)

[-]

uptimefordays@reddit

Ideally we're not blaming Microsoft often! I would not suggest anyone run new versions of Windows Server in prod day one, though I definitely have unattended upgrades configured on thousands of RHEL VMs (though not leapp upgrades).

Generally we would want to have something like patch rings, dev environments running on preproduction versions of supported platforms, etc. to ensure "when patches are applied we already know what will happen." In my industry we have dates by which updates must be applied for regulatory compliance so we build, plan, and test around the end of that box.

That said though, I would have a hard time signing off on software that doesn't target current versions of the platform on which they run.

[-]

MBILC@reddit

Similar for me in a past client, critical power infra, so there were hard set dates for patches and a process to rush any critical ones that could have a direct impact. But even with that, as you have, there was a test environment, and then once approved for Prod, it was a 50/50. Update 2 of the 4 DC's for example, then the following week, if no issues, the other 2 would be done.

And certainly, if a provider is not keeping relatively up to date on new OS's, considering 2025 has been out for enough time now, and does not vary too much from 2022, it would raise flags for me.

Like back in the day when some providers claimed outright they do not support virtualized OS's and things had to be run on bare metal, but they could never tell you why....

[-]

1StepBelowExcellence@reddit

I'm in full agreement with you, but I'm talking about what I think will be the inevitable effects, not that I'm giving admins a pass at being unaware or justifying their resistance and hesitance to the upgrade.

[-]

uptimefordays@reddit

I mean 2008 wasn't super widely adopted at launch, no was 2022--look how many people here still run 2019.

[-]

gandraw@reddit

You probably mean 2008 R2, that was the great one.

2008 was Vista Server, everybody hated that.

[-]

thefinalep@reddit

I"m not resistant to 2025, I'm just waiting for it to stop being in the sys admin news cycles for catastrophic failures.

My environment is well documented. My team understands what our servers do, and can easily create migration plans when the time comes.

End of support for 2022 is in 2031. Most of everything will be migrated to 2025 by 2029. Now I only have a few hundred of Windows servers, so that approach may be different if I had a larger responsibility. I'll ditch 2025 in 2032/3 and on to the next.

[-]

uptimefordays@reddit

Well sure, if you didn’t read any of Microsoft’s blogs or warnings about changes to NTLM you’d be really screwed! People who did no research and/or blindly upgraded with zero testing in their environments probably shouldn’t be making decisions about what OS to run for core production systems.

[-]

xSchizogenie@reddit

Turn it around: We will migrate our servers to server 2025 until March 2026, that’s your deadline to make the software running it.

[-]

Secret_Account07@reddit

This is how we got folks off 2012.

All VMs running 2012 are a security vulnerability and compromising our security posture. As such, we will be powering off all 2012 R2 servers on x/x/20xx when they no longer receive security patches. We request you upgrade or migrate all data off 6 weeks in advance so as not to cause unnecessary pain in the asses.

[-]

mahsab@reddit

Or else what? 🙃

[-]

xSchizogenie@reddit

Was an example how it could also go. Go with time, or you’re gone with time. 🤭

[-]

Zealousideal-Shine52@reddit

They arnt testing they are probably developing a cloud solution that you will have no choice but to move too as your organization forces you off sunset OS’s

[-]

Secret_Account07@reddit

The lack of communication from them is probably the most frustrating.

This is why we have a rough set schedule.

Customers know by 6 months after new version we are going to be supporting it. I can think of a few hiccups over last decade but those are always communicated

Some of the comments here are nightmare devs lol

[-]

Secret_Account07@reddit

Yes extremely long.

Were have a rather large environment (~6,000 VMs) but have been rolling out 2025 for a bit. Customers get way too antsy and start asking before new version even releases, which drives me absolutely bonkers, but I can’t imagine it takes more than 6 months to test all tools and get a template created. Licensing shouldn’t take that long either.

We have quite a few 2025s out so not doing 2022 is ridiculous to me.

[-]

Ok_Conclusion5966@reddit

drop the vendor, money is the only thing they understand

[-]

PossibilityOrganic@reddit

Also server 2022 has been a bit iffy running as a vm on kvm/open stack unless your running fairly bleeding edge. Disk Io has some weird issues

So that may be the hesitation.

[-]

SikhGamer@reddit

In general, I don't tend to voice an opinion on other people's job especially when I don't know anything about what their job entails.

Otherwise you'll get people expecting you to do your job in a timeframe they know nothing about.

What do you know about developing an app for Windows Server?

[-]

sodiumbromium@reddit

Nah, it's not that. It's just "if a previous version is still in support, we are not wasting resources on certifying anything else".

[-]

MacAdminInTraning@reddit

If they are not supporting 2022 as of this point they never will, I’d consider looking for a replacement tool.

[-]

BigBobFro@reddit

USAF are probably just now getting to thentesting of 2022. They are usually 2-3 major versions behind. When 2012 was released,.. they had only just certified server 2003 for use

[-]

RequirementBusiness8@reddit

Yea, that seems pretty unreasonable imho. I get that some vendors will skip OS versions, but yea, I would call that unacceptable.

[-]

nemec@reddit

isn't this a long time to wait for a developer to test their software?

I mean there are still companies with software which only supports Windows XP. But yeah, this can mean "we haven't bothered to look at it yet" to "it's broken and we haven't addressed all the issues yet".

Is there a standard

I would say it depends on what's in your contract, but it sounds like the dev is part of your own company. At some point you / your management needs to escalate the issue with their management to make sure the developer is allocated sufficient time to test and fix issues. They probably have a lot of other things going on and 2022 support is not prioritized.

[-]

DeepFakeMySoul@reddit

How will abandoning new shiney features and making it compatible with a new OS generate revenue for the company?

Thats the angle that needs to be taken, if you want management to push this, explain why it will benefit them. Will it save man hours, will it what?

[-]

sodiumbromium@reddit

Yeah. The vendor I formerly worked for said it didn't work on 22.

Got it to work on 22 and their response was "yeah it'll work but we don't support it on there as we haven't tested it and aren't planning to."

Thanks, chief!

[-]

Fatality@reddit

Devs don't know much outside their specialties and a lot of them don't care to learn

[-]

AnonymooseRedditor@reddit

Do they support any currently supported OS? Yikes

[-]

RBeck@reddit

Not if they're trying to push you to their cloud solution.

[-]

Antique_Grapefruit_5@reddit

Feels familiar. Philips is famous for this: "Our new software supports server 2019. You can PAY to upgrade to that.". Me: Microsoft no longer supported that as of January 2024. Them: "Well, Philips supports it!"

[-]

spikeyfreak@reddit

My favorite is HPE killing Synergy hardware support for OSes that are still supported by Microsoft.

2016 has been unsupported for a couple of years now. 2019 is about to go out of support.

[-]

Altusbc@reddit

Last place i worked, we would only do a formal cert of our logistical shipping software on every other Windows server version. For example: cert on 2012, skipped 2016, cert on 2019, skip 2022, cert on 2025. This is clearly laid out in all signed agreements so that no one can say, " you didn't tell us that."

[-]

MrJacks0n@reddit

I had 2016 as the most recent supported a few months ago.

[-]

p2ii5150@reddit

They aren't testing...

[-]

bindermichi@reddit

The "standard" would be to only support version that are in Mainstream support. So I would tell this developer they have time to fix this until the Mainstream support for Windows Server 2019 end. Which is on January 9, 2024. Alternatively they could pay for the added cost of extended support packages.

Also look for a different supplier for software.

[-]

PenlessScribe@reddit

A friend at a large company said they didn't get approved to deploy Windows 7 until a year before Windows 10 was released.

[-]

pdp10@reddit

Though, to be fair, that would have been 2014 and Windows 7 didn't go EOL until 2020-01-14. Five and a half years.

[-]

Expensive-Might-7906@reddit

Some software is developed around free tools that are not supported in later versions. Some of them are migrating to cloud and don’t do extensive testing either. Some are unwilling to do a partial test to say “yes” and would rather be honest about true compatibility.

[-]

grep65535@reddit

devs don't understand the sysadmin mindset no matter how much they claim they do. They won't be convinced on things related to infra maintenance and security because typically their focus is code and not its periphery (which is shortsighted), and they're not trained to care.

We legit have a senior dev who claims (among other things) they're a "memory expert" because they "installed extra memory on their laptop at home" and therefore know that a SQL Server that's been demonstrated to consume 28GB memory at its peak when configured to ceiling out at 48GB, "requires" at least 128GB to stop his massive stored procedure from being a blocking process on everything else.

He also claims that another database that just stores 3 tables of not normalized records with nothing else going on "isn't compatible with anything higher than SQL Server 2014 compatibility level...so even though we've moved the server to 2022, he refuses to up the level....because he's also a "SQL expert" lol

It's exhausting and infuriating at times. Also, dev compatibility claims against OS levels never stopped me from standing up a VM and trying it out. If you've had no history of support calls and the product is trivial to troubleshoot and/or has good logging, support may actually be a hindrance. Obviously it's different in environments with contracted outsourced support and special devices that are more important to the organization than you yourself are.

[-]

LastTechStanding@reddit

Haha same dev probably uses select * too…. And likely doesn’t know how to use indexes in SQL either smh

[-]

grep65535@reddit

The same guy scoffs at and brushes off Brent Ozar and says "that's just 1 guy's opinion"... lol dinosaurs are among us.

[-]

LastTechStanding@reddit

Brent Ozar is basically the default guy all SQL admins follow

[-]

pdp10@reddit

"requires" at least 128GB to stop his massive stored procedure from being a blocking process on everything else.

These situations can sometimes be resolved with a friendly wager. What percentage faster do you say it's going to be when we bump the memory, again?

Sure, it'll buy time for the DBA while you source, procure PO, receive, downtime, and install, but it's often worth it to temporarily install some memory in order to foreclose certain classes of complaints. And make sure to run the benchmark again immediately before putting in the memory.

[-]

timallen445@reddit

Supporting a new OS can be a major pain that can take away from other development tasks. Also combine the minority of users/customers that are demanding a new OS with the risk there are OS level bugs or software conflicts you could be diving into major head aches for a fraction of your user base.

[-]

TerrificVixen5693@reddit

A new three year old OS.

[-]

timallen445@reddit

Would you want your software developer focusing on new features or bug fixes or testing every micro function on a new OS?

[-]

NorthStarTX@reddit

I think it's pretty important that at least one developer focuses on making sure that their product is usable on at least one OS that is not past EOL. Otherwise your product can't be considered in compliance at any company that cares about such things.

[-]

pdp10@reddit

I expect our software developer vendors to have automated integration tests, just like we do. If they can't keep the existing codebase working, I sure don't want them adding "features".

We've found that it's not uncommon for the process of batch-fixing issues turned up by a tool or by a new platform, to have silently fixed known bugs. We discover this when the (usually automated) reproduction cases fail to reproduce on the newer codebase.

[-]

marklein@reddit

The software is 200% worthless without an OS to run it on, so yeah I kind of expect them to test it too.

Imagine a car maker designing a car but never testing it on a ROAD.

[-]

TerrificVixen5693@reddit

They should be practicing modern modular software development practices that decouple the application from the OS, so neither.

[-]

timallen445@reddit

what if the codebase is not modern?

[-]

andrea_ci@reddit

for a normal application, supporting an highly retro compatible new version is not a big task.

they're not making a new dbms, driver or similar...

[-]

uptimefordays@reddit

Server 2022 is 3 years old, it’s not bleeding edge anymore.

[-]

don_biglia@reddit

Meanwhile I'm waiting to be able to request ws 2025 machines to start configuration and qualification 😅 so I would say they're late yes.

[-]

DeltaSierra426@reddit

There's no standard, but yes, I would agree that it's long and IMO overdue at this point. Unfortunately, it's not uncommon. Devs tend to prioritize new products, features, and bug fixes over validating new OS releases. That's their bread and butter and ultimately how they make money, not so much taking customers' business priorities and IT operations as any concern of their own. They aren't taking into account that IT has limited timeframes on software support cycles, with major OS upgrades and often entirely new hardware being major operations and requiring pain-staking effort to get right and get done in a timely fashion. While Server 2019 has support for many years, why would any organization deploy 2019 on brand new servers today? Some are already deploying 2025, whether still just in testing stages or to full production, e.g. especially Domain Controllers.

Server 2022 isn't radically different than Server 2019 just as Windows 11 isn't radically different than Windows 10 (same NT build version of 10 as one example), so the delay really isn't warranted IMO.

[-]

razzemmatazz@reddit

Not all devs want that, but most management prefers to sweep mountains of tech debt under the rug so that sales can try to market the new shiny thing rather than support "legacy" projects. Last job I worked at the bread and butter app was written in Visual Basic 6 and was nearly impossible to maintain but no one could replicate it in a more modern language.

[-]

pdp10@reddit

An older language would have worked fine, too, so long as it wasn't a proprietary, single-implementation, language owned by a vendor who wanted you to move to something else.

Visual Basic only lasted from 1991 to 1998, with the final 1998 version ending all official support in 2008. There was never any 64-bit (only 16-bit and 32-bit) or IPv6 support.

Contrast with, say, Lisp, an old and now-uncommon language. Created in 1958, standardized with multiple implementations in 1984, still used today for major SaaS web applications like ITA and Grammarly, and infrastructure utilities like PGLoader. Lisp has been used to write around four operating systems.

The issue with legacy VB6 isn't usually that the code itself can't be simply rewritten, it's typically that binary-only COM or ActiveX libraries were being called from classic VB. If so, there was a separate dependency problem from the start, not just the dependency on Microsoft's VB language being supported.

That, or the source code has simply been lost, which isn't rare either.

[-]

razzemmatazz@reddit

It could have been any of the factors above, though finding experienced devs willing to program full-time in the language was also cited as a factor.

[-]

pdp10@reddit

Since you don't want to run VB6 until the heat death of the universe anyway, the obvious thing to do is to present it from the first line of the advertisement as a job to migrate from VB6 into something reasonable, with the new hire driving.

Then you make the interviews, after establishing bona fides, about how the candidate supposes they would do the job, based on what they know. You'd normally circular-file the obvious architecture astronauts, and shortlist based on how aligned the candidate with the organization's priorities.

It shouldn't be hard to find candidates who would jump at the opportunity to replace a business system, do some presentation-worthy reverse engineering, put a bullet on their CV, even if they despise VB. Especially if they despise VB.

[-]

bemenaker@reddit

The only two potential issues are compliance requirements, and support. If their support refuses to help because it's not official, then you own the liability. For compliance, don't need to explain that one.

Other than that, I agree it will almost certainly work just fine.

[-]

Gadgetman_1@reddit

Honestly, as long as they support 2019, and they can get 2025 support next year, you should consider them a 'pretty good supplier', at least when it comes to servers running specialty SW or support special HW.

I just had to run up a WinXP PC to support some crappy, old HW that's built into a floor. The SW requires a driver that doesn't run on anything newer than XP. I tried... Several times. Spent hours googling, even.

The company that supplied the HW wanted something like $4K to reimage a PC and set up their crappy old SW again.

We have new HW on order now, from a different supplier, but it won't arrive until after Christmas, and intalling will mean jackhammering a concrete floor. (Not my job, luckily)

[-]

Lukage@reddit

DMZ, migrate the server, get the stakeholders to sign liability, move on.

I've got so many Server 2012 or Windows 7 "servers" with EHR stuff on them because the developers just refuse to develop it. Because we all know the devs are long gone and its just some software vendor squeezing the life out of what is left.

[-]

Sudden_Office8710@reddit

Maybe they officially support 2025 🤣 and are skipping 2022 Build stuff in Java and run it through Tomcat so it doesn’t matter what OS you’re running

[-]

Idenwen@reddit

Long testing...? We have to use an BSI tested application that is still only supported up to Server 2019 because they didn't manage to test to end on newer Server Versions.

But hey it still supported on WindowsPOSReady 7 😁

[-]

ludlology@reddit

said said, or there’s just an old kb article that maybe hasn’t been updated in years?

[-]

hpz937@reddit

ha, my point of sale software just started supporting server 2019 this year, some of the supporting software is long since discontinued from companies out of business.

I tend to just install it on the newer versions and run in an unsupported config as I would prefer that to running discontinued versions of windows. The annoying part is they version lock the installer to the version of windows its installing on so I have had to do workarounds.

[-]

Shiveringdev@reddit

“Sorry 3 years is not nearly enough time to support a product, we imagine it will be rectified and supported by late 2028.”

[-]

desmond_koh@reddit

What version of Windows Server do they support? Windows 2022 isn't really that different and Windows is killer for backward compatibility. I cannot fathom why something that ran on Windows Server 2003 wouldn't run on Server 2022 - even if it was 32-bit.

[-]

FalconDriver85@reddit

Considering that my company has a policy that new projects (or software/os refresh of existing projects) cannot target OSs that are already out of mainstream support… well, if that was my case, I would tell them straight away that they could already target 2025.

[-]

stoltzld@reddit

If they don't have any customers willing to beta test for them, maybe not.

[-]

kuahara@reddit

2022 has had 0 known issues since November 2024 when they had it and server 2019 unexpectedly upgrading to 2025.

It is the perfect server OS right now.

2025 on the other hand has a new major issue every month. Just this morning new issue for anyone usingn 2025 for web servers. Your sites and anything depending on HTTP.sys might not load.

Skipping out on 2022 right now is a solid mistake.

[-]

Impressive_Change593@reddit

why wouldn't you go to server 2025 at this point?

[-]

Unnamed-3891@reddit

”Explain to me please, in your own words, what exactly is the purpose of OS vendors making their products available to developers for compatibility testing 6-12 months before public release of said OS?”

[-]

cats_are_the_devil@reddit

One of our vendors just released support for 2019 this past year... Before that we were stuck on 2012R2. They ardently fought when I asked to go to 2019 too. They wanted me to go to 2016. When I pointed out that there's literally no code differences in 2019 from 2016 the phone went silent and I got a well, I guess 2019 would be okay.

[-]

Bordone69@reddit

If it works on 2019 it’s most likely going to work on 2022. However if you are in an environment where you “require” support you’re boned until they say yes. You didn’t say what OS you’re on, I mean if it’s 2016 and that goes EOL in a year I’d start hounding them to know which OS above that they do support. 2019 is better than 2016 though it sick to do two migrations/upgrades.

[-]

ez12a@reddit

Is this an in house or external developer (vendor)? If the latter It's time to look for another developer. That should light a fire under their butts.

[-]

muttmutt2112@reddit

gif

Yeah, that's kind of silly considering Windows 2025 is now live. What do they say their problem is? And why would this affect the developers using the software? I get it that they might not want to migrate Enterprise systems to it, but don't your developers have their own VM farm for this kind of thing?

[-]

joeswindell@reddit

Ask them what DOTNET it targets and laugh at them.

[-]

cryan7755@reddit

First_Time.gif

[-]

Dolapevich@reddit

So.. ¿Have they been testing since 2022 until today? A week should be enough.

[-]

DiggingforPoon@reddit

Windows Server 2022's end of life (EOL) for mainstream support is October 13, 2026...

They got less than a year to get compatible before it sunsets.

[-]

marklein@reddit

Nobody I know cares about mainstream support, only extended support.

[-]

DiggingforPoon@reddit

BUT if a Dev can't even hit that date, you got throw up some serious flags

[-]

marklein@reddit

True. If dev hasn't tested by 6 months after release then they're not going to and they never were.

[-]

Ok_Watercress_9426@reddit

That OS is being skipped

[-]

technobrendo@reddit

And I JUST validated our software for Server 2003, and now THIS

[-]

NorthExcitement4890@reddit

Yeah, that does seem like a while. Honestly, there isn't really a standard; it's kinda up to the developer. But I'd expect most software to be compatible within, like, a year of a major OS release? Maybe push them a little? Or see what other options are out there. It might also be worth checkin' if other users are having the same problem - could give you leverage! Good luck!

[-]

fadeaway222@reddit

Stick with what they want. You may lose support otherwise.

[-]

raip@reddit

Depends on the shop, industry, and software. Some web application, yeah, this is definitely behind. Some CNC Tool or Biomed device? This would be cutting edge.

I'm still supporting some Biomed devices that are running Windows XP (they're off the network now). The device and software are still supported and they're actively testing Windows 10.

[-]

taker223@reddit

> and they're actively testing Windows 10.

which means Windows 11 would likely be OK as well. More than that, there is ESU 1-2-3-4-6 years program for Windows 10.

[-]

raip@reddit

Maybe, but it's a machine worth more than my life to do anything on it that's not officially supported by the vendor. It's off the network so I don't really care about the OS so much, just as long as it works and I can call the vendor to take care of it.

[-]

taker223@reddit

Sounds like a win-win-win , doesn't it?

[-]

cofonseca@reddit

If they don't officially support it by now then they probably have no intention to or it hasn't been prioritized by product management.

No, there are no standards as far as when compatibility should be completed. That is left to the dev team or publisher.

[-]

TrueStoriesIpromise@reddit

It's all about priorities; the manager of the developers hasn't prioritized compatibility testing with 2022.