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.
The latest free eBook from Microsoft Press is likely to strike a chord with IT professionals interested in or planning for upcoming Windows 10 deployments. It’s entitled Deploying Windows 10: Automating deployment by using System Center Configuration Manager. The eBook is available for immediate download in a variety of electronic formats (standard PDF, mobile PDF, ePub, and Mobi/Kindle). The author team includes Andre Della Monica, Russ Rimmerman, Alessandro Cesarini, and Victor Silveira. All of these folks work for Microsoft as “premium field engineers,” and all have been involved in larger-scale Windows deployments, including recent and relevant experience with deploying Windows 10.
Though only 95 pages in length, the book offers relevant best practices and deployment advice for deploying Windows 10.
According to the book’s description, over 70 percent of businesses use System Center Configuration Manager (SCCM) to manage PCs. That platform also enjoys increasing market share on a quarter-over-quarter basis. Of its many features and functions, SCCM’s OSD (OS Deployment) functions are among the most popular and frequently used. This book explains and explores those features and functions, and how to use them in real-world situations.
Deploying Windows 10: Contents
The books four chapters are organized as follows:
- Chapter 1 describes what’s new in Windows 10, and what makes it worth using.
- Chapter 2 covers Windows 10 deployment options, and compares and contrasts deployment methods.
- Chapter 3 digs into OSD concepts to prepare for deploying Windows 10 using SCCM.
- Chapter 4 provides a walk-through of the Windows 10 deployment process using SCCM, including implementation details.
How can anyone turn down a free eBook that offers potentially useful and valuable information and implementation advice? Digging in won’t cost you any more than the time it takes to download and start reading. Be sure to follow the links you’ll find in the first paragraph of this blog post, and grab yourself a copy today. Hopefully, it will help get the Windows 10 deployment ball rolling in your organization.
Yesterday, MS released Cumulative Update KB3140743, which promises — and describes in detail — a raft of bug fixes and improvements. Be sure to check the Windows 10 update history page for those details. MS’s actual language is: “improved reliability in numerous areas, including … network connectivity and discovery.” What’s going on here shows up nicely under the Network heading in File Explorer. It now correctly lists all local computers, media devices, network infrastructure elements, and (networked) printers on the LAN. Network discovery has been fixed, and fixed quite well!
Network discovery now catches and displays everything of interest in the Network element in File Explorer.
It’s hard to over-enthuse about this improvement, which captures and displays the network neighborhood quickly and accurately. As an experiment, I withdrew a local PC from my LAN Homegroup. Upon re-establishing its membership, the PC immediately re-appeared in the Computer pane on another PC. It even shows terminal server sessions via RDP. It would eventually display my son’s XboxOne when it booted up later that day.
Reliability Improvements Go Way Beyond Network Discovery…
The improved reliability claim also extends to other items as per the update history for KB3140743:
OS and Windows Update installation, startup, installing and configuring Windows for the first time, authentication, resuming from hibernation, shutdown, kernel, Start menu, storage, Windows Hello, display modes, Miracast, AppLocker, Internet Explorer 11, Microsoft Edge browser, … and File Explorer
I haven’t yet had time to explore these other items in any depth. But if they offer the same accuracy and speed as the networking stuff, Windows 10 has truly taken a big leap forward in reliability. The next few days promise to be more interesting than usual, as I and others explore and learn more about these changes. One thing’s for sure: this is one Windows Update that most users won’t want to miss. Also, enterprise admins will want to start testing this update for deployment sooner rather than later, even those on the Current Branch for Business!
Last weekend, I got my new production PC off the ground with a basic build and OS install. This weekend, I finished the job. This meant installing a raft of SSDs and hard disks, then moving the contents of the old production PC onto the new one. Lots of various applications, services, and so forth needed to move over as well. I put LapLink PCMover to work, and was able to save significant time by doing so. However, I hit a few potholes along the way, and learned a thing or two as I made my PC switchover.
I found myself having to reinstall much of the licensed software that PCMover claimed to have moved. Such items included Office 365, PaintShop Pro, System Information for Windows (SIW), and Nitro Pro 10, but not Paragon Partition Manager. Also, I had to reconfigure e-mail access info in Outlook to get everything working, which took some trial and error to puzzle my way through. Right now, the system appears to be working correctly, and I’m functioning normally on my production PC. It’s something of a relief, I’ll confess, because I hit several snags that had me wondering if I’d be able to get back to work this morning.
PC Switchover Lessons Learned
I don’t know what it is about some hardware manuals, but I’m usually capable of following instructions. I did hit some snags in getting my SSDs and hard disks attached to the Asrock Z170 Extreme 7+ motherboard, and observed that instructions about drives blocked because of SATA ports consumed by the M.2 NVMe SSD didn’t quite match the ports I was able to get working. My reading of the instructions was that the bottom row of SATA connectors at the right on the motherboard block would be unusable, but it turned out that the top ones were unusable instead. I also experienced issues with the ASMedia SATA connectors, not realizing that installing a former boot drive into any of those ports would attempt to pre-empt the NVMe SSD in the boot order.
On another similar front, I attempted to recycle some spare mSATA SSDS into dual RAID 0 configurations using some StarTech circuit boards, but discovered one of them non-functional (it would accept the mSATA devices, but wouldn’t allow me to configure them for storage in Disk Management, producing an “I/O Error” every time I attempted to set up either a GPT or MBR based storage volume). It took some time to sort out all the storage stuff, but eventually I got more than enough working to get the system outfitted with a fair amount of space (about 9 TB worth: 7.5 TB on HDD spinning disks, the remainder on SSDs from 250 GB to 500 GB in size).
A snippet from SIW Pro following the PC Switchover.
PCMover Makes a Quicker PC Switchover Possible
PCMover cost me $60 but proved eminently worth it by automagically moving most of my applications, and all of my files and settings (Documents, Downloads, and so forth) from the old production PC to the new one. I did the migration over my GbE network, and the whole thing took about 35 minutes from start to finish. Though I did have to re-install a handful of applications after the move was completed, it was still quite a bit faster than doing everything over again would have been. The last time I rebuilt my production PC, it took me just over a long day to deal with the aftermath of getting the OS reinstalled, and to put my applications and settings back to where they had been beforehand.
I will say this much for the new rig: it’s the coolest-running PC I’ve ever built. Idle temps are in the low 20s; it runs in a range of 24-29 for ordinary use; and I have yet to see it spike over 37 at the heaviest load I’ve thrown at it (all temps are in Celsius). Throw in a faster CPU, faster memory, and a blazing fast NVMe boot/system drive, and it’s proving to be an entirely satisfactory upgrade.