You can call me “slow on the uptake” when it comes to figuring out how to take best advantage of advanced Windows 8 technologies if you like, but I’ve only recently realized that the best way to take advantage of SSDs and Intel’s Rapid Storage Technology and Rapid Start Technology requires building systems with disk architecture configured for RAID from the get-go. I’ve been using AHCI (the advanced host controller interface) as my default with SATA drives for years now, but have only recently learned how to use Rapid Start and a second SSD to boost Windows’ boot-up and shutdown behaviors (and times).
The default UEFI/GPT setting works fine for most smaller SSDs, but…
Having tried numerous proposed methods to switch an existing install from AHCI to RAID without success now, I’m reasonably convinced that selecting RAID in the BIOS for the motherboard’s (or system’s) SATA configuration setting prior to performing a Windows 8.* install (which means a UEFI install of Windows 8.1 on a GPT disk layout these days — at least, on most of my systems) is absolutely the right way to go. My desktops increasingly support two or more SSDs nowadays, and my Lenovo laptops accommodate mSATA SSDs as well as 2.5″ units of the same type, which means all of those systems can support both forms of Intel RST (Rapid Storage Technology and Rapid Start Technology as well). Even if you don’t use a RAID array of any kind, Rapid Start doesn’t work unless you configure the boot drive as RAID rather than AHCI (and with an SSD for the boot drive, there’s no real need to pair two drives together to boost performance for conventional hard disks).
There’s another potential wrinkle in this process that’s worth further reading and study — namely, the partitioning scheme when building a UEFI/GPT based boot/system drive for Windows 8.*. This is admirably documented in the TechNet article entitled “Configure UEFI/GPT-Based Hard Drive Partitions” but there is one proviso that may be worth considering — namely that default partition layouts may not always work exactly as expected. Let me explain: by default, Windows 8.* allocates 350 MB to the Windows Recovery Environment (WinRE) partition, 100 MB to the EFI System Partition (from whence Windows boots), and the rest of the space available on the drive to the OS partition where the visible file system will reside. On smaller SSDs, this allocation appears to work pretty well. But I’ve noticed on larger SSDs (256 GB or bigger) and conventional drives (most of which exceed 500 GB these days), some systems encounter problems when running Windows File History or when capturing a system image (using the System Image Backup option on the File History control panel element). That’s because they write such backups through the WinRE partition to the target drive, and may suffer when there’s insufficient free space in that partition to accommodate backup write activity. In such cases, you’ll want to override the default partition layout for your system, and allocate 500 GB of space (or more) to WinRE (please also follow the directives from the aforecited TechNet article about free space in that partition as well). A disk partition script (using DiskPart.exe) is available with the TechNet article, and worth both reading and using if you decide to depart from the defaults that Windows 8.* uses. An equivalent answer-file setup for SysPrep is also provided there as well.
There are many ways to clean up unwanted software on Windows PC using either built-in utilities such as the “Programs and Features” element in Control Panel (formerly known as “Add/Remove Programs”), or by using third-party tools such as the proverbial “PC Decrapifier.” But until the introduction of the Sourceforge project called the “Windows 8 App Remover,” there was no simple and straightforward way to remove so-called Metro (aka “Modern UI” or “Windows Store UI”) apps from the tiled desktop that is still featured in all currently available Windows 8 versions (Windows 8, Windows 8.1, and Windows 8.1 Update [Build 9600]). The download is an .exe file that you can run in any administrator level account, and produces a display like this one:
You must remember to match the version selector (upper left) to your installed or targeted
version of Windows 8 for this program to work.
Once you tell the program which version of Windows you’re using (a drop-down box pick from the upper left corner of its program window as shown in the preceding screen capture), it gives you the option of removing any of the apps installed on the version of Windows you target. By default the program picks the “Online” image, which means it targets the version of Windows that’s running on your PC. You can also target Windows Image (.wim) files elsewhere in your file system), but only after mounting them to a folder on some drive available to your PC (changes are saved only when you unmount the image you target following use of this program). And while you can uninstall anything you like using this tool, you can only restore these apps by downloading and installing them from the Windows Store thereafter (not as easy as turning Windows features on and off using “Programs and Features,” but not a serious hardship, either). Because the tool works by actually removing binary packages from a Windows 8 image (.wim) file, reinstallation is mandated because the program bits are gone, gone, gone from whatever version of Windows 8 you use it on.
On several of my test machines, I elected to remove some of the Bing apps (Finance and Sports, which I never use), along with Health and Fitness, Reading list, XBOX Games, and Zune Music. This does produce some modest disk space savings on the system drive, and it will result in the disappearance of app tiles from the Windows Store UI. Mostly, it helps to get rid of clutter on the Metro “home page” for Windows 8 versions, and keep you from dealing with apps that you might not want or never use. A nice utility, all in all, Win 8 App Remover is best understood as a GUI wrapper for the Windows Deployment Image Servicing and Management tool, which runs at the command line as DISM.
Anybody who’s been reading this blog for awhile knows I’m a great fan of master utility builder Nir Sofer, the Israeli software development dynamo who’s behind the terrific NirSoft.net website. Today’s blog pays homage to another of his little gems: this one is named WifiInfoView, which Sofer describes as a “Wi-Fi Scanner for Windows 7/8/Vista.”
The WifiInfoView Utility has lots of useful information to show about WiFi networks in your vicinity (click image to view full-size version).
I like to use this tool to observe what my wireless router (“Narbor”) is showing to the world at large, and to get a sense of what else is active my wireless neighborhood. I’m a little embarrassed to observe that somebody nearby (“Jorge54”) has already beat me to deploying 802.11ac. In fact, this spurred me on to order the highly-reviewed and -regarded ASUS AC1900 Dual Band Gigabit Router from Newegg. I also like to use this tool when traveling to scan my wireless environs to see what kinds (and speeds) of connections might be available to me (on more than one occasion, I’ve discovered a higher-speed wireless Guest network than the one my host of the moment advised me to login into).
The WifiInfoView program icon describes its function visually and concisely.
The utility occupies a mere 235 KB of disk space, with just under 300 KB for the entire collection (which includes configuration, help, and readme files, in addition to WifiInfoView.exe). This makes it well-suited for inclusion on any admin’s traveling utility USB flash drive (as is the case for most of Mr. Sofer’s utility offerings), or for routine installation for power users’ (or other interested parties) laptop, notebook, or tablet PCs. Please dash out and grab yourself a copy today, then spend a few minutes checking out the rest of the Nirsoft collection. You won’t be disappointed.
This interesting post last week on the Windows PowerShell Blog is entitled “A World of Scripts at your Fingertips — Introducing Script Browser,” and explains how you can download the aforementioned item to run inside the PowerShell ISE (Integrated Scripting Environment). This grabs a Microsoft Software Installer (.msi) file that’s 1,390 KB in size, and runs a search tool from inside the ISE to help users browse through over 10,000 PowerShell scripts available from TechNet, the PowerShell team at Microsoft, and the folks at “the Garage.”
Though the screen cap is too small to read in detail, you can consult the full-size original for easier deciphering.
Adding this tool to your PowerShell ISE environment produces two additional add-on tabs in the pane at the right-hand side of the UI, as shown above. The left-most tab is labeled “Script Browser” and provides entry to a search dialog like the one shown below:
The search box pane permits users to search and peruse elements from a huge collection of scripts; very handy.
You have the ability to filter searches by resource (PowerShell, Microsoft, Community), various ways to categorize listings, and easy access to summary info and download links for each search hit.
The script analyzer, which appears in the second tab from the left, labeled “Script Analyzer,” provides access to marked up script listing data in the left-hand pane, and error messages in the right hand pane, which makes it an excellent run-time debugging tool.
All in all this is a powerful, helpful, and free tool for script-heads to download and use. Highly recommended.
When I reported here on April 8 that the “Windows 8.1 Update 1 is NOT Optional,” I was working from the then-current and correct understanding that MS would require all users to apply the Spring Update to Windows 8.1 to continue to receive security updates, patches, and fixes via Windows Update. I also observed that it was time for enterprises to “Get Busy” because the testing and vetting cycle in many larger organization normally exceeds the 5 weeks or so that Microsoft was allowing at the time. I guess enough enterprise customers must have remonstrated with Microsoft, because the company has now relented on its timing for requiring the application of the Spring Update for business customers.
The normal enterprise deployment cycle includes testing before deployment, which takes some time. Nice for MS to recognize this.
[Image Credit: Shutterstock 178153691 © Arka38]
Last week, in fact, Mary Jo Foley reported over at ZDNet that “Microsoft gives business users more time to install Windows 8.1 Update,” wherein she reported that for users who manage their updates via WSUS, Windows Intune or System Center Configuration Manager, they now have until August 12, 2014, to apply this update before it becomes mandatory. End Users who rely on Windows Update are still bound to the original May 12 deadline, however.
In the meantime, MS will make all Patch Tuesday items available as standalone installers via the Knowledge Base so that enterprise class users will be able to pick and choose which items that may be released on the Patch Tuesdays in May, June or July of this year that they want to apply, even in the absence of Update 1. It just goes to show you that MS will indeed listen to its biggest customers, especially when they hue and cry is both loud and frequent enough to really get their attention. Thus, you may now return to your normal testing and vetting schedules, ladies and gentlemen in the corporate testing and deployment teams!
As I’ve observed many times in this blog over the years, I’m a hopeless tinkerer. This even applies to my production system when the whim strikes and time permits. My current production machine features the following collection of components (among others): an Asus P8X68-V Pro Gen3 motherboard, an i7-2600K CPU, 32 GB RAM, and a pair of OCZ Vertex SSDs (an older 128 GB Vertex 3 and a newer 256 GB Vertex 4 that serves as the boot/system drive). I hope I can be forgiven for wanting to add the Intel Rapid Start Technology to this machine. But because it was installed with the SATA drives set up as AHCI not RAID, I decided to try a post-install conversion technique I read about online to switch from the former to the latter (the technique required a reboot, a switch to RAID in the BIOS, and a safe boot to give Windows the chance to load new drivers). Long story short: it didn’t work and I found myself compelled to repair my now unbootable machine.
Don’t be inclined to think of a system refresh as the same as an image restore of the system drive: there are some key differences.
Before starting down this road to potential perdition, I made two “backups” of the system disk: one using SlimImage Utilities’ RecImgManager, the other using the “System Image Backup” facility now present in Windows 8.1 as an add-on feature in the File History widget in Control Panel. Just for grins, I started my recovery efforts with the Refresh option for which RecImgManager had created my most recent refresh image, to see how it would all pan out.
It’s interesting that RecImgManager describes the operation of capturing a refresh image as an explicit “Backup” operation, when in fact that’s not exactly how it works. To be fair, it’s close, but it’s also no cigar, either. Here’s what I found that was different after refreshing the image I captured just before beginning my “convert-to-RAID” manueuvers:
1. The restore operation informed me that I would need to reinstall Kindle reader, OneDrive, and WinDirStat once the restore was complete. This proved only partially correct, as both OneDrive and WinDirStat were present and working when the refresh image came up on the PC. Kindle was indeed missing.
2. I had to reload the printer driver for my Samsung ML-2850 laser printer into the refreshed image.
3. When I ran Outlook again for the first time after the refresh took over, I had to reconfigure the whole darn thing (account set-up, archive handling, e-mail download behavior, switch to my preferred archive PST file, and so forth) all over again.
4. Browser plug-ins for Chrome, IE, and so forth had to be re-examined and enabled/disabled as per prior selections.
5. When I ran 8GadgetPack for the first time, it had to be set up once again, as if for the first time.
It’s possible that I might have encountered a few more things had I stayed with the refresh image longer than the two hours I decided to devote to that experiment. After that, I booted up using my Windows 8.1 Install UFD, elected the “Repair” option, and overwrote the refreshed image with my preserved system image captured earlier that morning. What I got back then was exactly what I wanted — namely, my current runtime environment set up, configuring, and working just the way it was when I captured that system image, and requiring absolutely no fiddling about whatsoever to match prior system behavior, configuration, and so forth.
It all goes to show that a system image backup and restore represents the ability to return to the status quo that prevailed at the time of the image capture, and that a system refresh comes close to doing the same, but isn’t quite exactly identical to the system image restore operation. In some cases, especially where Windows flakiness is involved and replacement of system/boot drive files outside the scope of “OS components” is undesirable or unacceptable, a refresh clearly makes more sense than restoring an earlier system image. But it’s not accurate to think of image restore and refresh as equivalent or identical. They are not, and savvy admins and power users would do well to recognize this and take it into account when formulating Windows recovery strategies and processes. The important distinction is that where Refresh does preserve files and some settings outside the scope of OS components, some additional work will be required to get refreshed system exactly back to where it was at the time the custom windows image (.WIM file) for the underlying Windows installation was captured.
In spelunking around on TechNet, I’ve come across an interesting element in the latest Windows Assessment and Deployment Kit (ADK). It’s called WIMBoot and it appears to explain quite nicely how it is that Microsoft has been able to trim down the size of Windows 8.1 Update 1 installations. In fact MS has a pair of interesting illustrations that *show* how this works, and an explanation as to why a smaller image and runtime environments result. The image pair is best understood as a kind of “before” and “after” scenario, in light of this explanation from the WIMBoot Overview (taken verbatim from its “How does it work?” section):
In a standard Windows installation (without WIMBoot), every file is written to disk at least twice: once in the compressed form for recovery, and once in the uncompressed form in the applied image. When the push-button reset feature is included, the compressed image remains on the PC. Having both the Windows installation and recovery image on the device can take up a lot of disk space.
When installing Windows with WIMBoot, you write the files to the disk only once, in compressed format. Next, you apply a set of pointer files onto the Windows partition that point back to the compressed files in the Images partition. When the user adds files, apps, or updates, they’re added onto the Windows partition.
In WIMBoot, your WIMBoot image is also used as the recovery image, saving disk space.
Here are the symbolic (not-to-scale) disk layouts for the before and after scenarios:
The Standard partition layout includes MSR, WinRE, uncompressed Windows files, and a Recovery partition.
The WimBoot partition layout drops WinRE, keeps Windows files compressed, and stores install.wim, winre.wim, and custom.wim.
Overall savings on disk footprint can be pretty substantial, with reductions in size of 6 GB or greater typical. This is essential for smaller configurations, particularly for tablets with 32 GB of storage space or less, but it could also be nice for tablets, ultrabooks, or notebooks where storage space may still be at a premium. For more information on how to set up and build such installations, see also the following TechNet elements:
1. Create WIMBoot images
2. Deploy WIMBoot Images: If you know the size of the images upfront (explains “push-button reset tools” and includes a pointer on how to Update WinPE5.0 to WinPE5.1)
3. Deploy WIMBoot Images: If you don’t know the size of the images upfront
4. WIMBoot: Identify if your PC is Configured to Boot from a WIM file
I can’t wait to try this out, and see how it goes. I also plan to contact my buddies as Paragon Software to see if they might not be working on some tools to help automate this process. If you know of other tool providers with similar work underway, please drop me an e-mail.
Here’s an interesting note from Michael Hildebrand’s April 7 post to the Ask Premier Field Engineering (PFE) Platforms blog entitled “Exploring Winodws 8.1 Update – Start Screen, Desktop and Other Enhancements” (it occurs far enough down the page that some scrolling may be required to uncover it):
- Failure to install this Update will prevent Windows Update from patching your system with any future updates starting with Updates released in May 2014 (get busy!)
The details about end of support for Windows 8 are buried on this MS web page.
But wait! There’s more to ponder, thanks to further reporting on this phenom at Neowin by John Callahan (“Windows 8.1 Update is a mandatory update for Windows 8.1 users“). First, he informs us that “…Microsoft has already announced it will stop supporting Windows 8 in the very near future.” Subsequent analysis of various indications and “a new FAQ page” reveals that “the final date for Windows 8 support” (for Windows 8 installations not yet upgraded to 8.1 and subsequent mandatory updates) is January 12, 2016, about 20 months from now (see MS Product Lifecycle Search, product name = Windows 8, where it lists 1/12/2016 as the “Service Pack Support End Date”). That means — for those already running Windows 8 — it will soon be time to get off that version and onto Windows 8.1, and thus also, Windows 8.1 Update 1.
That gets us back to where this blog post started: if you run Windows 8.1 (and if you don’t run it now, you should start running it soon), you will have to install the update that will be bundled with the next Patch Tuesday set of offerings. As the PFE blog post so correctly observes for production business/enterprise installations of Windows 8 or 8.1 where pre-deployment testing and vetting can involve up to three months of work, it is indeed time to “get busy!” That also means it’s already time to start working through potential issues and gotchas related to that mandatory update, given that any delays in deployment will also delay propagation of upcoming security updates and hotfixes in production Windows environments going forward.
I know what many enterprise desktop admins are thinking as they read this, and chew over the implications: “Good thing we haven’t yet deployed Windows 8 or 8.1 on any (or too many) of our production machines!” Yeah, sure. But with the “Windows lifecycle fact sheet” also reporting that Windows 7 ends mainstream support on January 13, 2015 (end of life/extended support 5 years later), this is not something that enterprises and organizations can willfully ignore forever. Otherwise, they wind up facing the horns of the current Windows XP dilemma: rapid abandonment and forced updates, or expensive extensions beyond the extended support date.
A couple of interesting stories in the news of late have challenged the conventional understanding that Windows XP will finally, finally shuffle off the stage on April 8, just as the latest Windows 8.1 Update is pushed out via Windows Update. Recent reports indicate that some governments are taking the option to pay Microsoft to keep supporting their massive Windows XP installations for some time to come. Amidst lots of other online stories, Leon Spencer at ZDNet (“Dutch government pays millions to extend Microsoft XP support”) tells us that the Dutch government has struck a deal with MS to obtain support for somewhere between 34 and 40 thousand PCs running XP on the desks of Dutch civil servants. This comes on the heels of a deal announced last week between MS and the UK government for over $9 million to extend XP support for its numerous XP, Office 2003 and Exchange 2003 installations through April 2015.
Windows XP is stubbornly clinging to life, especially within government and large institutional settings.
Industry observers have speculated that other governments — including the US Government, which probably still has tens to hundreds of thousands of PCs still running XP within numerous agencies, arms of (and contractors for) the military, and so forth — may have to cut similar deals with Microsoft to obtain extended support for installations they have been unable to upgrade in advance of tomorrow’s cutoff date. In fact, it looks increasingly like XP will continue to limp along for some time after its official termination date has come and gone. In this report on the situation, Ars Technica’s Sean Gallagher states that the current deals on record “…may be just a drop in the bucket in comparison to what the US government may have to pay for the hundreds of thousands of systems still running XP and other end-of-life software.”
To me, it looks something like the long-lived XP operating system may be morphing into “the OS that wouldn’t die.” It should be interesting to keep tabs on other life extension deals for XP that will undoubtedly be popping up in the weeks and months ahead.
[Note added 4/14/2014: Check out this WinBeta.org story entitled “US Internal Revenue Service to pay Microsoft ‘millions’ for an extra year of security patches:” the IRS will pay MS $11.6 million out of its enforcement budget to keep its 60,000 or so XP PCs under the custom support umbrella through the end of 2014.]
When you download the update from MSDN, the first odd thing you’ll notice is that what shows up as a result is a ZIP file. Upon expansion, this is what the 64-bit version unpacks into:
Update 1 turns out to include 6 standalone installer update files (.msu)
The ReadMe.txt file is actually important because it lists the prescribed order of installation for the files in this collection. Based on the last 3 digits of each KB item involved that order is as follows:
1. 422: on both of my test machines (a desktop with an i7-4770K and a tablet with an i7-U4600) this item shows up as already installed
2. 355: this is the biggest item by far, at nearly 700 MB in size. It took 14 minutes to install on the desktop and 32 minutes on the tablet, including the time to get to a login screen after the restart required post-installation (all of the remaining items also require individual restarts, and are timed to get to a login screen as well).
3. 046: this took about 3 minutes on each machine to complete.
4. 592: this took about 1 minute on the desktop and 1:10 on the tablet.
5. 439: this took less than 1 minute on the desktop and 1:20 on the tablet.
6. 621: this took less than 1 minute on the desktop and 1:25 on the tablet.
Total time required varied from about 20 minutes on the desktop to 39 minutes on the tablet. It was kind of a pain to have to reboot 5 times along the way, but that’s what you must do when using the standalone update installer instead of waiting for Windows Update to batch those items together on your behalf. I’m guessing this will cut at least 6 minutes off the overall install time for users who wait to grab these materials from Windows Update next week.
One more thing: you’ll want to run the “Clean up system files” option in Disk Cleaner after installing these updates on a Windows 8.1 PC. This will recover about 700 MB of storage space on your boot drive (which may be meaningful for those using smaller SSDs to fulfill this role, as many systems do nowadays). The composition in the space recovered shakes down to about 690 MB of Windows Update Cleanup files on the 64-bit systems I updated plus a few other odds’n’ends (numbers will be lower for those running x86 versions of Windows 8.1 instead). Cleanup takes a while, too: about 35 minutes on the desktop, and 60 minutes on the tablet, by my rough measurements.