5 ms·
From the perspective of a long-time Windows user who at one point managed the services my former employer used to keep hosts up to date, this is an excellent de
by mdip 10y ago
From the perspective of a long-time Windows user who at one point managed the services my former employer used to keep hosts up to date, this is an excellent development.
Execution will be important here and IMHO, and it has been done pretty poorly with the past versions of Windows Update/WSUS -- there's a lot of room for improvement. A lot of the benefit will center around how Differential Update is performed. Is this purely at the file level or are they actually delivering the differences in the files (similar to how I read Chrome updates were delivered). The latter would likely involve a lot more processing on the MS/WSUS side, but could dramatically lower bandwidth requirements.
The next piece centers around the WSUS component itself. I found it interesting that they've specifically used the word "Unified". Could there be a future where I, as an ISV, can publish an update/update repository for my application and have patches to my software delivered via update services? It always puzzled me that while I can create an MSI/MSP file for deployment, I could not similarly produce an MSU file for updating. Third-party software has eclipsed the core OS software as far as vulnerability threats and patching it in an enterprise is a nightmare. Most large Windows enterprises use System Center Configuration Manager which is best described as a swiss-army knife for software delivery and at its worst, described as a bunch of unrelated tools that are used to deploy software with different rules depending on what the software is. Standardizing patch delivery, or even simply allowing a third-party to install a patch via WSUS would have made patching browser plug-ins, Adobe Reader and other common software (some of which provide more attack vectors than features) a lot less painful. We maintained a 99.5% patch target with varying range requirements and while we nearly always hit those targets with OS patches, we almost never hit them with these third-party applications. They didn't mention this as a specific feature, and the naming could simply be the marketing department picking a new buzz-word, but I'm hoping this is a future path they're planning on taking.
Personally, I'd like to see updating that's as easy on Windows as it is on my openSuse or Ubunto hosts. Repositories are used to manage the various vendors, updates are packaged the same, standardized and "It Just Works" for the most part.
- JBiserkov 10y agoI completely agree. I just want to point out that Windows Update can deliver application updates and has done so for Office, Silverlight, Defender, Bing something and possibly others. So the capability is there, they "just" need to enable it for 3rd parties. Oops, I used a 4-letter word. I'm sure it's more complicated than that. They sorta did it for Store/UWP apps, but Win32 applications aren't going anywhere anytime soon (I hope!).
- mdip 10y agoI forgot about the Store apps and I remember when that came out, I thought "They got that mostly right". "Mostly Right" from the perspective that there is a standardized software install/repository for applications that also updates them. "Wrong" in that it's following the iOS App Store model rather than the Linux model, has no (real) ability to add third-party, software that hasn't undergone the "Microsoft Stamp of Approval"[0]. And I'll admit that my first thought was that it was the end of any dream that MSUs would be opened up to third-parties. And the Office/Silverlight mix always drove me crazy - it's something you have to separately turn on (and depending on the OS version/kind, you have to click through an additional EULA to activate), so they already had the plumbing in place to accept non-OS update complete with an EULA page and "activation" of that feature. I know there are a lot of issues that have to be addressed to successfully implement this. There are those legal ones -- like the ones they encountered that caused them to differentiate "Windows Update" and "Microsoft Update", as well as adding another attack vector (now the drive-by installs only need to install a new repository and they can deploy malware through updates)[1], as well as probably tens or so that I am not clever enough to think of. [0] Though a quick search for just about anything in the WinStore indicates that Microsoft's standards are really low -- the spam disguised as software in the is a big problem. [1] There's ways around this, though, with existing features already built into Windows. Using a model similar to Intellicode with an internet connection required to verify trust and CRL (you need it to download the update, any way, after all), backed up by a bit more hands-on verification on Microsoft's side (along with a higher fee to pay for that) would cover third-party repositories and for "Internal Enterprise" MSUs -- built by IT staff and deployed via SCCM -- the requirements could be "accept only if it originates from the enterprise CA that the domain trusts" (not other, external, CAs).