I have five mobile PCs at my disposal. At various times, I’ve taken all of them on the road with me. Earlier this week, I took at look at the various wireless profiles defined on each of those machines. I found no less than 18 entries on any given machine. My trusty Lenovo T520 — the machine I take with me most often, thanks to its 15.6″ display, comfortable keyboard, and capacious storage (3 drives for 2.75 TB) — had 25! Looking at what I found when running netsh wlan show profiles quickly led me to clean up old wireless profiles on all of those machines. PowerShell makes that pretty easy, so I’ll show what I found, then explain how I cleaned it up.
Aside from numerous client office networks and my home WAPs, this list features lots of hotels and miscellany (25 entries!).
How to Clean Up Old Wireless Profiles in Windows 10
PowerShell happily fields 99.9% of the commands that cmd.exe accommodates, and thousands of cmdlets besides that. I turned to the standard network management command netsh to get my work done in this case. The basic sequence of activities flowed like this:
- netsh wlan show profiles produced the list of profiles shown in the preceding screen capture. These include numerous client locations, my iPhone and home WAP networks, plus lots of hotels and other remote networks, many of whose generic names ring no bells with me at all.
- netsh wlan delete profile name=”<name>” is the syntax for removing old, obsolete or unwanted profiles from that list, where one must substitute <name> with an actual profile name (e.g. TSI or Ft.Marcy Wifi, both of which were among the 15 targets I removed). [Note: the quotation marks enclosing the value of the name attribute are mandatory.]
- PowerShell lets you use cut-n-paste operations with commands, so I used the output from netsh wlan show profiles to capture the strings I used in the subsequent delete commands to clean up the entries I didn’t want or need any longer. Took me less than two minutes on any given PC to clean up my list.
For those of us who take their PCs with them on the road, and who tie into lots of “away” wireless LANs, this kind of clean-up is worth doing at least once a year, if not more often than that. Good thing that PowerShell makes it fast and dead simple!
On Monday, a piece in ZDNet attracted my attention and interest. Shortly thereafter, it also generated some local alarms on four of my systems. The title of that piece says it all “Intel chip vulnerability lets hackers easily hijack fleets of PCs” (emphasis mine). Alas, it seems an Intel AMT exploit needs attention in businesses of all sizes that run Intel-based PCs of “a certain age.” In this case, AMT stands for Active Management Technology. As it happens, AMT lets IT admins perform remote maintenance/update tasks, including wiping hard disks.
AMT can, in the words of the ZDNet story, allow an administrator “to remotely control the computer’s keyboard and mouse, even if the PC is powered off.” Such godlike powers need strong controls that turn out to be MIA. In fact, security researchers discovered that a blank password gets anybody into the Web interface for AMT. That gives them the ability to do whatever they want to entire fleets of PCs. The best fix turns out to be disabling AMT altogether. Admins must thus forgo its administrative conveniences to avoid potentially catastrophic compromises. Find all the details in this Intel security advisory on Exploit Intel-SA-00075.
How to tell if the Intel AMT exploit needs attention on your PCs
Fortunately, Intel has also released a detection tool to tell you if your PCs are vulnerable to this exploit or not. That said, only operations that use AMT are subject to this vulnerability. Thus if your business hasn’t turned on AMT, it can’t be compromised through AMT, either. Download the Detection Guide from the Intel Download Center and you’ll be able to tell if your PCs are vulnerable or not. I ran it on my 8 PCs here at the house, and learned that half of them are potentially vulnerable to this exploit. But I don’t run AMT, so that vulnerability cannot currently be exploited.
If a PC is vulnerable, here’s what the output from that Detection tool looks like:
To check your systems, run the detection tool and see if the word Vulnerable pops up in RED.
Unaffected systems will report Not Vulnerable in GREEN
From what I can glean from the Intel advisory, other coverage, and my own experience, Intel PCs built from 2010 through 2014 are likely to be affected. Thus all of my older systems were affected. These included:
- my wife’s Ivy Bridge dual core i7 mini-itx box
- my son’s Haswell quad core i7 Dell XPS27 All-in-one
- my two Lenovo Sandy Bridge dual core i7s laptops
None of my newer systems fell prey, however:
- the Surface Pro 3 i7 (Haswell i7-4650U)
- my Dell Venue Pro 11 7139 (i5-4210Y)
- my production desktop PC (i7 6700)
- my Insider test desktop (i7 4770K)
I suspect many business PCs will be subject to the AMT vulnerability. For those organizations using AMT, turning it off for the time being is an essential step to regaining control over their PC fleets. Don’t delay in taking that step, please!
Applications are the key to end-user computing, but they haven’t always been the industry’s focus. Security fears around BYOD and the consumerization of IT put the spotlight on mobile device management and, later, EMM. And the flood of major software vendors into that market kept our attention there for much of the past decade.
That will change this year.
Application development, deployment and delivery are some of the top end-user computing (EUC) projects taking place in IT departments this year, according to TechTarget’s 2017 IT Priorities Survey. Let’s take a closer look at some of the app-related results.
Deploying an enterprise application is this year’s most popular mobility project. Among organizations implementing mobility, half said they will roll out at least one app this year. Collaboration apps will be a popular choice, with nearly 40% of respondents planning to deploy those.
Organizations will explore different approaches to get these apps into users’ hands. Some will build them themselves, as more than 35% plan to adopt a mobile application development platform. And 29% will use desktop or application virtualization to deliver apps to mobile devices.
Speaking of virtualization, it’s one of the most common data center projects planned for 2017. Of organizations with IT infrastructure projects in the works, 28% will implement VDI. That beats out much-hyped technologies such as converged and hyper-converged infrastructure, private cloud computing and containers. Clearly, it’s a priority to bring enterprise applications to users wherever they are, on whatever devices they have.
On the desktop side, more than 46% of organizations that have projects planned this year will deploy or migrate to Windows 10. Applications dominate the rest of the list, however, with software as a service, app and desktop virtualization, and cloud apps all garnering at least 25%. IT departments seem content to stick to these more traditional technologies; only 7% of respondents plan to deploy workspace suites, a new approach to delivering and managing all of a user’s applications and data across all of his devices.
Management and security are still important and always will be. Almost 40% of organizations with a mobility project will deploy enterprise mobility management (EMM) this year. But it’s applications that will drive end-user computing growth.
This post originally appeared in the May 2017 issue of Access Magazine.
Here’s an odd and interesting bit of Windows trivia for you. Windows 10 Insider Builds since 15063 (arrived 3/20/2017) include a UWP version of File Explorer. It’s not immediately usable without creating a special shortcut, though. If you’re willing to cut’n’paste a specific and cryptic string to define one, the Insider Win10 UWP File Explorer is yours to play with. That string is:
Be careful if the string spans more than one line. If so, paste the string into a text editor and remove any spurious linefeeds (there shouldn’t be any). YMMV, depending on which browser you use. I pasted it as a continuous string from my source, so you should be able to grab and use it that way, too. My source, BTW, is a tip that appeared at onMSFT.com on 5/6/17.
What Does Insider Win10 UWP File Explorer Look Like?
If all goes well with your shortcut creation, you’ll see something like this on your Windows 10 Insider desktop:
The UI is greatly stripped down and simplified in UWP File Explorer. I’m curious, but by no means ready to switch over from the old version.
Playing around with this version of File Explorer, I make numerous immediate observations:
1. It’s greatly stripped down from the explorer.exe version. There are only minimal display controls (icons at lower right include only list and icon view, a simplified checkbox selection capability, and limited “other” options under the ellipsis at furthest bottom right).
2. I really miss the ability to display file details, such as size, creation/modification dates, and so forth.
3. I likewise miss the ribbon with its extensive, context-sensitive controls.
4. The search function is slow and seems a bit cumbersome (I use VoidTools Everything anyway, so I’m spoiled).
Overall, this earliest version seems more like a throwaway experiment or a toy implementation, rather than a serious contender to replace the current heavyweight version of File Explorer. But with Windows S looming and UWP the main UI for touch and limited-capability versions of Windows I don’t expect things to stay that way for long. It’s interesting though, and worth checking out, for those who have an interest in such things.
Build the Shortcut for Insider Win10 UWP File Explorer
The quickest way to build the shortcut for this version of Explorer is as follows:
1. Right-click the desktop background on Windows 10 Insider
2. Select “New” –> Shortcut from the resulting pop-up menus
3. Paste the string into the location box in the Create Shortcut window, then click next.
That’s it. The shortcut will appear on your desktop. Double-click same to launch the Insider Win10 UWP File Explorer. Enjoy!
In rebuilding my Windows 10 Insider test desktop, I’ve been re-installing my usual toolbox of Windows apps and applications. Chief among the latter is Piriform’s CCleaner, a long-time go-to for cleaning up file clutter on Windows PCs. This time around while installing CCleaner, I ran into something I’ve never encountered before. As I fired off the installer, it got to about 10% complete and then hung. I let it sit for 10 minutes and when the progress bar hadn’t moved I realized something was wrong. I searched Google for “CCleaner install hangs Windows 10” and found lots of helpful information online. For me, the best way to fix CCleaner Install hang appeared in a Piriform Forums post entitled “[Solution] When CCleaner won’t install or download (Windows).”
How Best to Fix CCleaner Install Hang
The forum post explains a great many techniques for resolving download or install problems. For me, the tip that did the trick read “Make sure CCleaner isn’t already running. To find out if it is, open Task Manager to see if it’s in the list of running processes.” I checked, and sure enough, I saw not one, but two instances of CCleaner.exe on the alphabetical list (by process name) on the Details pane therein.
Normally, one sees only a single CCleaner.exe or CCleaner64.exe running in Task Manager. On my test machine, I saw 2!
I right-clicked each of those two items, and selected “End Task” from the resulting pop-up menu. Then, when I relaunched the installer, it immediately completed the job. The whole thing was done in under 30 seconds as has been typical on that and other machines for years. I can only speculate I double-double-clicked when launching the installer, and thus and had two instances of the installer running at the same time. The program wisely chose to forgo honoring my erroneous request for two installs, but I didn’t understand that’s what I was seeing until I looked into Task Manager to see what was going on.
Overall, the afore-linked Forum article is a good one. Might be a good idea to bookmark it in case you, too, ever fall prey to some CCleaner install or download difficulties. It worked nicely for me, so it could also do likewise for you.
In resuscitating my Insider Preview desktop, I’ve been fixing dual boot and Windows Recovery (WinRE). (Links to previous posts: Balky Mobo, Clean Install.) Apparently, something about dual boot interferes with WinRE’s normal operation. It usually lurks in the background, ready to take over if Windows boot or startup issues appear. Dual booting, however, appears not just to disable WinRE. Alas, it also breaks its normal re-enablement process. In researching this, I’ve discovered a couple of peachy resources, and found a nice fix. The resources help with troubleshooting Windows Recovery Environment issues, so I share them here.
Here’s what you see on a typical Windows 10 PC, after you set up dual boot then run the REAgentC command. For those unfamiliar with that command, it’s used to configure a WinRE image and “push-button reset recovery.” Happily, that quote comes from one of my two nonpareil resources on WinRE.
After setting up dual-boot on Win10 on my PC, both installations show status as “Disabled.” Time for some troubleshooting!
Tools for Troubleshooting Windows Recovery Environment
First comes the “official resource” — the MSDN Hardware Dev Center’s 5/4/2016 documentation. It’s a multi-part opus. Thus, I provide links to each part, along with a brief explanation. Helpfully, the first item defines what WinRE is and does:
Windows Recovery Environment (WinRE) is a recovery environment that can repair common causes of unbootable operating systems. WinRE is based on Windows Preinstallation Environment (Windows PE), and can be customized with additional drivers, languages, Windows PE Optional Components, and other troubleshooting and diagnostic tools. By default, WinRE is preloaded into the Windows 10 for desktop editions (Home, Pro, Enterprise, and Education) and Windows Server 2016 installations.
WinRE produces a familiar “alternate boot” screen during Windows boot-up. It can come when called, or when the primary active install of Windows 10 can’t or won’t boot:
When WinRE kicks in, this is what you see on your PC’s display.
Tool 1: MSDN/Hardware Dev Center WinRE Reference
Here are WinRE items from Microsoft. Key sections are flagged with an asterisk (*):
Windows Recovery Environment (Windows RE)*: general WinRE overview.
Customize Windows RE: manipulate a WinRE image (using DISM). Include languages, packages, drivers, and custom diagnostic or troubleshooting tools.
Add custom tool to the Windows RE boot options menu: mount and configure a WinRE image.
Add hardware recovery button to start Windows RE: simplified process introduced with Windows 10.
Deploy Windows RE: deploy WinRE to a new computer including BIOS and UEFI options.
Push-button reset: for OEMs wanting push-button reset features for computer systems.
REAgentC command-line options*: command-line tool for WinRE setup and management.
ResetConfig XML reference: XML elements in the ResetConfig.xml file for push-button reset.
Windows RE troubleshooting features: Recovering from startup failures and WinRE troubleshooting utilities. Automatic Repair, System image recovery, Command Prompt, and more.
In working with reagentc.exe, I found the overview and the command line options elements useful and germane. Those who wish to customize WinRE will find the other sections helpful, too.
Tool 2: TeraByte KB Article 587
This gem is entitled “Repairing the Windows Recovery Environment (WinRE).” It’s both long and incredibly detailed. Believe me, that’s what you want when exploring various ways to get WinRE working on a Windows PC.
For me, the fix that worked appears in a section entitled “Reset the ReAgent.xml File.” It shows how to edit that configuration file. ReAgent.xml drives a running Windows image’s set-up for and understanding of WinRE. By changing XML elements as this section recommends, I was able to run reagentc /enable successfully. This meant that the tool rebuilt my Windows Recovery environment and made changes needed to get it working again.
But the article covers a range of ways to repair WinRE. First, it explains various ways that WinRE might fail. These include:
- WinRE disabled
- BCD file not correctly configured to boot WinRE
- missing or misplaced WinRE.wim file
- wonky WinRE configuration file (ReAgent.xml)
Repairs discussed include
- disabling and re-enabling WinRE
- correcting invalid BCD file references to WinRE
- moving WinRE to the right path/location
- resetting the ReAgent.xml file
- finding and restoring the Winre.wim file
Each repair provides sufficient detail to work your way through it. Even better, each section is illustrated with examples. Bottom line: I was able to diagnose and fix my issues using this Guide. ‘Nuff said!
As I explained in a recent blog post, I’m busy rebuilding my Win10 desktop test PC. (Details: “Balky Mobo Caused Insider Boot Woes,” 4/28/17.) For the past few hours, I’ve been clean installing the Insider Preview version of Windows 10 Enterprise. Working through that process, I observe that the Insider Preview clean install confers insights worth sharing. I’d been updating the previous installation for over two years, so that’s saying a lot.
What impelled the clean install? I had to switch motherboards because the previous occupant of the test system went south. That is, after power on, I could only get it to give me an error code for “SATA problem” (A2) or “USB problem” (99). It’s hard to use a system when you can’t even get into the BIOS/UEFI! Thus, I had to rip out a failing MSI z87-G45 motherboard.
After shopping around, I replaced the old unit with an Asrock z97 Fatal1ty Killer. That meant I had to switch from a Samsung 840 EVO mSATA SSD, to a Samsung 951 m.2 NVMe SSD in the new board. Alas, the Insider Preview OS on that dual boot machine was affected. So that’s why I performed a clean install this time around. A “back to bare metal” situation argues pretty convincingly for such a move anyway.
This are the drivers the Windows installer found on its own in setting up the test system.
[Click image to see full-size view]
If Insider Preview Clean Install Confers Insights, What Are They?
I got my good friend and occasional collaborator, Kari the Finn, to build me an ISO for the latest Insider Preview build (16184). (Kari’s the author of the recent “Windows 10 Custom ISO” 6-part-series of blog posts here, and a true master of the Windows image arts. Here are links to Parts 1 – 2 – 3 – 4 – 5 – 6.) This morning, I used the latest version of Rufus (2.14) to build a bootable USB flash drive from that ISO, being careful to select the UEFI only option that perforce uses FAT32 formatting for the install media.
Overall, the install process proceeded without a single hitch. I did notice some changes in its overall speed. In fact, the first phase is much, much faster. The last time I clean-installed Windows 10 on that machine back in late 2014, it took 20-25 minutes to work through that process. This time, I was done in less than 15 minutes. The Enterprise installer is much more aware of its capabilities now, too. When asking for a Microsoft account for account set-up, it wouldn’t let me use my Yahoo! email address, and it was smart enough to know that neither edtittel.com nor spamarrest.com would permit me to draw on a domain server or DNS connection. In fact, I had to set up a local account to get through initial install (my preference anyway). After the initial install was done, I linked to my primary MS account through the Accounts page in Settings without difficulty.
How Clean Install Has Changed Since Then…
This time around, Windows 10 did a bang-up job with device drivers, too. Earlier, the Windows Installer couldn’t recognize the Killer 2200 Ethernet adapter on the MSI motherboard (also present on the Asrock, BTW). I needed a USB GbE dongle (a $21 Startech model still available from Newegg) to bring my network connection back to life. In fact, all of the drivers I needed showed up after the latest clean install on that machine. I only had to update these exceptions:
- Logitech SetPoint for my m325 mouse.
- Dell E228WFP monitor (almost time to replace this guy, too)
- Intel devices 0C01 (PCI express controller), 0C00 (DRAM controller), and 8CA2 (SMB host controller)
- Intel Management Engine Interface (MEI)
- Nvidia display driver
None of this stuff was terribly hard to run down, and I’ve seldom seen any install get the Intel stuff completely right anyway. A quick check into Reliability Monitor shows me the system tried to grab current drivers for all system items (shown in the preceding screen grab). For some items my tool of choice (Windows Update MiniTool, or WUMT) was better informed or up-to-date than MS. But everything was working, with no unknown devices in Device Manager.
And then, there’s the usual tweaking and clean-up that follows any clean install. I had to change the network status from Public to Private, and join a Homegroup, before Remote Access worked. Usual tweaks in File Explorer options must come via the Microsoft account, because they were already set. Ninite helps with the tedium of adding back in most of my common apps, but not with more specialized tools. I still have a few hours left to go before things will be just the way I like them, and my toolbox fully restocked. Wish me luck!
I just got finished rebuilding my test desktop Windows Insider PC. This system was set up for dual boot, actually. It could boot either Current Branch (1703/Build 15063) or Insider Preview (Enterprise Build 16179). I’d been having terrible boot issues lately trying to manage both boots. That’s because the Windows Installer happily trashes dual-boot setups when it performs a feature upgrade. That makes rebuilding the boot files and boot configuration data a necessary follow-up. Given the frequency of feature upgrades in the Insider Program, that drove me bonkers. When I replaced some hardware, I determined that my (former) balky mobo caused Insider boot woes galore. A motherboard swap set things right. Let me explain…
How Do I Know a Balky Mobo Caused Insider Boot Woes?
I’d been having problems getting the system to boot into the BIOS for some time. Even the maker’s “Boot to UEFI” function was hit or miss. I ran that MSI Z87-G45 board for just over three years, but recently it started getting wonky. Eventually, I found myself in a situation where if I tried to boot with any SATA drives attached, the board would hang with a SATA device error code (A2). But with no SATA devices attached, it would hang with a USB error code instead (99). Ouch!
Alas, you can’t boot a system that can’t get past the error codes. That’s when I decided to purchase a new motherboard, so I could reclaim most of the components at a modest cost. Because I chose an Asrock Fatal1ty Z97 Killer, I also decided to spring for an M.2 NVMe SSD (a Samsung 951) to replace the mSATA Samsung 840 EVO I’d been using in the previous build. I confirmed my initial diagnosis when the new build fired right up, upon inserting the CPU, RAM, and the 1703 boot drive into the new motherboard. I didn’t even have to reinstall Windows 10, though I did have to go through some contortions to get the new install activated. For the first time, the activation troubleshooter didn’t automatically activate my install when I clicked the “hardware changes” button. I’m guessing it was because I was using an MSDN key that had been auto-upgraded from Windows 8. But I still have MSDN keys for Windows 10 Pro available, so burned another one of those…
With a combination of nice features and a good price ($140), I pick the Asrock Z97 Fatal1ty Killer.
Not Quite Home Just Yet, Though
I switched from an mSATA to an NVMe SSD for the other part of the dual boot: Windows 10 Enterprise Insider Preview. That meant I wanted to perform a clean install to a brand-new drive. Wouldn’t you know it? Microsoft has turned off Insider Preview ISO downloads at the moment, and I can’t find them anywhere for that reason. Even the usually infallible HeiDoc.Net Windows and Office ISO Downloader comes up blank for Insider Preview items right now. No sooner than is one problem solved, than another jumps up to take its place. To be continued…
As President Donald Trump’s administration considers changes to tax, healthcare and immigration laws, large technology companies are primed to feel some of the biggest effects.
The CEO of one such organization, Citrix, discussed the potential fallout in an interview with SearchEnterpriseDesktop.
“There’s a lot of anticipation,” Kirill Tatarinov said.
That’s especially true regarding the rules around H-1B visas, which allow U.S. companies to temporarily employ foreign workers in specialty careers such as technology. These visas are distributed to candidates based on a random computer-generated lottery system. Last month, the U.S. Citizenship and Immigration Services suspended the fast-tracking process for H-1B approval, which lets applicants pay a fee to get a faster response to their applications.
“Expectations are very high for — I would characterize it as ‘modernization’ of — H-1B visas,” Tatarinov said. “We employ highly educated, highly paid workers that were brought up in countries other than the United States. Citrix, just like frankly most other native high-tech U.S.-based companies, would benefit from something other than a lottery.”
In terms of healthcare, Citrix employs about 4,000 people in the U.S. who would feel the waves of any changes there.
“It’s not insignificant,” Tatarinov said. “Expectations are still high, despite what transpired, in healthcare reform that impacts everybody.”
Republicans in March shelved a first attempt at a new healthcare bill that would repeal and replace the Affordable Care Act, but the White House said just last week that it would continue those efforts.
Tatarinov also discussed Citrix’s turnaround over the past year and its partnership with Microsoft. Check out more of the interview on SearchVirtualDesktop.
If you’re running the Current Branch release for Windows 10 — namely, Build 15063 — you may have a DISM problem. Some tangible percentage of such installs will puke if you run DISM /checkhealth on the runtime image. But with a Build 15063 DISM fix available, you can repair this anomaly yourself. Here’s what the symptoms look like:
SFC finds nothing amiss, but DISM erroneously thinks something’s off in the Component Store.</>
The key elements for these peculiar circumstances are:
- SFC /scannow completes without a hitch
- DISM /online /cleanup-image /checkhealth reports repairable component store issues
- DISM … /restorehealth cannot fix those issues, no matter what /source you use (I’ve tried them all)
- The DISM log file reports a variety of (mostly driver-related) files MIA as the cause of the errors
With a Build 15063 DISM Fix Available, What’s the Deal?
Warning! Some registry editing will be required, so prudence dictates you back up your registry before proceeding. But that editing simply involves deleting these two specific keys. First, reset permissions on each key to give Administrators full access before entering the delete command, or that command will fail.:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\PackageIndex\Microsoft-Windows-TestRoot-and-FlightSigning-Package~31bf3856ad364e35~amd64~~0.0.0.0]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages\Microsoft-Windows-TestRoot-and-FlightSigning-Package~31bf3856ad364e35~amd64~~10.0.15063.0]
With those edits performed, the DISM problem will vanish. And while cleaning this up might seem like a bit of over-the-top OCD because it restores DISM to proper operation, it actually has real value. That’s because should the running Windows image actually need some kind of real repair, DISM will then be able to perform such tasks.
[Note: I’d like to give a shout-out to the relentless expert Win10 tweakers at TenForums.com, particularly user gommace from posts #39 and 40 in this thread: Creators update component store shows corruption but unable to repair. Be sure to read the whole thread to get a sense of potential gotchas that applying this fix could invite. Most of the more senior members of the forum are electing to wait for MS to fix this issue, as I am myself (except for the test system where I tried out this fix).]