Windows Enterprise Desktop


June 13, 2018  11:00 AM

Sysprep Audit Mode Alternate Key Sequence

Ed Tittel Ed Tittel Profile: Ed Tittel
Keyboard Shortcuts, MS Sysprep, Sysprep, Windows 10

When it comes to building custom Windows images, few tools are as helpful as Microsoft’s venerable System Preparation Tool. Usually known as “Sysprep,” this tool works with a variety of other elements from the Microsoft Assessment and Deployment Kit (ADK). Savvy admins use Sysprep in Audit Mode to make and capture alterations to running Windows images. The Microsoft docs tell us that once you get to the final dialog after the last boot during the Windows install process, one can enter Audit mode using Ctrl+Shift+F3 keys. Why, then, is a Sysprep audit mode alternate key sequence necessary? [Note: this is the dialog where the system asks you to choose “Customize” or “Use express settings.” See Kari’s great TenForums tutorial Customize Windows !0 Image in Audit Mode with Sysprep… for fully illustrated step-by-step instructions.]

Sysprep Audit Mode Alternate Key Sequence.screencap

When you enter Audit Mode, the System Preparation Tool pops up. For those who wish to customize a Windows install, the next thing to do is to press the Cancel button to close this window.

It seems that on some keyboards — especially those found on laptops — system builders monkey with the handling of function keys. Often, that’s because keyboards are smaller and include fewer options. On my Lenovo laptops, for example, there’s a blue function (Fn) key that must be pressed for those keys to perform alternate functions. These include lock/unlock, sleep, display redirection, snapshots from the built-in camera, brightness controls, and so forth. On my Dell Venue Pro, the function keys work only if the blue Fn button is depressed. Otherwise, system control functions apply. Still other laptop makers use different conventions, key assignments, and so forth. You get the idea, I hope.

Sysprep Audit Mode Alternate Key Sequence Revealed

Ok, then. Let’s assume you try the default key sequence of Ctrl+Shift+F3 and nothing happens. What then? My preceding discussion foreshadowed the fourth key you’ll add to this mix. Try Ctrl+Fn+Shift+F3. That’s because you’re trying to use the Function key as a veritable function key and pressing Fn on some keyboards will make that happen. If neither sequence works, you’ll have to visit your laptop (or keyboard) maker’s website to get the right sequence from them. Since their deployment techs invariably use some sequence to get Sysprep into Audit Mode, somebody there will undoubtedly know the answer. All you have to do then, is to find your way to that somebody or some other source for that information. My best guess is that if the site has a user forum, you’ll be able to find the info there in short order by searching on “Sysprep” or “Audit Mode.” Good luck!

For the record, on my Lenovo systems Ctrl+Fn+Shift+F3 works like a champ to get into Audit Mode. If the default sequence doesn’t work for you try the alternate sequence next.

Shift
Ctrl
Fn
F3

June 11, 2018  12:35 PM

Fixing Win10 Restart PC to Finish Installing Drivers Issue

Ed Tittel Ed Tittel Profile: Ed Tittel
Device drivers, Troubleshooting, Windows 10

I’ve chased down a strange sequence of clues over the past few days to finally resolve an odd device driver issue. The reason I say the device driver issue is odd stems from its origin. It followed in the wake of a recent Security Update for the Adobe Flash Player. “I don’t see that a device was involved,” was my reaction to unwinding the clues that led me to this discovery. I’m sure other readers may react likewise. But the clues that led me to this understanding are convincing. Thus, let me present the evidence for fixing Win10 restart PC to finish installing drivers issue.

Evidence for Fixing Win10 Restart PC to Finish Installing Drivers Issue

On June 8, I got a notification from Windows 10 that I needed to finish installing a device driver. With no new device drivers added to my machine that day, I was a little puzzled. First off, I turned to Reliability Monitor, which showed me only two information items, neither of which specifically mentioned a device driver:

Fixing Win10 Restart PC to Finish Installing Drivers Issue.relimon

Only two info items for that day, neither of which is labeled explicitly as a device driver. Curious, eh?
[Click image for full-sized view].

Quite naturally, this led me to the Windows log file setupapi.dev.log, where Windows 10 logs all device driver additions and changes. For the record, this file resides in %windir%\INF, and can be an occasional and valuable source for driver insight. This time, it showed me an entry at the same time the Adobe Flash Player update was installed. Thus, the evidence is unshakeable that part of the security update includes a device driver of some sort or another. Here’s that log entry:

1  [Boot Session: 2018/06/08 10:41:05.428]>>>  [Finish Install Action – USB\VID_046D&PID_C52B&MI_02\6&44B3556&0&0002]
2  >>>  Section start 2018/06/10 08:42:21.371
3  dvi: {Build Driver List} 08:42:21.375
4  dvi:      Searching for hardware ID(s):
5  dvi:           usb\vid_046d&pid_c52b&rev_2406&mi_02
6  dvi:           usb\vid_046d&pid_c52b&mi_02
7  dvi:      Searching for compatible ID(s):
8  dvi:           usb\class_03&subclass_00&prot_00
9  dvi:           usb\class_03&subclass_00
10 dvi:           usb\class_03
11 dvi: {Build Driver List – exit(0x00000000)} 08:42:21.385
12 dvi: Class GUID of device changed to: {745a17a0-74d3-11d0-b6fe-00a0c90f57da}.
13 dvi: {DIF_FINISHINSTALL_ACTION} 08:42:21.385
14 dvi:      Using exported function ‘CoDeviceInstall’ in module ‘C:\WINDOWS\system32\LkmdfCoInst.dll’.
15 dvi:      CoInstaller 1 == LkmdfCoInst.dll,CoDeviceInstall
16 dvi:      CoInstaller 1: Enter 08:42:21.392
17 dvi:      CoInstaller 1: Exit
18 dvi:      Default installer: Enter 08:42:21.393
19 dvi:      Default installer: Exit
20 dvi: {DIF_FINISHINSTALL_ACTION – exit(0xe000020e)} 08:42:21.393
21 <<<  Section end 2018/06/10 08:42:21.394
22 <<<  [Exit status: SUCCESS]

Digging Into Details

A search on the device ID involved, however — namely usb\vid_046d&pid_c52b&rev_2406&mi_02 (line 5) — tells me it’s actually a Logitec device driver. Most likely, it’s for the Universal USB Receiver that connects to my RF-based M325 mouse. So actually, Flash Player isn’t responsible. It’s something that came along for the ride with the Flash player. In fact, the issue is that even after restarting the machine in the wake of the update, the install status of the driver fails to clear. The “Configure a device” troubleshooter keeps displaying the same status, no matter how many times I restart my PC. Here’s what that looks like:

Fixing Win10 Restart PC to Finish Installing Drivers Issue.troubleshooter

The desired transformation failed to occur, despite numerous restarts. Sigh.
[Click image for full-sized view.]

Some quick research on Bing led me to some possible fixes. The first one I tried indicated that an anti-malware package could interfere with the proper status reset during the restart process. So I disabled Norton on my PC for 15 minutes, restarted the machine, and presto! Problem solved. It just goes to show that you can indeed figure out how to fix many Windows gotchas, if you carefully collect the evidence available and let it lead you to a solution online. Case closed, thank goodness!


June 8, 2018  2:20 PM

VDI vendors must change tack as on-premises market slows

Alyssa Provazza Alyssa Provazza Profile: Alyssa Provazza
cloud, DaaS, Desktop virtualization, Desktop Virtualization Implementation, End user security, survey, VDI

Several factors have slowed new on-premises VDI adoption, and VDI vendors are forced to shift their strategies as a result.

VDI projects in the design, pilot and rollout stages make up a tiny portion of VDI environments, and they have decreased over the past year, according to the State of the EUC 2018 report released in May. Just 1.18% of respondents said their on-premises VDI is in the newly designed or proof-of-concept phase, down from 3.07% in 2017, according to the survey by research initiative VDI Like a Pro. Meanwhile, 41.3% said their VDI has been in production for two to four years, with 33.92% in production for five years or longer.

That’s because most IT departments interested in deploying VDI likely have already done so. Major challenges that cropped up around the technology — storage capacity, GPU power, cost — have since been considerably eased.

Very large organizations or even higher-end mid-market companies with 3,000 to 5,000 users are still good candidates for VDI, but they’re hesitant to move because of the time commitment, said Dane Young, strategic business advisor at Entisys360, an IT consultancy based in Concord, Calif.

“Now we’re dealing with the harder long pole in the tent — the slower adopters,” Young said. “They recognize that they need to, but also that it’s a three- to five-year plan. It takes a lot of time to move a couple thousands users into that environment.”

VDI vendors can gain new ground by focusing their attention on these companies — and pushing the security benefits.

“The number one trend that we’re seeing drives these types of VDI or app delivery initiatives has been security,” Young said. “IT leaders need to… involve their security [team] early and often.”

Desktop and application as a service has also shifted IT’s interest away from on-premises VDI. This trend presents new opportunities for vendors that provide VDI management and monitoring because IT needs tools aimed at handling these cloud workloads.

Another way for VDI vendors to find new customers may simply be a renewed emphasis on winning business from competitors, said Ruben Spruijt, CTO of cloud workspace provider Frame and an author of the report, along with Mark Plettenberg, senior product manager at Login VSI.

“The vendors will look at customers who are replacing their hardware or are not totally satisfied with the vendor that they have,” Spruijt said. “As the market matures, the way that VDI vendors engage with the customer has to change.”


June 8, 2018  12:23 PM

Ctrl+Winkey+C Toggles Win10 Display to Grayscale Mode

Ed Tittel Ed Tittel Profile: Ed Tittel
Display Attribute, Screen display, Windows 10

Here’s something freaky about Win10 that seemingly comes up more often by accident than by design. Based on periodic OMG posts on TenForums and answers.Microsoft, and my own experience, it strikes from time to time. It rests on a three-key sequence: Ctrl, Winkey  and the letter “C.” Struck together, they toggle a Win10 display between grayscale and normal color. That means if the display is in normal color mode (as it will be by default), this causes the display to switch to black-and-white. For those who don’t do it on purpose (or, as I read in at least one case, whose cat treading on the keyboard did it for them) it seems like something’s gone wrong to leach all the color out of windows. Because Ctrl+Winkey+C toggles Win10 display to grayscale mode, you need only repeat the toggle to return to full color.

Here’s a side-by-side comparison using three Google News items to illustrate:

Ctrl+Winkey+C Toggles Win10 Display to Grayscale Mode.colorCtrl+Winkey+C Toggles Win10 Display to Grayscale Mode.bw

Full color version on top, grayscale version on the bottom. [Click either image for full-sized view.]

How Ctrl+Winkey+C Toggles Win10 Display to Grayscale Mode

This behavior comes enabled in Windows 10 by default. But it’s easy to reverse (as long as you remember the secret key combo). You can also turn it off by typing “color filter” into the Windows 10/Cortana search box. This opens the “Color Filters” page in Settings. There, you can turn color filters off if they’ve been mistakenly turned on. The checkbox labeled “Allow the shortcut key to toggle filter on or off” can also be disabled, if you like.

Ctrl+Winkey+C Toggles Win10 Display to Grayscale Mode.filters

A slider and a checkbox control the presence or absence of color filters, and the efficacy of the three-key-sequence.

For those bitten by this phenomenon by accident or mistake, unchecking the checkbox prevents an unwanted recurrence. Instead of remembering the key sequence that returns your system to normal, you must instead remember the Color Filters page. There, you can manage color filters manually. It’s kind of an interesting trade-off, isn’t it? Personally, I’m sticking with the three-key sequence myself.


June 6, 2018  12:02 PM

NirSoft NetBScanner Offers Win10 LAN Insights

Ed Tittel Ed Tittel Profile: Ed Tittel
IP networking, NetBIOS, Windows 10

Nir Sofer is a prolific developer of Windows tools for all kinds of uses. His NirLauncher utility console brings over 200 tools together, at last count. After massive reporting of LAN issues for Version 1803, I re-discovered his excellent NetBScanner utility. It scans local subnets nicely, and produces readable reports on what it finds. My LAN is on a private Class C subnet 192.168.1.x. The tool quickly scanned through all 256 LAN addresses and produced a table of the occupied addresses. Because the data is nicely pruned and formatted, NirSoft NetBScanner offers Win10 LAN insights that are immediate and useful.

NirSoft NetBScanner Offers Win10 LAN Insights.nbscanoutput

Only occupied IP addresses show up, with all the useful and interesting values ready to hand.
[Click image for full-sized view.]

How NirSoft NetBScanner Offers Win10 LAN Insights

The problem with built-in command line tools is that they make it difficult to pair up NetBIOS names, IP addresses, MAC addresses, and adapter vendor info in a single glance. NetBScanner does all that in one swell foop, and provides NetBIOS Master Browser status as well. This tool came in very handy as I was trying to make my LAN nodes visible to the other Windows 10 hosts on the network after upgrading to 1803 earlier this month. I’ve also read online that numerous other regulars and members at TenForums have benefited from using this nice little tool, too.

Although NetBIOS has a deserved reputation as something of a “Zombie protocol” (the protocol that wouldn’t die), it’s still around. And it’s still the cornerstone for LAN access and use among Windows PCs. Thus, ready access to this tool will help you see and figure out what’s up on your Windows LAN, should trouble rear its ugly head. And indeed, it helped me figure out that several of my nodes had switched from private to public network status after applying the 1803 upgrade. A quick switch back, and some tweaks to the Defender Firewall, and I was able to see and interact with my entire LAN cohort, as shown in the preceding screenshot.

If it worked for me, chances are pretty good it will work for you, too. Give it a try, please!


June 4, 2018  12:20 PM

Set Win10 RS5 Rollback Retention Interval

Ed Tittel Ed Tittel Profile: Ed Tittel
DISM, rollback, Windows 10

I don’t normally write much about the Insider Preview builds for this blog post. Practicing Enterprise admins have enough on their hands keeping up with current branch versions of the OS. But when I see new features of potential benefit, I break that restriction happily. As of Build 17682, the built-in Deployment Image Servicing and Management (DISM) command gains an interesting new capability. At the command line, you can tell it to alter the default 10-day retention period for keeping Windows.old around. That means when the next version of Windows 10 goes into production, you can set a rollback period of your choosing simply and easily. Thus, it’s piece of cake to set Win10 R5 rollback retention interval however you like it.

How to Set Win10 RS5 Rollback Retention Interval?

Here’s a PowerShell screen capture that shows me:

  • inquiring about the current interval
  • re-resetting that interval to 12 days
  • showing that changed value

Set Win10 RS5 Rollback Retention Interval.dism-examples

DISM /ONLINE is a given, because we’re working on a loaded (and running) Windows image. The new cmdlets are Get-OSUninstallWindow and Set-OSUninstallWindow.
[Click on image for full-sized view.]

The syntax for Get-OSUninstallWindow is dead simple. By itself, it shows you the current number of days the OS will keep Windows.old around, thereby allowing rollback to occur. Set-OSUninstallWindows takes an integer value for the /Value attribute. It resets the retention interval to whatever number of days you specify. Thus, I show the intial value as a default of 10 days. I reset that to 12 days, and use Get-OSUninstallWindow again to show the change has been applied.

What’s Your OSInstallWindow Choice?

It’s whatever you want it to be. If you build canonical images for deployment, you can use this DISM command on a running instance of that canonical OS to make this change while it’s online. Note that MS Docs “DISM operating system uninstall command-line options” includes this warning: “OEMs shouldn’t use this setting in imaging or manufacturing scenarios. This setting is for IT administrators.” That said, I don’t see a downside to changing this in a canonical image prior to its deployment to testing or production. And then, your rollback interval will be whatever you choose!

What If These Commands Don’t Work? [Added 6/25/18]

If you don’t have a Windows.old folder on your PC you can’t use the Get or Set -OSUninstallWindow parameters on DISM successfully. I can’t say why MS did this, but if you run either command on a Windows 10 1803 or higher PC that has already been cleaned up after its most recent upgrade, you’ll get an error that reads “The system cannot find the path specified.” That’s because the command goes off looking for Windows.old. If it doesn’t find that entry, you get the error. If it does find the entry, get shows you the current size of that window in days, while set lets you change the value from its default of 10 days. You’ve been warned. Go Figure!


June 1, 2018  12:42 PM

AdDuplex-based Win10 Uptake Projections Mostly Bogus

Ed Tittel Ed Tittel Profile: Ed Tittel
User information, Windows 10

I’ve found myself shaking my head in disbelief over the past weeks as stories about incredible uptake rates for Version 1803 have appeared. Usually credible writers such as Peter Bright at Ars Technica and Liam Tung at ZDNet have been taken in on some numbers based on observations from AdDuplex which describes itself as a “leading cross-promotion network for Windows Phone and Windows applications.” Alas, as my old buddy and fellow Windows Insider MVP Ed Bott observes, “the inclusion of Windows Phone, a now defunct product … should be a red flag” when it comes to assessing AdDuplex’s credibility and veracity as a broad base for statistical anything. In fact, Mr. Bott convincingly argues at ZDNet that characterizing AdDuplex-based Win10 uptake projections mostly bogus is absolutely correct.

AdDuplex-based Win10 Uptake Projections Mostly Bogus.welcome1803

It’s impossible for half the user base to have updated to 1803 already.

Why Say AdDuplex-based Win10 Uptake Projections Mostly Bogus?

AdDuplex’s numbers extrapolated to the entire Windows installed base indicate that half that population has already updated to Version 1803. As Mr. Bott observes in his article (and I had independently concluded on my own) this is flatly impossible. Microsoft has just reported on June 1 at its Build 2018 meet-up, as per this Neowin story, that “there are over 700 million active Windows 10 devices.” Thus, that would mean somewhere in the neighborhood of 350 million devices already upgraded to 1803. Simply put, that’s not true (or possible).

Here’s why. The extrapolation comes from data collected on about five thousand Windows Store apps with the AdDuplex SDK embedded inside them. Bott reports a principal at AdDuplex puts the number of devices sampled at “over 100,000.” As Bott observes, that’s less than 2.14 x 10-6 (0.00000214) of the total Windows population. (I adjusted his 600M baseline to the 700M baseline confirmed by MS this morning.) The kicker is that only AdDuplex apps use the SDK. Many of those apps are mobile (a mostly defunct and vanishing platform). In fact, they focus primarily on what Bott describes as “casual games … and some utility apps.”

A Shaky Foundation for All Windows Users

What kind of basis is that for making projections about the Windows user base? Bott submits, and I concur, that it’s not a very good one. For one thing, it completely omits the 200M enterprise/business users of Windows 10 (as reported in this 5/8 ComputerWorld story), none of whom are likely to have anything to do with AdDuplex data acquisition. For another, the mobile focus in AdDuplex represents an odd and vanishing subset of Windows 10 users. And finally, there’s the practical observation that MS deliberately stages its release of new feature upgrades, and withholds the upgrade through Windows Update for older and potentially more problematic PCs. It also blocks the update for machines with known gotchas (such as the Intel 600p series SSDs, which didn’t work with 1803 until KB4100403 was released on May 23) until fixes are ready.

Flatly stated, there’s no way in heaven or hell that half of the user base is at 1803 just yet.  It’s simply not possible, and thus, completely unlikely  as well. As the old data analysis maxim goes: “Garbage in, garbage out!”


May 30, 2018  11:32 AM

Two Win10 Setup.exes Offer Differing Capabilities

Ed Tittel Ed Tittel Profile: Ed Tittel
Dual booting, Setup and deployment, Windows 10

Hey! I just learned a cool Windows 10 installation trick for dual or multi boot scenarios. Turns out there are two different versions of setup.exe on a typical bootable USB flash drive (or other installation media). One resides at the root of the drive, the other in the \sources folder. Run the version at the root while Windows is running, and you’ll launch into a typical in-place upgrade repair install scenario. This is great for system repairs. Run the version in the \sources folder, and you can launch a separate install that targets some partition other than the current boot/system partition. And that, dear readers, is why I entitled this post two Win10 Setup.exes offer differing capabilities.

How Do Two Win10 Setup.exes Offer Differing Capabilities?

Upon closer examination, although both setup.exe files share the same name, they do differ. Here are the properties Details for each one, side-by-side:

Two Win10 Setup.exes Offer Differing Capabilities.details

\sources version on the left, UFD root version on the right. Notice the difference in file sizes (272 vs 78.8 KB).
[Click image for full-sized view.]

Just for grins, I ran the file comparison command (FC) and the old WinDiff utility against the two versions. Because they’re binary files (which I didn’t attempt to reverse compile) all I can see is that there are indeed lots of differences between the two files. Also, the \sources version has a lot of stuff in it that the root version does not. That’s what I’d expect, based on the difference in file sizes.

The key distinction comes from the uses to which these two different setup files may be put. The \sources version works to set up dual- or multi-boot at runtime inside Windows 10 itself. No need to boot to alternate media and run the installation outside your normal, comfortable runtime. The root version is for performing upgrade installs (or repairs) to the OS that’s currently running. Good to know!

[NOTE] Here’s a shoutout to TenForums.com fellow guru and regular NavyLCDR, who in turn credits rescue media maven Kyhi for this trick in thread#7 of a post entitled Boot 2 copies Win10 Pro in Separate Partitions. Thanks, guys!


May 25, 2018  12:18 PM

HID Woes Cause Overkill Win10 Repair

Ed Tittel Ed Tittel Profile: Ed Tittel
Computer mouse, Troubleshooting, Windows 10

How’s this for irony? Two days ago, I wrote a story for SearchEnterpriseDesktop explaining what to do if a mouse and/or keyboard go missing in Windows. Yesterday morning, when I sat down at my primary PC, my user interface was totally bollixed. Ultimately, I determined the cause was a failing wireless mouse. But there were a few wrong turns before that diagnosis became crystal clear. It definitely woke me up, but it also wasted most of my morning. If you’ll recall, HID stands for human interface device in Windows-speak. And that’s why I entitled this post HID woes cause overkill Win1o repair. If this story has a moral, it should be “swap the hardware first” whenever devices get weird.

HID Woes Cause Overkill Win10 Repair.M325replacement

This cheap and colorful little mouse ultimately rode to my rescue, but only after some spinning of the wheels.

How Did HID Woes Cause Overkill Win10 Repair?

My problem was that I jumped to a software diagnosis for what was a purely hardware problem. Had I followed my own advice from the preceding day’s story, my second step after restarting the PC (I did do that) should have been to “Try a substitute device.” Had I done that, the story would have come to an immediate, positive and workable solution. But no! Problem is I’ve been reading so much about driver issues for mice and keyboards on Windows Version 1803 (aka Spring Update) that I immediately assumed I’d been bitten by a driver problem. Wrong!

The nearest I can figure, what REALLY happened is that the RF transmitter in my Logitech M325 mouse started failing intermittently. It worked to some extent most of the time, but would cut out completely 3-4 times a minute. Unfortunately, this caused my keyboard to act weird as well. I think it was fighting for USB bus access with the failing mouse radio. They share the same USB 2.0 hub on my production PC, as fate would have it. So when the mouse starting picking up and dropping, and picking up and dropping, the keyboard also started having issues communicating with the PC. Ouch!

After completely removing and reinstalling only generic HID device drivers, my problem remained. And then, when that didn’t change after I performed an in-place upgrade repair install, I knew it HAD to be the hardware (nothing else was left). So I ran upstairs, borrowed my son’s high-end wired Razer gaming mouse, plugged it in, and Presto! my problems vanished. I ruefully remembered one more reason why intermittent failures are the hardest to find and fix. So my new M325 ($13 + tax at Fry’s) banished all remaining ills — for the time being, at least.

Sigh.


May 23, 2018  1:15 PM

Win10 NetBIOS Names Get Weirder

Ed Tittel Ed Tittel Profile: Ed Tittel
Hostname, Name resolution, NetBIOS, Windows 10

Last Friday, I observed in a post here that machine names appeared case sensitive in RDP. Indeed they are — kind of — and in other places, too. This includes the ancient and venerable PING command, a go-to utility to check connectivity between IP hosts. In trying to get all of my PCs to show up on the LAN, I turned to PING to see who was reporting in and who wasn’t. Along the way I observed some fascinating and surprising case sensitivity in PING itself. Here’s an illustrative screen capture from PowerShell:

Win10 NetBIOS Names Get Weirder.dvp-ping

An abridged version of PING attempts using the same base string, with differing upper- and lower-case chars.

Why I Insist That NetBIOS Names Get Weirder and Weirder

The following table sums up the results from the preceding sequence of PING attempts (plus another item I chose not to include). It basically shows that NetBIOS name resolution has its apparent quirks.

Variations on a NetBIOS name: DellVP11
Name string Ping result Capitalization map
dellvp11 succeeds llllllnn
Dellvp11 succeeds Clllllnn
DEllvp11 succeeds CCllllnn
DELlvp11 succeeds CCClllnn
DELLvp11 succeeds CCCCllnn
DELLVp11 succeeds CCCCClnn
DELLVP11 succeeds CCCCCCnn
DellVP11 FAILS ClllCCnn
DellVp11 succeeds ClllClnn (not shown)

To me, there’s one captivating thing about the outputs. The only string that DOESN’T work is also the same string that PING uses itself — namely, DellVP11. That’s ClllCCnn, in the notation of the table. This denotes: initial cap, followed by three lower-case letters, two more cap letters, and two digits, in case you wondered.

A Surprising Finding for NetBIOS Names

It turns out there’s good reason for PING to use that specific NetBIOS name for the Venue Pro. The Microsoft Developer Network Documentation says this about NetBIOS names (emphasis mine):

Neither [RFC1001] nor [RFC1002] discusses whether names are case-sensitive. This document clarifies this ambiguity by specifying that because the name space is defined as sixteen 8-bit binary bytes, a comparison MUST be done for equality against the entire 16 bytes. As a result, NetBIOS names are inherently case-sensitive.

There’s only one way I can find to get the “real NetBIOS name” for a Windows 10 computer. It requires checking the Computer Name field in the Control Panel’s System element. On my Venue Pro, that field reads “DellVP11” (ClllCCnn). Go figure! It’s the only name that DOESN’T resolve in PING. This makes no sense to me whatsoever, but it’s indisputably true — on this particular PC at least.

On some of my other PCs, PING accepts all variants of the machine name. The case of individual letters doesn’t matter. On others, it does. As I’ve already reported for my T520 Lenovo laptop, “T520” doesn’t work but “t520” does– and the latter is the apparent actual NetBIOS name string. For my X220 Tablet, “X220T” doesn’t work, but all three other possible variants do (“x220T” “X220t” and “x220t”, of which “x220t” is the actual NetBIOS name string).

Again: weird! I sure hope MS comes up with some kind of fix for this. Because most IP utilities report the machine name in upper case only, seems like that should be the canonical form for such names. We’ll just have to wait and see how it all plays out…


Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: