Last week, I posted a blog here entitled “MS Publishes Big Free Command Line Reference.” It explores a revision to Microsoft’s recently revised and re-released command line info ws-commands.pdf. It’s 948 pages long, and documents 270-plus Windows commands. Over the past four days, I’ve conducted an experiment with each of those commands, to make some Windows Command Line Reference observations. In particular, I’ve tried to oberve the following:
- Commands that work on Windows 10 in both PowerShell and cmd.exe
- Strings that don’t work in PowerShell, but do work in cmd.exe
- Commands that don’t work in Windows 10 at all
- Strings with PowerShell aliases
Making Windows Command Line Reference Observations
Along the way, I also learned something interesting and useful: one can launch the command prompt from inside PowerShell. Simply type cmd or cmd.exe and you’ve got a command line session running inside PowerShell. You can tell by the prompts what’s what, as I show here:
If the prompt starts with PS, it’s PowerShell; if it starts with C:\ (or %SystemDrive%, to be more precise) it’s the command prompt.
[Click image for full-sized view.]
Here’s what I ran (and recorded) for all of the commands in the Command Line Reference:
1. Ran Get-Alias in PowerShell to see if the command had a PowerShell alias. (I counted only 17 unique aliases from the 270-plus commands, over a total of 22 commands. 5 of that total — like cd and chdir — mean the same thing in cmd.exe, and thus also ditto for PowerShell.)
2. Ran the command in PowerShell to see if it worked. (92 commands did not work out of 273, approximately one-third of all commands. Of those 92, 36 aim at Windows Server not Windows client OSes. 15 of the commands are deprecated, of which 13 don’t work on Windows 10 at all.)
3. If it didn’t work in PowerShell, I checked to see if it worked in the command prompt. (12 of those 92 commands worked in the command prompt even though they didn’t work in PowerShell. Some of these are batch file controls such as the shift command.)
All in all, it was a fascinating exercise that showed the majority of commands work with equal facility in PowerShell and the command prompt. For me the biggest benefit was learning that the command prompt inside PowerShell is never more than four keystrokes away (c-m-d-Enter). Just remember to type exit to shell back out into PowerShell when you’re done with cmd.exe!
Next week, I plan to post the complete table of results with additional analysis and lots of links to make things easy to find therein over at Win10.Guru. When I do, I’ll update this post with a link to that article.
I’m active at TenForums.com. I spend at least 90 minutes a day there, reading user posts and responding when I can. There’s a class of errors that show up in the Windows Event Viewer for all Windows 10 machines. The event source is “Microsoft-Windows-DistributedCOM” aka DCOM, and the event ID is 10016. Some borderline OCD Windows users obsess about the presence of any and all errors in the Event Viewer, and attack these DCOM errors with a vengeance. There are various fixes possible that involve hacking the registry or using the Component Services admin tool. These either grant users the missing permissions that provoke the errors, or turn DCOM error logging off completely. But now we know that Win10 DCOM 10016 errors are mostly benign. This revelation comes thanks to f14tomcat, who turned up a Microsoft Support note that explains things nicely.
Header of the support note that confirms these errors occur by deliberate design and may be safely ignored.
[Click on image for full-sized view.]
How Do We Know That Win10 DCOM 10016 Errors Are Mostly Benign?
It’s all laid out in the Microsoft Support note “DCOM event ID 10016 is logged in Windows.” These errors are explained there as follows (verbatim quote):
These 10016 events are recorded when Microsoft components tries to access DCOM components without the required permissions. In this case, this is expected and by design.
A coding pattern has been implemented where the code first tries to access the DCOM components with one set of parameters. If the first attempt is unsuccessful, it tries again with another set of parameters. The reason why it does not skip the first attempt is because there are scenarios where it can succeed. In those scenarios, that is preferable.
Furthermore, the same note asserts that “These events can be safely ignored because they do not adversely affect functionality and are by design.” I’d long suspected this was the case myself. Why? Because even after making the various possible repairs, it never made any difference in system stability or behavior. Also, the errors blithely returned with each feature upgrade. That told me that MS didn’t think they mattered. And now, of course, this is explicitly confirmed in the afore-linked Support note.
You wouldn’t believe how often this comes up at TenForums and elswhere. A quick search there shows 174 hits on “Error 10016.” I’ve sent an email to the main forum moderator asking for a pinned post on this topic. I’ve even volunteered to write it up, to let everybody know what’s up. Yes, it’s an error. But it occurs by design on ALL Win10 systems, and can be ignored. End of story, so fuggedaboutit!
OK, then. With the release of Windows 10 Version 1803 (April Update) HomeGroup is gone, gone, gone. I’m not sorry to see HomeGroups disappear, because it was an enormous pain to kill off an old HomeGroup to create a new one. But I didn’t realize it had been supporting some networking capability on my LAN. With HomeGroup’s demise, all my local PCs disappeared from the Network pane in File Explorer. And that’s why I had to figure out how to bring back basic Win10 1803 networking. As it turns out, it’s not at all difficult. But it does require two steps to get there. At least, that’s how it worked on my LAN anyway. Note: if you never used HomeGroups, none of these contortions should be needed.
Two Steps to Bring Back Basic Win10 1803 Networking
Step 1: Make sure Network Discovery is turned on
HomeGroup doesn’t need network discovery to find other nodes on a LAN. One of its few pluses was that it used the IPv6 Neighbor Discovery protocol to figure out who (or what) is “out there” on a local network. But with HomeGroup now MIA, Windows networking works best if Network Discovery is turned back on. Open the Network and Sharing Center, click “Change advanced sharing settings,” and be sure the radio button for “Turn on network discovery” is selected under the Private network heading (you can, and probably should, leave it in the “off” position for Guest or Public networks, though).
With no HomeGroup, you need Network Discovery turned on for private/local networks to make computers visible in File Explorer (and elsewhere).
[Click image for full-sized view.] I turn off file and printer sharing because all my printers are networked.
Step 2: Turn on Function Discovery Services
The two Windows services that support Network Discovery are Function Discovery Provider Host and Function Discovery Resource Publication. By default in Version 1803, they’re set to Manual startup. That needs to be changed to “Automatic (Delayed Start)” for things to work properly in File Explorer (and elsewhere in Windows 10). Otherwise, you won’t see local computers on the network under the Network heading there.
Click Properties for each of the two Function Discovery services, then change its startup type as shown.
[Click image for full-sized view.
What’s in a Network Map?
I like to see the computers on my LAN in File Explorer. This also lets me navigate into them, and access the files to which my account gives me access. If you follow the two simple steps I’ve outlined here and use a Workgroup (not Domain) based Windows 10 network, you should be able to see (and do) likewise. Enjoy!
[Note: thanks to the various posters at TenForums who put me on the trail of this solution, especially those who posted to the “1803 disable finding computers by name?” thread. Their suggestions led me to observe that switching the Function Discovery services to Automatic or Automatic – (Delayed Start) was essential to regaining the appearance of local PCs under the Network display/map in File Explorer.]
Last Friday, my partner in crime at Win10.Guru, Kari Finn, sent me a link to a very interesting document. It comes from the Microsoft Download Center and shows up with very little descriptive information or fanfare. It’s a 948-page PDF file that includes comprehensive and current coverage for ALL commands from the Windows command line. Most of these items work in both PowerShell and in the old cmd.exe “Command Prompt” window. I don’t know why, but it wasn’t until I saw Martin Brinkmann’s ghacks.net article this morning, that the value of this not-so-little item struck me. It’s also what led to the headline for this blog post — namely “MS publishes big free command line reference.”
There’s not enough information to really clue readers into what’s inside this document. It covers hundreds of common commands of interest to admins and power users.
[Click image for full-size-view. Command Line Reference download link.]
Why MS Publishes Big Free Command Line Reference Is a Big Deal
A few simple observations will explain the preceding assertion.
1. The document is 948 pages long, 4.6+ MB in size, and covers commands relevant to Windows 8.1 and 10, and Server versions 2008 through 2016 (including R2s ).
2. Though MS describes the document as a “complete listing of Windows commands” I must quibble. It doesn’t include bootrec or dism. But those are .exe files, so I understand why Microsoft might not include them in a command reference.
3. I count 273 individual commands documented in the PDF file, where at least another 100 sub-commands have subsidiary entries.
4. If you follow any of the linked references in the PDF, it takes you to the Windows Commands online reference. For those who want to access current info online, this link is also handy.
Great stuff, though, all the way around! Grab a copy of the PDF, and add the online reference to your bookmarks or favorites today.
Last Monday, April 30, MS unleashed Version 1803, aka the “April Update,” to the general public. Though many folks believed it would only trickle out via the Media Creation Tool, it appeared through Windows Update, the Windows 10 Update Assistant, and MCT that same day. Since then, lots of people have been installing, analyzing and digesting the new release. Indeed, it does come with a few gotchas — see Martin Brinkmann’s excellent ghacks story “All the issues of Windows 10 version 1803 you may run into” for the most complete rundown I know of. But not too many of them are serious, nor potential showstoppers. One item could be pretty major, though. As Brinkmann reports from his own personal experience, 1803 may drop Spectre Patches on some PCs — Ouch!
If 1803 May Drop Spectre Patches on Some PCs, Does That Affect You?
Turns out that only those systems that got their Spectre v2 protection courtesy of Microsoft security updates can be affected. Here at my house, almost all the PCs got firmware updates from their system or motherboard makers (Lenovo, Dell, and Asrock, as that turned out). Thus, none of those machines upgraded to 1803 lost their Spectre/Meltdown protection as a result. Other makes and models may be affected, though, if Mr. Brinkman’s experience is any indication.
How can you tell if you’ve been bitten? It’s easy. Simply run Steve Gibson’s excellent InSpectre utility on your PCs. If you see something like this you’re OK:
If you see something like this instead, you’re not:
The only system here that’s affected is one for which a vendor patch was never provided: my wife’s Jetway-based mini-ITX system. Be sure to check yours after you make the upgrade, to see if you need additional mitigation or remediation.
Is Their an 1803 Spectre Patch in the Offing?
I’d have to give this a very high likelihood of showing up soon. By the time many of the IT pros who decide to try out 1803 for possible future deployment fire up this latest OS version this issue may be moot. But it’s easy to check, so be sure to grab a copy of InSpectre (it’s free) to make sure your PCs are covered.
On Monday, April 30, Microsoft unleased Windows 10 Version 1803 on the world. Among the various reports of potential gotchas, I’ve been bitten by this one. Win10 1803 sometimes creates phantom recovery drive post-upgrade/install. You can tell it’s happened to you because you’ll get regular notifications from the OS complaining about an overfull drive. Actually, the partition in question is the Recovery partition. Once it’s been written the first time, it doesn’t usually get written to much, if at all, thereafter so it’s an unlikely candidate for disk congestion. The real problem is that 1803 assigns this partition a drive letter (which it doesn’t normally have). That, in turn, ties it into disk space management and reporting, whence the complaints arise. Fortunately, there are a couple of quick and easy fixes readily available.
I call this a “nagification” because this notification message appears often enough to be annoying. Let’s make it go away, shall we?
If Win10 1803 Sometimes Creates Phantom Recovery Drive, Then What?
You’d think the way to fix this issue would be to right-click the partition in the Disk Management console. But if you run diskmgmt.msc and right-click that partition (far left on Disk 2 in the following screenshot), you get only a “Help” entry as shown.
Normally, the right-click menu includes lots of entries, including one that reads “Change Drive Letter
and Paths…” Not this time! Menu entry aside, there’s no help here.
OK, then. If diskmgmt.msc won’t cut it, what will? For those who believe the saying: “Real geeks do it at the command line,” one can use the disk partitioning command, aka Diskpart. Here’s a sequence of commands that will do the job, assuming the bogus drive is labeled Z: (as in my contrived example). You’ll have to replace references to disk and partition numbers to reflect the specific partition you wish to divest of its bogus and unwanted drive letter.
Do It with Diskpart
The following sequence of commands should set you straight (I use volume 2 and drive letter Z because that’s what’s on my system). Text items that start with double colons (::) indicate comments in batch files and serve that same purpose here. Enter these commands inside an administrative command prompt window, please! The text in bold is what you must enter. You’ll also have to supply proper values for volume number and drive letter in the third and fourth commands, respectively.
diskpart :: opens the disk partition utility list volume :: lists volumes on PC where diskpart runs :: find volume number & drive letter for bogus drive select volume 2 :: selects the volume associated with drive letter Z: :: substitute actual volume number for 2 remove letter=Z :: removes drive letter Z associated with volume 2 :: substitute actual drive letter for Z exit :: exit Diskpart utility exit :: close command prompt window
This is pretty easy, as long as you read the output of list volume carefully. You want to be sure to use the right volume number and drive letter in these commands. To that end, I recommend throwing in an extra list volume after the select and remove letter commands. The first should show an asterisk at the left to indicate selection of the desired volume. The second should show there’s no longer a drive letter associated with that volume. Done!
MiniTool Partition Wizard Does It in One Click!
Although using Diskpart isn’t rocket science, it’s waaaaay easier if you download and use the free version of the MiniTool Partition Wizard Free (aka MTPW). Simply right-click on the Z: partition, and select “Change Letter” from the resulting pop-up menu. You’ll see this window appear next:
By default this shows up with the new assigment of “None.” That’s exactly what you want, so click OK to get that drive letter outa here. Done again! My preferred method, in fact.
If you tune into PortableApps.com, you’ll find a free, open source project. It specializes in permitting users to build portable custom suites of apps and applications. Instead of having to install programs on specific machines, you can access such programs from various location. These incluee a cloud folder (such as DropBox, OneDrive, or Google Drive), a local hard disk, or even a USB flash drive. That means you can sit down at a computer, any computer, and get access to your go-to browser with favorites or bookmarks and extensions or add-ins ready to go. Same goes for music files, photo editors, games, development tools, and so forth.
If I Tune Into PortableApps.com, Then What?
You’ll start off by downloading the PortableApps setup environment from the download page. Then you must choose an install target. Of the many targets available for this screen shot I chose a 64GB Mushkin USB 3.0 flash drive.
Your basic range of portable app targets: USB drive, local drive, or in the cloud.
The Fun Begins After Installation Ends
That’s it for installation. The next step is to run the PortableApps.com Platform. Do that by clicking Finish. The Platform window pops up, followed by a fill-in form that allows you to choose portable apps to install in your personalized environment. There are hundreds of options from which one can choose of which — strictly for grins — I chose Notepad++, IrfanView, Chrome, FileZilla, Firefox, Opera, AIMP, Audacity, VLC, Hijack This, Kaspersky TDSSKiller, PWGen, 7-ZIP, CPU-Z, CrystalDiskInfo, CrystalDiskMark, Explorer++, GeekUninstaller, GPU-Z, SSD-Z, TreeSize Free, WhatChanged, WinDirStat, Windows Error Lookup Tool, and World Clock. Click next and it tells me I’ve got 28 items to grab, which it starts downloading in the order specified. I see bandwidth levels jumping into the hundreds of Mbps, so it doesn’t appear overly throttled.
It takes about 5 minutes to download the 28 items I chose, and another litte while before I realize I have to grant permission for the apps on my list to get installed on the Mushkin UFD. Then I get into a rhythm with the remaining 27 items. This takes a while longer (perhaps 20 minutes all told). CPU usage never spikes that much, so this appears to be a mostly IO-bound activity. Chrome and Opera take longest (1-2 minutes each); some items install in less than 5 seconds; the major seem to take 20-35 seconds. You can find a complete directory of the more than 300 portable apps available for this project on its Portable App Directory page. It’s a pretty big list.
Using Portable Apps Is Dead Simple
Once you’ve got your portable apps installed, run start.exe from the root of the UFD (or wherever else you might put your portable platform). Then a portable menu becomes accessible through the portable apps icon in the notification area on the Taskbar. Click that, and you get a menu that lets you pick from the list of portable apps you’ve installed.
I couldn’t change the 5-sec delay in Snagit and it takes 3 seconds or so for the notification items to clear, so perforce you see both here. Sigh.
To launch a protable app from the menu, select it and double-click, or hit the enter key. Great stuff. I just wish they had more admin apps in their collection.
OK, so this morning I saw the news on TenForums.com that new versions of the Windows Defender security elements were out. Naturally, I wanted to check the new version info against what I had installed on my various PCs. I quickly realized that finding Windows Defender Security About info is not quite as simple and straightforward as it might be. In fact, as I poked around online, I quickly realized that much of the advice on how to do this is out of date. If what you find shows an entry in Windows 10 Settings for “Windows Defender” it’s now passe. You want to look inside the Windows Defender Security Center to get this info anyway. But even the docs file for this app fails to disclose where its “About” info resides.
Finding Windows Defender Security About Info Isn’t Easy
Never mind Settings, open the Windows Defender Security Center (WDSC) instead. If you type “def” into the Cortana search box, it should appear high up on the resulting list of selections. Once inside WDSC, click the “toothed cog/gear” symbol for settings in the lower left corner. When the Settings pane appears click About at the upper right:
The trick is knowing that About information is on the WDSC Settings page (red arrow).
Once you know where to look, finding the information is easy. After jumping to Settings inside WDSC, simply click on About at the upper right. Here’s what appears on my Dell Venue Pro 11 7130 (running Build 17134.1, Insider Preview Fast Ring):
Everything you need to know about Windows Defender component versions appears right here.
Nothing tricky, nothing difficult, nothing unusual. And fortunately for me, what’s installed is indeed what’s current. But alas, I had to beat around the bush before I clicked enough options to find my way to this information. Hopefully, this blog post — while it still remains accurate — will save others that extra effort. But alas, Windows Defender and the associated Security Center seem to be changing on a fairly regular basis.
Closing lament: Oh for the days when clicking Help → About was all it took! Now there are many ways to get to About, each of them slightly different. That’s life, here in Windows World!
Imagine my surprise upon stumbling across mention of a new Window 10 edition yesterday. An alert installer named Lucan found it in the latest Skip Ahead Insider Preview (Build 17650). That’s how I cobbled my headline — “Skippy Shows Off Lean Win10 Edition” — together. But it’s not yet clear what it really means, though it has promoted several interesting guesses online.
How Skippy Shows Off Lean Win10 Edition
The old saw: “A picture’s worth 1,000 words” seems apt here. To that end, here’s the OS selection window from the 17650 setup.exe. It shows Lean as a new item at the top. It appear above Home (and Home N) and Pro (and Pro N) editions.
The new Lean edition appears at the head of the list on 17650’s OS selection pane.
What apparently makes this OS lean is that it’s about 2 GB smaller than Win10 Pro. The space savings apparently comes from foregoing various bells and whistles. These include IE, wallpapers, the Microsoft Management Console, the Registry Editor, and other items. According to Lucan, Lean runs UWP programs from the Store, and also old-school Win32 applications as well.
The Verge cites anonymous sources “familiar with Microsoft’s plans” to position the new edition for OEMs with low-budget laptop and tablets (and limited RAM and storage). It claims that “the edition will be available for devices with 16GB of storage…” And further, “… it’s primarily designed to ensure these machines will still receive Windows updates.” Others have speculated that with a folding screen device patent in the works, MS is ready to jump back into the mobile device market. Peter Bright at Ars Technica speculates that Lean is unlikely “to be the final branding.” He observes further that this OS edition self-identifies internally as “Windows 10 S.” (It’s true, even though MS claims to have abandoned that moniker as an edition label.)
It will be interesting to see how all this works itself out. Once we get past 1803 and advance toward the upcoming Fall feature update/upgrade, we’ll probably know more. Stay tuned!
For some reason, lots of people — including me — take pleasure from following the procession of Windows 10 release names. That’s why I jumped all over a Neowin.net news item today. It’s entitled “The upcoming feature update for Windows 10 will be called the ‘April Update’.” It even provides visual proof for this assertion. April Update shows up verbatim in Welcome page after upgrading Insider Preview to Build 17134. Although MS has not confirmed the nomenclature, it seems fair to say that Build 1803 Equals April Update nevertheless.
Says April update right at the top of the latest Welcome screen in Build 17134. What else ya need?
Proof That Build 1803 Equals April Update
The top line of the Welcome page indisputably says “April update.” The last contender in the name sweepstakes comes from output from the PowerShell Get-VMHostSupportedVersion command. I blogged about this on March 12. I used it to assert that the current name candidate was “Spring Creators Update.” So I ran the command again just now to find this output instead:
Notice the bottom line now reads “Windows 10 Update/Server 1803.” No hard data to confirm or deny a name here.
Of course, this could easily be a placeholder. MS could substitute a different name on the Welcome page when the RTM comes out for real. But half the fun comes from finding and pondering clues that MS lets slip as RTM draws nearer. At least, April gets away from the “hemispheric bias” of associating releases with seasons in the Northern Hemisphere. Maybe MS has finally recognized that what’s Spring for us in the USA or Europe is Fall (or Autumn) for those in Latin America, Africa or Australia (and lots of other places, too).
Here’s hoping this signals a new global point of view for release names in general. I still think they should stick to Version (1803) and Build (17134.1) numbers and be done with it. Not much room for mixed or missed references or ambiguities there!