Way back in December 2024, Microsoft released the ConfigMgr Tech Preview 2411 release. It wasn’t long after that before the India-based team maintaining ConfigMgr was either laid off or reassigned to other things, so not surprisingly there was then an announcement in November 2025 that laid out a new annual release cycle for ConfigMgr. Reading between the lines, this is part of Microsoft’s ongoing emphasis on the cloud, and ConfigMgr doesn’t have a role to play in that future. Does this mean that ConfigMgr is dead? More like “on life support” with mimimal investments and an uncertain future.
But that’s not really news. What caught me off guard was a question and answer in the comments of the release cycle blog post:

Well OK then. So those like me running labs with TP2411 are running out of time: that release was good for a year, with the countdown starting on the day that you installed it. I didn’t install it right away, so I still have 84 days left, but it’s officially a dead-end. At the end of those 84 days, I’ll be forced to reinstall.
This TP2411 release is already behind on the times, as it doesn’t include the changes (mostly fixes) that have been made in ConfigMgr 2503 and 2509, so it makes sense to “upgrade” (which really means “completely reinstall and reconfigure, and find a product key from somewhere) sooner rather than later. Add that to the to-do list…
p.s. Of course Microsoft hasn’t updated the eval media, so it’s back on 2403. But at least you can install it and then update through the console to 2509. But for future reference, if you want to download the 2509 media you can get it from https://go.microsoft.com/fwlink/?linkid=2341103.
p.p.s. That doesn’t mean the process is easy. It sounds easy enough: uninstall the tech preview, then install the latest baseline build. Except the uninstall doesn’t clean up the SQL Service Broker definition, and the new install won’t install to the same instance if there are other databases on the instance — SCCM doesn’t want to share. OK, create a new instance, install to that, right? Well, that’s where the SQL Server Broker problem comes in. At the end of the install process, it tries to create a new SQL Server Broker in the new instance, but that uses the same 4022 port that the old database is still using, so it fails and leaves your install incomplete, so you have to uninstall and start over. But in case you need to manually clean this up:
- Connect to the old database in SQL Management Studio.
- Run a query to “select * from sys.service_broker_endpoints” to confirm that the ConfigMgrEndpoint endpoint is defined.
- Use “ALTER ENDPOINT ConfigMgrEndpoint STATE=STOPPED” and then “DROP ENDPOINT ConfigMgrEndpoint” to clean it up.
Or you could just specify a different port…






Leave a comment