Replies

Testing testing . . .

Hmmm. I might need to make some changes to my G+ . . .

~ Group "Weekend" ~

I think I am in agreement with abbodi86 . . . Looking at the details of this from our perspective, this is one of the updates we want to take.

We slipstream updates into master images for recovery and for a little over three weeks this process has been prone to fatal errors thrown by DISM for the WinRE.WIM image.

This update looks to have fixed that problem – I have four images — after applying this update first, all four slip-streamed the last rollup without issue this morning for the first time in almost a month. Without documentation it’s hard to say (yet) that this is a specific fix for the problem, but it sure looks like it could be.

~ Group "Weekend" ~

On top of this, one of the largest ISP’s in the US is having stability issues, affecting both home and SMB connections. It’s been like this since about 2 AM Mountain time last night.

I remoted into all of my clients this morning and set the WSUS service to disabled for today. They are all set to sync in the wee hours every night. I have several days before client workstations start complaining. Expecting to turn all the WSUS servers back on later this week, but by then we’ll have a much better idea of what to expect, allow, block or run away screaming “I quit!”

Woody, thanks again for providing this forum – it’s been really valuable in making decisions on what approve for updates. And yes, your book is ordered.

~ Group "Weekend" ~

So much for the coincidence regarding patch failure on multi-drive systems. one of my test machines with two physical drives just succeeded at applying this patch. The others are still failing today though . . . no rhyme or reason to it that I can discern.

~ Group "Weekend" ~

This may be a total coincidence . . . but I’m experiencing a pattern on my test machines when trying to install 14393.222 aka KB 3194496.

So far this week, the test machines with a single hard drive and ONLY a C: drive partition have installed KB 3194496 without issue.

On the other hand, all of my multi-drive or multi-partitioned workstations have failed this update during the boot up segment of the patch process. They roll back, reboot again, then after logging in attempt to install again. None of them have succeeded yet.

Even more aggravating is that turning off the release/slow/fast preview ring for 5 days has not stopped these machines from attempting to install this patch over and over again.

Can anyone else corroborate this behavior of single drive versus multi-drive patch success or failure?

~ Group "Weekend" ~

I am fairly pensive about October.

At all my clients, we use WSUS to control patch releases. Over the years it’s not been uncommon for a specific patch to break software that is critical for the Engineering and Architectural community. Some would say this is the fault of the third party software vendors, and they would be correct . . . but the the fact remains that for these people to do their daily jobs, that software has to work.

So we test patches the day of release, and if we have problems, we block the patch that induced the issue. This has happened on a rough average of twice a year over the last ten years.

With the new patch model rolling out for Windows 7 in October, I am pretty sure this method is going to be much easier – if the patch breaks something we roll the whole patch back.

It’s going to be harder though, if the rollup patches install older patches we already blocked.

And it’s going to be less secure – which is really bothering me – because now we’ll be blocking MORE critical fixes that got lumped in with less critical repairs.

And the following months, the rollup will attempt again to install stuff we had to block.

Really not sure how this is going to work yet – eventually our software vendors fix their stuff to be reliable on up to date patches systems, but it can take them months.

~ Group "Weekend" ~

Just to clarify, System Restore is what I am talking about above. The System Image that you can optionally snap during Windows Backups is – in my experience – highly reliable. Just in case anyone gets confused between the two. 😀

~ Group "Weekend" ~

When SR works, it works very well – it’s saved my bacon many times. But you cannot trust it to work every time, so you use it as the last resort before committing to a re-image/update/re-install job.

Cases where it usually succeeds: bad drivers that BSOD the system, odd third party software that broke DLL hell rules, non kernel patches from MS.

Cases where it almost always fails: MS patches that touch the kernel. Malware/Virii …

~ Group "Weekend" ~

I have what looks like the same bug that hit me the day I installed the Win10 Mobile 1607 update on my phone . . . it munged the microSD card on that phone into a RAW partition, which still reads fine when mounted into a card reader on Win7, but not on other Win10 AU 1607 desktops. Been waiting to see if the delayed “fix” will restore the card to normal use (holding off reformatting it so I can test.)

~ Group "Weekend" ~

I believe we have a short migration period for recompiling our stuff per KB3181759 – but they are not clear what the forgiveness time will be. Could be short.

~ Group "Weekend" ~

This has been a known issue for over a year now.

I put together a list of the initial patches that need to be installed manually before continuing with the normal WU on a new “clean” install a few months ago. You are welcome to refer to it as needed.

https://networkdefend.blogspot.com/2016/05/fix-windows-7-updates-stalling-out-or.html

~ Group "Weekend" ~

– @ Anon re KB971033

That was not quite the same as the KMS style check-in that Leo reported. Then, your system would check against certain system changes that might indicate a hacked activation, and there was suspicion that there might have been a blacklisted set of keys . . . although MS likely stopped doing that. If that system never ever check in, it would happily continue running.

Think of it as a passive check when possible.

Today’s reveal indicates that known good active licenses might require an activation check to stay happy. A non-passive check if you will.

KMS for my clients requires a regular check-in from all clients to keep Windows Enterprise, the Office suite, “happy” . . . it can be hosted on site for large networks, or in the cloud, or by MS.

More info:
Understanding KMS
https://technet.microsoft.com/en-us/library/ff793434.aspx

~ Group "Weekend" ~

If this turns out to be confirmed, then a rare use case becomes very difficult: Long term offline workstations that act as either dedicated controllers (where updates are feared) or field working computers. I know that’s a vanishing breed, but I still have to support two of them.

~ Group "Weekend" ~

Woody, we’ve got a new-ish bug on 1607 that impacts small business networks.

Users trying to create or rename folders on a server share from Win10-1607 getting errors, timeouts, or it works but take several minutes for one folder to take its new name.

Simple solution seems to be disabling the Windows Search service on the Server . . . ugh.

Full problem and description here:
https://networkdefend.blogspot.com/2016/09/fix-windows-10-error-0x8007003b-when.html

~ Group "Weekend" ~

(Blush) . . . I really can’t take original credit for what should be considered a bug. Pretty sure there were others that found it an hour or so earlier than I did when I did a WinDif on registry hive dumps between a working profile and a non-working profile re: Cortana.

Anyway, here is what I “think” the differences are for the aforementioned registry key values.

At the profile hive level: (HKCU)

CanCortanaBeEnabled appears to be a hacky method (by MS) to store an internal check setting that controls whether the user can enable/activate Cortana. (This is part speculation . . .) I think it’s set to ‘1’ when a Local Only user links to a MS Account in account settings – or when a new profile is created directly with a MS Account. On a new profile that meets the requirements of using an online MS Account this setting appears to trigger the Cortana Setup dialog/wizard when the search bar is clicked.

AllowCortana is the correct key to enable/disable Cortana for that profile – which only works on enable if certain other requirements are met — such as the user is logged on with a linked or direct MS account and whether Bing Search is enabled.

BingSearchEnable is the key that was discovered to be set to the incorrect value during the upgrade from 1511 to 1607 on some profiles (no idea why yet) that “broke” Cortana. As far as I can tell, this is a BUG, and is not the “official” supported method to turn Cortana off/on. But it’s tied into the fact that Microsoft disabled the ability for Cortana to use any alternate search engine other than Bing. (I smell an EU antitrust suit in the making here.)

As always I highly recommend the use of local machine or domain group policy to make any of these changes, which I know leaves Home editions in the dark. Hack the registry at your own risk folks. Leaving the umbrella of officially supported methods can lead to future unexpected (and very difficult to diagnose) problems on patch days.

Off topic, but because I am still peeved about something:

What can we do to pressure MS to restore the ability to turn off Consumer Experiences (aka pushing unwanted random crap-ware tiles onto a users start menu) in Windows 10 Pro by Group Policy?

~ Group "Weekend" ~