I bet many of you, like me, performed system maintenance duties for your family. Last week my mom complained that her Windows 10 PC was extremely sluggish. For example, when she opened Microsoft Edge - which I consider to be the best and the most secure web browser on the market for nontech savvy folks - it took round about 10-20 seconds for the browser to become responsive. I had no choice but to investigate. After a couple of minutes with SysInternals tools, I was able to determine the cause and to come up with a workaround.

As a reader of this blog, I suspect that you, like me, are a frequent visitor to TechNet forums. Earlier today, a user posted a question on the Microsoft Deployment Toolkit (MDT) forum asking for guidance on how to enable Version 1 of the Server Message Block (SMB) protocol in MDT generated Windows PE boot images. In case you have not heard, you should stop using SMB1. In Windows 10, version 1709 (Fall Creators Update) and Windows Server, version 1709 (RS3), the Server Message Block version 1 (SMBv1) network protocol is no longer installed by default. This also applies to the latest version of Windows ADK (Windows Assessment and Deployment Kit). The full removal has begun.

I haven't blogged the last couple of days because I was busy answering questions on TechNet. A couple of posts ago I talked about the importance of spending some quality time on TechNet as it may bring interesting cases to your attention. Today, I would like to highlight one of these cases in hopes that someone from the Microsoft Deployment Toolkit Team team is out there listening.

Windows 10 Fall Creators Update (1709) includes a number of enhancements over the previous Windows 10 release in various areas. You can see a detailed list of the changes here. Each major new version of Windows 10 also includes dramatic changes to Microsoft Edge, including a number of performance, security, and compatibility improvements. In addition, Microsoft continues to improve management capabilities for Microsoft Edge in an Enterprise deployment scenario.

As a reader of this blog, I suspect that most of you are already starting to work with Windows 10 Fall Creators Update (1709). As part of that process, you are probably taking a look at provisioned apps - most likely you want to ensure that only a choice selection of apps is being installed, whenever a user logs on either for the first time or after installing a feature update on a Windows 10 computer, because app installation directly impacts logon time.

In a desperate effort to make this blog post worth reading and not go through the indignity of having to write about Windows 10 1709, I have turned to the headline-generating festival currently ongoing on the net: the vulnerability in Trusted Platform Module (TPM) produced by Infineon Technologies AG which could allow security feature bypass.

Quite a few of my blog posts start off with a customer engagement - this one is no different. This week I held another Windows 10 deployment workshop in Munich where I emphasized how Microsoft Deployment Toolkit is a powerful OS deployment tool which allows a high grade of Windows 10 golden image customization. One of the questions was "Is it possible to remove the "Quick Assist" application from a Windows 10 "Fall Creators Update" (1709) image using Microsoft Deployment Toolkit? The answer was a resounding "yes" because #PowerShellIsKing

In case you have not heard, you should stop using SMB1. Not only is it 30 years old and was publicly deprecated back in 2014, it was also superseded by SMBv2 all the way back in 2007. In Windows 10, version 1709 (Fall Creators Update) and Windows Server, version 1709 (RS3), the Server Message Block version 1 (SMBv1) network protocol is no longer installed by default. The full removal has begun.

There is a caveat: while there are few valid use cases left in modern enterprises where SMB1 is still required, you may still be running a product that explicitly requires SMBv1. In my personal experience, an attempt to get rid of an outdated product, may hit a snag and the conversation with the CEO may go like this:

Security Officer: "Microsoft removed SMBv1 in the latest edition of Windows 10 because it is an older protocol and it has known security issues regarding ransomware and other malware."
CEO: "Is it possible to reinstall it?"
Security Officer: "Yes, but Microsoft strongly recommends that we do not reinstall it as SMBv1 was the main attack vector for the recent WannaCry outbreak."
CEO: "You do know I am the CEO, right?"

Case and point, SMBv1 is bad, really bad and you should never, ever reinstall it. But - if this is your only option - it is very easy to enable SMB1 in your environment during OSD. Simply add an Install Roles and Features step in your task sequence and select SMB 1.0/CIFS File Sharing Support feature.

Alternatively, run this simple PowerShell script:

# Determine where to do the logging 
$tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment 
$logPath = $tsenv.Value("LogPath")  
$logFile = "$logPath\$($myInvocation.MyCommand).log"

# Start the logging 
Start-Transcript $logFile
Write-Host "Logging to $logFile"

# Start Main Code Here

Write-Host "Enabling SMB1 optional feature."
Enable-WindowsOptionalFeature -Online -FeatureName smb1protocol -NoRestart

# Stop logging 
Stop-Transcript

EnableSMBv1.ps1

As a reader of this blog, I suspect that you, like me, are a frequent visitor to TechNet forums. Yesterday, a user posted a question on the Microsoft Deployment Toolkit (MDT) forum asking for guidance on how to disable Version 1 of the Server Message Block (SMB) protocol in MDT generated Windows PE boot images. Version 1 of the Server Message Block (SMB) protocol was developed in the early days of personal computer networking, and as Ned Pyle wrote in a blog post in September of 2016 Stop using SMB1 there are many reasons to cease using it on your networks as it is vulnerable to a man-in-the-middle attack.

A few months ago a customer complained that on a Dell Optiplex 7040 MiniTower the boot menu contained multiple entries for the "Windows Boot Manager". Given that we were in the process of deploying Windows 10 client and the importance of the customer, I immediately started troubleshooting. This particular case is especially interesting because it might affect a large number of users and the vendor was not aware of the issue.