Include me among those who love to tweak and fiddle with their tools, including the Windows OS. I’ve also been vexed with a Windows 10 File Explorer default since its initial release. Recently, I was delighted to discover a registry tweak to get around my vexation. To my great relief, it enables tweaking File Explorer in Windows 10 to drop duplicate items. Here’s a screen capture to illustrate:
By default the removable G: drive shows up twice. Once under This PC, and a second time by itself immediately below.
I don’t like it that you can see the G: drive twice. But that’s the way Windows 10 shows information in the left-hand navigation pane by default. It shows once in the drive hierarchy under “This PC” and a second time by itself because it’s a removable drive. This is mildly vexing on the Lenovo X220 Tablet whence the screenshot comes. That vexation level jumps on my production PC where up to half-a-dozen removable drives may be visible.
In reading the forums at TenForums.com, I discovered a link to Shawn Brink’s excellent tutorial. It’s entitled “How to Add or Remove Duplicate Drives in Navigation Pane of File Explorer in Windows 10.” That tutorial explains how to edit the registry to drop duplicate drive displays. Better still, it provides registry update files (with a .reg extension) that run programmatically. Thus, manual registry editing need not occur. Brink kindly also includes 32- and 64-bit files to reverse those changes, so that users can resume default operation if they don’t like the new look. This makes tweaking File Explorer about as easy and safe as it gets. After running the update file, this File Explorer display appears:
With the registry update applied, the G: drive appears only under the “This PC” heading.
A Trove of Tutorials for Tweaking File Explorer
Who cares about tweaking File Explorer? Enough people to generate 5 pages of back-and-forth questions and commentary on this tweak, and enough to stimulate expert members of the TenForums community to create an additional 10 further tutorials in this same vein there, to wit:
If you’re an incurable tweaker like me, you can’t help but love this stuff. Have fun, and get going tweaking File Explorer right away!
Now that Windows sleep appears to be working properly on my production PC, I’ve begun to understand that various influences can disturb that hallowed and blissful state. Starting last Thursday, I noticed that my PC was already running in the morning when I arrived in my office. Apparently, something other than my moving the mouse or striking a key on the keyboard was waking up the machine. Mildly curious, I started researching how to figure out what was causing the wake-up to occur, so I could provide some Windows Sleep Protection.
I found my answer in a nice article from Ghacks.net entitled “How to find out why your PC wakes up, and how to stop it.” Although this article from December 31, 2013, predates the Windows 10 release date in mid-2015, it applies to Windows 10 in every particular nonetheless. From its contents, I learned that the powercfg command can provide useful information about wake causes, and that the Windows System log in Event Viewer can shed even more light on what’s causing wake-ups to occur. That’s the foundation on which Windows sleep protection rests.
The powercfg command shows information about the most recent wake-up, and devices that have caused recent wake-ups.
Windows Sleep Protection Requires Preventing Unwanted Wake-up Events
The most important clue in the preceding screen shot comes from the presence of the Intel network interface at the tail end of the -devicequery version of the powercfg command. That let me know that something arriving from the network was waking up my system. Because I’m no longer relying on that system to provide services to the network, it doesn’t need to respond to Wake-on-LAN packets anymore. Once upon a time, that PC had been the host client for a USB-attached printer, and also served as the “master system” for my local Homegroup. But no longer. That means it was now OK to block Wake-on-LAN events as a form of Windows sleep protection.
Confirmation came from inspecting the March 24, Power-troubleshooting events in Event Manager, as this detail display illustrates:
The event detail for 3/24 clearly confirms the wake-up originated from the Intel I211 GbE network interface.
How to fix this? Simple! I know from long prior experience with local area networks that the Power Management tab in the Properties window for modern Windows network interfaces includes a “Wake on LAN” pane, with a variety of wake-up options related to the so-called “Magic Packet” that can trigger a wake-up event. I simply made sure all of those checkboxes were unchecked, and I have not had an unwanted wake-up since. Here is what my current settings look like:
Please note that none of the “Wake on…” checkboxes is selected. That’s the trick!
Not every unwanted wake-up will be as easy to fix as this one was, though these techniques should work for any kind of cause. Follow-up research on how to delay or disable the cause of the wake should provide the additional details necessary to keep Windows from being disturbed when you don’t want it to be. Blissful snoozing should be the resulting outcome.
What to do when a Windows 10 install gets damaged to the point where it won’t boot? Why, repair the code, of course! That’s what a recent post from Sergey Tkachenko over at Winaero.com reminded me of yesterday. It’s entitled “How to run the sfc /scannow command if Windows 10 does not boot,” and it’s worth a read in its own right. The importance of attempting Windows 10 image repair on a troubled or damaged OS is easy to overlook, and impossible to overstate.
I can’t say this has never happened to me, usually because I’ve been tinkering with something that might have been better left alone. But I can say that the ensuing “Oh no!” reaction sometimes turns off my “intellect vast and cool and unsympathetic” (to channel HG Wells). Thus, I might be inclined to forget that the reverse of the old maxim is entirely true and apt — namely: “If it is broke, you SHOULD fix it.” And fixing a broken Windows install is very often possible and doable using one of two powerful tools. As Sergey observes in the afore-cited blog post, the system file checker (SFC) is indeed one of those tools. The other is the redoubtable Deployment Image Servicing and Management tool, aka DISM. Both of them can help with Windows 10 image repair, in fact.
Windows 10 Image Repair, By the Numbers
Either way, the general approach to dealing with the repair is the same, though the syntax details do differ. Here’s the 10,000 foot view of what’s involved:
- Use a bootable UFD to boot into the Windows installer
- Follow along until you see the Repair option, then elect the “Command Prompt” option
- Run sfc /scannow … to attempt a Windows OS files repair, then reboot
- If that reboot works, you’re done. If it still fails, run dism /image /cleanup-image /restorehealth … to attempt another repair, then reboot
- If that reboot works, you’re done. If it still fails, you will want to try an in-place upgrade next
Basic syntax for the DISM offline image repair command. Be sure to read up on the /source attribute: it’s a doozy!
I could keep going to the ultimate fix but readers probably have the idea right now. And that, of course, would be an image or backup restore from the most recent backup or image. But like the old textbooks say, I can leave that as an exercise for the reader!
There are a couple of important notes here. They come from the ellipses at the end of the commands in steps 3 and 4 above. First, the syntax for running these commands offline on a moribund OS is different from running them on an active image. Tkachenko’s post does a nice job of covering them for sfc so I’ll let readers dig them up there. The definitive DISM reference for offline repair is available from TechNet, entitled “Repair a Windows Image,” but you’ll also need “DISM Operating System Package Servicing Command-Line Options” to get the /image and /source attribute options completely straight. And both of these commands will sometimes provide just the Windows 10 image repair you seek.
Just saw a nice infographic from the folks at 1e.com. Their Nomad product lets Microsoft System Center Configuration Manager handle large-scale Windows deployments. “But wait!” I hear you thinking. “Doesn’t SSCM do deployment on its own? Why another tool?” Good questions. The quick answer is Deployment Automation. Here’s my explanation:
Setting the Stage for Deployment Automation
Think about mammoth enterprises, with tens to hundreds of thousands of endpoints. Or ponder the US DoD, which has announced plans to upgrade ~4M endpoints by the end of 2017. Sure, SCCM can set up and fire off in-place or policy-based upgrades for endpoints. But alas, that is subject to some interesting issues:
- Bandwidth: upgrade packages for Windows 10 range from 3.2 to 4.2 GB in size. Also, they must be transferred to every endpoint. SCCM isn’t good at bandwidth throttling, nor can it stagger downloads to reduce traffic. Multiply this by large numbers, and what happens? Enough data in transit to choke WAN links of any size.
- Legacy hangover: Sure, an in-place upgrade sounds good. But it doesn’t support UEFI boot security on PCs running legacy BIOS. To benefit from UEFI boot security enhancements, the boot drive must be wiped and reformatted. Oops! That doesn’t work with an in-place upgrade.
- Manual labor: Many organizations still require human interactionto get upgrades installed. Ditto, for production systems migrating from an old OS to a new one. 1e’s infographic shows that over a third of organizations require manual intervention for OS deployments (40+%) and application migration (37+%). That’s alotta labor!
There are more issues worth chewing on, even for organizations willing to stage SCCM servers closer to sites where Windows 10 gets deployed. These include cost of additional SCCM licenses and platforms, admin overhead, and more. In short, there’s a big gap between what needs to be done to migrate and what SCCM can do unaided at enormous scales.
What’s the solution? Simply put: bandwidth conservation, proximity staging, and ample deployment automation. 1e’s Nomad addresses deployment all the way to the endpoints. It is especially relevant to remote endpoints. These might reside in remote premises, branch or satellite offices, or belong to itinerant field staff:
- Local staging: For each LAN, Nomad picks a “master” node. It gets one download of the deployment package over the WAN. All other clients on that LAN get their copy from that master. Thus, only one WAN transfer per LAN occurs. Local transfers work peer-to-peer, using an agent on each endpoint to request and manage delivery. Bandwidth is monitored and automatically throttled so transfer traffic won’t interfere with business traffic.
- Powerful deployment automation: On each client, automation tools preserve and migrate applications, settings, and preferences from an old to a new install. They also handle wipe-and-clean-install of Windows 10 where needed. Ongoing monitoring and status reporting built into the agents helps, too. It lets them flag a flubbed or faulty system, and revert it to its original state. It can even schedule that client for manual intervention through mechanisms the customer chooses. This might be something like “provide a replacement, ship unit to depot for service, swap replacement for upgraded unit,” for example.
This diagram from the Nomad page speaks to the product’s many capabilities.
These capabilities and techniques present a workable way to manage large-scale Windows 10 migrations and deployments. That’s what makes products like 1e’s Nomad worth investigating, and perhaps acquiring. For those with big Windows 10 deployment plans, it makes good sense to inquire further.
With the appearance of the latest Insider Preview build of Windows 10 (14291) an interesting feature has appeared in Settings. It’s a tool for temporary files cleanup that also handles the Windows.old and other files retained by default for 30 days after a Windows 10 upgrade. Find it by following this item selection sequence in Settings:
System –> Storage –> This PC –> Temporary Files
[Note: You must scroll down to find the Temporary Files item under “This PC”. It is the penultimate item in that list.]
What Temporary Files Cleanup Looks Like in Settings
Here’s what turned up when I ran this on my Dell Venue Pro 11 this morning, updated to Build 14291 last Friday, but not yet cleaned up using either CCleaner or the built-in Disk Cleanup utility to clear away the previous Windows 10 Insider Preview build. It addresses all the common categories to conduct a temporary files cleanup.
Note the final item that reads ‘Previous version of Windows.’
This adds yet another method for cleaning out prior versions of Windows to the general bag of tricks. I imagine this will remain a part of Windows 10 going forward, but am curious to learn if this portends possible changes to the venerable Disk Cleanup utility, whose “Clean up system files” option provides another means for achieving the same end.
I’ve also noticed recently that CCleaner’s ability to handle Windows.old, Windows.$~BT, and other remnants of prior Windows releases tends to vary according to the release it’s pointed at. Right now, for example, it (and the Disk Cleanup utility) can handle those elements on my Windows 10 Enterprise Insider Preview just fine. But they’re balking at removing a folder in the Windows.old\Windows hierarchy named InfusedApps on Windows 10 Pro Insider Preview. Now that I double-check the new Temporary Files cleanup facility in the aftermath of an attempted clean-up using that tool, I see that the same folder persists following its use, too. I wonder what’s in that 124 KB folder that’s causing it to resist removal? To make it go away, I had to take ownership of the InfusedApps folder, and then manually delete all the folders in the hierarchy above and below it, all the way up to Windows.old. Strange!
[Note: here’s a shout-out to Richard Hay at WinSuperSite.com, whose Friday 3/18 story “Windows 10 Build 14291 — Visual Changes and Enhancements” brought this newly-minted capability to my attention. Thanks also to him for responding to my comment to explain how to navigate to this facility.]
Windows PE stands for “Windows Preinstallation Environment.” It’s a minimal running subset of the regular Windows operating system that’s designed to support Windows installation, deployment and repair. It’s been around since the Windows Vista days, and an iteration for every subsequent version of Windows is readily available. The Windows 10 version is described nicely in a Hardware Dev Center article entitled “Windows PE (WinPE)” and is included in the Windows Assessment and Deployment Kit (Windows ADK aka WinADK). Using MS-supplied tools, Windows admins can build their own completely customized Windows PE tools, as described in those documents (and in other items that are linked to there).
Windows PE Tools Tend to Focus on System Repairs
A full-blown WinPE environment can incorporate all kinds of third-party tools and utilities, as well as whatever set of drivers might be needed for the machines on which that environment will run. While some Windows PE tool sets stick to the command line as an interface, others have well-built GUIs that can sometimes be hard to distinguish from a complete Windows OS installation. Most WinPE environments tend to be heavy on repair and recovery tools, though. That’s because WinPE as a runtime environment is primarily aimed at repair efforts (installation and deployment work just fine fully automated, so GUI grandeur is not needed).
Building one’s own Windows PE tools environment may not be necessary, except for those with very special needs. There are numerous WindowsPE toolkits readily available, some free and some for a fee. Admins may want to look over and ponder this list before deciding to roll up their sleeves and take the DIY route:
- Paragon Software Rescue Kit 14 Free Edition
- Lazesoft Recovery Suite 4.1 ($27.95 and up, various editions)
- AOMEI PE Builder (free)
- LSoft Technologies Active@ Boot Disk ($99.95 and up, based on Windows 8.1 PE)
- Kyhi’s Windows 10 Recovery Tools — Bootable PE Rescue Disk (free, TenForums.com)
- Gandalf’s Windows 10 x64 PE with all x64 apps (free)
This screen cap of the Start menu from Gandalf’s Win10 PE tools shows off a full-blown GUI.
[Click image above to see full-size version.]
No doubt there are other pre-fab Windows PE tools programs out there for Windows 10. So far the preceding items are the best that I’ve been able to find. If you know of others, please post a comment here. I’ll check them out, and those that I also like I’ll add to subsequent updates to this post with shout-outs to the first person to provide a pointer. Thanks!
On Leap Day (2/29) I made the switchover from my previous production desktop PC to a newly-built replacement. For the first 10 days or so I struggled with the build I’d put together. During that time, I slowly realized that a legacy BIOS environment with an MBR layout for the boot/sys drive was not working well. About one week ago, I bit the bullet, and reinstalled Windows 10 on that system. This time, I made sure to pick the UEFI: labeled item in the list of boot devices, and made sure to format the boot/sys drive using GPT partitioning. That way I could be sure to use my new PC’s extensive UEFI boot capabilities and utilities.
Modern Windows Works Well with UEFI Boot
Windows 8 and 10 are inherently UEFI-aware and -friendly. Subsequent system behavior has made this a very worthwhile action for me. Prior to the re-install, my reliability index had hovered between 1 (the lowest value possible) and 5 (the middle of the range). Since the day I re-installed as described, and started using UEFI boot, it’s been a straight, solid 10 across the board. Here’s a screencap:
A perfect 10 from day one to the present on the latest production PC Win10 build. (10 is top line, 1 bottom)
Even Better, UEFI Boot Works Like a Champ on my Windows 10 PC
I’m not used to seeing this kind of stability on my production systems. That’s probably because I mess around with them all the time. I’m always updating drivers, installing new software, tweaking here and there, and otherwise provoking trouble. But since I made the change to UEFI boot and GPT on this particular build, it seems to be as solid as the tablets and notebooks I use regularly. These include my Surface Pro 3 (i7, 256GB SSD, 8GB RAM), my Lenovo ThinkPad X220T (i7, 256GB SSD, 16 GB RAM), and my Dell Venue Pro 11 (i5, 256GB SSD, 8 GB RAM), all pretty unshakeable machines.
The moral of this story is to check your defaults carefully when installing Windows 10, and to make sure you select the UEFI: item in the boot priority listing when booting to a USB Flash Drive to begin the installation process. The latest version of Rufus (2.7) makes that easy because it offers “GPT partition scheme for UEFI” as an option when setting up a bootable UFD for installing Windows 10. Electing that option means that the defaults that will be supplied in the Windows 10 installer are the ones you want, so your checking should simply confirm the desired options, rather than fixing incorrect ones. This should result in a solid and stable system, just like mine. Enjoy!
Anybody who’s been following sleep states and power management for the new Microsoft Surface Book and the Surface Pro 4 knows that lingering and troublesome problems have plagued those platforms until recently. ( On February 17, MS released a firmware update that finally fixed things as reported in this Ars Technica story.) In fact, sleep and hibernation have been thorny issues for Windows for years. They have been problematic enough, in fact, that I’d gotten into the habit of turning sleep off on my PCs because of issues involved in waking up. But now, it seems that with the latest cumulative update to Windows 10 (KB3140768), lingering issues are solved for Windows sleep — at least on my small but hopefully representative sample of desktop PCs.
I’ve just gotten my new production PC squared away. I accidentally blew away my habitual Power Options settings on Friday, after re-installing APC’s Power Chute (Personal Edition) software on that machine. Before I got around to resetting Power Options to disable sleep I noticed something interesting. Windows sleep not only works as it’s supposed to on this PC (and on other desktop units and All-in-Ones here at home), but because this PC boots from an NVMe boot drive it’s also darn quick. Using the stopwatch on my iPhone, I’ve timed the delay between striking a key on the keyboard or moving my mouse and getting to the Windows login screen at between 8 and 9 seconds. That’s short enough that I don’t mind letting the PC sleep when I’m not using it. I’m even becoming confident that Windows sleep and wake behavior will stay consistent, because it’s already done so for the past four days now. No strange driver issues nor missing or lagging devices after wake-up now, either!
Windows Sleep cuts back on power usage
The real upside of this Windows sleep regime is that the PC consumes almost no energy when it’s sleeping. Thanks to Power Chute I can see that my electric bill will be dipping, too, as a result. I pay about $0.11 per KWh, and it looks like my monthly charge for the PC will drop by about $1.00 a month (down from $5 to just under $4, according to the software’s regular monitoring reports) thanks to sleeping overnight. I’m usually at my PC by 7:00 or 7:30 AM and keep it running until about 10:00 PM, so the new sleep regime gains it ~9 hours of sleep time daily.
Enabling Windows sleep saves about 25% on daily energy costs.
What’s interesting to me is to find myself marveling and happy about something that Windows has claimed to do for years that now finally seems to work as it should. You’d think one could take this kind of thing for granted but sadly, experience has taught otherwise…
I’ve been working with a new production PC for the past week, and only slowly realized that I had goofed with my initial install of Windows 10 on that machine. I had naively assumed that Windows 10 would recognize my NVMe drive needed a GPT disk layout and run the OS install accordingly. Not so: as I struggled with painfully slow boot times on a rig that was supposed to feature blast-fast boot and shutdown times, I slowly realized that my naïve assumption was dead wrong. Sure enough, inspection of the drive layout in Disk Management showed no EFI partition. No EFI partition meant the disk was formatted for Master Boot Record (MBR) boot-up. Alas, that meant the motherboard UEFI BIOS had trouble finding the NVMe drive at boot time. In fact, it was taking way too long to work its way through the 8 other drives I’ve got on that machine. Only eventually and apparently reluctantly would it hand over boot responsibility to the NVMe drive to get the OS up and running, even though I’d designated this drive as the highest priority in the BIOS boot order.
As it explains in this nice article at the “How-to-Geek” website:
“Windows can only boot from GPT (which stands for GUID Partition Table, where GUID is a “globally unique identifier”) on UEFI-based computers running 64-bit versions of Windows 10, 8.1, 8, 7, Vista and corresponding server versions.”
That article also goes onto illuminate the improvements to boot integrity that GPT provides. Chief among these is its ability to store multiple copies of the partition table and drive layout information. Thus, if one copy of that data gets damaged, another copy is still likely to remain accurate and usable. MBR maintains only a single copy of such data, so if it gets damaged, bootability usually gets trashed. Also, GPT works with drives of any size, whereas MBR tops out at 2TB. Further, GPT permits an arbitrary number of partitions on a drive (Windows caps that number at 128, but that’s not a GPT limitation), and MBR tops out at four. All good stuff, to be sure!
GPT Disk Layout Makes a Difference!
But GPT’s inherent association with UEFI was most important to my set-up, because a UEFI BIOS is better able to identify and work with that partitioning scheme than with MBR. During the bootup when the drive was formatted with MBR, a cursor would appear and blink on-screen for 30-45 seconds once boot-up got underway. A bit of online research told me that this behavior indicates the BIOS is searching for a boot drive while this occurs. I’m not sure why this happens when boot priority is specified as a BIOS configuration item, but it was constant and unrelenting anyway.
The EFI partition shows that the new install used a GPT disk layout.
The switch to GPT disk layout eliminated this phase of the boot process. Now, my PC boots in 13-14 seconds once the BIOS actually starts the boot-up process. The motherboard maker’s logo “Asrock” still sits on the screen for just over a minute before that process actually gets underway, though. My next troubleshooting mission will be to figure out how to make that go away.
The only downside to this change is that it required me to perform a clean reinstall of Windows 10, that being the only way to change the system/boot drive from MBR to GPT disk layout. I was able to get through most of it after hours last evening — the whole process took about 2.5 hours, except for a few more details I have to work through this morning. These include migrating my Library folders from the old install to the new, reconfiguring Outlook, and adding the old drive’s PST tiles into that new Outlook environment. Fortunately, having made an image backup of the old drive yesterday, I am able to mount that image in Disk Management as a virtual disk, and then to grab anything and everything I need while that drive is mounted.
File this one under the heading of “I didn’t know you could do that with Windows 10.” This refers to what Sergey Tkachenko calls a “secret reboot mode” in Windows 10 (and 8 versions, too, apparently). It’s available using the old three-fingered salute on Windows 10 PCs. (That means striking the CTRL-ALT-DEL simultaneously, a technique originally used to force DOS to reboot back in the pre-Windows days of PC computing). When you strike that key sequence in Windows 10 you get a security options screen that options like Lock, Switch User, Sign out, Change a password, and Task Management. That’s not where emergency restart comes into play for Windows 10, however.
Instead, you must click the shutdown button at the lower right corner of this window while holding down the CTRL key on your keyboard. This provokes the Emergency Restart screen shown (reproduced from the WinAero.com blog post on this topic):
Taa daa! Emergency restart is exactly what this special restart option says and does.
[Image credit: WinAero.com/Sergey Tkachenko]
Of course, that raises these very interesting questions:
What exactly is emergency restart?
How does emergency restart work?
It’s important to understand the answers because they affect the outcome of exercising this option. Basically, Emergency Restart shuts down all active Windows processes immediately, then shuts down the OS next. It’s as quick as shutdown gets, but also means losing any unsaved work in applications open on your desktop. It’s a kind of last-ditch OS shutdown maneuver that’s just one step shy of hitting the reset button when the OS is still running. Though a forced reset may sometimes be necessary when the OS or an application hangs completely, and the system becomes completely unresponsive to input, it’s never a happy maneuver. For this option, as long as the PC still responds to the three-fingered salute, you can bail out without a maneuver that produces the “Windows was not properly shut down” message in Reliability Monitor.
I mess around with my Windows machines often and aggressively enough that I like this newly uncovered restart option. If your usage patterns are anything like mine, you’ll probably like it too! Thanks again, Sergey, for sharing this useful tidbit of insider info.