Windows Enterprise Desktop

March 23, 2018  5:15 PM

Script Out Your Win10 Build History Using PowerShell

Ed Tittel Ed Tittel Profile: Ed Tittel
history, Windows 10

I just came across a fascinating pair of PowerShell commands. Run in an administrative PowerShell session, they’ll tell you every build your system has had installed on it since the last clean install was performed. That’s why I say you can use these items to script out your Win10 Build History using PowerShell.

These commands come to you through an interestingly circuitous route around the Northern Hemisphere of Planet Earth. I got them from Russian blogger Sergey Tkachenko at He got them from somebody named (whose domain name, at least is in Germany and post was in German). Originally they came from user sizzlr at Reddit (location unknown, but who writes American English like a native speaker).

How to Script Out Your Win10 Build History Using PowerShell

All you need to do is cut and paste the content for each line item below from this blog post into an administrative PowerShell session. Copy Line 1 first, then paste it, then hit enter (only the monospaced text, please). Repeat that same process for Line 2 (ditto).

Line 1:cls

$AllBuilds = $(gci "HKLM:\System\Setup" | ? {$_.Name -match "\\Source\s"}) | % { $_ | Select @{n="UpdateTime";e={if ($_.Name -match "Updated\son\s(\d{1,2}\/\d{1,2}\/\d{4}\s\d{2}:\d{2}:\d{2})\)$") {[dateTime]::Parse($Matches[1],([Globalization.CultureInfo]::CreateSpecificCulture('en-US')))}}}, @{n="ReleaseID";e={$_.GetValue("ReleaseID")}},@{n="Branch";e={$_.GetValue("BuildBranch")}},@{n="Build";e={$_.GetValue("CurrentBuild")}},@{n="ProductName";e={$_.GetValue("ProductName")}},@{n="InstallTime";e={[datetime]::FromFileTime($_.GetValue("InstallTime"))}} };

Line 2:
$AllBuilds | Sort UpdateTime | ft UpdateTime, ReleaseID, Branch, Build, ProductName

Sampling a Win10 Build History

Here’s what the output from my production desktop looks like in PowerShell:

Script Out Your Win10 Build History Using PowerShell

The sequence captures my journey from Win 10 Pro to Enterprise Insider to Enterprise current branch.
[Click image to see full-sized view.]

I’m not sure that anybody really NEEDS this capability. But it is very interesting to look at the sequence of builds that have come and gone on most PCs. My fast ring PCs produce listings with 93(!) entries in that list, starting with Build 10547 on 10/17/2015 and ending with Build 17123 on 3/20/2018 (and that’s because I haven’t rebooted that machine to upgrade it 17128 just released this afternoon). Great stuff!

Here’s that lengthy list in all its glory:

March 21, 2018  11:14 AM

Reducing Win10 Upgrade Offline Time

Ed Tittel Ed Tittel Profile: Ed Tittel
Windows 10, Windows Update

Last week, the Windows Insider blog featured a notable bit of information. Under the somewhat bland heading of “feature update improvements” Joseph Conway (Sr. Program Manager, Windows Fundamentals (Deployment)) dropped some fascinating information. Talking about feature update installation, he reported that a new and improved model comes built-in when 1803 goes public in the near future. In fact, reducing Win10 upgrade offline time remains a major design goal for that release.

What’s Up with Reducing Win10 Upgrade Offline Time?

FYI, offline time means that a PC is unavailable/unusable. Simply put, reducing offline time during an upgrade means more time for the user do something while the upgrade is underway. The blog post includes a peachy table that shows old vs. new feature update models, so I reproduce it here:

Reducing Win10 Upgrade Offline Time

Items on upper right in dark black moved from offline into online processing explain a huge time difference.
[Click on image to see full-sized view; Source: Windows Insider Blog 3/16]

Offline Time Savings?

The numbers are pretty interesting. Under the old model offline time averaged 82 minutes for a Windows feature upgrade. The post explains that this number is based on telemetry during the millions of upgrades to version 1709 (aka the Fall Creators Update) late last year. For the upcoming 1803 release, which uses the new model, average offline time has dropped to 30 minutes. As the blog post proclaims: “That’s a reduction of 63% from the Creator’s Update!” I notice that the blog post fails to address whether or not the overall install time has changed, either for the worse or the better. Having been through dozens of such Insider installs for the forthcoming 1803 release, my personal impression is “Not much.” I don’t mean to diminish this accomplishment, but I must observe that for corporate/enterprise users, they probably won’t be using their PCs while they’re upgrading anyway.

The Real Value of These Process Models

To me, the real value of these process models comes from the details about what goes on during the feature upgrade installation process. By extension, in fact, this provides a pretty good model for Windows installation in general. Thus, either list of steps is a good one. I reproduce the NEW list verbatim, in numered form because it’s what Windows users face looking foward. For this list, I don’t much care which parts are online and which parts offline, either.

  1. PC checks for available feature updates (manually or automatically)
  2. Feature update payload is downloaded
  3. User content is prepared for migration
  4. New operating system is placed into a temporary working directory
  5. PC waits for a required reboot to begin update installation
  6. PC reboots to begin update installation process
  7. Drivers and other required operating system files are migrated
  8. User content is migrated
  9. PC reboots and completes the update
  10. OOBE begins

This new model gives us a nice timeline against which to plot errors. It also means when errors occur, one can make a good guess about the issue involved based on the current active phase. I’ll make ongoing, detailed observations over the next few months. Then, I’ll build and populate that map as best I can. Stay tuned: I’ll write this up when I have enough data to make it worth sharing.

March 21, 2018  8:11 AM

VMware Workspace One gets intelligent

Colin Steele Colin Steele Profile: Colin Steele
AirWatch, VMware, VMworld

Details have emerged about several new VMware Workspace One capabilities that IT pros got a preview of last year.

VMware Workspace One Intelligence, Mobile Flows and support for the Microsoft Graph API for Intune are now all generally available, VMware said today. The company originally announced the features at its VMworld conference last August.

Let’s take a look at the three components:

Workspace One Intelligence monitors and analyzes data from users’ devices and applications and enables IT to automate responses to security threats, application crashes and other issues. It uses technologies from VMware’s AirWatch compliance engine and Apteligent, an app analytics vendor VMware acquired last year. Applications must integrate with Apteligent’s APIs to provide performance and user behavior data to VMware Workspace One Intelligence, but the product can provide insights around user adoption, software licenses and more natively, VMware said.

Mobile Flows build common business processes directly into VMware’s mobile email app, Boxer. If a sales rep receives a request for a quote from a new customer, for example, he can create a new contact in Salesforce by pressing just one button in Boxer — instead of having to open the Salesforce app, sign in and then create a new contact. VMware plans to expand Mobile Flows into other apps besides Boxer, but those capabilities are not available at this time.

Support for the Microsoft Graph API for Intune enables IT to manage Office 365 mobile apps directly through AirWatch. But organizations must have both AirWatch and Intune licenses to use this feature.

Coming soon in VMware Workspace One

VMware also announced some additional capabilities that will be available later this year. The Workspace One Trust Network will allow third-party security vendors to feed data into Workspace One Intelligence, providing IT with even more insights into their users’ devices and applications to detect threats. Participating vendors today include Carbon Black, CrowdStrike, Cylance, Lookout, McAfee, Netskope and Symantec.

Another upcoming offering, AirLift aims to help IT more easily manage Windows 10 devices with VMware Workspace One and Microsoft System Center Configuration Manager (SCCM). Those co-management capabilities already exist, but AirLift will provide a console for administrators to select which tasks to perform with Workspace One and which tasks to leave to SCCM. The console will be available in April, VMware said.

March 19, 2018  3:28 PM

Logon times play key role in virtual desktop UX monitoring

Eddie Lockhart Eddie Lockhart Profile: Eddie Lockhart
published applications, VDI

Almost everyone who’s ever used a computer has sat, head in hand, frustratingly waiting for the desktop to start up. If this productivity loss runs rampant in a VDI deployment, it can have a real cost, so it’s important for IT to get a handle on logon times.

If users detect a decline in virtual desktop performance from what they were used to with physical desktops, they are likely to revolt against the technology. To quantify the effect bloated logon times can have, ControlUp, a monitoring software provider in San Jose, Calif., conducted a study on logon performance for virtual desktops and published applications. The results showed the importance of shorter logon times and consistency.

Gone in 31.9 seconds

The average logon time for virtual desktops was 31.9 seconds with a median of 23 seconds, according to the ControlUp study, presented in a webinar last week. The study, which tracked logons over almost two years across 876 organizations, defined desktop logons as the length of time from the instant a user enters his correct credentials to the moment the Start button becomes clickable.

The median indicates that half of the logons took 23 seconds or less, while the much higher average shows that there are significant outliers pulling the mean up — suggesting that many organizations have problems with logon consistency.

If logon times fluctuate significantly, users may be unhappy because they cannot rely on their desktops to start the same way every time. Time of day can be a key factor, as logons may take longer when more users within an organization are active at once. IT must allocate resources correctly throughout the VDI deployment to deal with peak usage times.

The discrepancy between the average and the median was not as significant for published apps, because they are less complex. The average time was 16.44 seconds, and the median was 12. Published app monitoring is important, because apps are the lifeblood of most users’ productivity.

Longer logon times for desktops and apps can be caused by oversized user profiles, resource contention issues, or misconfigurations after a storage array or network drive relocation. One way to reduce logon times is to use monitoring tools that can help pinpoint the source of slowdowns. In addition to ControlUp, products include VMware vRealize Operations for Horizon, Login PI from Login VSI, Goliath Technologies’ Logon Simulator and the Comtrade management packs for Citrix.

Quantifying the results

Organizations can get time and cost savings by reducing logon times.

OneWorld Community Health Centers in Omaha, Neb., used ControlUp’s monitoring tool to gather and analyze logon data, which revealed that the infrastructure had a VM sizing issue, said IT director Steve Elgan, in the webinar. His team added more processors with more RAM and changed the ratio of virtual CPU to physical CPU to one-to-one — reducing desktop logon times by 14 seconds. The company calculated that it saves about $10,000 per year because of time saved, and allows each doctor to see about seven extra patients each year.

March 19, 2018  3:26 PM

Understanding NTUser.dat in Windows 10

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

Saw a fascinating question on TenForums this morning, as I was making my “morning run” though the new threads there. It appeared in a thread named “ntuser.dat” and read “Why do I have so many ntuser.dat files?” Being one to look for evidence any time Windows quirks or behaviors are described, I immediately fired up voidtools’ (Search) Everything to look for that string in my file system. Right now, it turns up 60 objects, of which many are logs or pending registry transmissions (files of type .regtrans-ms). But there is also one file named ntuser.dat and eight more files named NTUSER.DAT. Obviously, there’s something interesting and useful going on with all these copies. And, as it turns out understanding NTUser.dat in Windows 10 hinges on understanding user profiles and typical accounts on a Win10 systems.

Understanding NTUser.dat in Windows 10

Of the 60 items with “ntuser.dat” in their names, these nine items shown take that name precisely on my production PC. What gives?

Why Bother Understanding NTUser.dat in Windows 10?

As it happens, each and every user profile created on a particular running instance of Windows 10 has its own NTUser.dat file. This file contains personal files and preference settings particular to each such user. As you can tell from looking at those files on my production PC (depicted in the preceding screenshot), this includes default and “behind-the-scenes” accounts as well as user accounts. That’s why we see a system account (…System32\Config\systemprofile), various service accounts (… NetworkService and …LocalService), and dot-NET accounts (dot-NET v4.5 Classic and dot-NET v.5), plus Administrator, Default and DefaultAppPool accounts. The only real user account is C:\Users\etitt. It reflects my Microsoft Account, which starts with the 5 characters “etitt”.

As it also turns out, messing with files with this name is NOT a good idea. Deleting an NTUser.dat file destroys the associated account’s preferences and settings and may even corrupt the associated user profile. Each such file has one or more backups, which appears as a file named NTUser.dat.log. If an error occurs in the master copy of NTuser.dat, Windows can use one or more log files to correct it. NTUser.ini files describe roaming profiles used in networked environments. You can rename this file But that changes the user profile from a user-controlled profile to a locked-down profile that users can alter only temporarily (changes are not saved when the user logs out).

Writing the NTUser.dat happens during login; essentially, it’s a copy of the Windows Registry’s HKEY_CURRENT_USER hive. The contents of the user profile changes constantly over time: it reflects changes that occur while Windows is running. Windows size and position, for example, changes each time you open, move, or resize an application window. And that’s just the tip of a very large iceberg of data that goes into keeping constant track of user activity.

How NTUser.dat Changes

Though user settings, preferences, and so forth change at runtime, NTUser.dat stays static. Rather, those changes go into a raft of  .regtrans-ms files that Windows 10 creates. Windows 10 processes these files whenever a user logs out, or the system shuts down or restarts. This controls and manages Registry writes, much like a “database commit” operation. (Note: database commit is a complex and interesting concept with many wrinkles, with much thought and effort required for proper implementation. For now, this means “changes either happen completely, or they don’t happen at all”. That keeps databases — including the Registry, in this case — consistent at all times.)

Thus, even when an uncontrolled shutdown or a BSOD occurs, NTUser.dat remains OK. User settings and preferences changes from the preceding session are lost. But user profiles remain intact and consistent.

I completely agree with long-time TenForums VIP and Guru member Bree (identified in the “ntuser.dat” thread mentioned at the outset of this blog post). Here’s his take on messing with or deleting files named NTUser.dat: “Best leave them alone then.” Well said, and advice worth following!

March 16, 2018  12:50 PM

Check Current Win10 for In-place Upgrade Repair

Ed Tittel Ed Tittel Profile: Ed Tittel
Repair, Troubleshooting, Windows 10

Just yesterday, I had an article go live on ComputerWorld. Its title explains its focus: “How to fix Windows 10 with an in-place upgrade install.” I’ve already gotten a couple of emails from readers informing me they tried this, and get only a clean install as an option when they fire off setup.exe. There are many reasons why this can happen, all of which are enumerated in that selfsame story. (See the section labeled “Sounds to good to be true; what’s the catch?”) But there are ways to check current Win10 for in-place upgrade repair to make sure the ISO you use will work with the running image. I’ll enumerate them here, to help would-be repair-persons succeed in their repair attempts.

How to Check Current Win10 for In-place Upgrade Repair

The conditions that must be met include specific items for the image that’s running and the image from which repairs are made. I’ll march through most of these one at a time in the sub-sections that follow, but will dispatch a couple of them here immediately. First, to run setup.exe in Windows 10, you must be logged into an administrative account. But because you must be able to run cmd.exe or PowerShell as an administrator to execute most of  the following commands, I take that as a given for anyone who attempts an in-place upgrade for repairs. Second, to attempt an in-place upgrade for repair purposes, the OS must be running well enough for setup.exe to run to the point where the system reboots for the first time. After that, the installer takes over and the old OS is no longer in charge of the PC.

Third, the system drive (the SSD or hard disk on which Windows resides) must have enough free space for repairs to complete. How much free space is that? It’s about 9GB more than the space that Windows itself consumes on disk. According to WinDirStat for my production PC, for example, that comes to 28GB (18.9 GB for Windows 10 and another 9GB for workspace, rounded up).

Determine Win10 “Bittedness”

Windows 10 comes in 32-bit (x86) and 64-bit (x64) architectures. You can check this at the command line by typing wmic os get osarchitecture. Here’s what comes back in response on my production PC using PowerShell:

Check Current Win10 for In-place Upgrade Repair.bittedness

The output clearly states that this PC is running a 64-bit architecture. That means the chosen repair image must match. The ISO one grabs to use for repair will always include its bittedness. You’ll be asked to explicitly choose either a 32- or a 64-bit download.

Get Win10 Version/Build Info

You can use the built-in Win10 utility winver.exe to obtain this information. You can run this from the start menu or type the program name into the administrative command prompt or PowerShell window. Either way, it’s going to open in its own Window on screen, like this:

Check Current Win10 for In-place Upgrade

As you can see, the version is identified as 1709, and the build number is 16299.309. Don’t close this window just yet, it also provides information for the next sub-heading as well. When you grab an ISO for repair it will be identified primarily by its version (build) number. That means you’d have to download an ISO numbered 16299 or higher, for the build identified in the preceding screen capture. Right now the current Win10 Enterprise Insider Preview build is 17115, as I write this post.

Get Win10 Edition Info

Notice the line in the preceding window immediately following the © Copyright notice. It reads “The Windows 10 Enterprise operating system…” The fourth word in the sentence identifies the edition. Thus, a Windows 10 Home install would say “The Windows 10 Home operating system…” instead. Likewise for Pro and Education editions. You can also type wmic os get caption to produce this information as well. Here’s what that looks like from PowerShell:

Check Current Win10 for In-place Upgrade Repair.edition

As you can see, this identifies the edition as “Microsoft Windows 10 Enterprise.” This is the selfsame edition that must be used in any attempted in-place upgrade repair install. The name of the ISO usually includes this information when grabbing one to use for repairs. The edition is also identified explicitly when downloading an ISO for Windows 10, so pick one that matches what’s running.

Get Win10 Language Info

The deployment image servicing and management (DISM) command can report on language information for Windows images, on and offline. Checking the language information for the running image is easy, but the output is verbose. The DISM command to use on a running image is DISM /online /get-intl. Here’s the command and its output from PowerShell:

Check Current Win10 for In-place Upgrade Repair.lang

The value for “Default system UI language” is  “en-US.” This means the running OS’s language is English as spoken/written in the United States. Thus, the corresponding ISO to download  is labeled “English” online. Other languages (or English versions) are labeled more explicitly.

Grabbing an ISO for Repairs

To obtain Current Branch ISOs, please visit the Download Windows 10 page. For Insider Preview ISOs, please visit the Windows Insider Preview Downloads page. For older ISOs, I find and its Windows ISO Downloader  absolutely invaluable.  (It grabs only official Windows ISOs from despite its apparently dodgy appearance and Asian location). I could download and use this ISO for repairs on my production PC:


Notice it includes the edition (“Enterprise”), bittedness (“x64”), language (“en-us”), and build (“17115”) in the filename. Good stuff! It tells me enough to let me know if I have a workable match or not. Your chosen ISO’s filename should do the same for you.

March 14, 2018  12:42 PM

MS Offers New Spectre Updates

Ed Tittel Ed Tittel Profile: Ed Tittel
Firmware, Windows 10, Windows Security, Windows Update

Late yesterday, another post on the Windows Blogs for Windows 10 appeared. It offers additional news and insight, and something of a progress report, on Spectre and Meltdown issues. It’s from John Cable, MS Director of Program Management, Windows Servicing and Delivery. The title reads “March 2018 Windows security update — Expanding our efforts to protect customers.” But it isn’t until you get to the second heading that things get interesting. Labeled “Expanding … coverage … to address Spectre and Meltdown vulnerabilities” it tells us MS offers new Spectre updates. A bit of digging is required to understand what’s going on here, though.

Understanding How MS Offers New Spectre Updates

Bottom line: coverage for microcode updates through the Microsoft Catalog is expanding. For a full list of covered items, one is advised to consult KB4093836. The short list is Skylake, Kaby Lake and Coffee Lake processors. You actually must  visit KB409007 to see that list or a download link  from the Microsoft Update Catalog. All that said, I applied that update to my Skylake production desktop without difficulty. I didn’t notice any perceptible performance delays added thereby, but my day is still young!

Where does this leave the world in terms of Windows coverage for Intel processors, one might wonder? According to Wikipedia’s “List of Intel Processors,” not very far. Most of those processors came out some time after the start of 2015. The list of major CPUs by family name has the following timeline:

Sandy Bridge (2007) → Ivy Bridge (2012) → Haswell (2013) →
Broadwell (2014) → Skylake (2015) → Kaby Lake (2016) → Cannonlake\Coffee Lake (2017)

Only the items in red are covered for this vulnerability. My two Lenovo laptops have Sandy Bridge (i7-2640M) CPUs. The Surface Pro 3 has a Haswell (i7-4650U). The  Dell Venue Pro 11 7130 likewise Haswell (i5-4210Y), and my Dell XPS 2720 again Haswell (i7-4770S). My production desktop is Skylake (i7-6700). The boss’s mini-ITX has an Ivy Bridge (i7-3630QM), and the boy’s desktop has a Haswell (i7-4770K). That means that here where I live and work, only 1 in 8 machines is currently covered. Covering Haswell takes care of half the population. Lenovo promises to cover Sandy Bridge as soon as it can. But if MS doesn’t issue an Ivy Bridge update, that machine may never get coverage: Jetway, the mobo maker for that unit, shows little or no inclination to join the dance.

What’s Next?

I sincerely hope that Microsoft will dig back at least two more steps on the preceding timeline. That means providing coverage for at least Haswell and Broadwell processor families. Ideally, I’d like to see them go all the way back to Sandy Bridge. But, as always, only time we’ll tell. We’ll see!

March 12, 2018  12:30 PM

1803 Equals Spring Creators Update

Ed Tittel Ed Tittel Profile: Ed Tittel
Windows 10, Windows Update

Now we’ve got proof of the next version name and build number for Windows 10. It’s now showing up in the so-called Skip Ahead release (Build 17618). If you run the Get-VMHostSupportedVersion PowerShell cmdlet on that build, it confirms that terminology and equivalence quite visibly. Of course, that’s why I entitle this post 1803 equals Spring Creators Update. Here ’tis:

1803 Equals Spring Creators Update

The final line equates 1803 and Spring Creators Update with version 8.3.

If 1803 Equals Spring Creators Update, Does That Really Mean March 2018?

Probably not. In fact, the last few releases have gone public the month after their four-digit version identifiers. Thus, for example, 1709 appeared in October 2017, and 1703 in April of that year. Likewise, 1607 showed up in August 2016. To be fair, though, 1511 did appear in November 2015, and 1507 just barely squeaked out in late July of that same year.

All this chewed over, I’d pretty much assumed that 1803 would appear in April rather than March. But I’m hearing rumors that the actual public release date for 1803 could be as soon as March (or what the number says it should be: 3rd month of 2018) to as late as June (3 months behind). As usual when a feature upgrade is approaching “real soon now,” MS isn’t saying just yet. We will have to find out soon, though, as time marches ever forward.

March 11, 2018  12:32 PM

Post Build 17115 Driver Fix Routine Still Works

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

I upgraded my Dell Venue Pro 11 to Insider Preview 17115 recently. This morning, when I got into my office I tried to remote into that PC. It didn’t come up either in Remote Desktop Connection or when using NirSoft’s FastResolver to scan my LAN. “Oho!” I thought to myself, “I bet the network got reset from Private to  Public.” And indeed, that was true. But the Dell 1537 a/g/n adapter was also showing an exclamation point in DevMgr, with status “Device could not be started.” So I knew something was out of whack, and driver repairs were needed. And that’s how I can confirm that the post build 17115 driver fix routine still works.

Digging into the Post Build 17115 Driver Fix Routine

First, I simply tried the right-click “Update driver” menu option for the device. No joy. Next, I visited the Dell Drivers & Downloads page, where the built-in scanner (Dell Detect) used my service tag to look up machine specifics. There I found exactly what I was after:

Post Build 17115 Driver Fix Routine

This Dell installer launches the Qualcomm/Atheros driver update facility. This comes with several options to

  • Update the installed driver
  • Uninstall the current driver
  • Install a new driver

As fate would have it, I ended up exercising all three options before I succeeded in restoring the 1537 to working status. First, I tried update the installed driver (which required a reboot). But even after a reboot, the exclamation point and the same error message persisted in DevMgr. So I opted to uninstall the current driver (which required another reboot). Then, I performed the analog to a “clean install” from the driver download package. And yes, that meant a third reboot.

But when the machine came back up, and I got back onto the Windows 10 desktop, I was prompted to supply wireless login credentials. And indeed, the driver and its associated device were working once again.

Working through the Driver Fix Routine

This multi-step approach to fixing driver issues has worked for me on dozens of Insider Preview builds since I got going with Windows 10 in October, 2014. That’s so long ago, in fact, that they called it the Technical Preview back then. You can memorize the sequence of steps as “Repair-Remove-Reinstall” if you like, to summarize what you must go through to fix most driver difficulties.

Sometimes, Step 1 is the only step that’s needed. Other times, you might even have to find and use a third-party utility to uninstall (like guru3d’s display driver uninstaller for graphics cards) a busted driver in Step 2. And when Step 2 is necessary, that normally makes Step 3 mandatory, too. However, you can try the “Scan for hardware changes” Action menu item in DevMgr after Step 2, if you’re feeling adventurous.

However you slice it, the driver fix routine should see you to a working driver most of the time. When the routine fails, it may just be because the underlying device has hardware issues, so don’t discount that possibility.

March 9, 2018  8:48 PM

MS Foils Coin Mining Compelling Telemetry Case

Ed Tittel Ed Tittel Profile: Ed Tittel
ai, Machine learning, Windows 10, Windows Security

OK, then. I’m back from the Microsoft MVP Summit, and still catching up from all the buzz and running around. One recurring theme from the conference that is unclassified is the enduring value of telemetry. That’s the data that Windows 10 constantly ships back to HQ, to report on what systems and applications are doing. Various Microsoft mavens made the point that telemetry provides useful and important information. I heard this same message from numerous OS developers, applications folks, and security types. When MS foils coin mining in a big way, it’s obvious that telemetry can be a real system-saver.

MS Foils Coin Mining

The darker the country, the higher the Dofoil impact.
[Source: Microsoft; Click Image for Full-Sized View]

How Telemetry Translates into MS Foils Coin Mining

As reported at Infosecurity Magazine on March 8, MS detected a “massive and widespread” campaign that might have compromised half a million PCs or more. When the company detected — through telemetry from Windows Defender — a large number of sophisticated Trojans on March 6, it knew something was up. Over the next 12 hours, in fact, Defender fended off more than 400K new instances of those same Trojans. 73% of the reports came from Russia, 18% from Turkey, and 4% from Ukraine. They all pointed to a new strain of DoFoil (also called “Smoke Loader”) in the wild. DoFoil is popular because it uses the NiceHash function. This allows it to mine for a variety of cryptographic currencies. These particular samples mined Electroneum coins, but it could have been Bitcoin, Ethereum, or others.

The story quotes a March 6 Microsoft Secure blog post entitled “Behavior monitoring combined with machine learning spoils a massive Dofoil coin mining campaign.” Please read that story for all the interesting and intricate details of this clever and intricate attack. My point is that MS was able to use telemetry data to identify this outbreak, and to make sure its defense mechanisms could handle it and fend it off. If that telemetry data hadn’t been available, MS would have had to react to the attack after the fact. And because clean-up and repair are so much harder, more time-consuming, and expensive, that would have not been good at all. The following chart shows how telemetry drives recognition and response through machine learning:

The MS caption for this figure reads “Layered machine learning defenses in Windows Defender AV.”
[Click image for full-sized view.]

Again, if it weren’t for telemetry providing the data to feed the analysis and power those defenses, AI and machine learning would have nothing to work on — especially not in anything close to real time. And that, dear readers, is a compelling illlustration of why telemetry is valuable and important stuff!

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: