Posted by: Ed Tittel
when relevant content is
added and updated.
Late last week, Microsoft pushed out a batch of new fixes for the Windows 8.1 Preview for x86, x64, and RT versions. This comes about a week after Patch Tuesday, and includes five fixes — one labeled “Important,” with four others “Recommended” — that are separate and distinct from the Patch Tuesday fixes that appeared on July 9. This signals an apparent departure from Microsoft’s prior practice of holding most patches and fixes until the second Tuesday of the month (aka “Patch Tuesday”). According to Ed Bott’s recent story for ZDnet, Microsoft calls this a “rapid update cadence.”
More frequent updates mean more time spent evaluating updates, and probably also more time in the test lab, checking for adverse or unwanted side effects.
That story also provides some interesting information about the specific updates pushed, which include an app compatibility roll-up, plus a welcome fix that addresses jerky scrolling behavior in the Windows 8.1 Preview (see story for details). But what I find interesting about this approach is that it apparently signals a move from a “periodic update” regime to a “as needed” update regime. This is all well and good for individual and small business operations where updates will be applied automatically in most such situations. But this may mean more work for larger organizations and enterprises, where updates must be tested and vetted, and only those that don’t cause problems integrated into periodic pushes dictated by internal schedules — typically, on a once-a-month or a once-per-quarter planned refresh/update basis, over a three-day weekend or holiday if possible, so as to minimize potential productivity impacts.
What does this signify for enterprise admins, especially those who manage change control for updates, patches, and fixes? Let me speculate that it will mean more frequent attention to incoming patches and fixes, and perhaps also more frequent scheduling for test lab work to assess the need for and impact of pending patches and updates. I doubt that it can affect internal refresh/update cycles themselves, but it will have at least some impact on the activities that lead up to approval of pending changes for each “next cycle” and will probably require more time and effort in the test lab to keep playing catch-up.