Windows Enterprise Desktop


April 3, 2019  10:59 AM

Win10 KB4490481 Could Leave 6 Reclaimable Packages Behind

Ed Tittel Ed Tittel Profile: Ed Tittel
DISM, Windows 10, Windows Updates

Just yesterday, MS released a new cumulative update (CU) — namely, KB4490481. For the first time in my experience, Win10 KB4490481 leaves 6 reclaimable packages behind. What does this mean? After you install this update, run DISM /online /cleanup-image /analyzecomponentstore You’ll see something that looks like this (captured inside a PowerShell administrator session):

Win10 KB4490481 Leaves 6 Reclaimable Packages Behind.6pckgs

Notice the line in the command output near the bottom that reads “Number of reclaimable packages: 6.” In my experience, this sets a new record for detritus in the wake of a Windows 10 CU.

Win10 KB4490481 Leaves 6 Reclaimable Packages Behind. So What?

As I recite in my previous blog post, cleanup using DISM /online /cleanup-image /startcomponentcleanup after this CU can pay big dividends. Notice the size of the item in the preceding screen capture: Backups and Disable Features. At 8.94 GB, all that goes bye-bye after the cleanup. My typical cleanup results came in around 9.5 GB, so there’s another 0.54 GB that gets whisked away from other component store nooks and crannies, too.

As post-CU clean-ups go, this one’s a biggie. In fact, it’s the biggest one I can ever remember seeing. Especially for those running Win10 1809 on small-footprint devices (tablets or laptops with limited storage of 32 or 64 GB) this maneuver seems more mandatory than optional. But even for those with system/boot SSDs of 512 GB or larger, a 9+ GB cleanup still remains significant. And, should you run into the same error I encountered when working this through on the Release Preview before it hit general distribution, my previous blog post explains how to fix that, too. Alas, though, if you’re updating only from 17763.379 to 17763.404, you’ll find only 1 reclaimable package when you run /AnalyzeComponentStore. This will recover upwards of 1.6 GB instead (because there are many fewer packages involved). YMMV, as they say on the Internet.

If all this talk about component store cleanup piques your interest — and I hope it does — here’s a great resource for further exploration. Shawn Brink over at TenForums offers a great tutorial on this stuff. Prosaically enough, it’s entitled “Clean Up Component Store (WinSxS folder) in Windows 10.” It goes into and illustrates all the relevant DISM commands in detail. It’s worth a read-through. You can even use it as a step-by-step guide to work through these commands on your own Win10 PCs. Check it out!

April 2, 2019  12:43 PM

Second Reboot Fixes DISM StartComponentCleanup Error 6824

Ed Tittel Ed Tittel Profile: Ed Tittel

Generally speaking, whenever one installs a Win10 cumulative update (CU), it raises the possibility that component store cleanup should follow. How do you find out if cleanup is needed? The command DISM /Online /Cleanup-Image /AnalyzeComponentStore when run, will recommend for or against cleanup. Lately, I’ve observed that trying to run that cleanup immediately after the restart that CU install requires doesn’t always work. Generally, a second reboot fixes DISM StartComponentCleanup nicely.

In fact, I’ll show a sequence of PowerShell screencaps that show this in action. [WARNING! Completing this cleanup often takes a long time — over a half hour on my Surface Pro 3, for example.]

How to Tell If a Second Reboot Fixes DISM StartComponentCleanup

You’ll know if you need to try a second reboot because of the error message that DISM produces for that particular command. It appears in the following screenshot:

Second Reboot Fixes DISM StartComponentCleanup.error

Notice the 6824 error at bottom: “The operation cannot be performed because another transaction is depending on that fact that this property will not change.”
[Click image for full-sized view.]

Apparently, a Reboot Clears the Pending Mystery Transaction

MS Docs labels the 6824 error code as ERROR_CANT_BREAK_TRANSACTIONAL_DEPENDENCY. As far as I can tell, it means that some other OS transaction is pending. Before DISM StartComponentCleanup can do its thing, that transaction must complete. I  can’t yet identify that other pending transaction. But it’s pretty clear that a second reboot handles and clears it. The second reboot lets the previously failed DISM command run unimpeded.

If you ever find yourself in this boat after installing a CU, try another reboot. It’s worked for me every time I’ve gotten the 6824 error code instead of package cleanup. It should probably work for you, too.

Here’s where I wound up with my successful cleanup, after the second reboot. Please note that after the DISM command ran for 30 minutes it got stuck on 94% complete. So I closed the PowerShell window, opened it again, and re-ran the same command. What you see below shows the strange results that ended in success almost immediately. I ran another /AnalyzeComponentStore command to get “post-cleanup” sizes. The component store dropped from 15.93 GB to 6.52 GB (HUGE: 9.42 GB), with attendant size reductions in actual size, primarily from backups and disabled features. It’s pretty unusual to see six (6) reclaimable packages after a CU, so I expected — and got — significant cleanup. Good stuff!

Second Reboot Fixes DISM StartComponentCleanup Error.after

[Click image for full-sized view.]


March 30, 2019  11:06 AM

WakeMeOnLan Provides Quick Compact Net Survey

Ed Tittel Ed Tittel Profile: Ed Tittel
Network management, Network Scanners, Wake on LAN, Windows 10

Sometimes, accidental uses of software outstrip intended uses. Let me explain: my son’s PC is up in his bedroom. It’s about as far from my office as you can get in my house. Because I’m always tinkering with the PCs at home, I like to remote into them. But he’s away at school most weekdays, and out and about on weekends. So we’ve got his machine configured to go into deep sleep (S3/S5) while he’s not using it. Thus, I found myself learning how to enable the Magic Packet for Wake-On-LAN (WOL) so I can start that machine up from my office, and then get an RDP session going. In researching the topic, I stumbled across Nir Sofer/Nirsoft’s excellent WakeMeOnLan utility. In using that utility I realized it shows a list of all active IP addresses on the LAN, which makes it superior as a simple LAN scanner as well. Not only will it let me do what I want, WakeMeOnLan provides quick compact net survey. Here’s what that looks like:

WakeMeOnLan Provides Quick Compact Net Survey.output

Not only does it offer remote wake-up/shutdown, it also shows every device on the LAN (including our Alexa, printers, and even my otherwise unlabeled WAP). Good stuff!
[Click image for full-sized view.]

Why WakeMeOnLan Provides Quick Compact Net Survey Is a Good Thing

I’ve tried plenty of other LAN survey tools. But most of them list the entire address range from 0 to 254 with a bunch of empty entries when no device is mapped to an open IP address. WakeMeOnLan shows only occupied addresses, and thus also, shows me only what I want to see. Because I use DHCP device addresses will occasionally change. That makes this tool especially helpful when that happens to one or more of my network-attached printers, because that means I have to use the new IP address to resolve driver issues.

Others may find this tool likewise helpful and informative. Like most of Sofer’s utilties, it’s quick, capable, and easy to use. Check it out!


March 29, 2019  9:50 AM

Win10 1809 Designated for Broad Deployment

Ed Tittel Ed Tittel Profile: Ed Tittel

Man, I have to laugh! Just yesterday (March 28), John Wilcox in the MS Windows IT Pro Blog posted that “version 1809 has transitioned to broad deployment.” This occurs, just as the buzz about 1903 is starting to escalate. In fact, people are speculating that it could show up as early as next month (April 2019). Of course, we know that MS has designated this next release as 19H1. This means that it could show up as late as June 30, and still hit its stated mark. Indeed,  I have to believe that with Win10 1809 designated for broad deployment, a later date now seems more likely than an earlier one. This could buy MS some apparently much-needed time, because the latest Slow Ring release (Build 18362) has been withdrawn from circulation. The latest release is waiting on pending bugfixes related to updates for Build 18356.16.

Win10 1809 Designated for Broad Deployment.graphic

This cheerfully ominous connected cloud graphic adorns Mr. Wilcox’s proclamation of “broad deployment” for 1809.

What Does Win10 Designated for Broad Deployment Really Mean?

In the afore-linked blog post, Mr. Wilcox explains that 1809 transitions to this state “based on the data and feedback we’ve received from consumers, OEMs, ISVs, partners, and commercial customers.” My interpretation is that recent telemetry has showed fewer issues. I’d guess, too, that the volume of complaints or issues reported from those constituencies has dropped to normal levels. Thus, MS has put 1809 into full general release, 5.5 months after its initial foray. It emerged on a Tuesday; the following Friday, it disappeared (11/13 and 16, respectively).

Wilcox goes on to report that “Windows 10 Enterprise and Windows 10 Education, version 1809 will be serviced for 30 months from its November 13th release date.” Given that my last blog post featured speculation that MS is hopeful that users might skip from 1803 directly to 19H1/1903, I wonder how many Enterprise and Education users will adopt the 1809 feature update anyway. That same post also reported shockingly low uptake of 1809 at this point in the release cycle. I wonder if the transition to “broad deployment” changes that current and painfully slow uptick at all. We’ll see!


March 27, 2019  1:25 PM

AdDuplex Tells Interesting 1809 Story

Ed Tittel Ed Tittel Profile: Ed Tittel
technology adoption, Windows 10, Windows Upgrades

The March 2019 AdDuplex Report is out, and it tells and interesting and possibly depressing story about Windows 10 1809. The 1809 rollout has been bumpy, to say the least. As 1903 looms ahead, only 26.4% of PCs under the AdDuplex purview are running 1809. Compare this to 1803, which runs on 66.3% of that population. This leads AdDuplex to assert that “Microsoft seems to be giving up on [1809] … in favor of upgrading users straight to the next version.” I agree. It’s also why I say that AdDuplex tells interesting 1809 story.

AdDuplex Tells Interesting 1809 Story.win10dist

Note that 1803 still outweighs 1809 by a 2.5:1 ratio, almost six months after its initial release and subsequent withdrawal.
[Source: AdDuplex. Click image for full-sized view.]

The Data that Drives AdDuplex Tells Interesting 1809 Story

Lots of people, including Paul Thurrott, have raised issues with AdDuplex’s numbers. They rightly observe that those numbers don’t really represent the complete population of Windows users. As AdDuplex itself states “This report is based on data collected from around 5,000 Windows Store apps running AdDuplex SDK v.2 (and higher). The raw data analyzed was collected over the day of March 26th, 2019 (UTC time) unless otherwise stated.” They also note the total PCs involved in this sample is “more than 100,000.”  That’s only a tiny fraction of the 800 M copies of Windows 10 in active use right now (0.0125 %).

Normally, I’d quibble with AdDuplex numbers for those selfsame reasons. But this time, I think they may be onto something valid. That’s because it’s the proportions that matter most, not the absolute numbers. If a majority of Windows 10 users is running 1803, with just over a quarter of them on 1809, this is interesting. It also follows logically that MS would try to upgrade those users to 1903. This lets them skip the apparently still problematic 1809 release along the way.

I’ve been following Windows professionally since 3.11 was released in 1992. Over the past 26 years, I can’t remember too many other Windows releases with a similar slow and unwanted uptake profile. Only Windows ME, Vista, and the original Windows 8.0 release are in this hunt. In my opinion, only Windows ME has had more bad press and more bad cess. This shows an unexpected benefit of the twice-yearly feature upgrade cycle, I guess. That is, no matter how bad or problem-ridden a feature upgrade may be, we don’t have to live with it longer than six months unless we choose to do so.

[Here’s a shout-out to Shawn Brink at TenForums, whose post “AdDuplex Windows 10 Report for March 2019 now available” brought this to my attention. Thanks, guy!]

 


March 26, 2019  10:59 AM

Win10 1903 Policy Handles Automatic Updates and Restarts

Ed Tittel Ed Tittel Profile: Ed Tittel
Group Policy Editor, Group Policy management, Policy, Windows 10, Windows Updates

For the past few days I’ve been reading about a new Group Policy setting in 1903. Here’s the deal: A new Win10 1903 policy handles automatic updates and restarts. As is sometimes the case, I had a little trouble running the specifics down. Good old Martin Brinkmann, at Ghacks.net, came across with those. Thanks to his excellent description and depiction of the new policy, I was able to find it for myself. Open gpedit.msc, then navigate thusly: Computer Configuration → Administrative Templates → Windows Components → Windows Update. Within that policy folder, you’ll find an entry named “Specify deadlines for automatic updates and restarts” as shown here:
Win10 1903 Policy Handles Automatic Updates and Restarts.gpeitem

Once you know where to look, the policy setting is easy to find, enable, and configure.
[Click image for full-sized view.]

What Win10 1903 Policy Handles Automatic Updates and Restarts Actually DOES

To access this setting, click the link in the middle column that reads “Edit policy setting.” (This is a mock link; it doesn’t actually work.) When you do that the related policy setting window opens as shown below. First, you must click the “Enabled” radio button at the top left, to turn this policy on. Then you can manipulate the settings in the Options: pane at the lower left.

Win10 1903 Policy Handles Automatic Updates and Restarts.options

Once you enable this policy setting, the defaults show up in the Options tab.
[Click image for full-sized view.]

What Are Your Options Here?

You can set the deferral period for quality updates (stuff from WU other than feature updates) anywhere from 2 to 30 days. Ditto for feature updates. The grace period defines an interval between when that update is applied (either kind) and when the device will be restarted, forcibly and automatically. This value may be set anywhere from 0 (immediately following update installation) to 7 days. There’s also a checkbox that reads “Don’t auto-restart until end of grade period” that admins can choose if they’re so inclined.

For smaller businesses that use Windows Update, this group policy could be helpful. Most larger organizations manage their own update intervals and windows quite carefully and closely themselves, however. It’s unlikely to have much impact on organizations with formal change control and related update procedures already in place.

[Note: here’s a shout-out to Martin Brinkmann at Ghacks.net for his  March 21 story entitled “Windows 10 version 1903: new Windows Update policy.” It was the only story on this topic I found online that included all the details necessary to find and play with this new policy setting. Vielen Dank, Herr Brinkmann!]


March 25, 2019  2:06 PM

KB4465065 Offers New Microcode Fixes

Ed Tittel Ed Tittel Profile: Ed Tittel
firmware update, Windows 10, Windows Updates

On March 19, Microsoft issued a new and comprehensive set of microcode fixes for Intel CPUs. These go back to Ivy Bridge (and perhaps earlier) and address potential issues on all of my PCs. They may do likewise for yours. In fact, KB4465065 offers new microcode fixes for three specific vulnerabilities. These are CVE-2017-5754 [rogue data cache load], CVE-2018-3639 [speculative store bypass] and CVE-2018-3620 [L1 terminal fault]. I’ll show “before” and “after” screencaps from the Get-SpeculationControlSettings applet in PowerShell for the specifics.

KB4465065 Offers New Microcode Fixes.before

The red arrows point to various key state indicators from the Get-SpeculationControlSettings applet prior to installing the latest microcode fixes.
[Click image for full-sized view].

The red arrows point to various key state indicators from the Get-SpeculationControlSettings applet after installing the latest microcode fixes.
Note the extra line of text in the speculative store bypass area, and the enablement of all 3 microcode fixes in the Windows OS.
[Click image for full-sized view].

If KB4465065 Offers New Microcode Fixes, Is That a Good Thing?

There can be a performance impact on some PCs when enabling various microcode fixes. All you can do is to try them out on a test machine, then measure and observe their consequences. If you need to undo those changes, you’ll have to flash a modified firmware onto the affected PC(s). The best way to do that is to make a firmware snapshot before applying KB4465065, so you’ll have something to roll back to if you don’t like the outcomes. See this SuperUser article “Can Intel updates be rolled back?” for more discussion. You’ll need to work with system or motherboard utilities to make UEFI/firmware snapshots as well, and understand how to apply them properly. Only then can you undo those changes.

For information on downloading and using the Get-SpeculationControlSettings applet, please consult the PowerShell Scripting center. You’ll find what you need in an item entitled “Speculation Control Validation PowerShell Script” (it includes a download link, and instructions on how to use this tool).

The View from Up Close and Personal

I have installed and am using this fix on a variety of machines include one Ivy Bridge PC, three Haswell PCs, and other, newer Intel Processors (SkyLake and Broadwell). So far, I have experienced no noticeable nor detrimental performance impacts. YMMV, however, as the old acronym goes.

You can grab the update from the Microsoft Update Catalog, or grab a self-installing update (.msu) file for x86 (32-bit) or x64 (64-bit) PCs directly (1809 build, see update catalog for older Win10 versions). Enjoy!


March 22, 2019  1:33 PM

Win10 ComputerName Generation

Ed Tittel Ed Tittel Profile: Ed Tittel

I just got back from a Spring Break mini-vacation yesterday, and am back at work today. When I tried to log in to my Surface Pro 3 remotely just now, I realized a couple of things. One: I couldn’t find the device under its usual moniker. Two: I did eventually identify it as DESKTOP-1D8K0YZ. This is a randomly generated computer name. It appears during routine Win10 installation, when a name isn’t specified in Unattend.xml using Sysprep. “Aha!” I thought to myself, “I forgot to rename the machine when I did that last clean install.” This led to the question “How does Win10 ComputerName generation work, anyway?”

Win10 ComputerName Generation.casefail

In trying to make a “trivial” (case-only) ComputerName change, I learn that such changes are not significant to the rename-computer function in Windows 10. Interesting!
[Click image for full-sized view.]

How Win10 ComputerName Generation Works

As is so often the case with such questions, a Microsoft Hardware Dev Center article provides a good answer. The “ComputerName” article provides good information and guidance on this topic. It starts with this helpful note:

Note   In Windows 10, users can no longer enter a computer name during OOBE as the name is auto-generated. To set a default computer name pre-OOBE, OEMs can configure ComputerName in the Unattend.xml file and specify a name for the computer. After OOBE, end users can change this default computer name after OOBE by changing it in the System Properties page.

Here are some useful facts about what happens during installation, and about what may (and may not) appear in a valid Windows 10 ComputerName string:

  • If no ComputerName is pre-specified (using Unattend.xml), a random computer name is generated.
  • If the install occurs when values for Fullname and Organization (more values from Unattend.xml) are lacking, the ComputerName takes the form “DESKTOP-XXXXXXX” where “XXXXXXX” is a randomly generated string. Note that such strings will always be 15 bytes in length.
  • ComputerName strings can include ASCII or multi-byte characters (such as Kanji, Hangul, and so forth) as long at they don’t exceed 15 bytes in total length.
  • A ComputerName string cannot include spaces or any of the following reserved characters:
    { | } ~ [ \ ] ^ ‘ : ; < = > ? @ ! ” # $ % ` ( ) + / . , * &
  • ComputerName must also be able to be validated through the DnsValidateName function (which means purely numeric strings don’t work, either). See this discussion of the DnsValidateName function for more details.
  • You can use the rename function in the System widget in Control Panel to rename your PC, or simply run the “Rename-Computer -NewName “<newname>” command in an administrative PowerShell session. Either way, you must reboot the OS for the new name to “take.”
  • Though the Rename-Computer command preserves case in ComputerName strings, case doesn’t matter when it comes to resolving or differentiating such strings. I learned this by observation in writing this blog post, as shown in the preceding screen capture.

My good friend and business partner, Kari Finn, has created a YouTube video on how to name a PC during setup that explains a crafty end-around for this apparent Windows 10 limitation. Check it out at “How to name PC at Setup.”


March 15, 2019  1:26 PM

Praising Voidtools Everything

Ed Tittel Ed Tittel Profile: Ed Tittel
Windows 10, Windows Search

According to its online description voidtools Everything “is a desktop search utility for Windows that can rapidly find files and folders by name.” I’ve been a user and fan of this tool for years. But yesterday, I got a real glimpse of what it can do in the Windows environment. I’m helping a friend who’s readying a new release of his excellent dictionary toolset for MS Office, through his company Lexica Software. In checking out some installation issues, I found myself looking for specific logs, config files and so forth. Shortly thereafter, I found myself also praising voidtools Everything as well. Though I knew the names of files and folders, I didn’t know where they were located. Everything made short work of my search-by-name efforts. It even supports basic Explorer right-click menus so I could open, move and delete items right from the tool itself.

Praising Voidtools Everything.searchresults

Everything helped me determine where the install was placing file. It also took me straight to various database files I needed to delete, and config files I needed to alter.
[Click image for full-sized view.]

Praising Voidtools Everything for Speed and Convenience

Sure, you can use the built-in Explorer/Windows Search capability (and I still do, especially through the Start Menu and Cortana). But Everything is orders of magnitude faster than that facility. It usually starts returning results even before I finish typing my search strings. And it takes me quickly to those results when I want to investigate or manipulate them. And it’s FREE.

I was a regular and enthusiastic Everything user before yesterday. I’m even more enthusiastic now. If you’re a developer, or you work with software testing, forensics, or support, this tool is a true must-have. It is donation ware, and well worth supporting. I just added to my earlier contributions to its developer, David Carpenter, via PayPal. If you try out, use and like this tool, I urge you to do likewise.


March 14, 2019  11:47 AM

Win10 Compact OS for Conventional HDs

Ed Tittel Ed Tittel Profile: Ed Tittel

For those running, or taking care of, Win10 installs that boot from hard disks, here’s a trick worth knowing. In Win10 compact OS for conventional HDs speeds up performance. On machines that boot from SSDs, however, Win10 disables this function by default. That’s because HDs are slow enough that compressing the OS files leans on the CPU for decompression. The speed gain from reading less data from a slower disk offsets the performance loss from decompressing that data before putting it to work. But SSDs are so fast that this trade-off is no longer favorable. That means a slight net performance loss vis-a-vis reading the data uncompressed. But for setups with small SSDs (or slower, flash-based storage devices like eMMC) this command might also prove useful because it does free up storage space and won’t impose a heavy performance penalty.

How to Query Win10 Compact OS Status

One simple command does this nicely at the command line. I show examples from PowerShell, but it works just as well in an Administrative Command Prompt windows (cmd.exe), too. Here’s what the command and its output look like from machines with the OS compacted or not:

Win10 Compact OS.yes

Win10 Compact OS.no

Above: compact OS turned on; Below: not turned on, with explanation.
Anyone with admin privileges can turn it on or off easily.
The /compactOS:query parameter simply checks status.
[Click either image to see full-size view.]

To learn to use the compact command, see the MS Docs compact page. It’s easy to check status, and to turn it on or off. By default, it turns it off for PCs that boot from SSDs. I no longer have any PCs that boot from spinners, so I can’t say if Win10 is smart enough to turn it on by default for such rigs. But it’s easy enough to check — and change. If you’ve got some, either or both activities should pay worthwhile dividends for those PC’s users. Enjoy!


Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: