Windows 8.1 (sans Update 1) will no longer be supported after June 30 2014

[John Connor]

You must upgrade to update 1 or you will no longer get security updates.

http://www.forbes.com/sites/gordonke...rtner=yahootix

Updated title before anyone freaks out and thinks Windows 8.1 support is ending
-ViRGE

 

[RU482]

why on earth is "Windows 8.1 Update" not just called "Windows 8.2"

/Windows 98 SE comes to mind

 

[postmortemIA]

the thread is duplicate, and Microsoft has rescinded after public outcry
http://blogs.windows.com/windows/b/.../windows-8-1-update-requirement-extended.aspx
extended to June 30 which is also pathetic
I'm not defending Microsoft (the original decision is very poor, in line with everything related to windows 8 that Microsoft has done), just stating the facts.

 

[John Connor]

Where was the OT? I searched. I just knew someone had to have posted it, but I couldn't find it in three pages. Oh well. :shrug:

 

[Mushkins]

So wait, regular old Windows 8 will still be supported until the 2015 cutoff date, but Windows 8.1 will not unless you install 8.1 Update 1?

My brain hurts.

 

[G73S]

So wait, regular old Windows 8 will still be supported until the 2015 cutoff date, but Windows 8.1 will not unless you install 8.1 Update 1?

My brain hurts.

seriously man...what the heck is this!

what are the MS employees smoking?

 

[code65536]

seriously man...what the heck is this!

what are the MS employees smoking?

Why the [heck] are people making a fuss out of this?

8.0 -> 8.1 has a longer transition grace period (2 years) because it's a larger update (and technically considered a new OS, as far as the under-the-hood mechanics are concerned, even though MSFT treats it as a SP for support lifecycle purposes).

8.1 RTM -> 8.1 U1 has a shorter transition period because it's not as big of an update--not that much more than, say, the 8.1 RTM -> 8.1 GA that everyone who got 8.1 before general availability had to put up with (and with zero transition period). Nor do you get transition periods on other monthly updates.

So the question is, what are you smoking? How the hell is it irrational or unexpected for the former to have a longer transition period than the latter?

And it's bloody misleading to consider 8.1 and 8.1 with Update to be two separate products. Tempest, meet teacup.

Be excellent to your fellow poster. And no profanity in the tech forums, please
-ViRGE

 

[Mushkins]

So the question is, what are you smoking? How the hell is it irrational or unexpected for the former to have a longer transition period than the latter?

If i'm running Windows 7 SP1, and I skip a few patch tuesdays or don't have obscure update KB12353225 installed that fixes some obscure .net bug that 99.999% of users will never, ever, ever encounter, Microsoft does not consider my product "out of scope for support."

Think of it on the Enterprise level. Lets say my company migrated everyone to Windows 8.1. Spent millions of dollars updating licensing and custom software. Now you're telling me that I *have to* do another round of software development immediately and regression testing to ensure compatibility and *have to* deploy 8.1 update 1 even if there's no business case to do so because you're going to dump OS support and stop releasing new security patches if I don't? But if I just stuck with regular old Windows 8 my company would be good for another year?

In the world of home users and automatic updates, yeah, who cares. In the world of WSUS, controlled computing environments, and custom software: sorry, this is BS.

 

[code65536]

If i'm running Windows 7 SP1, and I skip a few patch tuesdays or don't have obscure update KB12353225 installed that fixes some obscure .net bug that 99.999% of users will never, ever, ever encounter, Microsoft does not consider my product "out of scope for support."

Think of it on the Enterprise level. Lets say my company migrated everyone to Windows 8.1. Spent millions of dollars updating licensing and custom software. Now you're telling me that I *have to* do another round of software development immediately and regression testing to ensure compatibility and *have to* deploy 8.1 update 1 even if there's no business case to do so because you're going to dump OS support and stop releasing new security patches if I don't? But if I just stuck with regular old Windows 8 my company would be good for another year?

In the world of home users and automatic updates, yeah, who cares. In the world of WSUS, controlled computing environments, and custom software: sorry, this is BS.

And how is this regression testing any different from the regression testing that happens every month for security updates? And yes, security updates have broken compatibility in the past.

I do the same thing, too. I have a test machine that acts as the guinea pig for each month's updates and I don't deploy to other machines until that one checks out okay. I just don't see a practical difference between a large update and a small update--you still need to test the same things in either case.

 

[RampantAndroid]

seriously man...what the heck is this!

what are the MS employees smoking?

Maybe that maintaining machines with AND without the update is a major code fork? All Windows service packs have the same behavior - the SP becomes a prerequisite for all future updates.

 

[Mushkins]

And how is this regression testing any different from the regression testing that happens every month for security updates? And yes, security updates have broken compatibility in the past.

I do the same thing, too. I have a test machine that acts as the guinea pig for each month's updates and I don't deploy to other machines until that one checks out okay. I just don't see a practical difference between a large update and a small update--you still need to test the same things in either case.

Running a single test PC in a lab is not software development regression testing. We're talking about the Enterprise, thousands of workstations with highly regulated configurations and custom application development that integrates with multiple products.

Security patches you push out to a dedicated group of maybe 100 test users who *know* they're test users, are made abreast of the updates being pushed, and report any new problems to the development team. Something as big as a service pack? There's a lot more internal testing that needs to be done to make sure the software moving hundreds of millions of dollars around your business on a daily basis isn't going to break when you push that update out. The service pack could change a UI element or a registry key, or have a mandatory Internet Explorer update rolled into it that *does not* work with your software. Not to mention that the update could break other software that integrates with your software (like Adobe Acrobat).

Updating enterprise level custom applications is not an "oh, cook up a patch and push it out this afternoon" thing. Release timelines and version updates can stretch well over a year. By dropping this bomb, MS is essentially telling any enterprises that are actually running 8.1 that they now have to rush in an upgrade path for all of their proprietary software or lose support. That's just not a thing enterprise level organizations can do, it's like telling a cruise ship it has to do an immediate 180 and head back to port. Its not a jetski takes a whole lot of time and a whole lot of money to turn that boat in another direction. Remember, these are the actual organizations that rely on and engage that support when something the OS is doing does not want to work with their custom application, the people engaging tier 3 developers at MS directly. We're not talking 'Pa Sanders calling in because his windows key wont activate.

Microsoft has *never* suddenly cut off support for a product like this.

 

[code65536]

Running a single test PC in a lab is not software development regression testing. We're talking about the Enterprise, thousands of workstations with highly regulated configurations and custom application development that integrates with multiple products.

Security patches you push out to a dedicated group of maybe 100 test users who *know* they're test users, are made abreast of the updates being pushed, and report any new problems to the development team. Something as big as a service pack? There's a lot more internal testing that needs to be done to make sure the software moving hundreds of millions of dollars around your business on a daily basis isn't going to break when you push that update out. The service pack could change a UI element or a registry key, or have a mandatory Internet Explorer update rolled into it that *does not* work with your software. Not to mention that the update could break other software that integrates with your software (like Adobe Acrobat).

Updating enterprise level custom applications is not an "oh, cook up a patch and push it out this afternoon" thing. Release timelines and version updates can stretch well over a year. By dropping this bomb, MS is essentially telling any enterprises that are actually running 8.1 that they now have to rush in an upgrade path for all of their proprietary software or lose support. That's just not a thing enterprise level organizations can do, it's like telling a cruise ship it has to do an immediate 180 and head back to port. Its not a jetski takes a whole lot of time and a whole lot of money to turn that boat in another direction. Remember, these are the actual organizations that rely on and engage that support when something the OS is doing does not want to work with their custom application, the people engaging tier 3 developers at MS directly. We're not talking 'Pa Sanders calling in because his windows key wont activate.

Microsoft has *never* suddenly cut off support for a product like this.

Yes, this is unprecedented.

Your problem is that you're confusing magnitude of the impact of disruption with the scope of the update. So you have line-of-business software powering your multi-gazillion-dollar business. If it's really that important to you, your tests for each security patch (which, again, have been known to break programs in the past) should be just as intensive as your tests after a service pack. There was a recent security patch that patched something in ntdll.dll--that DLL is loaded by literally every program on the system. If there were gazillions of dollars on the line, I'd test and double-test the hell out of that thing.

If Microsoft does their job and limits the compatibility impact of their changes--and if you are doing your job and doing thorough testing of updates instead of assuming that security patches are something to breeze through, then the difference between this and other monthly updates isn't as nearly as big as you are making it out to be.

 

[Mushkins]

Yes, this is unprecedented.

Your problem is that you're confusing magnitude of the impact of disruption with the scope of the update. So you have line-of-business software powering your multi-gazillion-dollar business. If it's really that important to you, your tests for each security patch (which, again, have been known to break programs in the past) should be just as intensive as your tests after a service pack. There was a recent security patch that patched something in ntdll.dll--that DLL is loaded by literally every program on the system. If there were gazillions of dollars on the line, I'd test and double-test the hell out of that thing.

If Microsoft does their job and limits the compatibility impact of their changes--and if you are doing your job and doing thorough testing of updates instead of assuming that security patches are something to breeze through, then the difference between this and other monthly updates isn't as nearly as big as you are making it out to be.

I'm not sure what to say here other than you're not understanding the difference. Testing a single security patch takes far less time than testing a rollup nearly as big as a service pack. If everything goes well and there's no problems, then yes, it's an identical testing schedule. It's when something *doesn't* go well (like you pointed out, not an uncommon occurrence) where the big difference hits.

If that single security patch causes a conflict in your test group, awesome, you roll back, don't push the patch to the enterprise, and the devs engage Microsoft to fix it/work around it/etc. Or you determine that the risk of not applying that patch is minimal and you don't ever deploy that update because keeping your LOB software working is far more important than some "wifi reliability" update when none of your devices have wireless cards in them anyway.

Here we have a rollup of 100's of minor patches and MS is mandating that you install it to maintain support. Your enterprise doesn't have the option of just rolling back and not installing it, because when you have a problem with some other minor security update six months down the line MS is going to tell you you're up the creek without a paddle and they won't help you because you didn't install this other patch. If any one of those rolled up tweaks or changes causes a problem, you cant just roll that one back, it's a package deal and your continued MS support hinges on it. It could take weeks or months to track down specifically which needle in the haystack is causing the conflict and now you're under the gun to drop all other dev and fix this patch that in all honestly is one you could legitimately get away with never deploying. You're essentially breaking the first rule of troubleshooting/debugging: only change *one* thing at a time between tests to maintain control.

You could argue that most enterprises aren't running 8.1 in the first place so it's a minimal issue, but the real point here is that they're setting a dangerous precedent by accelerating the support cut off dates for their flagship product.

 

[C1]

http://www.pcworld.com/article/2157...chases-of-windows-8-surprising-microsoft.html

 

[VirtualLarry]

http://www.pcworld.com/article/2157...chases-of-windows-8-surprising-microsoft.html

Too many MS back-doors for comfort?

 

[ViRGE]

Too many MS back-doors for comfort?

Nah. China is just being fussy because they want support for XP, even though most of the copies in that country are stolen. The fact that they're using energy savings as one of the reasons to justify it shows how dishonest the whole affair is.

 

[postmortemIA]

Nah. China is just being fussy because they want support for XP, even though most of the copies in that country are stolen. The fact that they're using energy savings as one of the reasons to justify it shows how dishonest the whole affair is.

Energy savings claim is not about xp vs 8. It is about Windows vs. more efficient computing devices that do not run Windows at all (tablets) and such. Or so they do say.

 

[John Connor]

Doesn't China build like one coal-fired power plant a week? I have read or heard that, true I can't say. Energy savings my American azz!

 

[gmaster456]

Sounds like a lot of shit. When there has been public outcry since the developer preview days of Windows 8 almost 3 years ago (First dev preview was Sept. 2011) and they are still pulling crap like this, it makes me wonder if they are actually trying to drop market share. Windows 8 from the get go hasn't made any sense, and the fact that Windows 8 still has over a year of support left while 8.1 sans update 1 only has just over a month is mind boggling. There's a reason people and businesses are still buying Windows 7.

I do not hate Windows 8/8.1 but I am incredibly displeased with the way Microsoft has been handling Windows for the last 3 years.

 

[RampantAndroid]

8.1 sans update 1 only has just over a month is mind boggling. There's a reason people and businesses are still buying Windows 7.

So are you also complaining that Win7 sans SP1 has no support?

 

[gmaster456]

So are you also complaining that Win7 sans SP1 has no support?

No. It's not the same.

It would be as if microsoft came out and said, Windows 7 users are ok, but if you have SP1, you must have update KB12345678 installed or you are SOL.

 

[RampantAndroid]

No. It's not the same.

It would be as if microsoft came out and said, Windows 7 users are ok, but if you have SP1, you must have update KB12345678 installed or you are SOL.

It IS the same. Windows 7 goes unsupported after SP1 comes out, and any scan to windows update will show basically SP1 only, before showing new updates.

SP1 is a rollup of all previous updates, and some extra fixes.

The point is 8.1U1 IS a service package. No different than XPSP2 coming with MASSIVE security changes.

 

[hhhd1]

You seems to have missed the point.

When windows 7 sp1 was released, users with no sp1 where still supported for some time, and not forced to imediatly download a 800MB update to receive any future updates.

The same thing with windows 8.1, .. users not updating their windows 8, are still supported for some time.

 

[Mushkins]

It IS the same. Windows 7 goes unsupported after SP1 comes out, and any scan to windows update will show basically SP1 only, before showing new updates.

SP1 is a rollup of all previous updates, and some extra fixes.

The point is 8.1U1 IS a service package. No different than XPSP2 coming with MASSIVE security changes.

It's not the same, the underlying OS still has support. Lets fast forward to July 1st 2014 to illustrate:

If you have Windows 8 installed: You have support until sometime in 2015.
If you upgrade that installation to Windows 8.1: you lose support
If you upgrade to Windows 8.1 U1: You have ongoing support.

It's inconsistent, and a head scratcher at best.

 

[code65536]

If you have Windows 8 installed: You have support until sometime in 2015.
If you upgrade that installation to Windows 8.1: you lose support
If you upgrade to Windows 8.1 U1: You have ongoing support.

It's inconsistent only if you consider 8.1 to be a different OS than 8.1 U1, which is a stretch.

If everything goes well and there's no problems, then yes, it's an identical testing schedule. It's when something *doesn't* go well (like you pointed out, not an uncommon occurrence) where the big difference hits.

Well, here's to hoping that Microsoft does a better job of maintaining stability. Which is probably made a lot easier when they don't have to account for a gazillion different permutations of patch configurations. Mandating everyone be on the same page instead of letting people pick and choose what mix of component versions probably makes their job of testing and bug-finding easier.

Oh, and did you hear about the time when Microsoft partially (and silently) backported a Windows 8 feature to Windows 7 inside an unrelated critical security update because the feature was in a file that was required for the security update? The feature was only half-working, until months later, when another unrelated security update ended up backporting the other part of the feature.