Tuesday, 10 October 2017 12:49

Re-Enable SMBv1 in Windows 10 1709 Using MDT

Written by

image

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

Thursday, 28 September 2017 07:12

Disabling SMBv1 in WinPE through MDT

Written by

image

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.

Monday, 25 September 2017 17:56

The Case of Duplicate Firmware Objects in BCD

Written by

image

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.

Thursday, 21 September 2017 18:39

TPM Upgrade Process on Dell & HP Systems Using MDT

Written by

image

In my last blog post, I discussed clearing Trusted Platform Module (TPM) using PowerShell and MDT. This time I’m turning my attention to another issue: field upgrading TPM from 1.2 to 2.0 specification on HP and Dell systems which support discreet TPM switching.

Systems that shipped with Windows 7 from the factory will have TPM 1.2, however, most modern systems feature a firmware based component running in a trusted execution environment on a general purpose SoC, which allows discrete TPM mode switching in real time. Customers I worked with in the past couple of months and which roll out Windows 10 intend to make use of important security advantages of TPM 2.0 specification including greater crypto agility by being more flexible with respect to cryptographic algorithms, newer algorithms, which can improve drive signing and key generation performance, a more consistent experience across different implementations and a consistent dictionary attack protection guarantee.

Page 1 of 3

Recent Posts