On a server by server basis, we need to make decisions on whether or not to allow individual patches/updates to be installed. In a typical scenario, this would be because of things like .NET version compatibility (or rather, incompatibility) with applications such as SharePoint, Exchange, Skype For Business and line-of-business applications.

We want to be able to approve patches in WSUS generally, but then ignore or just delay those on a particular server on a case-by-case basis, according to the needs of various applications. We used to be able to run Windows Update, see the list of patches for that server, then de-select any that we didn't want at that time.

Installing a Windows Server 2016 cumulative update (e.g. after setting up a new server) can take pretty long. After a few minutes, the unchanging message "Getting Windows ready / Don't turn off your computer", despite its looping dots, stops inspiring confidence that progress is being made.

Monitoring %windir%\Logs\CBS\CBS.log helps slightly, at least until "CommitPackagesState: Started persisting state of packages".

I would therefore request that
* on Windows Server, and optionally on Windows 10 as a configurable option, the "Getting Windows ready" screen shows additional detail, similar to the output in CBS.log (e.g. "processing package 1564/7144 for KB4025339")
* if possible, CBS's persisting of packages be logged more verbosely to make progress more obvious

The monthly Windows Update rollup releases greatly sped up creating a machine from scratch, upgrading an image to latest, and just patching machines. These rollups ceased shipping in December 2014. There has been no rollup release in over 14 months for the current latest production server OS from Microsoft.

This translates to over a hundred updates (about 150 past the last rollup) and a few reboots, multiple ngen passes for .Net that aren't needed. Only the last of these time-costly operations needs to run, a handy side-effect the rollup has.

Instead on thousands of tens of thousands of sysadmins spending a great deal more time patching or additional time slipstreaming image deploys, it would be a much better use of time if Microsoft resumed shipping these very useful rollups.

These updates should also be listed in a single place, not the blogs people relied on before. Microsoft should house the source of truth here.

Related: can we add a category to this UserVoice for patching/updated or similar?

Hi All,

it looks like that ndp46-kb4033990-x64 one of the Updates included in
KB4035036-August 2017 Preview of the Quality Rollups for the .NET Framework 3.5.1, 4.5.2, 4.6, 4.6.1, 4.6.2, and 4.7 for Windows 7 SP1 and Windows Server 2008 R2 SP1 (https://support.microsoft.com/kb/4035036)

patches the wrong .NET 4.6.1 DLLs on a Windows 2008 R2 Server.

Registry sill says .NET 4.6.1 (394271) is installed, but

the new patched files have a signature from 4.7.
For e.g: mscorlib.dll has after the patch 4.7.2106.0.

There a some third-party products, that have problems with .NET 4.7, like OpenEdge Progress.(https://knowledgebase.progress.com/articles/Article/gui-net-application-crashes-after-net-upgrade-to-4-7).

And after installing KB4035036, we have the same issues as if we installed .NET 4.7 directly.

I know that KB4035036 is only a preview, but i hope that this issue doesn`t go online in the september production updates.

After installing update KB3213986 on Server 2016 Desktop Experience, a failed logon is logged every time the BITS service is started.

Failed Logon Event:
Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 2/27/2017 1:27:10 PM
Event ID: 4625
Task Category: Logon
Level: Information
Keywords: Audit Failure
User: N/A
Computer: PLB-DXX-TP01.dev-products.local
Description:
An account failed to log on.

Subject:

Security ID:        SYSTEM

Account Name:       PLB-DXX-TP01$

Account Domain:     DEV-PRODUCTS

Logon ID:       0x3E7

Logon Type: 5

Account For Which Logon Failed:

Security ID:        NULL SID

Account Name:       -

Account Domain:     -

Failure Information:

Failure Reason:     An Error occured during Logon.

Status:         0xC0000073

Sub Status:     0xC0000073

Process Information:

Caller Process ID:  0x49c

Caller Process Name:    C:\Windows\System32\svchost.exe

Network Information:

Workstation Name:   -

Source Network Address: -

Source Port:        -

Detailed Authentication Information:

Logon Process:      Advapi  

Authentication Package: Negotiate

Transited Services: -

Package Name (NTLM only):   -

Key Length:     0

Removing the update resolves the issue. I've tested this on multiple fresh installs of Windows Server 2016 from media.

The failed logon is problematic because it triggers false-positives in our monitoring solutions.

The issue is easily reproducible.

Consider having the entire Component-based Servicing Infrastructure running from RAM if available and as far as is possible.

I've done extensive analysis and testing to what CSI is actually doing. While no doubt it is much much more secure/reliable then for example WinXP updates were, it does have a significant drawback, which hurts even more in Virtualization. Let me ask you: What do you commonly have enough of in Virtualization ? CPU ? Yes, Mem. ? Usually, also yes, Network ? Usually, yes, Disk I/O ? NO. Usually, disk I/O is the common bottleneck in most Virtualization-environments I've come across by far. So while it would be easy to scale up no. of VMs per host based on CPU/Mem./Network, it usually gets bottlenecked because of limited available disk I/O. Not even so much under normal running conditions, but especially when doing servicing, aka Windows Updates/DISM. In general, the current CSI does a very bad job at this simply because everything seems to be totally disk-based. Every stage from detection to download to staging to comparing, to installing, to pre-shutdown and post-startup ("Working on updates", etc.) is totally disk-based and as such heavily bound by the total available disk I/O on a host (or SOFS/etc.). This greatly impairs otherwise possible upscaling of no. of VMs per host. I've calculated roughly that to deploy 1 Gbyte of updates you will get over 11 Gbytes of total disk-churn. Hey, this is talking 1 (one!) VM. If excluding the downloads, you're still, generally speaking, talking about a factor 5-6 disk-churn ! -> Which could have been largely avoided if most of the entire CSI would be running from RAM. I've developed a script which employs a dynamic ramdisk in combi with alot of folder-redirecting (reparsepoints) to get most of CSI running from RAM, saving state to ramdisk at startup and restoring state at shutdown, and as such have been able to reduce disk-churn by a factor 3 and deployment-time from 3 h. to 2 h. for 204 updates so far! The script though is an ongoing experiment as I find more and more stuff that I can redirect to ramdisk to speed up this whole process, reducing disk-churn along the way. Since it's a dynamic ramdisk, using it in combi with Dynamic Memory means a VM will grow for around 4 Gbytes during the whole process, but after it's done everything gets returned to the OS by the dynamic Ramdisk, which in turn 5 min. later returns it back to the host for use elsewhere. The current new way of doing major upgrades is in my opinion also just a big miss! How about "servicing" 50 or a 100 or even more systems with that simultaneously ? What kind of disk-subsystem would you need for that, just to be able to keep up with that ? From my testing so far I've seen major improvements just by having all these processes done from ram(disk), thereby increasing chance of corruption, no doubt, but why not making it one huge "major" transaction as such then ? If it fails somewhere, the whole thing gets undone/ignored/discarded and has to be started from scratch (in ram), but if it succeeds, it would enormously speed up everything involved, so also installing roles/features to name something (DISM), not to mention needed IOPs and as such (using tiered storage or just SSDs) alot of unneccesary wear. Having a Replica ? Calculate your savings from this times 2. Oh, what about backup ? It certainly is a best practice, right ? Calculate x3. So, roughly, having Replica and backups, to install 1Gbyte of updates on 1 VM costs you 1 * (factor of 5) * 3 = 15 Gbytes. Employing CBT do you ? Okay, then 1 * (factor of 5) * 2 + 1 = 11 Gbytes. Doing most in RAM would mean you deploy 1Gbytes of updates which only writes the end-result = 1 Gb, so 1*3 = 3Gb. Per VM and one large update-run you thus save roughly 11 Gbytes of wear and tear of your machines (Replica-network gets considerably less aswell ofcourse). Now please recount when having 100 VMs to be serviced/replicated/backed up !

Each month for the last 2 years, a manual check of Microsoft Update reveals a lot of what I call junk or unwanted updates. For example, why in the earth should a Win2008/2012 server receive updates related to Surface3? Or why is some obscure critical updates presented on an English Server OS, when the fix is for some excotic Chinese languge setting? If somebody would really ready all the KB articles that follow each month, you would be really astonished over the sheer number of unwanted updates. And it takes time to download, deploy and install. Not a problem if you have 1 or 2 servers, but when you have 1000's it is a problem.