A few days ago I stumbled upon a question on the Microsoft Deployment Toolkit (MDT) forum where a user asked for guidance on how to install support for additional keyboard layouts using MDT. This post explains how you can add additional keyboards in Windows during OSD.
Automated OS deployment became common as IT professionals install systems using tools like Microsoft Deployment Toolkit or System Center Configuration Manager. In most cases, deploying Windows OS is fairly straightforward if you follow established best practices. However, there are still issues out there that may catch you off guard and you will suffer the consequences of task sequences misbehaving.
These days most of my blog posts start off with a question from a customer. At least, this time around the question was relatively simple: How do you sideload a modern application into Windows 10? If you have followed Windows 10 development closely, then you have probably heard that Microsoft Deployment Toolkit has the ability to sideload apps, assuming you have the necessary source files handy. But what if you are using a third-party tool to deploy applications?
Quite a few of my blog posts start off with a customer engagement - this one is no different. This week I am implementing a LoginVSI Automation Machine powered RDS infrastructure at a large automotive company. This process involves packaging quite a few applications including Dell Active Roles 7.1 MMC Interface, a single, intuitive tool designed for comprehensive privileged account management in Active Directory and Azure Active Directory. Packaging Dell Active Roles console is *SUPER* easy with Login VSI Automation Machine because it comes in an MSI package, so all you need to do is simply importing the MSI file into the media repository, creating the corresponding package and adding Install MSI action item. However, when opening the Dell Active Roles 7.1 console, the following error reared its ugly head: "MMC could not create the snap-in. The snap-in might not have been installed correctly.", followed by "CLSID: {D50F5BB7-337F-4A59-8797-BDA0B7DC1DF0}".
The other day, as I was working with a customer on improving and optimizing his Windows 10 image, one of IT technicians asked if it would be possible to import a wireless network profile to devices during the OS deployment without resorting to Group Policies (I am sure they had good reasons). By deploying these settings, the customer hoped to minimize the effort that end users require to connect to the corporate wireless network.
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.
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
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.